Upload of APC-1773

[Callaghan, Robert]

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 at INTEL.COM]
> Gesendet am:  Friday, April 28, 2000 19:04
> An:   ITU-SG16 at 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 at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com