Table Of Contents
Cisco CallManager 4.1(3) Call Detail Record Definition
Cisco CallManager Release 4.1(3)
Cisco CallManager Release 4.1(2)
Cisco CallManager Release 4.0(1)
Cisco CallManager CDR Overview
Cisco CallManager Configuration
Cisco IP Phone Failure During a Call
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 Going Directly to Destination with No Rules
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)
Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)
Personal Assistant Conferencing
Immediate Divert (IDivert) During Alerting
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 CallManager 4.1(3) Call Detail Record Definition
This document describes the format and logic of the call detail records (CDRs) that the Cisco CallManager Release 4.1(3) 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 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
•
•
•
•
•
New and Changed Information
This section describes any new features and or changes for CDRs that are pertinent to the specified release of Cisco CallManager.
Cisco CallManager Release 4.1(3)
For this release, the content of the CDR records changed for the new Auto Pickup feature, but no new CDR fields or changed CDR fields were added. Enhancements to the existing Call Pickup and Group Call Pickup features provide the Auto Pickup feature.
You can enable and disable Auto Pickup by using the new service parameter Auto Pickup Enabled. By default, the system sets the Auto Pickup Enabled parameter to False. When the parameter is set to True, Auto Pickup applies to all types of Call Pickup.
Auto Pickup
The following list gives the three types of auto pickup:
•
•
•
The new Auto Pickup feature generates only two CDR records: one CDR for the ringing call and another CDR for the final connected call that is picked up. Both CDRs have the same Call ID.
For the first CDR, the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to 16 (Pickup), which indicates that the call terminated on behalf of the Pickup feature.
For the second CDR, the lastRedirectOnBehalfOf and joinOnBehalfOf fields get set to 16 (Pickup), which indicates that the system joined the call on behalf of the Pickup feature. The lastRedirectDn will indicate from where the call was picked up, that is, lastRedirectDn will contain the party that was ringing when the call was picked up. The lastRedirectRedirectReason will contain the redirect reason 5 (Pickup).
Pickup
The existing pickup features generate only one CDR record. The origCalledPartyRedirectOnBehalfOf, lastRedirectRedirectOnBehalfOf, and joinOnBehalfOf fields get set to 5 (Call Froward), which indicates that the Call Forward feature redirected the call. The origCalledPartyRedirectReason and lastRedirectRedirectReason contain the redirect reason code of 5 (Pickup).
Cisco CallManager Release 4.1(2)
The following list provides the features or changes for CDRs in Cisco CallManager release 4.1(2):
•
•
The 4.1(2) Cisco CallManager release provides three new CDR fields to support FAC and CMC:
•
•
•
Cisco CallManager Release 4.0(1)
The following list provides the features or changes for CDRs in Cisco CallManager release 4.0(1):
•
–
origPrecendenceLevelfor the precedence level of the originating leg of the call–
destPrecedenceLvelfor the precedence level of the destination leg of the call–
•
Commentfield•
origCause_valueanddestCause_value•
OnBehalfOffield contains a new code (value = 14) for the Immediate Divert feature and value = 15 for Barge.•
–
origVideoCap_Codec–
destVideoCap_Codec–
origVideoCap_Bandwidth–
destVideoCap_Bandwidth–
origVideoCap_Resolution–
destVideoCap_Resolution–
origVideoTransportAddress_IP–
origVideoTransportAddress_Port–
destVideoTransportAddress_IP–
destVideoTransportAddress_Port•
callingPartyLoginUserIDandfinalCalledPartyLoginUserID) to ensure that the system associates a valid UserID with a newly created phone device and that it gets properly reported in CDRs•
Cisco CallManager Release 3.2
The change for CDRs in Cisco CallManager release 3.2 means that CDR records get written to comma-delimited flat files (text) on the subscriber databases. The localCDRPath service parameter specifies the directory to which the files are written. CDR and CMR records fpr each subscriber periodically pass to the publisher database, and the CiscoInsertCDR service reads the records from the flat files and inserts the records into the centralized SQL database.
Cisco CallManager CDR Overview
The Cisco CallManager comprises several Windows 2000 Servers that are using Microsoft SQL clustering method to share common data. Each cluster comprises a publisher and several subscriber databases.
Microsoft SQL Server 2000 Service Pack 3A, which replaces Microsoft SQL 7.0, gets configured with only TCP for communications and NT authentication. Named Pipes communications and Mixed mode authentication no longer get configured.
Note
The connection logic in the database layer uses Windows NT authentication. All database layer connections, which are DSN based, use an Open Database Connectivity (ODBC) system DSN, CiscoCallManager. For more information, see the "Reading Records" section.
Any third party application that connects to the database can change the way that it connects. Beyond that, everything else remains the same. Both previous and current connections work.
The configuration ensures that web applications that do not require an NT login and use the database layer, such as CCMUser, run as a different NT user with limited privileges, not ANONYMOUS.
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 database 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 enterprise 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 Cisco CDR Insert service reads the records from the flat files and inserts the records into the centralized SQL database.
The configurable directory that contains the files defaults to \Program Files\Cisco\CallDetail.
Cisco CallManager does not perform any post processing on the records. For more information, see the "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 the following service parameters, set to False by default, that control the generation of CDRs:
•
•
•
To view all CDRs for billing and fraud detection purposes, enable the flags.
MaxCdrRecords is a service parameter for the Cisco Database Layer Monitor service and 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
You can configure service parameters on the Service Parameters Configuration window in the Cisco CallManager Administration.
Enterprise Parameters
Configure the following parameters in the Enterprise Parameters Configuration window in Cisco CallManager Administration.
•
•
•
•
•
Note
Retaining the default values for these parameters will write CDRs to the primary CDR server database.
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.
The CDR table lists the CDRs that are 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, and only completed calls and failed calls get written to the CDR table.
Number Translations
The Cisco 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#."
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 2000 Service Pack 2 database via ODBC. The install configures an ODBC system DSN that is called CiscoCallManager. 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 that is listed in the CDR is not straightforward, it appears as a known issue in the "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 Service Parameters Configuration 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 that are 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 the Call Diagnostics service parameter is set to true, processStationCdpc generates up to two CMR records 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 the database at the end of the call. Only completed calls and failed calls generate records.
Note
Reading Records
The easiest way to read data from the SQL database may be to use ODBC. The connection string looks like one of the following examples, depending on whether you need to get to the configuration data or CDRs:
For SQL authentication:
DRIVER={SQL Server};SERVER=machineX;DATABASE=CCM0300;UID=CiscoCCMUser;PWD=password
DRIVER={SQL Server};SERVER=machineX;DATABASE=CDR;UID=CiscoCCMCDR;PWD=password
For Windows NT authentication:
DSN=CiscoCallManager;SERVER=X;DATABASE=CCM0300;Trusted_Connection=yes
or
DSN=CiscoCallManager;SERVER=X;DATABASE=CDR;Trusted_Connection=yes
Use the correct database name. The tables reside in the CDR database.
Note
The machine that serves 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 that host a database. Look at the registry key, \\HKEY_LOCAL_MACHINE\Software\Cisco Systems Inc.\DBL, for DBConnection0. This string item contains a connection string that includes the machine name and database name of the primary database.
The following table specifies the user ID and password that you should use when you access 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:
•
•
Default - For CDR records, this field will always be 1.
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 that are associated with a standard call have the same Global Call ID in them.
Default - This field should always be populated.
globalCallID_called
Positive Integer
Designates unique call identity value that is 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 that are 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 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.
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 when the setup message is received for an incoming call. UTC specifies the time.
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
Positive Integer or Zero
For calls that originate at a gateway, identifies the port or span on the gateway where the call originated.
For 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 equals zero.
Default - Populated based on these rules.
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 gateway.
For intercluster calls, this field specifies the address of the remote Cisco CallManager.
The "IP Addresses" section describes the IP address format.
Default - Populated based on these rules.
origIpPort
Positive Integer
Identifies the IP port number that is associated with the OrigIpAddr field.
Cisco CallManager does not use or populate this field.
Default - Field will always be 0 or null.
callingPartyNumber
Text String
Specifies numeric string of up to 25 characters.
For calls that originate at a Cisco IP Phone, this field shows the extension number of the line that is used.
For incoming 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 CallManager (such as translations at the gateway).
Default - Populated based on these rules.
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 "Cause Codes" section lists the valid values per Q.850.
For clearing causes that are created internally by the Cisco CallManager, this value equals zero.
Default - 0.
origCause_value
0 to 128
For calls that the originating party cleared, reflects the reason for the clearance. The "Cause Codes" section lists the valid values per Q.850.
For calls that the terminating party cleared, this field specifies zero.
In addition to the standard values that are described in Q.850, when a call is placed on hold, the CDR terminates, and this field gets set to 126. This represents a proprietary value for this field.
MLPP uses the current cause codes:
•
•
•
•
•
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
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 gateway.
For intercluster calls, this field specifies the address of the remote Cisco IP Phone.
The "IP Addresses" section describes the IP address format.
Default - 0. If media is not established, this field will be 0.
origMediaTransportAddress_Port
Positive Integer
Identifies the IP port number that is associated with the OrigMediaTransportAddress_IP field
Default - 0. If media is not established, this field will be 0.
origMediaCap_payloadCapability
0 to 15, 32 to 33, 80 to 84
Identifies the codec type that the originator used to transmit media. The following valid values descriptions apply:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Default - 0. If media is not established, this field will be 0.
origMediaCap_maxFramesPerPacket
Positive Integer or Zero
Identifies the number of milliseconds of data per packet that the originating party sent. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, can store any nonzero value.
Default - 0. If media is not established, this field will be 0.
origMediaCap_g723BitRate
0, 1, or 2
When the codec that the originating party used is G.723, indicates the data rate that was used. The following values apply:
•
•
When the codec is not G.723, this value equals zero.
Default - Field will always be 0.
origVideoCap_Codec
100 = H.261
101 = H.263
102 = Cisco Video Link
Identifies the codec type used by the originator to transmit video (H.261, H.263, and the Cisco Video Link.)
Default - 0. If media is not established, this field will be 0.
origVideoCap_Bandwidth
Positive Integer
Identifies the bandwidth measured in units of kbps.
Default - 0. If media is not established, this field will be 0.
origVideoCap_Resolution
1 = SQCIF
2 = QCIF
3 = CIF
4 = CIF4
5 = CIF16
Identifies the Video resolution.
Default - 0. If media is not established, this field will be 0.
origVideoTransportAddress_IP
Integer
Identifies the IP address of the device that originates the call.
Default - 0. If media is not established, this field will be 0.
origVideoTransportAddress_Port
Positive Integer
Identifies the video RTP port associated with the origVideoTransportAddress_IP field.
Default - 0. If media is not established, this field will be 0.
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.
Default - 0. If the destination cannot be reached, this field will be 0.
destNodeId
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 will be 0.
destSpan
Positive Integer or Zero
For calls that terminate 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 that did not terminate at a gateway, the value equals zero.
Default - 0. If the destination cannot be reached, this field will be 0.
destIpAddr
Integer
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 gateway.
For intercluster calls, this field specifies the address of the remote Cisco CallManager.
The "IP Addresses" section describes the IP address format.
Default - 0. If the destination cannot be reached, this field will be 0.
destIpPort
Positive Integer or Zero
Identifies the IP port number that is associated with the destIpAddr field.
This field is not used or populated by Cisco CallManager.
Default - Field will always be 0 or null.
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.
Default - empty string "" or null. If destination cannot be reached, this field will be empty.
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").
Default - empty string "" or null. If destination cannot be reached, this field will be empty.
destCause_location
0 to 15
For clearing causes that are received over ISDN signaling links, specifies the Location field that the ISDN release message indicates. The "Cause Codes" section lists the valid values per Q.850.
For clearing causes that the Cisco CallManager created internally, this value equals zero.
Default - 0. If the destination cannot be reached, this field will be 0.
destCause_value
0 to 128
For calls that the destination party cleared, reflects the reason for the clearance. The "Cause Codes" section lists the valid values per Q.850.
For calls that the originating party cleared, this field equals zero.
MLPP uses the current cause codes:
•
•
•
•
•
Default - 0. If the destination cannot be reached, this field will be 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
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.
The "IP Addresses" section describes the IP address format.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaTransportAddress_Port
Positive Integer
Identifies the IP port number that is associated with the DestMediaTransportAddress_IP field.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaCap_payloadCapability
0 to 15, 32 to 33, 80 to 84
Identifies the codec type that the terminating party used to transmit media.
The Codec Types section lists the valid values.
Default - 0. If the destination cannot be reached, this field will be 0.
destMediaCap_maxFramesPerPacket
Positive Integer
Identifies the number of milliseconds of data per packet that the terminating party of the call sent. This field, normally set to 10, 20, or 30 for G.729 or G.711 codecs, 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 will be 0.
destMediaCap_g723BitRate
0
Depreciated since Cisco CallManager Release 3.3(4).
Default - This field is always 0.
destVideoCap_Codec
100 = H.261
101 = H.263
102 = Cisco Video Link
Identifies the codec type that the terminating party used to transmit video (H.261, H.263, and the Cisco Video Link).
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoCap_Bandwidth
Positive Integer
Identifies the bandwidth measured in units of kbps.
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoCap_Resolution
1 = SQCIF
2 = QCIF
3 = CIF
4 = CIF4
5 = CIF16
Identifies the video resolution.
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoTransportAddress _IP
Integer
Identifies the IP address of the device that receives the call.
Default - 0. If the destination cannot be reached, this field will be 0.
destVideoTransportAddress_Port
Positive Integer
Identifies the video RTP port that is associated with the destVideoTransportAddress_IP field.
Default - 0. If the destination cannot be reached, this field will be 0.
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.
Default - 0. If the call is never connected, this field will be 0.
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.
Default - 0.
lastRedirectDn
Text String
Specifies numeric string of up to 25 characters.
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 "" or null. If call was never redirected, this field will be 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
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 that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
Default - empty string ""or null. If the original called party does not have a partition, this field will be empty.
callingPartyNumberPartition
Text String
Identifies the partition name that is 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 that ingress through a gateway, this field remains blank.
Default - empty string "" or null. If the original called party does not have a partition, this field will be empty.
finalCalledPartyNumberPartition
Text String
Identifies the partition name that is 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 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 "" or null. If the final called party does not have a partition, this field will be empty.
lastRedirectDnPartition
Text String
Identifies the partition name that is 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 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 "" or null. If the last redirecting Party does not have a partition or the call was never redirected, this field will be empty.
duration
Positive Integer or Zero
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 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 will always be populated.
destDeviceName
Text String
Specifies text string that identifies the name of the destination device.
Default - empty string "" or null. If the original device does not have a name, this field will be empty.
origCalledPartyRedirectReason
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.
Default - 0.
lastRedirectRedirectReason
Integer
Identifies the last redirect reason for redirection.
See the "Redirect Reason Codes" section for a complete list of the codes.
Default - 0.
destConversationID
Integer
Specifies unique identifier that is used to identify the parties of a conference call.
Default - 0.
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 "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
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 "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
origCalledPartyRedirectOnBehalfOf
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 complete list of the codes.
Default - 0.
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 "4."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
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 "10."
See the "OnBehalfof Codes" section for a complete list of the codes.
Default - 0.
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
Default - This field should always be populated.
Comment
TextString
This field allows features to add text to the CDR records. This text can describe details about the call.
For example, the following field flags malicious calls.
Tag—CallFlag
Value—MALICIOUS
Default - This empty string "" or null.
callingPartyLoginUserID
Text String
Identifies the calling party user login ID.
Default: This empty string, "", or null.
finalCalledPartyLoginUserID
Text String
Identifies the final called party user login ID.
Default: This empty string, "", or null.
authCodeDescription
Text String
Description of the authorization code. For security purposes, the authorization code does not get written to the CDR; the authorization description and level get written instead.
Default: This empty string, "", or null.
authorizationLevel
0, integer
The level of the authorization code. For security purposes, the authorization does not get written to the CDR; the authorization description and level get written instead.
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.
Default: This empty string, "", or null.
"9999999999999999" indicates an invalid CMC in CDR for a zero duration call.
CMR Fields (Diagnostic)
The following table contains the fields, range of values, and field descriptions of the CMRs.
Guest
