Media And Signalling Model In WebRTC

WebRTC is widely used by the developers for establishing real-time communications over Peer-to-Peer network. WebRTC enables browser-to-browser web applications such as voice calling, video calling and Peer-to-Peer media sharing. But do you know how the webRTC model actually works? In case you don’t, this blog might be useful for you. In this blog, we’re going to show you what happens when you make a P2P call using WebRTC, the underlying architecture of WebRTC and the internal processes.

Also read Recording Video Sessions Using WebRTC.

Process Behind P2P Calling

Let’s take an assumption that two browsers are connected via an application server. The application server connects two browsers and is responsible for signalling and media sharing. Another entity which finds its use in the underlying process is the ‘STUN’ or ‘TURN’ server. However, the role of STUN/TURN server is not much significant but yet it can’t be overlooked. So let’s see how it works!

In webRTC model, all the signals from both browsers are received by the application server which connects them. Once, the connection is established, the media can be transferred directly between the browsers. This is what happens in a P2P call. But now the question worth asking is that “what does STUN server has to do with all this?” Well, it does play a trivial role as we said earlier. But what is it then? When the connection is established between the two browsers and signalling takes place, there is also a small proportion of signals flowing from the two browsers toward the STUN/TURN server for many reasons. For instance, it is crucial for obtaining the public IP addresses of the web browsers.

Basic Phenomenon Behind A Relay Call

The Relay Call is where STUN/TURN server finds some real substance. In absence of the Peer-to-Peer functionality, the two browsers can’t share media directly over the web even if they are connected via an application server. There has to be a third entity to facilitate the media sharing process. That’s where the STUN/TURN server comes into action. In this case, the TURN server facilitates the media transfer.

Let’s suppose we have two browsers (B1 and B2). They are connected by the application server (Q) in such a way that it forms a triangle (B1QB2). When a relay call is to be made, the browser (B1) should transfer media to the browser (B2). But it can’t do so directly. So a TURN server (T) is used in between to facilitate the process. In such case, the browser B1 transfer media to the server (T) from where it is directed toward B2. That’s how the media sharing takes place in a relay call.

The Centralized Signalling Model

The centralized signalling model is used when the media is to be processed or analyzed in between before reaching the end browser. As the media sent from browser-to-browser is protected by the end-to-end encryption, the ordinary signalling model can’t be used for analyzing the data or recording webRTC calls. And it can’t be done even by the TURN server.

That’s where a Media Server is used. The Media Server divides the process into two halves or two webRTC sessions. It acts as a termination point for the incoming media from the first browser. This is where the first session ends and this is where a new session begins. The media can be analyzed and processed at this termination point and the calls can be recorded as well. Further, this forms a centralized signalling model where the media server is in-control of the media flow from browser-to-browser.

Oodles Technologies is among the top rated WebRTC Service Providers across the world. We are a leading software development company based in India, providing SaaS Development Services. We also have expertise in Live Video Streaming, Blockchain App Development, Big Data and WebRTC Software development.