Interoperability Problems due to Open Type encoding of Null types
mpaul at TRILLIUM.COM
Wed Jan 17 18:13:47 EST 2001
We have come across a specific problem which has been the root
cause of interoperability failures across different implementations
of H.323 stack. The problem is related to the
1) Encoding and decoding of NULL data types when they appear as
2) Encoding and decoding of extension IEs which have NULL as the
outermost ASN type.
There have been different interpretations of the PER rules that apply
to the above conditions causing interop failures at encode/decode level.
Although the implementations would encode/decode (1) and (2) according
to Open Type elements, some subtle differences come as mentioned below:
In case of (1), some implementations would not encode an extra 0x00
octet for NULL data type and would just encode the length of the open type
element as 0x00. This idea probably stems from the fact that a NULL
data type has no encoding when they appear in the root of the ASN.1 type.
However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for
such a case would be 0x01 0x00, where 0x01 is the uncosntrained length
of the NULL data type encoding and 0x00 is the value of NULL data type in
In case of (2), some implementations would encode the extension IE as per
it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for
the outermost NULL data type in it's encode tree. This would change the
value of length field to be appended to this open type. Whereas some
implementations do add 0x00 octet for the outermost NULL data type.
There appears to be a confusion as to what is meant by the "outermost"
value in 10.1.3 of X.691. I would appreciate clarification on this
clause as it would save a lot of interop overhead at encode/decode level.
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd