Subject: Re: Setting SDP values for Unicast

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Apr 2000 17:18:37 -0400

Nicolas Quartier wrote:
> 
> Dear Mr. Schulzrinne,
> 
> I think I found an inconsistency between RFC2543(SIP) and RFC2327
> (SDP).
> Section B2 of RFC2543 deals with the setting of SDP values for Unicast
> and there it
> is mentioned that:
> 
> If caller and callee have no media formats in common for a particular
> stream, the callee MUST return a session description containing the
> particular "m=" line, but with the port number set to zero, and no
> payload types listed.
> 
> But according to RFC2327, at least 1 payload type should be present
> in the "m=" line.

This should probably be brought to the attention of the SDP authors, to
be either fixed in the next version or otherwise resolved. Thanks.

> Kind regards,
> Nicolas Quartier.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Mark Handley <[email-masked]>
Date: Sun, 16 Apr 2000 15:04:03 -0700

>be either fixed in the next version or otherwise resolved. Thanks.

Actually this sounds more like an SIP spec bug in its usage of SDP
than an SDP spec bug.  This usage is pushing the envelope of the
semantics of what SDP was defined for, but even so, the SIP spec
should not have stepped outside of valid SDP syntax.  A simple
solution would be to define in the SIP spec that in this context "-"
as a format means no formats in common.

Thanks to Nicholas for pointing this out - we definitely need to
decide on a single solution for this before we take SDP and SIP to
draft standard.

Cheers,	
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Apr 2000 08:00:35 -0400

Mark Handley wrote:

> decide on a single solution for this before we take SDP and SIP to

While this wasn't intentional, my general feeling is that any set should
always allow the empty set, as that's far more logical than defining a
specific symbol for the the empty set, from a special-case perspective.
After all, any robust implementation will need to deal with accidental
cases of this nature in any event. Thus, I would strongly favor allowing
empty sets anywhere where that's possible without causing confusion.