How to Tell Where the Problem Actually Is

VoIP From the Ground Up: Part 10 of 10

This is the post the entire series has been building toward.

You now understand how traditional phone calls worked and why we moved away from them. You know how data networks operate, how packets move, and why voice is uniquely sensitive to network imperfections. You understand the difference between the local network you control and the internet you do not. You know what latency, jitter, and packet loss are, how they interact, and how Quality of Service can protect voice traffic on your side of the boundary.

The question that remains is the one that drove us to build VoIP Test in the first place: when calls sound bad, how do you figure out where the problem actually is?

The diagnostic mindset

The first thing to understand is that VoIP troubleshooting is a process of elimination. The voice path has multiple segments, and the problem could be in any one of them. Jumping to conclusions without data leads to the same circular blame game we described in Part 7.

Instead, the goal is to systematically narrow down where in the path the degradation is occurring. You work from the inside out: start with what you control, verify it is clean, and then move further along the path until you find the segment where the numbers go bad.

Segment 1: The endpoint

Start with the device itself. Is the problem isolated to one phone, one headset, or one computer running a softphone application? If other devices on the same network are experiencing clean calls, the issue may be the endpoint hardware, its configuration, or its connection to the network.

Check the obvious things first. Is the device on a wired connection or wireless? If wireless, move it to wired temporarily and see if the problem resolves. Is the device's network port running at the expected speed, or has it negotiated down to a slower rate because of a cable issue? Is the device's software up to date? Is its codec configuration consistent with what the VoIP provider expects?

A surprising number of quality complaints trace back to a single bad cable, a headset with a failing microphone, or a softphone application running on a laptop that is simultaneously processing heavy workloads.

Segment 2: The local network

If the problem affects multiple devices, the local network is the next suspect. This is where the knowledge from Part 6 and Part 9 becomes practical.

Run a latency and jitter test between your VoIP devices and your router. On a healthy local network, latency from any device to the router should be under 1 millisecond on a wired connection, and jitter should be negligible. If you see latency in the tens of milliseconds or measurable jitter on a wired connection, something is wrong with your switching, cabling, or network configuration.

Check for bandwidth saturation. Monitor your network utilization during the time periods when calls sound bad. If your internet link is running at or near capacity during those times, local congestion is likely the cause. This is where Quality of Service makes the biggest difference, but it only works if it is configured correctly.

Look at your switch port statistics if you have managed switches. Error counters, collision counters, and discard counters all tell a story. Rising error counts on a specific port often indicate a cable problem. Rising discard counts indicate congestion.

If your local network checks out clean, the problem is beyond your boundary.

Segment 3: The internet connection

The boundary between your network and your internet service provider is the most important diagnostic point. This is where you transition from the infrastructure you control to infrastructure you pay for but cannot directly manage.

Test the connection between your router and your internet service provider's first hop. If you see packet loss or high jitter at this first hop, the problem is either in your internet connection itself or at your provider's local equipment. This is something your internet service provider can investigate, and having specific data showing loss at their first hop gives you something concrete to report.

Also compare your actual bandwidth to what you are paying for. Not in a single speed test, but measured over time during the hours when calls are problematic. Many business internet connections deliver close to their rated speed during off-peak hours but significantly less during peak times. This sustained measurement is far more useful than a one-time speed test.

Segment 4: The middle of the internet

This is the hardest segment to diagnose because you have the least visibility into it. Between your internet service provider and your VoIP provider, your traffic may cross several networks, and you cannot directly monitor any of them.

Traceroute is the traditional tool for this. It shows you each hop along the path and the latency to each one. If you see latency jump dramatically between two specific hops, that transition point is likely where the problem lives. If you see packet loss at a specific hop that is not present at earlier hops, that device or the link to it is the issue.

However, traceroute has significant limitations for voice diagnostics. It uses a different type of traffic than VoIP, and some routers along the path may respond to traceroute probes differently than they handle actual voice packets. Latency shown at a specific hop sometimes reflects the router's slow response to the probe rather than actual forwarding delay.

More importantly, even if traceroute identifies the problem hop, you usually cannot do anything about it directly. The device belongs to a network you have no relationship with. The actionable step is to present this data to either your internet service provider or your VoIP provider, depending on whose network is closest to the problem hop, and ask them to investigate.

Segment 5: The VoIP provider

The final segment is your VoIP provider's own infrastructure. If the path to their network is clean but calls still sound bad, the issue may be on their end: overloaded servers, misconfigured routing, or capacity problems in their data centers.

Most VoIP providers offer some level of call quality metrics in their management portal. Call detail records often include jitter, loss, and MOS score data for each call. Comparing the metrics they report with what you measure on your end can reveal discrepancies that point to problems within their infrastructure.

If the provider claims their metrics show clean calls but your end is clearly experiencing degradation, the problem is most likely in the path between you, not at either endpoint. This is the hardest scenario to resolve because it requires cooperation between multiple parties who may not have a direct relationship with each other.

Putting it together

The diagnostic process, simplified:

Check the endpoint first. Rule out device-specific problems by testing with different hardware or connections.

Verify the local network. Confirm that latency, jitter, and loss between devices and the router are within acceptable limits. Verify Quality of Service is configured and functioning.

Test the internet connection. Measure real bandwidth, latency, jitter, and loss to your internet service provider's first hop during the times when problems occur.

Trace the path to the VoIP provider. Identify which hops introduce latency or loss and determine which network owns those hops.

Check provider-side metrics. Compare what the VoIP provider reports with what you observe on your end.

At each step, you are either finding the problem or eliminating that segment as the cause. By the time you have worked through all five segments, you know where the issue is. And just as importantly, you have the data to prove it.

Why this is hard to do on your own

If the process above sounds straightforward in theory but difficult in practice, that is because it is. Each step requires different tools, different expertise, and often different access. Running a traceroute is easy. Interpreting the results correctly, understanding which hops matter, knowing when high latency at a specific hop is meaningful versus a misleading artifact, that takes experience.

And the most critical gap is sustained monitoring. Network problems are often intermittent. They appear during peak hours, during specific routing conditions, or during congestion events at distant peering points. A single diagnostic test run at a random time might show a perfectly clean path, while the same path was severely degraded an hour earlier when the calls were actually bad.

What is needed is continuous, automated measurement of the voice path that captures the exact conditions during quality events. Measurement that simulates actual voice traffic rather than relying on generic network probes. Measurement that covers every segment from your device to the VoIP provider, so when a problem occurs, the data is already there showing exactly where it happened.

Our VoIP quality test is the starting point: it measures your connection using realistic voice traffic patterns and shows you exactly where degradation is occurring. For a systematic way to run these measurements — baseline tests, loaded tests, and before-and-after comparisons — see how to get real numbers instead of "calls sound bad".

The end of the blame game

The entire series has been about building understanding from the ground up so that when voice quality problems happen, you are not helpless. You understand what is going on, you know what to check, and you have a framework for systematically finding the answer.

But understanding the problem is only half the battle. Having the data to prove it, to your internet service provider, to your VoIP provider, to whoever owns the segment that is failing, is what actually gets things fixed.

Independent, continuous, data-driven voice quality analysis that shows exactly where the breakdown is happening and gives every party in the chain the evidence they need to take action. That is the product we are building, and now you understand exactly why it needs to exist.

If you want to be notified when we launch, sign up on our homepage.

This is the final post in the VoIP From the Ground Up series. For deeper dives into specific topics, check out our other posts on jitter, packet loss, MOS scores, wired vs. wireless, and VoIP quality for remote teams.