Subject: SIP Supported Header

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Mar 2000 12:35:43 -0500

Folks,

I have just sent draft-ietf-sip-serverfeature-02.txt to IESG for
consideration as proposed standard. This small but important extension
clears the way for several other documents which depended on it,
including the reliable provisional responses and session timer.

I'd now like to try and focus some discussion on the reliable
provisional responses draft:
http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-00.txt

I have received no comments on this at all. I encourage people to take a
look at it, and particularly comment on some of the open issues. For
example, right now, cumulative acknowledgements are supported. Is this
too complex?

There also need to be some minor changes to align it with the final
Supported header draft. I will also shorten the option tag to "prel" for
provisional reliability.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 08 Mar 2000 13:48:01 +0000

The draft talks about when it's OK to generate new reliable responses
for a transaction, but it doesn't seem to say anything about whether
final responses can be generated by a UAS which has outstanding
unacknowledged reliable responses.

I believe the UAS must be allowed to generate a final response at any
time. 

The question is what happens with existing 'orphan' reliable responses
and corresponding PRACKS. They can either terminate normally, i.e. the
UAS continue retransmitting those reliable responses as it would have
done had a final response not been sent and likewise the UAC still
PRACKS them, or else maybe they could be terminated somehow - the UAS
stops retransmitting them, and the UAC never PRACKS anything for which
it has received a final response.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Mar 2000 02:25:55 -0500

> I believe the UAS must be allowed to generate a final response at any

Yes, agreed.

> it has received a final response.

Hmm. Good question. I tend to lean towards having those orphaned
provisional responses still be PRACKED. Here's my reasoning:

1. These responses were sent reliably since they contain some important
and useful information. It may be that this information is no longer
useful once the final response is sent, but then again, it may be that
it is still useful. So, if the user tries to send a provisional response
reliably, lets always deliver it. Let the application decide whether its
useful after a final response.

2. Lets keep transactions independent. We went through a similar thing
with CANCEL, and the state machines were confusing until we decided to
make CANCEL a mini-transaction that does nothing but ask the UAS to
quickly answer the request. I think we will see confusion in the PRACK
processing if its operation becomes dependent on events in other
transactions.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 13 Mar 2000 13:00:10 +0000

> processing if its operation becomes dependent on events in other

It is certainly simpler to just always complete according to the
original plan, so to speak. Interestingly, though, one might have
thought it to be OK for the UAS to stop retransmitting reliable,
un-PRACK'ed responses when it sends a final response. The theory here
would be that this is so because either
  1) the reliable response has been lost before reaching the UAC, and so
there's no observable difference anywhere in the network from it never
having been sent, or
  2) the UAS did receive the reliable response so no retransmission are
needed anyway.

The only snag I can see is that some proxy somewhere may in fact be
clever and act upon certain reliable responses, thus destroying
assumption 1) above, so it would appear to be prudent for the UAS to
retransmit as per the draft even in this case.

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Mar 2000 10:14:25 -0500

> retransmit as per the draft even in this case.

Its not so much the proxy, as the UAC. If the UAS sent the response
reliably, its probably because it contained some information that was
important for the UAC to see. Otherwise, it wouldn't have sent it
reliably in the first place.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 13 Mar 2000 15:45:55 +0000

> reliably in the first place.

The information carried in a reliable provisional response may or may
not still be useful after a final response has been sent. Actually, I
would expect most of the time it wouldn't be, but presumably the UAS
would know and could make its choice accordingly. As I was saying I'm
not advocating this, though.

Anders