WebRTC: Phantom Menace or New Hope?

It has been three years since Google announced WebRTC (Web Real-Time Communication) standard. Nevertheless, this topic stays hot and causes massive discussions in the telecom crowd, communications providers in particular.   

For billions of subscribers, i.e. users of desktop and mobile versions of browsers like Chrome, Firefox, Opera, and their derivatives (e.g. SRWare Iron), WebRTC opened an opportunity to participate in video conferences by clicking a link in the browser. Since WebRTC does not require any special software or plug-ins, a bidirectional full-duplex audio and video communication can be accessed using just a web browser. All that is necessary is to allow the access to the camera. Enterprises may find it beneficial to use WebRTC as it allows to connect external users or those inexperienced in IT to internal video conferencing sessions.

How on Earth should service providers get their profit from the worldwide telecom revolution under the banners of WebRTC? The success here, first of all, will depend on how fast the service providers will learn all pros and cons of this technology, and how fast they will be ready to adapt their services. 

What is WebRTC? It is an open-source standard for data stream transmission between browsers and other enabled endpoints in real time using “peer-to-peer” (P2P) technology.

WebRTC is changing the telecommunication services, and these are worrying news for service providers. From now on pricing will be defined by the aims of user, aims of communication and its context, not just by the available service plans.

WebRTC Project speeds up the integration processes, but it is still quite “raw” and needs a lot of improvements to make it comfortable and available for wider audience.

For example, Safari and Internet Explorer still do not support this standard, and those are millions of users that create a severe restraining factor that holds this technology from further development.

The greatest problem of WebRTC is group video conferencing. WebRTC allows conducting 1-on-1 video conferencing sessions without any problem, but group video conferencing causes a lot of issues. Why? Because WebRTC standard on its own does not include SVC (Scalable Video Coding), and without SVC, group video conferences demand re-encoding of the same conference into various formats, especially on mobile devices.

Let’s imagine a situation where three clients have different symmetrical communication channels (200, 500 and 500 Kb/s). What will happen to the channel during a group video conference? Each client will transmit the widest data stream possible. As the result, client #1 with channel bandwidth of 200 Kb/s will be able to transmit only 100 Kb/s to clients #2 and #3, or 200 Kb/s to only one of those clients. Both scenarios are unacceptable for a normal group conference.

In this case, the optimal solution is to install a so-called mediator — video conferencing server that receives all clients’ video streams and distributes them among the participants according to their capabilities. The role of such server may be played by classic MCU (Multipoint Control Unit) or by a modern software-based server, that uses SVC (Sсalable Video Coding) for managing video streams. 

SVC allows changing the channel (size) of a video stream without any re-encoding. This also affects the framerate, resolution, and image quality.

During a video conferences with classic MCU, all incoming video is decoded and then re-encoded while adding delay and requiring massive amounts of computing power. All that influences the resulting price of video conferencing server. On the other hand, using SVC makes it possible to conduct more group conferences on a regular server. 

In order to compare those two approaches from the financial point of view, we can look at the price of a standard project for WebRTC conferencing for 100 subscribers of a service provider. As we mentioned earlier, WebRTC on its own does not mention group conferencing in any way, and does not allow the browser to receive more than 1 video stream, so it requires re-encoding for mixing images captured during a group conference. With SVC, video re-encoding occurs only once, and then video of corresponding resolution is distributed among the participants. MCU works on a different principle: re-encoding occurs several times, because transmission of video with different resolution requires re-encoding it each time. Imagine that those 100 subscribers have different communication channels. Then, if we use SVC approach (using SVC in WebRTC), such project will cost about $44,000, while classic MCU approach (transcoding of separate video streams for each resolution) will cost at least $880,000, i.e. 20 times more.

This means that SVC technology may help service providers to organize a low-cost WebRTC solution. And since users do not want to spend any time or effort on configuring software or hardware endpoints, WebRTC-enabled browsers can lower the barrier to entry and increase usability of video-related services. At this point service providers should seize the moment.

Aiming for the development of VaaS (Video as a Service) concept, service providers have always been providing only local communication services, such as special network conditions (direct IP) or special software for their subscribers. This, in turn, was limiting the possibilities of users, who demanded a worldwide communication. Usually, the provider sells services based on his own proprietary client software. Such applications are produced on demand and only for the most popular platforms (like Windows), without the ability to provide a stable technical support, bug fixing and improvements for them even on newer versions of Windows. Often users become unsatisfied with such software already in a year since release.

Sure thing, the popularity of smartphones with simplified software installation (AppStore, Google Play)  helped service providers, but did not eliminate the problem completely. WebRTC technology may resolve the issue with necessity of proprietary communication software, because it allows to connect any computer to VaaS service of the provider. Thus, users will not have to install any special software, and providers will not have to pay for its programming/development. 

Thus, WebRTC gives service providers an opportunity to distribute services among more endpoints, and for more users. All that pushes the telecom market (dominant companies and regulatory structures) towards reviewing its dated business models and towards developing communications services and solutions in order to satisfy new customer needs. If vendors will be flexible, i.e. will reach a connection with the developers and create strong teams that will aim for innovative ideas, then users, developers, and service providers themselves will be satisfied.

