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@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@openser.org
>>>>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users@openser.org
>>>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users@openser.org
>>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users@openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>
>


_______________________________________________
Users mailing list
Users@openser.org
http://openser.org/cgi-bin/mailman/listinfo/users