Table Of Contents
Cisco Unified CallManager 5.0 Call Detail Record Definitions
Cisco Unified CallManager CDR Configuration
Cisco Unified CallManager CDR Overview
Types of Call Information Records
Calls with Busy or Bad Destinations
Immediate Divert (to Voicemail)
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 Conferencing
Normal Calls (IP Phone to IP Phone)
Calls With Busy or Bad Destinations (Unsuccessful Calls)
Examples of Unsuccessful Calls
Immediate Divert (to Voicemail)
Forced Authorization Code (FAC)
CMR Field Descriptions (Diagnostic)
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Cisco Unified CallManager 5.0 Call Detail Record Definitions
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. An integration partner 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, how to interpret fields in the files, and some of the known issues.
When you install your system, CDRs and CMRs are disabled by default. You can enable or disable CDRs or CMRs at any time 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.
Contents
This document covers the following topics:
•
Cisco Unified CallManager CDR Configuration
•
•
•
•
•
•
New and Changed Information
New features or changes for CDRs/CMRs that are pertinent to a specified release of Cisco Unified CallManager are described in the Release Notes for the corresponding release.
Note
Cisco Unified CallManager CDR Configuration
The following sections define the current CDR configuration parameters.
Service Parameters
These values are set to False by default. You must enable these configuration items separately on every server in a cluster. You can configure these parameters on the Service Parameters Configuration page in the Cisco Unified CallManager Administration. To access the Service Parameters Configuration page, open Cisco Unified CallManager Administration and select Service -> Service Parameters.
•
•
•
Enterprise Parameters
You can configure these parameters on the Enterprise Parameters Configuration page in the Cisco Unified CallManager Administration. To access the Enterprise Parameters Configuration page, open Cisco Unified CallManager Administration and select System -> Enterprise Parameters.
•
•
Cisco Unified CallManager CDR Overview
This section provides a brief description of how CDRs are generated and managed in Cisco Unified CallManager. The changes and new features are described in the following subsections.
CDR Management
The CDR Management (CDRM) feature is a background application that supports the following capabilities:
•
•
•
•
•
CDRM consists of the CDR Agent, CDR Repository Manager, and CDR onDemand Service.
CDR Agent
As part of the CDRM feature, a resident component on every Unified CM node within a Cisco Unified CallManager cluster is the CDR Agent. On a Unified CM 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 ("_") prefixed to the filename by the call processing module to indicate that the file is not available for transfer. If this control character is not present, then the file is assumed to be available for transfer and is sent to the designated CDR Repository node. Upon successful transfer, the local copy of the file is deleted.
Reliability is given the highest priority for the CDRM feature. CDRs are 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 if a CDR file is available for transfer to the CDR Repository node. The advantage of having a short interval is that as soon as a file is available it can be delivered 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 indicating 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, all leftover CDR files will be sent to the CDR Repository node immediately after connectivity is restored.
When the CDR Agent starts or restarts, it checks whether there are any CDR files remaining 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, an alarm is raised.
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 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, as illustrated in Figure 1.
Figure 1 CDR Management Feature
When the file arrives on the CDR Repository node, the CDR Repository Manager detects it. The file is archived in a directory 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, a soft link to the file is created in a directory 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 soft link in the destination directory is removed.
CDRM supports a BHCC (Busy Hour Call Completion) rate of 60K on a single node. Every Cisco Unified CallManager node can generate one CDR file and one CMR file every minute for up to one hour. If there are 16 Unified CM nodes within a Cisco Unified CallManager cluster, then the minimum hard disk space requirement for the CDR Repository is 36GB. The maximum disk space used for storage of CDR files on the CDR Repository node is user-configurable through provisioning.
The File Manager component of the CDR Repository Manager is scheduled to run daily. When the File Manager runs, it deletes files with dates outside the configured preservation duration. It also checks if disk usage has exceeded the high water mark. If so, CDR files will be deleted until the low water mark is reached, starting with the oldest files. However, if any CDR file to be deleted has not been successfully sent to the specified billing server, it is left in the CDR Repository and a notification or alarm is raised. A flag file is created during the configured maintenance window, which denies access to the CDR files for third party billing applications and the CDR onDemand Service. The flag file is removed after the maintenance window has expired.
For detailed procedures for configuring the CDR Repository Manager and customer billing servers, see the "CDR Repository Manager Configuration" chapter in the Cisco Unified CallManager CDR Analysis and Reporting Administration Guide.
CDR onDemand Service
The CDR onDemand Service is a SOAP/HTTPS-based service that 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 one hour) and returns all lists fitting the time duration specified in the request.
The CDR onDemand Service can also handle requests for delivering a specific CDR file to a specified destination through (s)FTP. The CDR onDemand service can only be activated on the CDR Repository node as it has to access the CDR files in the repository. This service is prohibited during the maintenance window. For detailed information on the CDR onDemand Service, see the Cisco Unified CallManager Developers Guide for Release 5.0(4).
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 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.
Global Call Identifier
The 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 shown in Table 2:
Timestamps
Timestamps within a CDR appear in universal coordinated time (UTC), which is the number of seconds since midnight on January 1, 1970. 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 Linux OS.
The CDR includes the UTC timestamps shown in Table 3:
Call Release Cause Codes
The CDR includes two call release 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 release cause code value shows zero.
The "Call Release Cause Codes" section lists the call release cause code values per ITU specification Q.850. For on-net call legs, the Cisco Unified CallManager determines the call release cause code value. For off-net call legs, the far-end switch determines the call release cause code value.
IP Addresses
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 be 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, two CMRs are written: one for the originator and one for the destination of the call.
This section describes the records 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 logging calls with zero duration is enabled, the following actions occur:
•
•
•
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
These calls will all be logged as a normal call with all relevant fields containing data. The Calling or Called Party Cause fields contain a cause code indicating why the call was not connected, and the Called Party IP and Date/Time Connect fields are blank. All unsuccessful calls are logged, even if zero duration calls are not being logged (CdrLogCallsWithZeroDurationFlag set at True or False, a duration of zero, and a DateTimeConnect value of zero).
The following table contains three examples:
•
•
•
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.
The following table contains two examples:
•
•
Pickup Calls
Cisco Unified CallManager includes two pickup modes: Pickup and Auto Pickup. This section describes the CDRs for each mode.
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 Example
1.
2.
3.
Auto Pickup
Auto Pickup works like call pickup with auto answer. The call connects automatically so there is no need for the last answer softkey press. The system generates two CDRs for Auto Pickup, and these CDRs have the same Call ID.
The first CDR is generated 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 is the original placed call. The second CDR is the setup call (consultative/announcement) used to initiate the transfer. The third CDR is 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 this call resulted from a transfer. Therefore, all legs of the transfer can be tied back to a single call.
The following examples are not an exhaustive set, and are intended to illustrate the records that would be generated under the stated circumstances. This is intended to help clarify what records are generated on transferred calls.
Example 1
A calls B, A transfers B to C. The three calls logged are:
1.
2.
3.
If the call was a blind transfer, then the call from A 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 are the same.
Example 2
A calls B, B transfers A to C. The three calls logged are:
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 are the same.
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 logged are:
1.
2.
3.
Since the call was a blind transfer, then 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.
The following table contains three examples:
•
•
•
Transfer with Consultation
Transfer with consultation essentially acts identical to transfer without consultation, except the duration of the middle call is not zero.
As with a transfer without consultation, Cisco Unified CallManager creates three CDRs. The first CDR reflects the call between the original two parties (A and B), the second CDR represents the consultation call between the transferring party (A) and the new party (C), and the final CDR reflects the call between B and C.
The following table contains three examples:
•
•
•
Conference Calls
Two major operational factors exist for conference call CDRs:
1.
For example, if four people are connected in a conference call (Amy, Dustin, Spencer, Ethan), when Ethan hangs up three people remain in the conference call that is connected to the conference bridge (Amy, Dustin, Spencer). When Spencer hangs up, only two people remain in the conference call (Amy and Dustin). The system joins Amy and Dustin directly and the conference resource gets released. Directly joining Amy and Dustin creates an additional CDR between the last two parties in the conference.
2.
Comment field = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD"
•
•
Calls that are part of a conference have multiple records that are logged for them. The number of CDRs that are generated depends on the number of parties in the conference. One CDR exists for each party in the conference, one CDR for the original placed call, and one CDR for each setup call that is used to join other parties to the conference. Therefore, for a three-party ad hoc conference, six CDRs exist:
•
•
•
•
The setup calls can be associated with the correct call leg in the conference by examining the calling leg ID and the called leg ID.
The conference bridge device holds special significance to the Cisco Unified CallManager. Calls to the conference bridge appear as calls to the conference bridge device. A special number in the form "b0019901001" shows the conference bridge port. All calls get shown "into" the conference bridge, regardless of the actual direction. You can determine the original direction of each call by examining the setup call CDRs.
The call legs that are connected to the conference have the following values for these fields:
•
•
•
•
•
The original placed call and all setup calls that were used to join parties to the conference have the following values for the fields:
•
•
The following tables contain these examples:
•
•
•
•
•
•
Precedence Calls (MLPP)
Precedence calls take place the same as other calls except the precedence level fields get set in the CDR. Also, when a higher-level precedence call preempts a call, the cause codes indicate the reason for the preemption.
The following table contains an example CDR for this scenario:
•
•
•
•
Malicious Calls
When a call gets identified as a malicious call (button press), the local Cisco Unified CallManager network flags the call. The Comment field flags the malicious call.
The following table contains an example CDR of a customer call that gets marked as malicious.
9728552001
CUST
5555
ACNTS
0
16
"callFlag=MALICIOUS"
Conference Drop Any Party
The Conference Drop Any Party feature terminates calls that look the same as other calls except for a new cause code. The cause code identifies calls that get terminated by this feature.
The following table contains an example CDR for a call that was connected to a conference and dropped by this feature.
Guest
