In its simplest incarnation, WebRTC allows you to set up a live peer-to-peer connection between two browsers to exchange private video, audio, and data between them. It looks like this:

Of course, you and I both know that we also need signaling and a couple of STUN/TURN servers to do the trick. For now, let’s leave out these components. Just remember that they are still there!

Let’s make it a party

What would happen if we add another user to the connection? Then another? And another? This is a situation defined as multi-party. With it, the rules of the game change, and believe me, they change a lot.

There are three types of strategies when it comes to how to handle multi-party connections on WebRTC. Mesh, SFU, and MCU. Mesh is the simplest and probably the most obvious solution. Mesh is what we will discuss today. 

Mesh

For the connection to be possible, each peer that uses the RTCPeerConnection API must create a connection object. This connection object adds all the relevant information, such as video and audio stream, STUN/TURN servers addresses, and handlers for when Interactive Connectivity Establishment (ICE) candidates are created or any data is received.

The API then takes care of establishing the connection using all the data that has been passed with a signaling process in the middle.

We then just repeat this process for any number of peers that are added to the call. In other words, we create additional RTCPeerConnection objects for each one.

So, if we add another peer to the diagram described above using this strategy, it will look like this:

You can see that now each peer is maintaining an additional connection by sending media streams and data to two peers, and also receiving the streams and data from each peer. 

Who invited all these people to my party?

Now, let’s see what this would look like if we add a few more peers.

As the number of users keeps increasing, the processing and bandwidth consumption becomes excessive. This is more visible on mobile devices or in low-end spec computers, where resources are more limited. Also on broadband connections, which are usually tied to contracts where a monthly limit of usage is specified.

With five users, each browser needs to maintain four additional connections for sending and receiving streams and data to and from other peers. 

With all this, we can say that Mesh is the simplest way to implement multi-party as it doesn’t require any change on the infrastructure. All the work is done on the browser. The problem is that it only works with a small number of users.

An alternative strategy

If we want to be able to support more users without any problems, we need to find another strategy – one that allows us to mix all the connections created by Mesh or somehow route them, in order to avoid the high CPU and bandwidth consumption on the client side. This is where approaches like MCU (mixing connections) and SFU (routing connections) enter.

Building apps with WebRTC is harder than one would imagine. It takes an expert team. If you are interested in working with the best, contact WebRTC.ventures today.