Cisco CallManager Call Detail Record Definition for Release 3.1

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.

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 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 Each server (publishers and subscribers) can operate as a call control engine, but Cisco recommends that you reserve the publisher server for management processes.

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:

•

CdrLogCallsWithZeroDurationFlag—Enables logging of CDR records for calls that were never connected or that lasted less than 1 second. If you set this parameter to True, all calls get written to the database.

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 Enable these configuration items separately on each server in a cluster.

Enterprise Parameters

Configure the following parameters in the Enterprise Parameters Configuration page in Cisco CallManager Administration.

•

LocalCDRPath—The directory for local CDR files written by Cisco CallManager. Ensure the value is not empty or invalid, or the CDR files will not be moved.

•

PrimaryCDRUNCPath—The central collection point for CDR files. Ensure the value is not empty or invalid, or the CDR files will not be moved. The install sets this parameter.

•

CDRFormat—The parameter that determines whether the files get inserted into the database. The value specifies either FLAT or DB(Default DB).

•

PrimaryCDRDSN—An optional parameter that points to the primary CDR server on which to insert CDRs. The machine, to which the parameter points, does not need a Cisco CallManager install but does need SQL server and a CDR database. This allows movement of the CDRs off the Cisco CallManager cluster. If this parameter is missing, CDRs get written locally at the PrimaryCDRUNCPath.

•

CDRFlatFileInterval—The parameter that determines the number of minutes to write to a CDR file before Cisco CallManager closes the CDR file and opens a new one.

Note If the PrimaryCDRDSN parameter is missing, CDRs get written locally at the PrimaryCDRUNCPath.

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 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."

GlobalCallID	Start Time	End Time
1	973795815	973795820
2	973795840	973795845
5	973795860	973795870
4	973795850	973795880

Note Gateways may perform further modifications to the number before the digits are actually output through the gateway. The CDR does not reflect these modifications.

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#."

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.

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.

Phone Number	Description
callingPartyNumber	This party placed the call. For transferred calls, the transferred party becomes the calling party.
originalCalledPartyNumber	This number designates the originally called party, after any digit translations have occurred.
finalCalledPartyNumber	For forwarded calls, this number designates the last party to receive the call. For non-forwarded calls, this field shows the original called party.
lastRedirectDn	For forwarded calls, this field designates the last party to redirect the call. For non-forwarded calls, this field shows the last party to redirect (such as transfer and conference) the call.
callingPartyNumberPartition	This number 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.
originalCalledPartyNumberPartition	This number 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.
finalCalledPartyNumberPartition	This number 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	This number 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.

Field	Format	Description
dateTimeOrigination	UTC	For outgoing calls, this field designates the time that the device goes off hook. For incoming calls, this field designates the time that the SETUP message is received.
dateTimeConnect	UTC	This field designates the time that the devices connect and speech begins. This field shows a zero if the call never connects.
dateTimeDisconnect	UTC	This field designates the time that the call disconnects. This field never shows a 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 The database displays a negative number when the low byte of the IP address has the most significant bit set.

For example, the IP address 192.168.18.188 displays as -1139627840. To convert this IP address, perform the following procedure:

Step 1

Convert the database display (-1139627840) to a hex value.
The hex value equals 0xBC12A8C0.

Step 3

Convert the bytes from hex to decimal, as shown below:
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 The Cisco CDR Insert service will not insert a record if the CDRFormat service parameter has a value of Flat. If the service is disabled on the local Cisco CallManager, the CDR files generate, but do not get moved and deleted.

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:

Note You need access to both the configuration database and CDR database to properly resolve the CDR information.

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.

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.

Database	Tables	SQL User ID	Password	Capability
CDR	CallDetailRecord, CallDetailRecordDiagnostic	CiscoCCMCDR	dipsy	Read/Write
CCM0300	All	CiscoCCMCDR	dipsy	Read only

Tips

You should remove records more often than once a day or week in large systems. Queries to remove records consume CPU time and transaction log space relative to the size of the table: the smaller the table, the quicker your query.

CDR Record Field Descriptions


Field Name	Range of Values	Description
cdrRecordType	0, 1, or 2	Defines the type of record. The following valid values apply: •0—Start call detail record (not used) •1—End call detail record
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: •globalCallID_callID •globalCallID_callManagerID 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: •globalCallID_callID •globalCallID_callManagerID 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: •0—Media transfer stage was not reached during the call. •1—Nonstandard Codec •2—G.711 A-Law 64K •3—G.711 A-Law 56K •4—G.711 U-Law 64K •5—G.711 U-Law 56K •6—G.722 64K •7—G.722 56K •8—G.722 48K •9—G.723.1 •10—G.728 •11—G.729 •12—G.729AnnexA •13—Is11172AudioCap •14—Is13818AudioCap •15—G.729AnnexB •16—G.729 Annex AwAnnexB •18—GSM Full Rate •19—GSM Half Rate •20—GSM Enhanced Full Rate •25—Wideband 256K •32—Data 64k •33—Data 56k •80—GSM •81—ActiveVoice •82—G726_32K •83—G726_24K •84—G726_16K
origMediaCap_payloadCapability	1 to 25, 32 to 33, 80 to 84
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: •1—5.3K •2—6.3K 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: •0—Media transfer stage was not reached during the call. •1—Nonstandard Codec •2—G.711 A-Law 64K •3—G.711 A-Law 56K •4—G.711 U-Law 64K •5—G.711 U-Law 56K •6—G.722 64K •7—G.722 56K •8—G.722 48K •9—G.723.1 •10—G.728 •11—G.729 •12—G.729 AnnexA •13—Is11172AudioCap •14—Is13818AudioCap •15—G.729AnnexB •16—G.729 Annex AwAnnexB •18—GSM Full Rate •19—GSM Half Rate •20—GSM Enhanced Full Rate •25—Wideband 256K •32—Data 64k •33—Data 56k •80—GSM •81—ActiveVoice •82—G726_32K •83—G726_24K •84—G726_16K
destMediaCap_payloadCapability	0 to 25, 32 to 33, 80 to 84
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: •1—5.3K •2—6.3K 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.


Field Name	Range of Values	Description
cdrRecordType	0, 1, or 2	Specifies the type of this specific record. The following valid values apply: •0—Start call detail record (not used) •1—End call detail record •2—CMR record
globalCallID_callManagerId	Positive Integer	Specifies a unique Cisco CallManager identity. This field makes up half of the Global Call ID. The Global Call ID comprises the following fields: •globalCallID_callID •globalCallID_callManagerID All records associated with a standard call have the same Global Call ID in them.
globalCallID_callId	Positive Integer	Specifies a unique call identity value assigned to each call. This identifier gets allocated independently on each call server. Cisco CallManager chooses values sequentially when a call begins. Each call, successful or unsuccessful, receives value assignment. This field makes up half of the Global Call ID. The Global Call ID comprises the following two fields: •globalCallID_callID •globalCallID_callManagerID All records associated with a standard call have the same Global Call ID in them.
nodeId	Positive Integer	Specifies the node within the Cisco CallManager cluster where this record generates.
callIdentifier	Positive Integer	Specifies a call leg identifier that identifies the call leg to which this record pertains.
directoryNumber	Integer	Specifies the directory number of the device from which these diagnostics were collected.
dateTimeStamp	Integer	Represents the approximate time that the device went on hook. Cisco CallManager records the time when the phone responds to a request for diagnostic information.
numberPacketsSent	Integer	Designates the total number of Routing Table Protocol (RTP) data packets transmitted by the device since starting transmission on this connection. The value remains zero if the connection was set in "receive only" mode.
numberOctetsSent	Integer	Specifies the total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the device since starting transmission on this connection. The value remains zero if the connection was set in "receive only" mode.
numberPacketsReceived	Integer	Specifies the total number of RTP data packets received by the device since starting reception on this connection. The count includes packets received from different sources if this is a multicast call. The value remains zero if the connection was set in "send only" mode.
numberOctetsReceived	Integer	Specifies the total number of payload octets (i.e., not including header or padding) received in RTP data packets by the device since starting reception on this connection. The count includes packets received from different sources if this is a multicast call. The value remains zero if the connection was set in "send only" mode.
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 expected, less the number of packets actually received, where the number of packets 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 there are duplicates. The number of packets expected designates the extended last sequence number received, as defined next less the initial sequence number received. The value remains zero if the connection was set in "send only" mode.
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.
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 indicated by the RTP Control Protocol (RTCP) messages and the NTP timestamp of the receivers, measured when these messages are received. Cisco CallManager obtains the average by summing all the estimates then dividing by the number of RTCP messages that have been received.
pkid	Text String	Identifies a text string used internally by the database to uniquely identify each row. This text string has no meaning to the call itself.
directoryNumberPartition	Text String	Identifies the partition of the directory number.
deviceName	Text String	Identifies the name of the device.
globalCallId_ClusterId	Text String	Designates unique ID that identifies a cluster of Cisco CallManagers. Cisco CallManager does not use this field that is generated during installation: globalCallId_ClusterId + globalCallId_CMId + globalCallId_CallId.

Codec Types

The following table contains the compression and payload types that may appear in the Codec fields.

Cause Codes

Value	Description
1	NonStandard
2	G711Alaw 64k
3	G711Alaw 56k
4	G711Ulaw 64k
5	G711Ulaw 56k
6	G722 64k
7	G722 56k
8	G722 48k
9	G7231
10	G728
11	G729
12	G729AnnexA
13	Is11172AudioCap
14	Is13818AudioCap
15	G.729AnnexB
16	G.729 Annex AwAnnexB
18	GSM Full Rate
19	GSM Half Rate
20	GSM Enhanced Full Rate
25	Wideband 256K
32	Data 64k
33	Data 56k
80	GSM
81	ActiveVoice
82	G726_32K
83	G726_24K
84	g726_16K


Code	Description
0	No error
1	Unallocated (unassigned) number
2	No route to specified transit network (national use)
3	No route to destination
4	Send special information tone
5	Misdialed trunk prefix (national use)
6	Channel unacceptable
7	Call awarded and being delivered in an established channel
8	Preemption
9	Preemption—circuit reserved for reuse
16	Normal call clearing
17	User busy
18	No user responding
19	No answer from user (user alerted)
20	Subscriber absent
21	Call rejected
22	Number changed
26	Nonselected user clearing
27	Destination out of order
28	Invalid number format (address incomplete)
29	Facility rejected
30	Response to STATUS ENQUIRY
31	Normal, unspecified
34	No circuit/channel available
38	Network out of order
39	Permanent frame mode connection out of service
40	Permanent frame mode connection operational
41	Temporary failure
42	Switching equipment congestion
43	Access information discarded
44	Requested circuit/channel not available
46	Precedence call blocked
47	Resource unavailable, unspecified
49	Quality of Service not available
50	Requested facility not subscribed
53	Service operation violated
54	Incoming calls barred
55	Incoming calls barred within Closed User Group (CUG)
57	Bearer capability not authorized
58	Bearer capability not presently available
62	Inconsistency in designated outgoing access information and subscriber class
63	Service or option not available, unspecified
65	Bearer capability not implemented
66	Channel type not implemented
69	Requested facility not implemented
70	Only restricted digital information bearer capability available (national use)
79	Service or option not implemented, unspecified
81	Invalid call reference value
82	Identified channel does not exist.
83	A suspended call exists, but this call identity does not.
84	Call identity in use
85	No call suspended
86	Call having the requested call identity has been cleared.
87	User not member of (CUG)
88	Incompatible destination
90	Destination number missing and DC not subscribed
91	Invalid transit network selection (national use)
95	Invalid message, unspecified
96	Mandatory information element is missing.
97	Message type nonexistent or not implemented
98	Message not compatible with the call state, or the message type nonexistent or not implemented
99	An information element or parameter non-existent or not implemented
100	Invalid information element contents
101	Message not compatible with the call state
102	Call terminated when a timer expired, and a recovery routine executed to recover from the error.
103	Parameter nonexistent or not implemented - passed on (national use)
110	Message with unrecognized parameter discarded
111	Protocol error, unspecified
125	Out of bandwidth (this is a Cisco-specific code)
126	Call split. This Cisco-specific code applies when a call terminates during a transfer operation because it was split off and terminated (was not part of the final transferred call). This designation can help determine which calls terminated as part of a transfer operation.
127	Interworking, unspecified

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.

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.

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.

