Subject: RE: [Megaco] Field alternatives in SDP

From: "David Cromwell"<[email-masked]>
Date: Tue, 26 Mar 2002 10:49:56 -0500

I can't see how you could not have problems if alternatives are allowed for
any field in the SDP syntax.  To give a specific example, if you allowed
more than one port ( 1*(DIGIT) )in the media line, how would a parser
distinguish between the last port and the first media format (
1*(alpha-numeric) ) if the first format was numeric only?  You'd have to add
some syntax to group alternatives.  If we keep this language in, I'd like to
see a complete ABNF for SDP in the H.248 spec which reflects the possibility
of alternatives in each field. 

Regards,
David
--
[email-masked]                   Nortel Networks Cable
Telephony Solutions, Inc. 
Tel:   919-991-8870  (esn 351)                     35 Davis Dr
Fax:  919-991-4088                                    RTP, NC 27709

> -----Original Message-----
> From:	Terry L Anderson [SMTP:[email-masked]]
> Sent:	Tuesday, March 26, 2002 9:39 AM
> To:	Cromwell, David [NCRTP:3S12:EXCH]
> Cc:	Taylor, Tom-PT [CAR:B800:EXCH]; 'Carl Rutter'; [email-masked]
> Subject:	Re: [Megaco] Field alternatives in SDP
> 
> I am not sure I see an argument for adding a restriction.  An informative
> note
> that this was intended primarily for attributes might be helpful, but a
> normative restriction is a syntax change and I'd like to see where there
> is a
> problem before doing that.
> 
> Any MGC that does not want alternatives elsewhere simply doesn't add them.
> Any
> MG that cannot handle more than one value when receiving a request with
> ReserveValue simply picks one.  I cannot see how allowing alternatives in
> other
> places in the syntax can ever cause a problem even if unuseful, so why
> change?
> 
> David Cromwell wrote:
> 
> > Restricting the syntax exception to attribute lines sounds good to me.
> >
> > David
> > --
> > [email-masked]                   Nortel Networks Cable
> > Telephony Solutions, Inc.
> > Tel:   919-991-8870  (esn 351)                     35 Davis Dr
> > Fax:  919-991-4088                                    RTP, NC 27709
> >
> > > -----Original Message-----
> > > From: Taylor, Tom-PT [CAR:B800:EXCH]
> > > Sent: Monday, March 25, 2002 8:11 PM
> > > To:   Cromwell, David [NCRTP:3S12:EXCH]; 'Carl Rutter';
> [email-masked]
> > > Subject:      RE: [Megaco] Field alternatives in SDP
> > >
> > >
> > > This question has been asked in the past, but we never produced an
> answer.
> > > I think, since we are deviating from the SDP specification in this
> area,
> > > that we are going to have to come up with our own answers.  I would
> > > propose that we restrict the exceptional syntax to attributes (a=
> lines).
> > > That's certainly the sort of thing I had in mind when I contributed to
> the
> > > design in this area.
> > >
> > > Another grey area here is whether this sort of thing is allowed in the
> > > MG->MGC direction, or only in the MGC->MG direction.
> > >
> > > -----Original Message-----
> > > From: Cromwell, David [NCRTP:3S12:EXCH]
> > > Sent: Monday, March 25, 2002 6:06 PM
> > > To: 'Carl Rutter'; [email-masked]
> > > Subject: RE: [Megaco] Field alternatives in SDP
> > >
> > >
> > > The spec says the use of alternatives in place of a single parameter
> value
> > > is an exception to the syntax described in RFC 2327.  I'm trying to
> find
> > > out if this exception applies to all fields in all SDP lines, and, in
> > > those cases where it does apply, what is the syntax used, i.e. how are
> the
> > > alternatives encoded?
> > > Regards,
> > > David
> > > --
> > > [email-masked]                   Nortel Networks Cable
> > > Telephony Solutions, Inc.
> > > Tel:   919-991-8870  (esn 351)                     35 Davis Dr
> > > Fax:  919-991-4088                                    RTP, NC 27709
> > >
> > >
> > >
> > > -----Original Message-----
> > > From:   Carl Rutter [SMTP:[email-masked]]
> > > Sent:   Monday, March 25, 2002 5:52 PM
> > > To:     Cromwell, David [NCRTP:3S12:EXCH]; Carl Rutter;
> [email-masked]
> > > Subject:        RE: [Megaco] Field alternatives in SDP
> > > I haven't seen an application for it but maybe others have??
> > >
> > >
> > > Carl
> > >
> > > -----Original Message-----
> > > From: David Cromwell [mailto:[email-masked]]
> > > Sent: Monday, March 25, 2002 5:47 PM
> > > To: 'Carl Rutter'; [email-masked]
> > > Subject: RE: [Megaco] Field alternatives in SDP
> > >
> > >
> > > Carl,
> > >
> > > That makes sense with respect to the format list, which by the way is
> > > already defined in the SDP syntax, but does it make sense with respect
> to
> > > other fields?
> > > Regards,
> > > David
> > > --
> > > [email-masked]                   Nortel Networks Cable
> > > Telephony Solutions, Inc.
> > > Tel:   919-991-8870  (esn 351)                     35 Davis Dr
> > > Fax:  919-991-4088                                    RTP, NC 27709
> > >
> > >
> > >
> > > -----Original Message-----
> > > From:   Carl Rutter [SMTP:[email-masked]]
> > > Sent:   Monday, March 25, 2002 5:38 PM
> > > To:     Cromwell, David [NCRTP:3S12:EXCH]; [email-masked]
> > > Subject:        RE: [Megaco] Field alternatives in SDP
> > > In regards to the SDP parameters you could for example
> > > over specify the codecs
> > > ie)
> > > m=audio $ RTP/AVP 0 2 15
> > > Carl
> > > -----Original Message-----
> > > From: David Cromwell [ <mailto:[email-masked]>]
> > > Sent: Monday, March 25, 2002 5:02 PM
> > > To: [email-masked]
> > > Subject: [Megaco] Field alternatives in SDP
> > >
> > >
> > > I'd appreciate it if someone could clarify the following text from RFC
> > > 3105, Section 7.1.8, Local and Remote Descriptors:
> > > When text encoding the protocol, the descriptors consist of session
> > >    descriptions as defined in SDP (RFC2327).  In session descriptions
> > >    sent from the MGC to the MG, the following exceptions to the syntax
> > >    of RFC 2327 are allowed:
> > >    *  the "s=", "t=" and "o=" lines are optional,
> > >    *  the use of CHOOSE is allowed in place of a single parameter
> value,
> > >       and
> > >    *  the use of alternatives is allowed in place of a single
> parameter
> > >       value.
> > > Specifically, "the use of alternatives is allowed in place of a single
> > > parameter value" seems a bit wide ranging.  Is this saying that, for
> > > instance, the media field of the media line could contain
> alternatives?
> > > Let's say you want to use "image", "audio", and "video" as
> alternatives.
> > > How would you encode this. i.e. what syntax would be used.  How about
> the
> > > network type in the connection line.  Is it permissible to use "IN"
> and
> > > "ATM" as alternatives in a single connection line?
> > >
> > >
> > > Later on in the same section:
> > >    Either the local or the remote descriptor or both may be
> > >    *  unspecified (i.e., absent),
> > >    *  empty,
> > >    *  underspecified through use of CHOOSE in a property value,
> > >    *  fully specified, or
> > >    *  overspecified through presentation of multiple groups of
> > >       properties and possibly multiple property values in one or more
> of
> > >       these groups.
> > > With respect to the phrase "multiple groups of properties and possibly
> > > multiple property values in one or more of these groups",  is this
> talking
> > > about multiple session descriptions and with a session description,
> > > multiple media descriptions?  If so, maybe the language could be
> changed
> > > in a future version of the protocol to be more explicit.
> > > Regards,
> > > David
> > > --
> > > [email-masked]                   Nortel Networks Cable
> > > Telephony Solutions, Inc.
> > > Tel:   919-991-8870  (esn 351)                     35 Davis Dr
> > > Fax:  919-991-4088                                    RTP, NC 27709
> > >
> > >
> > >
> > > -----Original Message-----
> > > From:   [email-masked] [SMTP:[email-masked]]
> > > Sent:   Monday, March 25, 2002 8:17 AM
> > > Cc:     [email-masked]
> > > Subject:        [Megaco] I-D ACTION:draft-ietf-megaco-callflows-00.txt
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > This draft is a work item of the Media Gateway Control Working Group
> of
> > > the IETF.
> > >         Title           : Megaco/H.248 Call flow examples
> > >         Author(s)       : M. Brahmanapally, P. Viswanadham, K.
> Gundamaraju
> > >         Filename        : draft-ietf-megaco-callflows-00.txt
> > >         Pages           : 270
> > >         Date            : 20-Mar-02
> > >
> > > This draft illustrates the usage of Megaco (version 1)
> > > protocol defined between the Media Gateway Controller and Media
> > > Gateway. In light of the vast features presently incorporated
> > > and continuously evolving features of the protocol, it serves the
> > > purpose of representing typical use case scenarios.
> > > A URL for this Internet-Draft is:
> > > <
> > >
> <http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt>>
> > > To remove yourself from the IETF Announcement list, send a message to
> > > ietf-announce-request with the word unsubscribe in the body of the
> > > message.
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > >         "get draft-ietf-megaco-callflows-00.txt".
> > > A list of Internet-Drafts directories can be found in
> > > < <http://www.ietf.org/shadow.html>>
> > > or < <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > > Send a message to:
> > >         [email-masked].
> > > In the body type:
> > >         "FILE /internet-drafts/draft-ietf-megaco-callflows-00.txt".
> > >
> > > NOTE:   The mail server at ietf.org can return the document in
> > >         MIME-encoded form by using the "mpack" utility.  To use this
> > >         feature, insert the command "ENCODING mime" before the "FILE"
> > >         command.  To decode the response(s), you will need "munpack"
> or
> > >         a MIME-compliant mail reader.  Different MIME-compliant mail
> > > readers
> > >         exhibit different behavior, especially when dealing with
> > >         "multipart" MIME messages (i.e. documents which have been
> split
> > >         up into multiple messages), so check your local documentation
> on
> > >         how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft. << Message:  >>
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> 
> --
> -------------------------------------------------------
> Terry L Anderson, DMTS                   [email-masked]
> Lucent Technologies /INS/ Voice over IP Access Networks
> Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
> http://its.lucent.com/~tla  (Lucent internal)
> http://www.gti.net/tla
> -------------------------------------------------------
>  << File: Card for Terry L Anderson >>

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 26 Mar 2002 11:50:49 -0500

