Diagnosing Call Quality for Remote Workers

A structured way for IT teams to find out why one employee's calls keep failing — what to measure, what the evidence rules out, and how to close tickets you cannot fix.

"Teams keeps dropping for me." It is one of the least tractable tickets in IT support, because the fault usually sits on a network you do not manage, cannot log into, and cannot instrument.

The usual sequence is predictable: the employee runs a speed test, reports 300 Mbps, and everyone concludes the connection is fine and the problem must be the software. It is rarely the software. The measurements that matter are not the one being taken.

This is a structured way to work through it, ordered so that each step eliminates a category rather than guessing.

Give the user one link

The connection test measures packet loss, jitter and latency in both directions and produces a shareable result link. Sending one URL beats talking someone through command-line tools.

Run the connection test →

The five-minute test to run before triaging

Send this to the employee before spending half an hour on the application. It produces evidence rather than adjectives.

1. Run the connection test over Wi-Fi.
2. Run it again over Ethernet.
3. Run it idle, with nothing else going on.
4. Run it again during a large upload.
5. Send back the result links.

Four results and two comparisons — wireless against wired, idle against loaded — narrow the problem to a category before anyone opens a console.

The three numbers that matter

Packet loss. Whether data is arriving at all.

Jitter. Whether it arrives at a steady rate.

Latency under load. Whether the connection holds up when someone else is using it.

Bandwidth matters up to a point, but once a connection has enough capacity for the call, it stops being the limiting factor. These three keep mattering.

Why the speed test misleads everyone

Real-time media has requirements that bear almost no relation to throughput.

Voice traffic needs relatively little bandwidth, and video needs more — how much more depends on resolution, participant count, layout, screen sharing and what the application decides to do under the conditions it finds. The useful generalisation is not a specific number: it is that on most modern broadband connections, raw capacity is rarely the first thing worth investigating when calls fail. What a call needs is that small packets arrive consistently and on time, and a speed test measures neither.

Throughput tests also generally run over transports that recover from packet loss, so retransmission repairs the damage before it reaches the reported number. A connection experiencing real packet loss can still return a high throughput figure, because the transport quietly resent what went missing — while a call, which cannot wait for that, gets the gap. The full explanation is here, and it is worth sending to anyone who insists their connection is fine because the speed test says so.

What to ask for instead: packet loss, jitter, and latency under load. Three numbers that explain nearly every call-quality complaint.

The thresholds that matter

For triage, these are the figures worth holding in mind. Treat them as guidance rather than hard limits — burstiness and codec behaviour both shift the boundaries.

That last row is the one most often missed, and it catches a large share of "it only happens sometimes" tickets. See bufferbloat.

A triage sequence that actually narrows things

Each step rules out a category. Run them in order and stop when something changes.

1. Wired versus wireless

Same machine, same destination, same test — only the access method changes.

This is one of the highest-yield tests in the process and it resolves a large proportion of tickets outright. Wi-Fi introduces loss and jitter even at full signal strength, and home wireless environments are frequently dreadful: a router in a cupboard, a dozen neighbouring networks on the same channel, a laptop three rooms away.

If Ethernet fixes it, the conversation becomes about their home setup rather than your infrastructure — and you can close the ticket with a concrete recommendation.

2. Under load

Same test, but while a large upload runs.

Latency climbing from 30 ms to 300 ms is a strong indication of queueing under load, typically bufferbloat in their home router — particularly when it drops back the moment the transfer stops. Common, fixable, and within their control. It also explains the reports that only occur at certain times — a cloud backup, a family member streaming, a console updating.

3. Time of day

Ask for the same test at three points across a couple of days.

Consistent degradation suggests a hard fault. Degradation confined to evenings can suggest congestion, either in their ISP's local segment or at an interconnect, though it is not the only explanation. That distinction determines whether the ISP will act — congestion is a capacity problem they can schedule, while an intermittent fault is something they need to find. Repeated evening-only degradation, documented across several days, is useful evidence for a congestion or throttling investigation.

4. The path

A hop-by-hop MTR from their connection identifies where loss begins. Persistent loss that starts at a hop and continues through every hop after it is the stronger evidence of a problem affecting the path at or before that point. Loss at a single intermediate hop that disappears at later hops often means that router is rate-limiting or deprioritising probe replies rather than dropping transit traffic — a very common false positive that sends people chasing faults that do not exist.

5. The direction

If the outbound path is clean and problems persist, check the return path. Routing is asymmetric, so a fault inbound to the user will not appear in any test they or their ISP runs outbound. This is a meaningful proportion of the cases where everyone's testing comes back clean and the problem is still real.

Corporate factors worth ruling out

Some causes are yours rather than theirs, and they are easy to overlook because they do not affect users in the office.

VPN concentrator load. If all traffic is backhauled through the corporate VPN, call media takes a long detour and competes with everything else traversing the concentrator. Split tunnelling for known conferencing endpoints is the standard remedy, and Microsoft and Zoom both publish endpoint lists for exactly this purpose.

