In this article, we are going to learn about TURN servers What are TURN servers, how do they work and much more.

Definition of TURN server

A TURN (Traversal Using Relays around NAT) server is an important component in Real Time Communication (RTC).

During peer-to-peer networking, instead of peers sending the data directly to each other, the TURN server acts as a middle man.

This ensures that even if one or both the peers are behind restrictive NATs or firewalls they can send data to each other.

NAT traversal Challenges

NAT (Network Address Translation ) is a technique that is used by routers to allow multiple devices that are on a private network to use a single public IP address.

This technique is good for conserving IP addresses and improving security, it does create some challenges

  1. Blocked inbound traffic: NAT blocks unsolicited inbound traffic for devices on a private network.
  2. Different NAT types: There are different types of NAT (full cone, restricted cone, and symmetric NAT) each of these mapping internal IP port combinations
  3. Connection Complexity: The direct peer to peer connections can be unpredictable and often fails without additional help like TURN servers.

TURN Server importance in Real time communication

1.Ensuring Universal Connectivity

In real time communication scenarios, when you are using WebRTC, the goal is to establish peer to peer connection. But there are challenges

  • Many NAT environments: There are all sorts of different users that are on different networks with behind different NAT and firewall types. This results in direct p2p connections failing.
  • Reliability: A turn server solves this problem by being the middleman and guaranteeing that users can always connect. This is important for voice calls, video streaming and interactive sessions.

2.TURN Server Role in WebRTC and Other RTC Applications

In WebRTC, ICE uses STUN and TURN to determine the best path that can be used for data transmission.

A TURN server is only used when the STUN server fails to connect the users directly

  • Fallback Mechanism:

If the direct connection is not possible then the TURN relays audio, video and data streams between participants.

  • Maintaining Quality of Service (QoS):

TURN servers offer performance optimizations thus making sure that the relayed traffic is smooth and latency free as possible.

This is many times not possible when using STUN servers. Many corporations for this reason do not use STUN servers in their ICE array

  • Security and Encryption

TURN servers support TLS /DTLS for secure transmission, which is very important in privacy focused real time applications.

Distinctions from other NAT Solutions

There are other NAT traversal solutions as well besides the TURN servers.

Here are some of the commonly used solutions

  • STUN (Session Traversal Utilities for NAT):

STUN tries to discover the client devices public IP address and port mapping so that the peers can establish a direct connection. However the STUN servers do not relay data and fails in restricted NAT environments and firewall rules

  • TURN ( Traversal using relays around NAT):

TURN servers relay the data between peers and hence is the sure shot way to establish a connection between peers. Some TURN server services such as Metered.ca TURN servers uses port such as 80 and 443, these services work under the most restrictive NAT and firewall rules

  • UPnP/Port Forwarding:

These approaches require manual or automatic port configuration on the routers and do not handle all NAT types – especially those managed by ISPs and large corporations

  • VPN based solutions:

VPN based solutions can bypass NAT restrictions by tunnelling the traffic these introduce new and additional considerations and overloads that must be taken into account. Thus traditionally STUN and TURN servers are preferred. Understanding NAT and the Evolution of TURN

A. Network Address Translation (NAT basics)

  1. Purpose of NAT
    1. IP Address Conservation: NAT allows multiple devices on a private network to use a single Public IP address. This was done to preserve the limited pool of IPv4 addresses
    2. Added Security Layer: NAT also provides a layer of security, because it does not allow devices outside the private network to directly reach devices that are behind the private network.
  2. How NAT works and why it creates communication barriers
    1. Translation Process:
      1. Whenever a device which is behind the nat tries to connect to the internet.
      2. NAT rewrites the device's IP address with the routers public IP address and then assigns a unique external port.
      3. Inbound responses are then mapped to the correct device using this port number.
    2. Inbound connections are challenging
      1. Because the NAT often blocks unsolicited traffic from the internet, direct peer to peer connections are difficult unless NAT is specifically configured to allow inbound traffic
  3. Different types of NAT
    1. Full Cone NAT: This is easiest to traverse, one internal device can has mapped a port then external devices can send data to that port from any IP.
    2. Restricted Cone NAT: More selective form of NAT, here external hosts must match the IP address from which the internal device has received the traffic.
    3. Port Restricted Cone NAT: Even more restrictive then restricted cone NAT, here the external host has to match both the IP address and the port number of the client devices to which it wants to send the traffic.
    4. Symmetric NAT: Most restrictive, here it is impossible for the external device to send traffic to client device that is behind the NAT as the NAT changes the IP address and port number of the client device after every request.

