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 >> <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