Double NAT and CGNAT. Some ISPs place customers behind carrier-grade NAT, which complicates the peer-to-peer paths conferencing tools prefer and forces media through relay servers — adding latency and a shared bottleneck. Detecting it takes two numbers, not one: a web IP lookup reports the address our servers see, which behind CGNAT is the ISP's shared public address and looks entirely ordinary. The giveaway is on the router's WAN interface — if that shows something in 100.64.0.0/10 while the lookup shows a different, public address, the user is behind carrier NAT. Ask them to read both.

SASE and zero-trust gateways. Routing employee traffic through a cloud security stack adds hops and can add latency, particularly if the nearest point of presence is not actually near. The geographically closest gateway is not always the lowest-latency path either, since routing and policy determine where traffic actually exits the corporate network — an MTR with the agent on and off shows the real difference. It can also cause conferencing traffic to be classified oddly. Worth testing with the agent disabled, where policy allows.

TLS interception. If your security stack decrypts traffic, conferencing clients using certificate pinning may fail in ways that look like network problems. The diagnostic clue is selectivity: if only certain conferencing applications fail while general browsing is fine, interception or an application-specific security policy is worth testing before the network. The SSL proxy check confirms whether interception is active on their connection — see how detection works.

Endpoint contention. A laptop with the CPU pinned by endpoint protection scanning can produce audio artifacts that closely resemble network jitter. Check resource usage during a bad call before assuming the network.

Troubleshooting matrix

One table for the whole sequence, once you know what the tests returned.

Closing tickets you cannot fix

Some proportion of these are genuinely the employee's ISP, and that is where a documented handoff matters. An employee who tells their provider "my work calls are bad" gets told to reboot the router. One who arrives with measurements gets escalated.

Give them:

• Loss, jitter and latency figures from several tests across several days, with timestamps.
• The result links, which the ISP's own engineers can open and read.
• An MTR identifying the hop where loss begins.
• Confirmation that it was tested over Ethernet and, where practical, with the router or gateway bypassed, and reproduced on more than one device.

The guide to proving packet loss to an ISP is written for exactly this handoff and can be sent to the employee directly.

Set the expectation internally too. A ticket that has been correctly diagnosed as the employee's home ISP is resolved from your side, even though the symptom continues. Documenting that clearly prevents it reopening every fortnight.

Building a baseline before you need one

The most useful thing an IT team can do is collect measurements from remote staff before anyone complains.

A single test from each remote worker during onboarding, stored with the date, turns future tickets from an argument into a comparison. When someone reports degradation you can ask a precise question — has something changed, or has it always been like this? — and answer it with evidence rather than recollection.

It also surfaces the people who have been quietly struggling. Plenty of employees assume bad calls are normal and never raise a ticket at all, and a baseline sweep finds them.

Frequently asked questions

Why do Teams calls drop when the internet speed test is fine?

Because they measure different things. A speed test reports bulk throughput over a transport that repairs packet loss automatically. Real-time media has far less time to recover — by the moment a retransmitted packet arrives, the instant it was meant to fill has usually passed, so continuing with the next one is often the better option. Loss, jitter and latency under load all break calls while leaving throughput untouched.

How much packet loss is acceptable for video calls?

Under 0.5% is comfortable, 0.5–1% is marginal, and above 1% generates complaints. Bursty loss is considerably worse than the same percentage spread evenly, because codecs conceal isolated missing packets but cannot conceal a run of them.

How do I diagnose a remote worker's home network without access to it?

Have them run a browser-based test that reports loss, jitter and latency and produces a shareable link, then compare wired against wireless and idle against under-load. That sequence identifies the category of fault without needing any access to their equipment.

Should we use split tunnelling for Teams and Zoom?

Generally yes for media traffic. Backhauling real-time media through a VPN concentrator adds latency and creates a shared bottleneck. Both Microsoft and Zoom publish endpoint lists intended for split-tunnel configuration, and it is one of the more reliable improvements available to an IT team.

What is jitter and why does it matter more than average latency?

Jitter is variation in arrival timing between consecutive packets. Receivers buffer briefly to smooth it, but packets arriving after the application's playback deadline may be discarded or become unusable to the media application even though they reached the endpoint — appearing as loss in application statistics. A connection can show excellent average latency and still be unusable if the variation is high.

How do I tell whether the problem is the employee's ISP or their home equipment?

Test wired with nothing else running and, if possible, with the router bypassed. If loss survives all of that, it is beyond their equipment. An MTR then indicates where it begins. Anything that disappears on Ethernet or with other traffic stopped was inside the home.

Can our corporate VPN or SASE gateway cause call quality problems?

Yes. Backhauling media adds latency and concentrator contention, and cloud security stacks add hops. Testing with the agent disabled, where policy permits, isolates it quickly — and if that resolves it, split tunnelling for conferencing endpoints is usually the answer.