B. STUN vs TURN

  1. Key Differences
    1. STUN (Session Traversal Utilities for NAT)
      1. Goal: The goal is to discover the client devices public IP address and port number. This is to facilitate peer to peer connection
      2. Limitation: If the peer are behind restrictive NAT or firewall rules that block external traffic form coming in then STUN does not work.
    1. TURN
      1. Goal: Provides a relay around NAT when direct connections are not possible between peers
      2. How it works: Clients allocate a relay address on the TURN server and all the traffic flows through the relay.
      3. Resource cost: TURN is more resource intensive it requires CPU and Bandwidth, you can go with a TURN server service provider such as Metered.ca TURN service for this
  2. Why TURN Provides a more complete solution
    1. Guaranteed connectivity: With TURN, you can connect to the devices even with the most restrictive NATs
    2. Fallback mechanism: WebRTC ICE framework tries STUN first for direct connections. If STUN fails then it automatically tries TURN to connect the devices.
    3. Flexibility: TURN can handle complex enterprise NAT or firewall settings where simple methods fail.
  3. Common Scenario When STUN fails and TURN is Required
    1. Symmetric NAT: Each new outbound connection request us assigned a unique external port, thus this makes it impossible for external peers to connect back directly
    2. Corporate Firewalls: Some networks block inbound connections or specific traffic types, forcing the need for relay.
    3. Carrier-Grade NAT (CGN): Large Internet service providers often keep their users behind a huge NAT. They do this because they have a fewer IP addresses that they need to distribute among large number of subscribers.

c. When and Why are TURN servers become Essential

  1. High-Level Use Cases (Behind Symmetric NAT)
    1. Enterprise Environments: Many Corporations have advanced firewall and security so as to protect their business information. TURN makes sure there is stable video conferencing, VoIP calls and real time data transfer.
    2. Geographically Distributed Users: Global users often have different NAT types and are located far away from each other. A TURN server unifies connectivity so that sessions are not disrupted by local network.
  2. Examples of Applications that Relay on TURN Servers
    1. Video Conference Platforms: Services like Google Meet, Zoom, and Custom WebRTC based apps rely on TURN to ensure call quality.
    2. Voice over IP (VoIP) Services: Real time audio and data streams can be transmitted using TURN servers
    3. Online Gaming: Multiplayer online games need peer to peer connectivity with low latency. TURN servers help connect users that are behind different NATs
    4. IoT and Smart Home Devices: Connected IoT devices are behind Home routers and NATs. TURN servers help the devices communicate with external servers and each other using TURN servers

How does a TURN server Work (technical deep dive)

A. TURN Protocol Overview

  1. High level explanation of the TURN request/response cycle
  • Shared Messaging Format: Turn builds on the STUN protocol format (RFC 5389) . The TURN specific req and res use STUN message headers and attributes
  • Allocation of Relay resource:

When a client sends an Allocate request to the turn server, the server responds back with a relayed transport address that the client can share with its peers.

  • Message Types:

TURN extends the STU protocol with additional requests for example the CreatePermission and ChannelBind requests. These requests ensures that the client can securely send and receive data.

  • Lifetime Management

Allocations are time bound and must be refreshed from, time to time otherwise the server reclaims the allocation

  1. RFC Standards and protocol; References (RFC 5766)
  • Primary specification: The RFC 5766 outlines the TURN protocol including the requests, responses, message attributes and security mechanisms
  • Security Extensions: The security extension are often used alongside RFC 6062 (TCP relaying) and RFC 6156(IPV6 Support) in order to handle complex scenarios
  • Interplay with ICE (RFC 5245)
  • In Webrtc the TUNR server is typically used through ICE automatically if simpler STUn based methods fails

B. Key workflow steps

  1. Allocation: How can clients request a relay allocation
  • The client sends allocate request: The client sends a allocate request to teh server along with details like the transport protocol (UDP or TCP) and desired timeline
  • Server responses with relayed address. If the requested is authenticated and allowed by the TURN server then the server sends a relayed transport address and IP port which peers can use to send data
  • Security and authentication:TURN servers used long term credential mechanism, the client must present a valid credential for the allocation
  1. Creae Permissions: Making sure secure peer verification
  • permission creation : Once allocated the 'relayed transport address by the turn server then the client must decide which peer IP addresses are allowed to send traffic through the relayed address. This prevents unauthorized forwarding
  • Secure Communication: each CreatePermission request has limited lifetime and must be refreshed periodically if the client wants to access the data from the peer devices.
  1. Sending data Vs channel binding
  • Send/indication method:

