Pekka Pessi wrote:
The issue prevents interoperability between software using H.225.0 version 2 and software using any version, it should be solved before any version 2 devices are released.
I have raised the issue of compatibility between versions here before, but nobody except me seems to think that it will be a problem. Time will tell.
However, there is a serious problem: the canonical representation changes if the ASN.1 SEQUENCE type is extended later.
Correct, a SEQUENCE type must be defined as extensible starting with the first version in which it is defined if it is felt that it may need to be extended in the future. Once a SEQUENCE type is defined to be NOT extensible (there is no extension marker present), it cannot later be extended without changing the encoding. For example, the ICV type can never be extended.
PER Encoding of an Extended ASN.1 SEQUENCE
In the PER encoding of extensions to SEQUENCE types, the encoder first encodes the number of extensions as a normally small non-negative integer, then a bit field with one bit for each extension followed by the extensions itself (bit is one if the extension is present, zero if not). The encoding of each extension is preceded by the length of their encoding in octets.
Now, if the sender A uses following ASN.1 definition for a SEQUENCE
Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL }When encoding this, the length of extension bitfield is 2. However, recipient B is using extended version of Foo like this:
Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL }B decodes the Foo, removes ICV and encodes the packet again. In the resulting encoding, the length of extension bitfield is 3, and the ICV that B regenerates is different that A generated and sent to B. B is not able to interwork with systems using earlier version of the ASN.1 spec.
Why not? This is precisely what the H.225.0 and H.245 protocolIdentifier is for--to indicate which version of the Recommendation the endpoint supports. An endpoint must know what protocol versions the remote terminal supports. For example, if an H.225.0v3 endpoint communicates with a v2 endpoint, it knows that the v2 endpoint will not recognize any of the extensions added since v2 and shall not therefore depend on any v3 behavior on the part of the v2 endpoint. Likewise, the v2 endpoint must be able to treat all v2 and subsequent endpoints as a v2 endpoint. Basically, an extension cannot be added to the ASN.1 syntax of a Recomendation that changes the semantics of the fields defined in the previous version of the Recommendation. If this is done, we will have serious interoperability problems.
ASN.1 Compilers Don't Grok Unknown Extensions
There are also problems because the way some ASN.1 compilers behave. Using our previous example, when A receives Foo with the importantExtension field from B, A has somehow to include the value when it is re-encoding Foo in order to calculate the ICV.
I can't think of a situation where a terminal would ever have to re-encode. Are you referring to a GK or GW?
However, it may be very hard to present an value of an unknown extension to the ASN.1 encoding functions.
We use our own ASN.1 codec, so this isn't a problem for us.
Problems with Non-OPTIONAL Extensions
Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL extensions. Let us assume that software C uses following ASN.1 definition for Foo:
Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType }There are two kinds of problems with an extension like criticalExtension. First, the encoder may try to ensure that all encoded PDUs conform to the specification and signal an error when a PDU without criticalExtension is encoded.
IMO, this is correct behavior.
Another problem is that the intermediate representation produced by the ASN.1 compiler may not provide means for application to express that criticalExtension is not present. (In other words, the produced structure usually contains a flag telling whether an optional field is present or not. Such flags are not included when the field is not optional.)
This makes sense to me because all version-N extension additions must be _represented_ in the encoding if you are a version-N implementation, and extension additions that are not optional must also be _present_--their value must be encoded. Optional extension additions are always represented by their corresponding bits in the bit field; if they are present, their value is also encoded.
The presense or absence of the OPTIONAL flag in an extension does not change the PER encoding of the SEQUENCE. In order to avoid previously mentioned problems, application may use a version of ASN.1 notation that has extra OPTIONAL keyword after each extension.
Some extension additions are defined as OPTIONAL and some not, presumably for a reason. Indicating that a non-optional one is not present would produce an encoding with a semantic error, while not an encoding syntax error, per se.
Solution 1: Clarification to the PER Encoding Process
The text in PER document (X.691, 1994) is somewhat ambiguous how many bits should be included in the extension present bitfield of SEQUENCE. To quote verbatim: "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." (Is the "type being encoded" the abstract syntax or an actual value like { bar 1, baz 2 }?)
If you'll notice, X.691 is very careful about its use of "type" and "value." Specifically, "abstract syntax value: A value of an abstract syntax (defined as the set of values of a single ASN.1 type), which is to be encoded by PER, or which is to be generated by PER encoding." I am sure that X.691 is referring to, in our case, the ASN.1 syntax defined in the version of the Recommendation identified by the protocolIdentifier.
However, the 0 bits at the end of extension present bitfield can be left out without changing the resulting semantics: the corresponding extensions are not present. As a result, the PER encoding does not change after a new extension is added to the ASN.1 specification.
Syntactically, one could leave out the last N extension additions (regardless of whether any are OPTIONAL, they are still represented in some way); however, this would result in a semantic error because "a bit-field with 'n' bits" was not "produced" where "n" is "the number of extension additions in the type being encoded." Just as with a field in the extension root, one may not simply choose to not encode an extension addition that is defined in the version of the Recommendation that you identify in your protocolIdentifier field.
This solution, while leaving H.225.0 v2 protocol as it is, requires however changes to some existing ASN.1 compilers, and in a pessimal case, to the X.691 standard text, too.
I see know reason to modify compilers or X.691. If one obeys the rules, everything works. Clarification text may be needed, however.
-- Paul Long Smith Micro Software, Inc.