H.450.1 ASN.1 interoperability issue

Mark Brown Mark.Brown at ED.ACULAB.COM
Fri May 10 11:29:11 EDT 2002

We've been experiencing some fairly serious interoperability problems
with some systems due to confusion over what exactly the ASN.1 for
H.450.1 is and were hoping someone could clarify things for us.  The
problem stems from section of the V4 implementors guide which
adds a note below table 4:

   In the Invoke APDU, the invokeID is an INTEGER constrained by a
   PER-visible constraint (InvokeIdSet = 0..65535) and is therefore
   encoded as a *constrained* INTEGER (16 bits, no length field).  In
   the ReturnResult and ReturnError APDUs, however, the invokeID is
   encoded as an *unconstrained* integer (with explicit length field)
   because the applicable constraint... is not PER-visible.

However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be:

   InvokeIdSet     INTEGER ::= {InvokeIds,...}
   InvokeIDs   ::= INTEGER (0..65535)

which does not gel with the text in the IG and causes interoperability
issues since the two versions of the ASN.1 for InvokeIdSet are not
encoded identically.  This text appears to be unchanged from the
prepublished edition on Packetizer.

Our understanding of the text added in the IG is that the intent was to
emphasise that the encoding of the invokeID is not consistent between
the various APDUs and that the no change to the ASN.1 was intended.
This is particularly the case since the IG doesn't modify table 3 as
would be expected if it were correcting the ASN.1 there.  Others read
things differently and are using the definition of InvokeIdSet given in
the IG.

What is the intention here?  If the intention is to redefine the ASN.1
then some clarification as to why this was done would be very much

More information about the sg16-avd mailing list