Outgoing PSTN Calls

You can distinguish outgoing PSTN calls either by the partition name or by the Dialed Number (which begins "9"). These examples use "PSTN" as the partition name. Several partition names may represent the PSTN to achieve a varying class of service.

Value	Description
0	Unknown
1	CctiLine
2	Unicast Shared Resource Provider
3	Call Park
4	Conference
5	Call Forward
6	Meet-Me Conference
7	Meet-Me Conference Intercepts
8	Message Waiting
9	Multicast Shared Resource Provider
10	Transfer
11	SSAPI Manager
12	Device
13	Call Control

	Calling Party	Calling Partition	Original Called Party	Original Called Partition	Orig Cause	Dest Cause	Duration
A	2001	Accounts	2309	Marketing	16	0	60
B	2001	Accounts	2309	Marketing	0	16	60

	Calling Party	Calling Partition	Original Called Party	Original Called Partition	Orig Cause	Dest Cause	Duration
A	2001	Accounts	2309	Marketing			0
B	2001	Accounts	2309	Marketing			0

	Calling Party	Original Called Party	Original Called Partition	Orig Cause	Dest Cause	Duration
A	02920262227	2309	Marketing	16	0	60
B	02920262227	2309	Marketing	0	16	60
C	02920262227			1	0	0

•

D—Successful call to premium rate number. Caller uses a # to speed up dialing. (The # key indicates to the Cisco CallManager that all digits have been entered.)

Call Failures

	Calling Party	Calling Partition	Original Called Party	Original Called Partition	Orig Cause	Dest Cause	Duration
A	2001	Accounts	902920262226	PSTN	16	0	60
B	2001	Accounts	902920262226	PSTN	0	16	60
C	2001	Accounts	90891005100	PSTN	0	16	60
D	2001	Accounts	90891005100#	PSTN	0	16	60
E	2001	Accounts	907808784185	PSTN	0	16	60
F	2001	Accounts	9100	PSTN	0	16	60

Failed outgoing calls have a CdrLogCallsWithZeroDurationFlag set at True, a duration of zero, and a DateTimeConnect value of zero. A failed call can be anything from a Cisco IP Phone going off hook then immediately on hook to a call to an invalid number.

•

C—Call to PSTN number, number does not exist (cause 1 = number unavailable).

•

D—Call to PSTN, fails because PSTN trunks are out of order (cause 38 = Network Out Of Order).

Short Calls

	Calling Party	Calling Partition	Original Called Party	Original Called Partition	Orig Cause	Dest Cause
A	2001	Accounts			16	0
B	2001	Accounts	902920262226	PSTN	0	17
C	2001	Accounts	902920100000	PSTN	0	1
D	2001	Accounts	902920262226	PSTN	0	38

A short call, with a CdrLogCallsWithZeroDurationFlag set at True and a duration of less than 1 second, appears as a zero duration call in the CDRs. The DateTimeConnect field, which shows the actual Connect time of the call, differentiates these calls from failed calls. For failed calls (which never connected), this value equals zero.

The following table contains an example of a successful on-net call with a duration of less than 1 second, cleared by the called party.

Cisco IP Phone Failure During a Call

