TURN Servers for Live Streaming

Sub-second latency only matters if every viewer connects

WebRTC is the only widely-deployed transport that delivers true sub-second live latency to a browser. HLS and LL-HLS measure latency in seconds; WebRTC measures it in hundreds of milliseconds. That is why sports books, news desks, auction houses, and esports broadcasters keep moving to WebRTC pipelines built on mediasoup, Janus, OvenMediaEngine, or LiveKit.

The thing nobody tells you on day one: a measurable share of viewers — corporate networks, hotel Wi-Fi, university VPNs, mobile carriers in some regions — block UDP outright or sit behind symmetric NATs. Those viewers fail to connect to your SFU and bounce. A TURN server with TCP and TLS fallbacks rescues them.

Built for streaming workloads

• 20+ global TURN regions — pick the closest to each viewer cluster.
• UDP, TCP, TURN-over-TLS on 3478 / 80 / 443.
• Standards-compliant — works with mediasoup, Janus, LiveKit, OvenMediaEngine, Pion, MediaMTX (WebRTC mode), Ant Media Server, OpenVidu, Jitsi.
• Premium tier supports shared-secret authentication so you can issue per-viewer time-limited TURN credentials at scale without exposing a static password.
• Sports broadcasters, news organizations, and live audio platforms already pay $9/month here — see the homepage customer map.

mediasoup configuration

In mediasoup, TURN credentials live on the client. Pass them into the RTCPeerConnection the client uses for its sendTransport and recvTransport.

// mediasoup-client (browser)
const sendTransport = device.createSendTransport({
  id, iceParameters, iceCandidates, dtlsParameters,
  iceServers: [
    {
      urls: [
        'turn:relay1.expressturn.com:3478?transport=udp',
        'turn:relay1.expressturn.com:3478?transport=tcp',
        'turns:relay1.expressturn.com:443?transport=tcp'
      ],
      username: 'YOUR_EXPRESSTURN_USERNAME',
      credential: 'YOUR_EXPRESSTURN_PASSWORD'
    }
  ],
  iceTransportPolicy: 'all'
});

Janus / LiveKit / OvenMediaEngine

Each SFU has its own way to push iceServers to clients:

• Janus: set iceServers in the JavaScript client when calling Janus.init and per-handle when attaching to a plugin.
• LiveKit: set rtcConfig.iceServers when constructing the Room, or configure it server-side in livekit.yaml under rtc.turn_servers.
• OvenMediaEngine: set <ICEServers> in Server.xml under the WebRTC publisher/provider blocks.
• Pion: include the URLs in webrtc.Configuration.ICEServers when constructing peers.

Bandwidth math for streaming

• 720p @ 1.5 Mbps = ~675 MB/hour through TURN per viewer relayed.
• 1080p @ 3 Mbps = ~1.35 GB/hour per viewer relayed.
• 4K @ 8 Mbps = ~3.6 GB/hour per viewer relayed.

Only the share of viewers that need TURN consumes your relay bandwidth — typically 10–25% of total viewers depending on your audience. So a 5 TB premium plan supports a much larger raw audience than the math above suggests at first glance.

FAQ

Why does WebRTC live streaming need TURN?

WebRTC viewers come from every kind of network. A meaningful share are behind NATs or firewalls that block direct UDP, so the SFU's UDP candidates fail. TURN provides a TCP/TLS fallback path that always connects, at a small latency cost compared to direct UDP.

Does TURN add latency to a live stream?

Adding TURN as a fallback path adds zero latency to viewers who can connect directly — they keep using their UDP path. Viewers who need TURN see the relay's hop added to their path, typically 10–40 ms when you pick a TURN region close to the viewer.

Can ExpressTURN handle 1080p video?

Yes. A 3 Mbps 1080p stream consumes roughly 1.35 GB per hour through TURN. The free 1 TB plan supports about 740 hours of relayed 1080p; premium 5 TB supports about 3,700 hours.

Should TURN run on the publisher side or the viewer side?

Both peers in an SFU pipeline should list TURN in their iceServers so either side can fall back when its network blocks UDP.

Related: TURN for VoIP · TURN for multiplayer games · mediasoup integration recipe · LiveKit integration recipe · vs Cloudflare Calls