Subject: [Megaco] Field alternatives in SDP

From: "David Cromwell"<[email-masked]>
Date: Mon, 25 Mar 2002 17:01:35 -0500

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