VoIP Call Quality Issues: Diagnosing and Fixing the Top 10 Problems
Poor VoIP call quality is one of the most disruptive problems an IT team can face — and one of the hardest to diagnose. Unlike a server that’s clearly down or an application that won’t load, bad call quality is intermittent, subjective, and often reported by frustrated end users with descriptions like “it sounds like they’re underwater” or “the call keeps cutting out.”
The underlying causes span your local network, your internet connection, your UCaaS platform configuration, and your endpoints. Without a structured diagnostic approach, you can spend weeks chasing the wrong layer.
Understanding the Metrics That Matter
Before troubleshooting, you need to speak the language. VoIP quality is measured across four key network metrics:
Latency (delay): The time it takes for a voice packet to travel from sender to receiver. Acceptable: under 150ms one-way. Problematic: over 150ms (conversations start to feel stilted). Critical: over 300ms (calls become nearly unusable).
Jitter: The variation in latency between successive packets. Think of water flowing through a hose — jitter is the inconsistency in that flow. Acceptable: under 30ms. High jitter causes choppy, robotic audio even if average latency is fine.
Packet loss: The percentage of voice packets that never arrive. Even 1-2% packet loss is audible. Over 5% creates significant degradation. Packet loss sounds like words getting clipped or audio cutting out entirely.
MOS Score (Mean Opinion Score): A 1-5 composite quality score. 4.0+ is excellent. 3.5-4.0 is acceptable. Below 3.5 is noticeably degraded. Most UCaaS platforms surface MOS scores in their analytics dashboards.
Now, the 10 problems and their fixes.
Problem 1: Jitter (Choppy, Robotic Audio)
Symptoms: Audio sounds mechanical, words get clipped, conversations are hard to follow even when voice is technically audible.
Root cause: Network jitter is almost always a congestion problem. When your network path is saturated — whether at the LAN, WAN, or ISP level — packets queue and deliver inconsistently. Wi-Fi interference also causes significant jitter.
How to fix it:
-
Implement QoS (Quality of Service) on your core switches, routers, and SD-WAN devices. Voice traffic should be tagged DSCP EF (Expedited Forwarding) and prioritized in the queuing policy. This single fix resolves the majority of jitter complaints in environments where it hasn’t been configured.
-
Check Wi-Fi channel utilization. 2.4 GHz in dense office environments is a jitter factory. Move VoIP-heavy users to 5 GHz or 6 GHz (Wi-Fi 6/6E) and ensure your AP density is appropriate.
-
Review your ISP SLA. Many broadband providers don’t guarantee jitter. A Dedicated Internet Access (DIA) circuit with a proper SLA includes jitter targets. Learn more about DIA vs broadband.
Problem 2: High Latency (Talk-Over Conversations)
Symptoms: Callers constantly talk over each other. The classic “you go ahead” / “no, you go ahead” loop. Noticeable delay between speaking and being heard.
Root cause: Distance to the voice server, inefficient routing, or geographic mismatch between your UCaaS data center and your users.
How to fix it:
-
Check your UCaaS region configuration. Most platforms allow you to select regional data centers. If your users are in Dallas and your calls are routing through a London edge node, that’s your problem. Set the closest available region.
-
Evaluate your egress path. Traffic hairpinning through a central data center or corporate proxy adds significant latency. SD-WAN with local internet breakout routes voice traffic directly to the internet from each site — a major latency improvement for distributed organizations.
-
Run a traceroute to your UCaaS platform’s SIP servers during a complaint window. Look for asymmetric routing, unexpected hops, or a single hop with high latency — that’s your bottleneck.
Problem 3: Packet Loss (Audio Cutouts)
Symptoms: Words or entire phrases disappear. The call sounds like the other person keeps going on mute. Audio cuts in and out.
Root cause: Congested network links, faulty cables, misconfigured port settings, wireless interference, or ISP-level issues.
How to fix it:
-
Run a sustained ping test (500+ packets) to both your default gateway and the VoIP server during a complaint window. Any packet loss above 0.5% warrants investigation.
-
Check physical layer first. A flapping Ethernet port or a bad patch cable is an embarrassingly simple root cause that gets missed because engineers assume it’s something more complex. Replace suspect cables, check switch port error counters.
-
Audit switch port configuration. Speed/duplex mismatches between a phone and a switch port cause significant packet loss. Hard-set both sides to 100/Full or 1000/Full rather than relying on auto-negotiation.
-
Open a ticket with your ISP if loss occurs at the first external hop. Shared broadband during business hours can have meaningful congestion-driven packet loss. Bring data from your ping tests.
Problem 4: Echo
Symptoms: Users hear their own voice repeated back to them with a slight delay. Particularly distracting for the speaker; the listener often can’t hear it.
Root cause: Acoustic echo (physical sound from speakers being picked up by microphones) or electrical echo in the network path. The former is more common.
How to fix it:
-
Check headset and speakerphone configuration. Echo is most common when users have speaker volume high with an open microphone nearby. A decent headset with echo cancellation hardware eliminates this almost entirely. Cheap USB headsets or built-in laptop mics are frequent offenders.
-
Review conference room audio setups. Conference room speakerphones need to be placed correctly and may need echo cancellation tuning in the UCaaS platform. Avoid daisy-chaining cheap speakerphones.
-
Check for near-end echo in PSTN calls. When calling to or from traditional landlines, echo can be introduced at the PSTN gateway. If echo only occurs on external calls (not internal UCaaS-to-UCaaS), the issue is at the SIP trunk or PSTN gateway level — report it to your carrier.
Problem 5: One-Way Audio
Symptoms: One party can hear the other, but not vice versa. Or the call connects but one side is completely silent.
Root cause: Almost always a firewall or NAT traversal issue. Voice packets flow asymmetrically when firewall rules are inconsistent.
How to fix it:
-
Review your firewall rules for SIP/RTP traffic. UCaaS platforms publish the IP ranges and ports that need to be open. Ensure RTP (typically UDP 10000-20000) is allowed bidirectionally, not just outbound.
-
Disable SIP ALG on your firewall/router. SIP Application Layer Gateway is a feature meant to help VoIP but which frequently breaks it by modifying SIP headers incorrectly. It’s enabled by default on many routers. Turn it off.
-
Check for asymmetric NAT. If you’re behind a NAT device and your firewall doesn’t have consistent SIP handling, RTP streams can get separated. Your UCaaS vendor should have a firewall configuration guide — follow it exactly.
Problem 6: Calls Dropping Mid-Conversation
Symptoms: Active calls disconnect unexpectedly, often after 2-3 minutes or at other consistent intervals.
Root cause: SIP session timeouts, stateful firewall session expiration, or registration refresh failures.
How to fix it:
-
Check your firewall’s UDP session timeout. SIP uses UDP, and many firewalls have a short UDP session timeout (30-60 seconds). If it’s shorter than your SIP keep-alive interval, the firewall drops the session and the call dies. Set UDP timeout to at least 300 seconds.
-
Review SIP registration refresh intervals. Your SIP client or UCaaS client should send re-registration before the server’s timeout. If there’s a mismatch, calls drop. Check your UCaaS platform’s recommended registration interval.
-
Investigate internet connection stability. Brief connectivity blips that don’t affect web browsing (TCP reconnects quickly) will terminate active VoIP calls (UDP sessions are stateless — there’s no reconnect). Use a continuous ping monitor to catch intermittent drops.
Problem 7: Poor Quality on Wi-Fi Only
Symptoms: Call quality is fine on wired connections but degrades significantly for wireless users.
Root cause: Wi-Fi contention, insufficient AP density, interference, or incorrect QoS configuration at the wireless layer.
How to fix it:
-
Survey your Wi-Fi environment. Tools like NetSpot, Ekahau, or your wireless controller’s built-in analytics will show channel utilization, signal strength, and interference sources. Poor signal (-75 dBm or worse) combined with high channel utilization is a recipe for VoIP failure.
-
Enable WMM (Wi-Fi Multimedia) QoS on your access points. This extends QoS prioritization from the wired network into the wireless domain. Without it, voice packets get no preference over file downloads on the air.
-
Review AP density and placement. VoIP requires consistent, high-quality signal coverage — not just “connected.” If users are roaming or on the cell edge, quality suffers. Modern AP placement guidelines target -65 dBm or better in all occupied areas.
Problem 8: Calls Fine Internally, Bad with External PSTN
Symptoms: UCaaS-to-UCaaS calls are excellent. Calls to and from external phone numbers are poor quality.
Root cause: Issues at the SIP trunk, PSTN gateway, or carrier interconnect — not your local network.
How to fix it:
-
Gather call detail records (CDRs) from your UCaaS platform for affected calls. Note the call direction, originating number, and MOS score. If poor calls share a specific PSTN gateway or carrier route, the problem is upstream.
-
Test with multiple external destinations. If quality is bad calling one carrier’s network but fine calling another, the issue is likely at the PSTN interconnect. If it’s bad to all external numbers, suspect your SIP trunk.
-
Engage your UCaaS vendor’s support with data. Bring call IDs, timestamps, and MOS scores. Good UCaaS platforms can trace the RTP path and pinpoint where quality degrades.
Problem 9: Audio Degradation Under Load
Symptoms: Call quality is fine early in the day but deteriorates significantly during peak hours (9-11 AM, 1-3 PM).
Root cause: Internet bandwidth saturation or QoS not functioning at scale. You may have adequate bandwidth off-peak but not enough headroom during business hours.
How to fix it:
-
Monitor your WAN utilization during complaint windows. If your link is hitting 70%+ sustained utilization, you’re in congestion territory. VoIP needs not just raw bandwidth but headroom — QoS doesn’t work well when the pipe is completely full.
-
Calculate your VoIP bandwidth requirements. A G.711 codec call uses approximately 90 Kbps of bandwidth including headers. A G.729 call uses about 32 Kbps. If you have 50 concurrent calls on a 100 Mbps link that’s simultaneously handling video, cloud backups, and file syncs, you may be undersized.
-
Implement traffic shaping for non-voice applications. Limit large file transfers, cloud backup sync windows, and software update traffic to off-peak hours. This is a configuration change, not a bandwidth upgrade — and it’s often the faster fix.
Problem 10: Inconsistent Quality Across Locations
Symptoms: Calls from headquarters are fine. Calls from branch offices are consistently poor. Or vice versa.
Root cause: Each location has its own network path, ISP, firewall configuration, and QoS policy. Inconsistencies compound.
How to fix it:
-
Standardize your network stack across locations. If headquarters has proper QoS and the branch doesn’t, you’ll get branch complaints. Treat each site as a deployment project, not an afterthought.
-
Evaluate SD-WAN for multi-site deployments. SD-WAN appliances at each branch provide consistent QoS enforcement, intelligent path selection (automatically routing voice over the best available link), and centralized policy management. It’s the right long-term architecture for distributed organizations. See our multi-location network design guide.
-
Run the same diagnostic tests at each site and compare results. The site with the problem will show degraded latency, jitter, or packet loss on the WAN path. That points you to the root cause faster than chasing symptoms.
Systematic Diagnostic Approach
When you get a complaint, work through this order before jumping to conclusions:
- Reproduce it — get the user to tell you the call time, direction, and other party if possible
- Pull CDR data from your UCaaS platform — don’t rely on user descriptions alone
- Test the local network — wired vs wireless, QoS configuration, switch errors
- Test the WAN path — latency, jitter, packet loss to UCaaS servers
- Test the ISP — is the problem internal or external to your network?
- Engage your UCaaS vendor — with data, not just a complaint
Most call quality issues resolve at step 3 or 4.
When to Escalate to a Technology Advisor
If you’ve worked through this checklist and still can’t isolate the problem, or if you’re experiencing systemic quality issues across multiple sites or user populations, it may be time for a vendor-neutral assessment of your voice architecture.
At Catch Advisors, we work with businesses every day that have outgrown their original UCaaS or network setup — or were sold a solution that was never quite right for their environment. We can evaluate your current platform, network design, and carrier relationships, then recommend improvements without any vendor bias.
Schedule a free VoIP and UCaaS consultation — bring your call quality data, and we’ll help you figure out where the problem actually lives.
Related reading: