Subject: Re: Reliable 1xx w/BYE?

From: John Hearty <[email-masked]>
Date: Wed, 05 May 1999 08:28 -0500 (CDT)

Jonathan Rosenberg wrote:

>Adam B. Roach wrote:
>> 
>> We've been putting together a design with reliable 1xx messages
>> based on draft-ietf-mmusic-sip-100rel-00.txt, and I've run into
>> a strange situation.
>> 
>> In the case that the SIP nodes in question support reliable 1xx
>> messages, how do we handle the receipt of 1xx messages in response
>> to a request other than INVITE?
>> 
>> I see three options:
>> 
>> 1) Read literally, the current draft would seem to imply that an
>>    INVITE message would be used to acknowledge a 100 class message
>>    sent in response to, for example, BYE. The dangers in doing so
>>    should be obvious.
>
>The draft is really targeted at INVITE. We hadn't considered other
>methods, since they are substantially less important. INVITE, unlike
>other methods, generally requires human interaction to answer. For most
>other requests, the final response comes almost immediately (of course,
>this doesn't have to be the case). Furthermore, the main reasons for 1xx
>reliability are interoperability with the PSTN, where the provisional
>responses to the original INVITE are needed. Its not necessary to get
>them for other methods. So, in the interests of simplicity, I would vote
>for keeping this just for INVITE, unless there is a compelling reason
>otherwise.

 This sounds reasonable to me.

>
>Also, I believe you had mentioned in a previous note that the spec
>allows proxies to not forward provisional responses. I agree this should
>be changed, making it mandatory to forward them in order to achieve end
>to end (rather than hop by hop) reliability. However, there is an issue
>here: response implosion. A request which forks multiple times might
>generate lots of provisional responses. This is one of the reasons why
>forwarding them is optional in the first place (and why forwarding 100
>(not 1xx) responses is not allowed). So, we can:
>
>1. not worry about it, since the implosion problem may not be that
>severe (a fork to 1000 UAS is unlikely)
>
>2. disallow forking when reliable provisional responses are used
>
>I'm inclined to not worry about it, but I'd welcome comments otherwise.

2 might complicate or break features in the eyes of users, I don't
think that is a very good option.  I agree it is unlikely there would
normally be more than a handful of forked requests, so 1 seems like
a good option.

John Hearty
MCI Worldcom