Handling the "My Phones Sound Bad" Call

The MSP's Guide to VoIP: Part 12 of 20

Your phone rings. The client says "the phones sound terrible." Maybe they say it more colorfully than that. What they are telling you is that something about their voice experience has degraded to the point where they stopped tolerating it and decided to call you.

You have heard this call before if you have been running voice for any length of time. And the temptation is to jump straight into troubleshooting mode: start pinging things, pull up the PBX, check the router. But the MSPs that resolve these calls quickly and confidently have a system. They triage first, investigate second, and communicate third. This post walks through that system.

We have a whole troubleshooting series on this site that walks through voice quality symptoms from the end user's perspective. That series is deliberately written for someone with limited tools and limited access, like a business owner or office manager trying to figure out why their phones sound bad. You are not that person. You have packet captures. You have PBX logs. You have CDR records. You have network monitoring data. You have the ability to make configuration changes and test the results in real time. The approach here is different because your toolkit is different.

That said, the symptom-by-symptom posts are a useful companion reference. When a client describes a specific symptom, the corresponding post in that series gives you the end-user perspective on what they are experiencing and the common causes. Cross-reference as needed.

Triage: asking the right questions first

Before you touch a single tool, get answers to four questions. They take two minutes and save thirty.

One phone or all phones?

This is the single most important question because it immediately determines where to look. If one phone sounds bad and everyone else is fine, the problem is almost certainly at the endpoint or the local connection to that endpoint: a bad cable, a WiFi connection, a failing phone, a misconfigured codec. You do not need to investigate the WAN link, the trunking, or the provider.

If all phones sound bad, or a significant subset, the problem is further up the chain. The local network, the internet connection, the trunking, or the provider's infrastructure are all in scope.

If the answer is "a few phones but not all," ask which ones. Phones in the same physical area might share a switch, a cable run, or a WiFi access point. Phones in the same department might share a call path or a trunk group. Patterns in which phones are affected narrow the investigation before it begins.

Internal calls, external calls, or both?

This question separates the voice platform from the network path. If internal calls between extensions sound fine but external calls sound bad, the local network and phone hardware are probably clean. The problem is in the path from the PBX to the PSTN: trunking, the internet connection, or the provider.

If internal calls also sound bad, the problem is local. Media for internal calls on most platforms stays on the local network (or at least within the PBX), so it never touches the internet or the trunking provider. Bad internal calls point to local network issues, PBX resource problems, or endpoint issues.

If only internal calls are bad but external calls are fine, that is unusual and often points to a PBX configuration issue: codec mismatch between internal extensions, transcoding under load, or a media handling problem on the PBX itself.

Constant or intermittent?

A problem that is always present is easier to diagnose because you can reproduce it on demand. Run a VoIP quality test right now, capture the traffic, and you will see the issue in the data.

An intermittent problem requires a different approach. You need to know when it happens. Ask the client for specific times, specific calls, specific phone numbers if possible. "It was bad yesterday afternoon" is useful. "It's been bad for a while" is not. Push for specifics: dates, times, which extensions, which external numbers. You will need this to pull the right CDRs and correlate with network monitoring data.

If the problem follows a time-of-day pattern (fine in the morning, bad after lunch), that is a strong indicator of bandwidth contention. See the post on afternoon call quality degradation for the common causes. If it correlates with a specific activity (bad during the weekly all-hands video call, bad when the accounting team runs month-end reports to the cloud), that tells you exactly what is competing for bandwidth.

When did it start?

"It has always been like this" and "it started last Tuesday" are two very different investigations. If it started at a specific time, you need to know what changed at that time. New equipment installed? ISP maintenance? Software update on the PBX? New employee onboarded with bandwidth-hungry applications? A firmware update pushed to the phones?

If the client says it has always been bad, that might be true (which points to a systemic issue like insufficient bandwidth or missing QoS), or it might mean they only recently decided to complain about a gradually worsening problem. Check your monitoring data for the quality trend. If you have been tracking MOS scores, you can see exactly when quality started to decline, even if the client cannot pinpoint it.

Investigation: using your tools

With the triage answers in hand, you know where to look. Now you look.

Pull the CDRs

Start with the specific calls the client complained about. If they gave you timestamps and extensions, pull those CDRs. Look at the call duration, the completion status, and most importantly, the quality metrics if your platform records them per-call.

Many platforms attach RTP quality statistics to each CDR: MOS, jitter, packet loss, codec used. If the CDR shows a MOS of 3.2 with 4% packet loss on the calls the client flagged, you have confirmed the quality problem and you know the proximate cause is packet loss. You can use the MOS Explorer to understand exactly how those loss and jitter numbers translate to the MOS the user experienced. The question becomes: where in the path is the loss occurring?

