Here’s a slide we’ve shown in some of our webinars last year:

Why am I at this subject again? Mainly because of a tweet by Blair Pleasant:

#enterprisecon: Jim says stds don’t create interop – customers need to push vendors to work on interoperability. #ucoms

And Jim is of course correct – standards by themselves won’t give you interoperability. These are two separate things, which are both important.

A standard is only the beginning of the solution – and that, only when it becomes stable enough. At some point, human nature kicks in, with its not-so-deterministic interpretations. Here’s an example that might explain it (skip it if you hate technicalities).

H.323 uses ASN.1 to define the messages, and uses PER to encode the messages when it needs to send them over the network. Now PER is rather aggressive in the way it encodes stuff – it tries to get messages to a place where they are small enough. So in PER, most Boolean fields will take only a single bit of data. PER is also realistic, and tries to be nice to CPUs, so if you are trying to encode a string value, it will usually make sure it will begin to encode the string when it is aligned on a byte boundary. This causes bits to be skipped to get things aligned properly. And the question is – what should be the value of skipped bits?

It turns out the standard wants these bits to be 0s, even though nobody cares about their values. It also turns out that our PER decoder didn’t really care what the value is – as it has no meaning. This of course caused our PER encoder not to care, which meant that sometimes, these bits sometimes got the value of 1 instead of a 0. No harm done.

At least not until a few years ago, a customer complained that he can’t communicate with some device from another company. And the reason was the adamant requirement of that piece of equipment to have these bits as 0s. So we fixed it, and all is well.

But this is only one example on the message encoding level.

In real life we’ve dealt with interoperability issues on multiple levels where the problem was the way different vendors interpret the same standard:

• The operating system level, where different OSs behave differently killing your interoperability though maintaining standard support
• The transport level, where sockets and IP addresses are used
• The message encoding level, as the above example shows
• The signaling level, where the protocol’s base logic is implemented
• The media side, where both the codecs and the framework above them can cause problems
• The application logic, where everything comes together

So yes – follow standards. But make sure you invest enough in interoperability. If you won’t, then what’s the point in saying you are standard compliant?