Subject: Overspecifying in SDP

From: Terry L Anderson <[email-masked]>
Date: Wed, 3 Jan 2001 13:27:24 -0500

I want to confirm the proper interpretation of payload-type lists in SDP
in H.248.  I am afraid that my H.323-centric past has lead me to
misinterpret this case but I want to confirm my new understanding.

The third bullet in 7.1.8 dealing with exceptions to RFC 2327 states
that "use of alternatives is allowed in place of a single parameter
value".  The recipient's behavior for such overspecified parameters
depends on the setting of ReserveGroup/ReserveValue.

The question is whether a comma separated list of payloads in the "m="
line is a case of this.  My H.323-centric mind thought it WAS but now I
realise that this is NOT an exception to RFC 2327 which permits a list
of payloads here, but they are not alternatives in the H.248 sense.  SIP
and (I believe) H.248 permit multiple payload types to be used in a
single media stream (while H.323 prohibits this, hence my confusion).
So I believe that

m=audio 1234 RTP/AVP 4,0

offers a single choice of stream that will mix the use payload types 4
and 0 and that this is NOT overspecification and that even with
"ReserveValue = no" the MG should accept the m line as shown and NOT
return a single payload type in its reply.

Is this correct?  This would imply that the only way to offer
alternative payload types and force the MG to choose one would be to use
multiple groups of session descriptions and set ReserveGroup = no.

A related question (which I asked previously be got no response), what
are the allowed responses to CHOOSE as a payload type.  That is, given a
request with Local,

v=0
c=IN IP4 $
m=audio $ RTP/AVP $

with ReserveGroup = yes

Is it permitted to return more than one group to indicate the acceptable
payload types?  (since I now believe that I cannot return a
comma-separated list in a single group to imply alternatives).  That is,
can the MG reply

v=0
c=IN IP4 111.111.111.111
m=audio 1234 RTP/AVP 4
v=0
c=IN IP4 111.111.111.111
m=audio 1234 RTP/AVP 0

--
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   [email-masked]
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Troy Cauble <[email-masked]>
Date: Wed, 3 Jan 2001 16:58:08 -0500

> single media stream (while H.323 prohibits this, hence my confusion).

Yet another underspecified part of the H.248 spec.
No where does it say HOW to encode alternatives
within an SDP line. ("comma-delimeted"?)

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 5 Jan 2001 12:40:54 -0500

I apologize for not reading the SDP RFC carefully enough.  The <fmt list>
there is NOT comma-separated but rather space-separated and so there is no
conflict with H.248 alternative lists.  I assume then that the proper syntax
allows

    m=audio 1234 RTP/AVP { 4, 4 0, 0 \}

to allow alternates any of which could be an <fmt list>  (I also omitted the
brackets in my mail below).  This allows alternate codecs without requiring
multiple groups counter to what I asserted below.  I agree with a comment
made several weeks ago that we really need a precise ABNF for the H.248
permitted extensions to RFC 2327 to remove ambiguities.

I also assume from 7.1.8(d) that a request with CHOOSE and ReserveValues can
return a list so a request of
    m=audio $ RTP/AVP $
could get a reply with the list above.

This still leaves my question about whether it is allowed to reply to the
CHOOSE above with multiple groups to specify different ports or different
ptime's (if this had also been CHOOSE or a list).