VoIP latency is the mouth-to-ear delay between when you speak and when the other person hears you. Aim to keep that one-way delay under 150 milliseconds, with jitter under 30 milliseconds and packet loss near zero. If a call sounds off, the first move is to run a repeated latency and jitter test rather than guess at the cause.
TL;DR:
- High packet loss near zero is essential because even small sustained losses create audible artifacts during calls.
- Testing both wired and Wi-Fi connections under different network loads at multiple times helps identify persistent latency issues.
- Avoid routing VoIP calls through VPNs or proxies, as they often introduce significant additional delay and instability.
- Using a jitter buffer that is too large can improve smoothness but substantially increases conversational delay, masking underlying network problems.
- Maintaining one-way delay below 150 milliseconds is critical for natural speech; delays over 150 ms cause noticeable talk-over and awkwardness.
Table of Contents
- Understanding one-way delay, jitter, and the thresholds that matter
- How do you actually measure VoIP latency?
- Matching call symptoms to their likely cause
- A prioritized checklist for fixing VoIP latency at home or in a small office
- Building a test plan that proves where the problem lives
- What network testing actually reveals about VoIP calls
- Run a focused latency check before you call support
- Where these numbers and guidelines come from
- Sources
- FAQ
Understanding one-way delay, jitter, and the thresholds that matter
Round-trip time (RTT), the number most speed tests show, is not the same thing as mouth-to-ear delay. RTT measures how long a signal takes to travel to a server and back. Mouth-to-ear delay measures the one-way path a voice packet actually takes, plus everything added before and after transmission: codec lookahead, packetization, processing, and jitter buffering, according to ITU-T Recommendation G.114. That standard recommends keeping one-way delay below 150 milliseconds for calls that feel natural, tolerates 150 to 400 milliseconds with growing awkwardness, and treats anything past 400 milliseconds as unacceptable for planning purposes.
Codec choice and packetization interval add their own fixed delay before a single packet hits the network. Jitter buffers add more, smoothing out uneven arrival times at the cost of extra conversational lag.
Keep these bands in mind when you read your own numbers:
- Below 150 ms one-way: feels like a normal phone call, per ITU-T G.114.
- 150 to 400 ms one-way: usable but increasingly prone to talk-over and awkward pauses.
- Jitter under 30 ms: the level Google Workspace recommends for stable voice quality.
- Packet loss near zero: even small sustained loss produces audible artifacts.
One-way delay under 150 milliseconds is the threshold that separates a natural-sounding call from one where people start talking over each other, according to ITU-T Recommendation G.114.
How do you actually measure VoIP latency?
Most people only ever see a ping number, which tells you part of the story but not the whole one. A useful measurement session combines a quick browser check with a few repeated runs at different times of day.
- Run a browser-based latency and jitter test while on the network you actually use for calls, noting RTT, mean jitter, and percent packet loss.
- Repeat the same test three to five times across a few hours, since congestion often shows up only during peak usage windows.
- Test once wired and once on Wi-Fi to isolate whether the access point or the broader connection is the bottleneck.
- Compare results with and without a VPN or proxy active, since either can add delay or hide instability.
Advanced diagnostics use UDP jitter probes that simulate real VoIP traffic and report RTT, one-way delay, one-way jitter, and directional packet loss, as documented in Cisco's IP SLA UDP jitter operation. Cisco also notes that accurate one-way delay measurement requires NTP time synchronization between both endpoints. Without that synchronization, RTT divided by two is a reasonable, if conservative, stand-in for one-way delay.
GrandSpeed's Speed Test reports latency, jitter, packet loss, and bufferbloat in one pass and keeps a history of past runs, which makes the repeated-test approach easier to manage than juggling separate tools.
Pro Tip: Run your comparison tests within the same 30-minute window whenever possible so time-of-day congestion does not skew the wired-versus-Wi-Fi comparison.
Matching call symptoms to their likely cause
Different problems sound different, and matching the symptom to the metric saves time before you start changing settings.
- Talk-over or long awkward pauses: usually points to high one-way delay rather than jitter or loss.
- Robotic, clipped, or garbled audio: typically traces to packet loss or jitter, since delayed or missing packets force the receiving end to guess at gaps, per Cisco's QoS troubleshooting guide.
- Echo: often a combination of delay and an echo-cancellation setting that cannot keep up with it.
- Audio that cuts in and out under load: suggests bufferbloat or congestion rather than a distance-related delay problem.
Jitter buffers exist to smooth out uneven packet arrival, but Cisco's guidance notes that an oversized buffer trades one problem for another: it can grow enough to add noticeable conversational delay while still discarding packets that arrive too late. A real-time voice engineering resource makes a similar point about balancing smoothing against added lag in latency-sensitive audio pipelines.
Before troubleshooting further, run a quick triage: test wired versus Wi-Fi, with and without a VPN, and during an idle network versus one under active load from downloads or streaming.
A prioritized checklist for fixing VoIP latency at home or in a small office
Start with the changes that cost nothing and take minutes, then work toward network-level fixes if the problem persists.
- Switch to a wired Ethernet connection for the call if you are on Wi-Fi, since wireless interference is a common hidden contributor to jitter.
- Pause large uploads or downloads during calls, since saturated bandwidth is one of the most common causes of sudden latency spikes.
- Reboot your router and modem, which clears transient congestion and stale connection states.
- Enable Quality of Service (QoS) or DSCP tagging for voice traffic on your router if it supports it, giving voice packets priority over bulk data.
- Avoid routing calls through a VPN or proxy when you can, since Google's voice connectivity guidance notes that proxies and deep packet inspection frequently add latency and instability.
- Move Wi-Fi devices to the 5 GHz band where available, since 2.4 GHz is more crowded and more prone to interference.
- Update your access point's firmware and, where possible, use 802.11ac or 802.11ax hardware for lower baseline latency.
- Update your VoIP device or softphone firmware, and check whether your provider allows a shorter packetization interval or a lower-latency codec.
Pro Tip: If none of these moves close the gap, capture two or three repeated test results, wired and wireless, before contacting support: a single snapshot rarely convinces a provider that the problem is on their end.
When none of this resolves the issue, gather your evidence and escalate. Providers respond faster to a support ticket that includes actual numbers than to a description of "bad calls."
Building a test plan that proves where the problem lives
A single test result rarely settles an argument with an ISP or VoIP provider. A short, structured comparison does.
- Run the same latency and jitter test wired, then on Wi-Fi, using the identical test target both times.
- Repeat with and without any VPN or proxy active to isolate added delay from routing.
- Test once when the network is idle and once while another device is streaming or uploading.
- Repeat the full set at two or three different times of day to catch congestion patterns that a single test misses.
For each run, note the RTT, mean jitter, and percent packet loss, along with the exact timestamp and conditions. Cisco's UDP jitter methodology notes that accurate one-way delay depends on NTP-synchronized clocks at both ends, so absent that setup, treat half the RTT as a conservative estimate rather than an exact figure.
A useful support ticket includes:
- Test timestamps and network conditions for each run (wired or Wi-Fi, VPN or not, idle or busy).
- RTT, jitter, and percent packet loss for each test.
- The test URLs or tool used, so the provider can reproduce your results.
What network testing actually reveals about VoIP calls
Mouth-to-ear delay is never just a network number. Codec processing, jitter buffering, and device handling all add time before a packet ever leaves the building, which is why two people on the same connection can report different call quality.
One trap is worth calling out directly: a bigger jitter buffer can make an unstable connection sound smoother while quietly adding more conversational delay, the exact tradeoff Cisco's troubleshooting documentation describes. Fixing the symptom this way often buries the real problem instead of solving it.
The habit that separates a useful diagnosis from a guess is repetition. One test, run once, tells you almost nothing about whether a problem is constant or tied to a specific time of day, device, or network path.
— Peter D
Run a focused latency check before you call support
Generic speed tests report a download number and leave you guessing about the metrics that actually break calls. GrandSpeed's Speed Test measures latency, jitter, packet loss, and bufferbloat in a single run, and its Video Streaming Quality Test adds the streaming-specific detail that a plain speed check skips entirely.
- Latency, jitter, and packet loss reported together instead of as a single vague score.
- Bufferbloat and DNS timing included, since both can add hidden delay under load.
- Saved test history, so you can compare wired versus Wi-Fi or morning versus evening without rerunning everything from scratch.
Run a test at grandspeed.net before your next support call, save the results, and bring the numbers with you instead of a description of how the call sounded.
Where these numbers and guidelines come from
The thresholds and testing methods referenced here come from long-standing telecom standards and current vendor guidance rather than informal rules of thumb.
- ITU-T Recommendation G.114 sets the one-way delay bands used throughout this article.
- Cisco's IP SLA UDP jitter operation documents the testing methodology behind repeated jitter and packet loss measurement.
- Google Workspace's voice network guidance supplies the practical operational cutoffs for latency and jitter.
Sources
- ITU-T Recommendation G.114 (one-way transmission time)
- Google Workspace: optimize your network for voice
- Troubleshooting QoS choppy voice issues — Cisco
FAQ
How much latency is acceptable for VoIP?
Aim for one-way delay under 150 milliseconds, the threshold ITU-T G.114 recommends for natural-sounding conversation. Delay between 150 and 400 milliseconds is usable but increases awkward pauses and talk-over, while delays higher than 400 milliseconds are generally unacceptable.
Is a latency of 20 ms considered good?
Yes, a one-way delay well below 150 milliseconds sits within the range ITU-T G.114 treats as transparent for normal conversation. Google Workspace guidance similarly favors latency under 100 milliseconds to backend servers, leaving comfortable headroom.
Is 30 ms jitter bad?
No, 30 milliseconds is the upper bound Google Workspace recommends for mean receive jitter, not a warning sign on its own. Jitter above that level starts to strain the jitter buffer's ability to smooth playback without adding noticeable delay.
Is 40 ms of latency bad?
No, one-way delay well below 150 milliseconds is considered transparent for normal conversation by ITU-T G.114. Problems typically appear as delay climbs toward or past 150 milliseconds, not at lower delay values.