[Users] provisional response management ( 100 Trying )

samuel samu60 at gmail.com
Fri Jul 21 09:30:15 CEST 2006


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.

Just my 2 cents.

Samuel.

2006/7/20, Evan Borgström <evan.borgstrom at ca.mci.com>:
>
>
>         Yep, section 21.1 says that. It's a perfect example of the grey
> area
> the RFC creates and why most of us send provisional responses for
> most/all messages. :)
>
>         Just remember that if you're going to sl_send_reply with a 100 for
> all
> messages you should first check that method != ACK as ACK's MUST NOT
> generate a provisional message.
>
> -Evan
>
> Klaus Darilion wrote:
> > 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
> >>
> >
> >
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060721/36dad5f8/attachment.htm>


More information about the sr-users mailing list