RTCP XR measures VoIP performance

RTP Control Protocol Extended Reports defines a set of metrics that contain information for assessing VoIP call quality and diagnosing problems

Voice over IP can suffer from a variety of problems that can be challenging to detect and resolve, such as periods of degraded quality because of network congestion, and echo resulting from interconnections to other services. These issues require a new approach to fault and performance management.

A new VoIP management protocol, RTP Control Protocol Extended Reports (RTCP XR), defines a set of metrics that contain information for assessing VoIP call quality and diagnosing problems. The IETF this month published RTCP XR as RFC 3611 .

RTCP XR can be implemented as software integrated into IP phones and gateways inexpensively. RTCP XR messages containing key call-quality-related metrics are exchanged periodically between IP phones and gateways. This lets a probe or analyzer monitor these metrics midstream to support problem resolution, or be retrieved from a gateway using SNMP .

The protocol measures VoIP call quality using these key metrics:

Packet loss and discard

Packet loss and jitter affect call quality. The jitter buffer removes the jitter in the receiving IP phone or gateway, but this process adds delay and causes packets that arrive late to be discarded.

RTCP XR reports the packet loss rate, packet discard rate (because of jitter) and the distribution of lost and discarded packets. The loss/discard distribution describes the call in terms of bursts (periods during which the loss/discard rate is high enough to cause noticeable quality degradation) and gaps (periods during which lost or discarded packets occur infrequently and hence quality is generally good).

Delay

Delay can make conversations difficult and make the effects of echo obvious. RTCP XR reports round-trip delay, corresponding to the packet path delay that would be measured using RTCP, and end system delay, which represents the delay that the VoIP endpoint adds (because of encoding, decoding and the jitter buffer).

Signal, noise and echo levels

If a signal is too loud, too quiet or too noisy, call quality suffers. RTCP XR reports the signal and noise level associated with the received signal, making it easier to identify signal- and noise-level problems.

If the IP endpoint contains an echo canceller, RTCP XR can report the residual (uncanceled) echo level, which helps the remote IP endpoint calculate call quality more accurately and make the detection of echo problems easier.

Call quality

RTCP XR can report call quality directly, in terms of estimated R factor or mean opinion score (MOS). An R factor is a conversational-quality metric in the range of 0 to 100. MOS-LQ is a listening-quality metric and MOS-CQ a conversational-quality metric, both in the range of 1 to 5. These can be generated using embedded software-agent technology.

Configuration data

RTCP XR reports the jitter buffer size and configuration, and the type of packet-loss concealment algorithm in use.

Access to such performance data for each IP phone on an enterprise network makes it easier to diagnose problems remotely. Administrators can use SNMP to retrieve data from each IP gateway, or use midstream probes or analyzers to capture call-quality data to aid in problem resolution. RTCP XR lets midstream probes and analyzers obtain information on signal, noise and echo levels without having to decode the packet stream, which will be essential if payloads are encrypted using the new Secure RTP protocol from the IETF.

The set of VoIP performance metrics defined in RTCP XR also form the basis for new draft quality-of-service reporting extensions to leading call-control protocols. This will let IP endpoints report call-quality metrics directly to call managers and softswitches, making integration into call detail records easier.

RTCP XR will form a key part of the emerging VoIP management infrastructure. Major IP phone, gateway and VoIP test-equipment manufacturers already have begun to implement this new protocol and widespread support is expected by mid-2004.

Clark is the CEO of Telchemy. He can be contacted at alan@telchemy.com