The video call keeps breaking up, but the test says the line is fast. Why?

You are in a meeting. Your voice arrives in fits and starts, the picture stops dead, somebody types “we can’t understand a word” in the chat. So you open a speed test, and the test says 200 Mbit/s. You look at that number and decide the problem must be at the other end, or in the software, or in your luck.

The number isn’t lying to you. It’s answering a different question from the one you have.

There are two explanations in here, and the second one is the one you almost never read.

First explanation: you are looking at the wrong number

A video call is the one thing you do on the internet where you send as much as you receive. Watching a film is almost all downhill. A meeting goes uphill as well, continuously, for as long as your camera is on.

The figures the platforms publish say so, you just have to read the column nobody reads.

Microsoft, for a Teams meeting in what it calls the recommended profile, gives 2,500 kbit/s up and 4,000 down for each participant, and notes that somebody joining from a computer and a phone at the same time counts as two. Zoom, for group video, states something worth reading twice: in high definition at 720p it asks for 2.6 Mbit/s up and 1.8 down. More up than down, written in their own table. Google Meet, for a group meeting, talks about 250 kbit/s and above going up depending on the resolution you send, and up to 4 Mbit/s coming down.

WhatsApp publishes nothing. I went looking, and the calls page only gives the limits on how many people can join.

Now take your own line. As of March 2026, according to the observatory published by AGCOM, the Italian communications regulator, 39.7% of Italian fixed lines are still FTTC, meaning fibre as far as the street cabinet and copper the rest of the way home: it is the most widespread technology, ahead of FTTH at 36.1%. On an FTTC line, TIM states 200 Mbit/s down and 20 up. That is a ratio of ten to one. The minimum the contract guarantees is lower still, down and above all up: the figure for your own offer is on your provider’s technical transparency page, and it is worth going to read it.

Twenty megabits upstream is enough for a meeting, in theory. The catch is that it is enough if it is all yours.

Second explanation: the queue

This is the part that accounts for ninety per cent of real cases, and it has a name: bufferbloat.

It works like this. When a program sends data, it speeds up until it notices the link is full, and it notices because some packet gets thrown away. That is the stop signal. But network devices, over the last twenty years, have filled up with memory: instead of throwing the surplus packets away they put them in a queue. The stop signal never arrives, the program keeps speeding up, and the queue gets longer.

And in that queue, behind your backup, sits your voice.

Jim Gettys measured his own home line during a 20 GB transfer, and in 2011 he published it with Kathleen Nichols. Response time on an idle line sat below 10 milliseconds. During the transfer it went past 1.2 seconds and stayed there, with average packet loss of 33%. After putting a brake on the sending rate, same transfer, that same response time was 18.7 milliseconds.

Twelve hundred milliseconds against ten: two orders of magnitude apart. And while it is happening, the speed test carries on saying the line is fast, because the line is fast: it is the queue that is full.

Set those figures against the platforms’ own thresholds. Microsoft classifies an audio stream as poor above 500 milliseconds of response time, jitter above 30, or loss above 10%. Google says Meet quality is best under 100 milliseconds and degrades from 300 upwards. With a full queue you are outside all of those thresholds at once.

One clarification Microsoft makes, and it seems right to pass it on: going past those thresholds does not automatically mean you will notice a problem, because the software is built to cope with bad network conditions. Degradation is likely, not mechanical.

How to tell whether this is it

Here I have to be honest about what the tool I have put on this site does and does not do.

In How good is my connection? you get response time and stability, that is, how much it varies from one request to the next. Those are two useful numbers and they are measured at rest, while nothing else is going on. If stability already looks bad at rest, you have found your problem without looking any further. But if everything is fine at rest and the meeting goes badly anyway, that test won’t tell you, because it measures at the wrong moment. Measuring under load is the next thing I want to add.

In the meantime, the kitchen-table test works just as well and costs nothing: start the measurement while somebody in the house is uploading something big, or while you download a heavy file yourself. If response time goes from a few tens of milliseconds to a few hundred, you have seen the thing with your own eyes.

If you want a measurement done properly, there are tests built for it. Cloudflare, in its speed test, measures response time both idle and under load and puts them side by side: their practical guidance is that on a wired connection a difference approaching 100 milliseconds or more points at the line provider. There is also a dedicated test run by Waveform, which is a company that sells hardware, and I think that is worth saying.

What can actually be done

The order matters, because the first two things cost nothing and sort out the majority of cases.

1. Pause whatever is uploading. The most frequent culprit is cloud sync, which works upstream exactly while you are in a meeting. On OneDrive you can do better than pausing it: in the advanced settings there is a limit on upload speed with an option to adjust it automatically, which uploads files only with the bandwidth left over. Microsoft states that this is precisely so as not to disturb other programs. I have not checked the settings of the other cloud services, so have a look in yours.
2. Turn down what you send, not what you receive. In Google Meet, under video settings, there are two separate entries: the resolution you send and the one you receive. Lowering the first reduces upload, which is the bottleneck. On Zoom and on Teams, by contrast, the levers for limiting bandwidth exist only for network administrators, and Zoom writes explicitly that limiting bandwidth should only be done in very specific circumstances. For somebody at home, there is no slider there.
3. Try a cable, at least once. It tells you where the problem is rather than fixing it. If it's fine plugged into the router and bad on Wi-Fi, you have moved the problem from the line to your home network, and that is another article.
4. Look at who else is on your network while you are in a meeting: a television updating itself, a console pulling down a game, a phone backing up its photos. They all use the same queue.
5. If it happens every time and nothing else explains it, the technical remedy exists and it is called smart queue management. You will find it on routers as SQM, and it rests on algorithms described in two technical documents from 2018, RFC 8289 and RFC 8290, which are classified as experimental rather than as standards.

Two warnings on that last point, one technical and one practical.

The technical one comes from the people who have been studying the problem for fifteen years, and it takes apart three shortcuts: moving to a faster package doesn’t help, because the problem is the queue and not the speed; buying an expensive router, or one with “gaming” on the box, doesn’t help, because plenty of manufacturers don’t address the problem at all; and fiddling with the router’s priority settings helps very little.

The practical one concerns Italy. I went looking for whether the routers Italian providers hand out on loan offer queue management of this kind, and I found no official documentation either way. So I’m not telling you to go hunting for that setting in your router, because I don’t know whether it exists. Anyone who wants the complete fix, today, ends up putting an extra box between the provider’s modem and the home network, and that isn’t for everybody.

To understand what sits underneath

Response time and stability are what you measure with How good is my connection?, which now measures upload too, the number that actually counts in this article. One declared limit remains: it measures at rest rather than under load, so latency under load, which is the heart of the problem, does not show up there. If instead you suspect the Wi-Fi rather than the line, the checks in order are in Slow Wi-Fi: six checks to make before calling your provider.