Control of call quality for CUCM using Tariscope

As you know, Cisco Unified Communications Manager (CUCM) generates both Call Detail Records (CDRs) and Call Management Records (CMRs). The CMRs save information about the quality of the streamed audio and video of calls. The CMRs are linked with CDRs through two fields: GlobalCallID_callManagerId and GlobalCallID_Called [1].

CMRs are supported by Cisco Unified IP Phones, Cisco 7960 series phones, and Media Gateway Control Protocol (MGCP) gateways. Each endpoint of a call generates a separate CMR record. If the call involves endpoints that do not support call diagnostics, no record gets generated for that endpoint [1].

By default, the CMRs are disabled in CUCM. If you want to analyse IP call quality, activate this feature. How to do it, find in [1] or [2]. In this case CUCM will generate CMR files. Keep in mind that collecting CMR records requires some CPU utilization of CUCM (see Table 15 [1]).

In order to understand what information the CUCM administrator can be obtained from the CMR records, consider the list of CMR fields in the Table 16 of [1].

To estimate call quality the following CMR fields are of interest: numberPacketsLost, jitter, latency, and voice quality metrics from varVQMetrics field.

Packet loss

VoIP packets are sent using RTP, so they don’t get retransmitted if they are lost. The impact of lost packets varies depending on the number of packets lost and the manner in which they are lost. Packet loss is one of key network performance metric that affects the call quality. According to some sources it is believed that the loss of up to 5% of packets is invisible, and more than 10-15% - is unacceptable. Moreover, these values strongly depend on the algorithms of compression / decompression, and the type of packet loss. For example, in the one call the packet loss were singly or in small groups at various time points, with a total of 100 packets lost. And in the other call the losses were by two blocks of 40 and 60 packets, ie a total of 100 lost packets too. Naturally, in the first call the packet loss is not practically affect the intelligibility of speech, while in the second case it will be noticeable.

There are two types of packet loss:

1. Network packet loss: The receiver did not receive the packet because it was discarded somewhere between sender and receiver. Network packet loss has numerous causes, but the two most common are:
- Network congestion. Anytime there is too much traffic on a link or queue, a router must make the decision to discard some of the packets. Packets are dropped by the router according to a variety of different QoS mechanisms.
- Network errors. Link errors caused by physical media can lead to packet loss. If a packet is corrupted and can’t be reconstructed after transmission, it will be discarded and thus lost. Duplex errors between network cards and switches is a leading cause of packet loss.

2. Jitter buffer loss: The receiver received the packet, but it was too early or too late to be accommodated by the jitter buffer and was therefore discarded.

Jitter
Jitter, often referred to as delay variation, is a measure of the differences in arrival times among all VoIP packets sent during a call. When a phone sends a VoIP packet, it sets the timestamp value in the RTP header. When the packet is received, the receiver generates a timestamp and compares it with the sender’s timestamp. The timestamps are used to calculate the packet’s delay variation or jitter value, which can then be reported by the IP phone or by other monitoring equipment. Too much jitter can cause packets to arrive too early or too late to be processed by the jitter buffer. When this happens, the phone discards the packets – a form of packet loss.

To reduce the impact of jitter, the receiver employs a jitter buffer to receive the incoming packets. Most jitter buffers in IP phones and voice gateways hold at least two VoIP packets. They are adaptive and can adjust, becoming larger or smaller depending on network conditions. As packets are received, they are placed in the jitter buffer, which holds them in order to supply a constant stream of packets to the receiving codec. The jitter buffer may have to account for early- or late-arriving packets and may have to re-order any packets that arrive out of order. Packets that don’t fit into the jitter buffer are discarded, resulting in packet loss.

So, why not just make the jitter buffer large enough to handle all possible variations? The reason is that every millisecond increase to the jitter buffer results in a millisecond of additional latency for the VoIP packet. Jitter buffer delay must be factored into the overall latency budget for VoIP.

Latency
The time it takes for a VoIP packet to travel from the speaker to the listener is called the delay, or latency, of the system. The ITU G.114 standard includes research showing that 150 ms of one-way latency is the point where call quality begins to degrade. Delays greater than 150 ms can make conversing difficult and result in a degraded user experience.

We can distinguish the following sources of delay in voice over IP:

Packetization: The time it takes for a codec to encode and decode a packet for transmission or reception.
Queuing: The time spent in router queues along the path through the network. The more congestion, the greater the queuing delay.
Serialization: The time it takes to put a packet on a network link interface. This value increases as the packet size increases and as the link speed decreases.
Propagation: The time it takes to travel from one point to another in the network. This time is a fixed value that’s directly related to geographical distance.
Jitter buffer: Each VoIP phone and each voice gateway provides a jitter buffer to smooth out the effects of network jitter, or variations in delay among packets in the same stream.

This buffer adds delay as the packet is held for playout.

In [1] Cisco System calls the voice quality metrics as K-factor that represents an endpoint mean opinion score (MOS) estimation algorithm that is defined in ITU standard P.VTQ. K-factor is a general estimator that is used to estimate the mean value of a perceptual evaluation of speech quality (PESQ) population for a specific impairment pattern.

The MOS estimate provides a number that is inversely proportional to frame loss density. Clarity decreases as more frames are lost or discarded at the receiving end. MOS estimate is in the range from 1 (poor voice quality) to 5 (very good voice quality). Table 1 shows the MOS values and associated quality rating.

Table 1

MOS	Listening Effort
5	No effort required
4	No appreciable effort required
3	Moderate effort required
2	Considerable effort required
1	No meaning understood with any feasible effort

K-factor gets trained or conditioned by speech samples from numerous speech databases, where each training sentence or network condition that is associated with a P .862.1 value has a duration of 8 seconds. For more accurate scores, the system generates k-factor estimates for every 8 seconds of active speech [1].

In [1], the Table 17 you can find a list of K-factor data and their description.

It should be understood that K-factor and other MOS estimators are secondary because they warn a network operator of frame loss only after the problem becomes significant. Number of lost or obtained packets, concealment ratios, latency, and jitter represent primary statistics because they alert the network administrator before network problems will be visible and they will have an audible impact.

In different sources the MOS estimates are slightly different for different codecs. Wikipedia data [3] are shown in Table 2.

Table 2

Codec	Data rate, kbit/s	MOS
G.711 (ISDN)	64	4,1
iLBC	15,2	4,14
AMR	12,2	4,14
G.729	8	3,92
G.723.1 r63	6,3	3,9
GSM ERF	12,2	3,8
G.726 ADPCM	32	3,85
G.729a	8	3,7
G.723.1 r53	5,3	3,65
G.728	16	3,61
GSM FR	12,2	3,5

You can use this table data for assessing voice quality for a particular codec.

Support of CMR in Tariscope

Tariscope that is a call accounting and billing system supports processing as CDR, and CMR records. The user can view and analyze the CMR data using the corresponding reports.

To set up Tariscope for processing of CMR files, in the CUCM setting of Tariscope, click on the Configure list box and in the CUCM parser configuration window, select the Save all files checkbox as shown in Figure 1.

setting Figure 1

To view and analyse the processed CMR data, open a view with calls from CUCM, and on the toolbar, click on New report icon. In the Choose report window, in the report tree, select the CUCM folder. In the folder now you can find the following reports:

CUCM Jitter,
CUCM Latency,
CUCM Lost packets,
CUCM K-factor data,
CUCM CMR data.

The CUCM Jitter report displays CMR records which have non-zero jitter. The report data is sorted by telephone numbers. A sample report is shown in Figure 2.

jitter Figure 2

The CUCM Latency report displays CMR records which have non-zero latency. The report data is sorted by date and time. A sample report is shown in Figure 3.

latency Figure 3

The CUCM Lost packets report displays CMR records which have non-zero value of the lost packets. A sample report is shown in Figure 4.

lost packets Figure 4

The CUCM K-factor data report displays only those CMR records where the MLQKmn field value is below 4. An example of such a report is shown in Figure 5. MLQKmn field represents the minimum score that is observed since the beginning of a call and represents the worst sounding 8-second interval.

K factor Figure 5

The CUCM CMR data report is partially similar report on CUCM K-factor data, but also displays the values of jitter, latency and packet loss. A sample report is shown in Figure 6.

all cmr Figure 6

The Tariscope user, using the Report Designer program from the system can independently upgrade any of the above reports to fit your needs or create your own report forms.

Using the Tariscope Tasks mode, you can set a schedule by which the system will generate reports and save them in a specified folder or send an email to the specified email address. Thus, if in the task setting of Tariscope Tasks you select the Attach report to subscriber documents checkbox, the report will be accessible through the Personal subscriber cabinet.

The Tariscope system allows to create a script that after a specified period of time, for example, 1 second, will check for new CMR records and process their according to their contents and then will perform the required action.