Draft H.225.0 v4 - APC-1686

[Rich Bowen]

Well, this would make the change even "more" impossible - it would require
a change in the ASN.1 per each type of PDU, e.g.:

AccessRequest ::= SEQUENCE
{
     common         AnnexGCommonInfo,
     destinationInfo     PartyInformation,
     sourceInfo          PartyInformation OPTIONAL,
     callInfo       CallInformation OPTIONAL,
     usageSpec      UsageSpecification OPTIONAL,
     ...
}

Also it doesn't guarantee that the common part gets into every PDU that
will be invented in the future.

Well, that's ASN.1 and we have to leave with it.

Regards,
Lior





"Krishna Kr Banka" <kkbanka at HSS.HNS.COM> on 10/08/99 10:26:16 AM

To:   Lior Moscovici
cc:   "ITU-SG16" <itu-sg16 at mailbag.cps.intel.com>, "H323 Implementors"
      <h323implementors at imtc.org>, "Krishna Kr Banka"
      <kkbanka at HSS.HNS.COM>, "Chirag Vaidya" <cvaidya at HSS.HNS.COM>
Subject:  Re: Message Structure in H.225.0 Annex G




Hi Lior..!!

There seems to be yet another issue regarding the following :

> Since the "common" part includes the Sequence Number and other
information
> needed for lower level treatment of the message, this part should be
> decoded first, and the natural order should have been reversed. This is
> important since the size of the "body" is not fixed, and for cases in
which
> there is an error in the encoding of the body.

If the *common* part is placed above the *message-specific* portion, then
we
shall have a problem extracting the message type out of the encoded message
PDU. Since the common part contains fields such as : tokens, cryptoTokens,
nonStandard, which can be of variable length; the message-type cannot be
accessed without decoding the whole message.
One of the possibilities, in my opinion, is that the common part should be
made the first field of the message-body itself.

Regards
Krishna