This document describes how to configure Call Detail Routing (CDR) on Cisco Call manager 11.5 (CCM).
Cisco recommends that you have knowledge of this topic:
Cisco Unified Communications Manager (CUCM) version 11.5
The information in this document is based on CCM version 11.5
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
CUCM produces two types of records, which store call history and diagnostic information, as follows:
Call Detail Records- Data records contain information about each call which is processed by CallManager.
Call Management Records - Data records 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 to generate the billing records; however, it can also be used to track call activity, diagnose certain types of problems and capacity plan.
CDRs contain information about call origination, call destination, the date and time on which 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.
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.
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. However, 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).
Generates alarm if the delivery is failed, or disk usage too high.
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
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.
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 to deliver 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:
Allowed CDRonDemandget_file Queries Per Minute (Min:1, Max:20, Default: 10)
Allowed CDRonDemandget_file_list Queries Per Minute (Min:1, Max:40, Default: 20)
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 count = 8, file count = 0
trans - Files are received from CM node.
tmp - Files wait 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 the files which are needed to be processed by the CDR Loader.
Understand Preserve and Processed Directories
In regular work scenarios:
Once CDR Agent on the node runs, 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 are 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 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 continue to remain in the preserve location until both operations are completed, i.e. until both CDR Load and transfer 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.
If you are troubleshooting any CDR data for 17th July 2018 , then you may want to check whether the corresponding files exist in preserve directory or processed directory.
To check whether preserve directory contains files:
file list activelog /cm/cdr_repository/preserve/20180717
To check whether processed directory contains files :
file list activelog /cm/cdr_repository/processed/20180717
To better understand the service interaction, assume there are two servers in the cluster, Publisher and Subscriber. Assume CallManager service runs 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 are deleted.
If billing servers are configured, then CDR Repository Manager service on the Publisher transfers 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 inserts 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 to transfer 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 transfers the flat files to the cdr_repository directory structure on the Publisher.
Enable CDR and navigate to System > Service Parameter > Call Manager Service. Set the CDR Enabled Flag to True. This has to be done for all the nodes in the server.
Enable CMR and navigate to System > Service Parameter > Call Manager 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 cluster wide parameter.
Cluster ID: This parameter provides a unique identifier for the cluster because the parameter gets used in CDRs, collections of CDRs from multiple clusters, which 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 these characters: A-Z, a-z, 0-9,
Note: CDR configuration is done and these additional Steps are required to send CDR files to SFT server.
Now add SFTP server/Billing Server where the files are to be sent. Navigate to Cisco Unified Serviceability > Tools > CDR Management and add new billing server.
In order to create schedule to send CDR records, navigate to Tools > CDR Analysis and Reporting and then to System > Scheduler > CDR Load.
Disable Loading - In order 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 has to be performed (loader should be disabled prior to executing the purge operation). Stop and restart the CAR Scheduler service in order to make change take place immediately.
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.
In order to get report manually, navigate to CDR > Export CDR, as shown in the image:
The dates can be selected accordingly and you get the page, as shown in the image.
Click on the CDR Dump /CMR Dump to download the file. Also make sure that you uncheck Delete File so that the files are not permanantly deleted from CUCM
From Cisco Unified Serviceability, navigate to Tools > CDR Analysis and Reporting. The pop-up message provides an overview of the CDR configuration as well high level overview of number of records in CDR database.
Verify the calls from CDR > Search ( and use any of the option to track call).
Example: Under CDR Search by User Phone number, you can enter phone number and get the call details for that, as shown in the image.
From Cisco Unified Serviceability, navigate to Tools > CDR Analysis and Reporting). The pop-up message provides an overview of the CDR configuration as well high level overview of number of records in CDR database. The pop up also provided you with major error related to configuration.
For any error, try to restart these services :
CDR Repository manager
CAR Web Service
Soap- CDRonDemand Service
If the issue is still there please collect these logs :
Cisco CAR Scheduler
Cisco CAR Web Service
Cisco CDR Agent
Cisco CDr Repository Manager
Cisco Call Manager
For detailed troubleshooting, please refer to this link : https://supportforums.cisco.com/t5/collaboration-voice-and-video/troubleshooting-cdr/ta-p/3117504