There is no parsing problem.  The syntax for alternativeValue is
presumed to be used here (even though it is somewhat unnatural for
SDP).  Thus things like:
m=audio 1234 RTP/AVP { 4, 4 0, 0 \}
or
m=audio $ {AAL1/ATMF, AAL5/ATMF} 9 15

Note that alternative values of payload "{4, 0 \}" mean something
different than the space separated list allowed in SDP.
"4 0" means that the payloads of type 4 and of type 0 can be mixed
freely with 4 preferred.
"{ 4, 0 \} means that 4 and 0 are alternatives and if reserveValue is
false, the recipient must choose one and only one for the response.
That is why it makes sense to send
{ 4, 4 0, 0 \} which means that the recipient might choose "4" or "4 0"
or "0".

Of course, some of this same flexibility can be done by using
alternative groups rather than alternative values and the use of groups
allows coupling between a choice in one list with that in another.
However, the use of groups can lead to a very large number of groups
where there are several places to make a choice.

This was discussed on the list between jan 3-feb 13, 2001.  There seemed
to be agreement that this syntax was the intention but also several were
uncomfortable with it and wanted it formally specified in ABNF (or
changed).  However, no one ever proposed a solution.  The thread ran
out.

I guess the question is how widely is the alternativeValue production
currently supported?

