WebRTC audio streams routinely lose 1–5% of packets on consumer networks. At 20ms per packet and 50 packets per second, even 2% loss means one dropped frame every second—enough to make speech unintelligible without mitigation. Two RFC-standardized techniques—Forward Error Correction (FEC) and Redundant Encoding (RED)—tackle this problem with opposing philosophies: FEC sends parity data to reconstruct lost packets mathematically, while RED duplicates payload at lower quality. Both add overhead, but their performance envelopes differ sharply depending on loss patterns, CPU budget, and codec choice.

Forward Error Correction: XOR Parity for Bursty Loss

FEC in WebRTC typically uses RFC 5109's XOR scheme. The encoder groups k packets, computes their bitwise XOR, and transmits the result as a redundant packet. If any single packet in the group is lost, the receiver XORs the remaining k-1 packets with the FEC packet to recover the missing data. For k=4, this adds 25% bandwidth overhead but recovers from any single loss in each group.

The math is simple: if packets A, B, C, D produce FEC packet F = A ⊕ B ⊕ C ⊕ D, then losing B means B = A ⊕ C ⊕ D ⊕ F. Reconstruction is deterministic and computationally cheap—a few hundred CPU cycles on ARM. The catch: FEC only protects against one loss per group. Two lost packets in the same group? Unrecoverable. This makes FEC ideal for bursty loss (e.g., WiFi interference spikes) but poor for uniform random loss above 3–4%.

Configuration matters. Larger k values reduce overhead (1/k) but increase vulnerability to multi-packet bursts. Smaller k values (2–3) handle burst loss better at the cost of 33–50% overhead. In practice, k=4–6 is common for Opus at 32kbps. The FEC packet itself is sent with higher priority (DSCP EF marking) to reduce its own loss probability.

Redundant Encoding: Payload Duplication at Lower Bitrate

RED (RFC 2198) takes a different approach: encode each audio frame twice—once at full quality, once at reduced bitrate—and send both. The primary encoding uses Opus at, say, 32kbps; the redundant encoding might use 16kbps or even 8kbps narrowband. If the primary packet arrives, use it. If lost, fall back to the lower-quality redundant copy sent in the next packet.

This introduces one frame of latency (20ms) because the redundant copy lags behind. The receiver maintains a jitter buffer and, on detecting loss, checks if the redundant copy arrived in the subsequent packet. If present, it decodes that instead of synthesizing silence or using packet loss concealment (PLC). The redundant stream is typically Opus in CELT mode with complexity 0, which encodes in under 1ms on mobile ARM.

Overhead is higher than FEC—50–100% depending on the redundant bitrate ratio—but RED handles random loss better. At 5% uniform loss, RED with 16kbps redundancy recovers ~95% of frames (only fails if both primary and redundant are lost, probability 0.05×0.05=0.0025). FEC at k=4 recovers only ~60% of frames at 5% loss because multiple losses per group become likely.

Codec Interaction: Opus PLC vs Explicit Recovery

Opus has built-in PLC that synthesizes plausible audio from prior frames using linear prediction. For isolated losses, Opus PLC is remarkably good—Mean Opinion Score (MOS) degrades from 4.2 to 3.8 at 2% loss. But PLC fails on consecutive losses: two back-to-back drops produce audible artifacts (MOS ~3.0). FEC and RED aim to prevent consecutive perceived losses.

FEC's advantage: no additional encoding cost. The parity packet is computed from already-encoded payloads. RED's cost: you encode every frame twice. On a mid-range ARM SoC (Cortex-A55), Opus at 32kbps takes ~2ms per 20ms frame at complexity 5. Adding RED at 16kbps (complexity 0) adds ~0.8ms. Total encode time: 2.8ms per frame, or 14% of the frame budget. Battery impact is measurable—an extra ~50mW sustained on a 3W idle device.

Yet RED's perceptual quality is higher. In A/B testing for a P2P voice app, users rated RED-protected calls at 5% loss as 4.0 MOS vs 3.5 for FEC. The reason: RED always provides some signal, even if lower quality, whereas FEC's all-or-nothing recovery leaves gaps that Opus PLC must fill synthetically.

Hybrid Strategies: Adaptive Switching

Shipping production WebRTC clients often use neither pure FEC nor pure RED, but adaptive hybrids. Monitor receiver statistics (RTCP reports include loss rate and burst metrics). If loss is 1.5 favors RED; burst factor