3 Mar
2008
3 Mar
'08
8:06 p.m.
Jiri Kuthan wrote:
At 12:44 29/02/2008, Klaus Darilion wrote:
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
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)