Tuning WebRTC Bandwidth Estimator for Unstable Networks

Mobile radio links break every assumption a delay-based estimator makes. Packets arrive in scheduled bursts, RTT swings ±50 ms within a second, and a clean Wi-Fi-to-LTE handoff can drop the path out from under an active call. This page is part of the Bandwidth Estimation & Congestion Control guide, and it answers one decision precisely: how to constrain and observe Google Congestion Control (GCC) so it stops misreading bursty scheduling as congestion and cutting bitrate harder than the link actually requires.

Context & Trade-offs

GCC fuses a delay-based Trendline Filter with a loss-based controller and takes the minimum. On stable wired paths this is excellent. On 4G/5G the Trendline Filter is the liability: radio schedulers deliver packets in clumps, and a clump of late arrivals reads as queue build-up, so the estimate is cut to ~85% of receive rate on a spike that resolves 80 ms later. The result is visible oscillation — the estimate sawtooths instead of holding, and the encoder chases it into avoidable resolution drops.

The only knob WebRTC exposes to the application is the ceiling: maxBitrate on RTCRtpEncodingParameters, applied via RTCRtpSender.setParameters(). There is no minBitrate in the W3C spec — it is silently ignored if you set it — so a floor must be implemented at the application layer by watching the estimate and switching to a lower-complexity tier when it sags. The core trade-off is hysteresis versus responsiveness: a conservative ceiling (say 1.2 Mbps instead of 2.5 Mbps) tames oscillation but caps the estimator’s upward probing, so it can never discover headroom above the cap. Set the ceiling to the p90 sustained capacity of your worst target network, not its peak.

It helps to be precise about why the Trendline Filter misfires on radio links. The filter measures the slope of one-way delay across packet groups; a 5G scheduler that batches a frame’s packets and releases them in a single grant produces a burst of arrivals that all land late relative to their send spacing, so the measured slope spikes even though no queue is growing. On a wired link that slope would mean a standing queue and an imminent drop; on a scheduled radio link it means nothing — the next grant clears it. The filter’s adaptive threshold partially compensates by widening under jitter, but it cannot fully distinguish scheduler clumping from real congestion, which is precisely why an application-layer ceiling plus loss correlation outperforms leaving GCC unconstrained. You are not overriding GCC; you are giving it a sane operating envelope and a second opinion.

A second lever is scalability mode. Temporal-layer SVC (L1T3) smooths cuts because dropping a temporal layer sheds bitrate without the floor collapse that spatial downscaling causes — a 30→15 fps step is far gentler than a 720p→360p step. Temporal drops are also cheap to reverse: re-enabling a layer needs no keyframe, whereas a resolution change forces an IDR that itself spikes bandwidth right when the link is fragile. Picking the right ceiling and reacting to the estimate is the practitioner half of adaptive bitrate streaming in WebRTC; this page is the network-instability half.

One more decision shapes everything: how long to wait before believing a drop. The estimator updates faster than a human perceives a quality change, so adding hysteresis at the application layer — requiring a low reading to persist for 3 seconds before acting — costs you almost nothing in responsiveness while eliminating the flapping that destroys perceived quality. The numbers below assume that discipline: a single bad poll never triggers a tier change, only a sustained one does. Treat the ceiling as the coarse control GCC probes beneath, the scalability mode as the shape of how cuts land, and the application-layer floor as the backstop for when the estimate genuinely collapses.

Minimal Runnable Implementation

// Constrain GCC for an unstable link, then run an app-layer floor.
// Ceiling: conservative, set to p90 sustained capacity — NOT the peak.
const sender = pc.getSenders().find(s => s.track?.kind === 'video');

async function applyCeiling(bps) {
  const params = sender.getParameters();
  if (!params.encodings?.length) params.encodings = [{}];
  params.encodings[0].maxBitrate = bps;          // ceiling only; GCC probes beneath it
  params.encodings[0].scalabilityMode = 'L1T3';  // temporal layers absorb spikes
  await sender.setParameters(params);            // control signal: every 3–5 s, not per frame
}

// App-layer floor: GCC has no minBitrate, so we enforce a tier change ourselves.
let lowSince = null;
async function pollAndFloor(pc) {
  const stats = await pc.getStats();
  let availBps = null, lossRate = 0;
  for (const r of stats.values()) {
    if (r.type === 'transport') availBps = r.availableOutgoingBitrate ?? null;
    if (r.type === 'inbound-rtp' && r.kind === 'video') {
      const total = (r.packetsReceived ?? 0) + (r.packetsLost ?? 0);
      lossRate = total > 0 ? (r.packetsLost ?? 0) / total : 0; // correlate, don't trust BW alone
    }
  }
  // Sustained low estimate AND real loss → drop a tier rather than let it collapse.
  if (availBps !== null && availBps < 300_000 && lossRate > 0.12) {
    lowSince ??= Date.now();
    if (Date.now() - lowSince > 3000) await applyCeiling(250_000); // audio-priority tier
  } else {
    lowSince = null;
  }
}
await applyCeiling(1_200_000);                    // start conservative for cellular
setInterval(() => pollAndFloor(pc), 1500);        // 1–2 s cadence

