Guest

Cisco Unified Communications Manager (CallManager)

Cisco CallManager Call Detail Record Definition for Release 3.3(2)

  • Viewing Options

  • PDF (573.6 KB)
  • Feedback
Cisco CallManager 3.3(2) Call Detail Record Definition

Table Of Contents

Cisco CallManager 3.3(2) 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

Interpreting Cisco Personal Assistant Data in the CDRs

Personal Assistant Call Types

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 Going Directly to Destination With Rule to Forward the Calls to a Different Destination

Multiple Destinations

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 Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)

Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)

Conferencing

Known Issues

Troubleshooting

CDRs Fail To Insert

Symptom

Probable Cause

Corrective Action

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 3.3(2) Call Detail Record Definition


This document describes the format and logic of the call detail records (CDRs) generated by the Cisco CallManager Release 3.3(2) 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

Interpreting Cisco Personal Assistant Data in the CDRs

Known Issues

Troubleshooting

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.

Microsoft SQL Server 2000 Service Pack 2 replaces Microsoft SQL 7.0 and is configured with only TCP and for mixed mode authentication. Named Pipes are no longer configured.


Note SQL Authentication is supported although Windows NT Authentication is recommended.


The connection logic in the database layer is changed to use Windows NT authentication. All database layer connections are DSN based and use an Open Database Connectivity (ODBC) system DSN, CiscoCallManager. For more information, see the "Reading Records" section.

Any third party application connecting to the database themselves can change the way they connect. Beyond that, everything else remains the same. Both previous and current connections work.

Web applications that do not require an NT login and use the database layer, such as CCMUser, are configured to 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:

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 the "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 the following service parameters, 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 the 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.


You can configure service parameters on the Service Parameters Configuration page in Cisco CallManager Administration.

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.

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 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 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 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 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 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 shows a zero if the call never connects.


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 2000 Service Pack 2 database via ODBC. The install configures an ODBC system DSN 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 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 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. 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 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. 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 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 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 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 gateway.

For intercluster calls, this field specifies the address of the remote Cisco CallManager.

The "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 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. The "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. The "Cause Codes" section lists the valid values per Q.850.

For calls cleared by the terminating party, this field specifies zero.

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.

origMediaTransportAddress_Port

Positive Integer

Identifies the IP port number associated with the OrigMediaTransportAddress_IP field

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:

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

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

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.

This field can remain zero if the call does not complete.

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

For intercluster calls, this field specifies the address of the remote Cisco CallManager.

The "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. The "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. The "Cause Codes" section lists the valid values per Q.850.

For calls cleared by the originating party, this field equals zero.

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

For intercluster calls, this field shows the address of the remote Cisco IP Phone.

The "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 or Zero

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

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 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 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 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 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 "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10."

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 "12" for Device. If the call is terminated because of a transfer, the OnBehalfOf code shows "10."

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

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

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

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

The logging of calls with zero duration is optional. If logging calls with zero duration is enabled, the following occurs:

All calls generate a CDR record.

If the call was abandoned, such as when a phone is taken off hook and placed back on hook, various fields do not contain data. In this case, the "originalCalledPartyNumber," "finalCalledPartyNumber," the partitions associated with the them, the "destIpAddr," and the "dateTimeConnect" fields are blank. All calls that are not connected have a duration of zero seconds. When a call is abandoned, the cause code is 0.

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

Incoming calls are identified by the origDeviceName. If origDeviceName matches any of the Gateway device names, it is an incoming call. 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

All failed outgoing calls are logged whether they have a CdrLogCallsWithZeroDurationFlag set at True or False, 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 (when the CdrLogCallsWithZeroDurationFlag is set at only True).

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

101

b0029901001

 

116

b0029901001

   

3071111

PSTN

101

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


Interpreting Cisco Personal Assistant Data in the CDRs

The Cisco Personal Assistant application can selectively handle incoming calls and assist with outgoing calls. This section provides a brief overview of Personal Assistant and describes the Personal Assistant call types with example CDR scenarios.

Personal Assistant provides the following features:

Rule-Based Call Routing

Personal Assistant can forward and screen incoming calls based on rules that users devise. Personal Assistant can handle ncoming calls according to caller ID, date and time of day, or the user meeting status based on the user calendar (such as office hours, meeting schedules, vacations, holidays, and so forth). Personal Assistant can also selectively route calls to other telephone numbers. Thus, Personal Assistant can route an incoming call to a desk phone, to a cell phone, home phone, or other phone, based on the call routing rules that users create. An incoming call can even generate an e-mail-based page.

Speech-Enabled Directory Dialing

Personal Assistant allows users to dial a phone number by speaking the called person's name. Personal Assistant then obtains the telephone number of that person from the corporate directory or personal address book.

Speech-Enabled Voice Mail Browsing

Users can use voice commands to browse, listen to, and delete voice mail messages.

Speech-Enabled Simple Ad Hoc Conferencing

