WebRTC is a fantastic technology that allows users to communicate with each other in real-time. While on the surface, it looks like participants don’t need anything more than a browser and a good internet connection to start communicating, underneath the surface, there is a complex architecture of signaling servers that developers need to instruct in order to deliver data from one peer to another.
What are signaling servers?
Even if based on a peer-to-peer protocol, WebRTC connections can't run without a server. In order for two devices to locate one another, a discovery and negotiation mechanism called signaling must take place.
Since this process is not offered by the WebRTC API itself, developers need to establish a framework that allows WebRTC to overcome the complexities of real-time communication.
What is a STUN server?
As mentioned before, exchanging real-time communication (video, audio, screen sharing and other data) requires devices to connect to a mutually agreed upon server. STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers are both used in the signaling process but for different reasons.
Before establishing a peer-to-peer connection, it is essential for servers to identify the IP address for each participant. WebRTC applications use STUN servers most of the time. They are straightforward, quick, and most importantly, they don’t create much load.
Additionally, they are applied only during the connection setup for discovering and exchanging external host:port-pairs. Once the session has been established, media will be exchanged directly between participants. Nevertheless, STUN is sometimes restricted by firewalls. Therefore, developers need to "turn" and utilize a TURN server when STUN fails.
What is a TURN server?
Firewalls and closed corporate environments can limit access to the IP address. Without unique identifiers, it becomes unfeasible for two networks to find each other. This problem can be solved by using TURN servers as a middleman. Unlike STUN, a TURN server remains in the media path after the connection has been established.
However, using this walk-around can add some latency to your video conference. On top of that, it can also increase the operational costs of your IT infrastructure. The more traffic you direct to your TURN server, the more complex infrastructure you will need.
Conclusion
Real time video communication comes with a series of challenges. Even if WebRTC is designed to work peer-to-peer, it still requires building a whole signaling architecture behind it. This means that scaling up requires an additional investment in server infrastructure. One of the main key benefits of video APIs is freeing developers from dealing with this complexity.
CPaaS and VCaaS platforms can handle the signaling processes, accommodating large and frequent load changes. This way, developers can dedicate more time developing their applications. Relying on video engines that already take care of the signaling process can be a game changer!
