Use the IP Ping Tool to Diagnose Network Issues

The IP Ping tool lets you check whether Cloud Voice can reach a given hostname or IP (Internet Protocol) address from the network it sits on. This page walks through running a ping and making sense of what comes back. IP Ping only sends small test packets: it does not change any configuration or interrupt calls in progress, so it is safe to run on a live system.

When to use IP Ping

IP Ping uses the Internet Control Message Protocol (ICMP) to send small packets to a destination and measure whether they return, along with how long the round trip takes. It is a quick way to confirm that a target is reachable and to gauge the health of the path to it.

Reach for this tool when you run into either of the following:

• Connectivity problems. Verify that the system can actually reach a specific IP address or domain name.
• Degraded VoIP (Voice over IP) call quality. If calls suffer from echo, buzzing, or delay, a ping to the far end can reveal problems on the route: latency (how long each packet takes), jitter (how much that delay varies from packet to packet), or packet loss (replies that never arrive).

Run a ping

1. Sign in to the web portal and open Maintenance > Troubleshooting > IP Ping.
2. In the Target Host field, type the domain name or IP address you want to test.
3. Select Start to begin sending packets.
4. Select Stop once you have gathered enough output.

Note

The ping runs from Cloud Voice itself, not from your computer. The results reflect what the phone system can reach on its own network, which may differ from what your workstation can reach.

Tip

Entering a domain name (for example pbx.example.com) instead of a raw IP address also confirms that DNS is resolving, since the output shows the address the name resolved to. To tell a local network fault apart from an internet-wide one, ping a known-good public address such as 8.8.8.8 and compare.

Note

The tool keeps sending packets until you select Stop. That is why the failed example below shows 60 packets while the successful one shows only 3: it simply ran for longer before being stopped.

Interpret the results

A successful ping

When the target responds, the output resembles the following:

start...
PING 192.168.6.11 (192.168.6.11): 56 data bytes
64 bytes from 192.168.6.11: seq=0 ttl=64 time=8.853 ms
64 bytes from 192.168.6.11: seq=1 ttl=64 time=0.778 ms
64 bytes from 192.168.6.11: seq=2 ttl=64 time=1.394 ms

--- 192.168.6.11 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.778/3.675/8.853 ms

Here is what this tells you:

• Three packets were sent, and all three drew a reply, so no packets were lost.
• Each packet carried 56 data bytes, reported here as a 64-byte total once the ICMP header is included.
• The TTL (Time To Live) is 64, indicating the packets consistently follow the same path.
• The time value is how long each reply took to arrive after the request was sent (the delay between the outgoing Echo Request and the returning Echo Reply). Rising or erratic times are a useful signal that the network may be congested.
• The final round-trip min/avg/max line summarizes the fastest, average, and slowest reply times across the whole run.

Note

A wide gap between the minimum and maximum round-trip times means the delay is bouncing around, which is jitter. Even when no packets are lost, high jitter degrades voice calls, so watch that spread when you are chasing a call-quality complaint.

A failed ping

When nothing comes back, the output looks like this:

start...
PING 192.168.7.2 (192.168.7.2): 56 data bytes

--- 192.168.7.2 ping statistics ---
60 packets transmitted, 0 packets received, 100% packet loss

A result like this, with 100% packet loss, points to a problem with either the network path to the target or the target device itself.

Caution

A failed ping is not always proof that the target is down. Many networks, firewalls, and public servers deliberately block ICMP echo requests, so a host that ignores ping can still be serving traffic normally. Before you conclude a target is unreachable, confirm with another test (for example, reaching the service on its actual port).