Implement a Video Conference with WebRTC

WebRTC introduction

WebRTC (Web Real Time Communication) is an open source project that enables peer-to-peer communication between browsers. In other words, WebRTC allows you to exchange any kind of media through the web (such as video, audio and data) without any required plugin or framework. WebRTC allows users to initiate click-to-start video chats from their browsers and exchange information quickly enough to replicate in-person interactions.?This supports interactive live streaming between individuals, as well as browser-to-browser communication through a set of standard protocols. WebRTC is referred to as peer-to-peer technology, whereby each browser communicates directly with one another. ?Currently following available standard Streaming protocols are there.

• WebRTC?- Low latency protocol, built on open standards, uses SRTP for transport, works in all browsers.
• RTMP?- Low latency TCP-based protocol originally built for Flash. Requires Flash player to run in the browser.
• HLS?- High latency, non standard Apple-backed protocol
• MPEG-DASH?- High latency Google-backed web standard, very similar and has many of the same faults as HLS

Direct communication between browsers improves performance and reduces latency times since clients don’t need to keep sending and receiving messages through a server. For instance, we could use?WebSockets?to connect two clients but a server would have to route their messages as in the next diagram:

By contrast, WebRTC only needs a server to establish and control clients’ connections. This process is known as?signalling. Once the browsers have collected the required information of the peers, they can communicate with each other:

WebRTC doesn’t specify the signalling messaging protocol so the chosen implementation has to be based on the application requirements, some of the most common approaches are: WebSockets, SIP, XHR, XMPP, etc.

The signalling process works as follows:

• A client initiates the call.
• The caller creates an?offer?using the?Session Description Protocol?(SDP) and sends it to the other peer (callee).
• The callee responds to the offer with an?answer?message containing an SDP description too.
• Once both peers have set their local and remote session descriptions, which include information such as browser’s codecs and metadata, they know the media capabilities used for the call. However, they won’t be able to connect and exchange their media data yet because SDPs are not aware of things like external?NATs?(Network Address Translators), IP addresses and how to handle any port restrictions. This is achieved by?Interactive Connectivity Establishment?(ICE).

So how does Interactive Connectivity Establishment work? ICE is a peer-to-peer network communication method to send and receive media information over the Internet. How routing is made (NATs, firewalls …) is out of the scope of this article but it’s something that WebRTC needs to deal with. ICE gathers available network connections, known as?ICE candidates, and uses protocols?STUN?(Session Traversal Utilities for NAT) and?TURN?(Traversal Using Relays around NAT) for NAT and firewall traversal.

This is how ICE handles the connection:

• First, it tries to connect peers directly via UDP.
• If UDP fails, it tries TCP.
• If both UDP and TCP direct connection fail, which is often the case in real scenarios because of NATs and firewalls, ICE will first use a STUN server with UDP to connect peers. A STUN server is a server that implements the STUN protocol and is used to find the public address and port of a peer behind an asymmetric NAT.
• If the STUN server fails, ICE will use a TURN server, which is a STUN server with some extra relaying functionalities that can traverse symmetric NATs.

As you can see, ICE tries to use STUN servers first but TURN relay servers will be needed for very restrictive corporate networks. TURN relay servers are expensive, you will need to pay for your own ones or use a service provider, however, most of the time ICE will be able to connect peers with STUN. The following schema shows a STUN/TURN communication:

To summarise, the signalling process is used to exchange media information with SDP files and ICE is used to exchange the network connection of the peers. After the communication has been set up, peers can finally exchange data directly through their browsers.

Regarding security, WebRTC includes some mandatory features to cope with different risks:

• Media streams are encrypted using Secure Real-time Transport Protocol (SRTP) and data streams are encrypted using Datagram Transport Layer Security (DTLS).
• Access to camera and microphone has to be granted by the client. To keep the client aware, browsers show icons if the device’s camera or microphone is active.
• All WebRTC components run in the?browser sandbox?and use encryption, they don’t need any kind of installation, they will just work as long as the browser supports them.

How to achieve scale with WebRTC

A live streaming server?like AMS/ Red5 or?cloud-based service?can be used to?transcode?the WebRTC stream into a protocol like?HLS?for distribution to thousands. That way, content distributors can combine simple, browser-based publishing with large-scale broadcasting — albeit at a higher latency. When easy content acquisition (and not real-time delivery) is the key reason for incorporating WebRTC into your streaming workflow, then this solution is the way to go.