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

[Bogdan-Andrei Iancu]

Hi guys,

Thanks a lot for the valuable input. In my opinion,trying to summarize 
the discussion:

 what we need is not to have a mechanism to ignore the C timer, but 
rather a better way to manage/control C timer.

This means:

1) dropping (after all) the "noisy_ctimer" as it proves to be more or 
less a hack

2) add new feature to manage/control C timer (like onreply route change 
support, different routes for timeout and failures, etc)..


Is this commonly agreed?

Regards,
Bogdan



Jiri Kuthan wrote:
> At 20:17 03/03/2008, Ovidiu Sas wrote:
>   
>> On Mon, Mar 3, 2008 at 2:06 PM, Klaus Darilion
>> <klaus.mailinglists at pernau.at> wrote:
>>     
>>> Jiri Kuthan wrote:
>>>  > At 12:44 29/02/2008, Klaus Darilion wrote:
>>>  >> I vote for "remove" and have it "on" always.
>>>  >>
>>>  >> I never saw a reason for this parameter
>>>  >
>>>  > Maybe underdocumentation is the point why many folks seem to be excited
>>>  > by removal :-)
>>>  >
>>>  > 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.
>>>  >
>>>  > This obstacle should be in theory removed in RFC3261 which allows 18x
>>>  > to extend the proxy server timer.
>>>  >
>>>  > (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)
>>>
>>>  I think there is no easy way to solve this. A workaround would be to
>>>  increase the fr_inv_timer in the reply route (e.g. after getting a 183
>>>  response) - but I fear this would be difficult to implement.
>>>
>>>  regards
>>>  klaus
>>>       
>> Another workaround would be a timeout_route 
>>     
>
> Yes -- actually I think it would be a   clean step to separaate failure_route
> in failure_route handling negative replies and timeout_route. (cc-ing serdev
> thus too). Reseting the timer from there to comply to RFC3261 or executing
> some service (all kinds of haunting) or going stateless if desirable and
> possible would be few examples of meaningful actions to be done from there.
>
>   
>> and there the admin can
>> take a decision:
>> - drop the transaction, disable CANCEL generation and switch to stateless mode
>> - re-arm the timer and stay in statefull mode
>>
>> Like this, the script has full control over the behavior of the server
>> and no under the hood tricky mechanism is involved.
>>     
>
> I like explicit control in this case esthetically better too.
>
> -jiri
>
>
>   
>> BTW: I would love to see this implemented for dialog timers :)
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1892203&group_id=139143&atid=743023
>>
>>
>> Regards,
>> Ovidiu Sas
>>     
>
>
>
> --
> Jiri Kuthan            http://iptel.org/~jiri/
>
>
> _______________________________________________
> Users mailing list
> Users at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
>