Latency for Video Calls and VoIP: Targets and Fixes

Quick answer: a voice or video call is a real-time stream of small packets that must arrive on time, in order and almost without loss. Widely cited ITU-T G.114 guidance puts acceptable one-way delay for conversation at up to about 150 ms; beyond that, people start to talk over each other. Equally important are jitter (uneven packet arrival) and packet loss (packets that never arrive). Call quality problems at home are most often caused by weak Wi-Fi or a congested upload link, rather than by a slow plan. This page explains the targets, how call apps compensate, and how to find the cause when a call goes wrong.

Important: ping is not the same number as GlobeLatency's HTTPS latency. The ranges on this page describe round-trip time to the server you actually use (what ping, or a game's own ping display, shows). GlobeLatency times full HTTPS requests from the browser, which include DNS, TCP and TLS setup on a fresh connection (roughly three round trips) plus server and browser time, so its numbers are usually higher than ping to the same server, often 1.5 to 3 times on a cold connection. Judge GlobeLatency results by the colour and the comparison with the world average, and use these ranges for ping or in-game latency. See ping vs HTTPS latency.

Why calls are different from downloads and streaming

A file download or a recorded video can be buffered: the app can wait seconds for data and nobody notices. A call cannot. Every sentence you speak must reach the other person within a fraction of a second, so the app cannot wait for late packets for long. That makes calls sensitive to three things:

• Latency: how long a packet takes from you to the other person (one-way) or there and back (round trip). Explained in what is latency.
• Jitter: variation in that delay. See jitter explained.
• Packet loss: packets that are dropped or arrive too late to use. See packet loss explained.

Bandwidth matters only as a minimum: a call needs a modest, steady rate in both directions. See latency vs bandwidth vs throughput for the distinction.

What one-way delay is acceptable? The G.114 guidance

ITU-T Recommendation G.114 is a widely cited standard on one-way transmission time for voice. The commonly quoted summary, which is guidance rather than a hard rule, is:

One-way delay (mouth to ear)	Typical experience
0 to about 150 ms	Acceptable for most conversations; natural turn-taking
About 150 to 400 ms	Acceptable for some uses but noticeable; people interrupt each other more
Above about 400 ms	Generally unacceptable for interactive conversation

"Mouth to ear" is the total delay including everything, not just the network. A call app also spends time on:

• capturing and encoding audio (often 10 to 40 ms depending on codec frame size),
• the jitter buffer at the receiver (commonly tens of milliseconds),
• decoding and playout,
• for video, capture, encode, decode and display, typically adding tens to a hundred or more milliseconds.

So the network budget is smaller than 150 ms.

Worked example: building a delay budget

Say two people are in different continents. The network round trip between them is 160 ms, so one-way is about 80 ms. Add 30 ms encode and packetising, 40 ms jitter buffer and 20 ms decode and playout. Total mouth-to-ear delay is about 170 ms, slightly above the 150 ms guidance but still usable. If one person is on weak Wi-Fi that adds 30 ms on average and a 100 ms spike now and then, the spikes push the buffer to grow and total delay moves past 250 ms, where interruptions start. The call does not need to be perfect, but each added stage uses budget.

How call software hides imperfections

Jitter buffers

Packets are sent at an even pace, perhaps every 20 ms for audio, but arrive unevenly. The receiver holds them in a jitter buffer and releases them at an even pace. Buffer size is a trade-off: bigger hides more jitter but adds delay. Modern apps adapt the size dynamically, so a quiet link has a small buffer and a bad link gets a bigger one, which is why a poor connection sounds both delayed and glitchy.

Codecs and bitrate adaptation

A codec compresses audio or video. Voice codecs commonly run at roughly 6 to 64 kilobits per second; wideband codecs sound clearer and cost a bit more bandwidth. Video codecs use far more, from a few hundred kbit/s to several Mbit/s. Many apps measure the path and automatically lower resolution, frame rate or bitrate when loss or delay rises. That is why video turns blurry first, while audio keeps working.

Packet loss concealment and error correction

Packet loss concealment (PLC) is the receiver guessing the missing audio, by stretching the previous sound. It works for a single lost 20 ms packet; it fails over several in a row, producing robotic or choppy speech. Many systems also send redundancy, called forward error correction, trading extra bandwidth for resilience, and some retransmit lost video packets when the delay allows. Rough guidance: under about 1 percent loss is usually hidden; 1 to 3 percent is audible on some paths; above 5 percent most calls degrade clearly. Burst loss is more damaging than the same average spread evenly.

Zoom, Microsoft Teams, Google Meet and similar apps

Popular meeting apps use the same building blocks described above: UDP-based real-time media where possible, a fallback over TCP or HTTPS when firewalls block UDP, adaptive bitrate, and servers in cloud regions that relay or mix media. Exact codecs, bandwidth numbers, ports and region selection differ per product and change over time, so check your provider's current network requirements page for specifics. General points that apply to all of them:

• If UDP is blocked by a corporate firewall, calls fall back to TCP, which adds delay and makes loss feel worse because TCP retransmits and waits.
• Large meetings often route media through a server, so your latency depends on the distance to that server, not to the other person.
• Peer-to-peer media paths (common in one-to-one calls on some services) depend on how your NAT behaves; see IP addresses, IPv4, IPv6 and NAT.
• Apps' own statistics panels, where offered, show round-trip time, jitter and loss as the app sees them. Use them alongside an independent measurement.

Upload bandwidth and why it is often the real problem

Home connections are often asymmetric, with much less upload than download. A video call sends your video up while receiving others down. A single HD video stream can use a few Mbit/s upstream. If you have 10 Mbit/s of upload and another device is backing up photos at full speed, the queue in your router fills, and the delay grows into hundreds of milliseconds. That effect is bufferbloat.

Situation	What happens	What you see
Upload fully used by a backup	Packets queue in the modem or router; delay rises by the queue size, often 100 to 1000 ms	Delayed audio, then bursts of catch-up
Several people on video in one home	Combined upstream exceeds available upload	Frozen or blocky video for everyone
Upload fine, Wi-Fi congested	Frames are retried over the air	Random short stutters

Wi-Fi issues that damage calls

Wi-Fi shares the air. Retransmission is invisible to apps but shows up as jitter. Typical culprits: distance and walls, a crowded 2.4 GHz band, microwave ovens, a laptop's power-saving mode that wakes the radio slowly, and many devices streaming at once. Fixes in order of usefulness: use Ethernet for the call machine; move closer or add an access point; use 5 GHz or 6 GHz; pick a less crowded channel; and keep large transfers off the network during meetings. See Wi-Fi, Ethernet, fibre, mobile and satellite latency.

QoS and prioritisation

Quality of Service (QoS) tells a router to prioritise some traffic, such as calls, over others when the link is busy. It helps only when the bottleneck is a link you control, usually your own router's upload. Packet markings (such as DSCP) are often ignored once traffic leaves your network, so QoS cannot improve the internet beyond your router. Smart queue management (SQM) in your router is often more effective than manual rules because it limits queue build-up for all traffic. Set the shaper slightly below your real line rate, for example 90 to 95 percent, so the queue forms in the router, where it is managed, instead of in the modem.

How to diagnose a call problem with GlobeLatency Monitor

You usually cannot reproduce a glitch on demand, so continuous measurement is the right tool. Calls and measurements share the same network, so what you see reflects what the call sees, as far as your access link goes.

1. Before the call, open the monitor in its own window on the same device or another one on the same network. Pick a few destinations: one or two nearby, one or two in the region of your meeting servers, and one in a distant region for contrast.
2. Set the interval to 5 to 10 seconds for finer detail. Keep the window visible; browsers throttle background tabs.
3. During the call, note the time whenever audio or video degrades.
4. Afterwards, read the cards: the sparkline shows spikes, the worst value and 95th percentile show tail behaviour, and the no-reply percentage shows gaps.

Interpretation: if all destinations spike together at the glitch moment, the problem is between you and the internet (Wi-Fi, router, bufferbloat, ISP). If only a distant destination spikes, it is a path issue elsewhere and probably not your home. If nothing moves while the call is bad, the cause is probably the meeting provider or the other participant. More detail in the monitor guide. Remember GlobeLatency measures HTTPS round trips from the browser, not the call media itself.

Common mistakes and myths

• Checking only a speed test. It does not reveal jitter or short stalls.
• Blaming the app first. Check your local network before assuming the provider is at fault.
• Running one test. Intermittent problems need continuous measurement over time.
• Using a VPN during calls without measuring. It may add distance and delay; see VPN and latency.
• Treating 150 ms as a network-only budget. Processing and buffering consume part of it.

What to do next

Run a free latency test on the call device, preferably on Ethernet and then on Wi-Fi, and compare. Work through how to reduce latency and, for persistent problems, troubleshoot high latency.