[Users] provisional response management ( 100 Trying )

[Evan Borgström]

	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.

-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