WebRTC is a simpler, easier future of softphone calls

If we want to define WebRTC (Web Real-Time Communication), we present it as a set of standards, capable of setting up an instantaneous communication system that can be used from the browser. The implementation of such a system is based on solutions that boil down to the deployment of a well-defined module, in some cases requiring very specific expertise. In what follows, we will elucidate how this tool works, through an exploration of its basic techniques.

The main idea behind WebRTC is to simplify video, audio, and data communication.

On the browser pane, the WebRTC consists of 3 complementary APIs, which are :

  • The MediaStream (GetUserMedia)
  • PeerConnection
  • DataChannel

The first component provides access to the user’s various media. In other words, their input/output devices (their webcam, microphone, and screen sharing). The second component, considered the backbone of WebRTC, manages the encoding and decoding of the data stream. This management in turn allows the management of the peer-to-peer connection between any two users. Finally, the DataChannel allows you to apply control over the transmission of data between two terminals.

The operation is as follows: if a terminal A wishes to start a communication, then the latter must generate an offer. Technically, this offer is called SDP (Session Description Protocol), it indeed has a very specific format containing a collection of information about the terminal (for example, the access path to be able to reach it, the codecs that are there. used, etc …). After generating this offer, terminal A will transmit its offer to terminal B.

Once terminal B has received said offer, it, in turn, generates an offer which contains all the information relating to it to send it to terminal A. Once the two respective terminals A and B have their mutual offers, they can establish peer-to-peer communication. In this case, there is no longer a need for a third-party server to be able to communicate and exchange with each other without any problem. Unlike other older technologies, there is no longer an intermediary at this level.

With all the pre-described operations, you must be able to manage the firewalls. If you have the IP address of a terminal, this does not mean that it is possible to communicate with it.

So, a key question arises, how to be able to route the messages?

You have to use two servers, of great importance.

The STUN Server (Simple Traversal of User Datagram Protocol) is a server that must be requested to obtain the identification of the route to take to reach us. But on the other hand, the public IP address of a terminal is not sufficient to reach it. At this point, another server intervenes, the TURN server.

The TURN Server (Traversal Using Relays around NAT) will be responsible for redirection of traffic. However, this server has a limit, in terms of the bandwidth it consumes, since it will ensure the transmission of all the data received.

Moreover, communications involving more than two people create bandwidth difficulties. For example, if 4 people want to communicate with each other in peer-to-peer, the bandwidth will be overused, because if terminal A transmits a stream, it will be sent to user B, then to l user C and finally to user D. To solve this problem an MCU (Multipoint Control Unit) server is used to retrieve the data of all people and retransmit them.

WebRTC integrates a set of tools, capable of setting up an instantaneous communication system in real-time, offering only the basic part of the system. Voicespin is at the forefront of new technologies, with an array of super-efficient and useful services that adapt to all circumstances. At Voicespin, we have adjusted our clocks, and we have also made ourselves compatible with WebRTC.

So, if you’re interested in using this technology, ask our Support team by emailing support@voicespin.com.