WebRTC offers developers unprecedented capabilities for streaming voice and video data through the browser. The three WebRTC APIs - getUserMedia, RTCDataChannel, RTCPeerConnection - work together to capture, relay, and render the input that comes from a computer’s webcam and microphone from one browser to another. From its inception, WebRTC has been backed by some of the web’s leading development teams. But Google, more than any other company, has paved the way for WebRTC’s success. From its inception in the Chrome team’s lab to its current status as a game-changing technology, WebRTC has relied on Google’s backing to sustain its growth. Google and WebRTC, for better or worse, are inseparable entities at this point. This of course has ramifications for WebRTC’s codification at the W3C.
Google and WebRTC - A History
The history of Google and WebRTC is actually the story of several different companies becoming interworking subsidiaries of a larger project. Google used its finances, stature, and engineering prowess to produce WebRTC as the first true in-browser solution to real-time communications in 2011. The sudden renaissance of browser-based RTC in 2011 was spurred by a series of mergers. Google acquired On2, the creators of the VP8 video codec, and Global IP solutions, a company that was already licensing low level components for RTC. With these new resources, the WebRTC Chrome project was born. Google made the project open source, and its developers ultimately settled on G.711, OPUS, and VP8 as the required codecs for the WebRTC API. The first implementation of WebRTC was built by Ericsson in 2011. In November 2012, Chrome 23 became the first large scale browser to offer embedded WebRTC functionality right out of the box.
Google and WebRTC - Overarching Design
The relationship between Google and WebRTC begins with the fundamental design decisions the Chrome team made when they inaugurated the project. Google’s vision of real-time, in-browser communication begins with three HTML5-based Application Programming Interfaces (API) that allow JavaScript to manipulate streaming media to traditional audio and video objects in HTML. getUserMedia is tasked with capturing and transmitting audiovisual data from the computer’s microphone and webcam and turning this information into JavaScript objects that can be manipulated with ease. RTCPeerConnection is a signaling agnostic API that connects peers (i.e. browsers) across the Internet. RTCDataChannel allows for real-time data exchange (i.e. text chat) and gives RTCPeerConnection more flexibility in how it can usher streaming data across the internet.
The decision to treat traditional data separately from audiovisual streams comes from Google’s desire to give RTCDataChannel bidirectional support like WebSockets. This allows data to arrive asynchronously, which leads to faster transfer rates and greater delivery efficiency. The unchosen signaling mechanism of RTCPeerConnection gives developers leeway in crafting the underlying architecture of the way an app can communicate across the Internet. OnSIP has a mature SIP platform that offers a reliable solution to developers who want to scale their WebRTC application, broker connections between endpoints, and traverse NAT and firewall settings that can disrupt real-time data sharing.
Google and WebRTC at the W3C
The World Wide Web Consortium (W3C) is the international standards foundation for the world wide web. The 385 member panel was founded in 1994 by Tim Berners-Lee, and the group is primarily responsible for codifying major advances in web technology. WebRTC has experienced significant adoption, and it is currently completely interoperable between Chrome and Firefox, but it is still awaiting official codification by the W3C. Official standardization will likely pave the way for other companies, such as Microsoft and Apple, to utilize the technology.
The official WebRTC specification that will be submitted to the W3C will not be the exact same WebRTC that Google outlined in its initial 2011 release. But the fundamental architecture of the APIs and their duties within the WebRTC framework have never changed. The initial premise of WebRTC - to offer developers simple JavaScript functionality that can easily manipulate streaming media - is still the broader goal of the project. Google’s initial WebRTC specifications have proven to be highly successful in an overarching sense. Although variants of the technology have arisen (most notably Mozilla’s spec), the defining aspects of WebRTC will remain the same when they are presented to the W3C.