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

---

From: Carl Rutter <[email-masked]>
Date: Mon, 25 Mar 2002 17:37:44 -0500

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

	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. 

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

Regards, 
David 

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

	A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt
<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. 

	A list of Internet-Drafts directories can be found in 
http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>  

	Send a message to: 
        [email-masked]. 
In the body type:

---

From: Carl Rutter <[email-masked]>
Date: Mon, 25 Mar 2002 17:37:44 -0500

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

Regards, 
David 

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

        

	Send a message to: 
        [email-masked]. 
In the body type:

---

From: Carl Rutter <[email-masked]>
Date: Mon, 25 Mar 2002 17:52:09 -0500

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 

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

	m=audio $ RTP/AVP 0 2 15 

	Carl 

	-----Original Message-----
From: David Cromwell [ mailto:[email-masked]
<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:

	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?  

	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

	-----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 URL for this Internet-Draft is:
< http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt> > 

	A list of Internet-Drafts directories can be found in
< http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html> >
or < ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt> > 

	Send a message to:
        [email-masked].
In the body type:

---

From: Carl Rutter <[email-masked]>
Date: Mon, 25 Mar 2002 17:52:09 -0500

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, 

Regards, 
David 

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

	m=audio $ RTP/AVP 0 2 15 

	Carl 

	-----Original Message-----

	Regards,
David

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

       

	Send a message to:
        [email-masked].
In the body type:

---

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

Carl,

Regards,
David

> 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 
> -- 
> 	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. 
> 
> 	<http://www.ietf.org/shadow.html> 
> 	or <ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 
> 
>

---

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

Carl,

Regards,
David

---

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

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

> Sent:	Monday, March 25, 2002 5:52 PM
> To:	Cromwell, David [NCRTP:3S12:EXCH]; Carl Rutter; [email-masked]
> 	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 
> 	-- 
> 		From: David Cromwell [ <mailto:[email-masked]>]
> 		I'd appreciate it if someone could clarify the following
> text from RFC 3105, Section 7.1.8, Local and Remote Descriptors:
> 
> 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?  
> 
> 
> 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
> 	--
> 		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. 
> 
> 		<
> <http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt>> 
> 
> 		Internet-Drafts are also available by anonymous FTP. Login
> with the username
> 		< <http://www.ietf.org/shadow.html>>
> 		or < <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>> 
> 
> 
> 		        "FILE
> /internet-drafts/draft-ietf-megaco-callflows-00.txt".
>

---

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

Regards,
David

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 25 Mar 2002 20:20:46 -0500

Examples of the sorts of things I had in mind when we designed this:
 -- range of allowed packetization intervals
 -- alternative video resolutions
 -- all sorts of other video parameters

-----Original Message-----
From: Carl Rutter [mailto:[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

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, 

-----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 
       
Internet-Drafts are also available by anonymous FTP. Login with the username

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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 25 Mar 2002 20:20:46 -0500

-----Original Message-----
From: Carl Rutter [mailto:[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

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,

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 25 Mar 2002 20:10:44 -0500

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

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,

-----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 
       
< <http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt>>

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 25 Mar 2002 20:10:44 -0500

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

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,

---

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

> 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]
> 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.
> 
> 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 
> -- 
> I'd appreciate it if someone could clarify the following text from RFC
> 3105, Section 7.1.8, Local and Remote Descriptors:

---

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?

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

> 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]
> normative restriction is a syntax change and I'd like to see where there
> is a
>  << File: Card for Terry L Anderson >>

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 26 Mar 2002 10:07:09 -0500

The problem comes with an example like the one suggested earlier in this
discussion, where multiple media types are offered in the same the m= line.
The fact is that the different components of the m= line are interdependent,
so if you offer the choice of audio, video, or text as the medium you also
have to offer different choices for your media formats and sometimes for
your transport.  I agree that it is always possible to return some error
code meaning "You've said something stupid", but it would be safer to simply
restrict use of alternatives to areas where they have a chance to be
understood.

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 26 Mar 2002 10:07:09 -0500

---

From: Dan Elbert <[email-masked]>
Date: Tue, 26 Mar 2002 18:00:38 +0200

I agree
 
Dan Elbert
RADVISION

-----Original Message-----
From: David Cromwell [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 5:50 PM
To: 'Terry L Anderson'
Cc: Tom-PT Taylor; 'Carl Rutter'; [email-masked]
Subject: RE: [Megaco] Field alternatives in SDP

Regards, 
David 

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

> > From: David Cromwell [ < mailto:[email-masked]
<mailto:[email-masked]> >] 

> > in a future version of the protocol to be more explicit. 
<http://www.ietf.org/internet-drafts/draft-ietf-megaco-callflows-00.txt> >> 
> > < < http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html> >>

> > or < < ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt> >> 

> > Internet-Draft. << Message:  >> 
<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 <http://its.lucent.com/~tla>   (Lucent internal) 
http://www.gti.net/tla <http://www.gti.net/tla>  
------------------------------------------------------- 
 << File: Card for Terry L Anderson >>

---

From: Dan Elbert <[email-masked]>
Date: Tue, 26 Mar 2002 18:00:38 +0200

I agree
 
Dan Elbert
RADVISION

-----Original Message-----
From: David Cromwell [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 5:50 PM
To: 'Terry L Anderson'
Cc: Tom-PT Taylor; 'Carl Rutter'; [email-masked]
Subject: RE: [Megaco] Field alternatives in SDP

Regards, 
David

---

From: Dan Elbert <[email-masked]>
Date: Tue, 26 Mar 2002 18:59:49 +0200

If the same effect can be achieved in a different way, I don't see sense in
breaking the SDP syntax.
If breaking the syntax is required, the ABNF should be specified.
We haven't seen the need to support this yet.

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 6:51 PM
To: David Cromwell
Cc: Tom-PT Taylor; 'Carl Rutter'; [email-masked]
Subject: Re: [Megaco] Field alternatives in SDP

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
> --
>      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:
>
>      possibly
>      with the
>      > >         a MIME-compliant mail reader.  Different
>      MIME-compliant mail
>      > > readers
--

------------------------------------------------------------
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: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:08:57 -0500

> Comments below.
> Sent:	Tuesday, March 26, 2002 11:51 AM
> There is no parsing problem.  
> 
> [<dcc>]  Now that I understand there is a defined syntax I agree.
> 
> The syntax for alternativeValue is
> [<dcc>]  It seems to me then that the base technical issue is whether to
> have larger SDPs with standard syntax or more compact SDPs with
> non-standard (with respect to RFC 2327)  syntax.  Are there any cases
> where semantic information will be lost by encoding in standard SDP?
> 
> [<dcc>]  I would be interested as well.  Was this syntax ever used during
> the megaco interop bakeoffs?  If the syntax is not widely supported then
> lots of people will have to upgrade their SDP parsers to avoid interop
> problems.  
> 
> The alternatives are:
> [<dcc>]  I'd add alternative # 5 which would be to disallow the
> alternativeValue syntax in SDP.
> 
> [<dcc>]  Anything other than # 5 will break networks that include MGCP and
> H.248 gateways.  That is unless the MGC is prepared to do some potentially
> complex transcoding of SDP encoded using the alternativeValue rule to
> standard SDP.
> 
> [<dcc>]  Regardless of the outcome of this discussion I would like to at
> least see a well specified definition of SDP syntax as used in H.248. 
>

---

From: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:12:55 -0500

This time without the unwanted ">"s.

> Sent:	Wednesday, March 27, 2002 4:07 PM
> To:	'Terry L Anderson'
> Cc:	Taylor, Tom-PT [CAR:B800:EXCH]; 'Carl Rutter'; [email-masked]'
> Terry,
> 	Thanks for the syntax example.  It was not clear that "alternatives"
> means the alternativeValue rule in the ABNF.  The relevant text in section
> 7.1.8 reads:
> 
> 	I may have missed something elsewhere in the v1 spec or the IG, but
> I interpret this as referring to some vague, unspecified method of
> encoding alternatives.  The statement would be clearer if it were
> reworded:
> 
> 	* the use of the H.248 alternativeValue syntax is allowed in place
> of any single SDP parameter value. 
> 
> Regards,
> David
> --

---

From: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:12:55 -0500

---

From: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:13:55 -0500

Again, without the unwanted ">"s.

> Sent:	Wednesday, March 27, 2002 4:09 PM
> To:	'Terry L Anderson'

---

From: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:13:55 -0500

---

From: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:06:47 -0500

> Terry,
> 
> Thanks for the syntax example.  It was not clear that "alternatives" means
> the alternativeValue rule in the ABNF.  The relevant text in section 7.1.8
> reads:
> 
> I may have missed something elsewhere in the v1 spec or the IG, but I
> interpret this as referring to some vague, unspecified method of encoding
> alternatives.  The statement would be clearer if it were reworded:
> 
> * the use of the H.248 alternativeValue syntax is allowed in place of any
> single SDP parameter value. 
> 
> Regards,
> David
> --

---

From: "David Cromwell"<[email-masked]>
Date: Wed, 27 Mar 2002 16:06:47 -0500

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 27 Mar 2002 16:41:11 -0500

I can give the history.  We inherited SDP in the first place from SGCP by
way of MGCP: it was a clever way of interworking with SIP.  However, when
the draft Megaco/H.248 spec was fairly mature, it still wasn't clear how the
two ends were going to agree on the session description.  As a result of
discussion in the December 1999 - January 2000 time frame (when I should
have been putting the document through Last Call and avoiding a heap of
trouble later), we added the ReserveValue and ReserveGroup logic.

I have always understood that ReserveValue applied to the standard SDP list
of media formats as well as to items conveyed by the alternativeValue
construct.  Your words make me wonder if that was an assumption not shared
by everyone.

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 4:25 PM
To: Cromwell, David [NCRTP:3S12:EXCH]
Cc: Taylor, Tom-PT [CAR:B800:EXCH]; 'Carl Rutter'; [email-masked]
Subject: Re: [Megaco] Field alternatives in SDP

We allow several exceptions to SDP syntax 
1) omitting s=, t= and o= 
2) allowing CHOOSE 
3) alternatives 
The first two are fairly easy to work around, I believe most are concerned
only with #3.  Completely removing alternative would remove most of the
functionality of ReserveValue (it can still be used with CHOOSE but this is
not the most valued use IMHO).  So I think the main issue is whether we
prefer to have only multiple groups and ReserveGroup in order to avoid
having to modify an SDP parser for the added production. 
Remember that we also have a binary syntax that allows alternative values
for each property (see Annex C).  Removing any way to support alternatives
in text encoding would leave a difference in functionality between the two
unless we also disallowed alternatives in binary. 
This seems like a rather big change.  I was not involved when the
alternative/ReserveValue feature was originally proposed so I cannot say why
it was considered to be worth the impact on SDP parsers.  Perhaps others can
provide the history.  It seems rather useful to me, but I admit that much
the same functionality can be provided by groups alone, if one accepts
rather huge descriptors. 
As to interworking with standard SDP (I suppose H.248<->SIP ??), this will
continue to be a problem in that multiple groups and multiple streams offers
features that are difficult/impossible to implement in a single SDP session
description even with simcap and fid. 
I don't believe that such interworking was the original goal (but again I
wasn't there) but rather providing a rich syntax for our descriptors without
starting from scratch.  We borrowed SDP syntax because it provided most of
what we wanted but not all. 

David Cromwell wrote: 
  
Comments below. 
David 
  
-----Original Message----- 
From:   Terry L Anderson [SMTP:[email-masked]] 
Sent:   Tuesday, March 26, 2002 11:51 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 
have larger SDPs with standard syntax or more compact SDPs with non-standard
(with respect to RFC 2327)  syntax.  Are there any cases where semantic
information will be lost by encoding in standard SDP?

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 27 Mar 2002 16:41:11 -0500

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 4:25 PM
To: Cromwell, David [NCRTP:3S12:EXCH]
Cc: Taylor, Tom-PT [CAR:B800:EXCH]; 'Carl Rutter'; [email-masked]
Subject: Re: [Megaco] Field alternatives in SDP

David Cromwell wrote: 
  
Comments below. 
David