Today nearly every organisation has an IP telephony based solution running over the same UTP data cabling as its network. Once the office telephony was considered a dark art, which required separate infrastructures and specialists with intricate knowledge of proprietary PBX systems.
During that time even the simplest office extension move required a visit from a PBX technician to change the programming in the system and make the necessary physical hardware changes. Also during that era, the phone system operated on its own cabling infrastructure and didn't integrate with anything else (unless you had one of those advanced IP gateways for computer telephony integration (CTI).
When the IP telephony revolution happened, suddenly voice services became part of the remit of the network team. The new phones used Ethernet and PC server architecture. The proprietary console driven interface became a web based GUI. For the first time a company could do an office shift without calling a specialist. The phone had a hardware MAC address and could be plugged in anywhere and the user extension would move with the phone.
However, the migration to VoIP brought new headaches and responsibilities for the IT department. The first being quality of service (QoS). Businesses had accepted that delays in network response were normal and expected, especially for remote sites running over a wide area network (WAN). But, the end user expectation was different when it came to VoIP. Customers would only tolerate so much degradation of a telephone call before complaining. Ensuring voice quality depended on deploying QoS mechanisms. Today, validation of QoS policies are more important than ever. The QoS has extended itself from being critical for voice quality to other time sensitive data applications such as Citrix, video and multi-cast applications.
Monitoring voice quality is easier than data traffic, since you don't need to establish a base line for acceptable quality because it is already done. The ITU-T Recommendation G.114 states that a one way delay of 150ms or less provides acceptable voice quality, and a delay of up to 400ms is acceptable for planning purposes. Similarly voice quality metrics, also called a Mean Opinion Score(MOS), is a simple method of measuring voice quality.
A test audience is played different samples of speech encoded at different bit rates to establish a common quality base line, which could be used across any voice technology. It is also an ITU-T recommendation contained in P.800.
|Good||Perceptable, although not annoying||4|
In service provider environments, it is common to see a R-Factor scale which is part of the E-model described in ITU-T G109. The R-Factor works on a scale of 1 to 100 and takes into consideration the complete ear to mouth circuit. Any value under 50 is not recommended. The values vary since user perception can vary depending on the environment as to where the call was made from and also the direction. For example, a mobile call R-Factor will differ depending on whether the call originated from the mobile network or started from the PSTN, and will score a different value accordingly.
|MOS||R-Factor||Data Rate (kbit/s)||Codec|
Methods for Measuring Call Quality
Most call quality monitoring methods use synthetic tests to determine quality. In the case of Cisco IP/SLA, a synthesised voice packet is generated between two routers to determine the quality. In addition to monitoring call quality ratings, the other impairments which are worth monitoring, and are included in synthetic call quality measurement methods are jitter, delay and packet loss.
In most enterprise environments the signalling information Real-Time Control Protocol (RTCP) contains information about the Real-Time Protocol (RTP) stream such as jitter and packet loss. Probe - based monitoring devices can intercept this information and report the call quality to the NMS. Lower cost IP handset devices may not support RTCP, so other methods of calculating the call quality must be used.
Furthermore, in the service provider environments the signalling information is carried out-of-band in another part of the network, and signalling is contained in ISDN user part messages (ISUP). In carrier environments, a call quality algorithm is used to computationally measure the actual traffic against known mathematical reference samples. These methods although not perfect can realise high accuracy percentages and are good enough to determine whether degradation is occurring in a voice path.
Jitter and Packet Loss
Have you ever been on a mobile call and for a moment or two the person at the other end of the call took on a robotic voice or the audio sounded strange? If you have, it is due to excessive jitter. For IP phone calls to work properly, they require a smooth constant stream of packets travelling in both directions. If there is congestion or improperly configured QoS then the stream of voice packets could be delayed slightly, causing a reduction in the sampling rate and lowering the quality of the call.
In order to compensate for jitter, the IP phone will have a jitter buffer that will delay the call by approximately a second, while the jitter buffer orders the packets back into a uniform sequence. The jitter buffer usually can compensate for up to 2 seconds of queuing before the listener perceives a delay in the call. Modern phone systems use adaptive jitter buffers which can increase or decrease dynamically depending on network conditions.
When the inter-arrival of packets exhausts the jitter buffer, the listeners perceives both delay and garbled speech. On a 100Mb or better Ethernet network the jitter values for voice calls will be small even without any QoS configured, since the latency of Ethernet is so low. However, on a serial WAN circuit clocked at 2Mb, QoS will be critical to ensure that voice packets are prioritised.
In IP telephony packets which arrive out of sequence or are significantly delayed are considered lost. A phone call is a real- time activity and RTP has no mechanism for ensuring packets arrive in sequence. However, due to the way the speech is decoded, we can usually compensate for a few missing bits in a voice stream without noticing a break. In a monitoring solution you are likely to see degradation of service as excessively high jitter, although this is normally concealed by the end-point device.
However, at some point the amount of packet loss will start to increase if network conditions continue to deteriorate. If this occurs periodically, the investigation should start with scheduled network backups, or virus engine updates occurring during phone calls that are not prioritised accordingly.
Both probe based and NetFlow based monitoring have the ability to report on the QoS traffic levels. The industry accepted standard for QoS is referred to as DiffServ. It works by marking or colouring packets at the source which meet a certain criteria. RTP voice packets for example are treated differently to unmarked packets or packets with other markings. Once again the values for these markings are a generally accepted standard.
DiffServ treats all markings on a per hop basis. It means every router or switch in the traffic path needs to be configured to honour the configured markings, and assign the packets into the correct queue for prioritisation. Often, a high amount of jitter or packet loss can be caused by incorrectly configured QoS on a WAN router. The network management system should have the ability to identify traffic placed into the wrong queue.
To conclude, the cause of poor voice quality values is normally created by the underlying network configuration. If the network is congested or voice traffic isn't prioritised then the quality of the voice traffic will suffer accordingly. A good NMS will include the ability to provide MOS, jitter and packet loss reports over time to ensure good quality.