Subject: RE: [Megaco] Field alternatives in SDP

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

> Comments below.
> 
> 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 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
> 
> There is no parsing problem.  
> 
> [<dcc>]  Now that I understand there is a defined syntax I agree.
> 
> 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.
> 
> [<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?
> 
> 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?
> 
> [<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:
> 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.
> 
> [<dcc>]  I'd add alternative # 5 which would be to disallow the
> alternativeValue syntax in SDP.
> 
> Understand that anything other than #1 may break current
> implementations.
> 
> [<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. 
> 
> ------------------------------------------------------------
> 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
>  << File: Card for Terry L Anderson >> 

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

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 27 Mar 2002 17:29:36 -0500

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.

--

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 27 Mar 2002 17:29:36 -0500

--