WebRTC, ICE, STUN, and TURN: A Simple Guide for Live Broadcasters

What is WebRTC & Why Should Broadcasters Care?

WebRTC stands for Web Real-Time Communication. It's a free, open-source project that provides web browsers and mobile applications with real-time communication capabilities via simple application programming interfaces (APIs). In plain English, it's a technology that allows you to send live video and audio directly between browsers and devices without needing any special plugins, downloads, or proprietary software like Flash.

For live broadcasters—whether you're a radio DJ, a podcaster running a video show, a church streaming its services, or a school running its own radio station—WebRTC is a revolutionary technology. Its primary advantage is enabling incredibly low-latency streaming. While traditional streaming workflows using RTMP and HLS/DASH can introduce delays of 15-45 seconds, a well-configured WebRTC stream can achieve a **very low latency 3 sec** or even sub-second delay. This makes real-time interaction with your audience not just possible, but seamless.

Imagine your listeners hearing your song request shout-out the moment you say it, or a live event viewer seeing the action as it happens. That's the power of WebRTC. It’s built into modern browsers like Chrome, Firefox, Safari, and Edge, meaning your broadcast can truly **stream from any device to any device**. A guest can join your podcast from their iPhone's web browser with a single click—no app installation required. This accessibility dramatically lowers the barrier to entry for both creating and consuming live content.

ICE: The Master Coordinator Finding the Best Path

ICE (Interactive Connectivity Establishment) is not a single protocol, but a framework or a "master coordinator" that finds the best possible path for two devices to communicate. It doesn't establish the connection itself; rather, it uses other tools (STUN and TURN) to discover all potential connection paths and then tests them to find one that works.

The process, known as "candidate gathering," works like this:

• Host Candidates: The device first gathers its own local IP addresses (e.g., 192.168.1.100). This is useful if both devices are on the same local network.
• Server Reflexive Candidates: The device then asks a STUN server for its public IP address. This is the most common path for peers on different networks.
• Relay Candidates: If a direct connection seems unlikely, the device gets a temporary address from a TURN server. This path involves relaying all data through the TURN server.

Once both peers have gathered their list of candidates, they exchange them (using a signaling server, which Shoutcast Net provides). ICE then systematically tests the pairs of candidates, starting with the most efficient (and cheapest) option first:

ICE Connection Strategy:

1. Try Direct Connection (Host Candidates)
   - Are both devices on the same Wi-Fi?
   - If yes, connect. If no, proceed to 2.
     ↓
2. Try NAT Traversal (STUN-discovered Server Reflexive Candidates)
   - Can the router map a public port directly to the device?
   - If yes, connect. If no (due to symmetric NAT/firewall), proceed to 3.
     ↓
3. Use a Relay (TURN Relay Candidates)
   - Forward all traffic through a TURN server as a last resort.
   - This path is almost guaranteed to work but adds latency and cost.
        

This prioritized approach ensures that you always get the fastest, lowest-latency connection possible for your specific network conditions.

TURN: The Reliable Relay for Tough Connections

TURN (Traversal Using Relays around NAT) is the powerful, guaranteed-to-work fallback for when a direct STUN-negotiated connection is impossible. It is the solution for the toughest 10-20% of cases involving restrictive firewalls or Symmetric NATs.

If STUN is like asking for your public address, TURN is like using a full-service package forwarding company. Instead of sending the stream directly to the other peer, you send it to the TURN server. The TURN server then "relays" or forwards the stream onward to its final destination. Both the broadcaster and the viewer connect to the TURN server, and it acts as a middleman for the entire media flow.

TURN Relay Flow:

[ Your Browser ] ---> [ TURN Server ] ---> [ Viewer's Browser ]
     (Stream)            (Relays)             (Stream)
[ Your Browser ] <--- [ TURN Server ] <--- [ Viewer's Browser ]
     (Feedback)          (Relays)             (Feedback)
        

The good news is that TURN makes a connection possible in virtually 100% of scenarios. The bad news? It comes with two significant costs:

• Increased Latency: Because the media has to travel an extra hop through the relay server, latency is inherently higher than a direct peer-to-peer connection. However, it's still far lower than traditional RTMP-to-HLS streaming.
• Server Costs: Relaying high-bitrate video and audio for potentially thousands of viewers consumes massive amounts of bandwidth and CPU power. This is the single biggest operational cost of running a WebRTC service at scale.

This cost factor is precisely why providers like Wowza have complex, metered billing. They charge you per GB of data relayed through their TURN servers, which can lead to unpredictable and astronomical bills if your stream goes viral.