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 is almost always 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 →

Why the speed test misleads everyone

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

A Teams or Zoom call uses roughly 1–4 Mbps for video and well under 100 kbps for audio. Any modern connection has that capacity many times over. What a call needs is that small packets arrive consistently and on time — and a speed test measures neither.

It also measures over a reliable transport that retransmits lost packets automatically, so the loss that ruins a call is repaired before it reaches the reported number. A connection dropping 3% of packets can still report full line rate. 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

Have the user run the same test twice — once on Wi-Fi, once on Ethernet.

This is the single highest-yield question in the whole 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 means bufferbloat in their home router. Common, fixable, and entirely 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 suggests congestion, either in their ISP's local segment or at an interconnect. 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.

4. The path

A hop-by-hop MTR from their connection identifies where loss begins. Look for loss that starts at a hop and continues through every hop after it. Loss at one hop that clears afterwards is that router deprioritising its own replies — 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. A user whose public address is in 100.64.0.0/10 is behind CGNAT, which the IP lookup will show.

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. 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 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 will produce audio artifacts that look exactly like network jitter. Check resource usage during a bad call before assuming the network.

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 wired, with the router bypassed if possible, 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 reliable transport that repairs packet loss automatically. Calls need consistent, on-time delivery of small packets and cannot retransmit. 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 beyond that window are discarded — appearing as loss even though the network delivered them. 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.