Subject: RE: [Megaco] SDP equivalent in ASN.1

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 30 May 2002 10:47:54 -0400

Hi,

         If I were to make life easier for MGC I say I'd use both: 
"miltiline SDP" for SDPs
being "passed through" and single record tags for explicitly added by MGC 
params.

Although for consistency and simplicity as well as to make life easier for 
MG (that is
for MG to have only one SDP parser) it makes sense to use only "multiline SDP"
form and "forget" C.11 table all together.

I'd vote for last one.

Thanks
         Aleks

At 08:44 AM 5/30/2002, Tom-PT Taylor wrote:

>Makes sense to me.  Is it your intent to use this tag for partial session 
>descriptions as well as complete ones, or only the latter?
>
>-----Original Message-----
>From: Aleksandr Ryabin 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Wednesday, May 29, 2002 8:50 PM
>To: Terry L Anderson; [email-masked]
>Subject: Re: [Megaco] SDP equivalent in ASN.1
>
>Hi,
>
>One "a=silenceSupp", or collection of this and any other SDP based parameters
>can be looked at as just one, or collection of SDP "records" (lines), thus
>generally
>speaking it can be treated as one "multiline SDP", so it still will work 
>if MGC
>needs to add such parameters explicitly.
>
>I'm just trying to understand the reasoning for having a C.11 table vs
>having just one
>tag that would indicate "here comes something resembling SDP" which will
>direct
>MG to invoke SDP parser on the property to get it handled.
>
>If there are no strong objections can we add support (tag) for "multiline 
>SDP"
>(e.g. entire SDP) as a single parameter?
>
>Thanks
>          Aleks
>
>At 08:11 PM 5/29/2002, Terry L Anderson wrote:
> >I don't believe that it was the intention to require that one take a
> >complete SDP session description and send all lines using C.11.  While one
> >could do this as an alternative to using the other Annex C properties, one
> >might also use the SDP equivalents to supplement the other properties
> >where a desired property is defined in SDP but not else where in Annex
> >C.  For example, one might use the SDP_A to send an attribute such as
> >a=silenceSupp defined in RFC 3108 which allows more control than boolean
> >Silencesupp (1008) in C.1.
> >
> >The question is whether we should also support an entire SDP session
> >description as a single parameter for the reasons you suggest.
> >
> >Aleksandr Ryabin wrote:
> >
> >>Hi,
> >>
> >>         Just out of curiosity, what do we gain by parsing SDP into
> >> records and encoding
> >>records one by one rather then "wrapping an entire multiline SDP"?
> >>
> >>         One might say this simplifies parsing on MG side, but since each
> >> SDP record has to
> >>be parsed anyway then MG must have SDP parser in any case, thus that does
> >>not seem
> >>like a good reason.
> >>
> >>         The reason I ask is from MGC point of view SDP in many cases is
> >> being passed
> >>to it from other signalling protocols (that is MGC does not generate it).
> >>Thus if we were
> >>to wrap an entire SDP as one param then MGC might not even need to have
> >>an internal
> >>SDP parser. While using current mechanism, MGC has to have SDP parser
> >>(capable of
> >>splitting SDP on records) and it has to invoke it each time it is
> >>"propagating" SDP to MG
> >>which seems like wasting of of memory and CPU.
> >>
> >>Thanks
> >>         Aleks
> >>
> >>At 05:03 PM 5/29/2002, Terry L Anderson wrote:
> >>
> >>>I guess the issue is whether one views the CRLF as a line terminator or
> >>>a delimiter. Since in Annex C we do not have multiple SDP lines in a
> >>>single string, as we do in a text encoding Local|Remote Descriptor,
> >>>there is no need for a delimitor for parsing purposes, and one is not
> >>>sending SDP one is sending an isolated SDP line as the value of the tag.
> >>>Admittedly RFC2327 discusses CRLF "to end a record" rather than as a
> >>>delimiter, but clearly the issue is a delimiter for parsing and when a
> >>>single "record" is used in an Annex C tag/value pair this is
> >>>unnecessary.  Are we arguing that some might have an SDP parser that can
> >>>handle a single record (illegal as SDP) but requires the CRLF as a
> >>>terminator?  Surely, it is trivial to add this to the output of the
> >>>Annex C parser before submitting to an SDP parser if required.  If we
> >>>were wrapping an entire multiline SDP spec into a single value in Annex
> >>>C I would agree we should use the RFC 2327 "record end", but I nothing
> >>>to be gained in adding either NULL or CRLF to a single SDP line.
> >>>
> >>>Troy Cauble wrote:
> >>>
> >>>>Sorry for the confusion.
> >>>>
> >>>>No we do not use the CRLF delimiters in the ASN.1 Annex C equivs.
> >>>>The same reaoning applies: it would take up space and add no value.
> >>>>
> >>>>-troy
> >>>>
> >>>>
> >>>>Tom-PT Taylor wrote:
> >>>>
> >>>>
> >>>>>I remember we agreed not to use NULLs, but that isn't the issue in any
> >>>>>event.  SDP isn't C, and its lines are terminated by CRLF (x0d0a).
> >>>>>Am I to
> >>>>>presume you operate without these?
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Troy Cauble 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >>>>>Sent: Tuesday, May 28, 2002 9:33 AM
> >>>>>To: Taylor, Tom-PT [CAR:B602:EXCH]
> >>>>>Cc: 'Nurit Shenhar'; 'Megaco_IETF (E-mail)
> >>>>>Subject: Re: [Megaco] SDP equivalent in ASN.1
> >>>>>
> >>>>>I think not.
> >>>>>
> >>>>>The ASN.1 standard for strings is to not include the EOL, and
> >>>>>Annex A specifies this as an IA5String.
> >>>>>
> >>>>>Adding NULLs would not make unpacking easier, but would increase
> >>>>>message size.
> >>>>>
> >>>>>I currently support a parser/encoder that uses the Annex C
> >>>>>SDP equivs without the NULLs.  It has interoperated with
> >>>>>other stacks using this format.
> >>>>>
> >>>>>-troy
> >>>>>
> >>>>>Tom-PT Taylor wrote:
> >>>>>
> >>>>>
> >>>>>>It's my view that we are in new territory here, so this is a matter of
> >>>>>what
> >>>>>
> >>>>>
> >>>>>>we agree.  Certainly the EOL is unnecessary, as the ASN.1 itself 
> provides
> >>>>>a
> >>>>>
> >>>>>
> >>>>>>clear delineation of each line.  So the question is whether having
> >>>>>>the EOL
> >>>>>>makes it easier to unpack the SDP and pass it to an SDP parser, or
> >>>>>whatever
> >>>>>
> >>>>>
> >>>>>>people do.
> >>>>>>
> >>>>>>Comments, please, from anyone who has explored this territory.
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Nurit Shenhar 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >>>>>>Sent: Sunday, May 26, 2002 10:30 AM
> >>>>>>To: 'Megaco_IETF (E-mail)
> >>>>>>Subject: [Megaco] SDP equivalent in ASN.1
> >>>>>>
> >>>>>>Hi
> >>>>>>When using the SDP equivalences for the ASN.1, should the string 
> still be
> >>>>>>finished with EOL?
> >>>>>>Nurit
> >>>>>_______________________________________________
> >>>>>Megaco mailing list
> >>>>>[email-masked]
> >>>>><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/ 
> mailman/listinfo/megaco
> >>>>
> >>>>_______________________________________________
> >>>>Megaco mailing list
> >>>>[email-masked]
> >>>><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/m 
> ailman/listinfo/megaco
> >>>
> >>>--
> >>>
> >>>------------------------------------------------------------
> >>>Terry L 
> Anderson              <mailto:[email-masked]>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>http://its.lucent.com/~tla (Lucent 
> internal) <http://www.gti.net/tla>http://www.gti.net/tla
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Megaco mailing list
> >>>[email-masked]
> >>><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/ma 
> ilman/listinfo/megaco
> >>
> >
> >--
> >
> >------------------------------------------------------------
> >Terry L Anderson              <mailto:[email-masked]>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>http://its.lucent.com/~tla (Lucent internal) 
> <http://www.gti.net/tla>http://www.gti.net/tla
> >
> >
> >
> >
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 31 May 2002 14:08:54 +1000

