Subject: RE: SDP and ';' comments

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 May 2001 14:02:15 -0400

A line that starts with "}" after a well formed line in SDP is an error.
So would be a line that started with ==.
 
Either you find the matching "}" in the Megaco parser, and pass the body to
the SDP parser, or you change the SDP parser to stop on the "}" and invoke
it
in-line.  Adding a == wouldn't change that except for not having to back up
the scanner on the }.  I don't want to change the protocol to add the "==".
 
Brian

-----Original Message-----
From: Tulpule, Naren [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:37 PM
To: 'David Stonehouse'; MEGACO list
Subject: RE: SDP and ';' comments

The resolution to Troy's initial statement is not only because of the way an
SDP ends, but also in the way that the octetString terminal will force the
Megaco parser to pull everything up to the '}' into the octetString.  
[Naren] Depends on the parser implementation... when there's no doubt that
the so-called octetstring is nothing but SDP, so you may not need to call
the Megaco octetstring parser followed by the SDP parser - you can call the
SDP parser in place. In this case the SDP parser can terminate when it
cannot understand the beginning of a line.

Pasting from Naren's post from last September (for which I never saw any
responses): 

    4. escaping "}" in SDP strings 
            I don't know if  "}" can appear in SDP attribute or VcId or
other 
    values. Nonetheless to be safe, especially on the MGC side when you
might 
    just want to treat SDP description as opaque, why not delimit the the 
    description with a line that starts with "==" (two "=" symbols) or a
similar 
    illegal combination? Using "\}" is really not feasible. 

The issue isn't that "}" could appear in SDP - it's whether "\}" could
appear in SDP.  If it can not, then it is okay for the Megaco parser to
translate the "\}" to "}", and pass the resulting string to the SDP parser.

[Naren] So far I haven't seen either "}" or "\}" in SDP. The thing is, we
don't really need to impose any restrictions on SDP at all. Just start a new
line with something which cannot occur after EOL in SDP  and define that to
be the "end-of-SDP-start-of-Megaco" delimiter (e.g. "==") instead of RBRKT.
(For the aesthetes, RBRKT can still follow this delimiter).

These views are mine alone, not those of Intel or Trillium. 
-- Naren 
Narendra C. Tulpule         310-442-9222 
SMTS, Trillium (an Intel company) 
12100 Wislshire Bl #1800 Los Angeles CA 90025

---

From: "Tulpule, Naren" <[email-masked]>
Date: Fri, 18 May 2001 11:30:51 -0700

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]

 
[NAREN] Hi Brian, 
  you are right about "==" not adding any value even if it replaces "}" as
far as the SDP parser is concerned. It doesn't matter where the SDP parser
is called from, (1) inline by Megaco parser or (2) seperately after Megaco
parser gathers the SDP octetstring. RBRKT will serve just as well, as a
delimiter.
My confusion was, when does Megaco parser stop collecting the octetstring? 
Megaco says - when you see a "}" which is not preceded by a "\" (backslash).
Megaco parser should replace all "\}" in SDP string with "}" while decoding
and replace all "}" with "\}" while encoding SDP in Megaco messages. This is
a simpler rule but adds more processing (not to mention the fact SDP strings
cannot be passed directly to another protocol because Megaco has changed
them).
I'd say - this is unnecessary - For case (2) Megaco parser should stop
collecting the SDP string on seeing a line which cannot be the beginning of
an SDP line (again, doesn't matter if it is "==" or LWSP "}"). No
substitution of "}" by "\}" or vice versa is necessary in any case. For case
(1) SDP parser should terminate if it sees the Megaco delimiter instead of a
valid beginning of SDP line. This delimiter as defined by the Megaco ABNF is
(LWSP "}") (part of RBRKT). 
So, let us remove the requirement of substituting "}" by "\}". 
Do you agree?