Subject: Comments on draft-ietf-mmusic-sip-100rel-00

From: John Hearty <[email-masked]>
Date: Wed, 21 Apr 1999 13:26 -0500 (CDT)

I didn't know this one was already published.  It seems to do the
job nicely.  The only issue I saw was in the introduction where a 181
is referred to as a queing response.  I believe that changed to 182
in the RFC since this draft was written.  On the open issues, I feel
we should follow the KISS philosophy and answer no to each issue. 
More specifically on issue 3, I am hopeful implementors will be aware
of this I-D and avoid discarding requests with the RAck header.

 Not that I want anything changed regarding the approach used in this
I-D, but I am curious why you did not do something like the ACK request
that makes non-1xx responses to Invites reliable.  That said, I'd like
to see if we can revive any comments on this draft and move it along
to RFC status as quickly as possible.

 Nice work (as usual).

John Hearty
MCI Worldcom

Date: Mon, 19 Apr 1999 20:41 -0500 (CDT)
From: Henning Schulzrinne <[email-masked]>
Organization: Columbia University, Dept. of Computer Science
To: [email-masked]
Sender: [email-masked]
Subject: RE: Behavior of SIP Callee user agent

Tom Taylor wrote:

> What a lot of PSTN interworking problems would be solved if SIP assumed a
> reliable transport end-to-end and we could count on "100 Trying" to carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger
> ringing!

This is what the SIP extensions for reliable 1xx responses are supposed
to address (see the Internet draft on the topic). They need to be
finalized; comments are most appreciated.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Apr 1999 01:34:18 -0400

John Hearty wrote:
> in the RFC since this draft was written.

Thanks for pointing this out.

 On the open issues, I feel
> of this I-D and avoid discarding requests with the RAck header.

Since presenting it, I have discovered some additional issues, mostly
related to congestion control. We'll try to have a revised version in
before next meeting.

> to RFC status as quickly as possible.

The reason we chose not to use ACK was to maximize compatibility. In
baseline SIP, a server already must support receiving multiple
retransmissions of the same request, and retransmitting the response
when it receives each. So, adding a few sequence numbers gave us
reliability without breaking the basic model. If we used ACK to
acknowledge each provisional, and then the final, this would be a much
more major change.

>  Nice work (as usual).

Thanks!

-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: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Apr 1999 09:16:03 -0400

Jonathan Rosenberg wrote:

> acknowledge each provisional, and then the final, this would be a much

The problem is also one of ambiguity, i.e., making sure the server knows
what got acknowledged. If you are not careful, the UAC could ACK a 1xx
and the server (particularly one that doesn't support this scheme) would
believe it was the ACK for the 200 it just sent.