Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT".
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible.
However, to be RFC strict multiple responses to INVITE's are indeed allowed. Check section 13.1
Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.
All of my real world practices show that sending provisional messages for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice...
-Evan
Weiter Leiter wrote:
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