Glossary
STUN and TURN
STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) are protocols that enable WebRTC peers to establish media connections across NAT routers and corporate firewalls. STUN discovers public addresses; TURN relays media when direct paths fail.
General definition
Most devices sit behind NAT routers and do not have a directly reachable public IP address. STUN solves this by having each peer ask a STUN server "what does my connection look like from the internet?" The server replies with the peer’s public IP and port. WebRTC then attempts a direct peer-to-peer connection using this information via the ICE (Interactive Connectivity Establishment) process.
- STUN: lightweight, stateless, typically on port 3478 UDP; resolves public IP and port for ICE candidates
- TURN: relays all media through the server when NAT or firewalls block direct connections; higher latency and bandwidth cost
- ICE tries candidates in order: host address first, then STUN, then TURN
- TURNS (TURN over TLS) encrypts the relay for environments that block UDP entirely
TURN relay is the fallback of last resort and is needed for roughly 10-15% of WebRTC calls in practice, typically those behind symmetric NAT or strict enterprise firewalls. Running a TURN server consumes significant bandwidth because all media passes through it. Open-source implementations include Coturn; cloud providers offer managed TURN services.
In the Ethora ecosystem
Ethora’s voice and video calling configures STUN and TURN as part of the WebRTC ICE setup so that calls connect reliably for users on corporate networks, strict firewalls, or mobile carrier NAT. STUN handles the majority of connections; TURN relay ensures calls still work in restrictive network environments.
Teams running Ethora on their own infrastructure can operate their own Coturn server alongside the platform, keeping all media relay traffic within their own network boundary. This is particularly valuable for healthcare and financial organisations where media must not transit third-party relay infrastructure, or for deployments in regions where latency to public TURN servers is high.
