Behind the seemingly seamless experience of WebRTC is a sophisticated network of servers and protocols that manage real-time, peer-to-peer connections across browsers, native applications, and media servers. Setting up and maintaining these connections requires various steps, each essential for reliable and efficient communication.

In this post, we’ll dive into two key components of this infrastructure: STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers. We’ll explore their functions, how they operate, and how to correctly integrate them into your WebRTC application to ensure a smooth, stable connection.

WebRTC’s Peer-to-Peer Nature

WebRTC enables peer-to-peer, real-time communication between two or more participants. This allows web browsers, native applications, and media servers to directly exchange media and arbitrary data with each other.

To establish this connection, peers first engage in a process called signaling. Through signaling, they share information about the media format and the communication methods they’ll use.

As part of this process, they exchange IP addresses and specify TCP or UDP ports through which they’re available to receive media and data. These sets of addresses and ports are known as ICE candidates.

Peer-to-peer in a NAT World

In an ideal world, where every peer has its own unique and publicly accessible address, establishing connections would be straightforward.

Unfortunately, this isn’t the case. Peers often reside behind private networks that impose restrictions. To communicate with the outside world, they must perform a process known as Network Address Translation (NAT).

NAT allows multiple devices within a network to share a single publicly reachable IP address, using different network ports to differentiate them. As a result, peers use such an IP address and its associated port as ICE Candidates. However, this isn’t always sufficient in some scenarios.

Another option is to negotiate with an external server, which can relay data between peers when a direct connection is not possible. The server’s IP address is then included as another ICE Candidate.

But how does a peer determine its public IP address? How does the communication with the relay server work? And what happens if network conditions change during the connection?

These challenges are managed by the Interactive Connectivity Establishment (ICE) protocol.

ICE, STUN & TURN

The ICE protocol not only establishes the connection between peers but also ensures that the connection remains active if network conditions change.

To manage this, the protocol relies on a set of servers that are defined during the signaling process. Such servers, often called ICE servers, are the STUN/TURN Servers.

A STUN server provides peers with their identity outside the private network they live in. Essentially, a STUN server reveals the peer’s external IP address and port assigned during the NAT process.

On the other hand, TURN servers receive media on behalf of the peer and relay it to them. This typically happens when a peer is behind a restrictive network, such as a corporate firewall, or when symmetric NAT is used.

Choosing the Right STUN/TURN Servers for Your WebRTC Application

Building a WebRTC application and wondering how to properly integrate STUN and TURN servers? Let’s clear up the confusion and guide you toward the best choice for your project.

STUN is straightforward – it’s practically costless and usually comes bundled with TURN servers anyway. TURN is where the real decisions (and costs) come in.

The Easy Button: Managed TURN Services

Here’s the TL;DR: Unless you have a compelling reason not to, go with a managed TURN service. Companies like Twilio offer this at around $0.400/GB (based on the region). Trust me, this is a bargain considering what you get! 

Why does a managed service make sense here?

1. It Just Works™

• Integration takes hours, not weeks.
• Best practices are baked in.
• No need to be a TURN server guru.

2. Economics That Make Sense

• Pay as you grow.
• No upfront infrastructure costs.
• Only pay for what you actually use (not all traffic needs TURN).

3. Global Scale Out of the Box

• Multiple regions? Covered.
• Scaling issues? Not your problem.
• Edge cases? They’ve seen them all.

4. Future-Proof

• Want to switch providers? No problem.
• Need to self-host later? That bridge can be crossed when you come to it.
• No vendor lock-in to worry about.

The DIY Route: Self-Hosted TURN Servers

I know some of you are already rolling up your sleeves, eager to build your own TURN infrastructure. Before you dive in, let’s talk about when this actually makes sense.

Here’s when to consider self-hosting:

1. The Regulation Game

• Need complete data sovereignty?
• Dealing with strict privacy requirements?
• Working in a heavily regulated industry?

Then yes, self-hosting might be your only option.

2. The Scale Factor

• Are you spending tens of thousands of dollars monthly on TURN services?
• Do you have massive traffic volumes?
• Already have a global infrastructure footprint?

At this scale, building your own starts to make financial sense.

3. Network Control Freaks (In a Good Way)

• Need specific, custom configurations?
• Running specialized packet acceleration?
• Have specific infrastructure integration requirements?

These could be valid reasons to go DIY.

4. Firewall Constraints

• Customers with strict IP range requirements?
• Existing firewall configurations that match your infrastructure?
• Need complete control over server addressing?

Self-hosting might simplify your life here.

Choosing the Right STUN/TURN Path for Your WebRTC Application

Integrating STUN and TURN servers is a crucial step in building a WebRTC application. While STUN servers are relatively straightforward, TURN servers require more consideration due to their associated costs. 

For most use cases, managed TURN services offer a convenient and cost-effective solution, providing ease of integration, scalability, and future-proofing. However, self-hosting TURN servers may be necessary for organizations with specific regulatory, scaling, or network control requirements. 

Ready to take your WebRTC application to the next level with reliable and scalable STUN and TURN server integration? At WebRTC.ventures, our team of experts has years of experience in designing and implementing custom WebRTC solutions, including STUN and TURN server setup and management. Contact us today and let us know how we can help! Let’s make it live!