Subject: RE: [Megaco] Octet String Encoding

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 15 May 2002 09:17:28 -0400

I think we need to fix something here so other people won't be misled.  At
the very least we need a comment in front of Local and Remote in Annex B.
Other suggestions?

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 4:27 AM
To: Rajeev K R
Cc: Megaco
Subject: Re: [Megaco] Octet String Encoding

Hi,

> I think you have answered the question correctly ( though you say you
> didin't understand the question correctly :)  )

Good :)

> So in your opinion the SDP string must go "as it is" in the megaco
message.
> (I also think the same way)

Yes, assuming we're talking about text encoded messages (binary encoding
uses
separate "tags" for SDP).

> The stack I have in MGC encode the SDP string in Hexadecimal coding
> format and so "v=0" is coded as "6EBC00" in the message

That is incorrect.

> and the MG reject it hence it is expecting "v=0" saying that the char "6"
is
> not expected. So
> this issue is related to the difference in encoding itself.
>
> The MG is able to understand the SDP and reply it correctly if I don't
> do this hexadecimal encoding in the stack.(by tweaking the stack code in
> MGC).  The reply from MG contains the pure (readable) SDP string. So there
> is a difference between the stacks in MG and MGC in encoding and decoding
> SDP string into message. So I wanted to confirm who is doing it right ??

The stack putting the SDP "as it is" into the message does it right.

> The implementer's guide  Section B.3 Hexadecimal octet coding states the
> following: "Hexadecimal octet coding is a means for representing a string
of
> octets as
> a string of hexadecimal digits, with two digits representing each octet.
> This octet encoding should be used when encoding octet strings in the text
> version of the protocol."
>
> This means that octet strings should be encoded in hexadecimal format.

Yes. But, since SDP is not binary, there is no need to encode it according
to
B.3.

Example where the octec encoding are actually used can be used in Annex M.4.

> From the ABNF Specification there are 3 places where we use octet string:
> They are
>
> mtpAddress           = MTPToken LBRKT octetString RBRKT
> localDescriptor      = LocalToken LBRKT octetString RBRKT
> remoteDescriptor     = RemoteToken LBRKT octetString RBRKT
>
> The SDP string we are discussing is part of localDescriptor  or
> remoteDescriptor. So it becomes applicable here...
>
> Any other thoughts on this ??

I think you are mixing two kind of definitions for octet string.

The ABNF defines octetString as:

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

Ie octecString is a string of allowed ASCII characters.

I DO, however, agree that this can be confusing, so I wonder if the name in
the
ABNF should be changed to something else?

Regards,

Christer Holmberg
Ericsson Finland

>
>
> Regards,
> Rajeev
>
> ----- Original Message -----
> From: "Christer Holmberg" <[email-masked]>
> To: "Rajeev K R" <[email-masked]>
> Cc: "Megaco" <[email-masked]>
> Sent: Tuesday, May 14, 2002 8:58 PM
> Subject: Re: [Megaco] Octet String Encoding
>
> >
> > Hi,
> >
> > I am not sure I understood your question correctly, but I'll give it a
try
> :)
> >
> > The hexadecimal octet coding is used to transport binary data in "text
> format"
> > within an H.248 message. SDP is already text format, so you don't have
to
> > convert it into anything...
> >
> > The first parameter in SDP MUST be the version line, but that is because
> of the
> > SDP standard, and has nothing to do with the encoding itself.
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> > > Is the Hexadecimal octet coding specified in Annex B.3 is applicable
for
> SDP
> > > string also ?
> > >
> > > I have a stack at the MGC side which does this encoding and send the
SDP
> > > out.
> > > But the MG reject this media because the first char is not 'v' (v=0
> line).
> > > The MG vendor says this encoding is only for display string in andisp
> > > package  and not for media,
> > > but the stack vendor says it is applicable for any octet string
> including
> > > media desc.
> > >
> > > Can anybody please clarify this ?
> > >
> > > Thanks and Regards,
> > > Rajeev
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >

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

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 15 May 2002 10:51:02 -0400

> the very least we need a comment in front of Local and Remote in Annex B.

Long ago I was mislead by this too.

My suggestion was to rename the ABNF element 
"octetString", since it doesn't really resemble
a string of octets.  You'll probably consider
that too radical though.

Here's the thread from November 2000.

-troy

> 
> Christian,
> 
> I'm happy to be wrong about the intent!
> 
> But if it's not referring to the "octetString" element
> of the ABNF, what is it referring to?
> 
> From the problem description:
>         "Sometimes it is desirable to transfer octet strings
>          between MG and MGC."
> 
> WHEN??  This should be a clearly labled part of the ABNF
> spec.
> 
> The solution describes how to do "hexidecimal octet coding"
> but doesn't tell us where or when we would.
> 
> I jumped to the conclusion that you were referring to the ABNF 
> "octetString".  (It *was* mentioned in the problem description.)
> 
> Can I suggest that the ANBF element "octetString" be renamed to
> avoid confusion?
> 
> -troy
> 
> 
> Christian Groves wrote:
> > 
> > Hello Troy,
> > 
> > I think you have a GROSS misunderstanding of what was proposed. It was a
> > suggestion from Lucent have some conformity when you wanted to code a
> > Binary octet with the text encoding. If you wish to send a binary
> > encoded octet string then you should use the hex format proposed. If you
> > have SDP or text to send ofcourse you use text.
> > 
> > Christian
> > 
> > Troy Cauble wrote:
> > >
> > > Hello again,
> > >
> > > Does section 6.48 of the Implementors Guide really say
> > > that the text encoding that used to be this:
> > >
> > >          Local {
> > > v=0
> > > c=IN IP4 $
> > > m=audio $ RTP/AVP 0
> > > a=fmtp:PCMU VAD=X-NNVAD
> > >         }
> > >
> > > Is now this:
> > >
> > >         Local {
> > >
> 763d30200a633d494e204950342024200a6d3d617564696f2024205254502f4156502030200a613d666d74703a50434d55205641443d582d4e4e5641440a
> > >         }
> > >
> > > !?!?!?!
> > >
> > > Let's be reasonable.  There's no reason to make this unreadable.

---

From: Troy Cauble <[email-masked]>
Date: Wed, 15 May 2002 10:51:02 -0400

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 15 May 2002 13:13:06 -0400

I prefer a comment, if we believe that is sufficient, over a change in the
syntax spec (renaming a production).  Tom, want to suggest a wording?  I'll
include it in the IG.

--

------------------------------------------------------------
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, 15 May 2002 13:13:06 -0400

--

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 May 2002 22:46:49 +0300

Hi,

One option would be to define that only SDP(s) are allowed inside the Local- and
Remote descriptors (does anyone use anything else????), but that would of course
not be very good for possible future possibilities (SDPng, or whatever...).

However, IF we allow different kind of "message bodies" in the Local- and Remote
descriptors, will we need some kind of "Content-Type" property? Or, can we assume
that the beginning of the message body (v=0 when we talk about SDP) will indicate
the type?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 May 2002 22:46:49 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland