Guest

Cisco Unified Communications Manager (CallManager)

Cisco CallManager Call Detail Record Definitions for Release 3.2

  • Viewing Options

  • PDF (443.0 KB)
  • Feedback
Cisco CallManager Call Detail Record Definition

Table Of Contents

Cisco CallManager Call Detail Record Definition

Contents

Cisco CallManager CDR Overview

Cisco CallManager Configuration

Service Parameters

Enterprise Parameters

Global Call Identifier

Number Translations

Partitions and Numbers

Timestamps

Call Clearing Causes

IP Addresses

Working With CDRs

Writing Records

Reading Records

Removing Records

CDR Record Field Descriptions

CMR Fields (Diagnostic)

Codec Types

Cause Codes

OnBehalfCodes

Call Types

Successful On-Net Calls

Unsuccessful On-Net Calls

Incoming PSTN Calls

Outgoing PSTN Calls

Call Failures

Short Calls

Cisco IP Phone Failure During a Call

Forwarded Calls

Conference Calls

Meet-Me Conferences

Call Hold and Resume

Transfer Without Consultation

Transfer with Consultation

Known Issues

Related Documentation

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Cisco TAC Web Site

Cisco TAC Escalation Center


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 Configuration

Working With CDRs

CDR Record Field Descriptions

Call Types

Known Issues

Known Issues

Related Documentation

Obtaining Documentation

Obtaining Technical Assistance

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:

globalCallID_callManagerId

globalCallID_callId

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:

CdrEnabled—Enables or disables CDR records.

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.

CallDiagnosticsEnabled—Enables or disables CMRs.

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 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 following table contains a sample CDR:

GlobalCallID
Start Time
End Time

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

The CDR uses the following Partition/Extension Number:

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.


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:

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.


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

Procedure


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

Step 2 Reverse the hex bytes, as shown below:
CO A8 12 BC

Step 3 Convert the bytes from hex to decimal, as shown below:
192 168 18 188

Step 4 The IP address displays in the following format:
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:

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

Database
Tables
SQL User ID
Password
Capability

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

The following table defines all fields in the current CDR records.

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

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


Cause Codes

The following table contains cause codes that may appear in the Cause fields.

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.

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


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—A 60-second call terminated by the caller

B—A 60-second call cleared by the called party

 
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


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—On-net call, destination is engaged.

B—On-net call, destination rings out.

 
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


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:

A—Successful incoming PSTN call, cleared by caller (PSTN phone)

B—Successful incoming PSTN call, cleared by called party (Cisco IP Phone)

C—Call from PSTN to an invalid Cisco IP Phone extension

 
Calling
Party
Calling
Partition
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


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.

The following table contains these examples:

A—Successful outgoing PSTN call, cleared by caller (Cisco IP Phone)

B—Successful outgoing PSTN call, cleared by called party (PSTN phone)

C—Successful call to premium rate number

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

E—Successful call to mobile number

F—Successful call to operator

 
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


Call Failures

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.

The following table contains four examples:

A—Extension 2001 going off hook then on hook.

B—Call to PSTN number, party engaged (cause 17 = user busy).

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

 
Calling
Party
Calling
Partition
Original Called Party
Original Called Partition
Orig Cause
Dest Cause
DateTime
Connect
Duration

A

2001

Accounts

   

16

0

0

0

B

2001

Accounts

902920262226

PSTN

0

17

0

0

C

2001

Accounts

902920100000

PSTN

0

1

0

0

D

2001

Accounts

902920262226

PSTN

0

38

0

0


Short Calls

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.

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


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.

Calling
Party
Calling
Partition
Original Called Party
Original Called Partition
Orig Cause
Dest Cause
Duration

2001

Accounts

2309

Marketing

41

0

120


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.

The following table contains two examples:

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

 
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


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:

One CDR record for the original call

Three CDR records for the parties that are connected to the conference

One CDR record for each setup call

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:

finalCalledPartyNumber—Represents a conference bridge "b0019901001."

origCalledPtyRedirectOnBehalfOf—Set to Conference (4).

lastRedirectRedirectOnBehalfOf—Set to Conference (4).

joinOnBehalfOf—Set to Conference (4).

The original placed call and all setup calls that were used to join parties to the conference have the following values for the fields:

origCallTerminationOnBehalfOf—Set to Conference (4).

destCallTerminationOnBehalfOf—Set to Conference (4).

The following tables contain these examples:

Call from 2001 to 2309.

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.

The conference talks for 360 seconds.

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.

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


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.

 
Calling
Party
Calling
Partition
Original Called Party
Original Called Partition
Final Called
Party
Final Called
Partition
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


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

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


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.

The following table contains three examples:

A—Call from extension 2001 to a PSTN number, talking for 120 seconds.

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.

 
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


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.

The following tables contain three examples:

A—Call from extension 2001 to a PSTN number, talking for 120 seconds.

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.

 
Calling
Party
Calling
Partition
Calling
Leg
Original Called Party
Original Called Partition
Called Leg
Orig Cause

A

2001

Accounts

101

902920262226

PSTN

102

126

B

2001

Accounts

103

2002

Accounts

104

126

C

902920262226

PSTN

101

2002

Accounts

104

0


 
Dest Cause
Duration

A

126

120

B

126

30

C

16

120


Known Issues

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

Ad Hoc Conferences

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.

End-of-Call Records

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

IP to Device Name Translation

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.

On-Net vs Off-Net

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.

Off-Net Digits Dialed

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.

Transferred Calls

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.

Related Documentation

The following documents contain additional information related to CDRs:

CDR Analysis and Reporting Tool Guide

Cisco CallManager System Guide

Backing Up and Restoring Cisco CallManager

Obtaining Documentation

The following sections explain how to obtain documentation from Cisco Systems.

World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following URL:

http://www.cisco.com

Translated documentation is available at the following URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Ordering Documentation

Cisco documentation is available in the following ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click the Fax or Email option under the "Leave Feedback" at the bottom of the Cisco Documentation home page.

You can e-mail your comments to bug-doc@cisco.com.

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.

Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to

Streamline business processes and improve productivity

Resolve technical issues with online support

Download and test software packages

Order Cisco learning materials and merchandise

Register for online skill assessment, training, and certification programs

You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:

http://www.cisco.com

Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.

Inquiries to Cisco TAC are categorized according to the urgency of the issue:

Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:

http://www.cisco.com/register/

If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered, you can open a case online by using the TAC Case Open tool at the following URL:

http://www.cisco.com/tac/caseopen

If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.