Also pull CDRs for the same time period from other extensions. If the flagged extension shows poor quality but other extensions at the same time show clean metrics, the problem is localized. If all extensions show degradation at the same time, the problem is shared infrastructure.

Check your network monitoring

If you set up monitoring as described in the previous post, you have bandwidth utilization, latency, and interface statistics for the client's network. Pull the data for the time window when the quality was bad.

What you are looking for:

Bandwidth saturation. Was the upload link at or near capacity during the problem period? If upload utilization was at 90% when the calls sounded bad and at 40% when they sounded fine, you have your answer. The fix is either better QoS configuration, bandwidth management to throttle non-voice traffic, or a circuit upgrade.

Latency spikes. Did latency to the VoIP provider's servers spike during the problem period? Compare to your baseline. If normal latency is 25ms and it was 150ms during the problem, something in the path changed. Check if the ISP had a maintenance event or a routing change.

Interface errors. Are the switch ports or router interfaces showing increasing error counters? CRC errors, input errors, and output drops all indicate problems. CRC errors on a switch port often mean a bad cable. Output drops on the router's WAN interface mean the outbound queue is overflowing, which is a QoS or bandwidth issue.

Run a packet capture

When CDRs and monitoring narrow the problem but do not definitively identify the root cause, packet captures tell the rest of the story. A capture on the relevant network segment shows you exactly what is happening at the packet level.

For voice quality issues, you want to capture the RTP stream. Most packet analysis tools (Wireshark being the standard) can decode RTP streams, display per-packet timing, calculate jitter, identify lost sequence numbers, and even play back the captured audio so you can hear the degradation yourself. If you have a pcap file from the capture, you can also run it through a PCAP Analyzer to extract the voice quality metrics without manually navigating Wireshark's RTP analysis dialogs.

Where you capture matters:

At the phone. Capture at the switch port mirroring the phone's traffic. This shows you what the phone is sending and receiving. If the RTP stream leaving the phone is clean (consistent packet timing, no gaps) but the stream arriving at the phone has gaps or irregular timing, the problem is in the network between the phone and whatever is sending the media.

At the router. Capture on the LAN side of the router to see traffic after it has crossed the local network but before it hits the WAN. Compare this to a capture at the phone to isolate whether the local network is introducing degradation.

At the PBX (if on-premises). For self-hosted PBX systems, capture at the PBX to see the media streams it is handling. This tells you whether the PBX is receiving clean audio from the trunk provider and whether it is sending clean audio to the endpoints.

Comparing captures at multiple points in the path is the most definitive way to identify where degradation is being introduced. If the stream is clean at point A and degraded at point B, the problem is between A and B.

Check the PBX

For self-hosted or on-premises PBX systems, check the platform's health during the problem period. High CPU utilization on the PBX can cause audio processing issues, especially if the system is doing transcoding (converting between codecs). A PBX that is transcoding 20 concurrent calls on hardware rated for 15 will produce exactly the kind of intermittent quality problems that are hard to pin down.

Check registration status for the affected phones. A phone that is intermittently losing its registration and re-registering will have brief periods where calls fail or audio cuts out. Registration issues point to network connectivity problems between the phone and the PBX, or to issues with the PBX's registration handling under load.

For hosted platforms, you have less visibility into the platform's health, but most providers offer a status page and incident history. Check whether the provider reported any issues during the time window in question. If they did not, that does not mean the problem was not on their end. It means they did not detect or acknowledge it. Provider-side investigation is covered in post 14.

Check SIP signaling

If the quality problem involves calls failing to connect, dropping unexpectedly, or exhibiting one-way audio, the issue may be in the SIP signaling rather than (or in addition to) the RTP media. Pull the SIP traces for the affected calls.

SIP traces show the entire call setup negotiation: INVITE, SDP offer/answer, codec selection, media port negotiation, and session timers. Common signaling-related quality issues include:

• Codec mismatch causing unexpected transcoding
• SDP negotiation selecting a low-quality codec when a better option was available
• NAT traversal problems causing media to flow through an indirect path
• Session timer expiration causing calls to drop after a set time

Reading SIP traces is a skill that takes practice, but it is one of the most valuable diagnostic capabilities your team can develop. The reading a SIP trace post covers the mechanics.

The most common root causes

After years of troubleshooting voice quality for MSP clients, certain root causes come up far more often than others. In rough order of frequency:

