Short transcript of a technical conversation explaining how WebRTC estimates available bandwidth. It contrasts loss-based and delay-based estimation, and discusses where estimation logic runs (receiver-side using RTCP/REMB vs sender-side using packet-send/feedback timing). The transcript notes that modern browsers default to sender-side estimation but can support receiver-side approaches.
Chapters
How does bandwidth estimation work in WebRTC?
I would say very dynamically, at a packet level. WebTC records information about the packets it sends and it gives feedback to the other side. And we have two cases. One is where we are based on loss. So we are experiencing loss, which means we're sending too much, and the other is we're seeing an increase in delay, which means we might be sending too much and the buffers on the network are filling up.
Okay. So in a way I might do it after the fact. When I see, oh, there is packet loss, it might be an issue with bandwidth, so I'll reduce bandwidth. Or it might be, oh, look, there is something happening in the network that hints that I might lose packets in the future, hence I should reduce bandwidth now.
Yes. These are called loss based bandwidth estimation and delay based bandwidth estimation.
Who makes the actual decision?
There are two ways to do it. One is the older one is that the receiver does the calculations. It sees the back clause incoming, it sees the delays incoming, and then it calculates the bandwidth estimate from that and uses RTCP in particular the REMB packet to give feedback to the sender. This is how much I think you can send.
Okay.
And the newer approach is to do it on the sender, which means that the sender records when it sends a packet and receives, receives feedback from the receiver about when these packets were received. And then it does calculations based on that.
Okay. And I guess at the end of the day, at least WebRTC inside the browser supports both of them. Both sender side decisions and receiver side decisions.
Correct. By default, sender side is used, but there are cases when you want receive side.