Why is Microsoft Teams call quality poor?
Broken audio, frozen video and dropped calls can begin on the Windows endpoint, local Wi-Fi, VPN, internet path or Microsoft service. Test each layer before blaming bandwidth.
Start with the affected call and participant.
Record the meeting time, affected participant, device, location and symptom. A company-wide incident, one-site pattern and one-user problem require different investigations.
Scope
Identify whether audio, video or screen sharing failed, and whether one participant, one site or the whole meeting was affected.
Measure
Compare round-trip time, jitter and packet loss with CPU, memory and network activity during the reported period.
Compare
Test another device, wired connection, site and VPN path to identify which variable follows the problem.
What the IT team should check.
Capture the affected user, device, site, application and exact time before changing configuration. The comparison is often more useful than a single reading.
Media-network quality
Review latency, jitter and packet loss rather than relying only on download speed.
Endpoint pressure
High CPU, memory pressure, driver trouble or a busy disk can degrade calls even on a healthy connection.
Wi-Fi, VPN and route
Compare wired and wireless access, direct and VPN paths, and another site where policy permits.
Affected population
One participant suggests a local path; a site-wide pattern points toward shared infrastructure.
The exact timeline
Use Teams telemetry and retained endpoint measurements from the same call window.
Escalation evidence
Keep meeting, participant, device, site and network evidence together for the next support tier.
Match the Teams symptom to the first comparison.
A symptom is a starting point, not a diagnosis. Use the call timestamp and participant details to compare Microsoft telemetry with endpoint and network evidence from the same window.
| Observed symptom | First branch to test | Useful comparison |
|---|---|---|
| Choppy or robotic audio | Jitter or packet loss on the participant path | Compare gateway and external-path stability, then a wired peer at the same site. |
| Long conversational delay | Round-trip latency or an indirect VPN route | Compare the same participant with and without the approved tunnel path, or against another site. |
| Frozen video while audio continues | Upload pressure, intermittent loss or endpoint resource pressure | Compare outbound traffic and network quality with CPU, memory and the Teams process. |
| The whole Teams client is sluggish | Windows endpoint pressure | Compare CPU, memory and disk activity with a similar healthy device before blaming the call path. |
| Several users at one office are affected | Shared Wi-Fi, gateway, WAN or VPN dependency | Compare wired and wireless users at that office with the same task at another site. |
Turn a complaint into evidence.
Tonzio keeps Windows endpoint, application, network and support context together so an IT team can compare an affected device with healthy peers and retain the timeline for intermittent cases. It supports the investigation; it does not replace vendor diagnostics or responsible change control.
- Record the exact symptom and time
- Compare the endpoint and network independently
- Use a healthy peer or site as a control
- Attach the evidence to the operational follow-up
Common questions.
Does a fast speed test mean Teams should work well?
No. A throughput test can look healthy while delay variation, packet loss, Wi-Fi instability or endpoint pressure still harms real-time media.
What measurements matter most?
Round-trip time, jitter and packet loss are key network measurements; also check endpoint CPU, memory, audio devices and whether the participant used Wi-Fi or a VPN.
Should we disable the VPN?
Only as an approved comparison test. Do not bypass security controls without authorization; compare direct and tunnelled paths within policy.