[OpenSER-Users] "noisy_ctimer" parameter in TM module

Anatoly Pidruchny apidruchny at newxt.com
Mon Mar 3 15:33:59 CET 2008


Jiri Kuthan wrote:
> Maybe underdocumentation is the point why many folks seem to be excited
> by removal :-)
>   

I do not think so. I think it should be removed because I do not know 
any reasons why you would not want to send CANCEL to the called party, 
but terminate the INVITE transaction in OpenSER and send 408 Request 
Timeout to the calling party when fr_inv_timer expires.

> Well -- with RFC2543 it could have been quite inconvenient for you to
> figure out that after say 90 seconds of early media (say on my favorite
> callee, German imigration office) you will be disconnected by a proxy
> server while stil in hope someone would answer for you. This is
> particularly annoying if the server in the path is playing a special
> purpose role (such as load-balancer) and surprises rest of the world
> with a CANCEL. this has been a real trouble in the field.
>   

Again, what you are complaining about is not at all the fact that 
OpenSER sends or does not send CANCEL to the callee when fr_inv_timer 
expires. What you are complaining about is just the fact that a proxy 
can terminate the INVITE transaction. In case of OpenSER it happens when 
fr_inv_timer expires. The problem could be that somebody configured 
OpenSER with fr_inv_timer parameter that is too short for you. This is a 
different issue that has nothing to do with the noisy_ctimer parameter 
that is discussed in this thread.

> This obstacle should be in theory removed in RFC3261 which allows 18x
> to extend the proxy server timer.
>   

You can start a different thread if you want to discuss ways to increase 
fr_inv_timer somehow dynamically. As I said, this issue has nothing to 
do with noisy_ctimer parameter.

> (It goes back to the INVITE transaction as whole being misconcepted in 
> the SIP protocol, but that's frankly not worth fixing now.)
>
> With that, my recommendation is to check behaviour of existing gateways
> before doing changes. (otherwise noisy_timer is undoubtably a confusing
> hack which if absent makes things simpler)
>   

So, do you vote to remove noisy_ctimer or not? From previous sections it 
looked like you are trying to defend keeping the noisy_ctimer parameter, 
but here you say that noisy_ctimer is a confusing hack and so you do 
want it to be removed.

> p.s. the argument 3) is an oxymoron. By using noisy_timer the proxy becomes
> in fact stateless.
>   

I do not understand what you are trying to say here. Are you saying that 
setting noisy_ctimer=1 somehow makes a proxy stateless?

Regards,
Anatoly.
>   
>> and always had it turned on.
>>
>> klaus
>>
>> Bogdan-Andrei Iancu wrote:
>>     
>>> Hi,
>>>
>>> I want to get some feedback from the users regarding one of the TM 
>>> parameters: "noisy_ctimer" .
>>>
>>> This parameter, is disabled, would try to let a call to ring for ever 
>>> (openser will never give internal timeout). But, the parameter is 
>>> automatically turned on (disregarding the script setting) in certain 
>>> conditions:
>>>     - 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)
>>>
>>> Following some discussion on the tracker, there is large support for 
>>> removing this parameter as:
>>>     1) it is difficult to anticipate the final behaviour due complicated 
>>> logic
>>>     2) due all dependencies, in 99% of the case, the param will be 
>>> automatically turned on
>>>     3)it breaks the RFC3261, which make mandatory to have a final reply 
>>> form a stateful proxy
>>>
>>> My question is:
>>>
>>> Is anybody having a good point in not removing this parameter (and 
>>> having noisy_ctimer behaviour all the time)?
>>>
>>> I'm pushing this question only on users list, as between the developers, 
>>> there is an consent in removing it ;)
>>>
>>>
>>> Regards,
>>> Bogdan
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>     
>
>
>
> --
> Jiri Kuthan            http://iptel.org/~jiri/
>
>
> _______________________________________________
> Users mailing list
> Users at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
>   





More information about the Users mailing list