Subject: [Megaco] Octet String Encoding

From: "Rajeev K R" <[email-masked]>
Date: Tue, 14 May 2002 12:34:19 +0800

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

---

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

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 15 May 2002 13:24:18 -0400

Actually, I think I prefer to rename the production.  There is already a
comment before the Local and Remote productions that indicate that
octetString is only used for SDP.  Also, there is already a comment before
octetString that indicates that it is used to describe SDP.  Do we really
need more comments?

What is wrong with renaming the production to something like SDPString?  The
only other productions it will affect are localDescriptor and
remoteDescriptor.  This should be a fairly easy change to implement.

Kevin

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 1:13 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'Christer Holmberg'; Rajeev K R; Megaco
Subject: Re: [Megaco] Octet String Encoding

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