Video calls keep freezing? It is almost never your bandwidth

Someone says "you're breaking up" and you check your speed test, which reports 400 megabits. You are not short of bandwidth. You have never been short of bandwidth. A video call needs about three megabits in each direction, which is less than one percent of what you are paying for.

Calls do not fail because there is not enough capacity. They fail because the capacity is not steady, and almost nothing you normally measure tells you about steadiness. Here is what a call actually needs, and how to find out which part of it your network is failing to provide.

What a video call actually needs

Requirement	Typical need	What happens when it is not met
Bandwidth	1 to 4 Mbps each way	Video quality drops, then video turns off. Audio survives longest.
Latency	Under 150ms round trip	People talk over each other. Nothing freezes, it just feels wrong.
Jitter	Under 30ms	Robotic audio, clipped words, frozen frames.
Packet loss	Under 1%	Gaps in audio, blocky video, dropped frames.

Look at the bandwidth row, then at the other three. The one thing most people optimise for is the one thing that is almost never the problem. Jitter and loss are what break calls, and neither appears on a standard speed test result.

The jitter buffer, and why calls break before downloads do

Real time audio has a deadline. A packet carrying the next 20 milliseconds of someone's voice is useful only if it arrives before that 20 milliseconds is due to play. Arrive late and it is worthless, because the moment has passed.

Applications compensate with a jitter buffer: they hold incoming audio for a short while, typically 20 to 100 milliseconds, so packets that arrive slightly out of order or slightly late can still be played in sequence. It is a small shock absorber.

When a packet arrives later than the buffer can accommodate, it is discarded, and you hear a gap. So a late packet and a lost packet produce exactly the same result. Jitter is effectively loss, from the application's point of view.

This is why a connection can pass every test and still fail a call. A file download does not care if a packet is 200 milliseconds late. It waits, reassembles, and reports the same final speed. A call has already moved on.

It also explains a second thing: making the buffer bigger would fix the stutter but add delay, which is why applications keep it small and adapt it dynamically. When you hear audio that is smooth but noticeably behind, the application has widened the buffer to cope with your network.

It is almost always the upload

Home connections are asymmetric. A plan advertised as 500 megabits often provides 20 or 40 up, and some older cable and DSL plans offer far less. In a call, your video goes out over that upload path, so the limit that matters is the small number, not the big one.

More importantly, the upload is the easiest part of your connection to saturate, and saturating it does not just slow things down. It fills the queue, latency climbs sharply, jitter goes with it, and every real time application on the network degrades at once. A single cloud backup, one photo library sync, one large email attachment or one person uploading a video can do it.

The signature is distinctive: the call is fine, then abruptly terrible, then fine again, and it correlates with something else starting rather than with any change in the call itself.

Two things make this much better. First, find out what is uploading. Second, if your router supports smart queue management, turn it on. It keeps latency low even when the link is full, which is precisely the failure mode that ruins calls. There is more on that in the post about slow internet with a clean speed test.

Testing during a call

The measurement has to happen while the problem is happening. A test afterwards, when everything is calm, describes a network you were not using.

1. Run a continuous ping for the whole call

   Set the count to 0 against 1.1.1.1 and leave it going. Watch the per packet values rather than the average. Flat numbers with occasional spikes point at congestion. Consistently high numbers point at distance or routing.

2. Ping your own router at the same time

   If the gateway shows jitter too, the problem is between your device and the router, which means Wi-Fi. If the gateway is rock steady and the internet target is not, your local network is fine and the problem is further out.

3. Note the exact moment it freezes

   Then look at what the ping was doing at that moment. A latency spike at the same time is the entire diagnosis.

4. Measure jitter explicitly

   The speed and latency baseline reports jitter alongside throughput. Run it before a call and during a bad one and compare the two numbers. This is the figure to quote when someone insists the connection is fine because the download speed is high.

5. Check whether the problem follows the network or the device

   Join the same call from a phone on cellular data. If it is smooth there, the problem is your network. If it stutters there too, the problem is the service, the other participants, or something on your device.

# Leave running for the whole call and watch the shape
https://netdebug.app/open/ping?target=1.1.1.1&count=0

# Latency, jitter and throughput in one pass
https://netdebug.app/open/speed?download=32&upload=8

The causes, in order

1. Wi-Fi

The leading cause by a wide margin, because Wi-Fi produces variable delay rather than constant delay, and variation is what calls cannot absorb. A retransmitted frame adds milliseconds unpredictably. Contention with neighbouring networks does the same. So does a client that dips into power saving between packets.

The single most informative test: join one call on a cable. If it is perfect, you have your answer and can stop reading.

2. A saturated upload

Covered above, and worth checking before anything else if the failures are episodic rather than constant.

3. Distance to the meeting server

Conferencing platforms pick a region, usually based on the organiser or the first participant. A call hosted on another continent starts with 150 milliseconds of unavoidable delay, and every further problem stacks on top of that. This is why the same platform feels different from one meeting to the next.

4. The other person

Worth stating plainly, because it gets overlooked. If one participant has a bad connection, everyone experiences it as a problem with the call. Before rebuilding your network, check whether the freezing is one person or everybody. It is remarkably often one person.

5. The device, not the network

Video encoding is demanding. An older laptop with a full CPU will drop frames regardless of the network, and the symptoms look identical. If the call stutters while the ping stays flat, look at the machine rather than the connection.

6. VPNs and security software

A VPN adds a hop, adds encryption overhead, and often adds distance. Some corporate setups route all conferencing traffic through a data centre, which is exactly the worst thing to do with real time media. Inspection software that examines every packet adds delay too. Test with them off, if policy allows.

The mid-call Wi-Fi handover nobody suspects

This one is worth knowing because it produces a very specific symptom and almost nobody diagnoses it correctly.

If you have a mesh system or more than one access point, your device decides when to move between them. That decision is made by the client, not the network, and clients are often slow and bad at it. They hold onto a weak access point far too long, then switch abruptly.

During the switch, which can take anywhere from a few hundred milliseconds to a couple of seconds, your traffic stops. On a web page you would never notice. On a call, the audio drops out and the video freezes, then everything recovers.

The signature: calls break when you move around, or at roughly the same physical spot every time. Walking from a desk to a kitchen during a call and having it stutter at the same doorway is not a coincidence.

What helps: staying put during important calls, which is unglamorous but effective. Beyond that, some mesh systems allow tuning the signal threshold at which they encourage a client to move, and enabling the fast roaming standards (802.11r, k and v) if every device supports them. Older devices sometimes behave worse with those enabled, so change one thing at a time.

The short version

A call needs a few megabits, so bandwidth is almost never the problem. It needs consistency, and jitter above roughly 30 milliseconds is heard as broken audio because late packets are discarded exactly like lost ones. Measure during the call, not after. Check your upload rather than your download, test once on a cable to rule Wi-Fi in or out, and if calls always break in the same physical spot, you are watching your device hand over between access points.