What is CDR, CMR ?

Posted on by Admin

Related Post

Overview

This document is applicable to the appliance model of Cisco Unified Communications Manager (i.e. CUCM version 5.x and later).

What is CDR, CMR ?

Cisco Unified Communications Manager produces two types of records which store call history and diagnostic information, as follows:

  • Call detail records (CDR)— Data records that contain information about each call that was processed by CallManager.
  • Call management records (CMR)— Data records that contain quality of service (QoS) or diagnostic information about the call. Also referred to as diagnostic records.

Both CDRs and CMRs together are referred to as CDR data. CDR data provides a record of all calls that have been made or received by users of the CallManager system. CDR data is useful primarily for generating billing records; however, it can also be used for tracking call activity, diagnosing certain types of problems and capacity planning.

CDRs contain information about call origination, call destination, the date and time the call was started, the time it actually connected, and the time it ended. A call is considered started or originated when the caller goes off-hook. The call is considered ended when either the caller or the called party goes on-hook. CMRs contain information about the amount of data sent and received, jitter, latency, and lost packets.

Logging Calls With Zero Duration

A CallManager service parameter called ‘CDR Log Calls with Zero Duration Flag’  determines whether CDRs for calls that were never connected or were connected for less than a second are generated. Examples:

  • When a user goes off-hook and then on-hook without completing a call.
  • When a user completes a blind transfer (the consultation call does not connect).
  • MWI On/Off calls.

Note:

The CDR Log Calls with Zero Duration Flag service parameter is valid only when the CDR Enabled Flag service parameter is set to True. If CDR generation is disabled, the setting of the CDR Log Calls with Zero Duration Flag service parameter has no significance.

CallManager always generates CDR data for calls that have a duration of 0 seconds and terminate because of an error condition of some sort, regardless of the setting of the CDR Log Calls with Zero Duration Flag service parameter. Calls to busy destinations or bad phone numbers are examples of this type of call. The duration of these calls is 0 because they were never connected, but their CDRs are generated anyway.

CallManager does not generate CDRs for calls that terminate normally and have a duration of 0 seconds, unless the CDR Log Calls with Zero Duration Flag service parameter is set to True. When CDR generation is enabled, CallManager generates a CDR for each call that was connected for 1 second or more.

Configuration

Enabling CDR

  • Enabled via CallManager service parameters.
         Under System -> Service Parameters
Select a server from the drop down box and then select the CallManager service
Set the ‘CDR Enabled Flag’ to True
  • Needs to be enabled per server basis.
  • The default value specifies False

Enabling CMR

  • Enabled via CallManager service parameters

Under System -> Service Parameters

Select a server from the drop down box and then select the CallManager service

Set the ‘Call Diagnostics Enabled’ parameter to either:

  • Enabled Only When CDR Enabled Flag is True (generate CMRs only when the CDR Enabled Flag service parameter is set to True).

—- or —-

Enabled Regardless of CDR Enabled Flag (generates CMRs without regard to the setting in the CDR Enabled Flag service parameter).

  • This is a clusterwide parameter.
  • The default value specifies Disabled.

Enterprise Parameters

Under System -> Enterprise Parameters, there are two parameters related to CDR:

CDR File Time Interval

This parameter specifies the time interval for collecting CDR data. For example, if this value is set to 1, each file will contain 1 minute of CDR data (CDRs and CMRs, if enabled). The CDR database will not receive the data in each file until the interval has expired, so consider how quickly you want access to the CDR data when you decide what interval to set for this parameter. The minimum value is 1 (which is also the default). Maximum is 1440. The unit of measure for this required field represents a minute.

Cluster ID

This parameter provides a unique identifier for the cluster. Because the parameter gets used in CDRs, collections of CDRs from multiple clusters can be traced to the sources.The default value specifies StandAloneCluster. The maximum length comprises 50 characters andprovides a valid cluster ID that comprises any of the following characters: A-Z, a-z, 0-9, . -.

Architecture

Architecture.JPG

Services

CallManager

Can be activated on any node in the cluster.
Performs call processing and writes CDR, CMR data into flat files.
The flat files are generated at a frequency determined by the ‘CDR File  Time Interval’ flag under Enterprise Parameters.

CDR Agent

Runs as a network service on every node in a cluster (including the Publisher).

It polls the local directory for CDR, CMR flat files every 6 seconds.
If finds new CDR, CMR flat files, it pushes CDR, CMR flat files from that  node to the CDR Repository node (Publisher).
Upon successful transfer, the system deletes the local copy of the file.

