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)
-jiri
p.s. the argument 3) is an oxymoron. By using noisy_timer the proxy becomes in fact stateless.
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/