[Users] provisional response management ( 100 Trying )

Klaus Darilion klaus.mailinglists at pernau.at
Thu Jul 20 21:22:03 CEST 2006 

On Thu, July 20, 2006 20:25, Evan Borgström said:
>
> 	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".

AFAIK somewhere in the RFC they say you should send a provisional response
if the processing of the requests (till we can send a final response) will
take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine.
Especially for REGISTER which is handled stateless in openser.

regards
klaus

PS: If you still want to know how to do it without 2x100:
Use t_newtran and t_forward_nonack.
http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK

>
> 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
>>>
>>>
>>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>

More information about the Users mailing list