How WebRTC works internally

What is WebRTC?

WebRTC is a service that provides the functionality that allows peers to share media between them without the need of a server. This functionality is mainly used on video calls. So you will be wondering how those peers know how to connect to each other, right? This is done using signaling. WebRTC takes care of everything that happens through the exchange of media between the peers except from the signaling process. So what does signaling stands for?

Signaling

Signaling is the process used by the peers to exchange their connection data before the session is started. We need a server to do this that knows the peers involved in the exchange information. WebRTC leaves this process to your choice to make it as open as possible. I will explain how this process works if two peers where to connect to each other.

So the signaling process steps are the following:

- First of all, our local peer set its session description as its local description.

- In the second step of the process the local peer creates an offer with its session description and then sends that information to the other peer though the server. The information sent contains the type of the message, that in this case will be offer and the sdp. This sdp is a message where the peer says what they want to receive (i.e video and audio) and many other technical stuff.

- The second peer will receive this information and on realizing that is an offer request, it will store the session description information that just arrived as remote description. Then it will create an answer to the offer received. Once the answer is created, it will store locally its session description and will send this description back to the first peer.

- As our local peer receives the answer, it will store the session description that arrived as remote description.

- After doing that, they can connect to each other using the stream they have exchange during the process.

- Now, both peers will exchange its Ice Candidates, that contains the information they both need to connect to each other.

- After this last step, the connection should be set and running, so they can exchange media.

Stun and Turn servers

Seems simple, right? There is just a small problem to solve here. Most connections work behind a firewall so the connection will be refused if we don’t cover a couple of steps more. To make the connection possible we can use a Stun server that will help us getting the direction of the peer on the other side of the connection. To do so we can set the direction of this server as Ice Server in our peers so they will communicate with the server in case they can’t make the connection. There are a few free different servers out there that we can ask in other to get the information we need.

Sometimes this won’t help on making the connection possible as the peers security is higher. In this case we will need a Turn server to make the connection possible. The different between a Stun server and a Turn one is that the Stun server will only help us getting the info to connect to the other end of the conversation and once this process the peers can talk with each other without the need of a server in the middle whereas the Turn server will act as an intermediary peer between the two that are talking. The peers will send the media to this server and it will manage to send it to the others peers. These kind of servers aren’t available for free as they need a big computational power to run them and the media exchange takes many resources from them.

After all this process our connection should be running and the call should have started.

Thanks you for reading the post, I’ll go into now into more detail on how to make an Android WebRTC app in the following posts.