Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

With WebRTC, real-time communications come to the browser

Chris Minnick and Ed Tittel | June 6, 2013
The WebRTC standard aims to make peer-to-peer communication over the Web as easy as picking up a phone. Here's what developers need to know about WebRTC, including how to set it up and what limitations the protocol currently faces.

< script > navigator.getMedia = ( navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia); navigator.getMedia ( // constraints { video: true, audio: true }, // successCallback function(localMediaStream) { var video = document.getElementsByTagName('video')[0]; video.src = window.URL.createObjectURL(localMediaStream); video.onloadedmetadata = function(e) { // Do something with the video here. }; }, // errorCallback function(err) { console.log("The following error occurred: " + err); } ); < /script > < video autoplay >< /video >

More Than One Way to Establish a Connection
Once a media stream is created, WebRTC uses the RTCPeerConnection API to communicate streaming data between peers. RTCPeerConnection, like MediaStream, employs a very simple interface. It takes a media stream and sends it to another recipient, where it's loaded into an RTCPeerConnection on their end. That's all there is to it.

Under the hood, however, RTCPeerConnection has to handle the following tasks:

  • Signal processing (including echo cancellation and noise reduction)
  • Codec selection
  • Peer-to-peer communication
  • Encryption
  • Bandwidth management

Before streaming between peers can begin, though, a process known as signaling must occur. Signaling is where things usually get sticky. Rather than reinvent the wheel, WebRTC leaves signaling up to the application. A developer is free to choose any two-way communication protocol, whether it's SIP, XMPP, WebSocket or even just JSON data.

Signaling is the part of a WebRTC system that does require servers to get around firewalls and network address translation (NAT). Most often, all that's needed to initiate a peer-to-peer connection is a public IP address for the sender. WebRTC uses a Session Traversal Utilities for NAT (STUN) server to tell a WebRTC application that's behind a firewall its public IP address. The WebRTC application can then proceed with establishing a peer-to-peer connection with another application.

If, for some reason, establishing a peer-to-peer connection fails, WebRTC can fall back to establishing a connection through a server by using a technology called Traversal Using Relays around NAT (TURN). Obviously, a connection that doesn't require any server resources (STUN) is less expensive and more efficient than routing data through a relay server (TURN). Whenever possible, then, you want to establish connections using STUN.

The job of making sure that your calls are always as low-cost as possible falls to a protocol called Interactive Connectivity Establishment (ICE). In the majority of cases-86 percent of the time, according to Google-you can make video calls work using only STUN. The result is a huge savings in server resources over real-time video systems that always require a server.

Here's a simple example of how RTCPeerConnection does its thing:

< script > pc = new RTCPeerConnection(null); pc.onaddstream = gotRemoteStream; pc.addStream(localStream); pc.createOffer(gotOffer); function gotOffer(desc) { pc.setLocalDescription(desc); sendOffer(desc); } function gotAnswer(desc) { pc.setRemoteDescription(desc); } function gotRemoteStream(e) { attachedMediaStream(remoteVideo,; } < /script >


Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.