How do I know if call quality problems are my network or the provider?

Run the provider's own quality test (most offer one) from the same network at problem times. If packet loss/jitter shows clean on their test but calls still suffer, it's your LAN or ISP. If the test itself shows loss on their route, escalate to the provider with the test IDs.

What are acceptable VoIP network metrics?

Latency under 150ms, jitter under 30ms, packet loss under 1%, in both directions. Breach any of those and calls degrade — the fix priority is loss, then jitter, then latency.

VoIP Call Quality Troubleshooting

Written by Ivan Elias, Founder & Principal Advisor · Published September 15, 2026

No fee · no obligation

Call quality complaints are almost never “the VoIP.” They’re a specific network condition with a specific fix. This is the sequence we run, in order of how often each step solves the problem.

Step 0: Capture the facts

Which users, which times of day, which direction (inbound/outbound), what does it sound like (choppy = packet loss, robotic/underwater = jitter, delay echoes = latency)? Pattern recognition halves the troubleshooting time.

Step 1: The local network (fixes ~60% of cases)

WiFi calls? Move frequent talkers to wired. WiFi is the #1 call-quality killer in offices — roaming between APs and congested channels destroy RTP streams. If WiFi calling is unavoidable: dedicated SSID, QoS enabled, 5GHz-only, full-strength coverage in call-heavy areas.
Switch infrastructure: daisy-chained desk switches, 10-year-old unmanaged gear, or half-duplex negotiation all corrupt voice. Voice belongs on managed switches with QoS.
Cables: a damaged Cat5 run presents as mysterious one-way audio. Replace suspect cables; verify negotiation at 1Gbps full duplex.

Step 2: Bandwidth and QoS (fixes ~20%)

Run a speed test during problem times. If upload saturates (cloud backups, video calls), voice suffers first.
Enable QoS on the firewall/edge: prioritize RTP/SIP traffic (DSCP EF 46), cap or shape the backup and streaming categories. This single change resolves most “afternoon choppy calls” reports.
For offices that can’t police usage: that’s what SD-WAN with QoS or Bigleaf does automatically.

Step 3: The internet circuit (fixes ~10%)

Latency/loss on your ISP’s route at peak times: test with the provider, ask for a different route, or move to a better circuit. DIA circuits with SLAs make this the provider’s problem, not yours.
Bufferbloat (latency under load): queue management on the edge (SQM/CAKE) or bonded circuits fix it.

Step 4: The provider (fixes ~10%)

Check their status page first; then run their diagnostic test at problem times and open a ticket with the test IDs and call samples. Good providers (see our rankings) respond with route analysis; bad ones blame your network forever. That difference is why our rankings weight support.
One-way audio across NAT: SIP ALG on your firewall is guilty until proven innocent. Disable it. (This one line fixes a shocking number of “random” call problems.)

Step 5: Codec and configuration

Force a modern codec (Opus/G.722 for HD where supported; G.711 on constrained branches). Transcoding hops degrade quality.
Check handset firmware — vendors ship quality fixes constantly.

When to stop debugging and redesign

If you’ve done steps 1–4 and complaints persist, the architecture is the problem: mixed-quality ISP circuits without QoS, WiFi-only floor plans, or an undersized firewall. That’s a redundancy and SD-WAN conversation — and it’s cheaper than it sounds.