Traversal Using Relays around NAT

Description

Traversal Using Relays around NAT (TURN) is a network protocol designed to facilitate real-time media communication, such as VoIP and video conferencing, between endpoints that are behind Network Address Translation (NAT) devices or restrictive firewalls. It operates as an extension of the STUN (Session Traversal Utilities for NAT) protocol, using a TURN server as an intermediary relay in the public internet. When direct peer-to-peer connectivity is impossible due to symmetric NATs or firewall policies, TURN enables endpoints to establish a connection by sending all data through the TURN server, which forwards traffic between the parties. The protocol is standardized by the IETF (RFC 5766, updated by RFC 8656) and is widely used in 3GPP IMS (IP Multimedia Subsystem) and WebRTC frameworks for reliable session establishment.

Architecturally, a TURN deployment includes TURN clients (e.g., user devices running communication applications), TURN servers (publicly accessible relay nodes), and peer endpoints. The TURN client first discovers the TURN server using STUN mechanisms, then allocates a relayed transport address (IP address and port) on the server through a TURN Allocate request. This address is shared with the peer via signaling protocols like SIP (Session Initiation Protocol), allowing the peer to send data to the relay address. The TURN server forwards incoming packets from the peer to the client, and vice versa, using ChannelData messages or Send/Data indications. Key components include the allocation lifetime management, permissions to control which peers can send data, and integrity protection via message authentication.

In operation, TURN works in tandem with ICE (Interactive Connectivity Establishment) to determine the optimal network path. During ICE candidate gathering, the TURN server provides relay candidates, which are prioritized lower than host or server-reflexive candidates from STUN. If direct or NAT-assisted connections fail, ICE falls back to using the TURN relay, ensuring connectivity at the cost of increased latency and server load. TURN supports both UDP and TCP (including TLS-secured) transports, with mechanisms for congestion control and bandwidth management. In 3GPP networks, TURN servers are often deployed as part of the IMS architecture, specified in TS 23.334 for WebRTC interworking, to guarantee service continuity for voice and video calls across diverse network environments.

Purpose & Motivation

TURN was created to solve the critical problem of NAT and firewall traversal for real-time communication protocols, which often fail in peer-to-peer mode due to restrictive network policies. As internet usage grew in the 2000s, NATs became ubiquitous to conserve IPv4 addresses, but they broke end-to-end connectivity by hiding private IP addresses. While STUN could handle many NAT types by discovering public addresses, it failed with symmetric NATs, where port mappings are unique per destination. Firewalls further blocked unsolicited inbound traffic, preventing direct media streams. TURN addressed these limitations by providing a guaranteed relay path, ensuring that applications like VoIP and video conferencing could work reliably in all network scenarios.

The motivation for TURN emerged from the IETF's work on ICE and WebRTC, aiming to standardize a fallback mechanism for worst-case connectivity. In 3GPP, TURN gained importance with the adoption of IMS for multimedia services and WebRTC for browser-based communication, starting in Release 7. It solved interworking challenges between mobile networks (often behind carrier-grade NATs) and external internet endpoints, enabling seamless services like VoLTE and video calls. By relaying traffic through a controlled server, TURN also offers operators a point for traffic management and security enforcement, though it introduces additional latency and resource costs compared to direct connections.

Key Features

• Relayed transport address allocation on a public server for NAT/firewall traversal
• Support for UDP, TCP, and TLS transports to accommodate various network policies
• Integration with ICE framework as a lower-priority candidate for connectivity fallback
• Permission mechanism to restrict data forwarding to authorized peer endpoints
• Lifetime management for allocations with refresh mechanisms to conserve resources
• Message integrity and authentication using STUN-based security (e.g., long-term credentials)

Evolution Across Releases

Defining Specifications