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.
Note
Immediate Divert (to Voicemail)
CDRs for Immediate Divert calls take place the same as forwarded calls except values exist for origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf fields.
The following table contains an example CDR for this scenario:
Video Calls
The following table contains an example CDR for a video call for this scenario:
•
•
•
•
•
•
VideoCap_ Codec
VideoCap_Bandwidth
VideoCap_Resolution100
320
2
288625580
49254
Interpreting Cisco Personal Assistant Data in the CDRs
The Cisco Personal Assistant application can selectively handle incoming calls and assist with outgoing calls. This section provides a brief overview of Personal Assistant and describes the Personal Assistant call types with example CDR scenarios.
Personal Assistant provides the following features:
•
•
•
•
•
Personal Assistant Call Types
Personal Assistant provides the following call types:
•
•
•
•
Personal Assistant Direct Call
A Personal Assistant direct call acts similar to the Transfer without Consultation call type. See the "Transfer Without Consultation" section.
The following table contains an example CDR for this scenario:
•
•
Note
In all cases, 2101 specifies the calling number.
Personal Assistant Interceptor Going to Media Port and Transferring the Call
This scenario acts similar to Transfer without Consultation and Forwarded Calls. See the sections on "Transfer Without Consultation" and "Forwarded or Redirected Calls".
The following table contains an example CDR for this scenario:
•
•
•
.
Personal Assistant Interceptor Going Directly to Destination
This scenario can have two different cases: with no rules and with rules.
Personal Assistant Going Directly to Destination with No Rules
The following table contains an example CDR for this scenario:
•
•
The following table contains an example CDR for this scenario:
Personal Assistant Going Directly to Destination with Rule to Forward Calls to a Different Destination
The following table contains an example CDR for this scenario:
•
•
•
Multiple Destinations
This scenario can have several different cases. In each case, User B (2105) configured a rule to reach him at extension 2110 or 2120. This rule could activate when a caller calls Personal Assistant route point (2000) and says "call User B" (direct case) or when the caller dials User B (2105) directly (interceptor case).
The following sections contain examples of each case. The tables contain example CDRs for each of these scenarios:
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)
•
•
•
Note
Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)
•
•
Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)
•
•
Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)
•
•
•
Note
Personal Assistant Conferencing
Personal Assistant conferencing acts similar to the Ad Hoc Conferences call type. For more information, see the "Conference Calls" section.
The following table contains an example CDR for this scenario:
•
•
This table is continued on the next page.
Call Scenarios
Each normal call between two parties logs one CDR. Each CDR contains all fields identified above, but some fields may not be used. If a field is not used, it is blank if it is an ASCII string field, or "0" if it is a numeric field. When supplementary services are involved in a call, more CDRs may be written.
In addition to the CDR, there may be one CMR per endpoint involved in a call. In a normal call between two parties 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, including all records for each call and important fields shown in summary tables for easy viewing and comparison.
•
•
•
•
•
Normal Calls (IP Phone to IP Phone)
Normal calls log three records per call; one CDR and two CMRs, one for each endpoint. In the CDR, the "originalCalledPartyNumber" field contains the same Directory Number as the "finalCalledPartyNumber" field.
Examples of Successful Calls
A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.
•
•
Abandoned Calls
The logging of calls with zero duration is optional. Normally these records will not be logged. If logging calls with zero duration is enabled, all calls will generate a CDR.
If the call was abandoned, such as when a phone is taken off hook and placed back on hook, various fields will not contain data. In this case, the originalCalledPartyNumber, finalCalledPartyNumber, the partitions associated with them, destIpAddr, and the dateTimeConnect fields are blank. All calls that were not connected will have a duration of zero seconds. When a call is abandoned, the cause code is "0".
If the user dialed a Directory Number and then abandoned the call before it was connected, the origCalledPartyNumber and finalcalledPartyNumber fields and their associated partitions contain the directory number and partition to which the call would have been extended. The destIPAddress field is blank and the duration is zero.
Examples of Abandoned Calls
•
•
Calls With Busy or Bad Destinations (Unsuccessful Calls)
These calls will all be logged as a normal call with all relevant fields containing data. The Calling or Called Party Cause field contains a cause code indicating why the call was not connected, and the Called Party IP and Date/Time Connect fields is blank. All unsuccessful calls are logged, even if zero duration calls are not being logged.
Examples of Unsuccessful Calls
•
•
globalCallID_callId
4
origLegCallIdentifier
302
destLegCallIdentifier
303
callingPartyNumber
2001
originalCalledPartyNumber
9728134987
origCause_Value
1
dest_CauseValue
0
duration
0
•
Forwarded Calls
Call Forwarding uses the redirect call primitive to forward the call. Features that use the redirect call primitive will have similar CDRs. Here are some of the important CDR fields for forwarded calls.
•
•
•
•
•
•
•
Forwarding Examples
•
•
•
Call Pickup
There are two types of call pickup in Cisco Unified CallManager: Pickup and Auto Pickup. The CDRs for both are slightly different for these two types of call pickup.
Auto Pickup
Auto Pickup is like call pickup with auto answer. The last answer softkey press is not needed. The call is automatically connected. Two CDRs are generated for Auto Pickup. These CDR will have the same Call ID.
•
•
Auto Pickup CDRs will look the same for all flavors for auto pickup: Auto Pickup, Auto Group Pickup and Auto Other Pickup.
Auto Pickup Example
•
Legacy Call Pickup
Legacy Pickup calls are very similar to forwarded calls. Legacy Call Pickup uses the redirect call control primitive just like call forwarding. Here are some of the important CDR fields for Legacy Call Pickup calls.
•
•
•
•
•
•
•
•
•
Transferred Calls
Calls that are transferred generate multiple CDRs. There is one CDR for the original call, one of the consultation call, and another for the final transferred call.
The original call has the origCause_value and destCause_value set to (split = 393216) which indicates the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields are set to (Transfer = 10) to indicate that this call was involved in a transfer.
The consultation call has the origCause_value and destCause_value set to (split = 393216) which indicates the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields are set to (Transfer = 10) to indicate that this call was involved in a transfer.
The final transferred call has the joinOnBehalfOf field set to (Transfer = 10) to indicate this call resulted from a transfer.
Transfer Examples
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.
•
•
•
•
Conference Calls
Calls that are part of a conference have multiple records logged for them. The number of CDR generated is dependent on the number of parties in the conference. There is one CDR of each party in the conference, one CDR for the original placed call, one CDR for each setup call that was used to join other parties to the conference, and one CDR for the last two parties connected in the conference. Therefore, for a 3 party Ad-Hoc conference there would be six CDRs: one CDR for the original call, three CDRs for the parties connected to the conference, one CDR for each the setup call, and one CDR for the final two parties in the conference. The setup calls can be associated with the correct call leg in the conference by examining the calling leg Id and called leg Id.
The conference bridge device has special significance to the Cisco Unified CallManager, and 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 are shown "into" the conference bridge, regardless of the actually direction. But by examining the setup call CDRs, the original direction of each call can be determined.
The conference controller information can be found in the comment field of the CDR. The format of this information is:
Comment field = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003"
•
•
The call legs connected to the conference will have the following fields information:
•
•
–
–
–
–
The original placed call and all setup calls that were used to join parties to the conference will have the following:
•
•
Conference Example
Call from 2001 to 2309.
2309 answers and talks for 60 seconds
2001 presses the "conference" softkey and dials 3071111
307111 answers and talks for 20 seconds, then 2001 presses the conference softkey to complete the conference.
The three members of the conference talk for 360 seconds.
3071111 hangs up leaving 2001 and 2309 in the conference. Since there are only two participants left in the conference, the conference features joins these two directly together and they talk for another 55 seconds.
Note
Call Park
Call Pickup will generate 2 CDRs, one for the original call that is parked and another for the call that is picked up or reverted. These CDRs will have the same globalCallID_callId.
Call Park Pickup
•
•
Call Park Example
•
Call Park Reversion
When a call is parked and not picked up, the call park reversion timer will expire and redirect the call back to the called party. In this case, there are 2 CDRs generated. The first CDR is the same as Call Park Pickup scenario above, but the second CDR is slightly different. When the Call Pickup Reversion timer expires, the call is redirected back to the called party.
When the call is parked, the call is split. This generates a CDR for the original call. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields are set to (Call Park = 3) for this CDR (same as Call Park Pickup scenario).
•
Call Park Reversion Example
•
Precedence Calls (MLPP)
With precedence calls everything is basically same for all calls (normal calls, forwarded calls, transferred calls, etc.). The difference is the precedence level fields is set in the CDR. Also when a call is preempted by a higher-level precedence call, the cause codes indicate the reason for the preemption.
Precedence Call Examples
•
•
•
Malicious Calls
When a call is identified as a malicious call (button press), the local network (CCM) flags the call. The "comment" is used to flag the malicious call.
Malicious Call Example
•
Immediate Divert (to Voicemail)
Idivert can be invoked in three different call states.
•
•
•
IDivert Examples
•
Note
•
Since the call was connected before the redirect, 2 CDRs are generated.
One for the original connected call and another for the call diverted to voicemail.
Barge
When a shared line uses the barge feature, the origCalledPartyNumber, finalCalledPartyNumber and lastRedirectDn are the conference bridge number `b00...'. The redirect and join OnBehalfOf fields have a value of (Barge = 15) and the redirect reason fields are (Barge = 114).
Barge Examples
•
Note
•
Note
•
Note
cBarge
The cBarge feature is very similar to the conference feature. When a shared line uses the cBarge feature, the origCalledPartyNumber, finalCalledPartyNumber and lastRedirectDn are the conference bridge number `b00...'. The redirect and join OnBehalfOf fields have a value of (Conference = 4) and the redirect reason fields are (Conference = 98).
cBarge Examples
•
Video Calls
This is an example CDR for a video call.
Video Calls Examples
•
Forced Authorization Code (FAC)
When FAC feature is invoked the authorization description and level are written into the CDR. For security reasons, the actual authorization code will not be written to the CDR.
•
•
FAC Example
45000 calls 9728134987, the user is prompted for a authorization code and enters 12345. FAC code 12345 is configured as level 1 and name Legal1. The caller answers the call and talks for 2 minutes.
Client Matter Code (CMC)
When the CMC feature is invoked the client matter code is written into the CDR. The clientMatterCode field contains the client matter code entered by the caller.
CMC Example
•
Call Secured Status
This field identifies security status of the call. It contains the highest level of security reached during a call. For example, if the call is originally unsecured, then later the call changed to secured, the CDR contains 1 for "Secured" even though different portions of the call had different status values. The callSecuredStatus will identify the security status of the call.
Examples
•
•
DTMF Method
These fields identifies the DTMF method used for the call.
DTMF Call Examples
•
•
RSVP
These fields identifies the status of RSVP reservation for the call. The Unified CM RSVP CDR status field value is concatenated and the last 32 status values are retained for the call.
For example, if a call is established with "Optional" policy, and the initial RSVP reservation is successful, and then it subsequently loses its bandwidth reservation and then regains its bandwidth reservation after retry, for several times during middle of the call, and the call ended with successful RSVP reservation, the CDR shows the following string as the Unified CM RSVP reservation status for that particular stream: "2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success).
RSVP Call Examples
•
•
Redirection (3xx) Calls
This is an example CDRs for a the redirection feature (3xx).
When a call is redirected by the Redirection Feature (3xx), the origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields are (CCM Redirection = 19). The origCalledPartyRedirectReason and the lastRedirectRedirectReason are (Redirection = 162).
Redirection (3xx) Examples
•
Replaces Calls
This is an example CDR for a Replaces call.
Replaces Examples
•
Note
•
Note
Refer Calls
See the "Replaces Calls" section for an example of Refer with Replaces.
CDR Field Descriptions
Table 4 defines all fields in the current CDRs in the order in which they appear in the CDR.
Table 4 CDR Field Descriptions
cdrRecordType
0, 1, 2
Defines the type of record. The following valid values apply:
•
•
•
Default - For CDRs, this field is always 1.
globalCallID_callManagerId
Positive Integer
Designates a unique Cisco Unified CallManager identity.
The Global Call ID consists of two fields: globalCallID_callId and globalCallID_callManagerId
All records associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
globalCallID_callId
Positive Integer
Designates unique call identity value that is assigned to each call. This identifier is allocated independently on each call server. Values are chosen sequentially when a call begins. A value is assigned for each call, successful or unsuccessful. When Cisco Unified CallManager restarts, this values resets to 1.
The Global Call ID consists of two fields: globalCallID_callId and globalCallID_callManagerId
All records associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
origLegCallIdentifier
Positive Integer
Identifies the originating leg of a call. This value is unique within a cluster. If the leg of a call persists across several sub-calls, and consequently several CDRs (as during a call transfer), this value remains constant.
Default - This field should always be populated.
dateTimeOrigination
Integer
Identifies the date and time when the user goes off hook or the date and time the H.323 Setup message is received for an incoming call. The time is stored as UTC.
Default - This field should always be populated.
origNodeId
Positive Integer
Identifies the node within a cluster to which the originator of the call is registered at the time the call is made.
Default - This field should always be populated.
origSpan
0, Positive integer
For calls originating at a gateway, this field indicates the B channel number of the T1 or PRI trunk where the call is originated.
For H.323 gateways, in which the span number is unknown, this field contains the call leg ID of the originator.
For calls that did not originate at a gateway, the value is zero.
Default - Populated based on these rules.
origIpAddr
Integer
Identifies the IP address of the device that originated the call signaling.
For Cisco Unified IP Phones, this field specifies the address of the phone.
For PSTN calls, this field specifies the address of the H.323 gateway.
For intercluster calls, this field specifies the address of the remote Cisco Unified CallManager.
The "IP Addresses" section describes the IP address format.
Default - Populated based on these rules.
callingPartyNumber
Text String
Specifies numeric string of up to 25 characters.
For calls that originate at a Cisco Unified IP Phone, this field shows the extension number of the line that is used.
For incoming H.323 calls, this field specifies the value that is received in the Calling Party Number field in the Setup message. This field reflects any translations that were applied to the Calling Party Number before it arrives at the Cisco Unified CallManager (such as translations at the gateway).
For server calls, where Cisco Unified CallManager originates a half call without a calling party, this field may be empty.
CallingPartyNumber could contain a SIP URI.
Default - Populated based on these rules.
callingPartyUnicodeLoginUserID
Unicode - UTF_8
Calling party's login user ID. The format of this field is UTF_8.
Default - Empty string " ". If the user ID does not exist, this field is empty.
origCause_location
0 to 15
For clearing causes that are received over ISDN signaling links, specifies the Location field that is indicated in the ISDN release message. The "Call Release Cause Codes" section lists the valid values per Q.850.
For clearing causes that are created internally by the Cisco Unified CallManager, this value is zero.
Default - 0.
origCause_value
0 to 129
For calls cleared by the originating party, this field reflects the reason for clearance.
Cisco Unified CallManager currently uses the Q.850 codes and some Cisco Unified CallManager defined codes. These are listed in the "Call Release Cause Codes" section. Some of the non-standard cause codes have been changed in this release.
For calls cleared by the terminating party, this field is zero.
In addition to the standard values described in Q.850, when a call is split by a feature (transfer/conference), the CDR terminates, and this field is set to 393216. This is a proprietary value for this field.
Default - 0.
origPrecedenceLevel
0 to 4
For MLPP, each call leg has a precedence level. This field represents the original legs precedence level.
•
•
•
•
•
Default - 4.
origMediaTransportAddress_IP
0, Integer
Identifies the IP address of the device that originated the media for the call.
For Cisco Unified IP Phones, this field specifies the address of the phone.
For PSTN calls, this field specifies the address of the H.323 gateway.
For intercluster calls, this field specifies the address of the remote phone.
The "IP Addresses" section describes the IP address format.
Default - 0. If media is not established, this field is 0.
origMediaTransportAddress_Port
0, Integer
Identifies the IP port number associated with the OrigMediaTransportAddress_IP field.
Default - 0. If media is not established, this field is 0.
origMediaCap_payloadCapability
0, Positive integer
Identifies the codec type that the originator used to transmit media.
Cisco Unified CallManager currently uses the following payload capability values (0, 1-16, 18-20, 25, 32, 33, 81-86). The "Codec Types" section lists the valid values.
Default - 0. If media is not established, this field is 0.
origMediaCap_maxFramesPerPacket
0, Positive integer
Identifies the number of milliseconds of data per packet sent by the originating party. This field is normally set to 10, 20, or 30 for G.729 or G.711 codecs, but the field can store any nonzero value.
Default - 0. If media is not established, this field is 0.
origMediaCap_g723BitRate
0
Deprecated since Cisco CallManager Release 3.3.4.
This field will always be 0.
origVideoCap_Codec
0,
100 = H.261,
101 = H.263,
102 = Vieo
Identifies the codec type the originator used to transmit video (H.261, H.263, or Vieo.)
Default - 0. If media is not established, this field is 0.
origVideoCap_Bandwidth
0, Positive Integer
Identifies the bandwidth measured in units of kbps.
Default - 0. If media is not established, this field is 0.
origVideoCap_Resolution
0,
1 = SQCIF,
2 = QCIF,
3 = CIF,
4 = CIF4,
5 = CIF16
Identifies the Video resolution.
Default - 0. If media is not established, this field is 0.
origVideoTransportAddress_IP
0, Integer
Identifies the IP address of the device that originates the call.
Default - 0. If media is not established, this field is 0.
origVideoTransportAddress_Port
0, Positive Integer
Identifies the video RTP port associated with the origVideoTransportAddress_IP field.
Default - 0. If media is not established, this field is 0.
origRSVPAudioStat
0 to 5
Status of RSVP audio reservation from originator to terminator.
0 - No reservation.
1 - RSVP Reservation Failure condition at call setup or feature invocation.
2 - RSVP Reservation Success condition at call setup or feature invocation.
3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation.
4 - RSVP Mid Call Failure Preempted condition (preempted after call setup).
5 - RSVP Mid Call Failure Lost Bandwidth condition (includes all mid call failures except MLPP preemption).
Default - "0".
origRSVPVideoStat
0 to 5
Status of RSVP video reservation from originator to terminator.
0 - No reservation.
1 - RSVP Reservation Failure condition at call setup or feature invocation.
2 - RSVP Reservation Success condition at call setup or feature invocation.
3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation.
4 - RSVP MID Call Failure Preempted condition (preempted after call setup).
5 - RSVP MID Call Failure Lost Bandwidth condition (includes all mid call failures except MLPP preemption).
Default - "0".
destLegCallIdentifier
0, Positive Integer
Identifies the terminating leg of a call. This value is unique within a cluster. If the leg of a call persists across several sub-calls and, consequently, several CDRs (as during a call transfer), this value remains constant.
Default - 0. If the destination cannot be reached, this field is 0.
destNodeId
0, Positive Integer
Identifies the node within a cluster to which the terminating party of the call is registered at the time that the call is made.
Default - 0. If the destination cannot be reached, this field is 0.
destSpan
0, Positive integer
For calls received at a gateway, this field indicates the B channel number of the T1 or PRI trunk where the call is received.
For H.323 gateways, in which the span number is unknown, this field contains the call leg ID of the destination.
For calls not terminating at a gateway, the value is zero.
Default - 0. If the destination cannot be reached, this field is 0.
destIpAddr
Integer
Identifies the IP address of the device that terminated the call signaling.
For Cisco Unified IP Phones, this field specifies the address of the phone.
For PSTN calls, this field specifies the address of the H.323 gateway.
For intercluster calls, this field specifies the address of the remote Cisco Unified CallManager.
The "IP Addresses" section describes the IP address format.
Default - 0. If the destination cannot be reached, this field is 0.
originalCalledPartyNumber
Text String
Specifies number to which the original call was presented, prior to any call forwarding. If translation rules are configured, this number reflects the called number after the translations have been applied.
Numeric string which could be either digits or a SIP URL.
Default - empty string "". If destination cannot be reached, this field is empty.
finalCalledPartyNumber
Text String
Specifies number to which the call is finally presented, until it is answered or rings out. If no forwarding occurred, this number shows same number as originalCalledPartyNumber.
For calls to a conference bridge, this field contains the actual identifier of the conference bridge, which is an alphanumeric string (for example, "b0019901001").
Numeric string which could be either digits or a SIP URL.
Default - empty string "". If destination cannot be reached, this field is empty.
finalCalledPartyUnicodeLoginUserID
Unicode - UTF_8
Final called party's login user ID. The format of this field is UTF_8.
Default - Empty string " ". If the user ID does not exist, this field is empty.
destCause_location
0 to 15
For clearing causes that are received over ISDN signaling links, this is the Location field that the ISDN release message indicates. The "Call Release Cause Codes" section lists the valid values per Q.850. Some of the non-standard cause codes have been changed in this release.
For clearing causes that Cisco Unified CallManager created internally, this value equals zero.
Default - 0. If the destination cannot be reached, this field is 0.
destCause_value
0 to 129
For calls that the destination party cleared, reflects the reason for the clearance. The "Call Release Cause Codes" section lists the valid values per Q.850. Some of the non-standard cause codes have been changed in this release.
For calls that the originating party cleared, this field is zero.
In addition to the standard values described in Q.850, when a call gets split by a feature (transfer/conference), the CDR terminates, and this field is set to 393216. This is a proprietary value for this field.
Default - 0. If the destination cannot be reached, this field is 0.
destPrecedenceLevel
0 to 4
For MLPP, each call leg has a precedence level. This field represents the destination legs precedence level.
•
•
•
•
•
Default - 4
destMediaTransportAddress_IP
0, Integer
Identifies the IP address of the device that terminated the media for the call.
For Cisco Unified IP Phones, this field designates the address of the phone.
For PSTN calls, this field designates the address of the H.323 gateway.
For intercluster calls, this field shows the address of the remote phone.
The "IP Addresses" section describes the IP address format.
Default - 0. If the destination cannot be reached, this field is 0.
destMediaTransportAddress_Port
0, Positive Integer
Identifies the IP port number associated with the DestMediaTransportAddress_IP field.
Default - 0. If the destination cannot be reached, this field is 0.
destMediaCap_payloadCapability
0, Positive Integer
Identifies the codec type that the terminating party used to transmit media.
Cisco Unified CallManager currently uses the following payload capability values (0, 1-16, 18-20, 25, 32, 33, 81-86). The "Codec Types" section lists the valid values.
Default - 0. If the destination cannot be reached, this field is 0.
destMediaCap_maxFramesPerPacket
0, Positive Integer
Identifies the number of milliseconds of data per packet that the terminating party of the call sent. This field is normally set to 10, 20, or 30 for G.729 or G.711 codecs, but can store any nonzero value.
This field can be zero if the media is never established.
Default - 0. If the destination cannot be reached, this field is 0.
destMediaCap_g723BitRate
0
Depreciated since Cisco CallManager Release 3.3(4).
Default - This field is always 0.
destVideoCap_Codec
0,
100 = H.261,
101 = H.263,
102 = Vieo
Identifies the codec type that the terminating party used to transmit video (H.261, H.263, or Vieo).
Default - 0. If the destination cannot be reached, this field is 0.
destVideoCap_Bandwidth
0, Positive Integer
Identifies the bandwidth measured in units of kbps.
Default - 0. If the destination cannot be reached, this field is 0.
destVideoCap_Resolution
0,
1 = SQCIF,
2 = QCIF,
3 = CIF,
4 = CIF4,
5 = CIF16
Identifies the video resolution.
Default - 0. If the destination cannot be reached, this field is 0.
destVideoTransportAddress _IP
0, Integer
Identifies the IP address of the device that receives the call.
Default - 0. If the destination cannot be reached, this field is 0.
destVideoTransportAddress_Port
0, Positive Integer
Identifies the video RTP port associated with the destVideoTransportAddress_IP field.
Default - 0. If the destination cannot be reached, this field is 0.
destRSVPAudioStat
0 - 5
Status of RSVP audio reservation from terminator to originator.
0 - No reservation.
1 - RSVP Reservation Failure condition at call setup or feature invocation.
2 - RSVP Reservation Success condition at call setup or feature invocation.
3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation.
4 - RSVP Mid Call Failure Preempted condition (preempted after call setup).
5 - RSVP Mid Call Failure Lost Bandwidth condition (includes all mid call failures except MLPP preemption).
Default - "0"
destRSVPVideoStat
0 - 5
Status of RSVP video reservation from terminator to originator.
0 - No reservation.
1 - RSVP Reservation Failure condition at call setup or feature invocation.
2 - RSVP Reservation Success condition at call setup or feature invocation.
3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation.
4 - RSVP Mid Call Failure Preempted condition (preempted after call setup).
5 - RSVP Mid Call Failure Lost Bandwidth condition (includes all mid call failures except MLPP preemption).
Default - "0"
dateTimeConnect
0, Integer
Identifies the date and time that the call connected. The time is stored as UTC. If the call is never answered, this value shows zero.
Default - 0. If the call is never connected, this field is 0.
dateTimeDisconnect
0, Integer
Identifies the date and time when the call was cleared. This field gets set even if the call never connected. The time is stored as UTC.
Default - 0. If the call is never connected, this field is 0.
lastRedirectDn
Text String
Specifies a numeric string of up to 25 characters. Numeric string could hold the digits or a SIP URL.
For forwarded calls, this field specifies the phone number of the next to last hop before the call reaches its final destination. If only one hop occurs, this number matches the OriginalCalledPartyNumber.
For calls that are not forwarded, this field matches the OriginalCalledPartyNumber and the FinalCalledPartyNumber.
For calls to a conference bridge, this field contains the actual identifier of the conference bridge, which is an alphanumeric string (for example, "b0019901001").
Default - empty string "". If call was never redirected, this field is empty.
pkid
Text String
Identifies a text string that the database uses internally to uniquely identify each row. This text string provides no meaning to the call itself.
Default - A unique ID should always populate this field.
originalCalledPartyNumberPartition
Text String
Uniquely identifies the partition name associated with the OriginalCalledPartyNumber field because Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that egress through an H.323 gateway, this field uniquely specifies the partition name associated with the route pattern that pointed to the gateway.
Default - empty string "". If the original called party does not have a partition, this field is empty.
callingPartyNumberPartition
Text String
Uniquely identifies the partition name associated with the CallingPartyNumber field because Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that ingress through an H.323 gateway, this field remains blank.
Default - empty string "". If the original called party does not have a partition, this field is empty.
finalCalledPartyNumberPartition
Text String
Uniquely identifies the partition name associated with the FinalCalledPartyNumber field because Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that egress through an H.323 gateway, this field uniquely specifies the partition name associated with the route pattern that pointed to the gateway.
Default - empty string "". If the final called party does not have a partition, this field is empty.
lastRedirectDnPartition
Text String
Uniquely identifies the partition name associated with the LastRedirectDn field because Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that egress through an H.323 gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
Default - empty string "". If the last redirecting Party does not have a partition or the call was never redirected, this field is empty.
duration
0, Positive integer
Identifies the difference between the Connect Time and Disconnect Time. This field specifies the time that the call remains connected, in seconds. This field remains zero if the call never connected or if it was connected for less than 1 second.
Default - 0.
origDeviceName
Text String
Specifies text string that identifies the name of the originating device.
Default - This field should always be populated.
destDeviceName
Text String
Specifies text string that identifies the name of the destination device.
Default - empty string "". If the original device does not have a name, this field is empty.
origCallTerminationOnBehalfOf
0, Positive Integer
Specifies code that identifies why the originator was terminated.
For example, if the originator of the call hangs up the phone, the OnBehalfOf code shows "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10" for Transfer.
See the "OnBehalfof Codes" section for a list of the codes. New OnBehalfOf codes have been added in this release.
Default - 0.
destCallTerminationOnBehalfOf
0, Positive Integer
Specifies code that identifies why the destination was terminated.
For example, if the originator of the call hangs up the phone, the OnBehalfOf code shows "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10" for Transfer.
See the "OnBehalfof Codes" section for a list of the codes. New OnBehalfOf codes have been added in this release.
Default - 0.
origCalledPartyRedirectOnBehalfOf
0, Positive Integer
Specifies code that identifies the reason for redirection of the original called party.
For example, if the original called party was redirected because of a conference, the OnBehalfOf code specifies "4."
See the "OnBehalfof Codes" section for a list of the codes. New OnBehalfOf codes have been added in this release.
Default - 0.
lastRedirectRedirectOnBehalfOf
0, Positive Integer
Specifies code that identifies the reason for redirection of the last redirected party.
For example, if the last redirected party was redirected on behalf of a conference, the OnBehalfOf code specifies "4."
See the "OnBehalfof Codes" section for a list of the codes. New OnBehalfOf codes have been added in this release.
Default - 0.
origCalledPartyRedirectReason
0, Integer
Identifies the reason for a redirect of the original called party.
See the "Redirect Reason Codes" section for a complete list of the codes. New redirect reason values have been added in this release.
Default - 0.
lastRedirectRedirectReason
0, Integer
Identifies the last redirect reason for redirection.
See the "Redirect Reason Codes" section for a complete list of the codes. New redirect reason values have been added in this release.
Default - 0.
destConversationID
0, Integer
Specifies unique identifier that is used to identify the parties of a conference call.
Default - 0.
globalCallId_ClusterId
Text String
Specifies a unique ID that identifies a cluster of Cisco Unified CallManagers.
This field is generated at installation, but is not used by Cisco Unified CallManager. The following fields make up this unique key:
GlobalCallId_ClusterId + GlobalCallId_CallManagerId + globalCallId_callId
Default - This field should always be populated.
joinOnBehalfOf
0, Integer
Specifies code that identifies the reason for a join.
For example, if the join took place on behalf of a transfer, the OnBehalfOf code specifies "10."
See the "OnBehalfof Codes" section for a list of the codes. New OnBehalfOf codes have been added in this release.
Default - 0.
Comment
TextString
Allows features to add text to the CDRs. This text can describe details about the call.
For example, the following field flags malicious calls.
Tag—CallFlag
Value—MALICIOUS
Default: Empty string "".
authCodeDescription
Text String
Description of the authorization code. For security purposes, the authorization code is not written to the CDR; the authorization description and level are written instead.
Default: Empty string "" or null.
authorizationLevel
0, integer
Level of the authorization code. For security purposes, the authorization does not get written to the CDR; instead the authorization description and level are written.
Default: 0
clientMatterCode
Text String
Before the system extends a call, the user enters a client matter code that can be used for assigning account or billing codes to calls.
Default: Empty string "" or null.
origDTMFMethod
0, Positive integer
DTMF method used by the originator.
0 - No DTMF - Use ANY matched DTMF.
1 - OOB - Use OOB if endpoints behind SIPTrunk support it.
2 - 2833 - Use RFC2833 if endpoints behind SIPTrunk support it.
3 - OOB and 2833 - Use both KPML and RFC2833 if endpoints behind SIPTrunk can support both.
4 - Unknown
Default—0 (No preference)
destDTMFMethod
0, Positive integer
DTMF method used by the destination.
0 - No DTMF - Use ANY matched DTMF.
1 - OOB - Use OOB if endpoints behind SIPTrunk support it.
2 - 2833 - Use RFC2833 if endpoints behind SIPTrunk support it.
3 - OOB and 2833 - Use both KPML and RFC2833 if endpoints behind SIPTrunk can support both.
4 - Unknown.Default—0 (No preference)
callSecuredStatus
0, Positive integer
The highest security status reached during a call. For example, if the call is originally unsecured, then later the call is changed to secured, the CDR contains 1 for "Secured" even though different portions of the call had different status values.
0 - Non-secured
1 - Authenticated (not encrypted)
2 - Secured (encrypted)
Default - 0 (Non-secured)
CMR Field Descriptions (Diagnostic)
Table 5 contains the fields, range of values, and field descriptions of the CMRs in the order in which they appear in the CMR.
Table 5 CMR Field Descriptions
cdrRecordType
0, 1, or 2
Specifies the type of this specific record. The following valid values apply:
•
•
•
Default - For CMRs, this field is always 2.
globalCallID_callManagerId
Positive Integer
Specifies a unique Cisco Unified CallManager identity.
This field makes up half of the Global Call ID. The Global Call ID comprises the following fields:
•
•
All records that are associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
globalCallId_callId
Positive Integer
Specifies a unique call identity value that is assigned to each call. This identifier is allocated independently on each call server. Values are chosen sequentially when a call begins. Each call, successful or unsuccessful, receives value assignment.
This field makes up half the Global Call ID. The Global Call ID comprises the following two fields:
•
•
All records that are associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
nodeId
Positive Integer
Specifies the node within the Cisco Unified CallManager cluster where this record was generated.
Default - This field should always be populated.
callIdentifier
Positive Integer
Identifies the call leg to which this record pertains.
Default - This field should always be populated.
directoryNumber
Integer
Specifies the directory number of the device from which these diagnostics were collected.
Default - This field should always be populated.
dateTimeStamp
Integer
Represents the approximate time that the device went on hook. Cisco Unified CallManager records the time when the phone responds to a request for diagnostic information.
Default - This field should always be populated.
numberPacketsSent
Integer
Designates the total number of Routing Table Protocol (RTP) data packets that the device transmitted since starting transmission on this connection. The value remains zero if the connection was set in "receive only" mode.
Default - 0.
numberOctetsSent
Integer
Specifies the total number of payload octets (that is, not including header or padding) that the device transmitted in RTP data packets since starting transmission on this connection. The value remains zero if the connection was set in "receive only" mode.
Default - 0.
numberPacketsReceived
Integer
Specifies the total number of RTP data packets that the device received since starting reception on this connection. The count includes packets that were received from different sources if this is a multicast call. The value remains zero if the connection was set in "send only" mode.
Default - 0.
numberOctetsReceived
Integer
Specifies the total number of payload octets (that is, not including header or padding) that the device received in RTP data packets since starting reception on this connection. The count includes packets that were received from different sources if this is a multicast call. The value remains zero if the connection was set in "send only" mode.
Default - 0.
numberPacketsLost
Integer
Designates the total number of RTP data packets that have been lost since the beginning of reception. This number designates the number of packets that were expected, less the number of packets that were actually received, where the number of packets that were received includes any that are late or duplicates. Thus, packets that arrive late do not get counted as lost, and the loss may be negative if duplicates exist. The number of packets that are expected designates the extended last sequence number that was received, as defined next, less the initial sequence number that was received. The value remains zero if the connection was set in "send only" mode. For detailed information, see RFC 1889.
Default - 0.
jitter
Integer
Provides an estimate of the statistical variance of the RTP data packet interarrival time, measured in milliseconds and expressed as an unsigned integer. The interarrival jitter J specifies the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver, compared to the sender for a pair of packets. RFC 1889 contains detailed computation algorithms. The value remains zero if the connection was set in "send only" mode.
Default - 0.
latency
Integer
Designates value that is an estimate of the network latency, expressed in milliseconds. This value represents the average value of the difference between the NTP timestamp that the RTP Control Protocol (RTCP) messages indicates and the NTP timestamp of the receivers, measured when these messages are received. Cisco Unified CallManager obtains the average by summing all estimates then dividing by the number of RTCP messages that have been received. For detailed information, see RFC 1889.
Default - 0.
Pkid
Text String
Identifies a text string that the database uses internally to uniquely identify each row. This text string provides no meaning to the call itself.
Default - This field will always be populated with a unique id.
directoryNumberPartition
Text String
Identifies the partition of the directory number.
Default - Empty string, "". This field may be empty if no partition exists.
deviceName
Text String
Identifies the name of the device.
Default - Empty string "". This field may be empty if there is no device name.
globalCallId_ClusterId
Text String
Designates unique ID that identifies a cluster of Cisco Unified CallManagers.
This field is generated during installation, but is not used by Cisco Unified CallManager: globalCallId_ClusterId + globalCallId_callManagerId + globalCallId_callId.
Default - This field will always be populated.
varVQMetrics
Text String
This field contains a variable number of voice quality metrics. In this release, the kfactor and concealed seconds VQ (voice quality) metrics are added. This field is a string of voice quality metrics separated by a semicolon.
The format of the string is:
fieldName=value;fieldName=value/precision
This is an example of voice quality data, but the names may be different.
"MLQKav=14396/4096;MLQK=13926/4096;MLQKmn=12288/4096;
MLQKmx=14396/4096;CRRav=0/65536;CRR=1024/65536;
CRRmn=0/65536;CRRmx=3277/65536;CS=15;SCS=2"
Note
K-Factor Data in CMRs
K-factor is an endpoint mean opinion score (MOS) estimation algorithm defined in ITU standard P.VTQ. It is a general estimator and is used to estimate the mean value of a perceptual evaluation of speech quality (PESQ) population for a specific impairment pattern.
MOS is a term that relates to the output of a well designed listening experiment. All MOS experiments use a five point PESQ scale as defined in ITU standard P.862.1, which describes the PESQ as an objective method for end-to-end speech quality assessment of narrow band telephone networks and speech codecs.
The MOS estimate is a number inversely proportional to frame loss density. Clarity decreases as more frames are lost or discarded at the receiving end. The loss or discarding of these frames is termed "concealment." Concealment statistics measure packet (frame) loss and its effect on voice quality in an impaired network.
K-factor represents a weighted estimate of average user annoyance due to distortions caused by effective packet loss such as dropouts and warbles. It does not estimate the impact of delay-related impairments such as echo. It is an estimate of listening quality (MOS-LQO) rather than conversational quality (MOS-CQO), and measurements of average user annoyance range from 1 (poor voice quality) to 5 (very good voice quality).
K-factor is trained or conditioned by speech samples from numerous speech databases, where each training sentence or network condition associated with a P.862.1 value has a duration of eight seconds. Hence, for more accurate scores, k-factor estimates are generated for every eight seconds of active speech.
K-factor and other MOS estimators are considered to be secondary or derived statistics because they warn a network operator of frame loss only after the problem becomes significant. Packet counts, concealment ratios, and concealment second counters are primary statistics because they alert the network operator before network impairment has an audible impact, or is visible through MOS.
Codec Types
Table 7 contains the compression and payload types that may appear in the codec fields.
Call Release Cause Codes
The following tables contain call release cause codes that may appear in the Cause fields in CDRs.
L
Redirect Reason Codes
Table 11 contains the available Redirect Reason Codes that may appear in a record.
OnBehalfof Codes
Table 12 contains the available OnBehalfof Codes that may appear in a record.
Related Documentation
The following documents contain additional information related to CDRs:
•
•
•
•
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the Cisco website at this URL:
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation DVD
Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.
Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.
Cisco Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•
http://www.cisco.com/en/US/partner/ordering/
•
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
•
•
•
A current list of security advisories and notices for Cisco products is available at this URL:
If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at: http://www.cisco.com/wwl/export/crypto/tool/stqrg.html.
If you require further assistance please contact us by sending email to export@cisco.com.
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:
•
•
Tip
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:
http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on
In an emergency, you can also reach PSIRT by telephone: 1-877-228-7302 or 1-408-525-6532.
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.
Cisco Technical Support Website
The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•
http://www.cisco.com/go/marketplace/
•
•
•
http://www.cisco.com/go/iqmagazine
•
•
http://www.cisco.com/en/US/learning/index.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
