eWEEK Labs Tests Interoperability of Video Conferencing Systems

Video conferencing is traditonally touted as a money-saving technology in a down economy. Companies can slash their travel budgets by using video conferencing, but meeting with partners and suppliers outside of your own network requires interoperability of video conferencing systems. eWEEK Labs tests the ability of two very different systems to work together.

In a down economy, video conferencing makes a lot of sense economically. Companies can slash their travel budgets, redirecting some of that money to the acquisition of room-based or desktop conferencing solutions that allow parties to "meet" and share presentations while still being able to read participants' body language and facial expressions (video quality permitting).

But what happens when you want to extend these video conferencing capabilities outside of your own network-to pull partners, customers or suppliers into the mix? It is unlikely that you will want to spend your own capital budget to outfit partners with a solution known to work with your equipment. But as your partners are facing the same economic pressures as your organization, they quite possibly may also be considering the technology.

The question then becomes one of interoperability between systems purchased at different times from different vendors. The legacy perspective was that disparate video solutions don't play nicely together. But codec utilization and signaling have become more standards-based, and video conferencing purveyors have pursued partnerships with other vendors to plug holes in their product portfolios.

These moves should result in improved interoperability, but has that really been the case?

With these conditions in mind, I set out to test interoperability of video conferencing systems, at least on a small scale. My interoperability goals were modest, but would likely reflect the goals of two companies that wanted to take advantage of video conferencing to do business together. The plan was to take a pair of room-based conferencing systems from different vendors-acquired by the companies separately, without consultation-and get a video conference going between the two. Voice and video would be a must, as would data presentation sharing. Anything else would be gravy-at least for the short term.

In the end, achieving interoperability between disparate systems was easier than I thought it would be.

I conducted the interoperability test between two recent-model conference room solutions: the LifeSize Room 200  and Polycom's QDX 6000.

The two products are aimed at different market segments: QDX 6000 is significantly cheaper than Room 200 and is aimed at smaller offices or businesses; the Room 200 unit offers a full high-definition experience and packs in additional features that allow the host to extend the conference to more than one other party. That said, there is certainly a good chance that the two products would meet out in the world-for example, as a larger business tries to hold a conference with its customers or suppliers.

Room 200 supports both SIP (Session Initiation Protocol) and H.323 for signaling, while QDX 6000 supports H.323. The vendors of both products market claims of interoperability, and I felt it was warranted to test those claims.

While I assumed it would take some tweaking to get the units talking to each other via H.323, the products connected right away. The units automatically negotiated mutually supported audio and video codecs-in this case, H.264 at 708 by 480 resolution with G.722 audio. While these settings were inferior to what either product could optimally achieve, the video conference did work.

Likewise, I found H.239-enabled data presentation sharing worked in both directions, and I could control movement of the far-side camera for either product. Also, because both units support H.235 AES (Advanced Encryption Standard) encryption, I was able to secure the call payload between the two products.

I suspect that most companies trying to get a couple of products (recently released ones, at least) to interoperate will find the same thing. Everything works, but perhaps not optimally. Given the specifications of the two products I tested and their supported resolutions, the video resolution during my tests was about what I expected it to be, although I expected audio to instead utilize the mutually supported Siren 14 audio codec. Although the codecs in use in today's video conferencing gear are based on standards-or, failing that, are commonly implemented-the signaling for those codecs may not yet have the same level of standardization.