Users can initiate conference calls by telling Personal Assistant to set up a conference call with the desired participants.

Personal Assistant Call Types

Personal Assistant Direct Call

A Personal Assistant direct call acts similar to the Transfer without Consultation call type. See the "Transfer Without Consultation" section.

The following table contains an example CDR for this scenario:

User A (2101) calls Personal Assistant route point (2000) and says "call User B."

The call transfers to User B (2105). In this case, User B did not configure any rules.


Note In the following example, 2000 represents the main Personal Assistant route point to reach Personal Assistant; 21XX represents the Personal Assistant interceptor route point; and 2001 - 2004 represents the media port.


In all cases, the calling number is 2101.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2101

16777217

PAManaged

16777219

2004

Phones

2000

2004

16777221

Phones

16777222

2105

PAManaged

2105

2101

16777217

PAManaged

16777222

2105

PAManaged

2105


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023970182

2000

Phones

34

1023970182

2105

PAManaged

0

1023970191

2105

PAManaged

5


Personal Assistant Interceptor Going to Media Port and Transferring the Call

This scenario acts similar to Transfer without Consultation, and Forwarded Calls. See the sections on "Transfer Without Consultation" and "Forwarded Calls".

The following table contains an example CDR for this scenario:

User A (2101) dials 2105.

The Personal Assistant interceptor (21XX) picks up the call and redirects it to a media port (2002).

Personal Assistant processes the call according to the rules (if any) and transfers the call to the destination (2105), which has not configured any rules.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2002

16777234

Phones

16777285

2105

PAManaged

2105

2101

16777230

PAManaged

16777232

2002

PA

2105

2105

16777235

PAManaged

16777230

2101

" "

" "


.

Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023970478

2105

PAManaged

2

1023970478

21xx

" "

9

1023970483

" "

" "

5


Personal Assistant Interceptor Going Directly to Destination

This scenario can have two different cases: with no rules and with rules. The following tables contain examples of each case.

Personal Assistant Going Directly to Destination With No Rules

The following table contains an example CDR for this scenario:

User A (2101) dials 2105.

The Personal Assistant interceptor (21XX) picks up the call, processes according to the rules (if any), and redirects the call to the destination (2105).

The following table contains an example CDR for this scenario:

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2101

16777240

PAManaged

16777242

2105

PA

2105


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023970710

21XX

" "

8


Personal Assistant Going Directly to Destination With Rule to Forward the Calls to a Different Destination

The following table contains an example CDR for this scenario:

User A (2101) dials 2105.

The Personal Assistant interceptor (21XX) picks up the call and processes it according to the rules.

The Personal Assistant interceptor then redirects the call to the final destination (2110). In this case, 2105 configured a rule to forward the call to extension 2110.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2101

16777248

PAManaged

16777250

2110

PA

2105


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds

1023970922

21XX

" "

5


Multiple Destinations

This scenario can have several different cases. In each case, the User B (2105) configured a rule to reach him at extension 2110, or 2120. This rule could activate when a caller calls Personal Assistant route point (2000) and says "call User B" (direct case) or when the caller dials User B (2105) directly (interceptor case).

The following sections contain examples of each case.

Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)

The following table contains an example CDR for this scenario:

User A calls Personal Assistant and says "call User B."

User B answers the call at 2110 extension.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2004

16777262

Phones

16777263

2110

PAManaged

2110

2101

16777258

PAManaged

16777260

2004

Phones

2000

2110

16777263

PAManaged

16777258

2101

" "

" "


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023971303

2110

PAManaged

6

1023971303

2000

Phones

22

1023971312

" "

" "

9


Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)

The following table contains an example CDR for this scenario:

User A calls Personal Assistant and says "call User B."

User B answers the call at 2120 extension.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2001

16777269

Phones

16777270

2110

PAManaged

2110

2001

16777272

Phones

16777273

2120

PAManaged

2120

2101

16777265

PAManaged

16777267

2001

Phones

2000

2120

16777273

PAManaged

16777265

2101

" "

" "

2110

16777275

PAManaged

0

" "

" "

" "


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration

1023971456

2110

PAManaged

0

1023971467

2120

PAManaged

4

1023971467

2000

Phones

37

1023971474

" "

" "

7

1023971476

" "

" "

0


Personal Assistant Direct Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)

The following table contains an example CDR for this scenario:

User A calls Personal Assistant and says "call User B."

User B does not answer at either extension 2110 or 2120.

Personal Assistant transfers the call to the original destination (2105), and User B then answers at that extension.


Note The third destination in this case is 2105 (the original destination).


Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2002

16777281

Phones

16777282

2110

PAManaged

2110

2002

16777284

Phones

16777285

2120

PAManaged

2120

2101

16777277

PAManaged

16777279

2002

Phones

2000

2002

16777287

Phones

16777288

2105

PAManaged

2105

2101

16777277

PAManaged

16777288

2105

PAManaged

2105

2105

16777289

PAManaged

0

" "

" "

" "


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023971602

2110

PAManaged

0

1023971615

2120

PAManaged

0

1023971619

2000

Phones

38

1023971619

2105

PAManaged

0

1023971627

2105

PAManaged

7

1023971629

" "

" "

0


Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at First Destination)

The following table contains an example CDR for this scenario:

User A calls Personal Assistant and says "call User B."

User B answers the call at extension 2110.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2003

16777295

Phones

16777296

2110

PAManaged

2110

2101

16777291

PAManaged

16777293

2003

PA

2105

2110

16777296

PAManaged

16777291

2101

" "

" "


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023971740

2110

PAManaged

4

1023971740

21XX

" "

10

1023971749

" "

" "

9


Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Second Destination)

The following table contains an example CDR for this scenario:

User A calls Personal Assistant and says "call User B."

User B answers the call at extension 2120.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2004

16777302

Phones

16777303

2110

PAManaged

2110

2004

16777305

Phones

16777306

2120

PAManaged

2120

2101

16777298

PAManaged

16777300

2004

PA

2105

2120

16777306

PAManaged

16777298

2101

" "

" "


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023971815

2110

PAManaged

0

1023971824

2120

PAManaged

3

1023971824

21XX

" "

22

1023971832

" "

" "

8


Personal Assistant Intercept Multiple Destinations: 2110 and 2120 (Call Accepted at Third Destination)

The following table contains an example CDR for this scenario:

User A calls Personal Assistant and says "call User B."

User B does not answer at either extension 2110 or 2120.

Personal Assistant transfers the call to the original destination (2105), and User B then answers at that extension.


Note The third destination in this case is 2110 (original destination).


Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2001

16777312

Phones

16777313

2110

PAManaged

2110

2001

16777315

Phones

16777316

2120

PAManaged

2120

2101

16777308

PAManaged

16777310

2001

PA

2105

2001

16777318

Phones

16777319

2105

PAManaged

2105

2101

16777308

PAManaged

16777319

2105

PAManaged

2105


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023971923

2110

PAManaged

0

1023971936

2120

PAManaged

0

1023971940

21XX

" "

30

1023971940

2105

PAManaged

0

1023971953

2105

PAManaged

12


Conferencing

Personal Assistant conferencing acts similar to the Ad Hoc Conferences call type. For more information, see the "Conference Calls" section.

The following table contains an example CDR for this scenario:

User A calls Personal Assistant route point (2000) and says "conference User B (2105) and User C (2110)."

Personal Assistant conferences User B and C into User A conference.

Calling
Party Number
OrigLegCall Identifier
Calling Party Number Partition
DestLeg Identifier
Final Called Party Number
Final Called Party Number Partition
Original Called Party Number

2003

16777345

Phones

16777346

2105

PAManaged

2105

2101

16777340

PAManaged

16777342

2003

Phones

2000

2003

16777350

Phones

16777351

2002

PAManaged

2110

2003

16777342

Phones

16777347

2110

" "

b00110201001

2110

16777351

PAManaged

16777352

b00110201001

" "

b00110201001

2105

16777346

PAManaged

16777349

b00110201001

" "

b00110201001

2101

16777340

PAManaged

16777348

b00110201001

" "

b00110201001


Original Called Party Number Partition
Last Redirect DN
Last Redirect DN Partition
Duration (in seconds)

1023972575

2105

PAManaged

6

1023972576

2003

Phones

62

1023972595

2110

PAManaged

39

1023972601

b00110201001

" "

25

1023972609

b00110201001

" "

14

1023972610

b00110201001

" "

34

1023972610

b00110201001

" "

34


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.

Troubleshooting

This section covers an issue related to CDRs.

CDRs Fail To Insert

Symptom

A third party CDR application is installed and CDRs fail to insert.

Probable Cause

The issue may be caused by the third party CDR application.

Corrective Action

Alter all insert triggers for the third party application and change them to update triggers instead of insert triggers. This will help determine if the issue is due to the third party application.

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

These 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 this URL:

http://www.cisco.com

Translated documentation is available at this 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

You can order Cisco documentation in these 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 Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

You can submit comments electronically on Cisco.com. In the Cisco Documentation home page, click the Fax or Email option in the "Leave Feedback" section at the bottom of the page.

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

You can submit your comments by mail by using the response card behind the front cover of your document or by writing 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 online 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 with these tasks:

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

If you want to obtain customized information and service, you can self-register on Cisco.com. To access Cisco.com, go to this URL:

http://www.cisco.com

Technical Assistance Center

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

Cisco TAC inquiries 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.

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

Cisco TAC Web Site

You can use the Cisco TAC Web Site 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 this URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco service 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 this URL to register:

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

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

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

If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. 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 automatically opens a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this 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). When you call the center, please have available your service agreement number and your product serial number.