The Internet: The Part You Don't Control

VoIP From the Ground Up: Part 7 of 10

In the last post we covered the local network, the piece of the voice path you own and can fix. This post covers everything else: the long journey your voice packets take between your building and your VoIP provider's infrastructure.

This is the part that causes the most frustration for VoIP users, because when problems happen here, you cannot directly fix them. You can only identify them and put pressure on the right people.

What the path looks like

When a voice packet leaves your router, it enters your internet service provider's network. From there, it may pass through several other networks before reaching your VoIP provider. A typical path might look like this:

Your phone sends a packet. It crosses your local network to your router. Your router forwards it to your internet service provider's equipment, usually at a local facility. Your provider's network routes it through one or more of their own facilities, possibly across the region. At some point, the packet leaves your provider's network and enters another network, either through a direct connection (called peering) or through a third-party transit provider. It may cross one or more additional networks before finally reaching the network where your VoIP provider's servers live.

Each of these transitions is called a hop. A voice packet might cross 10 to 20 hops between your phone and the VoIP provider. Every hop is a router making a forwarding decision, and every hop is a potential point of failure.

Where problems happen

Your internet service provider's last mile

The "last mile" is the connection between your internet service provider's local infrastructure and your building. It might be a fiber optic cable, a coaxial cable, a copper line, or even a fixed wireless link. This segment is often the most congested part of the path because it is shared with your neighbors.

Cable internet, for example, uses a shared infrastructure at the neighborhood level. During peak evening hours when everyone is streaming video, available bandwidth can decrease significantly. Even a business-grade connection can be affected if it shares underlying infrastructure with residential customers.

Fiber connections are generally more consistent, but they are not immune to problems. A misconfigured device at the provider's end, a congested aggregation point, or a physical cable issue can all introduce latency or loss.

Peering points

Peering points are where different networks connect to each other and agree to exchange traffic. Major internet exchange facilities handle enormous volumes of data, and when traffic between two specific networks exceeds the capacity of their connection, packets get dropped.

Peering disputes are a known source of VoIP quality problems. If your internet service provider and your VoIP provider's network do not have a direct peering relationship, your voice traffic might take an indirect route through one or more intermediary networks. Each additional network adds hops, latency, and potential points of congestion.

These disputes and capacity limitations are completely invisible to you as an end user. Good VoIP providers actively monitor path quality and may detect peering congestion on their end, but your internet service provider may not even be aware of it. Neither side has full visibility into every network in between.

Transit networks

Large backbone networks carry traffic across long distances. They are generally well-maintained and have significant capacity, but they are not immune to problems. Equipment failures, fiber cuts, and routing changes can all cause sudden increases in latency or packet loss on specific paths.

Routing changes are particularly sneaky. The internet's routing system is dynamic. The path your voice packets take at 9:00 in the morning might be different from the path they take at 2:00 in the afternoon. A routing change might send your traffic through a more congested path, degrading quality, and then revert later in the day. Intermittent quality problems that seem to happen at random are sometimes caused by temporary routing shifts that are nearly impossible to predict.

Geographic distance

Physics cannot be negotiated with. Light in a fiber optic cable travels at roughly two-thirds the speed of light in a vacuum. A round trip from New York to Los Angeles and back takes approximately 60 milliseconds just for the speed-of-light component, before adding any processing or queuing delays.

For domestic calls, this is manageable. For international calls, especially to distant regions, the base latency from distance alone can push close to the 150 millisecond threshold where conversations start to feel awkward. Add network congestion and processing overhead on top, and you can end up with calls that sound fine but feel impossible to have a normal conversation on.

Why you cannot see the problem

When you run a speed test, you are measuring the bandwidth and latency between your device and a speed test server, usually located at your internet service provider's facility or a nearby data center. This tells you almost nothing about the quality of the path to your VoIP provider.

Your internet connection might show 200 megabits per second download, 50 megabits per second upload, and 10 milliseconds latency to the speed test server. Great numbers. But your VoIP traffic is not going to the speed test server. It is going to your VoIP provider's infrastructure, which might be in a completely different location, crossing different networks, through different peering points.

The speed test tells you that your last mile is fine. It does not tell you anything about hops 5 through 15 on the path to your VoIP provider. A congested peering point at hop 8 will never show up in a speed test. A VoIP quality test measures what actually matters for calls -- latency, jitter, and packet loss on a path that resembles real voice traffic -- rather than raw throughput to a nearby server.

This is exactly why the "have you run a speed test?" response from your VoIP provider is so unhelpful. It measures the wrong thing.

The blame game, revisited

Here is the pattern that plays out thousands of times a day at businesses across the world.

The phones sound terrible. You call your VoIP provider. They check their systems and report no issues on their end. They suggest you call your internet service provider. You call your internet service provider. They run a line test, see no errors, and tell you the connection is fine. You are now stuck between two companies, each claiming the problem is not theirs, with no way to prove where the issue actually is.

Both companies are often telling the truth as far as they can see. Your internet service provider can see the health of the last mile connection. Your VoIP provider can see the health of their own infrastructure. But neither one has visibility into the networks between them. The problem could be at a peering point, at a transit provider, or at an aggregation point that neither company monitors.

Without independent measurement that covers the entire path, you have no leverage and no way to hold the right party accountable.

What you can do

You cannot fix a congested peering point or reroute traffic through a backbone network. But you can take steps to improve your position.

Get a dedicated internet connection for voice. If your budget allows it, a separate internet connection used exclusively for VoIP traffic eliminates competition with data traffic on your local internet link. This does not solve problems in the middle of the path, but it removes your own connection as a variable.

Choose a VoIP provider with good peering. Providers who maintain direct peering relationships with major internet service providers deliver more consistent quality than those who rely entirely on transit networks. Ask your VoIP provider about their network architecture and peering relationships. If they cannot answer, that tells you something.

Run path-specific tests. Tools like traceroute can show you the individual hops between your network and your VoIP provider. While they do not perfectly simulate voice traffic, they can reveal where latency spikes or packet loss is occurring along the path. Running these tests during a quality problem gives you data you can bring to your provider with a specific hop identified.

Document everything. When quality problems occur, note the time, duration, and symptoms. Run diagnostic tests during the issue, not after. Intermittent problems are impossible to investigate after the fact. Having timestamped data that correlates with specific network path measurements gives your provider something concrete to investigate.

What comes next

Now that we understand both halves of the path, the local network and the internet, the next post takes a deeper technical look at the three metrics that define voice quality: latency, jitter, and packet loss. We will cover how they are measured, what the acceptable thresholds are, and how they interact with each other.

This is Part 7 of the VoIP From the Ground Up series. Part 8: Latency, Jitter, and Packet Loss in Detail provides the technical depth on the three metrics that define whether a call sounds good or terrible.