Bandwidth Estimation is the mechanism used in WebRTC (and other VoIP systems) to decide how much bandwidth is available for a given session.

Protocols running over IP networks have no guarantees regarding the available bandwidth at their disposal. Furthermore, the amount of bandwidth available can change dynamically throughout a session.

To that end, bandwidth estimation is used to decide how much bandwidth is available and make sure no more (and no less) is used by WebRTC. This ensures the best possible media quality for the session.

Bandwidth estimation is based on heuristics that model the network behavior and tries to anticipate it. The algorithms used vary between different network types (bandwidth estimation for WiFi networks won’t necessarily work for LTE or wireline).

Two techniques for bandwidth estimation used by WebRTC are:

  1. REMB
  2. transport-cc
YouTube video

What is Available Bandwidth?

To understand bandwidth estimation, it’s essential to first grasp what available bandwidth is. Imagine a timeline on the x-axis and bandwidth on the y-axis. The available bandwidth in a network can fluctuate over time due to various factors such as local network conditions and the state of the network between the client and the server.

Factors Affecting Bandwidth

Several elements can affect the available bandwidth. These include congestion in the local network, other users streaming content like Netflix, or issues in the remote network or any point in between.

The Importance of Accurate Bandwidth Estimation

Accurate bandwidth estimation is crucial for maintaining high-quality calls. If the estimation is too low, the call quality will suffer as the available bandwidth is not fully utilized. On the other hand, overestimating the bandwidth can lead to congestion and packet losses, which are detrimental to media quality.

Mechanisms for Bandwidth Estimation in WebRTC

Receiver-Side Mechanism: REMB

WebRTC employs two main mechanisms for bandwidth estimation. The first one is the receiver-side mechanism, known as REMB (Receiver Estimated Maximum Bitrate).

How Does REMB Work?

In REMB, the receiver makes the decision about the available bandwidth. The sender timestamps all video packets, allowing the receiver to calculate the time differences as the packets are received. Based on this information, the receiver decides when to increase or decrease the bitrate. The receiver then communicates this estimated bitrate back to the sender.

Sender-Side Mechanism: TWCC

The second mechanism is the sender-side mechanism, called TWCC (Transport-Wide Congestion Control).

How Does TWCC Work?

In TWCC, the sender is responsible for estimating the available bandwidth. The sender attaches a global sequence number to all RTP packets and remembers the send times based on this sequence number. The receiver reports back the time differences between the received RTP packets, using the global sequence number for reference. The sender then uses this data to decide when to adjust the bitrate based on its own calculations.

About WebRTC Glossary

The WebRTC Glossary is an ongoing project where users can learn more about WebRTC related terms. It is maintained by Tsahi Levent-Levi of BlogGeek.me.

Looking to learn more about WebRTC? 

Check my WebRTC training courses