John Bartlett wrote a short article about compatibility issues with B2B telepresence at http://www.nojitter.com/blog/archives/2009/02/business_to_bus.html, and I believe this topic deserves deeper analysis.
The article mentions Quality of Service as an issue for all types of telepresence systems that connect over the public Internet. I have some experience with the technology – I have been using Polycom HDX 4000 personal telepresence system in my home office for a while and can connect to the Polycom network via a video border proxy that resides in the De Militarized Zone (DMZ) of the closest Polycom office (San Jose, California). I can also place calls to other telepresence systems connected to the public Internet, e.g. a colleague of mine has one in Atlanta, Georgia.
The bad news is that the network performance is not predictable: sometimes I can connect at 1 megabit per second and enjoy high definition quality and sometimes I only get 512 kilobits per second which results in standard definition quality. On really bad days, I get mere 384 kilobits per second – luckily, the latest generation of video systems can deliver SD quality even over such low bandwidth. Internet distances are not like geographical distances, and I frequently experience high bandwidth (and high quality calls) to the other US coast (that would be the East Coast) or even internationally while getting lower bandwidth and quality on local calls. It all generally depends on the Internet usage during the call.
The good news is that my video system tolerates changes in the network conditions, and gracefully adjusts the quality (frame rate and resolution) to optimize the user experience. A video call that starts at 1 megabit per second (high definition) automatically becomes a standard definition call when the bandwidth falls to 768 kilobits per second, and goes back to HD when the available bandwidth increases.
There are ways to deliver QOS over the Internet by using two video border proxies back to back. I do not have one in my home office just because I like to have less boxes and cables and keep the place tidy but if you connect two offices, e.g. a main and a branch office of a company, you have enough networking closets to hide such equipment, and using VBP is recommended. The VBP assigns classes to the different type of traffic (voice, video, and data) and makes sure the real time traffic (voice and video) gets the appropriate priority through the Internet. I have some diagrams about that in the teleworking white paper, which is almost ready and will soon be published. Stay tuned!
John Bartlett also highlights the problem of signaling protocol incompatibilities and points out that Cisco and HP are destroying the balance created by standards (H.323, SIP) and interoperability in the video industry (Polycom, Tandberg, etc.). I think that HP Halo is less of a problem because it is just a single product/service that HP offers in the communication space. In my humble opinion, the desire to communicate with everybody else and the inherent disadvantages of using gateways will eventually drive HP to the standards camp. I am however concerned about Cisco because they have consistently tried to move customers away from standards and towards proprietary implementations, i.e. Call Manager. Starting with the Selsius Systems’ acquisition in 1998, they have been expanding their Call Manager ecosystem to include proprietary telephones and recently proprietary video endpoints that can only talk to Call Manager and to nothing else. I have already discussed the issue with proprietary implementation in my posting about collaboration tools for education: it creates an island in the communications market that cannot communicate with the rest. If you ask Cisco about standards compliance, they will tell you that they have gateways between Call Manager and H.323 or between Call Manager and SIP. They have been talking about their ‘interoperability’ (sometimes they use the word ‘compatibility’ but it does not really matter) since 1998. Nothing really came out of that. The gateways in question remain a demo for customers who need reassurance before investing in Cisco. Once customers install Call Manager and the deployment reaches critical mass, they have no other choice but to buy Cisco proprietary gear all the way. I have always wondered how companies with dual supplier purchasing policies or by the same token the federal government handle that. After 10+ years of Call Manager, does anyone out there still believe that Cisco is interested in interoperability with anyone but itself?
Anyway … John Bartlett then writes about the issues that only apply to multi-screen telepresence systems (mismatches of color temperature, audio, screen layout, image ratio, and eye contact lines). This issue is real and I have to say there is no good solution for it. Standardization bodies such as IETF and ITU-T are great at defining networking protocols but have no experience standardizing camera and microphone position, which is necessary to achieve true interoperability across multi-screen telepresence systems. There was a very heated discussion about that exact topic at the last IMTC meeting http://www.imtc.org/imwp/download.asp?ContentID=14027, and the issue is now getting visibility in the standards community.
I would be interested to get feedback from my fellow bloggers and followers on the issue of telepresence compatibility.
Net neutrality would only make the problem worse. It's a tough problem -- how does one guarantee QoS and still share the network with all other providers? It's finding a balance between optimizing the system considering any loading or capacity constraints, yet retaining flexibility on overall network performance.
ReplyDelete