4 Mar
2008
4 Mar
'08
1:58 p.m.
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(a)pernau.at> wrote:
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.
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 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&gr…
Regards,
Ovidiu Sas
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users