Subject: Re: [Sip] Comments on "unify" draft

From: William Marshall <[email-masked]>
Date: Tue, 22 Jan 2002 15:59:01 -0500 (EST)

Jonathan wrote:
> 
> In general, it would be helpful to get general feedback of the form 
> "seems like the right direction". Particularly, the main thing I need 
> feedback on ASAP is the proposal to pretty much keep this all out of 
> bis. The only thing in bis would be some generalized statement of when 
> you can see offers and answers, so that we can separate the 
> EM/manyfolks/herfp solutions from bis. Granted, this stuff still needs 
> to be on the fast track for 3g, but I want to get it separated from bis.
> 

First, I definitely agree this aspect should be decided quickly.

I may be in the minority, but I think that a problem in 2543 should
be fixed in the next version of the RFC, and that HERFP qualifies
as a bug in 2543.  It seems wrong to have a "supported:" tag defined
for a fix for a bug.

The main argument against this that I see is one of backwards
compatability.  But everyone seems to agree that a UA or proxy
written to conform to 2543 is nearly useless - so the question
seems to be one of backwards compatability to what?  Do we really
need to maintain backwards comatability to a I-D, defined as only 
a "Work in Progress"?  With the definition of Route and Record-Route
in bis, we've already given up backwards compatability with a 
pure-2543 proxy, and a fix for HERFP does not make the situation
any worse.

Second point is that 2543 already allows 1-of-N codec negotiation
through the use of a 3-way handshake (SDP in INVITE, subset in 200, 
new SDP in ACK).  So the statement that the 3-way handshake is not
backwards compatible is only with bis, not 2543, since the restriction 
to offer/answer appears only in bis.  Again this seems to be a
problem in bis, and should be fixed in bis.  Offer/Counter-Offer/Answer
is a much cleaner solution than a two-stage invite (although as an author
of the original two-stage invite proposal, draft-dcsgroup-mmusic-resource-00, 
June 1999, it is interesting that it has returned; all that is missing
is the No-Ring header in the first invite!).

The early media, and handling of multiple early media streams, and
resource reservation before alerting, all seem to be more "extensions"
than "bugs", so I'd agree with them being in separate drafts.  But if
COMET (or UPDATE) is defined in bis, these drafts would be short.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 15:34:44 -0500

> as a bug in 2543.  It seems wrong to have a "supported:" tag defined

This tag will be present irregardless of where this text lives. This is
needed to enable compatibility with existing sip implementations, most
of which follow one of the earlier bis drafts. Note that even though
100rel is folded into bis, it still requires usage of the Supported
header.

> seems to be one of backwards compatability to what? 

To existing implementations that are deployed, or are about to be
deployed and cannot be quickly changed. That is all that matters.
According to formal IETF process, we have no requirement at all for
backwards compatibility as far as I know; we are trying to maintain as
much as possible to preserve continued operation of the protocol.

> Do we really

See above, Bill. There is no UA I know of in any deployed situation that
is purely 2543 compliant, since the RR processing there was simply
underspecified. Most are following one of the earlier bis drafts.

> to offer/answer appears only in bis. 

I would argue that 2543 was simply unclear on this point entirely. It
was never my impression that it allowed it, however, I can see how one
my come to that conclusion (there is a sentence somewhere on updating
the SDP in the ACK). SDP usage in rfc2543 was vastly underpsecified,
overall. I would argue that most implementations today still only
support SDP in INVITE/200, with nothing in the ACK. A few are beginning
to support 200/ACK offer/answers.

> Again this seems to be a

Bill, these snide remarks get us nowhere. As you are well aware, the
issues with the two-stage invite in the original DCS had everything to
do with the fact that the original INVITE was answered. Furthermore,
even without answering the initial one, a two-stage INVITE is
sufficiently complex, from a dialog-maintenance point of view, that we
are not going to allow it. That is why it is INVITE followed by COMET
instead.

I would still like to know in what ways an three-way exchange is
cleaner? It is a few messages shorter, for sure. However, it cannot do
anything the two two-pass cannot do, either functionally, or in terms of
latency. However, it adds complexity, since now we have two exchange
mechanisms, and we will need to worry about how this interacts with
3pcc, how to signal which one is being used in which cases, and so on.
The proposal eliminates all of that.

As an example, with a three-pass exchange, the initial INVITE would need
to indicate whether a counter-offer was expected, or just an answer.
That requires a REquire header. Then, the UA will need to fall back to a
regular offer/answer in the case it fails. The 200 OK, of course, would
need an indicator somewhere about whether its an answer or
counter-offer. If itsa  counter-offer, we need to now specify procedures
for error handling if the answer doesn't come in ACK, and so on. 

> than "bugs", so I'd agree with them being in separate drafts.

The line is fine indeed. I think a convincing argument could be made for
it on either side. However, the argument is really philosophical in
nature, and I am more concerned with practical issues right now.

> But if

My main concern, and I am surprised its not yours as well, is timely
completion of bis for 3gpp. To do that, we require parallelism. I would
very much like to last call bis-06 as issued, and we could do that
shortly if this stuff stays out. In parallel with the last call period,
and iesg review, we can refine UPDATE/COMET, as this will take some
time.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Alan Johnston <[email-masked]>
Date: Fri, 25 Jan 2002 12:48:15 -0600

Bill,

See my comments below.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of William Marshall
> Sent: Tuesday, January 22, 2002 2:59 PM
> To: [email-masked]
> Subject: Re: [Sip] Comments on "unify" draft
> 
> 
> Jonathan wrote:
> > 

Some of us do have commercial SIP products and they do work with RFC
2543 devices.  This is also probably true for most of the SIP service
providers listed on Henning's page.

HERFP is a nice thing for a fix, but it is should not be classified as a
bug.

> to offer/answer appears only in bis.  

This is not correct - there have never been any working group documents
on base SIP (not extension) that show this incorrect behavior.
Interworkable SIP is shown in the call flows and by testing at SIPit.
This three way handshake is wrong.

Again this seems to be a
> COMET (or UPDATE) is defined in bis, these drafts would be short.

By the way, I support the direction of the unify draft, although I need
to think more call flows before I come to a conclusion.  It is
definitely better than the present COMET method as outlined in
manyfolks.