VPN and video calls: latency, jitter and what to change

A video call through a VPN works, and on a nearby, lightly loaded server using a UDP transport it is hard to tell the difference. What a VPN can add is latency, which becomes a slight delay in conversation, and jitter, which becomes stutter and frozen frames. Bandwidth is rarely the issue; a call needs a modest, steady amount, and the problem is steadiness. The things that hurt are a distant server, a busy server, and a network that forces the app onto a TCP-based transport.

What a call actually needs

A video call sends a constant stream of small packets in both directions, typically several dozen per second, each carrying a slice of audio or video. The call app measures how quickly they arrive and how evenly, and adjusts quality to fit. Three properties matter, in this order.

Latency. Round-trip delay above a couple of hundred milliseconds makes conversation feel like talking over a satellite link, with people speaking over each other. A VPN adds roughly 1 ms per 100 km to the server each way plus routing, so a server on the same continent adds tens of milliseconds and a server across an ocean adds well over a hundred.

Jitter. Variation in delay is worse than delay itself. The app keeps a small buffer to smooth it, and when the variation exceeds the buffer you get dropped audio, frozen video and the robotic voice effect. Jitter comes from packets queueing, which is what a busy server or a lossy network produces.

Packet loss. A few lost packets are concealed. Bursts of loss cause frames to freeze and audio to gap. Loss comes from congestion, weak Wi-Fi and, through a VPN, from a saturated server uplink.

The latency versus bandwidth explainer covers why these matter more for calls than throughput does.

Why the transport matters more for calls than anything else

Call apps use UDP because a late packet is worthless and should be dropped, not resent. WireGuard runs over UDP and preserves that behaviour: a lost packet stays lost and the call app conceals it.

On networks that block UDP, a VPN app has to fall back to a TLS-wrapped transport on TCP port 443. TCP resends every lost packet and holds everything behind it until the resend arrives. For a file that is right; for a call it means a single lost packet delays a whole burst of audio that was already too late to play, and the call app's own recovery fights with TCP's. The tunnel also uses smaller packets (an MTU of 1280 bytes), so each call packet costs more overhead. A call on that transport works, but it stutters more than the same call over UDP, and there is no setting that changes this; it is the cost of getting through a restrictive network. UDP versus TCP for a VPN explains the trade in full.

Server load shows up as jitter first

A busy VPN server queues packets, and queueing turns a steady stream into an uneven one. Calls notice this before downloads do: a speed test through a busy server may look acceptable while the call on the same server stutters. If a call is poor and the round trip to the city looks fine, load is the likely cause, and a city with more headroom will help more than one that is a few milliseconds closer. What server load is covers how it behaves over the day.

What to change, in order

1. Pick the city with the lowest steady round trip measured from your phone. For calls, distance and jitter beat every other factor.
2. If the round trip is fine but the call still stutters, pick a city with more headroom.
3. Use Wi-Fi with a strong signal or a good mobile signal; a VPN cannot fix a weak link underneath it.
4. If you are on a network that blocks UDP and the call matters more than keeping it in the tunnel, exclude the call app from the VPN with split tunnelling for the duration.

The fourth step is a trade. With the call app excluded, its traffic goes over the plain network and the Wi-Fi owner can see that you are on a call and with which service, though not what is said, because call apps encrypt their own media. Everything else on the phone stays in the tunnel. Split tunnelling on Android explains how the exclude list works.

Things that do not help

Turning the VPN off and on again during a call makes it worse, because the call app has to rediscover the path. Switching protocols by hand, where an app even allows it, rarely helps; the app already prefers UDP and falls back only when it must. And a server in the same country as the person you are calling does not help unless it also has a low round trip from you; the call goes from you to the VPN server to the call service to them, and your leg is the one you control.

Culvert VPN measures a live round trip from your phone to each city, ranks servers by load and distance, and uses WireGuard over UDP wherever the network allows it, so a call runs on the transport calls were designed for; it is free on Google Play.