Packetizer Logo
 

Interoperability and Compliance Rant (Q99)

The information in this article applies to:

Interoperability among so-called H.323 entities is different than H.323 compliance. In the strictest sense, all (true, compliant) H.323 entities are interoperable. If a test suite existed that determined full compliance, all passing entities would be inherently interoperable and interop events would be unnecessary. Interop events are only necessary when one or more of the following occur:

If contributors to the standards do a good job, the first can be minimized and the second eliminated. If vendors do a good job, the third can be eliminated. The more useful vendors find the interops, the worse job contributors and vendors are doing writing the standards and implementing products, respectively.

To say that an entity is H.323-compliant means that it completely embodies the particular version of the H.323 Recommendation it implements. Assuming that contributors to the Recommendations continue to properly use the inter-version compatibility features, such as ASN.1 extensions and protocolIdentifier fields, and admonitions, such as ignore components defined in subsequent versions and know that some components will be ignored, each version of the H.323 Recommendation is backward compatible. The result is that all H.323-compliant entities are interoperable with all other H.323-compliant entities. (This is also why a vendor should never reject a connection from an entity based on its version. I've seen this happen a few times, but it is simply unnecessary.)

By "interoperable," I don't mean that entities encode and recognize the exact same ASN.1 components. I mean that a call is established, audio is exchanged, and the call is terminated. Any differences in functionality are gracefully handled through existing facilities in H.323. For example, I don't know what it means for an H.323v1 entity to be compliant with an H.323v2 entity. If they are both compliant, they are interoperable.