CDR Repository Manager

It runs as a Network Service on all nodes in a cluster. But, in reality only the CDR Repository Manager on the Publisher performs any actions. On all other nodes, the service simply starts up, but then goes to sleep.
It creates the directory structure used by CAR services.
It manages the flat files that are received from other nodes. When the file arrives on the CDR Repository node, the CDR Repository Manager detects it.The system archives the file in a directory that is dedicated to the date that is indicated by the timestamp that was placed in the file name when the file was created.
Sends CDR files up to three outside billing servers.
Maintains CDR files for a certain number of days, up to 30 days.
Periodically check the disk usage and delete old files. The thresholds are configured using the CDR Management (covered later in the presentation).
Generate alarm if delivery failed, or disk usage too high.

CAR Scheduler

It runs as a Network Service on all nodes in a cluster. But, in reality only the CAR Scheduler service on the Publisher performs any actions. On all other nodes, the service simply starts up, but then goes to sleep.
Based on the CDR loading schedule, it accesses the CDR/CMR files in the directory structure that the CDR Repository Manager service creates , processes these files and inserts the CDR information into the CAR database.
The maximum size of CAR database is 6 Gb (not configurable). The CAR Scheduler purges data from the CAR database if it exceeds 6 Gb or if the number of records exceed 2 million. The two million record limit includes data in both tbl_billing_data and tbl_billing_error.

CAR Web Service

Can only be activated on the Publisher.
Runs as a feature service (Control Center – Feature Services).
It needs to be running in order to access the CDR Analysis and Reporting (CAR) tool.

SOAP – CDRonDemand Service

The CDRonDemand Service is a SOAP/HTTPS-based service that runs on the CDR Repository node (i.e. Publisher).
It receives SOAP requests for CDR file name lists from a third-party server based on a user-specified time interval (up to a maximum of 1 hour) and returns all lists that fit the duration that the request specifies.
The CDR onDemand Service can also handle requests for delivering a specific CDR file to a specified destination through (s)FTP. The system can activate the CDR onDemand service on the CDR Repository node as it has to access the CDR files in the repository.
There are two relevant parameters under System -> Enterprise Parameters that are used to throttle requests from the third party server:
  1. Allowed CDRonDemand get_file Queries Per Minute (Min:1, Max:20, Default: 10)
  2. Allowed CDRonDemand get_file_list Queries Per Minute (Min:1, Max:40, Default: 20)

How CDR flat files are processed

We need to dig a bit deeper into the CDR Repository Manager Directory structure to understand how CDR flat files are handled.

CDR Repository Manager Directory Structure

The CDR Repository Manager Directory Structure as described below exists only on the Publisher.

Everything under /var/log/active/cm/cdr_repository

admin:file list activelog /cm/cdr_repository

<dir>   car

<dir>   destination1

<dir>   destination2

<dir>   destination3

<dir>   preserve

<dir>   processed

<dir>   tmp

<dir>   trans

dir count = 8, file count = 0

admin:

trans – files being received from CM node

tmp – files waiting to be processed

preserve/yyyymmdd – files to be sent out and/or to be loaded by CAR

processed/yyyymmdd – files successfully sent to all destinations and loaded by CAR (if CAR is not activated and no billing server is configured, files are put here directly)

destinationX/yyyymmdd – contains symbolic links to files under preserve. CDR Repository Manager service uses these soft-links to determine what files need to be transfered to billing server.

car/yyyymmdd – contains symbolic links to files under preserve. CAR Scheduler service uses these soft-links to determine what files need to be processed by the CDR Loader.

Understanding ‘preserve’ and ‘processed’ directories

In regular working scenarios:

Once CDR Agent on the node running the CallManager service sends the files to the Publisher, they are stored in the ‘preserve/yyyymmdd’ directory on the Publisher. If CAR is activated, symbolic links will be created to these files in the ‘car/yyyymmdd’ location. If billing servers are configured, symbolic links to these files will also be created in the ‘destinationX/yyyymmdd’ location (where X can be 1,2,3 — since at most 3 billing servers can be configured).

The files will remain in the ‘preserve’ location until CDR Loader processes these files and enters corresponding records into the CDR database. Once the CDR files are processed, they are moved to the ‘processed’ location.

