Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Assuring VoIP Quality: Not There Yet: Page 5 of 7

Compared to TDM networks, packet networks present a unique problem in that problem conditions tend to be highly transient. When you make a call on a TDM network, the quality you experience in the first few seconds of the call is likely to be the quality throughout the call. As we've all experienced, that's not true for VoIP. So in order to manage VoIP quality, both the quality of the call and the network conditions at the time need to be constantly measured.

Telchemy and Psytechnics are two pioneers in developing computationally lightweight methods for calculating call quality based on data available from VoIP endpoints (such as phones, soft clients, and messaging centers) and gateways (such as IP PBXs and network gateways). Nortel Networks, for instance, has been using Telchemy's software agents in its phones since 2001. These agents use information gathered from the phone's Digital Signal Processing (DSP) chip, as well as from its protocol stack and jitter buffer (regarding packet loss and discards). MOS ratings and the E-Model can be evaluated every few seconds of a call in order to track the user's experience throughout the call. Telchemy is working with DSP and VoIP chipset manufacturers to build such data collection right into the VoIP chipset.

This data not only tells us the call quality experienced, but also provides information on the network conditions at the endpoint that led to the perceived call quality. For those who have followed data networking management standards for a while, this should sound a lot like the goals of SNMP's RMON MIB. The idea is to allow the endpoint device (or its associated switch port in the RMON world) to monitor its own performance and then report that information back to some centralized device for event correlation. If you tend to view RMON as an abysmal failure, take heart--the similarity (hopefully) starts and ends at the goal of data collection.

Those who championed collection of VoIP data at the endpoint realized that SNMP was too heavy for many devices. So instead of defining an SNMP MIB for the capture of call quality data, they decided to use the Real-Time Protocol (RTP), the same protocol used for sending bearer channel data on a VoIP network. Dubbed RTP Control Protocol Extended Reports (RTCP XR) and standardized as RFC 3611, the protocol calls for capturing and reporting 20 data network and voice quality statistics. Telchemy's CEO is one of the RFC's primary authors.

On the voice quality side, the MOS-LQ and MOS-CQ (Conversational Quality) scores are reported, as is the resultant (or "R") value of the E-Model described above. Also included are noise level, signal level, and echo return. On the data network side, packet loss, delay, and various jitter buffer statistics are reported. Some of these values are broken down further. For example, delay is measured both for RTP round trip and for the endpoint itself. Endpoint delay includes such parameters as the depth of the jitter buffer and the codec being used.