Stass Soldatov is the CTO of TrueConf.

4 Responses to "WebRTC: Phantom Menace or New Hope?" - Add Yours

Phil Edholm 8/29/2014 9:47:14 AM

While this post makes some good points (the relative cost differences of routed versus MCU mixed video. I felt a few comments were in order as I do not want readers to come away with either the wrong impressions or unclear information about either WebRTC or video in general.

WebRTC is a web technology, it enables communications to work in the web paradigm where I do not go through my server (service provider) to participate in a communications event hosted by another server, I go directly to the server managing that specific event. Goolge does not take me tot eh sites after a web search, they "send" me there and are not part of the subsequent web event. Similarly, when I get a URL to join a WebRTC based conference (try Uberconference for a voice based WebRTC experience), I go directly to the event and my server (PBX or SP) is not involved. This is the web model versus the client server model of computing. This is how the web changed the client server information model of 1990 and transformed information into the web we have today. Instead of one AOL, we have 30-40 million active web sites. In this new world, the end user support role of the service provider changes form outbound and inbound representation to primarily inbound representation and potentially security. At the same time, in any given day I may participate in many communications events, each one separate and unique, just as your web browsing is today. This link is to an overview of WebRTC for those unfamiliar that will detail many areas that will clarify the comments in this response: https://www.pkeconsulting.com/pkewebrtc.pdf

The discussion of how video works has a some issues. WebRTC can indeed receive more than one video stream. Just try FACEmeeting,Tawk, Bistri, or any of the many other video systems that enable multi-user peer to peer video without a centralized media server. I regularly do WebRTC video meetings with 3-5 participants without a media server and using end poi

Phil Edholm 8/29/2014 10:05:28 AM

The previous comment was cut off, so I will continue here:

I regularly do WebRTC video meetings with 3-5 participants without a media server and using end points with direct video and no centralized media server.

The choice of an MCU that does centralized video mixing versus a "routed" media server is primarily an application choice. Sometimes ththe video router is called a switch, I will use "router" here as it is managing the layers/streams. I do not know where the term "mediator" comes from as the community generally refers to these platforms as a media server, though it may be related to the "mediation servers" in Lync. The comment that WebRTC only allows an MCU is not correct. WebRTC does not specify the peer, it is a peer to peer protocol and API. A peer can be a browser or a media server. A media server can be an MCU mixer or a router. A router can use SVC (layered in a single stream) or multi-channel AVC (different streams of different bandwidths) to manage the streams. Vidyo is supporting WebRTC in it's router based implementation and SVC is coming in both VP9 and other codecs.

The choice of which media server to use is also about the application and the end points. for end points on relatively high speed connections, a routed solution makes sense, but for the user on a low speed mobile device, a single mixed stream may be more appropriate.

Finally, some comments about specific areas in the post:

the post makes the statement, "With SVC, video re-encoding occurs only once". This is not true/clear. In SVC (or multi-channel routed AVC), the transmitting end point encodes the video and send to the router. The router determines which layer (SVC) or bandwidth stream (AVC) to send to each end point without doing anything else to the video. The only reason to re-encode is for transcoding, a techniques that is bad for both quality and latency. As long as the end points are using the

Phil Edholm 8/29/2014 10:20:01 AM

Continuing.....

The comments on mobile apps and WebRTC needs some clarification. The major driver of the choice of a native OS app versus browser app is not WebRTC, but app performance. In most of today's mobile devices, an app written to the native OS (iOS in Apple, Android for most everybody else, and Windows Mobile and Blackberry for the few and the proud) has better performance for the user. This is because running the app in teh browser using HTML%, while delivering an app that can look great, is generally slower due to teh overhead and inefficincy of th browser as an aded layer. while it is true that the future of devices is probably HTML5 based apps running in the browser or in a browser OS like WebOS from Moxilla, for today, native apps run better. The 64 bit processor int eh iPhone 5s is the beginning of that change, but it will take 5 years. IN teh interim, we are weeing WebRTC being used in native OS apps as the communications environment. for example, CafeX delivered a native iOS iPad app to Amex for video chat from their contact cener (on PCs) to their customers (on iPads). This app has had explosive download and use and has had significant impact on customer satisfaction and loyalty. Almost all of the native OS development platforms have included WebRTC and there are many companies that are developing WebRCT based apps in native OSes.

Phil Edholm 8/29/2014 10:20:33 AM

Finally...

WebRTC is close to final 1.0 standardization. There are over 400 active companies in the WebRTC ecosystem developing delivery platforms,tools, SBCs, media servers and end applications. In addition there are a growing number of end user organizations using WebRTC. Today IE and Safari do not have WebRTC native, though there are plug-ins that enable WebRTC in IE. With the advent of the object oriented APIs in WebRTC 1.1 based n the ORTC efforts, Microsoft has indicated they will support the standard. The result is that WebRTC and the webification of communications is really exploding. Just as the web and the webification of information int he 90s and 00s changed the world and created trillions of dollars of capitalization and wealth, the webification of communications will change the communications landscape.

Thanks for the post :)