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

From: Panditha Govindaraj <[email-masked]>
Date: Thu, 7 Dec 2000 16:53:52 -0500

I understand that Octet string can have a $

but how do i parse this in SDP grammar, because i receive it as a part of
Octet string which has SDP grammar.

when it comes to MEGACO

Before i pass the Octet string to the SDP , How do i handle '$' in SDP as it
is a part of MEGACO

How is this to be handled.

Does this mean that RFC 2327 need to be updated.

Govind

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Thursday, December 07, 2000 4:07 PM
To: Panditha Govindaraj
Cc: [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: "Rosen, Brian" <[email-masked]>
Date: Fri, 8 Dec 2000 08:35:16 -0500

Naren

I am so sorry you were not contributing to the discussion when the grammar
was being solidified.  I am certain that all of us would have preferred that
the grammar used RANGE-d0,d6 rather than the difficult-to-parse d0:d6.
Prefix languages are fun.  I suppose you are a real lisp fan.  D'ja ever
try writing an APL parser?  That's pretty interesting.

I'm a little worried that we might have pushed back a little on getting
rid of comments.  Text based protocols being human readable, one often does
like
comments from time to time.  Turns out many real applications use fixed
hunks
of message text to accomplish tasks. Messages that humans write, and others
read.  'Course writing a parser for a text based grammar that includes
comments
might be considered difficult if only we hadn't gotten so used to them with
compilers and interpreters and just about everything else that uses a
parser,
right?

I like the suggestion I heard that you should have a runtime -verbose switch

which when on uses long tokens and leaves comments, when off uses short
tokens
and suppresses comments.

I actually would have tried to fix the shift-reduce issue.  That is
unnecessary,
but it's too late now.  We did fix several of these kinds of problems as we
developed the grammar.  There were 2-3 groups who were writing and modifying
parsers as the grammar evolved.  We made many edits as these brave souls
tried
to keep up with us and discovered ambiguities.  I believe the grammar can be

pretty easily fit into an LL(1) parser, and we have reports of several
others.
Lots of folks used yacc/lex which is LALR(1).

There were 12 or so DIFFERENT parsers at the first interop event.  No one
seemed
to have great difficulty with the grammar.  It's not a simple grammar, so
the
parsers aren't simple, but quite a few people have dealt with it.

Brian

> From: Tulpule, Naren [mailto:[email-masked]]
> Sent: Thursday, December 07, 2000 4:29 PM
> To: [email-masked]
> descrip tor
> 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
>
>
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Thursday, December 07, 2000 1:07 PM
> To: [email-masked]

---

From: Panditha Govindaraj <[email-masked]>
Date: Fri, 8 Dec 2000 11:30:45 -0500

Hi Naren,Troy and list

Does this mean that i need to parse the Grammar in the
draft-ietf-mmusic-sdp-atm-02.txt
and not RFC 2327
and one more thing , How do I parse VAD=X-NNVAD and when does this occur,
Where is this defined in the grammar,

This indicates Voice activity Detection though it is in Example of MEgaco
Specs but
this is still valid. Can you help me to find a clarification on this.

As of now i have written a parser for the grammar in RFC 2327 which is SDP
,to parse the octet string in Local & Remote
Descriptors.
Do I need to parse the Remote descriptor using RFC 2327
and write a different parser for Local descriptor which parses the grammar
in
draft-ietf-mmusic-sdp-atm-02.txt
but still the VAD=X-NNVAD is not clarified

We have written our own parser , Where we parse each token

This was not mentioned the RFC 2885 right

Please clarify me , Expecting a reply soon.

Govind

-----Original Message-----
From: Tulpule, Naren [mailto:[email-masked]]
Sent: Thursday, December 07, 2000 4:29 PM
To: [email-masked]
Subject: Re: clarification in SDP parsing (octet string ) in Local
descrip tor

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

-troy

---

From: "Tulpule, Naren" <[email-masked]>
Date: Fri, 8 Dec 2000 11:48:50 -0800

Hi Brian and list,
  My apologies to Troy, I was whinging about the grammar, he was NOT.
Brian,
   I will not harp on this lest this generates into a pointless flamewar
(started by me!!) I was pointing out what I thought were unnecessary
features. I am not convinced about the SDP format changes but as to the
rest, yes they're overcome using a parser-builder. I have to implement it
anyway, but don't call me a LISP fan :-)

-- Naren.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, December 08, 2000 5:35 AM
To: [email-masked]
Subject: Re: clarification in SDP parsing (octet string ) in Local
descrip tor

Naren

Brian

---

From: Panditha Govindaraj <[email-masked]>
Date: Fri, 8 Dec 2000 15:01:46 -0500

Hi Lsit

Sorry for Resending this once again,

iam resending this message as i have not got any solution to my previous
question ,

And i am in the process of implementing this.

So I would like some one in the List to answer my question, As I can keep my
SDP

Parser implementation work movinf.

Govind

Hi Naren,Troy and list

Govind

-----Original Message-----
From: Tulpule, Naren [mailto:[email-masked]]
Sent: Thursday, December 07, 2000 4:29 PM
To: [email-masked]
Subject: Re: clarification in SDP parsing (octet string ) in Local
descrip tor

-- Naren.

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

-troy