Client can use the Send and Data indicators to push data to the clients.

This is a simpler method but is less efficient because each packet that is send requires a STUN header

  • Channel binding:

Here the client binds to specific channel number to peer IP port number like IP:Port

Once the binding is done the data can be replayed with less overhead as compared to the Send/Data indicators.

This approach is often used in high throughput scenarios

C. Performance and Resource Considerations

High bandwidth usage considerations for high scale deployments

  • Higher Server throughput is required

Because the TURN server relays every packet incoming as well as outgoing tense high throughput turn servers are required

  • Network proximity:

The turn server needs to be near to your users for optimal performance hence if you have distributed users then going for a TURN server service provider such as metered.ca is recommended

  • Scaling strategies:

For large scale deployments multiple turn servers behind a load balancer might be required so that it can handle large volume of data.

CPU/Memory requirements and Optimization strategies

  • CPU overhead: There is large CPU overhead with running a turn server as every packet needs to be relayed by the turn server.
  • Memory usage: The server tracks client allocations, permissions and channels each requires memory. For thousands of users large amount of memory is required the is RAM
  • Optimized networking stack: High performance networking efficient kernel management and tuning in linux for example and specialized I/O frameworks are used to improve throughput.

Setting Up and Configuring a TURN Server

When setting UP and and configuring TURN servers there are basically two options, you can go for open source TURN servers like the CoTURN. Or you can consider TURN server service providers like Metered.ca TURN servers

A CoTURN : Overview

CoTURN is a popular open source STUN/TURN server implementation that fully supports TURN and STUN protocol

You can learn how to setup and install coturn on your machine here: How to setup and configure TURN server using coTURN?

B. TURN Server Service Providers

You can also consider using TURN server service providers such as Metered.ca TURN servers.

Metered.ca TURN servers

Metered Global TURN servers​

  1. API: TURN server management with powerful API. You can do things like Add/ Remove credentials via the API, Retrieve Per User / Credentials and User metrics via the API, Enable/ Disable credentials via the API, Retrive Usage data by date via the API.
  2. Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance.
  3. Servers in 12 Regions of the world: Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore,Sydney
  4. Low Latency: less than 30 ms latency, anywhere across the world.
  5. Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.
  6. Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
  7. Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
  8. Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
  9. Reliability: 99.999% Uptime with SLA.
  10. Enterprise Scale: : With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
  11. 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan

C. Verifying your turn setup

Once you have created a turn server or you have subscripted to the TURN service from Metered. You can test your TURN and STUN servers with a tool

Here is the TURN and STUN server testing tool from Metered that you can use: https://www.metered.ca/turn-server-testing

Metered.ca TURN server testing tool

  • Here Select what type of server you are testing STUN or TURN
  • Then type the server URL
  • Then Type the port number
  • Then your username or password (if required)
  • Then click on the add server button
  • You can multiple STUN and TURN servers to the array
  • Then click on the Launch Server Test Button to launch the TURN server test

Integrating TURN servers with WebRTC

A. ICE methodology and TURN

Overview of ICE (Interactive connectivity Estabkisghment)

  • Purpose: ICE is a framework used in WebRTC and other real time communication platforms. The ICE framework is used to find the best possible path for media and data to flow between peers.
  • STUN first, then TURN as a fallback: The ICE protocol first tries to connect using the STUN protocol if that fails then it tries to connect using the TURN servers

How ICE leverages the STUN/TURN

  • Candidate gathering : The WebRTC collects candidates form different sources
    • Host Candidates: Local IP address from the same network
    • Server reflexive candidates: Public IP/Port discovered from STUN
    • Relay Candidates: These candidates are allocated by the TURN server
  • Connectivity Checks: The ICE checks and tests all the available candidates, prioritizing the direct communication first and if that fails then the relay candidates from TURN servers are used by the ICE framework.

Common ICE parameters and Best Practices

  • iceServers : A list of STUN and TURN severs configurations
  • iceTransportPolicy Determines how aggressively the browser uses the TURN.
    • options include
    • all default: Tries all candidates, including host reflexive and relay
    • relay: forces the use of TURN candidates only. Many corporations prefer this option. benefits include quick connectivity, smooth jitter free connection