Hani,
Please consider that a similar modification has been made to the H.450.x standards beginning with H.450.4. We did not change the H.450.2 and .3 in order to guarantee backwards compatibility.
Beginning with H.450.4 the MSI information to standardized opertations are defined as SEQUENCE SIZE (0..255) OF MixedExtension. MixedEntension type is then defined as any combination of H.225.0 like nonStandardParameter type of extensions and ROS Object class extensions.
Regards, Karl
-----Ursprüngliche Nachricht----- Von: El-Gebaly, Hani [SMTP:hani.el-gebaly@INTEL.COM] Gesendet am: Friday, April 28, 2000 19:04 An: ITU-SG16@mailbag.cps.intel.com Betreff: H.450.2 ASN.1 related
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com