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

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

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

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 29 May 2002 09:51:43 -0400

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 29 May 2002 09:51:43 -0400

Sorry for the confusion.

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 29 May 2002 17:03:30 -0400

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.

-- 

------------------------------------------------------------
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: Terry L Anderson <[email-masked]>
Date: Wed, 29 May 2002 17:03:30 -0400

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 18:01:50 -0400

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.
>>
>Tel:732.949.5628   Fax:732.949.7016 Lucent Technologies/INS/Voice Over IP 
>Access Networks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 18:01:50 -0400

Hi,

Thanks
         Aleks

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 29 May 2002 20:11:07 -0400

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
>         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
>> 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, 
>> 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 
>> 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.
>>>
>> Tel:732.949.5628   Fax:732.949.7016 Lucent Technologies/INS/Voice 
>> Over IP Access Networks

--

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 29 May 2002 20:11:07 -0400

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 20:50:20 -0400

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:
>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.
>
>>to wrap an entire SDP as one param then MGC might not even need to have 
>>an internal
>>>Tel:732.949.5628   Fax:732.949.7016 Lucent Technologies/INS/Voice Over 
>>>IP Access Networks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 20:50:20 -0400

Hi,

Thanks
         Aleks