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

Jiri Kuthan jiri at iptel.org
Mon Mar 3 16:58:39 CET 2008


At 15:33 03/03/2008, Anatoly Pidruchny wrote:
>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.

see bellow. Because it may be legitimate to have a very long call setup period
(consuming memory), and you don't know in advance how long is long enough. Then, 
applying the "better-than-nothing" principle, it is beneficial to conserve memory 
and go stateless, rather than experiencing a stateful cancellation of transactions 
due to short timers or memory exhaustion due to long timers. 

A partial answer to this dilemma is the RFC3261 UAS-driven lifetime extension, which
should help to extend the timer using recepient's knowledge. 

>>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. 

Well, you can't really separate those two since a proxy terminate the INVITE transaction when
the fr_int_timer expires. There is no good timer length to be had. Sometimes
for "on-no-reply" type-of-services, it may be susbriber-driven, sometimes like with
the gateway example, it may be protocol-driven, in all cases it may have very different
lengthes. ( higher than 5 minutes may be really useless for personal call forwarding,
lower than 5 minutes may prohibit my calls to immigration office). 

Thus there are cases, when unsure about what length is long enough to keep callers happy
and short enough to avoid memory exhaution (which is 100MB/min with full-stem traffic),
you better silently drop the transaction context on hope to be able to complete
pending call setups. 

To provide an approximation of what time is actually good (so that if the timer timesout
you can feel safe to cancel the transaction), IETF came up with the UAS-driven timer
extension as introduced in RFC3261.


>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.

This is about what to do when the timer strikes, in particular
when it strikes earlier than you hoped for. If you think that it is
always reasonable to cancel on timer expiration (which I would second
*if* UASs were RFC3261-compliant in this matter), there is no question.


>>(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.

I hope you don't mind if I don't join this procedure as I am not a great
fan of engineering by counting raised hands. Here is at least my suggestion
so that folks interested in this process can create their own opinion.
The suggestion is to look how devices interoperate today (particularly check 
if they respect RFC3261 and resend provisional responses for early media). 
If they comply, remove it, otherwise keep it. It is a RFC2543 backwards 
compatibility hack, if the backwards compatibility is no longer issue, it can be easily 
removed (which is really trivial to do -- the only trouble is possible
interop issues).

If folks don't know which is the case interop-wise, I think leaving things
"as is" is proper answer: having it permamnently turned on doesn't really
cause any harm, and those with interop issues can still turn it off.
If it ain't broke, don't fix it 


>>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?

exactly. Being stateful is not a software-related feature, it is a feature of a specific
transaction at a given point of time. With noisy_timer the transaction context is silently dropped, 
and the transaction can still complete statelessly. There are cases when stateless completion is 
better than none. For example, load-balancers may loose stickeness but it is perceived
as better if they complete without stickeness than if they fail. (OTOH, those who account
from SER using transactional logic typicall prefer cancelled calls over incomplete CDRs.)
Similar use-case is with different failover stories where both machines are still able
to send traffic, and it is better if the newly-active machine completes a transaction
statelessly, whereas the active-before doesn't disturb by sending CANCELs around.


-jiri


>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
>>
>>  
>
>
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/





More information about the Users mailing list