A relay creates another usable path
TURN lets a client allocate a relayed transport address and control communication with permitted peers. In WebRTC, that produces relay candidates for ICE. When selected, traffic travels through the relay, adding an infrastructure dependency and a bandwidth cost. A TURN server does not replace application signaling or SIP registration. It also does not normally terminate the peers' DTLS-SRTP encryption just because encrypted packets pass through it.
Logical connections, shown in one direction for clarity. Media and signaling are bidirectional. TURN relays encrypted packets; the negotiated media peer terminates DTLS-SRTP.
Operate the service deliberately
Require authenticated allocation and limit abuse through appropriate credential lifetime, quotas and monitoring. Confirm which client-to-relay transports are supported and reachable. A TLS-capable endpoint can help some restricted networks, but no port number guarantees passage through every proxy or network policy. Size both ingress and egress for relayed traffic and account for regional latency. Track allocation failures, active sessions and actual traffic rather than estimating cost from total application logins. A relay-only policy can be useful for a controlled test or privacy requirement, but changes the expected traffic volume.
Prove that fallback works
Use a supported test configuration that forces relay candidates, then make a two-way call and inspect the selected pair. Verify credential expiry, reconnect behavior and what the client reports when allocation is denied. Restore the intended production candidate policy afterward. If a normal call succeeds directly, that is not a relay test. Record the selected relay location and transport in the test evidence. For production, provide a clear user-facing failure when no route can be established instead of leaving an answered-looking call silently waiting forever.
Watch the explanation
Tsahi Levent-Levi and Philipp Hancke connect host, server-reflexive and relay candidates to the browser events that expose them. The narrated example distinguishes gathering from signaling.
Read applicability and editorial notes →Watch this video here
A 2025 browser API walkthrough. Candidate exposure, timings and mDNS behavior depend on browser and permissions. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Compares a STUN lookup warning with a TURN authentication failure. The useful question is whether the expected candidates were gathered, not whether the console contains any error.
Read applicability and editorial notes →Watch this video here
March 2025 browser behavior. Verify event support in the browsers you deploy. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.