Network Visibility Through Active Path Testing

You've updated your voice calling system. It uses SIP trunking, you've saved money, and everyone is happy. But a few nagging problems let you know it's not working smoothly all the time. How do you tell whether the network is at fault?

By now, you should know the factors that affect voice quality: latency, jitter, and packet loss. Except in some cases like satellite circuits, latency should be low, perhaps 100 to 200 milliseconds at most. Jitter should likewise be low, unless congestion is driving big changes in queue depths at multiple points in the path. Packet loss may be a significant factor as congestion fills buffers in the networking equipment along the path.

How do you know the network is running smoothly? How do you know a voice problem is external to the parts of the network path you administer? You can't answer these questions if you don't have good network monitoring instrumentation.

Network Visibility
To start, the network monitoring system should be monitoring all interfaces in the paths over which voice may travel. This means the network monitoring system needs to be inexpensive and correctly configured to monitor all interfaces. I've seen too many implementations in which cost has limited the use of the monitoring system such that some network interfaces go unmonitored. The result is a lack of visibility into potential causes of packet loss.

I like to instrument a network to record interface errors and drops. Errors are a network interface or media problem, like a dirty optical connection or a noisy WAN circuit. Drops occur when a network interface's buffers fill and another packet needs to transit that interface. Congestion on egress is significantly more common than congestion on ingress. Investigate interfaces that have more than 0.0001% (that's 1x10E-5) packet loss, and fix those with errors. Drops require other measures, which I'll cover below.

Read the rest of this article on No Jitter.