What causes network jitter, how to test it, and why Zoom and VoIP calls break up

By Michael Obraitis, Managing Partner, and Michael Dale, CEO·Published August 12, 2026·Last reviewed August 2026·Last reviewed August 29, 2026·ADAM Pulse Knowledge Base

Answer

Network jitter is the variation in arrival time between packets in the same stream. Voice and video break up when that variation exceeds what the receiving jitter buffer can absorb, even while latency and packet loss look fine. Microsoft publishes 30 ms as its jitter threshold across Teams and Microsoft 365. Zoom Phone QoS publishes no jitter ms number, only a 300 ms round-trip delay limit; a separate Zoom statistics article says typically 40 ms or less. Use 30 ms as the ADAM Pulse working target for both platforms, labeled as our judgment. Measure jitter with repeated samples across the reported incident window, never with a single ping or a speed test.

Chapters. A healthy stream (0:02) · Same circuit at 70 ms (0:11) · Only one number changed (0:23) · What to measure against (0:30)

Explainer transcript

What causes network jitter. Why Zoom and VoIP calls break up when packet loss is zero.

A healthy stream. About 3 milliseconds of jitter. Zero packet loss. The jitter buffer absorbs the variation. No audible gaps.

Same circuit at 70 milliseconds of jitter. Still zero packet loss. The buffer under-runs. You hear the gaps.

Only one number changed. Loss stayed at zero. The gaps came from timing, not missing packets.

Microsoft publishes under 30 milliseconds across Teams and Microsoft 365. Zoom meeting and phone statistics say typically 40 milliseconds. Zoom Phone QoS has no jitter millisecond number, only a 300 millisecond round-trip limit. ADAM Pulse uses 30 milliseconds as our working target.

The published thresholds

These are first-party figures, not secondary summaries. The Zoom Phone QoS row and the Zoom statistics row are different articles. Do not mix them.

30 ms is the only jitter number Microsoft publishes consistently across those four products. Zoom’s QoS document is silent on jitter ms. Zoom’s statistics article says typically 40 ms. Nothing in the packet-timing physics changes between Teams and Zoom, so 30 ms is a defensible working threshold. That is our judgment, not a Zoom recommendation.

Zoom grades call quality by MOS on KB0065975: 4.0–5.0 Good, 3.0–4.0 Fair, 2.0–3.0 Poor, 1.0–2.0 Bad. Admins can set their own network alert thresholds. Those MOS bands are a quality grade, not a jitter millisecond figure, and they do not replace the table above.

What jitter actually measures

Jitter is not delay. Delay is how long a packet takes. Jitter is how much that delay changes from packet to packet in the same stream.

A healthy stream might arrive at 20, 22, 19, 21 ms. A ruinous stream can arrive at 20, 85, 24, 110 ms with no loss at all. Average latency can look acceptable in both cases. The conversation only survives the second series if the jitter buffer can hold the late packets long enough to play them in order.

RFC 3550 defines the interarrival jitter estimate that RTP voice and video platforms report. Bandwidth is capacity. Jitter is consistency. A speed test measures neither a real-time stream nor a jitter series, so it does not prove call quality.

Why the jitter buffer decides what users hear

The receiving endpoint holds arriving packets for a short playout delay so they can be released at a steady rate. Cisco’s delay-details note states the design target directly: the optimum initial playout delay for the de-jitter buffer equals the total variable delay along the connection. Hold too little and the buffer under-runs. Hold too long and the conversation itself becomes late.

Users hear buffer failure, not jitter. When the buffer empties, audio chops, words drop, and video freezes. When it overruns, packets are discarded and the symptom looks like loss even if the network delivered every packet. 30 ms is a threshold, not a cliff. A 31 ms sample does not instantly ruin a call. A repeated series that stays above the buffer’s ability to absorb variation will.

What produces jitter

Investigate in this order. The first three are local and cheaper to prove. The carrier path is last.

1. Wireless. Interference, retransmissions, weak signal, congestion, roaming, and competing devices add variable delay before traffic reaches the LAN.
2. Local congestion and queueing. A saturated uplink, a backup window, or a bulk transfer sharing the same queue makes one packet wait and the next pass. That variation is jitter.
3. The edge device. Firewall CPU exhaustion, deep inspection on media, a software VPN, and SIP ALG or VoIP inspection can delay packets unevenly even when the circuit is clean.
4. The carrier path last. Upstream congestion, unstable routing, and oversubscription can add jitter beyond the gateway. Do not open that ticket until the first three are measured.

