Scaling WebRTC Based Applications

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

WebRTC is supported by Chrome, Firefox, Opera, Android, and iOS.

First Attempt

In the simplest form, there are peers (WebRTC clients) and a signaling server. At the beginning, peers don’t know each other, and they don’t know the necessary network information to make a direct connection possible. Before establishing a direct connection, peers should exchange all necessary data using a signaling server. This is a middle point that is known to each peer. So each peer can connect to the signaling server, and then one peer can call another one—by asking the signaling server to exchange specific data with another peer and make peers know each other. Both clients exchange the necessary data (including network details) and then establish a direct peer-to-peer connection. After the connection is established, peers don’t use the server anymore.

A message service for signaling needs to be bidirectional: client to server and server to client. In this case, we can use WebSocket which is designed for full duplex client–server communication. To support highly concurrent users, our WebRTC app needs signaling servers that are able to handle a considerable load.

In this case, we can do vertical scaling by adding multiple signaling servers behind a load balancer. There is a problem with this when two peers are about to make a call but are connecting to different servers. So, how do these two servers talk to each other? The solution is to use a message queue, such as ZeroMQ, Redis, etc. 

Each signaling server needs to create two clients that are connected to the message queue: one for publishing a message to the queue and the other for subscribing to the queue. When a server gets a request to route a message to a client which is not in the local connections dictionary, it will publish a message to the queue server, which will tell all the subscriber servers to look for this client and issue the message if it’s connected to that server.

Using TURN Servers

In some cases, when clients use NAT and firewalls, it is impossible to establish a peer connection using STUN. This situation often appears when a client is working on a corporate network with a strict connectivity policy. In such a case, the only way to establish a connection is to use the TURN server. The TURN server works as a proxy—all the data between peers (including audio, video, and service data) goes through the TURN server.

The TURN server has to support authentication and prohibit anonymous access. When using a TURN service, all the traffic from one peer to another goes through the TURN server.

We may also need to vertically scale for TURN servers by adding a load balancer.

Combining the Best of Both Worlds

We can configure a TURN server as a fallback option when a peer connection can’t be established using STUN. That way we can combine the best of both worlds.

When we create a peer connection object, we use the following code:

var pc = RTCPeerConnection(configuration);

Here, configuration is an entity that contains different options to create a peer connection object. To utilize your TURN server, we use something like the following:

var configuration = {
    'iceServers': [{
            'url': 'stun:stun.l.google.com:19302'
        },
        {
            'url': 'turn:turn1.myserver.com:3478?transport=udp',
        },
        {
            'url': 'turn:turn2.myserver.com:3478?transport=tcp',
            'credential': 'xxxxx',
            'username': 'superxxxxxxxx'
        }
    ]
}

Here, we will ask the WebRTC API to use one of three servers when establishing a peer connection:

• A public STUN server provided by Google.
• A TURN server with anonymous access.
• A TURN server with authentication.

But how do clients know the TURN server's URLs and credentials? After the user gets authenticated, he will be redirected to the private area where the WebRTC interactive page is placed. The interactive page that a user gets from the web server should contain the proper credentials for accessing the TURN server. These credentials are calculated by the web server and are then sent to the authorized client.