Subject: FW: [MEGACO] Overspecifying in SDP

From: Lee Newman <[email-masked]>
Date: Thu, 1 Feb 2001 14:56:30 -0500

Point of clarity.

Is this a valid SDP line for Megaco?

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

Lee

-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of Tom-PT Taylor
Sent: Thursday, January 18, 2001 6:24 PM
To: [email-masked]
Subject: FW: [MEGACO] Overspecifying in SDP

Resend

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Tuesday, January 16, 2001 5:02 PM

We actually have a bit of a problem here.  Your analysis of <fmt list> is
actually much more thorough than mine when we discussed this a year ago.
However, I intended that we be able to indicate things like ranges of ptimes
supported in replies to the MGC, but the proviso got added to the spec. that
replies to the MGC must conform to the SDP RFC.  We do have the multiple
session description mechanism available as you suggest, but obviously that
could explode exponentially if more than a couple of parameters can vary.
The moral of the story is that the MGC must be careful with the number of
CHOOSE entries it puts into a session description.

Rationally, I would expect an MG to return just a single port number to any
CHOOSE request, since this is not really a negotiable datum.

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 12:41 PM
> To: [email-masked]
> Subject: Re: [MEGACO] Overspecifying in SDP
>
>
> 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).
>
> Terry L Anderson wrote:
>
> > 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
>
> --
> ------------------------------------------------------------
> 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: Tom Taylor <[email-masked]>
Date: Thu, 1 Feb 2001 15:27:35 -0500

I believe it is.  I do wish we had specified an escape mechanism more like that
for URLs -- this one looks too C-specific.

---

From: Lee Newman <[email-masked]>
Date: Thu, 1 Feb 2001 16:45:35 -0500

Then I strongly suggest that this go into the implentor's guide.

The text of RFC 3015, section 7.1.8, should clearly point this out.  If one
were to look at Annex B, the octectStrings of the Local and Remote
descriptors are said to be described in RFC 2327.  The curly braces and
commas in the example of my previous email occur in the fmt field of the
media-field production.  RFC 2327 specifies that fmt contain only
alpha-numeric characters.

So how does one know that these {}s and commas are allowed in the fmt field?

So I guess curly braces and commas are allowed in practically every field?
So is this a valid SDP line for Megaco?

m=audio $ {AAL1/ATMF, AAL5/ATMF} 9 15

At the very least, I'd to see some explanatory text.  I think a much clearer
solution is to inidcate the fields of RFC-2327 where Megaco uses a different
definiton of.

Lee

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 3:28 PM
> To: Lee Newman
> Cc: [email-masked]
> Subject: Re: FW: [MEGACO] Overspecifying in SDP
>
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 2 Feb 2001 08:47:14 -0500

I agree that this needs work.  I've always been nervous about the details of
what we did to SDP syntax, even though I feel responsible for making it happen
in the first place.  I wonder if we should draft an I-D doing a detailed
analysis of Megacoized SDP syntax with examples.

---

From: Christian Groves <[email-masked]>
Date: Tue, 13 Feb 2001 23:02:37 +1100

Hello Lee,

What text do you propose for the implementor's guide and where?

Cheers, Christian