WebRTC: Real-Time Communication for the Open Web Platform

burst of colored squares, illustration - Credit: Qushe / Shutterstock

WebRTC: Real-Time Communication for the Open Web Platform
Communications of the ACM, January 2019, Vol. 62 No. 1, Pages 106-114
Practice
By Niklas Blum, Serge Lachapelle, Harald Alvestrand

“Most importantly, WebRTC is growing from enabling useful experiences to being essential in allowing billions to continue their work and education, and keep vital human contact during a pandemic. The opportunities and impact that lie ahead for WebRTC are intriguing indeed.”

 

In this time of pandemic, the world has turned to Internet-based, real-time communication (RTC) as never before. The number of RTC products has, over the past decade, exploded in large part because of cheaper high-speed network access and more powerful devices, but also because of an open, royalty-free platform called WebRTC.

 

In fact, over the past year, there has been a 100-fold increase of video minutes received via the WebRTC stack in the anonymous population that has opted into Google Chrome’s statistics. WebRTC can be found in most Internet meeting services, social networks, live-streaming experiences, and even cloud-based gaming products.

 

WebRTC provides RTC capabilities to browsers and native apps. An open source implementation and tutorials for this platform can be found at https://webrtc.org. It includes audio and video codecs, and signal-processing functions such as bandwidth estimation, noise suppression, and echo cancellation.

 

This widely deployed communications platform powers audio/video calling, conferencing, and collaboration systems across all major browsers, both on desktop and mobile devices. This has enabled billions of users to interact. WebRTC has vastly expanded and facilitated the ability to create and deploy real-time, interactive services for startups and large-scale companies, and it can be found in commercial products and open source projects alike.

 

The idea for WebRTC originated in late 2009, more than a year after the launch of Google’s Chrome browser. The Chrome team looked for functionality gaps between the desktop and the Web. While most of the discrepancies were already being addressed by ongoing projects, no solution existed for real-time communications. At the time, only Adobe’s Flash and Netscape’s NPAPI (Netscape Plugin API) provided RTC. Flash’s offering was somewhat low quality and required a server license. Plug-ins are quite tricky for users to install, and few developers have the resources to handle deploying and updating plug-ins that work with three different browsers across several operating systems.

 

At about this time Google identified a company, Global IP Solutions (aka GIPS), that had the low-level components required for RTC. The GIPS components were licensed by several large customers and were present in products from Google, Skype, AOL, Yahoo!, Cisco, and others. By combining these audio and video components with a JavaScript interface, Google believed it could solve the big “hole” in its Web offerings and spur innovation in the RTC market. If a few lines of JavaScript code were all you needed to add RTC to a Web app—and with no licensing, integration of components, or deep knowledge of RTC required—who knew what could happen?

 

GIPS was based in Sweden and the U.S. and had engineers in both Stockholm and San Francisco. Luckily for Google, its audio and video Hangouts product was already being worked on in Stockholm, and having the GIPS engineers join in further reinforced the Stockholm office’s strength as an RTC specialist within Google.

 

When the acquisition was completed in January 2011, the newly formed Chrome WebRTC team focused on integrating the code into Chrome and open sourcing all the key components at webrtc.org. From the beginning the plan was to build something open for the Web that would make RTC available for everyone.

Architecture and Functionality

A WebRTC peer may be a user endpoint (Web browser, native app, and so on) or a server that acts as an intermediary between two or more endpoints. While many WebRTC services rely on a client-server architecture, many others are deployed in a peer-to-peer (P2P, aka connection-less) architecture.

Read the Full Article »

About the Authors:

Niklas Blum is a group product manager at Google. He leads the strategy and execution for the audio/video calling experience in Google’s video communication products, including Google Meet, Google Duo, and Chrome/WebRTC. He has spent 15-plus years in the communications space.

Serge Lachapelle is director of product management at Google. He has spent more than 20 years in the video communications industry, starting as the cofounder of Marratech AB, which was acquired by Google in 2007. At Google, Lachapelle started many video-calling initiatives, including Gmail Video Chat, Google Hangouts, WebRTC, Google Duo, and Google Meet.

Harald Alvestrand is the standards coordinator for the WebRTC project at Google. He has been an evangelist for open communication across company borders for over 35 years. He has been a member of the board at ICANN, chair of the IETF, and area director of the IETF Applications Area.

See also: