Skip navigation

Geek Speak

2 Posts authored by: ios_jockey

In Fundamentals of VoIP Monitoring & Troubleshooting Part 1 we spoke about the difficulties with reactively troubleshooting VoIP related problems and how Call Detail Records (CDRs) can be used to fill the gap in time. When an end user experiences a problem it can be mins, hours and even days before you’re notified and the troubleshooting process begins. Visibility into what took place during that call is paramount and the metrics gathered from CDR’s can help.


Let’s start with the following call quality metrics:


Network Jitter: Real-time voice communications over the network are sensitive to delay in packet arrival time or packets arriving out of sequence. Excess jitter results in calls breaking up. Jitter can be reduced to a certain extent by using jitter buffers. Jitter buffers are small buffers that cache packets and provide them to the receiver in sequence and evenly spaced for proper playback. Buffer lengths can be modified; however, if jitter buffer is increased too much then the call will experience an unacceptable delay. Consequently, a reduction in buffer turns results in less delay but more packet loss. Jitter is measured in milliseconds (ms).

 

Latency: Latency, or lag, is the time delay caused in the transmission of a voice packet. Excess latency results in delay, packet drops, and finally to echo. Latency is measured in milliseconds (ms)

 

Packet Loss: Packet loss occurs when one or more packets of data fail to reach their destination. A single packet loss is referred to as “packet gap”, and series of packet loss is known as” burst”. Packet loss can occur for a variety of reasons including link failure, high congestion levels, misrouted packets, buffer overflows and a number of other factors. Packet loss causes interrupted playback and degradation in voice quality. Packet loss can be controlled using packet loss concealment techniques within the playback codec.

 

MOS: Mean Opinion Score is a numerical value to indicate the perceived quality of the call from the user’s perspective of the received call after compression, transmission, and decompression. MOS is a calculation based on the performance of the IP network and is defined in the ITU-T PESQ P.862 standard and is expressed as a single number in the range of 1 to 5, where 1 is lowest perceived quality and 5 is the highest. The above metrics are important to monitor and control in order to keep call quality at an acceptable level. It’s also important to note that the above metrics can vary depending where they’re captured. As a best practice it’s a good idea monitor these metrics end to end within your VoIP network. In our next post we’ll talk about how you can capture these statistics from the perspective that matters most – between two VoIP phones after a failed call. 

 

For more information on monitoring and troubleshooting VoIP please read our white paper here.

As a VoIP Engineer, I’m sure you’ve spent your fair share of time troubleshooting mysterious VoIP outages and call quality issues. You know, the ones that only happen when you’re not around and apparently only strike the most annoying end-user on the floor.

These kinds of problems can be very difficult to troubleshoot and provide root-cause analysis. Typically, troubleshooting the problem begins well after the fact and without any clues to help isolate the problem. This usually results in attempting to reproduce the issue by performing multiple test calls, checking the network for inconsistencies, and interrogating the end-user. If you’re the adventurous type, you’ll even go as far as installing your favorite packet capture software and reading through terabytes of captured network traffic, only to find that what sounded like a network issue is now gone without any trace.

 

Having a packet capture is very helpful when troubleshooting VoIP problems, but having them in the right place at the right time is a task easier said than done. If only there was a way to go back in time and place your packet capture between the end-user and the switch port prior to the call, surely you would have found the UDP errors or out of sequence packets that caused the garbled call. Unfortunately time travel is not an option, but do not despair. By enabling a couple of features on your Cisco® Call Manager and/or Avaya® Communication Manager, next time you’ll have the clues you need to isolate these problems without the guesswork.

 

Call Detail Records, CDRs, CMRs, and CQEs have many different names depending on the VoIP platform that you own, but they all provide very similar and useful call statistics. These include origin and destination of the call, starting time of the call, call duration, and termination codes. They also provide more important call quality statistics like jitter, latency, packet loss, and mean opinion score (MOS).

 

Each one of these metrics can have an effect on a call and, more importantly, can be used to isolate and resolve VoIP issues. In the second post of this four part series, I’ll cover each metric in more detail and explain what you need to look for when analyzing each while troubleshooting.

 

For more information on SolarWinds VoIP & Network Quality Manager watch our SE Guided Tour here.

Filter Blog

By date: By tag: