STUN and TURN servers are two types of WebRTC signaling servers that can be used to create your peer-to-peer (P2P) connection when you are building a real-time communication application. Signaling is not part of the WebRTC standard and thus needs to be handled separately if you are building the application yourself rather than using a commercial platform (more on this later!) 

If you are a visual learner, we have embedded a WebRTC Tips by WebRTC.ventures video below entitled, “What are STUN and TURN servers?” Or, read on.

The Basics

When we talk about WebRTC at its most basic level, we’re talking about a peer-to-peer connection between two browsers. There are of course more complicated scenarios. But for the purposes of this post we will stay focused on this very simple scenario of two participants joined by a peer-to-peer connection for the exchange of real-time communications–be it voice, video, audio, or messaging data.

Before a conversation can be had, you have to establish that connection. To do this, you need a signaling server to coordinate some very important information. This is where STUN and TURN servers come in. They are a part of the handshaking process known as “signaling.” 

The Preferred Choice: STUN

A STUN (Session Traversal Utilities for NAT) server is what you are going to use most of the time. It is the preferred choice for your signaling server. For each browser/each participant in that WebRTC connection, it asks and answers the question, “What is your IP address?” This is essential because if we are going to have a peer-to-peer connection directly between two parties, then we have to have a unique identifier for each of those browsers. That identifier is the IP address.

For the vast majority of WebRTC calls, a STUN server is going to be able to make this identification for each member and use that to establish the peer-to-peer connection. It is simple, quick, and does not create much load. Sometimes, however, the STUN server can’t get the job done.

Your Backup Plan: TURN

There are times when you cannot get the unique IP address of one or both parties. Corporate or government networks, for example, often restrict access to this information. They use firewalls to protect the direct IP address of the machines inside. When it is impossible to communicate directly with one peer, you must turn to a TURN server. 

A TURN (Traversal Using Relays around NAT) server goes around the network address, essentially traversing the connection using relays. So when a STUN server cannot establish a connection between the two parties, the TURN server steps in as an intermediary. 

TURN = bad?

This doesn’t sound good, does it? It is certainly not ideal for our WebRTC connection. For one, it will introduce some latency to the call. But the only alternative if you can’t get that unique IP address from the STUN server is simply not to connect. So, TURN is better than nothing. And, the vast majority of the time you can connect once you are using the TURN server. 

The more important negative factor is that a TURN server will add cost to your infrastructure. The relaying adds more load than you would have on a simple STUN server. The more often you have to use the TURN server and the more traffic you are directing through it, the bigger TURN server (or farm of TURN servers), you are going to need. 

So, you want to use TURN servers as little as possible. One way around this is using commercial WebRTC platforms, for example Vonage or Twilio for your WebRTC media server. Microsoft has also launched its own CPaaS, Azure Communication Services, which we discuss here. In addition to writing your code, a CPaaS will handle signaling for you. Of course, as a commercial service, this comes at a price. For more about weighing open source vs. CPaaS, check out this WebRTC Tips video. If you are interested in what our CEO and Founder, Arin Sime, believes is on the horizon for the CPaaS marketplace and WebRTC in general, check out his Trends for WebRTC development in 2021.

Additional resources on STUN and TURN:

https://github.com/coturn/coturn

https://webrtcglossary.com/turn/

https://bloggeek.me/webrtc-turn/

https://webrtc.org/getting-started/turn-server

https://www.callstats.io/blog/2017/10/26/webrtc-product-turn-server

You can also check out this video from our team on STUN and TURN:

If you are looking for an experienced team to build your custom WebRTC application, check us out at www.webrtc.ventures today!