Decoding H.245 ASN.1 Extension Additions (Q62)

The information in this article applies to:

This article describes the basic requirements for decoding ASN.1 extension additions in H.245.

1. Introduction

H.245 version 1 is the base version for H.324, and version 2 is the base for H.323; however, H.245 is extensible and endpoints must be interoperable with subsequent versions of H.245.

In order to encourage interoperability with future versions of H.245, this document briefly describes the requirements for decoding ALIGNED PER ASN.1 extension additions. Of course, one must refer to X.691, "Information Technology - ASN.1 Encoding Rules - Packed Encoding Rules (PER)," for the complete, authoritative description.

2. Background

Apparently, all H.324 implementations other than ours currently use H.245 version 1. We started using version 2 in our H.324 terminal a few months ago and have noticed especially during the last two IMTC H.324 interoperability events that perhaps half of other vendors' terminals have problems decoding the ASN.1 extension additions present in version 2. In most cases, the problems were with hand-coded ASN.1 parsers. Ours is also hand-coded, but it has been validated with other H.324 terminals that correctly handle extension additions and through interoperability tests in our H.323 terminal

3. Basics

An endpoint must parse all extension additions. If they were added to a version after the one that the endpoint uses, the endpoint must simply skip over and ignore them. The endpoint cannot assume that just because it identified the H.245 version that it uses in the protocolIdentifier component of the TerminalCapabiltySet message that the other endpoint must refrain from sending any messages containing extension additions that were added since the indicated version. An immediate problem with this is that the TerminalCapabiltySet message containing the protocolIdentifier may also contain unexpected extension additions, so an endpoint must always ignore unexpected extension additions.

An endpoint must represent all sequence extension additions for the version of H.245 that it supports--it cannot leave the ones out that it does not feel are useful, that the vendor has not gotten around to implementing, or that it knows that the receiver will not recognize. The reasoning behind this is described in the next paragraph.

Annex A/H.245 defines the value of the H.245 Object Identifier: "This Object Identifier is used to indicate the version of this Recommendation in use as a multimedia system control protocol." Section 6/H.245 "specifies the syntax of messages using the notation defined in ASN.1" for this version of H.245. Taken together, these statements say that the Object Identifier indicates which version of the H.245 ASN.1 syntax is used by an endpoint. Further, H.245 specifies the use of X.691, which describes the ASN.1 packed encoding rules (PER), and 18.7/X.691 says, "Let the number of extension additions in the type being encoded be 'n', then a bit-field with 'n' bits shall be produced for addition to the field-list." This means that all of the ASN.1 extension additions in the version of H.245 that the endpoint uses shall be represented by the encoder. The word, "represented," is used here in place of "encoded," because, for example, the value of an extension addition marked OPTIONAL may not be present and therefore not encoded, but the extension addition is still represented in the PER extension-addition count and bit-field, with the bit at the corresponding position in the bit-field set to zero.

A receiver may therefore treat an unrepresented extension addition that is defined in the version of H.245 that the transmitter uses as an application semantic error. However, in order to do this, the receiver must support the same or a later version of H.245 as the transmitter; otherwise, it would not be able to detect that a particular extension addition is not represented.

When an endpoint sends a message containing one or more extension additions that the receiving endpoint does not recognize, such as a command, request, or capability that is not in the extension root, the transmitting endpoint shall not expect behavior from the receiving endpoint based on those extension additions. This is, of course, because the receiving endpoint ignores unexpected extension additions. Since an endpoint is required to represent all extension additions that are defined in the version of H.245 that it uses, it must know that any behavior on the part of the receiver is not based on the unrecognized extension additions. For example, if a version-1 endpoint acknowledges an open request containing version-2 extension additions in the data type, the originating endpoint must understand that the receiver acknowledged the request without considering the values of the unrecognized extension additions. The originating endpoint must then act accordingly, in this case, as if it sent a version-1 open request. This also means that the receiver shall not consider the presence of unrecognized extension additions when deciding what action to take, such as whether to acknowledge or reject an open request--the onus is on the originator.

4. Open type fields

Choice and sequence extension additions are both encoded as an open type field, so the open type field can be explained independently. An open type is basically a length field followed by the octet-aligned data that it contains. The length field contains the number of data octets and is encoded as an octet-aligned unconstrained length determinant. It exists solely for systems that recognize an earlier version of the ASN.1 syntax tree so that they may easily skip over unexpected extension additions. Since the data that an open type field contains is octet-aligned and padded out to the next octet boundary, the ASN.1 field that immediately follows an open type field is inherently octet-aligned.

