[OpenSER-Devel] [ openser-Bugs-1903333 ] noisy_ctimer parameter of the tm module has no effect

SourceForge.net noreply at sourceforge.net
Mon Mar 10 15:43:47 CET 2008


Bugs item #1903333, was opened at 2008-02-27 21:15
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1903333&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.2.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Anatoly Pidruchny (apidruchny)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: noisy_ctimer parameter of the tm module has no effect

Initial Comment:
As tested by Iñaki Baz Castillo, OpenSer SVN 3706 generates a CANCEL to the called after "fr_inv_timer" even if "noisy_ctimer" is 0 or 1.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-03-10 16:43

Message:
Logged In: YES 
user_id=1275325
Originator: NO

OK - following the discussion on the users mailing list, this parameter
was removed from openser 1.4 - better mechanism to control the timeout are
to be added.

Regards,
Bogdan 

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-28 21:02

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi, 

First of all, I put for discussion on the lists to see if there are other
opinion regarding this param.
If we decide to remove it, it will be done only for 1.4, as this is not a
bug fixe, so it will not be backported.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Anatoly Pidruchny (apidruchny)
Date: 2008-02-28 17:06

Message:
Logged In: YES 
user_id=1759384
Originator: YES

I also agree that this parameter should be removed. If everybody agrees
that is should go away then it will be removed only in version 1.4, right?
Then a note in the documentation for versions 1.2 and 1.3 about this
parameter saying that there are many conditions when this parameter is
turned on implicitly would be nice.

Regards,
Anatoly

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2008-02-28 16:56

Message:
Logged In: YES 
user_id=1395524
Originator: NO

I also agree that this parameter should go away.  Less things to configure
and well known expected behavior.
The AVP gives enough flexibility to allow long and short rings.

Regards,
Ovidiu Sas

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2008-02-28 16:51

Message:
Logged In: YES 
user_id=1296758
Originator: NO

I meant "implicitly turned on by some modules" in the last comment.

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2008-02-28 16:49

Message:
Logged In: YES 
user_id=1296758
Originator: NO

I agree with Bogdan that this parameter should go away. Not only it makes
no sense to let a phone ring forever (if that is desired, the INVITE
timeout can be set to a very long time) and it breaks RFC requirements, but
it's a very confusing feature, because one doesn't know when it's really
on/off given how many conditions need to be met for it not to send a
CANCEL. Many of these conditions are not obvious to a user and are done
under the hood (like for example the fact that some modules add failure
callbacks or explicitly truned on by some modules).

----------------------------------------------------------------------

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-02-28 13:20

Message:
Logged In: YES 
user_id=1844020
Originator: NO

Ok, it works but effectively I had to dissable acc, siptrace,
failure_route and parallel forking.

But after all of this I think as you Bogdan, it makes no sense at all
OpenSer not sending a CANCEL in this **specific** case (no acc, no cpl, no
siptrace, no parallel forking, no failure_route). It's a very improbable
case and the benefict of not generating that CANCEL is... very small?

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-28 12:43

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi,

First of all, let's be sure there is no bug and indeed it works as
expected. Inaki, please confirm (or not) your tests.

Secondly, I was wondering for some time id theis noisy_ctimer feature
really make sense or not - IMHO, I really do not see the purpose of having
noisy_ctimer off - calls ringing for ever.....First it is about logic, and
second it is a bit strange from processing point of view (I'm not sure, but
somehow it breaks the RFC3261, which make mandatory to have a final reply
form a stateful proxy). So, I would rather take this out and let all the
calls to expire according to fr and fr_inv timers.

Of course, the alternative, will be do document this, no problem ;).

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-02-28 12:21

Message:
Logged In: YES 
user_id=1844020
Originator: NO

ops, I have CPl enabled.

----------------------------------------------------------------------

Comment By: Henning Westerholt (henningw)
Date: 2008-02-28 11:48

Message:
Logged In: YES 
user_id=337916
Originator: NO

Hi all,

perhaps this conditions could be also added to the module readme to
prevent future confusion about this feature?

Henning

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-02-28 11:23

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi guys,

The noisy_ctimer feature is a bit complicated as it is automatically
trigger (even if you set it to 0) in certain conditions. 
So, the noisy_ctimer is automatically turned on (per transaction) if:
   - parallel forking is done
   - a failure route is set
   - a failure callback is set by other module (like acc, cpl, dialog,
etc)
   - a fr_invite timeout was configured via AVP
   - some reply was already received
   - no other module explicitly asked for this (like siptrace, acc,osp)

Can you check these conditions in your tests??

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Anatoly Pidruchny (apidruchny)
Date: 2008-02-28 00:08

Message:
Logged In: YES 
user_id=1759384
Originator: YES

I also tested on my environment that does not load acc module and just one
parameter for the tm module:

modparam("tm", "fr_inv_timer", 20)

After 20 seconds OpenSER generated the CANCEL to the called even though
noisy_ctimer was not set. I am using the snapshot version of OpenSER 1.2.x
downloaded on 1/25/2008. It was the latest snapshot of 1.2.x branch on that
date.

Regards,
Anatoly.

----------------------------------------------------------------------

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-02-27 23:50

Message:
Logged In: YES 
user_id=1844020
Originator: NO

I have tryed without ACC loaded and those parameters:

# -- tm --
modparam("tm", "fr_timer", 2)
modparam("tm", "fr_inv_timer", 5)
modparam("tm", "noisy_ctimer", 0)
modparam("tm", "onreply_avp_mode", 0)


After 5 seconds ringing OpenSer generates the CANCEL, when it's supposed
not to do it.

I can confitm that it didn0t occur in a previous version (OpenSer 1.2.X).
  

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2008-02-27 21:53

Message:
Logged In: YES 
user_id=1395524
Originator: NO

Make sure that you test this without the acc module loaded, as the acc
module will override the tm param settings:
http://www.openser.org/docs/modules/1.3.x/tm#AEN189

Regards,
Ovidiu Sas

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1903333&group_id=139143



More information about the Devel mailing list