Why Do Video Calls Freeze?

Why a fast connection can still freeze

A typical video call needs surprisingly little bandwidth: roughly 1 to 4 Mbit/s in each direction for a good one-to-one call, more for group calls or screen sharing, but nowhere near the tens or hundreds of megabits a modern plan advertises. If speed alone determined call quality, freezing would be rare on any connection sold today. It isn't, because a call is far more sensitive to timing than to volume.

Video and audio are sent as a continuous stream of small packets, arriving many times a second. The call software expects them to arrive at a steady pace and within a tight delay budget. When packets are delayed, arrive out of order, or bunch up and then go quiet, the receiving app runs out of audio or video to play and has nothing to do but freeze the picture or drop the sound until the stream catches up.

Real-time stream

A continuous flow of small data packets, like a call's audio and video, where a packet that arrives late is nearly as useless as one that never arrives at all — unlike a file download, where a late chunk simply takes a little longer.

This is the core reason a speed test and a video call can disagree. A speed test measures how much data a link can move over several seconds. A call cares about what happens millisecond to millisecond, and a link can move a lot of data over time while still mishandling individual packets badly enough to make a call stutter.

Why upload capacity deserves attention first

Most home connections are asymmetric: downstream capacity, used for receiving video, web pages and downloads, is usually many times larger than upstream capacity, used for sending your own outgoing video and audio. That upstream link is shared by everything leaving your home at once — cloud backups, photo syncing, someone else's upload, and your own outgoing call stream all compete for the same narrow lane.

When something else fills that lane, your outgoing call packets queue up behind it. The other participants on the call see your video freeze or your audio break up, even though your download speed and their download speed look fine. This is why the person freezing on a call is not always the one experiencing the freeze themselves; each direction is judged by the person receiving it.

Limited upload capacity is one of the more common and more fixable contributors to call freezing, precisely because it responds well to a simple test: pause anything else that uploads and see whether the call improves.

Jitter and latency spikes: the direct causes of a freeze

Latency is the time a packet takes to make a round trip. Jitter is the variation in that time from one packet to the next. A connection with 30 ms latency that stays close to 30 ms is easy for a call app to work with, because it can hold a small buffer and smooth out the flow. A connection that swings between 20 ms and 200 ms from one moment to the next is much harder to compensate for, and it is jitter, more than the average delay, that produces visible stutter.

Latency spike

A short-lived jump in round-trip response time, lasting anywhere from under a second to several seconds, after which the connection returns to its normal delay. A spike coinciding with a call is often what a freeze actually looks like from the inside.

Upload-loaded latency — the delay measured specifically while the upload link is busy — is particularly relevant to calls, because your own outgoing stream is, by definition, always loading that link while you are on a call. If upload-loaded latency is high, every call you make is happening under the exact condition most likely to cause stutter, whether or not anything else is running at that moment.

It's worth noting what Norynt's measurements do and do not tell you here. Norynt measures download and upload speed, idle latency, jitter, upload- and download-loaded latency, and how steady the speed stays. It does not measure packet loss directly. When a timing probe during a test fails to return a usable result, Norynt treats that as a sign the measurement itself was unreliable at that instant — for example because the browser tab lost focus or a probe was rate-limited — not as evidence that a packet was lost in the network. The two are different things, and conflating them would overstate what a browser-based test can actually observe.

Competing traffic, Wi-Fi variation and VPNs

Backups are one of the most common hidden causes of call freezing, because they are easy to forget about. A phone quietly backing up photos, a laptop syncing a folder, or a games console downloading an update in the background can each consume enough upload or download capacity to push a call's small, steady stream into an overloaded queue, without any obvious sign on the device doing the backing up.

Wi-Fi introduces its own variability. Unlike a cable, a wireless link's usable capacity changes from second to second depending on distance from the router, walls, interference from neighbouring networks, and even other devices on the same 2.4 GHz or 5 GHz band. A laptop that shows a full signal bar can still experience brief drops in throughput as it competes for airtime, and those brief drops line up neatly with the timescale of a call freeze.

VPNs add a further layer. Encrypting and re-routing every packet takes processing time and typically adds a small, fairly constant amount of overhead to both latency and available throughput. On a connection that already has little headroom, that overhead can be enough to tip upload-loaded latency or jitter into a range that visibly affects calls, particularly if the VPN routes traffic through a distant server.

When the app or the device is the real limit

Not every freeze is a network problem. Call software runs on ordinary hardware, and an older laptop, an overloaded CPU, or a browser tab fighting for resources with a dozen others can fail to encode or decode video smoothly regardless of how good the connection is. This tends to show up as a freeze that happens consistently on one device even when other devices on the same network handle the same call without trouble.

Call applications also adapt their own video quality automatically in response to conditions they detect, which means the same underlying network hiccup can look different depending on which app you're using. Two participants on the same call, one using a laptop app and one using a phone app, can experience noticeably different amounts of freezing from an identical shared network problem, because each app reacts to congestion differently.

This is one reason a methodical process matters more than a hunch: ruling out the device and the app early prevents time being spent chasing a network explanation for what is, in that instance, a local software or hardware limitation.

A sensible order for working through the possibilities

Because several unrelated conditions produce the same symptom, the most efficient approach is to test the cheapest and most reversible explanations first, changing one thing at a time and repeating the call rather than judging from a single instance.

1. Pause background transfers on every device on the network — backups, syncing, updates and other calls — then repeat the call.
2. Check whether the freeze happens on Wi-Fi specifically by testing the same call over a wired Ethernet connection if that's available.
3. If freezing persists, move closer to the router or reduce the number of walls between the device and the access point.
4. Turn off any VPN and retest, since VPN overhead is easy to rule in or out.
5. Compare behaviour across two different devices and, if possible, two different call applications, to separate a network cause from a device or app cause.
6. Once environmental causes are ruled out, review your speed, jitter and upload-loaded latency results with the time of the freeze in mind.

A single test run, or a single freezing call, rarely proves anything on its own. The value is in the comparison: does the problem change when one condition changes and everything else stays the same?