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
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
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.
Andrew cut his teeth as a systems administrator at the University of California, learning the ins and outs of server migration, Windows desktop management, Unix and Novell administration. After a tour of duty as a team leader for PC Magazine's Labs, Andrew turned to system integration - providing network, server, and desktop consulting services for small businesses throughout the Bay Area. With eWEEK Labs since 2003, Andrew concentrates on wireless networking technologies while moonlighting with Microsoft Windows, mobile devices and management, and unified communications. He produces product reviews, technology analysis and opinion pieces for eWEEK.com, eWEEK magazine, and the Labs' Release Notes blog. Follow Andrew on Twitter at andrewrgarcia, or reach him by email at firstname.lastname@example.org.