2 Mar
2008
2 Mar
'08
4:49 p.m.
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:
--
Jiri Kuthan http://iptel.org/~jiri/
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users