Subject: [Megaco] Reg Annex C Text Encoding - Property IDs

From: "Arvind Charanyan" <[email-masked]>
Date: Wed, 11 Jul 2007 17:06:59 +0530

Hi,

I need some clarifications with regards to the Annex C of H.248.1
Version 3 Specifications which talks about the text encoding of Annex C.

"Referencing of Annex C properties follows the PackageID/PropertyID
structure; however Annex C

is not in itself a package. Annex C is considered to have PackageID
0x0000 for binary encoding and

"anxc" for text encoding. For text encoding of H.248.1, Annex C shall
only be used if the required

property is either not defined by a package or not represented by SDP.
The nesting of one Annex C

property inside another is forbidden."

For a package, the property IDs are usually unique, which enables us to
map each value to a particular property.

But when we consider Annex C as a package, there are certain properties
which are present in more than one section of Annex C. For example, the
property ID "BIR" is present in General Bearer Properties, ATM AAL1 and
ATM AAL2. But when we refer to the property by anxc/BIR, we would not
know exactly which section this property refers to. Whereas in ASN, we
would know which section BIR Property is being referred to, since the
property tags are unique. 

Does this inconsistency need to be taken care of? Please clarify.

Also, some of the propertyIDs in Annex C do not follow the propertyID
conventions as described in Annex B. For example, in C.1, "Transmission
mode" , "Number of channels", "Sampling rate"  have spaces in between in
their property IDs. But in ABNF text encoding of protocols, the
propertyID can consist of ALPHA, DIGIT or "_". 

Please clarify this point also and recommend suitable property IDs for
these properties.

Snip from ABNF below - 

pkgdName = (PackageName SLASH ItemID) ;specific item

/ (PackageName SLASH "*") ;all items in package

/ ("*" SLASH "*") ; all items supported by the MG

PackageName = NAME

ItemID = NAME

NAME = ALPHA *63(ALPHA / DIGIT / "_")

Thanks and Regards,

Arvind 

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 31 Jul 2007 16:08:07 +1000

Hello Arvind,

Annex C was primarily designed for the binary encoding of the protocol. 
Therefore the "propertyID" text in the tables was largely informational. 
For the binary encoding the "property tags" are used which ensure the 
values are unique. It was later seen that it could be used for text 
encoding via H.248.15, that's when it was assigned the package id anxc.

So as the text suggests you should look at items defined by SDP first 
instead of using Annex C for text encoding. For example for BIR you 
should instead use the EECID element from the ATM SDP RFC.

For those other tags with spaces in the property names if you really 
must use them then the safest probably would be to remove the spaces 
from the names e.g. Transmission mode becomes Transmissionmode.

Regards, Christian

Arvind Charanyan wrote:
> *“Referencing of Annex C properties follows the PackageID/PropertyID 
> structure; however Annex C*
>
> *is not in itself a package. Annex C is considered to have PackageID 
> 0x0000 for binary encoding and*
>
> *"anxc" for text encoding. For text encoding of H.248.1, Annex C shall 
> only be used if the required*
>
> *property is either not defined by a package or not represented by 
> SDP. The nesting of one Annex C*
>
> *property inside another is forbidden.”*
>
> For a package, the property IDs are usually unique, which enables us 
> to map each value to a particular property.
>
> But when we consider Annex C as a package, there are certain 
> properties which are present in more than one section of Annex C. For 
> example, the property ID “BIR” is present in General Bearer 
> Properties, ATM AAL1 and ATM AAL2. But when we refer to the property 
> by anxc/BIR, we would not know exactly which section this property 
> refers to. Whereas in ASN, we would know which section BIR Property is 
> being referred to, since the property tags are unique.
>
> conventions as described in Annex B. For example, in C.1, 
> “Transmission mode” , “Number of channels”, “Sampling rate” have 
> spaces in between in their property IDs. But in ABNF text encoding of 
> protocols, the propertyID can consist of ALPHA, DIGIT or “_”.
>
> Snip from ABNF below –
> * *
> *pkgdName = (PackageName SLASH ItemID) ;specific item*
>
> */ (PackageName SLASH "*") ;all items in package*
>
> */ ("*" SLASH "*") ; all items supported by the MG*
>
> * *
>
> *PackageName = NAME*
>
> * *
>
> *ItemID = NAME*
>
> * *
>
> *NAME = ALPHA *63(ALPHA / DIGIT / "_")*
>
> Thanks and Regards,
>
> Arvind
>
> ------------------------------------------------------------------------
>