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

Thu Feb 28 15:49:32 CET 2008

Bugs item #1903333, was opened at 2008-02-27 21:15
Message generated for change (Comment added) made by dan_pascu
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: Open
Resolution: None
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: 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