Applications also need interoperability

By Tsahi Levent-Levi

Categories: Interoperability

May 1st, 2008

The IMTC’s SuperOp! event is just across the corner, and this time, I am proud to say that RADVISION will be hosting it (pdf). Companies coming to this event will be testing their products for interoperability. There are parts of the market though, that are ignoring interoperability. From my own experience, they pay dearly for it in due time.

Interoperability can be viewed as a process where you hurtle your product against a product of a different vendor and hope for the best. Since each developer reads and understands the standards differently, and each developer hides his own exotic bugs in his product, you will end up finding interoperability issues no matter how long you have been testing your product.

As interoperability is how close to the standard your implementation is, people tend to think that once you have a protocol stack that is interoperable – you’re good to go. If only it was true…

You can split interoperability into three different areas: protocol stack, codec and application. In each of these areas, you need to be interoperable.

Protocol stack

When it comes to the issue of interoperability, protocol stacks are easy. Interoperability assumes there is some kind of a basis for communication and that is, in turn, achieved by a protocol stack. The protocol stack implements the standard’s specification and needs to take care of interoperability against the standard.

Codec

Codecs are a bit more elusive than protocol stacks. They are also defined by standards, and as communication protocols these standards are getting more and more complex, making it harder to follow. To make matters worse, different protocols utilize codecs differently. To name a few differences:

• When SIP or H.323 use AMR, they use a different framing mechanism around this speech codec than the one 3G-324M requires.
• 3G-324M likes its video payloads smallish. RTP prefers the video payloads to be larger and closer to the MTU size.

This means that a codec needs to be tested in the context it is used in. It is not enough to test the codec alone – it must be tested as part of the system.

Application

The application is where it all comes together. The protocol stacks and the codecs are used with logic and a user interface glued on top. Usually, the leading vendors in a market segment will be taking their products to organizations such as the IMTC to test them for interoperability, while others won’t. Those that don’t, do that with a false assumption that an interoperable protocol stack is all they need. The moment they find that they are wrong, it will usually be at a customer evaluation, when it tends to cause the most harm – in such a scenario:

1. The protocol stack vendor will usually be unable to assist as the cause of the problem is on the application level.

2. The application vendor might need to add additional code into its application, which is not a good thing to do at the last moment.

3. The application vendor is experiencing the hardships of debugging interoperability issues – generating the correct log or saving the relevant bit streams might not come naturally to the developers doing it for the first time…

If you want to build a communication product that needs to work in a standardized world, and you are planning on becoming a significant player in your market, GO TO INTEROPERABILITY EVENTS. There’s one just two weeks from now, so see you there.