Table Of Contents
Cisco Unified CallManager Call Detail Record Definitions, Release 5.1(3)
Configuring Cisco Unified CallManager CDR
Configuring CDR Service Parameters
Configuring CDR Enterprise Parameters
Cisco Unified CallManager CDR Overview
Types of Call Information Records
Calls with Busy or Bad Destinations
Two types of conference linking exist:
Immediate Divert (to Voice Messaging System)
Original Calling Party on Transfer
Interpreting Cisco Personal Assistant Data in the CDRs
Personal Assistant Direct Call
Personal Assistant Interceptor Going to Media Port and Transferring the Call
Personal Assistant Interceptor Going Directly to Destination
Personal Assistant Interceptor Going to Multiple Destinations
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)
Personal Assistant Conferencing
Normal Calls (IP Phone to IP Phone)
Calls With Busy or Bad Destinations (Unsuccessful Calls)
Examples of Unsuccessful Calls
Immediate Divert (to Voice-messaging System)
Forced Authorization Code (FAC)
CMR Field Descriptions (Diagnostic)
Obtaining Documentation, Obtaining Support, and Security Guidelines
Cisco Unified CallManager Call Detail Record Definitions, Release 5.1(3)
This document describes the format and logic of the call detail records (CDRs) and call management records (CMRs) that the Cisco Unified CallManager Release 5.0 (and later) system generates. You can use this information for post-processing activities such as generating billing records and network analysis. This document describes how to access the CDR/CMR files and how to interpret fields in the files.
When you install your system, the system enables CDRs by default. CMRs remain disabled by default. You can enable or disable CDRs or CMRs at any time that the system is in operation. You do not need to restart Cisco Unified CallManager for the change to take effect. The system responds to all changes within a few seconds. The system enables CMRs (diagnostic data) separately from CDR data.
Contents
This document covers the following topics:
•
Configuring Cisco Unified CallManager CDR
•
•
•
•
New and Changed Information
The Release Notes for the corresponding release of Cisco Unified CallManager describe new features or changes for CDRs/CMRs that are pertinent to a specified release.
Configuring Cisco Unified CallManager CDR
CDR Analysis and Reporting (CAR) comprises a group of complementary services, which you can activate in the Service Activation window in Cisco Unified CallManager Serviceability. Before you can launch CAR from the Tools menu in Cisco Unified CallManager Serviceability, you must activate the CAR services by using the following procedure.
Procedure
Step 1
The Service Activation window displays.
Step 2
The window displays the service names for the server that you chose, the service type, and the activation status of the services.
Note
Step 3
•
•
Tip
Step 4
You must also configure certain CDR service and enterprise parameters:
•
•
Additional Information
See the "Getting Started With CDR Reporting And Analysis" chapter in the Cisco Unified CallManager CDR Reporting and Analysis Reporting Tool Administration Guide for additional information.
Configuring CDR Service Parameters
CAR relies on the data in the CDR and CMR records to generate both CAR and CDR reports. CAR requires that the CDR records be available in flat files on the CDR Repository node (the first node). Even if you do not use the CAR and CDR reporting services, you must enable certain Cisco Unified CallManager service parameters to ensure that CDR records are generated, and are generated in the manner that you can use for your particular system.
You can configure these parameters in the Service Parameters Configuration window in Cisco Unified CallManager Administration. To access the Service Parameters Configuration window, open Cisco Unified CallManager Administration and choose System > Service Parameters. Choose the Advanced button to display the complete list of Service Parameters. The following list of service parameters can affect CDR/CMR records:
•
–
–
•
–
–
–
•
–
Configuring CDR Enterprise Parameters
Configure these CDR parameters on the Enterprise Parameters Configuration window in the Cisco Unified CallManager Administration. To access Enterprise Parameters Configuration windows, open Cisco Unified CallManager Administration and choose System -> Enterprise Parameters.
•
–
–
•
–
–
CDR Processing
Cisco Unified CallManager generates two different types of call information records: CDRs and CMRs. The CDR records store information about a call. The CMR records store information about the quality of the streamed audio of the call. The CDR records relate to the CMR records by way of two GlobalCallID columns: Global CallID callManagerId and GlobalCallID Called. Depending upon the call scenario, more than one CMR may exist for each CDR.
When Cisco Unified CallManager places or receives a call, the system generates a CDR record when the call terminates. The system writes the CDR to a flat file (text file). Inside the Cisco Unified CallManager, the Call Control process generates CDR records. The system writes records when significant changes occur to a given call, such as ending the call, transferring the call, redirecting the call, splitting the call, joining a call, and so forth.
When CDR records are enabled, Call Control generates one or more CDR records for each call. The system sends these records to EnvProcessCdr, where they are written to the flat files. The number of records that are written varies by type of call and the call scenario. When Diagnostics are enabled, the device generates CMR records for each call. The system writes one CMR record for each IP phone that is involved in the call or for each Media Gateway Control Protocol (MGCP) gateway. The system also sends these records to EnvProcessCdr where they get written to flat files.
The Cisco Unified CallManager generates CDR and CMR records but does not perform any post processing on the records. The system writes the records to comma-delimited flat files and periodically passes them to the CDR Repository. The CDR and CMR files represent a specific filename format within the flat file.
Filename Format
The following example shows the full format of the filename:
tag_clusterId_nodeId_datetime_seqNumber
•
•
•
•
•
Two examples of filenames follow:
•
•
Flat File Format
The CDR and CMR flat files have the following format:
•
•
•
•
The following example shows a flat file:
Line1-"cdrRecordType","globalCallID_callManagerId","globalCallID_callId","origLegCallIdent ifier",...Line2-INTEGER,INTEGER,INTEGER,INTEGER,...Line3-1,1,388289,17586046,...Line4-1,1,388293,17586054,...
Note
Cisco Unified CallManager CDR Overview
The following sections provide a brief description of how CDRs are generated and managed in Cisco Unified CallManager:
•
CDR Management
The CDR Management (CDRM) feature, a background application, supports the following capabilities:
•
•
•
•
•
•
•
•
CDRM comprises two default services, the CDR Agent and the CDR Repository Manager, and one activate service, CDR onDemand Service.
CDR Agent
As part of the CDRM feature, a resident component on every node within a Cisco Unified CallManager cluster acts as the CDR Agent. On a node where both Cisco Unified CallManager and the CDR Agent are running, Cisco Unified CallManager writes the CDRs into CDR flat files (CSV format) with a special control character ("_") that is prefixed to the filename by the call-processing module and indicates that the file is not available for transfer. If this control character is not present, the system assumes the file to be available for transfer and sends the file to the designated CDR Repository node. Upon successful transfer, the system deletes the local copy of the file.
Reliability gets the highest priority for the CDRM feature. CDRs comprise very important financial data, so the goal of this feature is to guarantee that no CDR is lost. The Cisco Unified CallManager nodes within a cluster continuously write CDRs to flat files, close existing flat files, and open new ones. The number of records that are written varies by the type of call and significant changes that occur during a call, such as ending the call, transferring the call, redirecting the call, splitting the call, or joining the call.
The CDR Agent periodically polls the files in a designated path (/var/log/active/cm/cdr, which is a softlink to /common/log/cdr), every 6 seconds to determine whether a CDR file is available for transfer to the CDR Repository node. Having a short interval provides an advantage because as soon as a file is available, the system can deliver it immediately to the CDR Repository node.
The CDR Agent uses a standard SFTP utility, sftp_connect.sh, to transfer CDR files from the Cisco Unified CallManager nodes to the CDR Repository node. The utility requires a batch file as input and generates a log file that indicates the results of the requested actions. The CDR Agent creates unique batch and log files for each transfer session.
In case of an SFTP failure, the component on Cisco Unified CallManager repeatedly tries to make new connections until successful. When CDR files are accumulated due to a lack of an SFTP connection, the system sends all leftover CDR files to the CDR Repository node immediately after connectivity is restored.
When the CDR Agent starts or restarts, it checks whether any CDR files remain from the previous life cycle and sends them over to the CDR Repository node.
Should SFTP fail to transfer CDR files to the CDR Repository node, the system raises an alarm.
CDR Repository Manager
Within a Cisco Unified CallManager cluster, one instance of the CDR Repository Manager runs on the CDR Repository node. It manages CDR files that are received from the Cisco Unified CallManager nodes and periodically sends the files to the specified customer/third-party billing servers via an (s)FTP connection.
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 indicated by the UTC timestamp placed in the file name when the file was created.
If any external billing server is specified in CDRM configuration, the system creates a soft link to the file that is created in a directory that is designated to the destination. The file sender component of the CDR Repository Manager detects this soft link and sends the file to the destination with the specified method, either SFTP or FTP. If the delivery is successful, the system removes the soft link in the destination directory.
Every Cisco Unified CallManager node can generate one CDR file and one CMR file every minute for up to 1 hour. You can configure the maximum disk space that is used for storage of CDR files on the CDR Repository node through provisioning.
The File Manager component of the CDR Repository Manager runs hourly. When the File Manager runs, it deletes files with dates outside the configured preservation duration. It also checks whether disk usage has exceeded the high water mark. If so, the system deletes the processed CDR files until the low water mark is reached, starting with the oldest files. However, if any CDR file to be deleted was not successfully sent to the specified billing server, the system leaves it in the CDR Repository, and raises a notification or alarm. The system creates a flag file during the configured maintenance window, which denies access to the CDR files for the CDR onDemand Service. The system removes the flag file after the maintenance window expires.
For detailed procedures on how to configure the CDR Repository Manager and customer billing servers, see the "CDR Repository Manager Configuration" chapter in the Cisco Unified Serviceability Administration Guide.
CDR onDemand Service
The CDR onDemand Service, a SOAP/HTTPS-based service, runs on the CDR Repository node. It receives SOAP requests for CDR file name lists 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. The system prohibits service during the maintenance window. For detailed information on the CDR onDemand Service, see the Cisco Unified CallManager Developers Guide for Release 5.1(3).
Types of Call Information Records
Cisco Unified CallManager generates two different types of call information records: Call Detail Records (CDRs) and Call Management Records (CMRs). CDRs store information about the endpoints of the call and other call control/routing aspects. CMRs contain diagnostic information about the quality of the streamed audio and/or video of the call. More than one CMR can exist per CDR.
The CDRs relate to the CMRs via the two globalCallID columns:
•
•
When the Call Diagnostics Enabled service parameter is set to True, the system generates up to two CMRs for each call. Each type of call, such as conference calls, call transfers, forwarded calls, and calls through gateways, produce a set of records that get written to ASCII files at the end of the call. Only completed calls and failed calls generate CDRs and CMRs. Cisco Unified CallManager does not perform any post processing on CDRs or CMRs.
This section contains the following topics:
Global Call Identifier
Cisco Unified CallManager allocates a global call identifier (GlobalCallID) each time that a Cisco Unified IP Phone is taken off hook or a call is received from a gateway.
The CDR table (Table 1) lists CDRs that are written at the end of a call in the order that they are written. GlobalCallIDs for active calls do not appear in the CDR table. Other global IDs also may not appear in the CDR table. For example, each call leg in a conference call gets assigned a GlobalCallID that the conference GlobalCallID overwrites. The original GlobalCallID does not appear in the CDR.
Table 1 Sample CDR Table
1
973795815
973795820
2
973795840
973795845
5
973795860
973795870
4
973795850
973795880
The CDR table does not contain an entry for GlobalCallID 3 because that call was active when this record was taken. The table shows GlobalCallID 5 listed before GlobalCallId 4 because the GlobalCallID 5 call ended before the GlobalCallID 4 call ended.
Number Translations
The Cisco Unified CallManager can perform translations on the digits that a user dials. The translated number, not the actual dialed digits, appears in the CDR.
For example, many companies translate "911" calls to "9-911," so the caller does not need to dial an outside line in an emergency. In these cases, the CDR contains "9911" even though the user dials "911."
Note
Partitions and Numbers
Within a CDR, a combination of extension number and partition identifies each phone that is referenced, if partitions are defined. When partitions exist, fully identifying a phone requires both values because extension numbers may not be unique.
The Partition field stays empty when a call ingresses through a gateway. When a call egresses through a gateway, the Partition field shows the partition to which the gateway belongs.
If the dial plan allows callers to use the # key for speed dialing, the # key goes into the database when it is used. For example, the Called Party Number field may contain a value such as "902087569174#."
In this release, the Party Number fields may include SIP URIs instead of the traditional calling/called party number.
CDRs use the Partition/Extension Numbers that are shown in Table 2:
Timestamps
Timestamps within a CDR appear in Universal Coordinated Time (UTC). This value remains independent of daylight saving time changes.
Unsigned 32-bit integers represent all time values. This unsigned integer value displays from the database as a single integer. The field specifies a time_t value that is obtained from the operating system.
The CDR includes the UTC timestamps that are shown in Table 3:
Call Termination Cause Codes
The CDR includes two call termination cause codes: OrigCause and DestCause. When the originating party releases the call, the OrigCause gets populated. When the terminating party releases the call, or the call is rejected, the DestCause gets populated. When unpopulated, the termination cause code value shows zero.
The "Call Termination Cause Codes" section lists the call termination cause code values per ITU specification Q.850. For On Net call legs, the Cisco Unified CallManager determines the call termination cause code value. For Off Net call legs, the far-end switch determines the call termination cause code value.
IP Addresses
The system stores IP addresses as unsigned integers. The CDR file displays IP addresses as signed integers. To convert the signed decimal value to an IP address, first convert the value to a hex number, taking into consideration that it is really an unsigned number. The 32-bit hex value represents four bytes in reverse order (Intel standard). To determine the IP address, reverse the order of the bytes and convert each byte to a decimal number. The resulting four bytes represent the four-byte fields of the IP address in dotted decimal notation.
Note
For example, the IP address 192.168.18.188 displays as -1139627840. To convert this IP address, perform the following procedure:
Step 1
The hex value equals 0xBC12A8C0.Step 2
CO A8 12 BCStep 3
192 168 18 188Step 4
192.168.18.188When working with CDRs, you may want to read other tables in the CAR database to obtain information about the type of device in each CDR because the correlation between devices in the Device table and the IP address that is listed in the CDR is not straightforward.
Call Types
A successful call between two parties logs one CDR. Each CDR contains all fields, but some fields may not get used. If a field is not used, see the default values in the CDR definitions table. When supplementary services are involved in a call, additional CDRs may be written.
In addition to the CDR, a call may involve one CMR per endpoint. In a successful call between two parties who are each using an IP phone, the system writes two CMRs: one for the originator and one for the destination of the call.
This section describes the records that are written for different call types in the system.
•
•
•
•
Successful On-Net Calls
A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.
The following table contains two examples:
•
•
A
2001
Accounts
2309
Marketing
16
0
60
B
2001
Accounts
2309
Marketing
0
16
60
Abandoned Calls
The logging of calls with zero duration represents an optional action. If the CDR Log Calls With Zero Duration Flag service parameter is enabled, the following actions occur:
•
•
•
Abandoned Calls CDR Examples
The following table contains two examples:
•
•
A
2001
Accounts
16
0
0
B
2001
Accounts
2309
16
0
0
Calls with Busy or Bad Destinations
The system logs these calls as a normal call with all relevant fields containing data. The Calling or Called Party Cause fields contain a cause code that indicates why the call was not connected, and the Called Party IP and Date/Time Connect fields remain blank. The system logs all unsuccessful calls, even if zero duration calls are not being logged (the CDR Log Calls With Zero Duration Flag set at True or False, a duration of zero, and a DateTimeConnect value of zero).
Calls with Busy or Bad Destinations CDR Examples
The following table contains three examples:
•
•
•
Short Calls
A short call, with a CDR Log Calls With Zero Duration Flag set at True and a duration of less than 1 second, appears as a zero duration call in the CDR. The DateTimeConnect field, which shows the actual connect time of the call, differentiates these calls from failed calls. For failed calls (which never connected), this value equals zero.
Short Call CDR Example
The following table contains an example of a successful On Net call with a duration of less than 1 second that the called party cleared.
2001
Accounts
2309
Marketing
0
16
973795815
0
Forwarded or Redirected Calls
Forwarded calls generate a single CDR and show the Calling Party, Original Called Number, Last Redirecting Number, Final Called Number, and the associated partitions. If the call is forwarded more than twice, the intermediate forwarding parties do not populate in the CDR.
Call forwarding can occur on several conditions (always, on busy, and on no answer). The condition under which the call is forwarded does not populate in the CDR.
The CDRs for forwarded calls match those for normal calls, except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields contain the directory number and partition for the destination that was originally dialed by the originator of the call. If the call gets forwarded, the finalCalledPartyNumber and finalCalledPartyNumberPartition fields differ and contain the directory number and partition of the final destination of the call.
Also, when a call is forwarded, the lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that forwarded or redirected the call.
Forward or Redirected Call CDR Examples
The following table contains two examples:
•
•
Pickup Calls
Cisco Unified CallManager includes two pickup modes: Pickup and Auto Pickup. The following sections describes these calls:
Pickup
Pickup calls work like forwarded calls. The CDRs for pickup calls match those for normal calls except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields contain the Directory Number and partition for the destination that was originally dialed by the originator of the call.
If the call is picked up, the finalCalledPartyNumber and finalCalledpartyNumberPartition fields will differ and contain the Directory Number and partition of the phone that picked up the call. Also, when a call is picked up, the lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that redirected this call.
The origTermination, destTermination, lastRedirect, and Join OnBehalfOf fields contain 16 (Pickup) and the redirect reason field contains 5 (Pickup).
Pickup CDRs look the same for all types of pickup: Pickup, Group Pickup, and Other Pickup.
Pickup Call CDR Example
1.
2.
3.
Auto Pickup
Auto Pickup works like call pickup with auto answer. The call connects automatically, so no need exists for the last answer softkey press. The system generates two CDRs for Auto Pickup, and these CDRs have the same Call ID.
The system generates the first CDR for the original call. This CDR will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields equal to 16 (Pickup), which indicates that the call terminated on behalf of the pickup feature.
The second CDR represents the final call after it was picked up. This CDR will have the lastRedirectOnBehalfOf and the joinOnBehalfOf fields set to 16 (Pickup), which indicates that the system joined the call on behalf of the Pickup feature. The lastRedirectReason contains the redirect reason of 5 (Pickup).
Auto Pickup CDRs look the same for all types of auto pickup: Auto Pickup, Auto Group Pickup, and Auto Other Pickup.
Auto Pickup Example
1.
2.
3.
Transferred Calls
A single CDR cannot show all the data necessary for a call transfer because it is too complex. Each time a call is transferred, the Cisco Unified CallManager terminates the CDR for that call and initiates a new CDR.
Calls that are transferred have multiple CDRs logged for them, as follows:
1.
2.
3.
The first CDR represents the original placed call. The second CDR represents the setup call (consultative/announcement) that is used to initiate the transfer. The third CDR represents the transferred call itself. The first two CDRs have the origCause_value and destCause_value set to Split (126).
They also have the origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields set to Transfer (10) to indicate that these calls were involved in a transfer. The transferred leg of the call has the joinOnBehalfOf field set to Transfer (10) to indicate that this call resulted from a transfer; therefore, all legs of the transfer can be tied back to a single call.
Transferred Calls CDR Examples
The following examples do not comprise an exhaustive set, and are intended to illustrate the records that would be generated under the stated circumstances. These examples help clarify what records are generated on transferred calls.
Example 1
A calls B; A transfers B to C. The three logged calls follow:
1.
2.
3.
If the call was a blind transfer, the call from A to C will have a duration of zero seconds. If the call was a consultation transfer, all calls will have non-zero durations. Original Called Party and Call Party Number fields match.
Example 2
A calls B; B transfers A to C. The three logged calls follow:
1.
2.
3.
If the call was a blind transfer, then the call from B to C will have a duration of zero seconds. If the call was a consultation transfer, then all calls will have non-zero durations. Original Called Party and Call Party Number fields match.
Example 3
A calls B; B transfers A to C on a blind transfer. C is Call Forwarded on No Answer to D. The calls that are logged follow:
1.
2.
3.
Because the call was a blind transfer, the call from B to C has a duration of zero seconds. The call from A to D will have the Original Called Party field set to "C", and the Called Party Number field set to "D".
Transfer Without Consultation
The process of transferring a call, without consultation, involves the creation of three CDRs. The first CDR reflects the call between the original two parties (A and B), the second CDR represents the (zero length) call between the transferring party (A) and the new party (C), and the final CDR reflects the call between B and C.
No CDR reflects the time that a call is on hold. If a call is through a PSTN gateway, the call accrues charges that are not reflected in the CDRs while the call is on hold.
Guest
