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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 >>>>>>> [email protected] >>>>>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >>> >> > > > _______________________________________________ > Users mailing list > [email protected] > http://openser.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
