Bandwidth estimation is the congestion-control loop that decides how much data a call can safely send at any moment. Because no one tells an endpoint how much capacity the path between two people actually has — and that capacity changes constantly as networks load and unload — the sender has to infer it continuously. WebRTC does this by watching signals like growing one-way delay and the onset of packet loss, using transport-wide congestion control to probe upward when the path seems clear and back off when it sees signs of congestion, then steering the video encoder's target bitrate to match what it believes the network can carry.
This loop is what actually determines, second by second, the quality a patient experiences: whether their home Wi-Fi sustains a crisp 720p stream, drops to a soft 180p, or, when the estimate collapses, leaves them staring at a frozen frame. The encoder is downstream of the estimate — it produces whatever bitrate the congestion controller permits — so video quality is governed much more by the estimation logic than by the encoder settings teams instinctively reach for.
For a telemedicine product this reframes how you debug 'bad video.' When a consultation looks blocky or freezes, the first thing to inspect is the bandwidth-estimate trace, not the camera or the codec, because the encoder almost always just did what it was told. The common mistake is raising the configured maximum bitrate to 'force' better quality; if the estimator has concluded the path cannot carry it, pushing more data simply provokes congestion and loss, making the experience worse rather than better. The useful work is usually upstream — relay routing, network conditions, or how aggressively the estimator probes and recovers.