When a Cisco IP Phone is unplugged, no immediate, physical indication goes to the Cisco CallManager. The Cisco CallManager relies upon a transmission control protocol (TCP)-based keepalive signaling mechanism to detect when a Cisco IP Phone becomes disconnected.

Each Cisco IP Phone sends a keepalive message to the Cisco CallManager at the configured keepalive interval (default=30 seconds), and the Cisco CallManager responds with an acknowledgement. Both parties then know that the other is functioning properly. When a Cisco IP Phone is unplugged, it fails to send this keepalive message. The Cisco CallManager waits twice the keepalive interval from the time of the last keepalive message before assuming that the Cisco IP Phone no longer functions.

The implication to billing is that, when a Cisco IP Phone is unplugged, the duration of the call reflected in the CDR can be up to twice the keepalive interval plus the TCP retry timers longer than the actual speech-time that the user experienced. This worst-case value assumes that the other party did not hang up.

Identify calls that fail in this manner by a cause value of 41 (Temporary Failure). This cause value can possibly occur in other circumstances because external devices such as gateways can also generate this cause value.

The following table contains an example of a successful call from 2001 to 2309, terminated by unplugging extension 2001.

Forwarded Calls

Forwarded calls generate a single CDR and show the Calling Party, Originally Called Number, Last Redirecting Number, and Final Called Number. 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.

Calling Party	Calling Partition	Original Called Party	Original Called Partition	Orig Cause	Dest Cause	DateTime Connect	Duration
2001	Accounts	2309	Marketing	0	16	973795815	0

Calling Party	Calling Partition	Original Called Party	Original Called Partition	Orig Cause	Dest Cause	Duration
2001	Accounts	2309	Marketing	41	0	120

•

A—Call from the PSTN to extension 2001, forwarded to 2309, where the call is answered

•

B—Call from the PSTN to extension 2001, forwarded to 2309, which forwards to voice mail

Conference Calls

Calls that are part of a conference have multiple records logged for them. The number of CDR records generated depends on the number of parties in the conference. One CDR record exists for each party in the conference, one CDR record 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, five CDR records exist:

Associate the setup calls with the correct call leg in the conference by examining the calling leg Id and the called leg Id.

The conference bridge device has special significance to the Cisco 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 are shown "into" the conference bridge, regardless of the actual direction. You can determine the original direction of each call by examining the setup call CDR records, the original direction of each call.

The call legs connected to the conference have the following value for the 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:

	Calling Party	Calling Partition	Original Called Party	Original Called Partition	Final Called Party	Final Called Partition	Last Redirect Party	Last Redirect Partition	Duration
A	02920262227		2001	ACNTS	2309	MKTG	2001	ACNTS	120
B	02920262227		2001	ACNTS	6000	VMAIL	2309	MKTG	60

•

After 60 seconds, user 2001 presses the "conference" key on the Cisco IP Phone and dials the PSTN number "3071111."

•

3071111 answers and talks for 20 seconds; then 2001 presses the conference key to complete the conference.

•

Each call leg shows as a call into the conference bridge. The call appears as a call into the bridge, regardless of the actual direction of the call.

Meet-Me Conferences

A Meet-Me conference occurs when several parties individually dial into a conference bridge at a predetermined time. In the following examples, 5001 specifies the dial-in number. The conference bridge device signifies special significance to the Cisco CallManager, and calls to the conference bridge appear as forwarded calls; i.e., the user phones the predetermined number (5001), and the call gets forwarded to a conference bridge port. The conference bridge port appears with a special number of the form "b0019901001."

The following tables contain these examples of a call from 2001, 2002, and 2003 dialing into a Meet-Me conference bridge with phone number 5001.

Call Hold and Resume

When a Cisco IP Phone places an active call on hold and then returns to the call without making a second call, the CDR reflects the entire duration of the original call as an uninterrupted call.

The following table contains an example of a call from Cisco IP Phone 2001 to Cisco IP Phone 2309, placing the call on hold, and resuming speech part way through the call

