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

From: William Marshall <[email-masked]>
Date: Fri, 22 Jun 2001 15:32:18 -0400 (EDT)

At 08:46 AM 6/21/2001, Jonathan Rosenberg wrote:
> > -----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
> >
> > 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.
> > [...]
> > 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.
>
>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.

The problem of the UA receiving multiple SDPs from the other end was the
basic reason for the re-writing of the Annex on SDP usage.  Otherwise,
the simple rule of using the last one received (the RFC2543 way) would
work just fine, and there would be no reason to restrict the places
SDP may appear.

So if 2543bis says SDP MUST appear in the 200OK, and manyfolks says
SDP MUST appear in the 183, then the UAC MUST deal with multiple SDPs.
Therefore it MUST deal with differences between them.  How?  By ignoring
the second SDP?  Then why was it sent?  By ignoring the first?  Then
I know of several QoS architectures that will not work.

The basic principle I recall from the Minneapolis IETF was that the
UA should not be forced to deal with these complexities; thus the
simplification of only one SDP sent in each direction.  This
simplification can be maintained in almost all cases, by simply
allowing the SDP response to appear in a provisional response instead
of the final response.  The second round offer, if needed, can  be
restricted to a subset of the initial offer in order to keep the
processing simple.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  http://www.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