3 Mar
2008
3 Mar
'08
4:33 p.m.
Jiri Kuthan wrote:
Maybe underdocumentation is the point why many folks
seem to be excited
by removal :-)
I do not think so. I think it should be removed because I do not know
any reasons why you would not want to send CANCEL to the called party,
but terminate the INVITE transaction in OpenSER and send 408 Request
Timeout to the calling party when fr_inv_timer expires.
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.
Again, what you are complaining about is not at all the fact that
OpenSER sends or does not send CANCEL to the callee when fr_inv_timer
expires. What you are complaining about is just the fact that a proxy
can terminate the INVITE transaction. In case of OpenSER it happens when
fr_inv_timer expires. The problem could be that somebody configured
OpenSER with fr_inv_timer parameter that is too short for you. This is a
different issue that has nothing to do with the noisy_ctimer parameter
that is discussed in this thread.
This obstacle should be in theory removed in RFC3261
which allows 18x
to extend the proxy server timer.
You can start a different thread if you want to discuss ways to increase
fr_inv_timer somehow dynamically. As I said, this issue has nothing to
do with noisy_ctimer parameter.
(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)
So, do you vote to remove noisy_ctimer or not? From previous sections it
looked like you are trying to defend keeping the noisy_ctimer parameter,
but here you say that noisy_ctimer is a confusing hack and so you do
want it to be removed.
p.s. the argument 3) is an oxymoron. By using
noisy_timer the proxy becomes
in fact stateless.
I do not understand what you are trying to say here. Are you saying that
setting noisy_ctimer=1 somehow makes a proxy stateless?
Regards,
Anatoly.
and always had it turned on.
klaus
Bogdan-Andrei Iancu wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
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