eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Differentiation Leads to Lack of Interoperability
Vendors have done significant work to differentiate their implementations, particularly to bring HD video and audio to the fore and create innovative ways to use less bandwidth to deliver that quality. However, this differentiation contributes to a lack of interoperability.
Take, for instance, Radvision’s recent announcement that it will be implementing H.264 SVC (Scalable Video Coding) in forthcoming versions of its Scopia conferencing equipment and desktop client software. SVC adds a multilayered element to the H.264 standard, effectively creating a thin base layer of content to which additional layers can be added to boost resolution, video quality and frame rate. That way, in lossy networks, the base layer can be more easily transmitted to provide a smooth, glitch-free transmission at a base quality level, with enhancements added as possible given network conditions.
Although SVC was ratified as part of the H.264 standard a few years ago, issues surrounding signaling have yet to be agreed upon, so don’t expect interoperability with any of the few other SVC-capable products available today (such as those made by Vidyo). However, Radvision does promise that its SVC-enabled systems will continue to interoperate with other vendors’ gear that supports the regular H.264.
Of course, the testing scenario I pursued here is rather simplistic when considering business use cases. Point-to-point connectivity between two video conferencing room systems will have its place, but meetings will more often than not need to have multiple participants attending from many locations. In my tests, I was able to simulate some of that perspective-conferencing a total of four endpoints together (via LifeSize Room 200’s six-party Multipoint Control Unit).
But as video needs grow, more room systems need to join a meeting or desktop video clients need to be pulled into the mix, video conferencing customers will need to look into purchasing stand-alone MCU devices. These devices may come in the form of hardware, like Radvision’s Scopia conferencing platforms, or they may come as software to be installed on commodity server hardware, like Avistar Communications’ Avistar C3 Conference. But it falls to the vendors of these MCU devices to ensure interoperability at native resolution with as many endpoints-be they room or desktop solutions-as possible.
Of course, in a case where many partners have similar small-scale video conferencing initiatives, the question becomes one of who will pay for the MCU through which everyone can join the conference. Thankfully, there are some hosted MCU solutions available in the cloud that can provide that service for a fee.
Senior Analyst Andrew Garcia can be reached at agarcia@eweek.com.