Microsoft Teams Call Quality: Prove Whether It's Actually Your Network

Teams tells you the call quality is poor. It might even flash the little banner: "Poor network quality detected." What it will not tell you is where the problem is — your laptop, your Wi-Fi, your router, your VPN, your ISP, the office firewall, or Microsoft's own infrastructure. The blame lands on "your network" as if that were a single thing, and you are left rebooting the router because it is the only network object you can physically touch.

This post is about turning that vague accusation into a specific, testable claim. Teams call quality issues are almost always locatable if you know which numbers to read and how to isolate the variables. By the end you should be able to say "the problem is jitter on the Wi-Fi leg" or "the problem is the VPN concentrator" or, occasionally, "the problem is Microsoft, and here is the evidence" — instead of "Teams is bad today."

Your internet is fast. That was never the question.

Start with the most common dead end. A user complains about choppy Teams audio, someone runs a speed test, it reports 500 Mbps down, and the conclusion is that the network is fine. The conclusion does not follow, and understanding why saves hours of misdirected troubleshooting.

A Teams audio call consumes roughly 60-100 kbps in each direction. That is about 0.02% of a 500 Mbps connection. Bandwidth is not scarce and has not been scarce for voice since the DSL era. What voice needs is delivery discipline: a packet every 20 milliseconds, arriving in order, on schedule, every single time, for the entire call. A connection can move gigabytes effortlessly while failing this test constantly, because throughput and timing are different properties of a network. We cover the mechanics in bandwidth doesn't mean quality, but the operational takeaway is simple: a speed test result is not evidence about call quality in either direction. Stop running them for this problem.

The three numbers that actually predict Teams call quality are latency (how long packets take to cross the path), jitter (how much that time varies packet to packet), and packet loss (how many never arrive). Every symptom users report — choppy audio, robotic voices, audio cutting out, talking over each other — maps to one of these three. If you want the full symptom-to-metric mapping, see our guide to latency, jitter, and packet loss.

Reading Call Health like it matters

Teams ships a live diagnostic that most users never open. During any call, click the More (three dots) menu and select Call health. You get a real-time panel showing, for the leg between your client and Microsoft's media edge: round-trip time, jitter, packet loss, and the codec bitrate in use, broken out for audio, video, and screen share.

Here is how to read it. Microsoft's published performance targets for the client-to-edge leg are:

• Packet loss under 1% averaged over the call. Below 0.5% you will rarely hear anything. Between 1% and 3% you get audible dropouts and the smeared, underwater artifacts of a codec concealing missing frames. Above 3% sustained, the call is genuinely bad and everyone knows it.
• Jitter under 30 ms. The jitter buffer in the Teams client can absorb variation up to a point by delaying playback; past roughly 30 ms it must choose between adding perceptible delay and discarding late packets, and either choice degrades the call. Jitter is the usual culprit behind choppy or robotic audio — more often than loss, in our experience.
• Round-trip time under 100 ms is Microsoft's target; treat 200 ms as the trouble line. Between 100 and 200 ms, conversation still flows. Above 200 ms RTT, the acoustic gap between one person finishing and the other starting gets long enough that humans start talking over each other, then both stop, then both start again. The audio itself can be pristine and the call still feels broken.

Two practical notes. First, watch Call health while the problem is happening. These numbers move — jitter that averages 12 ms can spike to 80 ms for the ten seconds your audio fell apart, and a glance afterward will show you nothing. Second, remember what leg you are measuring: Call health shows your client to Microsoft's edge. The other participant has their own leg with its own numbers. If your panel is clean and the caller still sounds terrible, the problem is on their side or beyond the edge — which is diagnostic gold, because you have just cut the search space in half.

Admins have a wider lens: the Call Quality Dashboard and per-user call analytics in the Teams admin center retain these metrics per call, per leg, including the far end. If one user reports problems, pull their last ten calls and look for the pattern before touching any hardware.

Why Teams audio cuts out: isolating the fault domain

"Audio cutting out" is a symptom with at least six possible homes: the device, the Wi-Fi link, the LAN, the ISP path, the far-end participant, or Microsoft. The way to find which one is not intuition — it is controlled A/B comparison, changing exactly one variable at a time. This is the same discipline we describe in diagnosing VoIP problems, applied to the Teams stack.

Wired vs. Wi-Fi

The single highest-yield test. Plug the machine into Ethernet, reproduce the call, watch Call health. If jitter drops from 45 ms to 4 ms and the dropouts vanish, you have found the fault domain: the wireless link. Wi-Fi is the number one source of jitter in home and small-office Teams calls — retransmissions, channel contention, a microwave oven, a neighbor's access point, or simple distance from the AP all show up as timing chaos that voice cannot tolerate. The details, and what to do about them, are in wired vs. Wi-Fi for VoIP. If the problem persists on Ethernet, Wi-Fi is exonerated and you move one hop out.

