Hi,
Evan Borgström wrote:
Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message.
Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB.
The question is not whether sl replying is good or not - it for sure is. The question is how to be 100% conformant.
However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some lower layered network entity, so, from the uac's point of view, the 2 100s should not be a problem.
However, adding a config for tm not to take care of the 100 might be the cherry on the cake.
WL.
ps. Imo, this is one of ser/openser's problems: one script function can actually take some more (more or less documented) "atomic" actions than its name states (even in cases where otherwise could be done, without a performance or complexity impact), which, from a strictly programming point of view is completely wrong.
-Evan
T.R. Missner wrote:
You have the question exactly correct
Now - how can I do this?
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying )
Hi,
Norman Brandinger wrote:
At the top of our ROUTE_INVITE, we have:
#---------------------------------------------------------------------
- # Let the UA know we are working on their request - # they
shouldn't send retransmissions
#---------------------------------------------------------------------
sl_send_reply("100", "Trying");
This seems to work and it was adapted from code used during REGISTER processing.
If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac.
The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100.
Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying.
The question is how to prevent this, if I got it right...
WL.
Regards, Norm
Klaus Darilion wrote:
AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module.
regards klaus
T.R. Missner wrote:
Hello,
I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward
the message using t_relay.
Since I have already sent a 100 trying manually I'd like to short circuit the 100 t_relay sends so multiple 100 trying messages aren't
sent.
Does anyone know of a way to do this?
Thanks,
T.R.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users