WebRTC Comes to Android Chrome: Mind the Gap

Earlier this month Google announced the release of Chrome Beta for Android adding, among other things, WebRTC to the mobile browser. This is an important step that spawned many excited comments and posts. Phil Edholm rightly considered this as an important move of the industry.

Putting the industry excitement aside for a minute I would like to take a closer look at what this brings and more importantly, what further needs to be done for achieving real ubiquity.

At the end of the day it all boils down to native support vs. application level support.

Usage scenarios

There is an inherent conflict between feature richness and pure browser support. Yet, when it comes to mobile, it is not a sequential line between the two options, but rather a choice between pure browser (no download) or application.

The common usage scenario for mobile users is through applications. Although technically it is possible to provide many of the applications used today as HTML5 applications, reality is that most are still provided as dedicated, downloadable, applications and we the users are good with that. We are used to working through a dedicated application per task or vendor. Ken Yeung covers the HTML5 story of Facebook going from HTML5 to native app and then Home. It is a good post that pretty much closes the lid on this thing even though one may say that when you do a lousy job you get a lousy result; that doesn't mean technology used for the job is bad. Still, when it comes to real-time communications the requirements are far more exigent, so it is wrong to expect those applications to pioneer the HTML5 application storm.

The bottom line of this is simple, whenever the voice, video, data communication is part of a relationship, meaning a vendor or a service you trust or are regularly using, the native app is the answer. Only when it is an occasional user would the answer for this type of communication be the mobile browser and even for this type of scenario, offering an app for enhanced user experience would be a plus.

Support in the food chain

If the conclusion is that most WebRTC communication on mobile will be through native apps, the addition of WebRTC to the Chrome browser for Android is a nice move but far from being comprehensive. There are Challenges in Porting WebRTC to Mobile Devices because such real-time voice, video and data communication has special characteristics that require special attention.

Ubiquitous native support for WebRTC on mobile devices requires support across the food chain. In a bit of a simplistic view, the mobile device food chain includes the chipset vendors (the Qualcomms of the world), the OS vendors (Android in this case but not only) and the device vendors. Typically, the chipset vendor would take the Android version from Google, make his changes to it, and provide it to the device vendor. The device vendor may make some additional changes to fit his needs and release an official version of Android for his device. Therefore, at the end of the day, we have different builds of Android per device brand or model.

WebRTC needs to be pre-built into the Android version loaded to the device by the device vendors. While doing that, a few additional things need to be addressed.

Voice optimization

Audio codecs optimized for NEON. Something Google provided in the browser support already.

Optimized Acoustic Echo Cancellation (AEC) that minimizes the delay introduced. This requires both using the echo cancellation of the chipset as well as automatic tuning to the acoustics of the specific device.

Video optimization

This requires native support of VP8 in the chipset accelerators. WebRTC chipsets will significantly improve the video quality (resolution and frame-rate) as well as improve battery utilization. Current support for VP8 in the Chrome browser for Android is through a software codec running on the ARM processor. Support for VP8 in the chipset and having the native WebRTC of the phone using it will make this difference.

All this is far more complex than just adding WebRTC to the mobile browser. WebRTC needs to become ubiquitous and available for any mobile app developer without VoIP and media experience just as it is today for the web developers on the desktop (for the supported browsers of course).

When will this native WebRTC support be available on mobile devices is the real question and the real need. Anyone with an answer to that?

Amir Zmora is the Vice President of Products & Marketing for the Technology Business Unit at RADVISION an Avaya company.

*Opinions presented in this blog post represent the author's personal views and not necessarily those of his employer.