20 Jul
2006
20 Jul
'06
10:22 p.m.
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:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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(a)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(a)openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users(a)openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users