Subject: Re: Provisional Response Draft (Was: SIP Supported Header)

From: [email-masked]
Date: Wed, 8 Mar 2000 09:44:38 +0530

Hi,
I have two basic questions on provisional responses draft.

1. Do we need the final 200 OK after PRACK ? The UA (UA1) which sent the
rel. prov. response wanted to make sure that this reached
   the UA it was designated for (UA2). Just like ACK does not need a
confirmation in INVITE, does PRACK need it ? Once UA1
  received a PRACK, it knows UA2 received it. Does UA2 need to know that
UA1 received his PRACK confirmation ? If he hasnt received, as it is the
prov. response will be retransmitted.

Howver, there seems to be a mention of a PRACK containing media desc. body
- is this anyway realted to 200K being mandatory for PRACK ?

2.Cumulative response: I guess the advantage of this was that one could
reduce network traffic by block PRACKing many informative
responses. However, I feel it would be simpler if it only responded to one
prov. response and not many - Im not sure if it really is so helpful wrt
network traffic compared to the extra work the UAs will have to do just to
correlate all the responses, ensure there are no
holes in seq numbering, etc. Anyway, this is a subjective opinion :-)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Jonathan Rosenberg <[email-masked]> on 03/07/2000 11:05:43 PM

To:   [email-masked]
cc:

Subject:  SIP Supported Header

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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Mar 2000 23:54:10 -0500

> prov. response will be retransmitted.

Strictly speaking, for reliability purposes, the 200 OK to PRACK is not
needed. However, I believe it should to be there for the sake of
ensuring that all unknown requests at proxies can be treated as if they
were BYE (in terms of routing/processing/transmission rules). Consider a
proxy that doesn't know PRACK. It receives one, and forwards it. It will
believe that the rules are the same as for BYE, and thus expect a
response. This means it will maintain transaction state until some timer
has expired. Its even possible that the proxy might send CANCEL on
expiration of the timer, and then send a 408 response to the PRACK. All
this would be reasonable if PRACK has a response. If PRACK has no
response, proxies really MUST understand it, since the previous behavior
is going to confuse it and other entities involved. This means we need
to add a Proxy-Require header. I don't want to do that, since it affects
interop and the ability to easily get this out there.

> - is this anyway realted to 200K being mandatory for PRACK ?

No, this is unrelated.

-Jonathan R.

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 08 Mar 2000 00:00:52 -0500

[email-masked] wrote:
> 
> 1. Do we need the final 200 OK after PRACK ? 

Yes, we do. Reliability of provisional responses is end-to-end. One
consequence of this is that proxies need not know anything about
draft-ietf-sip-100rel-00.txt; thus, the proxies will treat PRACK as any
non-INVITE request and will retransmit it until they see a final
response. The 200 OK is needed to stop these retransmissions.

> holes in seq numbering, etc. Anyway, this is a subjective opinion :-)

I think that processing cumulative PRACKs should be fairly
straightforward: you just need to check the RAck value and stop
retransmitting responses whose RSeq is lower or equal to the RAck you
received. Accumulating PRACKs may be more tricky as you'd need to take
care not to linger too long as the other side might time out if it does
not see a PRACK within certain time interval. However, the draft does
not require that you do such accumulation, you just need to be prepared
to receive PRACKs accumulated by someone else.

---
Igor Slepchin

---

From: "K. K. Ramakrishnan" <[email-masked]>
Date: Wed, 8 Mar 2000 07:59:38 -0500

We had the discussion on having a 200 OK response for the
Ack. (PRACK) of a Provisional Response to an INVITE while working
on a proposal to go from a two-stage INVITE scheme to
one having a single stage INVITE, as part of the DCS effort.

One of our concerns was (upstream) messaging overhead
from the perspective of latency and bandwidth consumption.
In my mind, the PRACK is used to acknowledge a provisional
response. To then require a further acknowledgment (200 OK)
of this acknowledgment (PRACK) seemed to be excessive
overhead. Purely from the perspective of recovery from packet
loss, the reaction to the loss of the PRACK should be not
that different fromt he reaction to the loss of the provisional
response (e.g., losing the 183). We have a final response (200 OK)
for the original INVITE anyway.

In our case, the PRACK and the (hopefully unecessary) 200 OK
go end-end without going through proxies. It seemed to us
that in such a situation, having the 200 OK was even more
gratuitous because it didn't have some of the issues
about proxies keeping transaction state around.
I appreciate the issues of having to clear transactional state
at the proxies. But, one has to do that anyway with timers
if the UAS (terminal responding to the PRACK) doesn't send the
200 OK for some reason.

I also appreciate the need to not have special casing for methods -
but is this extra messaging coming about because we chose to
have the PRACK as a "method"? On the issue of backwards compatibility,
couldn't we say that proxies shouldn't be creating transaction state
for things it doesn't understand?

It'd be nice not to require the 200 OK for the PRACK...

     K. K. Ramakrishnan

-- 
K. K. Ramakrishnan                             Email:[email-masked]
AT&T Labs-Research, Rm. A155                   Tel: (973)360-8766
180 Park Ave, Florham Park, N.J. 07932         Fax: (973) 360-8050
	URL: http://www.research.att.com/info/kkrama

---

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

> for things it doesn't understand?

This proposal is itself not backwards compatible.  Also, it doesn't seem
quite right - it would mean, for example, that proxies cannot fork on
requests they do not know. This seems like a big limitation.

Anders

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Mar 2000 13:28:57 -0500

> requests they do not know. This seems like a big limitation.

I agree completely here with Anders. The spec clearly defines handling
for unknown requests as if they were BYE. 

As one of the design principles of SIP, we've really tried to make it a
fairly general purpose protocol. Many of the features and capabilities
have broad applicability and usage. Often, the result of this kind of a
decision is a tradeoff- messages are a little bigger, or more
information is sent, when its not always needed. I'd really like to keep
with that design philosophy. Having special case methods to cover every
new case, and requiring tons of Proxy-Requires to make it all work, ends
up resulting in a tangled mess of a protocol that doesn't interoperate.
Please, lets stick with the request-response model for all new methods.

-Jonathan R.