About a year ago we told you that WebRTC, an open project enabling real-time communication on web browsers, was the future of enterprise communication. Bringing real-time audio and video communication to the browser opens up myriad possibilities for instantaneous connection and data exchange the likes of which Skype and FaceTime haven’t even scratched the surface.

Yet before WebRTC becomes a mainstream browser mainstay, competing API specifications and HTML5 video codec standards need to be rectified, and therein lies the rub. The World Wide Web Consortium (W3C) is the standards organization working to make that happen, and a year later WebRTC is enabled in most major browsers and inching toward wider adoption as the W3C focuses on stabilizing its unique combination of specifications.

WebRTC Working Group staff contact Dominique Hazaël-Massieux shed some light on what progress the standard has made, what obstacles WebRTC and the W3C still face, and the future of the real-time communication API definition for both users and developers.

SD Times: In the past year or so, what changes, advancements or evolution have you observed in WebRTC?

Hazaël-Massieux: From a deployment perspective, WebRTC is now enabled by default in Chrome, Firefox and Opera, both on desktop and on mobile, making it possible to use WebRTC-enabled applications and services on more than 1 billion devices, and to more than 50% of users worldwide.

From a standardization perspective, although the specifications are still evolving, they are now quickly converging toward stability, reducing the costs for developers to track the changes and thereby accelerating deployment.

Can you give an overview of the current state of WebRTC specifications from the W3C’s perspective?

At W3C, the core of WebRTC consists of two main specifications:

  • the Media Capture and Stream specification defines the getUserMedia API that is used to obtain video and audio streams from cameras and microphones. That specification is expected to reach a first stabilization milestone (W3C’s “Last Call Working Draft” status) over the summer.
  • the WebRTC 1.0 specification defines the APIs used to establish peer-to-peer connections, and send audio, video and data channels over them; that specification is expected to reach Last Call status by the end of this year.

In addition to these two documents, the groups have been working on a number of additional features that are less advanced in the standardization process:

  • recording audio and video streams obtained from cameras and microphones
  • taking (high resolution) still pictures from a given camera
  • obtaining 3D streams from 3D cameras
  • screen sharing

Furthermore, the core WebRTC API is also expected to evolve in its architecture to provide developers more fine-grained control in establishing peer-to-peer connections.

Are HTML5 video standards still an obstacle to standardization? Which of the competing standards has or is beginning to emerge, and why?

In a peer-to-peer audio-video communication, it is critical that at both ends of the connection, the browser can properly decode the video stream sent by the other end, which means that the browsers must share a common video codec.

The IETF Working Group, which develops the protocol on top of which the W3C WebRTC APIs work, is also responsible for defining what such a common codec should be. The two main proposals have focused around VP8 (used in WebM) and H.264 (used in MPEG4).

While in current implementations of WebRTC VP8 is the most likely to be used, H.264 has historically been much more broadly available, especially in hardware acceleration and server-side processing components.

Which codec (or which combination of codecs) should be available in any implementation of the WebRTC protocols is still under discussion in IETF, with the next milestone expected during the fall. Due in particular to patent licensing, there remain important challenges in the discussions ahead. While getting a common codec is very important to make peer-to-peer video communications universally available across devices and browsers, there are also many ways to use WebRTC without a universal agreement on codecs.

Where does WebRTC stand in terms of developer interest and adoption?

WebRTC is already available on more than a billion devices and in browsers used by more than half the users worldwide, which for such a young and disruptive technology is quite impressive. I don’t have specific data on developer interest, but anecdotally, it certainly is a topic that is getting more and more visibility in developer conferences and forums I am familiar with.

What still needs to happen for WebRTC to become standard and grow in terms of mainstream use and adoption?

Through the W3C standards process we determine whether specifications satisfy a set of technical requirements and can be implemented. The two APIs I mentioned have nearly completed the first phase, after which we will shift our focus to testing to ensure interoperability across browsers and other software. Once we have demonstrated [the ability to implement,] we will finalize the specifications as W3C Recommendations, and they can be deployed royalty-free as part of the Open Web Platform.

Adoption and usage of WebRTC have not waited for the specifications (and their implementations in browsers) to be completely stable, but we can expect that the more stable and interoperable the technology becomes, the more developers will invest in it and the more users will be relying on it (knowingly or not). Part of the adoption question will also depends on which browser makers choose to implement WebRTC natively, beyond Chrome, Firefox and Opera. But it is also interesting to note that a lot of adoption of WebRTC has happened and will likely continue to happen outside the browser, or via plugins.

How do you see the W3C’s role in reaching that point? What needs to be accomplished in the near term?

[The] W3C’s main focus in the upcoming months will be to stabilize the specifications: this is critical to enable more service and content providers to invest in developments based on the technology.

What do you envision as the future of WebRTC?

On top of the other features that we have already started to work on (recording, photography, 3D cameras, screen sharing), we already know more advanced video processing will be useful (the Web platform already provides a good API for audio processing); the development of WebRTC communication systems will also require better integration with the underlying devices, and in particular the ability to receive so-called Push notifications, for example to alert the user of an incoming call even if their browser is closed.

But the exciting thing about WebRTC, as with most other Web technologies, is the things we can’t envision it will bring: it is a foundation to make peer-to-peer connections and the manipulation and transmission of audio, video and data as natural as the sharing of text and images has already been made on the Web. That is a foundation for many disruptive ideas and projects: the world opens up when any device can be a communications endpoint. With the explosion of devices promised by the Internet of Things, this makes WebRTC prospects even more interesting.

The longer-term future of WebRTC will necessarily depend on what emerges as the next set of demands on the Web platform.