When your VoIP service deteriorates, you can perform a command known as "traceroute" on your computer to see if there are problems with your internet connection, your hosted VoIP provider, or some intermediate router along the way.
The nearly instantaneous loading time of your internet can make it seem like your computer has a direct path to every URL destination. But the request that you send from your computer doesn't actually travel nonstop from Point A to Point B. In reality, your online data must travel through many devices, primarily routers, before it reaches its final destination, and vice versa.
A traceroute maps how internet data travels from your computer to your intended destination. Along the way, the traceroute documents the intermediary devices and measures how long it takes for data to travel from your computer to each point.
From a technical perspective, a traceroute sends three ICMP packets to each router it encounters on the way to the final destination. An ICMP packet is a small packet of data that consumes little bandwidth, and is used primarily as a measurement tool.
You can perform a traceroute on most operating systems, including Windows, Mac, and Linux. Here's how to initiate a traceroute on your computer:
Mac / Linux:
Windows:
"[hostname]" simply refers to the website address or IP address of a specific router, server, or device. This is the destination point that the traceroute will report on. The traceroute will terminate automatically when complete.
If you are experiencing issues with your VoIP service and not other online activities, run a traceroute to your VoIP provider's server (OnSIP customers should use sip.onsip.com) and compare it to a traceroute to another destination.
Note: The time it takes to complete a traceroute is not how long it takes for that website to load in a web browser.
Here is a sample traceroute report we ran on a computer to our homepage, www.onsip.com.
On the third line, you can see that there is a warning that the provided URL (www.onsip.com) has multiple IP addresses.
In this case, the traceroute will identify which of the IP addresses will be traced. The next line establishes the specific name and IP address of the traceroute's destination. It also displays the number of intermediate stops the command will report on (64 hops), and the size of each ICMP packet being sent (52 bytes). A "hop" is the technical term used to describe the path a packet takes between two routers.
Next, the traceroute will begin listing data for each router it encounters as the packets make their way to the destination. These hops are numbered vertically on the left-hand side of the window.
Each line includes the domain name (if available) and IP address of the router. Fun fact: Router names sometimes use the 3-letter code of the nearest airport to identify their geographical location. For example, the 6th hop in our sample traceroute is a Cogent router near JFK airport in New York City, denoted by the string "jfk05".
Next to this you will see three time measurements in milliseconds. These values indicate how long it took for each of the three ICMP packets sent by your computer to reach that router and then come back.
Usually, the first hop on the report refers to router on your own Local Area Network (LAN). The subsequent hops refer to routers associated with your Internet Service Provider (ISP). In our example, you can see that Cogent is our ISP (hops 3-6).
Once your ICMP packets leave your ISP's domain for the open internet, you'll notice that the round trip times will likely increase as the hops get further away geographically, the round trip times will increase.
In this example, the round trip times nearly triple when the packets leave the ISP's NYC servers and hop to servers in Newark, New Jersey and Ashburn, Virginia (hops 7-9).
Notice that under hops 7 and 8, it appears as if two different routers have been sent packets instead of one. This is not actually the case—it means that the router is responding to the ICMP packets from different interfaces, each of which have their own IP addresses, but it's the same physical device.
When a traceroute has difficulty accessing a device, it will display a "Request timed out" message and an asterisk for each unreturned packet. This usually means that it has reached a router that has been configured to automatically reject or deprioritize ICMP packets. Many routers do this because ICMP is not considered essential internet traffic.
If you experience timeouts at the beginning of your report but the traceroute continues to run, there shouldn't be an issue. If you are seeing several consecutive timeouts at the end of your report, it may be due to one of the following reasons:
If you are experiencing choppy audio, noticeable lags, or other VoIP call quality issues, a ping test is a useful for determining if the issue is related to a bad internet connection. If it is a network issue, a traceroute is the next step for finding out which router along the path is responsible for these problems.
Latency is the term used to describe how long it takes for a packet of data to get from one point to another. In a traceroute report, this is expressed as the round trip times at each hop. High latency can result in laggy internet and impact the quality of your business VoIP calls.
However, before you point fingers at the hop on your traceroute report with the highest round trip times, take into account that there are several factors that impact how long a hop takes.
First is the physical distance between your computer and the final destination. The closer two routers are, the faster it will be to transmit information between them. For example, if you're performing a traceroute to a web server 50 miles from your office, you should expect quicker round trip times between each hop. However, if you're trying to reach a web server that is thousands of miles away, or on another continent, the physical distance is going to result in longer round trip times. (Looking at an Australian company's website? Your information is traveling via submarine communications cables found on the ocean floor!)
Second is the type of connection between each hop. A computer with a Gigabit ethernet connection will probably experience faster hop times than a computer with smaller bandwidth caps. Besides bandwidth, the method of internet delivery matters too. A shared wireless router might deliver slower round trip times than a single computer that's connected to fiber optic internet via an Ethernet cord.
Taking all of this into account, there is no definitive benchmark for an ideal hop time. Generally, hops over 150ms - 200ms will cause a noticeable delay in your internet connection. However, times in this range could be normal if the packets are traveling to another continent.
In terms of hosted VoIP, high round trip times might not be a problem if there's little variance between when the packets arrive. However, if you're experiencing round trip times that are extremely high, your VoIP calls may have noticeable delays.
It all depends on where you see high latency in the traceroute report:
If you see round trip times increasing in a sustained fashion as the traceroute approaches the destination, it's likely that the device where the increase started is causing problems.
You should look out for high variance between the three round trip times at each hop. If one or two of the packets are taking a lot longer to return, this is an indication that you are experiencing jitter.
When reading a traceroute, you're judging not just what you see, but where you see it. The advantage of using a traceroute is that it can tell you where a problem exists. This comes in handy when you're trying to figure out which service - your ISP, your VoIP provider, or your own equipment - is responsible for subpar network performance.
At the same time, a traceroute is only one of several troubleshooting methods for determining the cause of a poor VoIP connection. Once you have identified the router that may be causing a network issue, you can perform a ping test to that hop to determine if it is the cause of jitter, packet loss, or other errors.