WebRTC Benchmarking: Why a Clean Call Recovery Test Can Be Wrong.

Before switching video SDKs, upgrading to a new version or renewing a vendor contract, engineering leaders want to know how their call quality compares with competing products and where it falls short. WebRTC benchmarking answers that by running each video calling product through identical network limits, such as a 500 kbps cap, and recording call quality on the receiving device.

A benchmark can look correct and be wrong. We ran one on Google Meet and Zoom Web (Zoom running in the browser), testing how each recovers after a network drop, and found two cases:

• The throttling setup we started with capped normal web traffic, but Google Meet’s call video escaped it. Our speed test showed about 490 kbps. In the clearest run, Meet’s incoming video was 2.2 Mbps under the “500 kbps” setting.
  
• Zoom Web’s video does not appear in the standard quality statistics. A report built on those statistics would have no picture-quality data for Zoom.

Neither case produced an error. If you are about to act on test results for an optimization, a migration or a release, these are the checks to ask for first. This post shows how we found both, and what the recovery test showed once we corrected for them.

The Test: One Network Drop on Google Meet and Zoom Web 

We ran this in our WebRTC Testing Lab, which automates real browsers and a physical Android phone, applies network conditions on a fixed schedule, and records WebRTC statistics (RTCStats, the browser’s getStats() data) once per second. Every run followed the same timeline: 30 seconds of normal conditions, 15 seconds capped at 500 kbps in both directions, then 30 seconds restored.

We tested Google Meet and Zoom Web on two device paths: desktop Chrome to desktop Chrome, and desktop Chrome to an Android phone. We ran the test 21 times. Each run has two devices receiving video, which gives 42 receivers. 

Recovery after a network drop is one test in a full benchmark. Others cover call quality on a steady connection, audio and video sync, processor load and mobile networks. The same method applies to any real-time audio or video product, including your own.

WebRTC Network Throttling: The Limit That Did Not Apply

We started with Chrome’s built-in network throttling, the DevTools feature that browser automation tools such as Puppeteer expose. Our first setup capped normal web traffic, and our speed test showed about 490 kbps, but Google Meet’s call video escaped it. In the clearest run, incoming video was 2.4 Mbps before the cap and 2.2 Mbps under the “500 kbps” setting. Nothing raised an error. Our lab caught it because it compares the real media rate with the cap in every run. Had we kept those runs, Meet would have looked almost unaffected by the disruption.

Chrome throttles a call connection only while its rules stay attached to it. Google Meet opens its call connections as soon as the page loads, so a cap that is cleared and set again between test steps can miss them for the rest of the call. We kept the cap attached from page load to the end of the call on every device, including the phone, which the lab drives over USB. Each device got its own 500 kbps limit in each direction, and in every run the call’s media stayed under it. Every result in this post comes from runs with that setup.

Every run also verified its own condition. Before each call, an independent speed test had to show the cap was really in force, and the exact apply and restore timestamps were recorded. The measured disruption lasted 15.1 to 15.7 seconds.

With the condition verified, the next step is deciding what counts as recovered.

Define “Recovered” Before You Look at the Result

Recovery is not one moment. We split it into four timestamps, all measured on the receiving side of the call.

• T0, network restored: the moment the disruption is lifted.
• T1, media resumes: the first one-second sample after T0 where video bytes and decoded frames grow again.
• T2, back in band: the first sample where inbound video bitrate reaches at least 80% of its pre-disruption median.
• T3, stable: the third consecutive in-band sample. Stable recovery time is T3 minus T0.

The 80% band and the three-sample rule are our benchmark criteria, not a WebRTC standard. Writing them down first matters because the same call can look “recovered” or “not recovered” depending on which number you pick. We also track frame rate against its own baseline, because packet flow alone can hide a frozen picture.

What getStats Shows About Recovery

Each second, the lab stores the full statistics report. Here is one inbound video entry from a Google Meet receiver, taken during the cap, trimmed and with identifiers removed:

{"timestamp": 1791548122391.871, "bytesReceived": 4039236, "packetsReceived": 4042,
  "packetsLost": 20, "framesDecoded": 1112, "framesPerSecond": 29,
  "frameWidth": 1280, "frameHeight": 720, "freezeCount": 8,
  "totalFreezesDuration": 2.497, "jitter": 0.014}