The pairing matters: never act on availableOutgoingBitrate alone. A low estimate with near-zero loss is the Trendline Filter spooked by a burst — riding it out beats cutting. A low estimate with sustained loss above 12% is genuine, and that is when you drop a tier.

Two implementation notes save grief in production. First, guard against a missing sender: on a renegotiation or track replacement the find() can momentarily return undefined, so wrap applyCeiling in a null check rather than letting it throw inside your interval. Second, debounce the recovery path as well as the cut path — when conditions improve you want to restore the higher ceiling, but doing so on the first good poll re-introduces the flapping you just eliminated. Require the healthy state to hold for the same 3-second window before raising the ceiling back, and prefer raising it in one step to the conservative target rather than ramping, since GCC does the fine probing beneath whatever ceiling you set.

Reproduction Steps & Debugging Log Patterns

1. Apply a degradation profile with tc netem (Linux) or Network Link Conditioner (macOS). A representative unstable profile: 8% random loss, 150 ms base RTT, ±50 ms jitter.

   # Linux: degrade outbound traffic on eth0 to mimic a flaky cellular bearer
   sudo tc qdisc add dev eth0 root netem \
     delay 150ms 50ms distribution normal \
     loss random 8%
   sudo tc qdisc del dev eth0 root   # remove when the test finishes

2. Open chrome://webrtc-internals and graph availableOutgoingBitrate on the transport series alongside targetBitrate on outbound-rtp. A healthy tuned estimator shows smooth, gradual transitions; an untuned one sawtooths between the cap and ~300 kbps.

3. Log pollAndFloor output every 1.5 s. Expected console under the profile above:

   avail=1180000 loss=0.07   // riding a burst — loss under 12%, hold
   avail=290000  loss=0.14   // genuine — lowSince armed
   avail=270000  loss=0.15   // >3 s low+lossy → applyCeiling(250000)
   

4. Confirm the cut was deliberate, not a flap: lowSince should arm, persist past 3 s, then trigger. If you see the 250 kbps tier applied within one poll, your threshold logic is reacting to a single spike — widen the window.

5. After removing the netem profile, watch the estimate climb back. It recovers slowly by design (additive probing ~+8% per RTT); a high-RTT link can take 5–10 s to re-discover headroom. That is correct, not a bug.

Common Implementation Mistakes

• Setting maxBitrate too low. A 600 kbps cap on a 4 Mbps link means GCC can never probe past 600 kbps — you have hidden your own headroom. Tune to p90 sustained capacity.
• Trying to set minBitrate. It is not in the W3C RTCRtpEncodingParameters spec and is silently ignored. Enforce floors at the application layer by switching resolution/codec tiers.
• Disabling FEC or NACK. Retransmission delays then read as congestion and recovered packets as late arrivals, so both GCC controllers over-react and the estimate collapses.
• Acting on availableOutgoingBitrate without loss correlation. A low estimate with under 2% loss is a jitter spook, not congestion. Always read packetsLost from inbound-rtp before cutting.
• Calling setParameters() like a PID loop. It is async; tight-loop calls serialise poorly and desync the encoder. Update at most every 3–5 seconds once conditions stabilise.
• Reacting to a single poll. Cellular estimates are noisy by nature; a one-sample dip is almost always a scheduling burst. Arm a timer and require the low state to persist past 3 seconds before changing tiers, then disarm it the moment conditions recover.

Frequently Asked Questions

Can I completely disable WebRTC’s bandwidth estimator? No. GCC is wired into the transport layer; bypassing it causes uncontrolled flooding and rapid connection collapse. You can only constrain its operating range via maxBitrate and shape its reaction with scalability mode.

Why does availableOutgoingBitrate spike and drop rapidly on 4G/5G? Radio schedulers deliver packets in bursts, and the Trendline Filter reads a burst of late arrivals as queue growth. A conservative maxBitrate plus temporal SVC (L1T3) smooths the transitions, because shedding a temporal layer avoids the floor collapse that spatial downscaling triggers. Confirm the cause by checking qualityLimitationReason while you graph the estimate.

How often should I call setParameters() to adjust limits? Only after conditions have held steady for 3–5 seconds. It is an async operation, and calling it in a tight loop creates state inconsistencies in the encoder pipeline.

Related: return to Bandwidth Estimation & Congestion Control for the full GCC architecture, read interpreting getStats() for congestion signals for the stats this page polls, and apply the ceiling within adaptive bitrate streaming in WebRTC.