H.323 experts,
The ASN.1 code for H.450.2 contains the following structure: "argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL," duplicated inside many larger structures such as CTInitiateArg, CTSetupArg, CTIdentifyRes, CTUpdateArg, SubaddressTransferArg, etc.
Feeding the code as is into the ASN.1 compiler will result in multiple _choice structures (_choice1, _choice2, _choice3, etc.) for the same exact structure: "CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL"
We can do some optimization and save some code (desperately needed for embedded platforms) by modifying the ASN.1 code and defining a new structure as follows: ExtensionASN ::=CHOICE { extensionSeq ExtensionSeq, nonStandardData NonStandardParameter }
And use ExtensionASN structure in all the CTXArgument structures that use the above structure, for example: CTInitiateArg ::= SEQUENCE { callIdentity CallIdentity, reroutingNumber EndpointAddress, argumentExtension ExtensionASN OPTIONAL, ... } Since implementers should not touch the ASN.1 code on their own and the H.450.2 document will have to go through the ITU process of producing a new revision to have a fix like this, my questions are: Does anyone see any problem with this optimization? Will a modification like this have any effect on bits going on the wire (it shouldn't)? Can this proposal break backward compatibility? Is there a compelling reason for writing the structures the way they are in the H.450.2 document?
Thanks for all your responses Hani ElGebaly
Intel Corporation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com