Subject: Re: clarification in SDP parsing (octet string ) in Local descrip tor

From: "Tulpule, Naren" <[email-masked]>
Date: Thu, 7 Dec 2000 13:28:38 -0800

Hi Troy, Govinda and list,
  First, Govinda - IN IP4 $ is not in RFC2327 (SDP) as it is now, but very
likely will be added. You can take a look at the MMUSIC drafts - they're
recirculating the SDP RFC, plus adding ability to describe ATM parameters
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-02.txt) among
others. I don't know which RFC or draft the a=fmtp line came from though -
it doesn't comply with RFCs 2733, 2833 or 2848. Good thing the Megaco spec
says it's only an example :-)
  Troy - I agree with you, they had absolutely no need to bend the SDP RFC.
They could have chosen to terminate SDP announcements with an invalid line
(e.g. "==" EOL). There are other improvements possible in the grammar of
course but perhaps it's too late now. Examples -
1. To know if a parmValue is a list-of-ANDed-values ("[ VALUE, VALUE, ...]")
or a range of values ("[ VALUE : VALUE]") you need to go past the first
VALUE when a prefix ("AND-" and "RANGE-") could have solved the problem
easily.
2. Ability to have comments embedded in the message seems really
superfluous. Is the MGC going to tell the MG "Keep up the good work" or
something :-) ? No Occam's razor was applied at any point in writing the
grammar.
3. There is a shift-reduce conflict when an MID is an MTP address, and
supposed to be followed by a SEP, because MTP address ends with a RBRKT
which ends with an LWSP. All parser builders would resolve it in favor of
shift but the grammar needs a reduce at this point.
    These are not unsurmountable difficulties of course, just unnecessary,
and contribute to complicate the pasring code in logic, code size and
runtime efficiency.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Thursday, December 07, 2000 1:07 PM
To: [email-masked]
Subject: Re: clarification in SDP parsing (octet string ) in Local
descriptor

Seems to me that the octetString can have a $.
As for the SDP RFC, I guess they're bending the RFC.

   octetString          = *(nonEscapeChar)
   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )

-troy

Panditha Govindaraj wrote:
>
> Hi
>
>         In the Example call flow of MEGACO RFC 2885
>
> The local descriptor :
>
> The local token follows by an octet string
>
> This Octet string is the part of SDP grammar, In the SDP grammar
>
> it is no where shown that the octet string can have a $ (does this mean
> choose wild card) if yes how is this to be handled, as RFC 2327 for SDP
>
> does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
> to be handles in the SDP Parser of Megaco
>
> Can somebody suggest me
>
> Here is a copy of the Example
>
> Local {
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 4
>    a=ptime:30
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>                      }
>
> Thanks
>
> Govindaraj.P

---

From: Troy Cauble <[email-masked]>
Date: Fri, 8 Dec 2000 11:04:17 -0500

"Tulpule, Naren" wrote:

> (e.g. "==" EOL).

For the record, I want to point out that I wasn't complaining
about this.  (As I do about so many other things:)

-troy