<br>Being normative, there's also an RFC relating to the provisional replies to non-INVITE transactions, RFC 4320, which does allow sending 100 provisional responses, and even recommend it, under some circumstances. <br><br>
Just my 2 cents.<br><br>Samuel.<br><br><div><span class="gmail_quote">2006/7/20, Evan Borgström <<a href="mailto:evan.borgstrom@ca.mci.com">evan.borgstrom@ca.mci.com</a>>:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
<br> Yep, section 21.1 says that. It's a perfect example of the grey area<br>the RFC creates and why most of us send provisional responses for<br>most/all messages. :)<br><br> Just remember that if you're going to sl_send_reply with a 100 for all
<br>messages you should first check that method != ACK as ACK's MUST NOT<br>generate a provisional message.<br><br>-Evan<br><br>Klaus Darilion wrote:<br>> On Thu, July 20, 2006 20:25, Evan Borgström said:<br>>> Well, if we're going get technical about conforming to the RFC then
<br>>> sending a 100 message for anything other than an INVITE is a "SHOULD NOT".<br>><br>> AFAIK somewhere in the RFC they say you should send a provisional response<br>> if the processing of the requests (till we can send a final response) will
<br>> take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine.<br>> Especially for REGISTER which is handled stateless in openser.<br>><br>> regards<br>> klaus<br>><br>> PS: If you still want to know how to do it without 2x100:
<br>> Use t_newtran and t_forward_nonack.<br>> <a href="http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK">http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK</a><br>><br>>> <a href="http://8.2.6.1">
8.2.6.1</a> Sending a Provisional Response<br>>><br>>> One largely non-method-specific guideline for the generation of<br>>> responses is that UASs SHOULD NOT issue a provisional response for a<br>
>> non-INVITE request. Rather, UASs SHOULD generate a final response to<br>>> a non-INVITE request as soon as possible.<br>>><br>>><br>>> However, to be RFC strict multiple responses to INVITE's are indeed
<br>>> allowed. Check section 13.1<br>>><br>>><br>>> Before sending a final response, the UAS can also send provisional<br>>> responses (1xx) to advise the UAC of progress in contacting the
<br>>> called user.<br>>><br>>> After possibly receiving one or more provisional responses, the UAC<br>>> will get one or more 2xx responses or one non-2xx final response.<br>>><br>>>
<br>>> All of my real world practices show that sending provisional messages<br>>> for non INVITE messages is a big help, especially when you get into<br>>> presence and IM related stuff. All too often clients like eyeBeam
<br>>> re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency<br>>> within the network if you don't send a 100 trying upon receipt. So for<br>>> me even if it's a SHOULD NOT it still makes my life easier than dealing
<br>>> with questions about receiving IM's twice...<br>>><br>>> -Evan<br>>><br>>> Weiter Leiter wrote:<br>>>> Hi,<br>>>><br>>>> Evan Borgström wrote:<br>>>>> Why would you want to prevent it? 1XX class messages are all
<br>>>>> provisional, do not solicit a response and are never forwarded upstream<br>>>>> so only the previous hop will get multiple 100 messages which will<br>>>>> effectively limit any chance of the upstream hop re-transmitting the
<br>>>>> original message.<br>>>>><br>>>>> Take the following example; A user sends their initial INVITE, you<br>>>>> sl_send_reply 100 and then check your proxy_authorize which returns a
<br>>>>> 407 and challenges the user. The user sends the second invite with<br>>>>> credentials you sl_send_reply 100 and then check your proxy_authorize<br>>>>> again and say, for instance, your DB server is now under heavy load (a
<br>>>>> cronjob runs, etc) and takes longer then 1s to respond, since you<br>>>>> haven't called t_relay yet which generates the second 100 message your<br>>>>> initial 100 message would still stop the user from re-transmitting the
<br>>>>> INVITE while proxy_authorize is waiting for the DB.<br>>>>><br>>>> The question is not whether sl replying is good or not - it for sure is.<br>>>> The question is how to be 100% conformant.
<br>>>><br>>>> However, imho, this misalignment is completely negligible, as if you<br>>>> make abstraction of the possible different reason phrase, the two<br>>>> messages will be identical - this duplicating can be done by some lower
<br>>>> layered network entity, so, from the uac's point of view, the 2 100s<br>>>> should not be a problem.<br>>>><br>>>> However, adding a config for tm not to take care of the 100 might be the
<br>>>> cherry on the cake.<br>>>><br>>>> WL.<br>>>><br>>>> ps. Imo, this is one of ser/openser's problems: one script function can<br>>>> actually take some more (more or less documented) "atomic" actions than
<br>>>> its name states (even in cases where otherwise could be done, without a<br>>>> performance or complexity impact), which, from a strictly programming<br>>>> point of view is completely wrong.
<br>>>><br>>>>> -Evan<br>>>>><br>>>>> T.R. Missner wrote:<br>>>>><br>>>>>> You have the question exactly correct<br>>>>>><br>>>>>> Now - how can I do this?
<br>>>>>><br>>>>>> -----Original Message-----<br>>>>>> From: <a href="mailto:users-bounces@openser.org">users-bounces@openser.org</a> [mailto:<a href="mailto:users-bounces@openser.org">
users-bounces@openser.org</a>] On<br>>>>>> Behalf Of Weiter Leiter<br>>>>>> Sent: Thursday, July 20, 2006 1:31 PM<br>>>>>> To: Norman Brandinger<br>>>>>> Cc: users
<br>>>>>> Subject: Re: [Users] provisional response management ( 100 Trying )<br>>>>>><br>>>>>> Hi,<br>>>>>><br>>>>>> Norman Brandinger wrote:<br>
>>>>><br>>>>>>> At the top of our ROUTE_INVITE, we have:<br>>>>>>><br>>>>>>><br>>>>>>> #---------------------------------------------------------------------
<br>>>>>>> - # Let the UA know we are working on their request - # they<br>>>>>>> shouldn't send retransmissions<br>>>>>>><br>>>>>>> #---------------------------------------------------------------------
<br>>>>>>> -<br>>>>>>> sl_send_reply("100", "Trying");<br>>>>>>><br>>>>>>> This seems to work and it was adapted from code used during REGISTER
<br>>>>>>> processing.<br>>>>>>><br>>>>>> If I got Missner's problem right, he wants to prevent sending multiple<br>>>>>> 100 replies back to the uac.<br>>>>>>
<br>>>>>> The rfc says - Page 109, paragraph 5 - that "MUST be forwarded<br>>>>>> immediately [...] Any provisional response other than 100 (Trying)"<br>>>>>> and<br>
>>>>> later, in same paragraph that "A stateful proxy MUST NOT immediately<br>>>>>> forward any other [= 101<=x<=299] responses". Now, it's true that in<br>>>>>> this case the proxy would not literally forward a 100 reply back, but
<br>>>>>> the uac would still see 2x100.<br>>>>>><br>>>>>> Now, if he does SL reply at the beginning, the tm module will, again,<br>>>>>> send a 100 on his own, before relaying.
<br>>>>>><br>>>>>> The question is how to prevent this, if I got it right...<br>>>>>><br>>>>>><br>>>>>> WL.<br>>>>>><br>>>>>>
<br>>>>>>> Regards,<br>>>>>>> Norm<br>>>>>>><br>>>>>>> Klaus Darilion wrote:<br>>>>>>><br>>>>>>>> AFAI remember there was function t_relay_no_ack or similar. Take a
<br>>>>>>>> lookat the README from TM module.<br>>>>>>>><br>>>>>>>> regards<br>>>>>>>> klaus<br>>>>>>>><br>>>>>>>>
T.R. Missner wrote:<br>>>>>>>><br>>>>>>>>> Hello,<br>>>>>>>>><br>>>>>>>>><br>>>>>>>>><br>>>>>>>>> I want to send an immediate 100 trying message when an Invite is
<br>>>>>>>>> received, then I do a DB lookup, then I rewrite the RURI and<br>>>>>>>>> forward<br>>>>>>>>><br>>>>>>>>> the message using t_relay.
<br>>>>>>>>><br>>>>>>>>> Since I have already sent a 100 trying manually I'd like to short<br>>>>>>>>> circuit the 100 t_relay sends so multiple 100 trying messages
<br>>>>>>>>> aren't<br>>>>>>>>><br>>>>>>>>> sent.<br>>>>>>>>><br>>>>>>>>> Does anyone know of a way to do this?
<br>>>>>>>>><br>>>>>>>>><br>>>>>>>>><br>>>>>>>>> Thanks,<br>>>>>>>>><br>>>>>>>>>
<br>>>>>>>>><br>>>>>>>>> T.R.<br>>>>>>>>><br>>>>>>>>><br>>>>>>>>><br>>>>>>>>>
<br>>>>>>>>> --------------------------------------------------------------------<br>>>>>>>>> ----<br>>>>>>>>><br>>>>>>>>><br>
>>>>>>>> _______________________________________________<br>>>>>>>>> Users mailing list<br>>>>>>>>> <a href="mailto:Users@openser.org">Users@openser.org
</a><br>>>>>>>>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br>>>>>>>>><br>>>>>>>> _______________________________________________
<br>>>>>>>> Users mailing list<br>>>>>>>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>>>>>>>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">
http://openser.org/cgi-bin/mailman/listinfo/users</a><br>>>>>>>><br>>>>>>>><br>>>>>>>><br>>>>>>>><br>>>>>>> _______________________________________________
<br>>>>>>> Users mailing list<br>>>>>>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>>>>>>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">
http://openser.org/cgi-bin/mailman/listinfo/users</a><br>>>>>>><br>>>>>>><br>>>>>> _______________________________________________<br>>>>>> Users mailing list
<br>>>>>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>>>>>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br>
>>>>><br>>>>>> _______________________________________________<br>>>>>> Users mailing list<br>>>>>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>>>>>>
<a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br>>>>>><br>>>>> _______________________________________________<br>>>>> Users mailing list
<br>>>>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>>>>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br>>>>>
<br>>>>><br>>><br>>> _______________________________________________<br>>> Users mailing list<br>>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">
http://openser.org/cgi-bin/mailman/listinfo/users</a><br>>><br>><br>><br><br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@openser.org">Users@openser.org</a>
<br><a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></div><br>