Network Resilience
The internet is not a perfect pipe. It is a series of unpredictable queues. WebRTC must maintain a smooth media stream even when the network drops 10% of its packets or delays them by hundreds of milliseconds.
The Resilience Toolkit
WebRTC uses three primary techniques to recover from the "Chaos" of the real-world web:
| Technique | Name | Goal |
|---|---|---|
| Retransmission | NACK | The receiver asks for a specific missing packet. Best for low-latency networks. |
| Error Correction | FEC | The sender sends "extra" data so the receiver can reconstruct lost packets. |
| Refresh | PLI / FIR | The receiver asks for a full "Key Frame" because the video stream is too corrupted to repair. |
1. Jitter Buffering
Network packets rarely arrive at a consistent interval. This variance is called Jitter.
- The Problem: If a frame arrives too late, the video "stutters."
- The Solution: The Jitter Buffer adds a tiny, dynamic delay (usually 20ms to 100ms) to collect out-of-order packets and release them to the decoder at a steady pace.
2. Congestion Control (GCC)
WebRTC does not have a fixed bitrate. It uses Google Congestion Control (GCC) to constantly probe the network's capacity.
- REMB / TMMBR: The receiver tells the sender: "I am overwhelmed, please lower the bitrate."
- Bitrate Adaptation: The browser dynamically lowers the video resolution (e.g., from 1080p to 480p) to keep the call alive rather than letting it drop.
- BWE (Bandwidth Estimation): The sender analyzes packet delivery timing to estimate the available pipe size.
3. Chaos simulation
This environment simulates the most common network failures:
Packet Loss (The Enemy of SCTP)
In a Data Channel, packet loss triggers retransmissions which can cause "Head-of-Line Blocking." For media (SRTP), packet loss causes visual artifacts like "ghosting" or "smearing" until the next Key Frame arrives.
Latency (The Speed of Light)
If the Round Trip Time (RTT) exceeds 300ms, human conversation becomes difficult. Users will start "talking over" each other because of the lag.
If you've ever seen a WebRTC video "freeze" and then suddenly "snap" back to clarity, you've seen a Full Intra Request (FIR) in action. The receiver gave up on the current stream and demanded a fresh start from the sender.
Study the Protocol Stack to see where these recovery mechanisms live, or use the Throughput Explorer to see live BWE data.