Latency Jitter and Packet Loss: What Breaks Video Calls

The screen froze at 14:03:41. I know the second because a timestamped ping was running in a side window, and between 14:03:39 and 14:03:46 it logged seven straight timeouts to a target that had answered in 24 milliseconds all morning. The speed test I ran ten minutes later, after apologizing and rejoining, came back at 238 Mbps down.

Per Zoom's own bandwidth table, read 1 September 2026, that call wanted 1.2 Mbps in each direction for 720p video. The line was delivering roughly two hundred times the bandwidth the call needed, and the call still died, because bandwidth was never the question. Seven seconds of packets went missing, and no amount of megabits stored up before or after could stand in for them.

That gap — a line that passes every speed test and still wrecks meetings — lives in three numbers no ordinary speed test screen shows you. Each one has a unit trap inside it, and each has a different published threshold depending on who you ask and when they last wrote it down.

A call is a metronome, a download is a bucket

A download is judged on one thing: how long the whole bucket took to arrive. Packets can show up late, out of order, or not at all, and TCP quietly re-requests them; the only cost is total time. A speed test measures exactly this, by flooding the line for a few seconds and timing the flood — which is why the repeatable speed test method is the right tool for proving throughput and the wrong tool for explaining a broken call.

Real-time media is the opposite contract. The call sends a stream of small packets on a clock, each describing a slice of sound or motion that is useful for that instant and worthless afterward. A packet that arrives after its slice was due to play is not late. It is lost, no matter that it arrived, because there is no rewinding a live conversation to slot it in. Retransmission, the mechanism that makes downloads reliable, is mostly useless here — the second trip would arrive even later.

The bandwidth those streams need is small enough that almost any working line clears it. Zoom's table puts 1:1 video at 600 kbps for standard quality, 1.2 Mbps for 720p, and 3.8/3.0 Mbps up/down for 1080p; group calls top out around 3.8 Mbps, and plain audio runs 60 to 80 kbps. Google's network guidance for Meet, also read 1 September 2026, budgets about 1 Mbps outbound and 1.3 Mbps inbound per participant for organizations. Even DSL clears those bars. If your plan survives what its technology can physically deliver, the megabits are table stakes — which is why the fix is never a faster plan, and why the diagnosis has to move to the three numbers below.

Latency: a 150 and a 400 that are not measured the way you measure

The engineering reference for delay is ITU-T Recommendation G.114, the 05/2003 edition, still the in-force version as of a 1 September 2026 reading of the PDF. Its two anchor figures: if delays can be kept below 150 ms, "most applications, both speech and non-speech, will experience essentially transparent interactivity," and delays above 400 ms "are unacceptable for general network planning purposes." It adds a caution that gets quoted less: highly interactive tasks — it names video conferencing specifically — "may be affected by delays below 100 ms."

Now the trap. Both figures are one-way, mouth-to-ear: from the sound leaving your lips to the sound reaching the other person's ear, including microphone capture, encoding, every network hop, the receiver's de-jitter buffer, decoding and playout. Your ping reports round-trip network time only. The two are not convertible by dividing by two, because everything outside the network — and the buffer, which we get to next — rides on top.

So use ping the way it deserves: as a relative instrument. A wired round trip in the tens of milliseconds to a nearby stable target leaves real headroom under G.114's curve. A round trip that sits at 24 ms idle and climbs past 500 ms whenever a cloud backup runs is the finding — that swing is latency under load, the queue-in-your-own-equipment problem, and the loaded-latency test in the twenty-minute Wi-Fi-or-line diagnosis is built to catch it. Distance also buys delay nobody can refund: G.114's own worked material treats intra-continental routes as comfortably under 150 ms one-way, while a geostationary satellite hop spends roughly a quarter second on physics alone.

One more unit check before you quote anyone. Cisco's Control Hub grades a Webex Calling leg as good when "Latency or Round Trip Time (RTT)" is under 400 ms — that is a round-trip figure that happens to share a numeral with G.114's one-way planning bound. Same 400, different quantity. Read the units line before comparing your log to anything.

Jitter becomes delay, or becomes loss — it never stays jitter

Jitter is variation in arrival timing: packets sent on a steady clock arriving 20 ms apart, then 3 ms, then 90 ms. Playing audio at that rhythm would be unlistenable, so every client keeps a de-jitter buffer — a short holding pen that releases packets on a smooth schedule.

The buffer does not remove jitter. It converts it, into one of two other problems:

