Real-time communication is now a core feature of many web-based applications, from video calls and online classrooms to telehealth services and IoT systems. These interactions depend on fast, reliable data exchange between devices, often without any manual setup by the user.
A key technology that makes this possible is Web Real-Time Communication (WebRTC), an open-source protocol that allows browsers and devices to share video, audio, and data directly, without needing third-party plugins or software.
In an ideal scenario, WebRTC enables two devices to communicate directly using a peer-to-peer (P2P) connection. However, in real-world networks, factors like firewalls and corporate network restrictions can obstruct direct communication.
When a direct connection isn’t possible, WebRTC relies on what are called Traversal Using Relays Around NAT (TURN) servers to act as intermediaries, ensuring a stable and reliable connection. By transmitting all data between peers, TURN becomes a critical fallback mechanism for real-time communication applications.
TURN acts as a sort of mail delivery service – one device sends the package to a central server, which then sends the message to another device. Here, I’ll explain more about how this works and why it matters in WebRTC.
CTA Video Demo Our full-stack demos give you access to the Nabto Platform so you can try it now. We specialize in secure, low-latency, P2P connectivity. Get the demo app to try it.
Set up a simulated IoT Video surveillance device on your PC in minutes.
What is TURN?
If you’ve ever joined a video call from a network with strict security settings – like those often found in corporate offices – or streamed a multiplayer game over hotel Wi-Fi, or used a remote desktop app over a mobile network, there’s a good chance a TURN server was working behind the scenes to keep your connection stable.
To understand how TURN fits into the WebRTC ecosystem, it helps to look at how these real-time connections are established. When two peers try to start a WebRTC session – whether it’s a video call, a sensor stream from an IoT device, or a screen-sharing session – WebRTC uses a process called ICE (Interactive Connectivity Establishment) to find the most effective path between them.
ICE first tries to create a direct, peer-to-peer link using STUN (Session Traversal Utilities for NAT). This lightweight protocol helps each device discover its public-facing IP address and port as seen from the outside network – information that’s critical for routing traffic through NATs and firewalls. NAT, or Network Address Translation, is a common networking technique that allows multiple devices on a private network to share a single public IP address, but it can also block direct peer-to-peer connections. If a direct connection isn’t possible, because of restrictive network settings, firewalls, or symmetric NATs, ICE turns to TURN.
In a TURN-based connection, one or both devices contact a TURN server to request a relay address. The TURN server assigns a temporary public address and begins acting as an intermediary, forwarding all packets between the two endpoints. This keeps the session alive even in locked-down environments in which direct links aren’t an option.
Unlike STUN, which is used only during setup, TURN remains active throughout the session. It handles every packet – voice, video, or data – requiring a persistent connection and robust infrastructure to avoid performance bottlenecks.
Because TURN servers do the heavy lifting – receiving, processing, and relaying all traffic – they consume more resources and can introduce additional latency. But for many real-time applications, including enterprise video conferencing, cloud-based gaming, telehealth, and remote collaboration, that trade-off is worth it. TURN ensures these apps remain usable, even under challenging network conditions when other connection methods fail.
When Is TURN Necessary?
TURN is not used in every WebRTC session – only when required. Some common scenarios where TURN becomes essential include:
- Symmetric NATs or restrictive firewalls that prevent STUN from functioning.
- Corporate or enterprise networks with locked-down configurations.
- Mobile networks with complex routing paths.
- Cross-geography connections in which network paths aren’t optimized for direct links.
In these cases, TURN ensures that communication continues uninterrupted, even if at the cost of higher latency or bandwidth usage.
Security and TURN Servers
TURN servers are not just about maintaining connectivity – they’re also a critical line of defense in securing real-time communications. Because they handle the entire stream of data between peers, TURN servers have full visibility into all transmitted content. That makes them a sensitive part of the WebRTC architecture and a potential target for misuse, so they must be protected accordingly.
To ensure data is secure during transmission, TURN servers typically use encryption protocols such as TLS (Transport Layer Security) or DTLS (Datagram Transport Layer Security). These protocols encrypt the media and data streams, making it difficult for unauthorized parties to intercept or tamper with the information in transit.
Authentication is another important layer of protection. TURN servers usually employ long-term credential mechanisms, requiring the connecting application (or client device) to provide a valid username and password before allocating a relay address. This helps ensure that only authorized users and systems can access the server’s resources.
Administrators can further strengthen security through access control measures, such as IP whitelisting or the use of Access Control Lists (ACLs). These configurations restrict server access to known or trusted networks, reducing the risk of abuse or unauthorized traffic.
In environments in which data sensitivity is paramount – such as in healthcare, finance, or enterprise communications – these security features are essential. They ensure that TURN servers do more than relay data – they help preserve the integrity, confidentiality, and trustworthiness of every real-time session.
Optimizing TURN Deployment
Because TURN servers are resource-intensive, it’s important to deploy them thoughtfully to balance reliability and cost. One key strategy is geographic distribution – placing TURN servers in multiple regions reduces latency by bringing the relay point closer to the communicating peers. This is particularly useful for applications with a global user base. In addition, using load balancing and autoscaling ensures that TURN infrastructure can handle varying traffic volumes without performance degradation or manual intervention.
Another key factor is maintaining a high peer-to-peer (P2P) connection ratio. WebRTC applications try to establish as many direct connections using Session Traversal Utilities for NAT (STUN) as possible. A high P2P ratio reduces the need for relaying traffic through TURN servers, which helps cut down on bandwidth costs and improves performance. However, the algorithms inside modern browsers determine whether a direct connection is possible, meaning developers have limited control over the actual P2P ratio achieved. Still, designing systems with this goal in mind—favoring STUN-first connectivity—can help reduce unnecessary reliance on TURN.
To keep costs under control, developers should configure WebRTC applications to use TURN only when necessary. The system should first attempt to establish a direct connection using STUN and only fall back to TURN when firewalls or NAT types make that impossible. Monitoring bandwidth usage is also essential, as TURN traffic can grow rapidly in data-heavy applications like video streaming or high-frequency IoT data relays. With careful planning, developers can ensure TURN enhances reliability without introducing unnecessary overhead.
TURN Supports IoT
TURN is widely used in WebRTC applications, but its significance extends beyond traditional video conferencing. It plays a crucial role in IoT deployments that rely on consistent, real-time data transmission across complex or restricted networks.
In smart security systems, IP-based surveillance cameras in office buildings, warehouses, and retail environments often encounter restrictive NAT configurations that block direct peer-to-peer connections. TURN servers help these cameras relay live video feeds to remote monitoring centers without interruption.
In medical IoT, connected health devices – such as continuous glucose monitors, cardiac telemetry tools, and other remote patient monitoring systems – must comply with strict hospital network security policies. When direct communication is blocked, TURN ensures that sensitive health data reliably reaches centralized clinical dashboards or care coordination platforms.
In industrial automation, facilities use IoT sensors to monitor everything from equipment wear and vibration to temperature, humidity, and inventory flow. TURN enables these systems to maintain real-time communication with analytics platforms and control systems, even in environments where internal network restrictions might otherwise disrupt data flow.
Final Thoughts
TURN servers are an indispensable part of the WebRTC ecosystem, acting as the reliable safety net when direct peer-to-peer connections are not feasible. In many real-world network environments, devices are protected behind NATs, firewalls, or stringent corporate security policies that effectively block or complicate direct communication. Without TURN, these restrictions could severely degrade the user experience or even prevent real-time communication altogether.
For developers and network architects, understanding TURN’s role within WebRTC is key to designing systems that balance performance, cost, and user experience. By carefully evaluating when and how TURN is used – favoring direct peer-to-peer links whenever possible but gracefully falling back to TURN when necessary – applications can deliver the best possible connectivity to users worldwide.
In short, TURN servers aren’t just a fallback mechanism. They are a foundational technology that enables the resilient, secure, and real-time interactions that modern digital communications demand.
Read Our Other Resources
We’ve published a range of resources for our community, including:
