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

From: Christian Groves <[email-masked]>
Date: Mon, 03 Jun 2002 13:39:32 +1000

G'Day Troy,

You could have either of the constructs. I was just illustrating that there are
ways of getting multiple SDP lines rather than a new property saying "multiline
SDP". You also could have multiple values and use reserve value in local
control.

Regards, Christian

Troy Cauble wrote:
> 
> Christian Groves wrote:
> 
> >  Megaco also introduces
> > a modified SDP.
> >
> > You can have multiple lines with the current properties by providing a list of
> > values to the property.
> 
> 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
> 
> > Aleksandr Ryabin wrote:
> > >
> > > 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

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 03 Jun 2002 13:39:32 +1000

G'Day Troy,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 03 Jun 2002 13:47:43 +1000

G'Day Aleks,

Please see my comments below.

Regards, Christian

Aleksandr Ryabin wrote:
> 
> At 12:08 AM 5/31/2002, Christian Groves wrote:
> >What is the real requirement for this property? Is it to encapsulate a
> >complete
> >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
> >SDP parser in the MGC because it has to pass the relevant information into the
> >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.

[CHG] You must have at least a simple parser that identifies Ptime from the
received SDP and then places it in the local or remote descriptor. You can't
just copy the entire SDP chunk received on the MGC and simply copy it into the
local and remote descriptors. 

> 
> >  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
> 
> >Regards, Christian
> >
> >Aleksandr Ryabin wrote:
> > >
> > > Hi,
> > >
> > > 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]]
> > > > 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]]
> > > > >>>>>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]]
> > > > >>>>>>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
> > > > >>>--
> > > > >>>------------------------------------------------------------
> > > > >>>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
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >--
> > > > >------------------------------------------------------------
> > > > >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: Christian Groves <[email-masked]>
Date: Mon, 03 Jun 2002 13:47:43 +1000

G'Day Aleks,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 10:49:13 -0400

Hi Christian,
         Please see my comment inline below.

>local and remote descriptors.

Sorry if I was not clear, but what I meant is ptime information would be 
provisioned,
that is it will be available to MGC without looking into SDP.

Of course, once it comes to getting anything from SDP then MGC got to have 
a parser.
The case I was advocating here is MGC which does not look what so ever into 
any
SDP given to it. Thus is does not have to have SDP parser, yet because of 
protocol
limitation/restriction it must have one.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 10:49:13 -0400

Hi Christian,

Thanks
         Aleks