Transfer Without Consultation

A single CDR cannot show call transfer, which is too complex to show. Each time that a call is transferred, the Cisco CallManager terminates the CDR for that call. 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.

Calling Party	Calling Partition	Calling Leg	Original Called Party	Original Called Partition	Called Leg	Final Called Party	Final Called Partition	Last Redirect Party
2001	ACNTS	101	2309	MKTG	102	2309	MKTG	2001
2001	ACNTS	101	2309	MKTG	115	b0029901001		b0019901001
2309	ACNTS	102	b0029901001		116	b0029901001
3071111	PSTN	106	b0029901001		117	b0029901001		b0019901001
2001	ACNTS	105	3071111	PSTN	106	3071111	PSTN	3071111

OrigConversationId	OrigCall TerminationOnBehalfOf	DestCall TerminationOnBehalfOf	OriginalCalledPtyRedirectOnBehalfOf	LastRedirectRedirect OnBehalfOf	JoinOnBehalfOf	Duration
0	4	4	0	0	0	60
1	12	0	4	4	4	360
1	12	0	4	4	4	360
1	4	4	4	4	4	360
0	4	4	0	0	0	20

	Calling Party	Calling Partition	Original Called Party	Final Called Party	Last Redirect Party
A	2001	Accounts	5001	b0019901001	b0019901001
A	2002	Accounts	5001	b0019901001	b0019901001
A	2003	Accounts	5001	b0019901001	b0019901001

	Last Redirect Partition	Duration
A		70
A		65
A		60

Calling Party	Calling Partition	Original Called Party	Original Called Partition	Final Called Party	Final Called Partition	Last Redirect Party	Last Redirect Partition	Duration
2001	Accounts	2309	MKTG	2309	MKTG	2309	MKTG	70

•

B—Extension 2001 initiates a transfer without consultation (hence the duration is zero) to extension 2002.

•

C—Extension 2001 completes the transfer, dropping out of the call, leaving a call between the other two parties.

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 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.

	Calling Party	Calling Partition	Calling Leg	Original Called Party	Original Called Partition	Called Leg	Orig Cause	Dest Cause	Duration
A	2001	ACNTS	101	902920262226	PSTN	102	126	126	120
B	2001	ACNTS	103	2002	ACNTS	104	126	126	0
C	902920262226	PSTN	101	2002	ACNTS	104	0	16	120

•

B—Extension 2001 places the PSTN call on hold and calls extension 2002, talking for 30 seconds.

•

C—Extension 2001 completes the transfer, dropping out of the call, leaving a call between the other two parties.

Known Issues

The Cisco CallManager 3.0 has several known issues with the CDR data. This section lists a few of these issues.

During an ad hoc conference, all CDRs show call legs into the bridge, regardless of the actual direction of the call. You cannot determine whether a participating call leg is incoming or outgoing.

The Cisco CallManager only generates end-of-call records. You cannot see records of calls in progress.

The CDR table lists IP addresses for the endpoints of a call. These IP addresses do not easily convert to device names, so the type of device can be determined.

You may have difficultly determining whether a call stays completely on the IP network or at least internal to the local system. One way you can verify this information is to check the device type of both ends of the call. If both are phones, you can assume that the call stayed on-net. If one device is a gateway, you must consider the following information. If the gateway is an analog access type of device with a POTS or station port, the call may have gone to a local analog phone or to the PSTN. You must look at the number dialed and the dial plan to determine whether the call went off-net.

If a call is placed out of a gateway, the digits dialed to get to the gateway may not be the digits sent to the PSTN. The gateway may modify the directory number further. The Cisco CallManager does not receive the modified number, and the CDR does not reflect the actual digits that are sent off-net.

The call that results from a transfer appears as a call from the transferred party (party B) to the destination party (party C) in the CDR. The transferred party (party B) becomes the originator of the final call and is charged for the call even though party A placed the original call.

Table Of Contents