From these counters, bitrate is 8 × ΔbytesReceived / Δt for each one-second step, and the per-second in-band flags feed a simple streak check. The function below walks those flags in order, counting consecutive in-band seconds and resetting on any dip, and returns the moment the streak first reaches the required length: T3.

def streak_end(flags, consecutive):
    """Time of flag number K of the first run of K consecutive True flags."""
    streak = 0
    for t, ok in flags:  # one (time, bitrate >= 80% of baseline) pair per second after T0
    streak = streak + 1 if ok else 0  # any dip below the band resets the count
    if streak >= consecutive:
        return t  # T3: the third in-band second in a row
    return None  # reported as "not recovered within the window", never as zero

The first chart shows one Google Meet receiver. During the cap its video dropped to about 245 kbps but kept flowing, and it stayed at 720p with its frame rate mostly near normal. After the restore the bitrate climbed slowly, and it took 26.9 seconds to get back to 80% of normal and stay there for three seconds.

Across every Meet run, the pattern held. The second chart has one marker per receiving endpoint per run.

These numbers describe two applications under one controlled condition. They are not a ranking. Which number an engineering team trusts is the question the next sections answer.

Treat Measurement Limits as Engineering Data

The most useful findings came from what the statistics could not show.

• Some platforms hide their frames. Zoom Web carries video over a WebRTC data channel instead of standard video streams, so there is no frame rate, resolution or freeze count to read. We timed its recovery from data channel bytes. Its rate was also low before the cap: pre-disruption rates ranged from 158 to 622 kbps, mostly below the 500 kbps cap, and by the session’s end they had roughly quadrupled. Consequently, 15 out of 20 receivers were already in band before the network was restored, meaning measured recovery times reflect our 30-second reference window far more than platform performance. The next step is to read frame markers from what the receiver actually renders, so every platform is measured the same way.
• Configured is not observed. A rule that says “500 kbps” proves nothing until media rates in every phase confirm it.
• Missing is not zero. A field that is unsupported, a counter that resets or a capture that stops early is reported as such and never averaged in as 0.
• Keep three results separate: whether the call ran, whether the telemetry was complete, and how well quality recovered. Runs we excluded are listed with their reasons rather than dropped.

Those limits point straight at the decision that matters most.

From Recovery Data to a Platform Decision

Two observed differences should change how you evaluate platforms. Media never stopped on any path, but for all 22 Google Meet receivers we measured, stable bitrate took more than 20 seconds or did not return within the 30-second window. “Never stopped” and “not recovered in thirty seconds” describe the same calls.

The second difference: the same cap is not the same disruption for every platform. Zoom Web’s video was mostly running well under 500 kbps when the cap began, so during the cap it kept a median of over 90% of its normal rate, and 15 of its 20 receivers were already in band before the network was restored. That does not mean Zoom recovers faster. It means the cap barely disrupted it, so there was little recovery to measure.

If your release gate or vendor evaluation only checks that media resumes, it will pass products that leave video below its normal bitrate for 30 seconds or longer. Put a stable-recovery target in your acceptance criteria, check that the disruption actually pushed each platform below its normal rate, and require access to the statistics you need to verify it.

Building real-time communication systems is hard, and proving how they behave under real network conditions is harder. WebRTC.ventures runs independent WebRTC benchmarking for enterprise video platforms. We can compare your call quality with competitors or SDK vendors under identical network conditions, verify that every condition applied, and report what the measurements could not see. You receive a test plan, a comparative scorecard and prioritized recommendations. Ask us for a WebRTC benchmark for your call quality.

Further Reading:

• The WebRTC Monitoring Gap: Why Users Complain When Your Dashboards Look Perfect
• A Quick Tour of webrtc-internals: A Powerful WebRTC Debugging Tool
• Expert WebRTC Testing: Your Real-Time Application’s Best Investment
• Using eBPF to Debug a WebRTC SFU: Finding Where Your Media Server Eats Packets
• W3C Identifiers for WebRTC’s Statistics API