Subject: RE: [Megaco] Field alternatives in SDP

From: "David Cromwell"<[email-masked]>
Date: Mon, 25 Mar 2002 22:32:02 -0500

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

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 26 Mar 2002 09:38:32 -0500

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?

--
-------------------------------------------------------
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
-------------------------------------------------------

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 26 Mar 2002 09:38:32 -0500