In addition to CDR Loading being enabled, if Billing Servers are configured, the CDR files will continue to remain in the ‘preserve’ location until both operations are completed — i.e. until both CDR Loading and transfering file to the billing server are completed.

Hence, in typical working scenarios, all the CDR flat files will in the ‘processed’ location as opposed to the ‘preserve’ location. This signifies that all operations for those files have been completed.

Example:
If you are troubleshooting any CDR data for Jan 5th, then you may want to check whether the corresponding files exist in preserve directory or processed directory.
To check whether preserve directory contains files for Jan 5th, use following command on the Publisher:
  file list activelog /cm/cdr_repository/preserve/20110105
To check whether processed directory contains files for Jan 5th, use following command on the Publisher:
  file list activelog /cm/cdr_repository/processed/20110105

Service Interaction

To better understand the service interaction, assume there are two servers in the cluster – one Publisher and one Subscriber. Assume CallManager service is running only on the Subscriber. Here’s how CDR, CMR files are managed:

  • CallManager service on the Subscriber generates CDR/CMR flat files locally.
  • CDR Agent service on the Subscriber transfers these files to the cdr_repository directory structure on the Publisher. Once the transfer is complete, the local copy of these files on the Subscriber is deleted.
  • If billing servers are configured, then CDR Repository Manager service on the Publisher will transfer these flat files to the billing servers.
  • If “Continuous Loading 24/7” is enabled (in the CDR Analysis and Reporting tool), then CAR Scheduler service on the Publisher will insert the call information in the flat files into the CAR database on the Publisher.

Note:

– For every node that runs the CallManager service, the CDR Agent service on that node is responsible for transfering the flat files to the cdr_respository structure on the Publisher. If the CallManager service runs on the Publisher as well, then the CDR Agent service on the Publisher will transfer the flat files to the cdr_repository directory structure on the Publisher.

Billing Servers

The system can send CDR files to up to three preconfigured destinations (billing servers) using FTP/SFTP. The CDR Repository Manager on the Publisher is responsible for transferring the CDR files to the billing servers.

Cisco allows you to use any SFTP server product but recommends SFTP products that have been certified with Cisco through the Cisco Technology Developer Partner program (CTDP). CTDP partners, such as GlobalSCAPE, certify their products with specified version of Cisco Unified Communications Manager. For information on which vendors have certified their products with your version of Cisco Unified Communications Manager, refer to the following URL:

http://www.cisco.com/pcgi-bin/ctdp/Search.pl

For information on using GlobalSCAPE with supported Cisco Unified Communications versions, refer to the following URL:

http://www.globalscape.com/gsftps/cisco.aspx

Cisco uses the following servers for internal testing. You may use one of the servers, but you must contact the vendor for support:

•Open SSH (refer to http://sshwindows.sourceforge.net/)\

•Cygwin (refer to http://www.cygwin.com/)

•Titan (refer to: http://www.titanftp.com/)

Configuration screenshots:

BillingServer.JPG

CDR Load Schedule

From Cisco Unified Communications Manager CDR Analysis and Reporting page, navigate to System > Scheduler > CDR Load as seen in the screenshot below:

System-Scheduler-CDRLoad.jpg

The following screen is displayed:

CDR Load.jpg

Disable Loading – To disable CDR data loading. Use this option if you do not want CDR data to be loaded into the CAR database. Changes take effect at midnight. You’ll also need to use this option if manual purge operation is to be performed (loader should be disabled prior to executing the purge operation). You can force the change to take effect immediately by stopping and restarting the CAR Scheduler service.

Continuous Loading 24/7 – Enables the CDR Loader to run continuously 24 hours a day, 7 days a week to load CDRs into the CAR database. This choice represents the default setting for the CDR Load Scheduler.

Note : If this option is chosen, it takes precedence over and ignores the other CDR and CMR load parameters on the screen, such as Time, Loading Interval, Duration, and Uninhibited Loading.

Load CDR Only – Check this box to load only CDR records into the CAR database. With this option, CMR records do not load into the CAR database. This choice represents the default setting for the CDR Load Scheduler. You must manually uncheck the Load CDR only check box to force the CMR records to load with the CDR records.

Useful Links/References

  • Please refer to the ‘Cisco Unified CDR Analysis and Reporting Administration Guide’ for the appropriate release for additional information. To access the document:

— Navigate to: http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

— Search for ‘Cisco Unified CDR Analysis and Reporting Administration Guide’ for the appropriate CUCM release