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