The alternatives are:
1) define formally the syntax allowing the use of the current
alternativeValue production
2) define some more "SDP-like" form of alternative value in ABNF (and
deprecate the use of alternativeValue production) (in the previous
discussion some objected that the alternativeValue production introduced
new symbols not previously allowed in SDP).
3) restrict the use of alternative values to a few specific locations in
the SDP and maintain the alternativeValue production
4) restrict the use of alternative values to a few specific locations in
the SDP and use a new more SDP-like syntax.

Understand that anything other than #1 may break current
implementations.

David Cromwell wrote:

>
>
> I can't see how you could not have problems if alternatives are
> allowed for any field in the SDP syntax.  To give a specific example,
> if you allowed more than one port ( 1*(DIGIT) )in the media line, how
> would a parser distinguish between the last port and the first media
> format ( 1*(alpha-numeric) ) if the first format was numeric only?
> You'd have to add some syntax to group alternatives.  If we keep this
> language in, I'd like to see a complete ABNF for SDP in the H.248 spec
> which reflects the possibility of alternatives in each field.
>
> Regards,
> David
> --
>      I am not sure I see an argument for adding a restriction.  An
>      informative note
>      normative restriction is a syntax change and I'd like to see
>      where there is a
>      Any MGC that does not want alternatives elsewhere simply doesn't
>      add them.  Any
>      ReserveValue simply picks one.  I cannot see how allowing
>      alternatives in other
>      places in the syntax can ever cause a problem even if unuseful,
>      so why change?
>
>      David Cromwell wrote:
>
>      > > This question has been asked in the past, but we never
>      produced an answer.
>      > > I think, since we are deviating from the SDP specification in
>      this area,
>      > > propose that we restrict the exceptional syntax to attributes
>      (a= lines).
>      > > That's certainly the sort of thing I had in mind when I
>      contributed to the
>      > > design in this area.
>      > >
>      > > The spec says the use of alternatives in place of a single
>      parameter value
>      > > is an exception to the syntax described in RFC 2327.  I'm
>      trying to find
>      > > those cases where it does apply, what is the syntax used,
>      i.e. how are the
>      > > alternatives encoded?
>      > > Regards,
>      > > David
>      > > --
>      > > already defined in the SDP syntax, but does it make sense
>      with respect to
>      > > other fields?
>      > > Regards,
>      > > David
>      > > --
>      > >    *  the use of CHOOSE is allowed in place of a single
>      parameter value,
>      > >       and
>      > > How would you encode this. i.e. what syntax would be used.
>      How about the
>      > > network type in the connection line.  Is it permissible to
>      use "IN" and
>      > >       properties and possibly multiple property values in one
>      or more of
>      > >       these groups.
>      > > multiple property values in one or more of these groups",  is
>      this talking
>      > > multiple media descriptions?  If so, maybe the language could
>      be changed
>      > > Subject:        [Megaco] I-D
>      ACTION:draft-ietf-megaco-callflows-00.txt
>      > > This draft is a work item of the Media Gateway Control
>      Working Group of
>      > > the IETF.
>      > >         Author(s)       : M. Brahmanapally, P. Viswanadham,
>      K. Gundamaraju
>      > >         "FILE
>      /internet-drafts/draft-ietf-megaco-callflows-00.txt".
>      > >
>      > >         command.  To decode the response(s), you will need
>      "munpack" or
>      > >         "multipart" MIME messages (i.e. documents which have
>      been split
>      > >         up into multiple messages), so check your local
>      documentation on
--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 26 Mar 2002 11:50:49 -0500

The alternatives are:

--

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Mar 2002 19:17:07 +0200

Hi,

I have to admit that I didn't follow the earlier thread, but I really think doing
what you propose is taking a dangerous path...

SDP is what it is, and if it doesn't give you what you want you should choose
another protocol. Yes, the ReserveXxx values, and the possibility to include
multiple SDP within a single descriptors, give us some extended options, but the
syntax of the SDP itself still more or less remains the same. It is true that if you
have lots of options you may get a pretty long list of SDPs. Also, if you are
including multiple SDPs, using the format you propose in each, you are going to get
more possible options that the current ReserveXxx values can "handle"....

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Mar 2002 19:17:07 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Troy Cauble <[email-masked]>
Date: Tue, 26 Mar 2002 12:10:30 -0500

YES!

> any field in the SDP syntax.  To give a specific example, if you allowed more
> than one port ( 1*(DIGIT) )in the media line, how would a parser distinguish
> between the last port and the first media format ( 1*(alpha-numeric) ) if the
> first format was numeric only?  You'd have to add some syntax to group
> alternatives.  If we keep this language in, I'd like to see a complete ABNF
> for SDP in the H.248 spec which reflects the possibility of alternatives in
> each field.
> 
> Regards,
> David
> --
> [email-masked]                   Nortel Networks Cable Telephony
> Solutions, Inc.
>      Any MGC that does not want alternatives elsewhere simply doesn't add
>      them.  Any
>      ReserveValue simply picks one.  I cannot see how allowing alternatives
>      in other

---

From: Troy Cauble <[email-masked]>
Date: Tue, 26 Mar 2002 12:10:30 -0500

YES!