Subject: Reliable 1xx w/BYE?

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 4 May 1999 10:53:19 -0500 (CDT)

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.

2) The scheme described in the draft could be employed with whatever
   method the orginal request was (e.g. BYE instead of INVITE)

3) It could be explicitly spelled out that reliable 100 class messages
   are supported only for INVITE messages

I beleive the most obviously useful solution is number 2. Does anyone
else have comments?

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
[email-masked]    |                  <*> | USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 May 1999 23:15:19 -0400

>    sent in response to, for example, BYE. The dangers in doing so

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.

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.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 5 May 1999 13:21:13 -0500 (CDT)

>> based on draft-ietf-mmusic-sip-100rel-00.txt, and I've run into
...
>for keeping this just for INVITE, unless there is a compelling reason

This sounds good to me (especially after further consideration, during
which I realised that even *final* responses are not ACKed). Perhaps the
next version of the spec should directly address the fact that
reliable 1xx responses do not apply to non-INVITE responses.

>I'm inclined to not worry about it, but I'd welcome comments otherwise.

I agree that option 1 seems to be the most appropriate. Forking proxies
are too useful to disallow in PSTN interworking situations.