WebRTC: What Happens After the Hype?

[Ashan Willy (ashan_willy)]

One of the key goals of visual collaboration has been to get video to the desktop in a way that is consumable and used in a large scale for both consumers and enterprise users alike.  Generally, I see 3 categories of applications on the desktop:

1. Rich UC client – much like Microsoft Lync or IBM Sametime, which have rich IM/Presence that incorporate voice and video capabilities.
2. Video specific client – like Polycom’s Real Presence Desktop, that provides advanced high quality audio and video capabilities.
3. Browser based – the most ubiquitous application in the world, the browser provides enterprises a way to enable all constituents, internal and external, the ability for rich media collaboration.  This is where WebRTC comes in.

WebRTC is a new standard in development facilitating browser to browser media sharing.  While browser based collaboration isn’t new, the promise of WebRTC is to make these rich media capabilities an inherent part of the browser that is plug-in free. Google is a major player here and provides open source code embedded in the Chrome browser to provide local camera/microphone access, encoding, decoding and transmission of secure media. The source code has been adopted by other browsers, notably Firefox and Opera.

Having WebRTC natively in a browser, one can start a video - without a plug-in - within a web page.  Additionally, developers can add rich media to their web applications easily, which allows for enticing applications.  

However, there are considerations outside of browser choice.  For instance, in a multipoint experience the most popular approach for WebRTC based solutions is mesh-based conferencing, where each browser sends its media to all the other browsers directly, allowing each participant to see members of the call.  This approach means media does not have to go through a centralized bridge, as in a traditional video conference. While this works as long as the number of participants in a call is limited, larger calls suffer.  The need to replicate media sent from each client to all other participants is a process that consumes significant bandwidth and CPU.  Increasing participants mean bandwidth issues can degrade the experience.  Additionally, the need to use the same signaling protocol and Google's media codecs, limits participants to using Google’s WebRTC flavor,  eliminating other browsers (IE or Safari), traditional conference rooms or other Unified Communications (UC) systems from participating.

Organizations have invested heavily in unified communications and video. To be successful, WebRTC can’t exist apart from existing collaboration and video systems. WebRTC may disrupt and ultimately change video collaboration, but to gain traction in its early stages, it needs to work alongside existing solutions.

At Polycom, we’re ready to make WebRTC possible and are excited about the prospects it brings for better collaboration. Some of the projects we’re working on include extending our existing web client capability, RealPresence CloudAXIS, to support WebRTC for plug-in free connectivity.  We will also solve the bandwidth issues for multipoint calls, bring WebRTC and non-WebRTC users together, and integrate enterprise needs such as scale, security, manageability, recording and data analytics.

Like any new technology in the industry, WebRTC is going through the hype cycle, but once it settles, WebRTC can make visual collaboration truly ubiquitous.

To learn more about our perspective on WebRTC, read my colleague's post: "Why WebRTC is key to unlocking mass adoption of video collaboration."

[emcho]

>  the most popular approach for WebRTC based solutions is mesh-based conferencing

This is no longer true. There are robust open source solutions out there like Jitsi Videobridge and Janus that already provide WebRTC enabled scalable conferencing servers. Full mesh conferences are a thing of the past. 

[Ashan Willy (ashan_willy)]

emcho, thanks for the comment, and thought.  Over time, I believe that it will be a hybrid approach, full meshed for smaller, ad-hoc'd approaches that may not need full interoperability and advanced capabilities that are more readily deployed in a centralized environment.  The mesh topology is currently popular with some vendors that are using  WebRTC because it is simple to implement and avoids costs related to sending the media through a server\bridge (bandwidth and processing).   As mentioned in the blog, this approach is useful in some cases, but has significant limitations. At Polycom we're very familiar with the different approaches and plan to accomodate all of them, and including meshed, switched, transcoded for all modes - voice, video, content.