The Isolated Worlds of Video Conferencing
I participated in a unified communications panel at InfoComm about three years ago. It was a great panel with representation from companies like Cisco, Polycom, and (the now defunct) Tely Labs. I was the oddball of the bunch; promising the audience that a focus on software to improve proximate meetings was needed at least as much as a focus on meetings with remote participants. The panel was fun and ended with some real fireworks as a theme of audience questions began to emerge — interoperability. Audience member after audience member pointed out that while all the video conferencing providers claim interoperability, it is simply too expensive, complex or terrible user experience to make it worthwhile. I won’t say the audience had pitchforks and torches, but it felt like the panel was under attack from an angry mob.
I didn’t think much of it at the time. We were so focused on getting Solstice launched that I purposely avoided thinking too much about the remote user use case — until now. About a year ago, I began to study the unified communications space. I interviewed customers all over the world, met with the analysts, and even have written a few SIP/H.323 socket-based applications. What I learned is that the number one problem in video conferencing is not the video conferencing software itself. It all works well and has matured to the point that the user experience can be quite enjoyable. The problem is that we’ve built a global communications network that’s a set of hard silos.
We’re in a world where IoT devices use well-known protocols to talk directly to one another (e.g., CoAP, MQTT) and WebRTC allows direct browser-to-browser video, but most of the major video conferencing applications require backflips to call one another. Customers report this issue as their number one problem with video conferencing.
The very act of installing a video conferencing meeting room requires a considerable level of commitment to a single vendor. I’ve experienced it myself in my own office. I installed a SmartDock and connected it to my display. I thought it would be a great way to communicate with partners. The first call on my calendar popped up a message “Please tell the organizer to make this a Skype meeting.” This is akin to owning an iPhone that can only call other iPhones. A Samsung user calling an iPhone would get a message “Tell the iPhone user to buy a Samsung.” Oh boy.
This reluctance to work together is understandable — each of these companies is vying for a fixed number of video conferencing endpoints. Why enable your competitors?
Who remembers Louis-Francois Breguet’s Dial Telegraph — a simpler to use competitor to Morse code? Even as late as 1920, Bell Telephone resisted moving to automated switching because they, in part, wanted to control the endpoint-to-endpoint experience for their customers rather than create a uniform, interoperable network.
Of course, there has been plenty of thought that has gone into interoperability. I don’t mean to come across as facetious, but I want readers to appreciate the scope of this problem. Why? Because problems this big in the technology landscape mean there may be cool solutions — ones that just haven’t been looked at before and may be disruptive. Companies like Pexip have, to their credit, focused on interoperability and standards-based routing for quite some time. Even BlueJeans, when Steamboat Ventures were first funding it, promised an escape from a single codec by focusing on cloud interoperability, but they’ve also become one of the many silos.
If I need to invite a WebEx user to my Zoom meeting — that’s possible. You do need to use a third-party connector service like Polycom RealConnect, Pexip, WebEx CMR or GTM InRoomLink. And, here’s the rub, you have to do something different than you would otherwise to connect using the same system.
It’s harder (and different) to do the inverse. Joining a WebEx meeting from Zoom takes several steps. Take a look at how Zoom instructs users to do this. Cisco recently introduced a USB pass-through mechanism that supports users who want to take advantage of a WebEx room with a different codec on their laptop and I applaud the move. This is an example of a big company caring about the user experience over competitive strategy. But this is the exception and not the rule.
If video conferencing were truly interoperable, we’d be in a lot more calls where participants are joining using whatever they want to connect. About one-third of the world’s meetings include remote participants. This explains why my laptop has about four different soft codecs installed. We should do something about this. I know I am going to start thinking about how best to address what may be one of the world’s biggest user-experience technology letdown. Users should be able to enter any room and use the codec that is going to be used for the meeting regardless.
Here are the two problems I’ll focus on:
- Dedicated room systems require the room system to commit to a codec.
If I want to use Zoom one day and Microsoft Teams the next, my video conferencing room should support it. While third-party connectors exist and work well when they are configured and pre-installed, there is a cost involved, there can be complexity issues, and they do nothing for enterprises that cannot afford to deploy a connector service.
- The user experience is inconsistent when using various codecs in rooms where they aren’t intended.
Taking a GoToMeeting call in a Zoom Room? Forget about it. Taking a Microsoft Teams call in a Zoom Room? Participants must follow four additional steps to get the room bridged to Zoom. This simply is not what users want, and we should strive to build a room that presents a uniform front end regardless of the codec.
I know some of my readers are probably smiling because I was so tenaciously focused on the in-room experience for so long, but now it’s clear that we as an AV community need to look at the wholistic meeting experience and that includes remote users on whatever codec they want to use that day.
This column was reprinted with permission and originally appeared here.