Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks

From: William Marshall <[email-masked]>
Date: Mon, 18 Jun 2001 14:47:26 -0400 (EDT)

The restrictive wording in bis-03 on allowable placement of
message bodies in SIP requests/responses seems to lead to a
lot of compatibility problems with other current I-Ds.

RFC2543 allows all requests and responses to contain a body.

100rel-03 specifically allows the PRACK request to contain a
body (section 6.1), and allows reliable provisional responses
to contain a body (section 6.2).

Manyfolks-resource-01 made use of these allowable combinations,
to include the UAS SDP in the first reliable provisional response
(typically a 183 if resource reservation is supported).

Unfortunately, bis-03 disallows this combination.

While I understand the desire to restrict the allowable combinations,
so as to more quickly obtain a draft standard with two interoperable
implementations of each feature, I think this creates significant
additional complexity.

An implementation of SIP that conforms to RFC2543, and implements
100rel and manyfolks,  will not conform to 2543bis-03.  The code
for 100rel and manyfolks will actually need to be removed to make
the implementation conform.  Further, it will be necessary to
re-cycle the 100rel and manyfolks I-Ds making the identical
extensions to 2543bis, once again allowing SDP to appear in these
additional requests/responses.

If 2543bis-03 was likely to become a draft standard, all this
might be worthwhile; but since it is more likely that 2543bis will
be recycled as a proposed standard, it does not seem reasonable to
require recycling all the extensions as well.  Especially since the
text changes to 2543bis-03 are so minor.

Annex B.1, which describes the "offer-answer" model, contains the
statement "The offer MAY be placed in an INVITE, in which case the
answer MUST be in a 200 class response, and the ACK MUST NOT contain
SDP."  Changing this to "... in which case the answer MUST be in
a provisional or final response, ..."

(If the PRACK were integrated into  2543bis, this could be strengthened
to say "a reliable provisional or final response"; but the "working code"
requirement will already cause this this to happen)

The second problem with the same paragraph in Annex B.1, is that
there is a case described in the manyfolks draft that requires two
offers to be sent from the UAC.  Specifically, if the UAC requires
a QoS "sendrecv" precondition,  but is only capable of ensuring "send"
(i.e. it uses RSVP), and the UAS agrees to the precondition, but is
capable of ensuring "sendrecv" itself, the UAS may respond with a 180
Ringing instead of 183 Session Progress.  The procedures in manyfolks
then allow (and possibly should require) the UAC to re-send the SDP
with the preconditions asking for a confirmation that "sendrecv" has
been obtained before starting the alerting -- otherwise the UAC does
not really know whether the preconditions were understood or not.

Both the dcs call flows (contained in draft-dcsgroup-sip-arch-04) and
the 3gpp call flows (contained in draft-drage-3gpp-sip-establish-00)
make further use of the secondary offer to perform negotiation of
codec capabilities.  A second round of offer-answer is allowed by
RFC2543, but disallowed by 2543bis-03.  Some additional allowed
combinations in B.1 could solve this problem as well.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 02:46:31 -0400

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Monday, June 18, 2001 2:47 PM
> To: [email-masked]
> Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
> 
> 

bis-03 doesn't rule this out. Where do you get the impression it does?

> Unfortunately, bis-03 disallows this combination.

Hows that? It merely states that if the INVITE contained SDP, so MUST the
200, and not the ACK. Nothing in there about PRACK or 18x. Similarly, when
INVITE doesn't have SDP, it MUST be in 200, and MUST be in ACK. Doesn't rule
out anything else.

> text changes to 2543bis-03 are so minor.

The goal is not to break those specs, I assure you. 

> a provisional or final response, ..."

Why? This would mean that you would be OK sending the answer in the
provisional, and NOT the final. I think that should be disallowed, and I
don't think any of the dcs drafts depend on that. The wording doesn't
prevent the 2xx from containing SDP, AND the 18x.

> not really know whether the preconditions were understood or not.

You lost me here. I don't follow the send/sendrecv stuff, or what this has
to do with 180 vs. 183. Not also sure how one re-sends the SDP.

> RFC2543,

Thats not clear at all. 

> but disallowed by 2543bis-03.  Some additional allowed

I am trying to avoid the preponderance of a million ways of doing things,
which has plagued other standards that shall remain nameless. 

-Jonathan R.

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

---

From: Romeo Zwart <[email-masked]>
Date: Thu, 21 Jun 2001 18:34:18 +0200

At 08:46 AM 6/21/2001, Jonathan Rosenberg wrote:
> > [...]

It's good to hear that bis-3 was not intended to ban out mechanisms
such as the manyfolks work propose. I think many people took the text
of annex B.1 to rule out SDP in 183's.

> >[...]

It is clear that 'a million ways of doing things' is not helping different
implementations to work together. From your earlier statement that sending
SDP in, e.g., 183 or PRACK is not excluded by bis03 and since sending
multiple 18x's is perfectly fine according to bis03 too, it would seem
that 'manyfolks' is not in conflict with bis03.

An additional few words in B.1. referring back to e.g. section 11.1 for
rules on (additional) SDP in 1xx responses might still be helpful to
avoid confusion.

Romeo