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

From: William Marshall <[email-masked]>
Date: Fri, 25 Jan 2002 09:30:16 -0500 (EST)

Jonathan wrote, in part:
> > Offer/Counter-Offer/Answer is a much cleaner solution than a 
> > two-stage invite.
> 
> 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.

I agree that a pair of two-way exchanges can do everything that a
three-way exchange can do, plus more.  My comment above was that
the three-way exchange was better than the two-stage invite, and I
doubt there is any disagreement on that point.

One way in which the pair of two-way exchanges is significantly better
is that, in the 3-way exchange, the (UAS) response/counter-offer would 
need to assign ports for all supported media streams, and just hope
that the UAC would not use most of them.  It is much better that the
fourth SDP (the second answer) give only ports for the media that will
be used.

Jonathan also wrote:
> 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.

Agree completely with the goal, and the concern.  But I guess I am less
convinced that we can get three new I-Ds (one defining COMET/UPDATE, second
for manyfolks, third for codec negotiation) through to RFCs in almost zero 
time.  Past experience (which I know does not indicate future results) 
is 30+ months.  From a 3GPP view, is it better to have bis and not the 
other three?  Or all combined, but one or two months later?  From what
I recall of TS24.228, the unify draft is already wrecking major havoc.

Could someone (Rakesh?) try posting a reasonable schedule that meets 
the needed deadlines?

Bill Marshall
[email-masked]

-----original message-----
Date: Thu, 24 Jan 2002 15:34:44 -0500
From: Jonathan Rosenberg <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sip] Comments on "unify" draft

William Marshall wrote:
> 
> 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.

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.

> 
> 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? 

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
> 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.

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.

> 
> 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. 

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
> 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!).

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. 

> 
> 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.

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
> COMET (or UPDATE) is defined in bis, these drafts would be short.

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

_______________________________________________
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: Wed, 30 Jan 2002 12:14:06 -0500

> doubt there is any disagreement on that point.

OK.

> that the UAC would not use most of them. 

I don't get it. If the UAS doesn't want a stream, then in either model
it can be rejected in the first UAS->UAC message.

> I recall of TS24.228, the unify draft is already wrecking major havoc.

This is a process issue which most definitely needs to be answered. I
remain unclear on the schedule and constraints for the non-bis documents
needed by 3g, including manyfolks, privacy, media-auth, sip-events,
refer, replaces, and so on.

It was my proposal to turn manyfolks into the new-COMET definition + the
manyfolks usage, which would avoid another document. Since it already
defines COMET + the manyfolks usage, its reasonably within the scope of
the document. However, I concur that this is not a minor change and will
take hard work to get it done for 3g timelines.

-Jonathan R.