VPN on vs. VPN off

Corporate VPNs are the second great destroyer of Teams calls. A full-tunnel VPN forces your media through the VPN concentrator — often in a data center hundreds of miles away — before it ever reaches Microsoft, adding latency, adding jitter, and frequently forcing the media into TCP encapsulation, which is poison for real-time audio. Run the same call with the VPN connected and disconnected and compare Call health. If RTT falls from 180 ms to 40 ms with the tunnel down, the fix is split tunneling: Microsoft explicitly recommends excluding Teams media traffic (UDP ports 3478-3481 toward Microsoft's ranges) from the VPN. This is a configuration change your IT team can make in an afternoon, and it is one of the most common root causes for remote workers — a topic we cover more broadly in VoIP quality for remote teams.

One user vs. the whole office

Scope tells you altitude. If one person on the office network has bad calls and twenty others are fine, the problem lives close to that person: their machine, their headset, their cable, their switch port, their Wi-Fi position. (Do not skip the device layer — a USB headset with a failing cable or a laptop pinned at 100% CPU produces symptoms indistinguishable from network loss.) If everyone's calls degrade, the problem lives in shared infrastructure: the firewall, the internet uplink, the ISP. Congested uplinks are a classic office pattern — voice is fine until someone starts a large upload, the uplink queue fills, and every Teams call in the building develops 100 ms of jitter simultaneously. That signature — correlated degradation across users — points at the shared edge, and the fix is QoS or more uplink, not new headsets.

Morning vs. afternoon

Time-of-day correlation is a fault-domain signal people overlook. Calls that are clean at 8 a.m. and choppy from 2 p.m. to 5 p.m. indicate congestion somewhere on the path that follows load: the office uplink during business hours, or residential ISP contention in the evening for remote workers. Run the same test call at both times and keep the Call health numbers. A path that degrades on schedule is a capacity problem, not a configuration problem, and the schedule tells you whose capacity.

Worked through in order — wired vs. wireless, VPN on vs. off, one user vs. many, quiet hours vs. busy hours — these four comparisons locate the overwhelming majority of Teams call quality issues to a specific fault domain in under an hour, without opening a single support ticket.

When it actually is Microsoft

It happens. Microsoft runs one of the largest real-time media networks on earth, and it still has incidents — regional media relay degradation, transport outages, bad client builds. The base rate is low; the overwhelming majority of poor calls trace to the first-hop network. But "it's never Microsoft" is as wrong as "it's always Microsoft," so here is how to tell.

The signature of a Microsoft-side problem is correlated failure across uncorrelated networks. If your home-office user on Comcast, your headquarters on fiber, and your contractor on a different continent all report degraded Teams calls in the same window, no shared local cause can explain it. Confirm with three checks:

1. Service health. Check the Microsoft 365 service health dashboard (admin center, or the @MSFT365Status feed) for a Teams advisory. Incidents frequently show up there within the hour, though not always immediately.
2. Your own leg's numbers. Open Call health during a bad call. If your RTT, jitter, and loss to Microsoft's edge are all comfortably inside the thresholds — sub-50 ms RTT, sub-15 ms jitter, near-zero loss — while the call still sounds broken, the degradation is happening beyond the edge, inside infrastructure you cannot see and do not control.
3. An independent path measurement. Run a VoIP quality test from the affected machine at the moment of the problem. If an independent real-time media path from the same machine over the same network measures clean, you have two witnesses agreeing that your network is delivering packets on time. The variable that remains is the service.

When all three line up, stop troubleshooting your network. Document the timestamps and the clean measurements, file the ticket or wait out the incident, and — importantly — show the evidence to the users who are convinced it is the office Wi-Fi again.

Prove it with numbers, not vibes

The deeper problem with troubleshooting Teams by feel is that Teams is both the patient and the only witness. Its Call health panel is genuinely useful, but it only reports during a Teams call, only for the Teams path, and only while you remember to look. What you want is an independent measurement of the same network path, taken outside Teams entirely, that you can run on demand and compare over time.

That is what our free VoIP quality test is for. It runs in the browser — no install, no account — and sends real encoded audio over an actual WebRTC media path for 60 seconds, measuring jitter, packet loss, latency, and a MOS score for the path your calls actually traverse. Run it wired, then on Wi-Fi. Run it with the VPN up, then down. Run it at 9 a.m., then at 3 p.m. Each result is a shareable report you can hand to IT, your ISP, or your own skeptical memory.

If the test comes back with 8 ms jitter, 0% loss, and a MOS of 4.3 while Teams is complaining about your network, you have proof the accusation is false — escalate accordingly. If it comes back with 60 ms jitter on Wi-Fi and 5 ms on Ethernet, you have your answer without touching a Teams setting. Either way, you have replaced "poor network quality detected" with a number, a location, and a next step. That is the entire game.