How WebRTC Bandwidth Estimation Works

Real-time communication relies heavily on adapting to fluctuating network conditions to maintain clear audio and video. This article provides a comprehensive look at how WebRTC continuously calculates and utilizes internal Bandwidth Estimation (BWE) to prevent network congestion. We will break down the transition from receiver-side to sender-side estimation, explain the delay-based and loss-based algorithms used for calculations, and explore how WebRTC dynamically adjusts media bitrates in real time.

The Role of Bandwidth Estimation in WebRTC

Bandwidth Estimation (BWE) is the mechanism WebRTC uses to determine the maximum amount of data it can transmit over a network path without causing congestion. Because consumer internet connections (especially Wi-Fi and mobile networks) experience constant fluctuations in capacity, WebRTC must continuously probe the network, calculate available capacity, and adapt its media stream bitrate on the fly.

If the estimate is too high, the network buffers overflow, leading to packet loss, high latency, and frozen video. If the estimate is too low, the video quality becomes needlessly poor.

Shift to Sender-Side Bandwidth Estimation

Historically, WebRTC relied on receiver-side estimation, where the receiver calculated the bandwidth and sent a Receiver Estimated Maximum Bitrate (REMB) message back to the sender.

Modern WebRTC implementations have shifted to Sender-Side Bandwidth Estimation. In this architecture, the receiver acts as a simple feedback agent, while the sender does the heavy lifting. The key protocol enabling this is Transport-Wide Congestion Control (TWCC).

With TWCC, the sender attaches a transport-wide sequence number to every outgoing packet. The receiver keeps track of when these packets arrive and sends back feedback packets containing a map of packet arrival times. Armed with this precise timing data, the sender calculates the network state.

How WebRTC Calculates Bandwidth

The sender-side BWE engine calculates the target bitrate by combining two distinct mathematical models: delay-based estimation and loss-based estimation.

1. Delay-Based Estimation

Delay-based estimation acts as an early warning system. It detects network congestion before packets are actually dropped by measuring changes in packet transit delay, known as one-way delay variation.

• Trend Detection: The algorithm groups packets into bursts and measures the time difference between when they were sent and when they were received.
• State Machine: Based on the delay trend, the estimator enters one of three states:
  • Normal: Arrival delay is stable. The algorithm can safely increase the bitrate.
  • Underuse: Delay is decreasing. The queue in the network router is clearing.
  • Overuse: Delay is increasing. This indicates that network buffers (queues) are filling up, and congestion is imminent.
• Kalman Filter / Trendline Estimator: Modern WebRTC uses a Trendline Estimator to filter out jitter and accurately predict whether the network queue is growing or shrinking. If overuse is detected, the estimator immediately lowers the target bitrate.

2. Loss-Based Estimation

Loss-based estimation is a reactive backup mechanism. It relies on explicit packet loss percentages reported via RTCP feedback or TWCC.

• If packet loss is low (under 2%), the network is healthy, and the estimator may slowly increase the bitrate limit.
• If packet loss is moderate (between 2% and 10%), the estimator keeps the bitrate stable.
• If packet loss is high (above 10%), the estimator immediately scales back the bitrate to relieve network pressure, as packet loss is a strong indicator of an already congested network.

The final bandwidth estimate is typically the minimum value calculated by these two controllers (Delay-Based and Loss-Based), ensuring a conservative and highly responsive approach to network congestion.

How WebRTC Utilizes the Estimated Bandwidth

Once the BWE engine calculates a new bandwidth limit, WebRTC immediately utilizes this estimate to modify the outgoing media streams through several layers of adaptation:

• Encoder Bitrate Adjustment: The video and audio encoders (such as VP8, VP9, H.264, or Opus) are instructed to compress the media to fit the newly estimated bandwidth limit.
• Simulcast and SVC (Scalable Video Coding): If WebRTC is routing media through a Selective Forwarding Unit (SFU), it can drop entire video layers (e.g., stopping the 1080p stream and only sending the 360p stream) to immediately meet lower bandwidth requirements without needing to re-encode the video.
• Pacing: WebRTC does not burst packets onto the network all at once. It uses a “Pacer” to distribute the transmission of packets evenly over time, matching the rate calculated by the BWE to prevent spike-induced congestion.
• Probing: When network conditions improve, WebRTC does not instantly jump to a high bitrate. It transmits temporary padding packets (probing) to safely verify if the network can handle a higher load before upgrading the actual video resolution.