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(a)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(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
