Traditional RTC is corporate, closed, complex and requires expensive audio and video technology. Rich communications on the Web can be cumbersome; require users to find, download, install and update software; and may involve Flash, which has limited quality, long delays and is often unreliable.
That’s the word from Jan Linden, senior product manager at Google.
“We need something that’s open, standardized and good for the Web,” said Linden, who is in Atlanta this week at the WebRTC Conference & Expo, which hosted the Google WebRTC Workshop.
Demonstrating that there is clearly demand for this kind of thing, Linden pointed out that President Obama recently made himself available to the citizenry via a Google Hangout, which received more than 200,000 real-time questions during the event, and that people were waiting in line to take part in that real-time session.
WebRTC can help enable this kind of multipoint, real-time communications and a whole lot more, said Linden of Google, which has been a pioneer on the WebRTC front. The company’s interest in WebRTC started with a meeting of the Chrome team at Google at which the members talked about how they could make the web better. One key way, they agreed, was to better allow for real-time communications.
Google later bought GlobalIP, for which Linden used to work. And by the spring of 2011 there were WebRTC working groups within the IETF and W3C. Linden explained that Google’s plan for WebRTC is to open source the technology, implement it in browsers, engage with the IETF and W3C to standardize it, and use it to address mobile platforms.
“Right now, today, more than a billion endpoints support WebRTC, and that’s just with Chrome and Firefox, and more will come very soon,” Linden said.
Sam Dutton, developer advocate at Google Chrome, who presented alongside Linden, took a deeper dive into the subject of WebRTC with his presentation, which discussed WebRTC APIs MediaStream, RTCPeerConnection and RTCDataChannel.
“The interoperability between the APIs on the Web – it’s really powerful,” he said.
A MediaStream, he explained, represents a single source stream of video or audio. RTCPeerConnection does signal processing, codec handling, peer-to-peer communication, security and bandwidth management. And then there’s RTCDataChannel, which initially didn’t get a lot of attention, but now is drawing interest from more developers, he said.
Image via Shutterstock
Linden went on to say that while WebRTC enables peer-to-peer communications, there’s still a need for signaling servers to initiate connections. But with WebRTC there is no specific signaling protocol decided on; session description protocol is the only thing that’s decided, and that tells you what formats the involved endpoints support, what they want to send, and the network information for P2P setup.
He then turned to discuss how peer-to-peer communications enabled by WebRTC work in environments involving NATs and firewalls. WebRTC leverages a mechanism called the ICE framework, which tries to find the best path for each call. The vast majority of calls use something called STUN, a standard that’s been around for a while that tells me what my public IP address is and sends data flows peer to peer; however, if that doesn’t work, the fallback is to leverage something called TURN. TURN provides a cloud fallback if P2P communication fails; as a result, the data is sent through a server, and uses server bandwidth. While TURN can be helpful, it’s a more costly way to go.
Edited by
Alisen Downey
