WebRTC is a free open source standard for real-time, plugin-free video, audio and data communication between peers. Many solutions like Skype, Facebook, Google Hangout offer RTC but they need downloads, native apps or plugins. The guiding principles of the WebRTC project are that its APIs should be open source, free, standardized, built into web browsers and more efficient than existing technologies.
How does it work
- Obtain a Video, Audio or Data stream from the current client.
- Gather network information and exchange it with peer WebRTC enabled client.
- Exchange metadata about the data to be transferred.
- Stream audio, video or data.
That’s it ! .. well almost, it’s a dumbed down version of what actually happens. Since now you have an overall picture let’s dig into the details.
How it really works
WebRTC provides the implementation of 3 basic APIs to achieve everything.
- MediaStream: Allowing the client to access a stream from a WebCam or microphone.
- RTCPeerConnection: Enabling audio or video data transfer, with support for encryption and bandwidth management.
- RTCDataChannel: Allowing peer-to-peer communication for any generic data.
Along with these capabilities, we will need a server (yes we still need a server !) to identify the remote peer and to do the initial handshake. Once the peer has been identified we can directly transfer data between two peers if possible or relay the information using a server.
Let’s look at each of these steps in detail.
MediaStream
MediaStream has a getUserMedia() method to get access of Audio or Video or a data stream and provide success and failure handler.
navigator.getUserMedia(constraints, successCallback, errorCallback);
The constraints is a json which specifies if an audio or video access is required. In addition, we can specify some metadata about the constraints like video with and height, example:
navigator.getUserMedia({ audio: true, video: true}, successCallback, errorCallback);
RTCPeerConnection
This interface represents the connection between local WebRTC client and a remote peer. It is used to do the efficient transfer of data between the peers. Both the peers need to setup RtcPeerConnection at their end. In general, we use an RTCPeerConnection::onaddstream event callback to take care of audio/video stream.
- The initiator of the call (the caller) needs to create an offer and send it to the callee, with the help of a signalling server.
- Callee which receives the offer needs to create an answer and send it back to the caller using the signalling server.
ICE
It is a framework that allows web browsers to connect with peers. There are many reasons why a straight up connection from Peer A to Peer B simply won’t work. Most of the clients won’t have a public IP address as they are usually sitting behind a firewall and a NAT. Given the involvement of NAT, our client has to figure out the IP address of the peer machine. This is where Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) servers come into the picture
STUN
A STUN server allows clients to discover their public IP address and the type of NAT they are behind. This information is used to establish a media connection. In most cases, a STUN server is only used during the connection setup and once that session has been established, media will flow directly between clients.
TURN
If a STUN server cannot establish the connection, ICE can switch to TURN. Traversal Using Relay NAT (TURN) is an extension to STUN, that allows media traversal over a NAT that does not allow a peer to peer connection required by STUN traffic. TURN servers are often used in the case of a symmetric NAT.
Unlike STUN, a TURN server remains in the media path after the connection has been established. That is why the term “relay” is used to define TURN. A TURN server literally relays the media between the WebRTC peers.
RTCDataChannel
The RTCDataChannel interface represents a bi-directional data channel between two peers of a connection. Objects of this type can be created using
RTCPeerConnection.createDataChannel()
Data channel capabilities make use of events based communication:
var peerConn= new RTCPeerConnection(),
dc = peerConn.createDataChannel("my channel");
dc.onmessage = function (event) {
console.log("received: " + event.data);
};