• Into delay. Everything now waits in the pen. G.114's planning rule of thumb is that a de-jitter buffer adds half its peak accommodation to the mean delay — its worked example: a buffer sized for 50 ms of variation adds 25 ms on average. Modern clients size the buffer adaptively, growing it through a rough patch, which is why a call can drift into that underwater, talking-over-each-other feeling without a single dropped packet.
• Into loss. A packet arriving after its slot has already played is discarded on arrival. Your network delivered it; the call still counts it lost.

Microsoft's archived guidance says the same thing in one sentence: clients "can adapt to some levels of jitter through buffering," and it is "only when the jitter exceeds the buffering that a participant notices." So jitter is the hidden variable behind both of the symptoms you can feel — lag and gaps — and a line can produce broken calls with flawless average latency and 0.0 percent measured loss.

Measuring it: on macOS and Linux, a hundred-packet ping prints a deviation figure in its summary line (stddev or mdev), a fair triage proxy. Windows ping prints none — read the spread between minimum and maximum instead.

Loss: the average is an alibi

Packet loss is the easiest of the three to misread, because it is usually reported as an average, and the average launders the damage. One percent loss spread evenly across an hour is a papercut — concealment tricks in modern codecs patch single missing packets so well you will rarely notice. One percent concentrated in a two-second burst is a sentence deleted from a conversation, and the hour still averages 99 percent delivered. Microsoft's archived network document draws exactly this line: "from small, individual lost packets having almost no impact, to back-to-back burst losses that cause complete audio cut-out."

This is why the number you need is not "my loss is 0.8 percent" but when the loss happened and in what shape — which only a continuous, timestamped record can show, and only a wired one can defend. Loss measured over Wi-Fi indicts your own airspace first; the wired control in the twenty-minute diagnosis exists to take that argument off the table before you make any other.

The thresholds the vendors quietly stopped publishing

Go looking for "Zoom's official jitter limit" and you will find dozens of confident answers on comparison sites and none in a primary source. Here is the actual state of the record, checked 1 September 2026:

Two things fall out of that table. First, the only current, citable thresholds are Cisco's, and they are generous, telephone-grade grading buckets — thirty times looser on loss than Microsoft's old engineering target. Second, any threshold you meet on a blog that is attributed to Zoom or Google is somebody's invention wearing a logo. There is no number a call vendor has promised you, which means there is no number to hold them to — the baseline you measure against is your own line on a good day, which is precisely what the logging method in the speed test post exists to establish.

Worth adopting from the archived Microsoft document anyway: its measurement advice. Sample every ten minutes for at least a week and judge against the 90th percentile, not the mean. A federal-cadence version of the same idea already structures the 28-run speed log; loss and jitter columns belong in the same file.

Catching a freeze in the act

The single most useful habit this post can leave you with costs one terminal window. Before a call that matters, on the wired machine, start a timestamped once-per-second ping to a stable nearby target and let it run for the whole meeting.

macOS or Linux:

ping -i 1 1.1.1.1 | while read -r line; do echo "$(date '+%H:%M:%S') $line"; done | tee -a call_ping.log

Windows, in PowerShell:

ping -t 1.1.1.1 | ForEach-Object { "{0:HH:mm:ss} {1}" -f (Get-Date), $_ } | Tee-Object -FilePath call_ping.log -Append

When the picture freezes or a voice goes robotic, glance at the clock and type the time into any open note. That is the entire discipline. Afterward, find that second in the log. Timeouts or a latency spike at the matching timestamp: line-side finding, timestamped, repeatable, ready to sit beside your speed log. A flat 24 ms straight through the freeze: the network between you and that target is exonerated for that minute, and the suspect list shrinks to the machine, the wireless leg, the platform, or the far end — before you have spent a single support call.

Two honest caveats. ICMP ping is triage, not what the call measures — media stacks track their own RTP timing per RFC 3550, and Microsoft's archived document flatly calls ping-based assessment "not effective" for performance measurement, so treat a clean ping log as narrowing, never as proof. And most clients keep their own scoreboard: Zoom's desktop client exposes per-call latency, jitter and loss in its statistics panel, and a screenshot of that panel taken mid-failure, next to your ping log showing the same second, is the rare piece of evidence that covers both what the network did and what the call experienced.

Tonight's version is one line: set up the timestamped ping now, while nothing is wrong, and run it through tomorrow's first meeting. The freeze you catch on your own clock, matched to a spike in your own log, will do more in a support ticket than every speed test you have ever screenshotted.