5. Decoding choice extension additions

Whether an extension addition is present for a choice type that has an extension marker, e.g.,

distribution CHOICE
{
    unicast NULL,      -- Alternatives that lie
    multicast NULL,    -- within extension root
    ...,               -- Extension marker
    myarmsinacast NULL -- Not within root
}

is encoded as a 1-bit field. If set to 0, an extension addition is not present; if set to 1, an extension addition is present. Whereas the choice index for a chosen alternative that lies within the extension root is encoded as a constrained integer, the choice index for a chosen alternative that does not fall within the extension root (an extension addition) is encoded as a normally small non-negative whole number with lower bound of 0.

The extension addition is encoded following the choice index as an open type field (see section 3). Even if there are no fields for the chosen alternative, as in the case of a NULL choice, an open type is still encoded but with a single octet of 0 and a length of 1. The decoder should not care whether there are zero, one, or several octets, though--if it recognizes the chosen alternative, it decodes the contents of the extension addition, possibly ignoring the length field entirely; if it does not recognize the extension addition, it skips over the specified number of octets and continues decoding.

6. Decoding sequence extension additions

Decoding sequence extension additions is a little trickier because there may be several extension additions in the sequence type, only some of which are recognized by the decoder (the first N), and some extension additions may be optional.

Like the choice type, whether there are any extension additions defined for a sequence type that has an extension marker, e.g.,

H263VideoMode ::= SEQUENCE
{
    resolution CHOICE
    {
        sqcif NULL,
        qcif NULL,
        cif NULL,
        cif4 NULL,
        cif16 NULL,
        ...
    },
    bitRate INTEGER (1..19200), -- units 100 bit/s
    unrestrictedVector BOOLEAN,
    arithmeticCoding BOOLEAN,
    advancedPrediction BOOLEAN,
    pbFrames BOOLEAN,
    ...,
    errorCompensation BOOLEAN
}

is encoded as a 1-bit field. If there is an extension marker, the 1-bit field is the first field of the sequence-type encoding and not the last field following the extension root, where one might have expected it to be because of the location of the extension marker in ASN.1 syntax. If set to 0, there are no extension additions; if set to 1, there are one or more extension additions, although some optional extension additions may in fact not be encoded because they are missing. Sequence type extension additions follow the extension root (at the "bottom" of the encoding).

If there are extension additions, the number of extension additions is encoded as a normally small length determinant with lower bound of 1. This is the number of extension additions defined for the version of H.245 that the encoder supports and not just the ones that are required plus the ones that are optional and present. In particular, this number includes the extension additions that are optional and missing. For example, there are four extension additions in the following sequence regardless of whether d and f are present.

Foo SEQUENCE
{
    a INTEGER (1..256),
    b INTEGER (1..256),
    ...,
    c INTEGER (1..256),
    d INTEGER (1..256) OPTIONAL,
    e INTEGER (1..256),
    f INTEGER (1..256) OPTIONAL
}

Note that unlike the choice index for a choice type extension addition, this number-of-extension-additions field is not necessarily octet-aligned.

A bit-field is encoded next with "n" bits equal to the number of extension additions, described above. This is a bit map where each bit position indicates whether the corresponding extension addition is encoded. The first bit in the bit-field corresponds to the first extension addition, the second bit corresponds to the second extension addition, etc. For an extension addition that is not defined as optional, e.g., c and e, above, the corresponding bit is always set to 1; for an optional field, e.g., d and f, the corresponding bit is set to 1 if the extension addition is present and 0 if it is missing.

For example, if d is missing for the sequence type, above, but f is present, there are four extension additions and the bit-field would be encoded as 1011. Encodings for c, e, and f would follow as open type fields. As another example, if d and f were both missing, there are still four extension additions and the bit-field would now be 1010. Specifically, trailing optional-but-missing sequence type extension additions must be represented in the number field and the bit-field. For this last example, an encoder cannot simply consider that there are just three extension additions, ignoring the trailing optional-but missing field, f, and encode the bit-field as 101.

Finally, the extension additions are encoded as open type fields (see section 3) in the order in which they are defined. Unlike a NULL chosen alternative that is not in the extension root, if an optional sequence type extension addition is missing, it is not encoded as an open type field of length 1 (or otherwise).