Davidoff777 - Fotolia
When network managers want to measure voice quality, they typically think in terms of packet loss, jitter and delay numbers, and almost always in terms of their averages. These numbers, however, are generally off the mark and often misleading.
First, the most important number to focus on is packet loss, which must not only include a count of packets lost in the network, but also packets discarded by the jitter buffer. If only the packets lost in the network are counted when you check for packet loss -- as is typically done by traditional Simple Network Management Protocol-based management methods, such as management information base 2 (MIB2) and Remote Network Monitoring (RMON) statistics -- you've probably missed the biggest source of lost packets: jitter-buffer discards.
Run a ping test
Before delving deeply in to packet-loss remediation, it's a good idea to confirm you are actually experiencing packet loss. Fortunately, it's easy to test for packet loss using the ubiquitous ping network utility program. Run a quick ping test to obtain a packet-loss result, among other information.
Ping is built into every operating system, and if it's not available via GUI-based utility, the ping test can always be found by bringing up the command line in Windows or the terminal shell on a Mac or Linux machine.
Select a destination, such as an IP address or domain name, that is on the other side of the network you want to test by typing Ping [destination domain name] and hit the enter key. You may want to adjust some options depending on the operating system. For example, a Mac operating system will run the ping forever by default, and you will wait forever for it to finish and give you your packet-loss result. Entering Ping –c 10 before your destination name will tell the Mac to run the ping 10 times. If packet loss is sporadic and you don't think it will be detected in a short run, increase the ping count to 100 or more.
Measure jitter-buffer discards to check for packet loss
To compensate for jitter -- aka packet-delay variation -- and maintain a smooth frame play-out rate, voice over IP (VoIP) endpoints implement a jitter buffer. The jitter buffer adds a small amount of delay to each packet and plays them out at a constant rate.
If a packet is too late by arriving beyond the jitter buffer's additional delay budget, the jitter buffer will drop it. As a result, the jitter buffer turns jitter into additional delay and ultimately packet loss, if the delay variation is too large. Obviously, a similar process occurs with simple delay. If the packet arrives too late, it is discarded. Thus, lost or late packets can degrade VoIP sessions.
How to use SD-WAN to check for packet loss
Today, though, a lost packet you detect on one network path might not be lost at all. Many software-defined WAN edge router technologies implement forward error correction (FEC). FEC works on the premise that packet loss and delay affecting one packet will likely not affect a duplicate of that packet, which could traverse a different network path. FEC protects sessions at the expense of additional traffic, as those duplicate packets consume bandwidth. But FEC can improve VoIP performance for the end user, given the packet now has two chances to arrive in a timely manner.
It's important to confirm that packets marked as lost are truly affecting your VoIP sessions. If FEC technology is replicating those packets, the packet loss might not be causing degradation at all. Of course, packet loss is never good, so if you are seeing anything above low single digits, it's probably time to contact your service provider to address the issue.
Fortunately, WAN analytics have improved dramatically in recent years. While devices still collect MIB2 and RMON data, most edge devices have implemented higher-level, session-oriented data collection. SD-WAN devices and related network optimization services, such as Symantec PacketShaper, can often provide information to accurately measure user experience.
At the end of the day, we care about packet loss because of its effect on user experience. By referencing user-oriented, session-level analytics, we can quickly and accurately identify whether packet loss, if present, is actually causing service-level problems.