Subject: Re: [Megaco] Octet String Encoding

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 May 2002 15:58:49 +0300

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 May 2002 15:58:49 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

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

Hi,

Thanks and Regards,
Rajeev

---

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

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

---

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

Hi,

Good :)

That is incorrect.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Rajeev K R" <[email-masked]>
Date: Wed, 15 May 2002 15:01:10 +0800

Hi,

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

following:
"Hexadecimal octet coding is a means for representing a string of octets as

The SDP string we are discussing is part of localDescriptor  or
remoteDescriptor.
So it becomes applicable here...

Regards,
Rajeev

---

From: "Rajeev K R" <[email-masked]>
Date: Wed, 15 May 2002 15:01:10 +0800

Hi,

Regards,
Rajeev