Can SD-WAN hide a jitter problem?

Yes. An overlay can steer real-time traffic onto a healthier path and make the application look fine while the underlay circuit is still unstable. That is useful for users and a problem for diagnosis. Monitor the underlay independently of the overlay. If the overlay is hiding daily jitter bursts, you will not see them in the Zoom dashboard, and you will not have evidence when the backup path is the one that fails.

How to test jitter properly

1. Sample continuously across the reported incident window, not once. Jitter is a series. One ping is a single delay sample.
2. Test from the site that reported the problem. A probe in another city, or a laptop on a hotspot, answers a different question.
3. Use multiple destinations. If jitter appears toward every external target, the problem is local or on the access circuit. If it appears toward one destination only, the problem is path-specific.
4. Keep the raw series. Peaks, duration, and recurrence live in the samples, not in a monthly average.
5. Correlate with the Zoom dashboard. Match the network timestamps to meeting or phone statistics for the same window. The application score tells you what users heard. The series tells you whether the network produced it.

Why averaged jitter is misleading

A monthly SLA average can hide a daily five-minute burst that made every standup unusable. Report peaks, duration, frequency, and recurrence. A site that is clean for 23 hours and 55 minutes and unusable for five minutes during the board call is not a healthy site. The average will say it is.

How to tell whether jitter is local or upstream

Compare boundaries. The first boundary that shows the variation owns the problem.

What evidence an ISP will actually act on

Carriers do not act on “Zoom sounded bad.” They act on a window, a circuit, and a comparison. Take this to the ticket:

• Site address and circuit ID
• Incident window with the timezone labeled
• Jitter, latency, and loss during the window, plus the same three on a quiet baseline
• Results toward at least three destinations
• Gateway and firewall health for the same window
• Whether WAN failover occurred
• Prior dates if the pattern has recurred

Frequently asked questions

Sources

• IETF — RFC 3550: RTP, A Transport Protocol for Real-Time Applications (July 2003, Internet Standard, STD 64). Defines the interarrival jitter estimate that voice and video platforms report.
• Zoom — Implementing Quality of Service for Zoom Phone (KB0076072). 300 ms RTT, 60 to 100 Kbps, “minimal” packet loss. No jitter millisecond number.
• Zoom — Accessing meeting and phone statistics (KB0070504). “Typically, a jitter of 40ms or less is recommended.”
• Zoom — Using meeting quality scores and network alerts (KB0065975). MOS bands: 4.0–5.0 Good, 3.0–4.0 Fair, 2.0–3.0 Poor, 1.0–2.0 Bad.
• Microsoft — Stream classification in Call Quality Dashboard. Audio poor when jitter ALL > 30 ms, RTT ALL > 500 ms, packet loss rate ALL > 0.1. Verified live 29 August 2026.
• Microsoft — Use real-time telemetry to troubleshoot poor meeting quality. Audio good threshold: jitter less than 30 ms, RTT less than 500 ms, loss less than 5%. Verified live 29 August 2026.
• Microsoft — Office 365 network connectivity test and Microsoft 365 network insights. UDP jitter lower than 30 ms, UDP latency lower than 100 ms, UDP loss lower than 1.00%. Verified live 29 August 2026.
• Microsoft — Manage the Walkie Talkie app in Microsoft Teams. Jitter < 30 ms, RTT < 300 ms, loss < 1%. Verified live 29 August 2026.
• Cisco — Understanding Delay in Packet Voice Networks (document 5125). Optimum initial playout delay equals total variable delay.
• ITU-T — Recommendation G.114, One-way transmission time. Delay bands only. Jitter is not addressed.
• IETF — RFC 8867: Test Cases for Evaluating Congestion Control for Interactive Real-Time Media (January 2021). How delay and loss are evaluated for real-time media.

ADAM Pulse watches jitter, latency and loss on the same circuits that carry Zoom and VoIP, so a choppy call has a timestamped cause rather than a guess.

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us