Bandwidth saturation without QoS. The client's internet connection is getting fully utilized during business hours, and voice traffic is competing with everything else for bandwidth. This is the single most common cause of intermittent voice quality problems in small business environments. The fix is proper QoS configuration on the router to prioritize voice traffic, combined with bandwidth management policies for non-critical traffic. In some cases, the connection itself is undersized and needs upgrading.

WiFi. Phones or softphones on wireless connections experience jitter and loss from the inherent variability of the wireless medium. This was covered extensively in the wired vs WiFi post. The fix is straightforward: wire the phones. If that is not possible, optimize the wireless environment for voice.

Bad cables or switch ports. A single bad Ethernet cable or a failing switch port introduces packet errors that affect the connected phone. These are easy to miss because the phone might work fine for data (web browsing is tolerant of occasional retransmissions) while voice quality suffers. The fix is replacing the cable or moving to a different switch port.

ISP issues. The internet connection itself is experiencing latency spikes, jitter, or packet loss. This can be caused by congestion on a shared connection (especially cable), a degrading last-mile connection, or routing changes in the provider's backbone. This is harder to fix because you don't control the infrastructure, but having data showing the problem is on the ISP side gives you the evidence needed to escalate. A client on a DIA circuit with an SLA has contractual leverage here.

PBX resource exhaustion. The on-premises PBX is running out of CPU, memory, or concurrent call capacity. This typically manifests as intermittent quality problems that correlate with call volume peaks. The fix is either optimizing the PBX configuration (reducing unnecessary transcoding, disabling unused features) or upgrading the platform.

Provider-side issues. The VoIP provider's infrastructure is the source of the degradation. This is less common than local issues but does happen, especially with lower-cost providers that oversubscribe their infrastructure. Diagnosing and resolving this requires working with the provider, which is the subject of post 14.

Communicating findings to the client

Finding the root cause is half the job. The other half is explaining it to the client in terms that are accurate, understandable, and actionable.

Clients do not care about MOS scores, jitter buffers, or DSCP markings. They care about why their phones sound bad and what you are going to do about it. Translate your technical findings into business language.

Instead of: "Your RTP streams are showing 3% packet loss due to bandwidth saturation on the WAN uplink during peak hours, and your router is not configured with QoS to prioritize EF-marked traffic."

Say: "Your internet connection is getting overloaded during your busiest hours, and right now the phones are competing with everything else for bandwidth. We need to configure your router to give phone traffic priority so it gets through even when the connection is busy. That should resolve the quality issues without changing your internet plan."

Be specific about what you found, what you are going to do, and what the expected outcome is. If the fix requires spending money (a circuit upgrade, new hardware), present the cost alongside the quality data. "Your current connection is running at 90% capacity during business hours. We can reconfigure the router to prioritize voice, which will help, but as your team grows you will need more bandwidth. Here is what an upgrade would cost."

Avoid blame language. "Your internet is too slow" makes the client feel like they bought the wrong thing. "Your connection was sized correctly when we set it up, and your team's usage has grown to the point where we need to plan the next step" positions you as a proactive partner managing their growth.

Document your findings and the resolution. You need this for your own records, but it also feeds into the quality reporting discussed in the monitoring post. If the same client has the same problem again in six months, you want to be able to pull up the previous investigation and see what was found and what was done.

Building the muscle

Voice troubleshooting is a skill that improves with repetition. Every quality investigation your team handles makes the next one faster. A few things accelerate this process:

Post-incident reviews. After resolving a quality issue, spend five minutes documenting what the symptom was, what the root cause was, and how it was identified. Build a knowledge base that your team can reference. Over time, this becomes a diagnostic shortcut: "intermittent choppy audio on external calls during afternoon hours" maps directly to "check for bandwidth saturation, verify QoS."

Lab practice. If you have a lab environment with a PBX and test phones, deliberately create quality problems and practice diagnosing them. Saturate the bandwidth and watch the MOS drop. Introduce jitter with a traffic shaper and listen to what it sounds like. This builds the pattern recognition that makes real troubleshooting faster.

Cross-reference the symptom guides. The troubleshooting series on this site covers specific symptoms in detail: choppy audio, one-way audio, echo, delay and talking over, static and buzzing, calls dropping. Each post describes the symptom from the user's perspective and lists the common causes. When a client describes a symptom, start with the corresponding guide to orient your investigation, then apply the MSP-level diagnostic tools described here.

The goal is to get to the point where hearing "my phones sound bad" triggers a systematic response rather than a scramble. Triage, investigate, diagnose, resolve, communicate, document. Every time.

Next up: Capacity Planning and Scaling, covering how to anticipate when a voice system needs to grow and present upgrades as proactive management rather than reactive firefighting.