Subject: RE: [Megaco] Field alternatives in SDP

From: Dan Elbert <[email-masked]>
Date: Tue, 26 Mar 2002 16:46:48 +0200

Any change in the SDP syntax can cause parsing problems so it should be
clearly defined, preferible by given the changes in the ABNF .
A parser may not "just ignore" the additional alternatives, it may just
fail.

Dan Elbert
RADVISION

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 4:39 PM
To: David Cromwell
Cc: Tom-PT Taylor; '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
-------------------------------------------------------

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

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

Hi,

My understanding of the ReserveValue for SDP was that the "multiple values" refers
the codecs, NOT media types etc. Ie one may send a list of codec alternatives (a
list of codecs), which IS allowed according to the ABNF.

Regards,

Christer Holmberg
Ericsson Finland

Terry L Anderson wrote:

> I never said "ignore".  Of course the parser must parse the full syntax, but
> there is no requirement to implement the use of multiple values (ReserveValue).
> I assume that a v1 parser handles the current syntax which allows alternative
> values and we are discussing whether they are useful or should be removed.
>
> Are you asking that the ABNF be given explicitly rather than the current loose
> language stating exceptions to the SDP RFC?  I agree that might be useful.  But
> I do not see how removing the alternatives from places they are now allowed
> helps, unless a current parser choose not to implement them or you are arguing
> that they introduce parsing ambiguities.
>
> Dan Elbert wrote:
>
> ------------------------------------------------------------
> 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:12:21 -0500

--

---

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

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

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

--