Subject: [Megaco] SDP equivalent in ASN.1

From: "Nurit Shenhar" <[email-masked]>
Date: Sun, 26 May 2002 16:29:35 +0200

Hi

When using the SDP equivalences for the ASN.1, should the string still be finished with EOL?

Nurit

************************************************************************************************************
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify [email-masked]
and permanently delete the e-mail and files.
***********************************************************************************************************

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 27 May 2002 09:14:30 -0400

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

****************************************************************************
********************************
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this email in error please notify
[email-masked]
and permanently delete the e-mail and files.
****************************************************************************
*******************************

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 28 May 2002 22:24:17 -0400

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 30 May 2002 08:44:22 -0400

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:
>>>>
>>>>
>>>>>>we agree.  Certainly the EOL is unnecessary, as the ASN.1 itself
provides
>>>>>a
>>>--
>>>------------------------------------------------------------
>>>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: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 30 May 2002 08:44:22 -0400

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

Thanks
         Aleks

provides

---

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:

>From: Aleksandr Ryabin 
>[<mailto:[email-masked]>mailto:[email-masked]]
>One "a=silenceSupp", or collection of this and any other SDP based parameters
>speaking it can be treated as one "multiline SDP", so it still will work 
>if MGC
> >>>>>From: Troy Cauble 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >>>>>>From: Nurit Shenhar 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >>>>><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/ 
> mailman/listinfo/megaco
> >>>>
> >>>><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/m 
> ailman/listinfo/megaco
> >>>
> >>>--
> >>>
> >>>Terry L 
> Anderson              <mailto:[email-masked]>mailto:[email-masked]
> >>><http://its.lucent.com/~tla>http://its.lucent.com/~tla (Lucent 
> internal) <http://www.gti.net/tla>http://www.gti.net/tla
> >>>
> >>>
> >>>
> >>>
> >>>
> >>><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/ma 
> ilman/listinfo/megaco
> >>
> >
> >--
> >
> >Terry L Anderson              <mailto:[email-masked]>mailto:[email-masked]
> ><http://its.lucent.com/~tla>http://its.lucent.com/~tla (Lucent internal) 
> <http://www.gti.net/tla>http://www.gti.net/tla
> >
> >
> >
> >
>
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>