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