[Users] provisional response management ( 100 Trying )
Evan Borgström
evan.borgstrom at ca.mci.com
Thu Jul 20 20:25:55 CEST 2006
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 at openser.org [mailto:users-bounces at 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 at openser.org
>>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>
More information about the sr-users
mailing list