Table Of Contents
Cisco CallManager Call Detail Record Definition
Cisco CallManager CDR Overview
Cisco CallManager Configuration
Cisco IP Phone Failure During a Call
Obtaining Technical Assistance
Cisco CallManager Call Detail Record Definition
This document describes the format and logic of the call detail records (CDRs) generated by the Cisco CallManager system. 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 database, how to interpret fields in the database schema, and some of the known issues.
When you install your system, the system specifies that Call Detail Records (CDRs) are disabled, by default. You can enable and disable CDR records at any time while the system is in operation. You do not need to restart the Cisco CallManager for changes to take effect. The system responds to all changes within a few seconds.
Contents
This document covers the following topics:
•
Cisco CallManager CDR Overview
•
•
•
Cisco CallManager CDR Overview
The Cisco CallManager comprises several Windows 2000 Servers using Microsoft SQL clustering to share common data. Each cluster comprises a publisher and several subscriber databases.
Cisco CallManager generates two different types of call information records: Call Detail Records (CDRs) and Call Management Records (CMRs). The CDRs store information about the endpoints of the call and other call control/routing aspects. The CMRs contain information about the quality of the streamed audio of the call. More than one CMR can exist per CDR.
The CDR records relate to the CMR records via the two globalCallID columns:
•
•
The primary server (publisher) maintains the central copy of the CDR database. When a call is generated on a subscriber, the Cisco CallManager writes CDRs and CMRs in flat files (text) on the subscriber databases. The localCDRPath service parameter specifies the directory to which the files are written. CDR and CMR records periodically pass from each of the subscribers to the publisher, and the CiscoInsertCDR service reads the records from the flat files and inserts the records into the centralized SQL database.
The configurable directory containing the files defaults to \Program Files\Cisco\CallDetail.
Cisco CallManager does not perform any post processing on the records. For more information, see "Writing Records" section.
Note
Cisco CallManager Configuration
Enable or disable the CDR and CMR records through the Cisco CallManager service parameters. You can find information on where and how the CDR and CMR records are generated in the System enterprise parameters.
Service Parameters
The Cisco CallManager contains three service parameters that are set to False by default that control the generation of CDRs:
•
•
•
To view all CDRs for billing and fraud detection purposes, enable both flags.
The MaxCdrRecords service parameter controls the maximum number of CDRs on the system. When this limit is exceeded, the oldest CDRs automatically get removed, along with the related CMR records, once a day. The default value specifies 1.5 million records.
Note
Enterprise Parameters
Configure the following parameters in the Enterprise Parameters Configuration page in Cisco CallManager Administration.
•
•
•
•
•
Note
Retaining the default values for these parameters will write CDRs to the primary CDR server database.
You can configure service parameters on the Service Parameters Configuration page in Cisco CallManager Administration.
Global Call Identifier
The Cisco CallManager allocates a global call identifier (GlobalCallId) each time that a Cisco IP Phone is taken off hook or a call is received from a gateway. If the Cisco CallManager is configured as described in "IP Addresses" section, it logs each of these calls in the CDR.
The CDR table lists the CDRs written to the CDR table 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 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.
The following table contains a sample CDR:
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 GlobalCallID 4 ended; therefore, only completed calls and failed calls get written to the CDR table.
Number Translations
The Cisco CallManager can perform translations on the digits dialed by a user. 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 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#."
The CDR uses the following Partition/Extension Number:
Timestamps
Timestamps within a CDR record 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 Windows NT (2000) system routines.
The CDR includes the following timestamps:
Call Clearing Causes
The CDR record includes two clearing causes: OrigCause and DestCause. When the originating party clears the call, the OrigCause gets populated. When the terminating party clears the call, or the call is rejected, the DestCause gets populated. When unpopulated, the cause value shows zero.
The "Cause Codes" section lists the calls clearing cause values per ITU specification Q.850. For on-net call legs, the Cisco CallManager determines the cause value. For off-net call legs, the far-end switch determines the cause value.
IP Addresses
The system stores IP addresses as unsigned integers. The database displays them 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 notation.
Note
For example, the IP address 192.168.18.188 displays as -1139627840. To convert this IP address, perform the following procedure:
Procedure
Step 1
The hex value equals 0xBC12A8C0.Step 2
CO A8 12 BCStep 3
192 168 18 188Step 4
192.168.18.188
Working With CDRs
Users can access the Microsoft SQL Server 7.0 database via Open Database Connectivity (ODBC). Users have read-only access to all tables in the database and have read/write access to the CDR and CMR tables. When working with CDRs, you may want to read other tables in the database to obtain information about the type of device in each CDR. Because this correlation between devices in the Device table and the IP address listed in the CDR is not straightforward, it appears as a known issue in "Known Issues" section.
Writing Records
The Cisco CallManager writes CDRs to the SQL database as calls are made, in a manner consistent with the configuration of each individual Cisco CallManager. You can configure the Cisco CallManager by accessing the Service Parameters Configuration page in Cisco CallManager Administration.
When CDR records are enabled, Call Control generates one or more CDR records for each call. These records get sent to EnvProcessCdr, where they are written to the flat files. The number of records written varies by the type of call and significant changes that occur to the call, such as ending a call, transferring the call, redirecting the call, splitting, or joining a call.
When Diagnostics are enabled, processStationCdpc generates up to two CMR records for each call. One CMR records gets written for each IP Phone involved in the call, or for each MGCP gateway. These records also get sent to EnvProcessCdr where they are written to the flat files.
Note
Reading Records
The easiest way to read data from the SQL database may be to use ODBC. A good connection string looks like one of the following examples, depending on whether you need to get to the configuration data or CDRs:
DRIVER={SQL Server};SERVER=machineX;DATABASE=CCM030x
DRIVER={SQL Server};SERVER=machineX;DATABASE=CDR
Use the correct database name. The tables reside in the CDR database.
Note
The machine serving the primary CCM0300 database serves as the machine that is the central collector of the CDR information.
You can find the primary database (machine and name) that the cluster currently is using by opening Cisco CallManager Administration, choosing Help > About Cisco CallManager, and clicking the Details button. You can also check the registry on machines hosting a database. Look at the registry key, \\HKEY_LOCAL_MACHINE\Software\Cisco Systems Inc.\DBL, for DBConnection0. This string item contains a connection string similar to that shown above with the machine name and database name of the primary database.
The following table specifies the user ID and password that you should use when accessing the Cisco CallManager database.
CDR
CallDetailRecord,
CallDetailRecordDiagnostic
CiscoCCMCDR
dipsy
Read/Write
CCM0300
All
CiscoCCMCDR
dipsy
Read only
Removing Records
Because the Cisco CallManager relies on third-party packages to process the CDR data, you should remove the CDR data after all packages finish with the data. Use the CiscoCCMCDR user to remove the records. The CiscoCCMCDR user designates the Microsoft SQL Server account that can be used to read/write to the CDR and CMR tables.
If CDRs accumulate to a configured maximum, the system removes the oldest CDRs along with related CMR records once a day. The default maximum specifies 1,500,000 CDRs.
When removing CDR data after analysis, be sure to remove all related CMR records also.
Tips
CDR Record Field Descriptions
The following table defines all fields in the current CDR records.
cdrRecordType
0, 1, or 2
Defines the type of record. The following valid values apply:
•
•
globalCallID_callManagerId
Positive Integer
Designates unique Cisco CallManager identity.
This field comprises half of the Global Call ID. The Global Call ID comprises the following fields:
•
•
All records associated with a standard call have the same Global Call ID in them.
globalCallID_callId
Positive Integer
Designates unique call identity value assigned to each call. Cisco CallManager allocates this identifier independently on each call server. Values get chosen sequentially when a call begins. A value assignment occurs for each call, successful or unsuccessful.
This field comprises half of the Global Call ID. The Global Call ID comprises the following two fields:
•
•
All records associated with a standard call have the same Global Call ID in them.
origLegCallIdentifier
Positive Integer
Identifies the originating leg of a call with a value that 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.
dateTimeOrigination
Integer
Identifies the date and time when the user goes off hook or the date and time when the H.323 Setup message is received for an incoming call. UTC specifies the time.
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
origSpan
Positive Integer or Zero
For calls originating at a gateway, identifies the port or span on the gateway where the call originated.
For H.323 gateways in which the span number is unknown, this field contains the call leg ID of the originator.
For calls not originating at a gateway, the value equals zero.
origIpAddr
Integer
Identifies the IP address of the device that originated the call signaling.
For Cisco IP Phones, this field specifies the address of the Cisco IP 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 CallManager.
"IP Addresses" section, describes the IP address format.
origIpPort
Positive Integer
Identifies the IP port number associated with the OrigIpAddr field.
callingPartyNumber
Text String
Specifies numeric string of up to 25 characters.
For calls originating at a Cisco IP Phone, this field shows the extension number of the line that is used.
For incoming H.323 calls, this field specifies the value received in the Calling Party Number field in the SETUP message. This field reflects any translations applied to the Calling Party Number before it arrives at the Cisco CallManager (such as translations at the gateway).
origCause_location
0 to 15
For clearing causes received over ISDN signaling links, specifies the Location field indicated in the ISDN release message. "Cause Codes" section, lists the valid values per Q.850.
For clearing causes created internally by the Cisco CallManager, this value equals zero.
origCause_value
0 to 127
For calls cleared by the originating party, reflects the reason for the clearance. "Cause Codes" section, lists the valid values per Q.850.
For calls cleared by the terminating party, this field specifies zero.
In addition to the standard values described in Q.850, when a call is placed on hold, the CDR terminates, and this field is set to 126. This constitutes a proprietary value for this field.
origMediaTransportAddress_IP
Integer
Identifies the IP address of the device that originated the media for the call.
For Cisco IP Phones, this field specifies the address of the Cisco IP 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 IP Phone.
"IP Addresses" section describes the IP address format.
origMediaTransportAddress_Port
Positive Integer
Identifies the IP port number associated with the OrigMediaTransportAddress_IP field
origMediaCap_payloadCapability
1 to 25, 32 to 33, 80 to 84
Identifies the codec type that the originator used to transmit media. The following valid values descriptions apply:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
origMediaCap_maxFramesPerPacket
Positive Integer
Identifies the number of milliseconds of data per packet sent by the originating party. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, can store any nonzero value.
This field can remain zero if the media is never established.
origMediaCap_g723BitRate
0, 1, or 2
When the codec used by the originating party is G.723, indicates the data rate used. The following values apply:
•
•
When the codec is not G.723, this value equals zero.
destLegIdentifier
Positive Integer
Identifies the terminating leg of a call. This field specifies unique values 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.
destNodeId
Positive Integer or Zero
Identifies the node within a cluster to which the terminating party of the call is registered at the time that the call is made. This field can remain zero when the call does not complete.
destSpan
Positive Integer or Zero
For calls terminating at a gateway, identifies the port or span on the gateway where the call terminated.
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 equals zero.
destIpAddr
Integer or Zero
Identifies the IP address of the device that terminated the call signaling.
For Cisco IP Phones, this field specifies the address of the Cisco IP 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 CallManager.
"IP Addresses" section describes the IP address format. This field can remain zero if the call does not complete.
destIpPort
Positive Integer or Zero
Identifies the IP port number associated with the DestIpAddr field. This field can remain zero if the call does not complete.
originalCalledPartyNumber
Text String
Specifies numeric string of up to 25 characters.
This field specifies the number to which the original call was presented, prior to any call forwarding. If translation rules are configured on the Cisco CallManager, this number reflects the called number after the translations have been applied.
finalCalledPartyNumber
Text String
Specifies numeric string of up to 25 characters.
This field specifies the number to which the call is finally presented, until it is answered or rings-out. If no forwarding occurred, this number shows the same number as the 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").
destCause_location
0 to 15
For clearing causes received over ISDN signaling links, specifies the Location field indicated in the ISDN release message. "Cause Codes" section lists the valid values per Q.850.
For clearing causes created internally by the Cisco CallManager, this value equals zero.
destCause_value
0 to 127
For calls cleared by the destination party, reflects the reason for the clearance. "Cause Codes" section lists the valid values per Q.850.
For calls cleared by the originating party, this field equals zero.
In addition to the standard values described in Q.850, when a call is placed on hold, the CDR terminates, and this field gets set to 126, a proprietary value for this field.
destMediaTransportAddress_IP
Integer
Identifies the IP address of the device that terminated the media for the call.
For Cisco IP Phones, this field designates the address of the Cisco IP 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 Cisco IP Phone.
"IP Addresses" section describes the IP address format.
destMediaTransportAddress_Port
Positive Integer
Identifies the IP port number associated with the DestMediaTransportAddress_IP field.
destMediaCap_payloadCapability
0 to 25, 32 to 33, 80 to 84
Identifies the codec type that the terminating party used to transmit media. The following list gives valid values:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
destMediaCap_maxFramesPerPacket
Positive Integer
Identifies the number of milliseconds of data per packet sent by the terminating party of the call. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, can store any nonzero value.
This field can remain zero if the media is never established.
destMediaCap_g723BitRate
0, 1, or 2
When the codec used by the terminating party is G.723, indicates the data rate used. The following values apply:
•
•
When the codec is not G.723, this value is zero.
dateTimeConnect
Integer or zero
Identifies the date and time that the call connected. UTC specifies the time. If the call is never answered, this value shows zero.
dateTimeDisconnect
Integer
Identifies the date and time when the call was cleared. This field gets set even if the call never connected. UTC specifies the time.
lastRedirectDn
Text String
Specifies numeric string of up to 25 characters.
For forwarded calls, this field specifies the phone number of the penultimate 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").
pkid
Text String
Identifies a text string used internally by the database to uniquely identify each row. This text string provides no meaning to the call itself.
originalCalledPartyNumberPartition
Text String
Identifies the partition name associated with the OriginalCalledPartyNumber field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls egressing through a H.323 gateway, this field specifies the partition name associated with the route pattern that pointed to the gateway.
callingPartyNumberPartition
Text String
Identifies the partition name associated with the CallingPartyNumber field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls ingressing through a H.323 gateway, this field remains blank.
finalCalledPartyNumberPartition
Text String
Identifies the partition name associated with the FinalCalledPartyNumber field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls egressing through a H.323 gateway, this field specifies the partition name associated with the route pattern that pointed to the gateway.
lastRedirectDnPartition
Text String
Identifies the partition name associated with the LastRedirectDn field. This field uniquely identifies this number because the Cisco CallManager supports multiple Cisco IP Phones with the same extension number in different partitions. For calls egressing through a H.323 gateway, this field specifies the partition name associated with the route pattern that pointed to the gateway.
duration
Positive Integer or Zero
Identifies the difference between the Connect Time and Disconnect Time. This field specifies the time that the call is connected, in seconds. This field remains zero if the call never connected or connected for less than 1 second.
origDeviceName
Text String
Specifies text string that identifies the name of the originating device.
destDeviceName
Text String
Specifies text string that identifies the name of the destination device.
origCalledPartyRedirectReason
Integer
Identifies the reason for a redirect of the original called party.
lastRedirectRedirectReason
Integer
Identifies the last redirect reason for redirection.
destConversationID
Integer
Specifies unique identifier used to identify the parties of a conference call.
origCallTerminationOnBehalfOf
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 "Device." If the call is terminated because of a transfer, the OnBehalfOf code shows "Transfer."
See the "OnBehalfCodes" section for a complete list of the codes.
destCallTerminationOnBehalfOf
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 "Device." If the call is terminated because of a transfer, the OnBehalfOf code shows "Transfer."
See the "OnBehalfCodes" section for a complete list of the codes.
origCalledPartyRedirectedOnBehalfOf
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 "Conference."
See the "OnBehalfCodes" section for a complete list of the codes.
lastRedirectRedirectOnBehalfOf
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 "Conference."
See the "OnBehalfCodes" section for a complete list of the codes.
joinOnBehalfOf
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 "Transfer."
See the "OnBehalfCodes" section for a complete list of the codes.
globalCallId_ClusterId
Text String
Specifies a unique ID that identifies a cluster of Cisco CallManagers.
Cisco CallManager does not use this field that generates at installation. The following fields make up this unique key:
GlobalCallId_ClusterId + GlobalCallId_CMId + GlobalCallId_CallId
CMR Fields (Diagnostic)
The following table contains the fields, range of values, and field descriptions of the CMRs.
Codec Types
The following table contains the compression and payload types that may appear in the Codec fields.
Cause Codes
The following table contains cause codes that may appear in the Cause fields.
OnBehalfCodes
The following table contains the available OnBehalfCodes that may appear in a record.
Call Types
Successful On-Net Calls
A successful call between two Cisco IP Phones generates a 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
Unsuccessful On-Net Calls
An unsuccessful call generates a CDR, even if the phone simply goes off hook then back on hook. You can easily identify these unsuccessful calls because the duration equals zero.
The following table contains two examples:
•
•
A
2001
Accounts
2309
Marketing
0
B
2001
Accounts
2309
Marketing
0
Incoming PSTN Calls
You can distinguish calls from the PSTN because they do not contain a Calling Partition. The Calling Party number specifies the number that is delivered by the gateway.
The following table contains three examples:
•
•
•
<
Guest
