Last week, we focused on whether or not your network could handle more real-time data, like video and voice over IP. The blog outlined how video and voice over IP affect the network, whether or not your network can potentially handle more of this real-time protocol (RTP) traffic, and how to best prepare for this confluence of highly sensitive data.
Now that you have determined that your network can handle more VoIP, it’s time to take it a step further: What is the quality of your calls, and how do you troubleshoot voice quality issues?
When troubleshooting real-time data like VoIP, it is important to have the right analysis tools in place that can baseline your network and drill down into the most granular details of packet traffic on your network, but more importantly it’s critical to have tools that let you focus quickly on telephony calls and quality, which is where we will begin.
MOS and R-Factor – automated measurement of call quality
Mean Opinion Score (MOS) is a rating system that helps you assess the relative quality of a call. It has been used for years in telecom landlines, where real people were asked to listen to sample telephone calls, rating the call quality from 1 (very poor quality) to 5 (perfect). That data was used to create automated measurements which give you a reliable estimate of how the VoIP users in your network perceive call quality. Anything above 4 is considered to be a good quality call, with 3 being “slightly annoying,” 2 “annoying,” and 1 “very annoying.” In practice, there will be few complaints if your VoIP calls are above 3.5.
While MOS is a score historically based on human perception, modern implementations use a mathematical analysis. Besides MOS, another key mathematical factor in use today is R-Factor, which is designed to scale from 1 to 100, and encompasses both narrowband and wideband codecs (a weakness in MOS). Reasonable R-Factor scores for a call are about 75 and above. Interestingly, as VoIP codecs have gotten better, it has become possible for calls to have an R-Factor greater than 100. Modern codecs on a low-latency, low-jitter connection can carry a call with a score of up to 120.
Another factor that affects call quality is jitter. Jitter is the measurement of the variability of the time delay between each RTP packet. Jitter is important as a factor in call quality because, if uncorrected, it can result in gaps and lost data (missing audio) in the call. While most equipment has a jitter buffer to smooth out the gaps, the correction introduces latency. Too much latency will be noticeable by the callers as a time lag when talking, which itself reduces perceived call quality.
Dissecting RTP and RTCP to discover where the issues lie
When it comes to troubleshooting a network, it really comes down to understanding and being able to visualize the most granular details. In the case of VoIP, the most granular details for solving problems are held in the Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol Packets (RTCP).
RTP provides more than just the packaging and delivery of voice data, it also contains details that help you troubleshoot issues, including:
- A sequence number that is handy for detecting lost or out of sequence packets;
- The payload type, which can be a well-known type or dynamically assigned by the signaling protocol;
- A sync source identifier to uniquely identify an RTP stream; and
- A timestamp set, used to determine the expected packet arrival rate to the listener and for calculating jitter.
The RTCP packets are useful because they report on various conditions during a call in progress, including the percentage of packets lost since the last sender report, cumulative packet loss and jitter. RTCP packets can be captured anywhere in the path between two VoIP users, and analyzed to see how many packets are being dropped according to the listener.
What should I have in my VoIP troubleshooting tool belt?
When you are planning to troubleshoot poor VoIP call quality, you need to have a tool in place that measures overall metrics like MOS and R-Factor, and analyzes network conditions like latency, jitter, and packet loss, based on an independent analysis of RTP streams. This way, if a device does not support RTCP, you can capture RTP streams on the same segment as the listener to get call quality information close to that user.
A robust VoIP analysis tool must go beyond simply reporting the jitter included in the RTCP packets. It must also be capable of examining independent sources of jitter information by calculating jitter directly from the RTP packet stream itself. It is also essential to have notifications not only when reported by an end-device via RTCP, but also in real-time via RTP stream analysis as packets are captured. Having it both ways allows the analyst to better pinpoint where in the network jitter starts to become a problem.
Analyzing VoIP is a two-way street
Don’t forget to analyze at the end-points. To reiterate, the VoIP packets captured at the core is not where the call terminates. Capturing at multiple points allows you to see exactly where the quality of the call drops.
Remember that it’s very important to analyze each side of the call independently when studying existing VoIP calls. For instance, during a call there will be an RTP stream from device A to device B and a second, completely independent RTP stream, from device B to device A. Why? You need to know in which direction the call has degraded to solve the problem.
When looking at factors for VoIP over wireless (VoFi), there’s an entirely new set of considerations, which we will dive into in more detail in a few weeks. Stay tuned!