What is the real requirement for this property? Is it to encapsulate a complete
SDP chunk without the MGC looking at it? Is it to provide SDP equivalent to the
text encoding equivalent of the protocol? You cannot get away with not having an
SDP parser in the MGC because it has to pass the relevant information into the
local or remote descriptor and local control descriptor. Megaco also introduces
a modified SDP.

You can have multiple lines with the current properties by providing a list of
values to the property.

Regards, Christian

Aleksandr Ryabin wrote:
> 
> Hi,
> 
>         If I were to make life easier for MGC I say I'd use both: "miltiline
> SDP" for SDPs
> Although for consistency and simplicity as well as to make life easier for MG
> (that is
> > From: Aleksandr Ryabin [mailto:[email-masked]]
> > speaking it can be treated as one "multiline SDP", so it still will work if
> > MGC
> > >>>>>From: Troy Cauble [mailto:[email-masked]]
> > >>>>>>From: Nurit Shenhar [mailto:[email-masked]]
> > >>>>>>When using the SDP equivalences for the ASN.1, should the string still
> > be
> > >>>>>>finished with EOL?
> > >>>>>>Nurit
> > >>>>>https://www1.ietf.org/mailman/listinfo/megaco
> > >>>>
> > >>>>https://www1.ietf.org/mailman/listinfo/megaco
> > >>>
> > >>>--
> > >>>
> > >>>Terry L Anderson              mailto:[email-masked]
> > >>>http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>https://www1.ietf.org/mailman/listinfo/megaco
> > >>
> > >
> > >--
> > >
> > >Terry L Anderson              mailto:[email-masked]
> > >http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> > >
> > >
> > >
> > >
> >
> > https://www1.ietf.org/mailman/listinfo/megaco

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 31 May 2002 14:08:54 +1000

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 31 May 2002 12:58:28 -0400

At 12:08 AM 5/31/2002, Christian Groves wrote:
>SDP chunk without the MGC looking at it?

Yes, primarily.

>Is it to provide SDP equivalent to the text encoding equivalent of the 
>protocol?

Yes, that too. This way MGC only has to have one (text) encoder for modified
SDPs, or if nothing needs to be modified then it is the same as the previous
question/answer above.

>You cannot get away with not having an
>local or remote descriptor and local control descriptor.

I beg to differ, if you are taking about properties encoded into SDP (e.g 
ptime),
this info can already be encoded into SDP at the time SDP is received
by MGC from outside (e.g a signalling protocol).
In case if MGC explicitly wants to set these then it can generate local SDP.
Note that generally speaking generation and parsing are two different things.

>  Megaco also introduces a modified SDP.

Of course if MGC needs to modify anything in SDP to use these new features
then it has to have a parser. What I was talking about is MGC that does not
do that and thus does not have to have a parser.

Thanks
         Aleks

> "miltiline

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 31 May 2002 12:58:28 -0400

Yes, primarily.

Thanks
         Aleks

---

From: Troy Cauble <[email-masked]>
Date: Fri, 31 May 2002 14:48:59 -0400

> You can have multiple lines with the current properties by providing a list of

It sounds like you are talking about the alternateValue sublist
construct.  But the Annex C.11 properties are defined as "String", 
not "Sub-list of string".

Or did you you mean the use of alternatives in the
SDP itself? 

	m=audio $ RTP/AVP 4,5,6

-troy

---

From: Troy Cauble <[email-masked]>
Date: Fri, 31 May 2002 14:48:59 -0400

m=audio $ RTP/AVP 4,5,6

-troy