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

[Klaus Darilion]

Bogdan-Andrei Iancu schrieb:
> 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

agreed

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

actually I never had any issues until now, nevertheless I think having a 
dedicated time_out route is a good idea.

regards
klaus

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