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.

Tariscope configuration to use the restriction feature with CUCM

Overview
Call restriction options
General settings
Do the following steps to configure the restriction feature:
Configuration of scripts for CUCM
Configuration option for CUCM
Administration and Monitoring
Licensing

Overview

Tariscope can be purchased with the additional feature called the Restriction feature.

limiting

The restriction feature allows the Tariscope administrator to set the restriction to the specific type of calls for a subscriber, group of subscribers, route or trunk. To apply the restriction feature it should be set a money limit or duration limit for a specific call type. The restriction is set for the month, week or day. The default period is one month. You can also set the start date of the next period. A specific type of calls is defined by a category. There are examples of categories that you can set:

only local calls,
only domestic long distance calls,
only international calls,
calls to specific telephone numbers,
and others.

A type of category is defined by the Tariscope administrator. When a subscriber has spent the money (time) that had been set to a specific call type, Tariscope executes a script. The script changes a subscriber configuration that restricts the subscriber access to the telephone network.

To use the restriction feature it should purchase a specific license.

Call restriction options

Tariscope supports two restriction options based on the method of obtaining information about the calls from the telephone system.

1. Restriction based on CDR information

In this case Tariscope gets information about calls only after the call ends. Therefore, there may be some excess of the set limit for some subscribers. At the time of exceeding the limit Tariscope Observer performs a script that sets an access restriction. Depending on the type of telephone system, the Tariscope administrator must select the appropriate script.

Tariscope includes scripts for the following telephone systems:

CS1000, Meridian 1 (Avaya-Nortel);
Aura, S8700/8500/8300, Definity (Avaya);
HiPath 4000 (Siemens);
3CX Phone System (3CX);
KX-TDA (Panasonic);
Asterisk,
Cisco Unified Communications Manager or CUCM (Cisco Systems).

If your PBX is not listed above, you can use a script that send an email. The script sends a message about an expenditure of the limit by a subscriber, and another message to the PBX administrator. Then it sets the access restriction for the subscriber.

2. Realtime monitoring

If a telephone system has API allowing to keep track of calls made at the current moment, Tariscope can restrict these calls with one-second accuracy. It calculates the cost and duration for each call that remains before the exhaustion of the limit. Once the limit is exhausted, the call is dropped. This allows to accurately control the company's budget. Tariscope performs a final calculation of the call cost after the call end and processing appropriate CDR. When the Realtime monitoring is used it is possible to apply the restrictions using scripts, but it is not mandatory. If you only use the Realtime monitoring, you must to configure the corresponding Tariscope services (Tariscope Main and Tariscope Observer).

This type of monitoring is supported for Asterisk and 3CX Phone System.

The following possibilities are also available for IP PBX 3CX Phone System:

the system can restrict a subscriber based on the state of his balance (for Tariscope Provider edition);
the system can prohibit to make calls from extensions which are absent in the Tariscope subscriber database.

General settings

To use the restriction feature, you must configure the basic parameters of Tariscope such as communication nodes, data collection subsystem, subscriber database, and rates. We will not consider these settings in this article, assuming that you have done all this settings.

Do the following steps to configure the restriction feature:

Enable the Restriction feature. To do this, on the All nodes configuration page, in the Control expenses (limiting) list, select an option that corresponds to your license.

limiting enable.en There are the following options:

Type	Description
Subscribers only	Tariscope only tracks the limits set for subscribers. When Tariscope gets a new call information for each category of restrictions it increases a sum of expenses.
Group only	Tariscope only tracks the limits set for subscriber groups. Limits of each subscriber will not be tracked separately, but they need to be set to mark the subscribers of the group, which may be restricted.
Routes/trunks	Tariscope only tracks the limits set for routes, trunks or gateways. There are no scripts for this option in the Tariscope installation package. You can add the scripts yourself or contact our support team.
Subscribers and groups	Tariscope tracks the limits set for subscribers and also for subscriber groups. The script is executed, if any of an individual limit or group limit will be exhausted.
All	Tariscope tracks all the configured limits.

Set the restriction group, classes of service, and their links to the call categories for each telephone system. To do this, open: Tariscope Management -> All nodes -> a desired node -> Equipment items -> a desired telephone system -> Restriction classes.

The following concepts are used for this configuration page:

Restriction group. This is a set of rules, according to which a class of service is selected, depending on the limitations set for a subscriber, and the status of expense for these limitations. A list of the restriction groups is common to all PBXs of communication node. But the elements of the group and their corresponding classes of service are tied to a particular PBX. You must create at least two elements of restriction group. For example, one element includes the class of service that permits phone calls, and another element that prohibits such calls. Groups of restrictions are tied to the subscribers.

Class of service (COS). This is an identifier that is used by a particular type of telepone system to determine access rights to various areas of the call. COS is passed to the restriction script, which uses it in the process of implementation. The format and value of COS are depended on the type of PBX.

For example: The Calling Search Space (CSS) is used as COS in Cisco Unified Communications Manager (CUCM).

For Communications Server 1000 (CS1000) by Avaya - Nortel you can use COS, NCOS, TGAR.

Call category. This is a parameter that is assigned to each call by the charging module of Tariscope in accordance with the direction of a call. One of purposes of the categories is to define a type of telephone traffic, which should be considered to set the restrictions. A list of categories can be obtained from the Tariscope Management -> Categories. You can tie country codes, area codes or telephone codes with categories using Tariscope Management -> Providers and rates -> your provider -> Destination codes or Destinations table.

The Restriction classes mode allows to configure COS for each combination of available categories of calls to subscribers. In the simplest case, each group of classes contains two elements: "everything is enabled" with a selection of All categories and "everything is disabled" when no categories were selected. If you want to restrict the various categories of calls individually, you need to create the elements of restriction group with all possible combinations of categories and corresponding COS. Tariscope automatically selects an element that is suitable for the current status of the subscriber restrictions, and pass it to the script.

You can assign any name for each group and element.

It is not necessary to configure the Restriction classes for Asterisk and 3CX Phone System when The Realtime monitoring mode is used. The calls are dropped by Tariscope.

For each subscriber, which can be restricted, select the Restriction group.

To do this, move to Tariscope Management -> All nodes -> a desired node -> Subscribers. Select one or some subscribers and click on the Edit icon located on the toolbar.

The subscriber editor window opens. Click on the Details icon.

In the Restrictions partition of the window, click on the Add button and select a restriction group, which should be applied to the subscriber. Type a limit to the call category. The limit can be set either in the money (in the current base currency) or in the time (in seconds). You can create multiple restrictions for a single subscriber for the different categories. They will be monitored simultaneously.
For each PBX, select the script file used for restriction.

To do this, select Tariscope Mangement -> Data collection/Observer -> a desired profile -> Configuration. In the appeared window of data collection, click on the Scripts button.

abonent script.en

In the Tariscope Observer scripts window, select a script for the event "Subscriber COS change". The predefined scripts are in the folder: C:\Program Files (x86)\SoftPI\Tariscope3\Scripts\

The script for sending email messages is called Generic\limiting-subscriber-setcos-email.vb

Scripts for different types of PBXs are in the appropriate folders.

In the window of the script selection dialog, you can choose a period of an automatic reset of the restriction and the start date of the next period.

After configuration of CDR collection service (Tariscope Observer), you should run it.

On this the restriction configuration is completed.

Configuration of scripts for CUCM

Due to the fact that the parameter control of Cisco Unified Communications Manager (CUCM) is performed via SSH, you should set a username and password that the script will use to connect to the CUCM command line interface. To configure the script, use the script editor built-in in Tariscope.

The script designed to change the subscriber access class for the CUCM located in the relevant folder:

\Scripts\CUCM\limiting-subscriber-setcos-ssh.vb

Configuration of scrips is executed in Tariscope Mangement -> Data collection/Observer -> a desired profile -> Configuration. In the appeared window of data collection, click on the Scripts button. In the Tariscope Observer scripts window, select a script for the event "Subscriber COS change". Click on the "..." button, and select the script file.

If you want to adjust the settings of the script, click Edit.

In the script, set connection settings to your CUCM:

Parameter	Description	Example of value
CUCM_HOST	IP server address of CUCM	10.10.1.123
CUCM_LOGIN	login to connect to CUCM	admin
CUCM_PASSWORD	Password	Password

It is recommended to save a customized script with a new name.

Save the script, and save the profile of data collection.

Configuration option for CUCM

Please note that the standard script supposes the use of a mechanism Calling Search Space (CSS). Therefore, the setting of "Restriction classes" in Tariscope should be carried out pointing out the names of the relevant CSS.

If necessary to use other methods, modify the SQL query in the script.

For example, if CUCM was configured to use Forced Authorization Code (FAC), change the SQL query as follows:

run sql update facinfo set authorizationlevel='{1}' WHERE name='{0}'

In this case you should specify levels of authorization codes in settings of the Restriction Class.

An example to view authorization codes: run sql SELECT * from facinfo

pkid name authorizationlevel code

==================================== ==== ================== ======

09d86b8a-52f7-d240-12de-5abfc73c7abe 2502 4 123

0c17b237-8a12-b481-6a56-73f8be0ef161 2501 11 2345

7a2ea379-1bdb-0a10-45c3-53836c071968 1512 7 433873

6ceac5f0-8ff2-940c-7149-0ecf56f8648c 1786 8 983933

You can configure the authorization codes as follows: Select Call Routing -> Forced Autorization Codes.

fac path In Tariscope, enter the authorization code in the "Service classes" mode:

fac list Set the access codes, as shown below:

fac route pattern

Administration and Monitoring

You can monitor the system by analyzing the Tariscope Observer log, as well as using the Restricted subscribers mode.

restricted subscribers.en

The mode displays a list of subscribers, for which the restrictions were applied. This mode allows you to view the restricted subscribers, sums of expenses, sums of limits for each category of each subscriber. You can open the subscriber editor, if it is necessary. Using the subscriber editor, you can set a restriction or clear it manually.

Licensing

The restriction feature is not included in the Tariscope base license and sold separately.