02. 09. 2015 Andrea di Lernia NetEye

Monitoring the Quality of VoIP Communications Using IP SLA

VoIP

Nowadays, digital technologies offer a variety of new channels for communication. The evolution of the last years, led Voice over IP (VoIP) become increasingly significant. On the one hand, VoIP allows the reduction of costs and a high degree of flexibility. On the other hand, it increases the complexity in terms of quality monitoring. Unfortunately, the identification of the root cause of emerging performance issues became even more difficult with this new technology.

VoIP-communications are frequently suffering bad quality and even interruptions, especially in locations with weak internet connection.

So, what can we do when users are continuously calling us, complaining that the quality of the connection is bad, but we do absolutely not understand WHY?

A targeted monitoring of all involved systems (switchboard, internet line, infrastructure of the local network, geographic connection among branch offices) obviously is a good first step, but generally it is not enough to find the root cause of the annoying interruptions during your VoIP-calls.

Let’s dig a little deeper: How does a VoIP communication work in detail?

For simplicity, we just consider those aspects, which affect the above described situation (therefore we do not consider the SIP protocol, which coordinates the management of phone sessions). Let’s concentrate on what happens when two people are connected and “try” to communicate.

To optimize the usage of the line, conversation data is usually coded and compressed through a codec. (Normally the g729, which has a rather good quality and an adequate bandwidth usage (24.8Kbps).)

To accelerate the communication, it is performed via UDP. Actually, this implies that we have no control over the delivery of the packages. In case of an overload, lost packages are not resend and therefore do never arrive to destination. This fact causes the disliked interruptions.

The communication between two phones, let’s assume an internal call between two different branch offices, can take place in two ways:

Peer-to-Peer: The phone communicate directly.

Non Peer-to-Peer: The phones communicate through a switchboard.

These two possibilities can also coexist; this depends on the configuration and the availability between the two branch offices. Non Peer-to-Peer communications need twice as much bandwidth as Peer-to-Peer communication, since data has to pass the line twice.

Now it is clear that applying a traditional monitoring approach does not allow collecting all necessary information to troubleshoot occurring performance issues.

How can we face this problem?

Here the IP SLA, developed by Cisco, comes to our aid. IP SLA measures the performance of IP services on a communication network consisting of Cisco devices. IP SLA permits to continuously and reliably generate traffic between two devices (switches, routers), to obtain quality indicators of this communication. In this way, we can determine how VoIP behaves between branch office A and B, between A and C and between B and C. Once we’ve understood this, we can adopt suitable measures.

There are two indicators, which provide information about the quality of a conversation:

MOS (Mean Opinion Score): Is a value among 1 and 5, where 5 implies an excellent audio quality. [Depending on the codec, a value near 5 can be reached.]

ICPIF (Impairment Calculated Planning Impairment Factor): Is the result of five different values, which ranges between 5 (excellent) and 55 (extremely bad). Normally, a “good” conversation has a value of 10.

Let’s consider a concrete example

  • User Rossi, in the branch office of Milan, complains about problems during the conversations (at 08:00, 08:40, 09:20) with user Verdi at the office at Catanzaro.
  • Since some time, IP SLA is active on the infrastructure in question and VoIP communications are monitored, archiving the corresponding performance data.
  • The service desk employee has received the complaint, checks the corresponding section and notes the following:

The indicators of the concerned periods show that during the conversations a deterioration of MOS and ICPIF occurred. During the same periods, an overload of the network between Milan-Catanzaro is discovered. (see images below)

Deterioration of MOS during the period of the conversation

Deterioration of MOS during the period of the conversation

Deterioration of ICPIF during the period of the conversation

Deterioration of ICPIF during the period of the conversation

Overload of the network Milan-Catanzaro

Overload of the network Milan-Catanzaro

Since we’ve recognized the problem, we are now able to set a QoS (Quality of Services) for communications between these two branch offices. To do so, we have to set/estimate a number of conversations, which have to be possible simultaneously. Once we set this number, we have to monitor it to understand if the actual bandwidth is sufficient.

The monitoring-system will proactively inform us if deviations from the predefined indicators occur. In this way, we can react in time to avoid restrictions to the users.

Below you will find an example, which shows the quality of MOS, IPCIF and Jitter.

IP-SLA img4

IP-SLA img5

IP-SLA img6

Andrea di Lernia

Andrea di Lernia

Profit Center Manager at Würth Phoenix
Hi everybody, I’m Andrea and my contribution to this blog is to give hints of the monitoring issue from an IT manager point of view. I was born in Bolzano in 1965 and my professional path started 25 years ago operating on the technical field as programmer, system/database administrator, network engineer, consultancy and so on. I’ve been living in Milan for 10 years working for multinational IT companies and I decided to return to Bolzano after my marriage and the birth of my daughter. I love sailing and diving in the summer, skiing in the winter and travelling off-road with my Landcruiser anytime

Author

Andrea di Lernia

Hi everybody, I’m Andrea and my contribution to this blog is to give hints of the monitoring issue from an IT manager point of view. I was born in Bolzano in 1965 and my professional path started 25 years ago operating on the technical field as programmer, system/database administrator, network engineer, consultancy and so on. I’ve been living in Milan for 10 years working for multinational IT companies and I decided to return to Bolzano after my marriage and the birth of my daughter. I love sailing and diving in the summer, skiing in the winter and travelling off-road with my Landcruiser anytime

Leave a Reply

Your email address will not be published.

Archive