WebRTC — Production Gotchas in ICE, STUN, TURN, and SDP

Every time you hop on a Google Meet call, share your screen on Discord, or do a live video consultation with a doctor, there's a real-time peer-to-peer communication layer quietly doing enormous amounts of work beneath the surface. That layer is WebRTC. It's baked into every major browser, it's free, and it's one of the most architecturally complex systems you'll encounter in web development — precisely because it has to punch through firewalls, negotiate codecs, handle network jitter, and do all of this in under a second. Understanding it at the component level is the difference between cargo-culting a tutorial and actually shipping a reliable product.

The problem WebRTC solves is deceptively hard: two browsers sitting behind separate corporate firewalls, NAT routers, and ISPs need to send live media to each other with sub-200ms latency. Traditional HTTP request-response doesn't work — there's no persistent bidirectional channel, and routing every video frame through your server would be catastrophically expensive at scale. WebRTC solves this by giving browsers a standardized API to discover each other's network addresses, agree on a common media format, and then open a direct encrypted UDP channel — all without you writing a single line of native socket code.

By the end of this article you'll be able to reason through the entire WebRTC handshake from first principles: what ICE candidates are and how they're gathered, what SDP actually encodes and why it matters, when STUN is enough and when you absolutely need TURN, how the DataChannel differs from MediaStream tracks, and what goes wrong in production when corporate proxies eat your UDP packets. You'll also walk away with annotated code showing the full offer-answer exchange and a comparison table to help you choose the right ICE topology for your use case.

How WebRTC Actually Connects Two Browsers Without a Server

WebRTC is a browser-to-browser protocol for real-time audio, video, and data transfer — no plugins, no central media server. The core mechanic is peer-to-peer: once a connection is established, media flows directly between clients. But the setup path is anything but direct. It relies on ICE (Interactive Connectivity Establishment) to discover the best network path, STUN servers to find your public IP and port, and TURN servers to relay traffic when NAT or firewalls block direct connections. SDP (Session Description Protocol) negotiates codecs, resolutions, and encryption keys before any packet is sent.

In practice, WebRTC works in three phases: signaling (exchange SDP offers/answers via your own server — WebRTC doesn't define this), ICE candidate gathering (STUN probes to find reachable addresses), and connectivity checks (pairs of candidates are tested until one works). The key property that matters in production is that ICE can take 2–5 seconds to complete, and if TURN relay is required, latency jumps by 50–100 ms and bandwidth costs spike. You cannot skip STUN/TURN configuration and expect reliable connections.

Use WebRTC when you need sub-500 ms latency for voice/video, screen sharing, or real-time data channels. It's the only browser-native option for peer-to-peer media. In real systems, it powers Zoom-like conferencing, live streaming, and remote desktop tools. The trade-off is complexity: you must run your own signaling server, configure STUN/TURN, and handle fallback logic when ICE fails. Without proper TURN infrastructure, up to 15% of connections will fail in enterprise networks with symmetric NAT.

ICE: Interactive Connectivity Establishment

ICE is the core negotiation protocol that determines the best path for media between two peers. It collects a list of candidate network addresses (local, STUN-reflexive, TURN-relayed) and tests them in order of priority. The goal is to find a pair that works — typically the fastest direct path wins. ICE handles network changes, NAT rebinding, and even multi-homed hosts. Without ICE, you'd need to manually configure every network topology.

package io.thecodeforge.webrtc;

import org.webrtc.IceCandidate;
import org.webrtc.PeerConnection;

public class IceCandidateHandler {
    public void onIceCandidate(PeerConnection pc, IceCandidate candidate) {
        System.out.printf("New ICE candidate: sdp=%s, sdpMid=%s, sdpMLineIndex=%d%n",
                candidate.sdp, candidate.sdpMid, candidate.sdpMLineIndex);
        // Send candidate to remote peer via signaling channel
    }
}

STUN: Session Traversal Utilities for NAT

STUN is a lightweight protocol that lets a client discover its public IP address and port as seen from the internet. The client sends a binding request to a STUN server, which responds with the observed source address. This gives you a 'reflexive candidate' that can be used by the remote peer to reach you. STUN works for most home NATs but fails under symmetric NATs (common in corporate firewalls) because the port mapping changes per destination.

package io.thecodeforge.webrtc;

import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;

public class StunQuery {
    public static String getPublicIp(String stunHost, int port) throws Exception {
        try (DatagramSocket socket = new DatagramSocket()) {
            socket.connect(InetAddress.getByName(stunHost), port);
            return socket.getLocalAddress().getHostAddress();
        }
    }
}

TURN: Traversal Using Relays around NAT

TURN is the last resort: it relays all media through a server on the public internet. When direct P2P fails (ICE reaches the end of candidate list without success), one peer connects to a TURN server and the other connects to the same relay. The TURN server forwards packets between them. This adds latency (~100-200ms extra) and server bandwidth costs, but it guarantees connectivity even under symmetric NATs or firewall blocks.

package io.thecodeforge.webrtc;

import org.webrtc.PeerConnection;
import org.webrtc.PeerConnection.IceServer;
import java.util.List;

public class TurnConfig {
    public static List<IceServer> getIceServers() {
        IceServer stun = IceServer.builder("stun:stun.l.google.com:19302").createIceServer();
        IceServer turn = IceServer.builder("turn:turn.example.com:3478")
                .setUsername("user")
                .setPassword("pass")
                .createIceServer();
        return List.of(stun, turn);
    }
}

SDP: Session Description Protocol

SDP describes the media session: codecs (H264, VP8, Opus), encryption keys (DTLS fingerprint), bandwidth, and network parameters. It's a plaintext format that both peers exchange via signaling. The 'offer' contains the caller's capabilities; the 'answer' contains the callee's intersection. SDP is not a transport protocol — it's a negotiation contract. Once agreed, media flows using the chosen parameters.

package io.thecodeforge.webrtc;

import org.webrtc.SessionDescription;

public class SdpHandler {
    public static void onOfferReceived(String sdp) {
        SessionDescription remoteDesc = new SessionDescription(SessionDescription.Type.OFFER, sdp);
        // Set remote description, then create answer
        System.out.println("Received SDP offer with codecs: " + extractCodecs(sdp));
    }

    private static String extractCodecs(String sdp) {
        // Parse SDP lines like a=rtpmap:96 VP8/90000
        StringBuilder sb = new StringBuilder();
        for (String line : sdp.split("\n")) {
            if (line.startsWith("a=rtpmap:")) {
                sb.append(line.substring(9)).append(", ");
            }
        }
        return sb.length() > 0 ? sb.substring(0, sb.length() - 2) : "none";
    }
}

Signaling: The Hidden Handshake

Signaling is the out-of-band exchange of session control messages (SDP offers/answers and ICE candidates) before the peer-to-peer connection exists. WebRTC does not define signaling — you use your own channel: WebSocket, HTTP, XMPP, or even carrier pigeon. The only requirement is that it's fast and reliable. Signaling is often where developers trip up: missing a candidate, reordering messages, or not handling multiple calls.

package io.thecodeforge.webrtc;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class SignalingChannel {
    private final BlockingQueue<String> messages = new LinkedBlockingQueue<>();

    public void send(String msg) {
        // In real code, send via WebSocket
        System.out.println("Sending signaling message: " + msg);
    }

    public String poll() throws InterruptedException {
        return messages.take();
    }
}

DataChannel: Beyond Audio/Video

DataChannel enables arbitrary data transfer between peers (files, game state, chat) with configurable reliability. It's built on SCTP over DTLS. You can choose 'reliable' (TCP-like) or 'unreliable' (UDP-like with ordered/unordered). DataChannel is ideal for low-latency game inputs or real-time collaboration where every packet matters.

package io.thecodeforge.webrtc;

import org.webrtc.DataChannel;

public class DataChannelExample {
    public static void sendMessage(DataChannel dc, String msg) {
        if (dc.state() == DataChannel.State.OPEN) {
            dc.send(new DataChannel.Buffer(io.netty.buffer.Unpooled.copiedBuffer(msg, java.nio.charset.StandardCharsets.UTF_8), false));
        }
    }
}

Why Your WebRTC Call Keeps Dropping: The NAT Debugging Nightmare

You've got ICE, STUN, and TURN working on paper. Great. But your production WebRTC app still drops calls when users are on corporate VPNs or carrier-grade NAT. Here's the dirty secret: NAT traversal isn't a binary pass/fail. It's a probabilistic clusterf***.

STUN works for about 70% of clients. That's the easy part. The remaining 30% have symmetric NAT, where your public IP:port binding changes per destination. STUN can't see this because it only talks to one server. Your ICE agent wastes seconds trying candidates that will never work. Meanwhile, the user sees "Connecting..." and rage-refreshes.

The fix? Run multiple STUN servers on different subnets. Google's free STUN (stun:stun.l.google.com:19302) is great until it rate-limits you. Deploy your own STUN behind anycast IPs. Also, implement ICE restarts when media fails after a successful connection. A network change mid-call (WiFi to cellular) invalidates your previous NAT mapping. Restart ICE immediately, don't wait for the 30-second timeout.

Aggressive nomination in ICE can mask connectivity issues during initial handshake but fail under load. Use regular nomination. It tests all candidates before selecting the final pair. Yes, it's slower. Yes, it saves your call quality when networks degrade.

// io.thecodeforge — system-design tutorial

import subprocess
import json

def check_nat_type(stun_host: str) -> dict:
    """Quick NAT type detection using STUN response.
    Returns dict with mapped port and changed address fields."""
    cmd = [
        "stunclient", "--mode", "full",
        "--local-port", "19302", stun_host, "3478"
    ]
    try:
        output = subprocess.check_output(cmd, timeout=5).decode()
        lines = output.strip().split("\n")
        info = {}
        for line in lines:
            if "Mapped address" in line:
                info["map_addr"] = line.split(":")[1].strip()
            if "Changed address" in line:
                info["changed_addr"] = line.split(":")[1].strip()
        # Symmetric NAT: mapped port != changed port
        info["is_symmetric"] = (
            info.get("map_addr") != info.get("changed_addr")
        )
        return info
    except subprocess.TimeoutExpired:
        return {"error": "STUN timeout - likely blocked UDP"}

result = check_nat_type("stun.l.google.com")
print(json.dumps(result, indent=2))

SDP Bloat: The Silent Killer of WebRTC Performance

Your SDP offer is 15KB. It takes 800ms to parse on the receiving peer. Why? Because every browser vendor includes every codec, every packetization mode, and every extension they've ever shipped. Chrome alone advertises 18 H.264 profiles, 4 VP8 configurations, and 3 Opus bitrates. The remote peer has to filter through this garbage to find what actually works.

This isn't just a latency issue. Large SDP causes fragmentation in WebSocket signaling messages, which leads to retransmission and reordering. Your ICE candidates arrive after SDP because they're in separate attributes—the peer starts gathering candidates before it knows which codecs to use, wasting resources.

The fix is SDP pruning. Before sending an offer, strip everything except the codecs you actually intend to use. If you only need VP8 at 30fps, remove H.264 entirely. Remove redundant rtpmap attributes. Many media servers (Janus, Mediasoup) do this automatically. If you're building peer-to-peer without a media server, you must implement it yourself.

Also, use "rollback" semantics in the createOffer/Answer flow. Modern browsers support it. Rejecting an old offer and sending a new one is atomic—no stale SDP in flight. And for god's sake, enable RTCP-mux and bundle. Reduces candidate pairs from n^2 to n. Your ICE agent will thank you.

// io.thecodeforge — system-design tutorial

import re

def prune_sdp(sdp: str, keep_codecs: set) -> str:
    """Remove unwanted codec lines from SDP.
    Keeps only codecs in { 'VP8', 'opus' } for example."""
    lines = sdp.split("\r\n")
    pruned = []
    in_media = False
    codec_map = {}
    
    for line in lines:
        if line.startswith("m="):
            in_media = True
            # Extract payload types from media line
            parts = line.split()
            # First 3 parts are: m=audio/rtp, port, proto
            payloads = parts[3:]
            pruned.append(parts[0])  # placeholder
            codec_map[line] = payloads
        elif in_media:
            if line.startswith("a=rtpmap:"):
                # rtpmap:96 VP8/90000
                match = re.search(r":(\d+) (.+?)/", line)
                if match:
                    pt, codec = match.groups()
                    if codec not in keep_codecs:
                        continue
            pruned.append(line)
        else:
            pruned.append(line)
    
    return "\r\n".join(pruned)

sdp_raw = open("offer.sdp", "r").read()
pruned = prune_sdp(sdp_raw, {"VP8", "opus", "rtx"})
print(pruned[:500])

How WebRTC Establishes a Connection (Step by Step)

Skip the magic. Here's the raw sequence your browser executes when you click "start call." First, your app sends an SDP offer over your signaling channel—WebSocket, HTTP, carrier pigeon, whatever. That SDP blob contains your codec preferences, ICE candidates, and crypto fingerprints. The remote peer sends back an SDP answer. Now both sides have each other's session descriptions and public candidate addresses.

Then ICE kicks in. Each browser gathers candidates: local IPs, STUN-mapped public IPs, and TURN relay addresses. They prioritize by connectivity cost. Local LAN? Instant. STUN? Fast. TURN? Last resort—you're paying for relay bandwidth.

Connectivity checks start immediately. STUN binding requests fire between every candidate pair. First pair to return a successful response wins. That's your active connection. Everything after that—DTLS-SRTP keying, codec negotiation—runs on that established pair. Your first audio packet flies maybe 200ms after the SDP answer arrived.

// io.thecodeforge — system-design tutorial

class IcedConnection:
    def __init__(self, signaling_channel):
        self.state = "gathering"
        self.candidates = []
        self.selected_pair = None

    def on_local_candidate(self, candidate):
        self.candidates.append(candidate)
        self.signaling_channel.send({
            "type": "ice_candidate",
            "candidate": candidate.sdp
        })

    def on_remote_candidate(self, candidate):
        pair = IcePair(self.candidates[-1], candidate)
        if pair.connectivity_check_passes():
            self.selected_pair = pair
            self.state = "connected"
            return pair
        return None

    def start_call(self):
        self.state = "checking"

The Solution: SFU (Selective Forwarding Unit)

Mesh architectures work for 3 people in a Google Meet. Beyond that, your browser melts trying to encode 9 separate video streams. That's where the SFU enters—the backbone of every production WebRTC deployment. Zoom, Discord, Twitch—they all run on SFUs.

An SFU is a server that receives one upstream from each participant and selectively forwards it to everyone else. No decoding, no transcoding. Just packet switching. Your browser sends one video stream to the SFU. The SFU copies that stream to every other participant. You encode once, they receive as many streams as they want.

The magic is selective forwarding. The SFU doesn't send 4K to someone on mobile with bad signal. It forwards the lowest bitrate simulcast layer. It drops packets from a muted speaker entirely. No wasted bandwidth. No client-side encoding hell.

SFUs scale horizontally. Need 10,000 participants? Spin up 50 SFU nodes behind a load balancer. Each node handles 200 people. Your WebRTC app just talks to the SFU—one connection, one encoding burden.

// io.thecodeforge — system-design tutorial

class SelectiveForwardingUnit:
    def __init__(self):
        self.rooms = {}

    def handle_media(self, ssrc, rtp_packet, room_id):
        room = self.rooms.get(room_id)
        if not room:
            return
        sender = room.participants[ssrc]
        for target in room.participants.values():
            if target.id == sender.id:
                continue
            target.feed_queue.put(
                self._maybe_downgrade_layer(
                    rtp_packet, target.bandwidth_limit
                )
            )

    def _maybe_downgrade_layer(self, packet, limit_kbps):
        if packet.bitrate > limit_kbps:
            return packet.to_lower_simulcast_layer()
        return packet

Why LiveKit Specifically

You could roll Janus, mediasoup, or even raw WebRTC with libwebrtc. Don't. LiveKit is the production shortcut your team needs. Here's why.

First, it's Go-based. One binary, zero dependencies. Deploy it on a t3.medium and it handles 500 concurrent rooms without flinching. Memory footprint? ~50MB per 100 participants. Compare that to Janus which needs a Redis cluster for state management.

Second, the WebRTC layer is abstracted. You don't write SDP parsing code. You don't configure STUN/TURN servers manually. LiveKit auto-discovers your network setup. Their clients (React, iOS, Android) expose Room, Participant, and Track objects. That's it. Your app sends audio, receives video, and handles disconnects with 3 lines of code.

Third, the ecosystem. Webhooks for recording, ingress for RTMP feeds, egress for file output. You can live-stream a WebRTC call to YouTube without writing a single transcoding pipeline. Their data channel API surfaces real-time metadata—reactions, chat, whiteboard state—over the same WebRTC connection.

Skip the academic research phase. LiveKit ships production-ready SFU logic, client libraries, and monitoring dashboards. Your job is to build the UI, not debug ICE failures.

// io.thecodeforge — system-design tutorial

from livekit import api

client = api.LiveKitAPI(
    url="wss://my-livekit-server:7880",
    api_key="API4abc123",
    api_secret="sk_secretxyz"
)

room = client.create_room(
    name="team-sync",
    max_participants=50,
    empty_timeout=300
)

# Participant connects via frontend SDK:
# await Room.connect(token, { audio: true, video: true })
# Track is auto-published to the SFU

print(f"Room {room.name} ready, SID: {room.sid}")