Guest

Cisco Unified Communications Manager (CallManager)

Cisco Unified CallManager Call Detail Record Definitions

Table Of Contents

Cisco Unified CallManager 5.0 Call Detail Record Definitions

Contents

New and Changed Information

Cisco Unified CallManager CDR Configuration

Service Parameters

Enterprise Parameters

Cisco Unified CallManager CDR Overview

CDR Management

CDR Agent

CDR Repository Manager

CDR onDemand Service

Types of Call Information Records

Global Call Identifier

Number Translations

Partitions and Numbers

Timestamps

Call Release Cause Codes

IP Addresses

Call Types

Successful On-Net Calls

Abandoned Calls

Calls with Busy or Bad Destinations

Forwarded or Redirected Calls

Pickup Calls

Pickup

Auto Pickup

Transferred Calls

Transfer Without Consultation

Transfer with Consultation

Conference Calls

Precedence Calls (MLPP)

Malicious Calls

Conference Drop Any Party

Immediate Divert (to Voicemail)

Video Calls

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

Multiple Destinations

Personal Assistant Conferencing

Call Scenarios

Normal Calls (IP Phone to IP Phone)

Examples of Successful Calls

Abandoned Calls

Examples of Abandoned Calls

Calls With Busy or Bad Destinations (Unsuccessful Calls)

Examples of Unsuccessful Calls

Forwarded Calls

Forwarding Examples

Call Pickup

Auto Pickup

Auto Pickup Example

Legacy Call Pickup

Transferred Calls

Transfer Examples

Conference Calls

Conference Example

Call Park

Call Park Pickup

Call Park Example

Call Park Reversion

Call Park Reversion Example

Precedence Calls (MLPP)

Precedence Call Examples

Malicious Calls

Malicious Call Example

Immediate Divert (to Voicemail)

IDivert Examples

Barge

Barge Examples

cBarge

cBarge Examples

Video Calls

Forced Authorization Code (FAC)

FAC Example

Client Matter Code (CMC)

CMC Example

Call Secured Status

Examples

DTMF Method

DTMF Call Examples

RSVP

RSVP Call Examples

Redirection (3xx) Calls

Redirection (3xx) Examples

Replaces Calls

Refer Calls

CDR Field Descriptions

CMR Field Descriptions (Diagnostic)

K-Factor Data in CMRs

Codec Types

Call Release Cause Codes

Redirect Reason Codes

OnBehalfof Codes

Related Documentation

Obtaining Documentation

Cisco.com

Documentation DVD

Ordering Documentation

Documentation Feedback

Cisco Product Security Overview

Reporting Security Problems in Cisco Products

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information


Cisco Unified CallManager 5.0 Call Detail Record Definitions


This document describes the format and logic of the call detail records (CDRs) and call management records (CMRs) that the Cisco Unified CallManager Release 5.0 (and later) system generates. An integration partner can use this information for post-processing activities such as generating billing records and network analysis. This document describes how to access the CDR/CMR files, how to interpret fields in the files, and some of the known issues.

When you install your system, CDRs and CMRs are disabled by default. You can enable or disable CDRs or CMRs at any time the system is in operation. You do not need to restart Cisco Unified CallManager for the change to take effect. The system responds to all changes within a few seconds.

Contents

This document covers the following topics:

New and Changed Information

Cisco Unified CallManager CDR Configuration

Cisco Unified CallManager CDR Overview

Call Types

Interpreting Cisco Personal Assistant Data in the CDRs

Personal Assistant Call Types

Call Scenarios

CDR Field Descriptions

CMR Field Descriptions (Diagnostic)

K-Factor Data in CMRs

Codec Types

Call Release Cause Codes

Related Documentation

Obtaining Documentation

Obtaining Technical Assistance

Obtaining Additional Publications and Information

New and Changed Information

New features or changes for CDRs/CMRs that are pertinent to a specified release of Cisco Unified CallManager are described in the Release Notes for the corresponding release.


Note In the following sections, references to CDR files imply both CDR and CMR files.


Cisco Unified CallManager CDR Configuration

The following sections define the current CDR configuration parameters.

Service Parameters

These values are set to False by default. You must enable these configuration items separately on every server in a cluster. You can configure these parameters on the Service Parameters Configuration page in the Cisco Unified CallManager Administration. To access the Service Parameters Configuration page, open Cisco Unified CallManager Administration and select Service -> Service Parameters.

CdrEnabled - This parameter enables or disables CDRs. If this parameter is false (the default value), Cisco Unified CallManager will not generate CDRs. If this parameter is true, CDRs are generated.

CdrLogCallsWithZeroDurationFlag - This parameter enables logging of CDRs for calls which were never connected, or which lasted less than one second. If this parameter is false, only calls with talk time greater or equal to 1 second and/or failed calls generate CDRs. If this parameter is true, all call will generate a CDR. In this case, going off hook and immediately back on hook will generate a CDR.

CallDiagnosticsEnabled - This parameter enables and disables CMRs. If the parameter is false, Cisco Unified CallManager will not generate CMRs. If this parameter is true, CMRs will be generated for all supported devices. Currently, only some IP phone and some MGCP devices support the diagnostic data.

Enterprise Parameters

You can configure these parameters on the Enterprise Parameters Configuration page in the Cisco Unified CallManager Administration. To access the Enterprise Parameters Configuration page, open Cisco Unified CallManager Administration and select System -> Enterprise Parameters.

CDRFlatFileInterval - This is a parameter for Cisco Unified CallManager that determines the number of seconds to write to a CDR file before opening another one. For example, if this CDRFlatFileInterval is 1 minute (default), Cisco Unified CallManager will write a minutes worth of CDRs into each file. If the CDRFlatFileInterval is 60 minutes, then Unified CM will write an hours worth of CDRs into each file.

Cluster ID - This parameter uniquely identifies the cluster. The Cluster ID is used both in the filename or the CDR/CMR flat files and in the CDR itself.

Cisco Unified CallManager CDR Overview

This section provides a brief description of how CDRs are generated and managed in Cisco Unified CallManager. The changes and new features are described in the following subsections.

CDR Management

The CDR Management (CDRM) feature is a background application that supports the following capabilities:

pushes CDR/CMR files from individual nodes within a cluster to the CDR Repository node

sends CDR/CMR files from the CDR Repository node to up to three customer billing servers

allows third party applications to retrieve CDR/CMR files on demand through a SOAP interface

monitors disk usage of CDR/CMR files on the CDR Repository node

periodically deletes CDR/CMR files that have been successfully delivered

CDRM consists of the CDR Agent, CDR Repository Manager, and CDR onDemand Service.

CDR Agent

As part of the CDRM feature, a resident component on every Unified CM node within a Cisco Unified CallManager cluster is the CDR Agent. On a Unified CM node where both Cisco Unified CallManager and the CDR Agent are running, Cisco Unified CallManager writes the CDRs into CDR flat files (CSV format) with a special control character ("_") prefixed to the filename by the call processing module to indicate that the file is not available for transfer. If this control character is not present, then the file is assumed to be available for transfer and is sent to the designated CDR Repository node. Upon successful transfer, the local copy of the file is deleted.

Reliability is given the highest priority for the CDRM feature. CDRs are very important financial data, so the goal of this feature is to guarantee that no CDR is lost. The Cisco Unified CallManager nodes within a cluster continuously write CDRs to flat files, close existing flat files, and open new ones. The number of records that are written varies by the type of call and significant changes that occur during a call, such as ending the call, transferring the call, redirecting the call, splitting the call, or joining the call.

The CDR Agent periodically polls the files in a designated path (/var/log/active/cm/cdr, which is a softlink to /common/log/cdr) every 6 seconds to determine if a CDR file is available for transfer to the CDR Repository node. The advantage of having a short interval is that as soon as a file is available it can be delivered immediately to the CDR Repository node.

The CDR Agent uses a standard SFTP utility, sftp_connect.sh, to transfer CDR files from the Cisco Unified CallManager nodes to the CDR Repository node. The utility requires a batch file as input and generates a log file indicating the results of the requested actions. The CDR Agent creates unique batch and log files for each transfer session.

In case of an SFTP failure, the component on Cisco Unified CallManager repeatedly tries to make new connections until successful. When CDR files are accumulated due to a lack of an SFTP connection, all leftover CDR files will be sent to the CDR Repository node immediately after connectivity is restored.

When the CDR Agent starts or restarts, it checks whether there are any CDR files remaining from the previous life cycle and sends them over to the CDR Repository node.

Should SFTP fail to transfer CDR files to the CDR Repository node, an alarm is raised.

CDR Repository Manager

Within a Cisco Unified CallManager cluster, one instance of the CDR Repository Manager runs on the CDR Repository node. It manages CDR files received from the Cisco Unified CallManager nodes and periodically sends the files to the specified customer/third party billing servers via an (s)FTP connection, as illustrated in Figure 1.

Figure 1 CDR Management Feature

When the file arrives on the CDR Repository node, the CDR Repository Manager detects it. The file is archived in a directory dedicated to the date indicated by the UTC timestamp placed in the file name when the file was created.

If any external billing server is specified in CDRM configuration, a soft link to the file is created in a directory designated to the destination. The file sender component of the CDR Repository Manager detects this soft link and sends the file to the destination with the specified method, either SFTP or FTP. If the delivery is successful, the soft link in the destination directory is removed.

CDRM supports a BHCC (Busy Hour Call Completion) rate of 60K on a single node. Every Cisco Unified CallManager node can generate one CDR file and one CMR file every minute for up to one hour. If there are 16 Unified CM nodes within a Cisco Unified CallManager cluster, then the minimum hard disk space requirement for the CDR Repository is 36GB. The maximum disk space used for storage of CDR files on the CDR Repository node is user-configurable through provisioning.

The File Manager component of the CDR Repository Manager is scheduled to run daily. When the File Manager runs, it deletes files with dates outside the configured preservation duration. It also checks if disk usage has exceeded the high water mark. If so, CDR files will be deleted until the low water mark is reached, starting with the oldest files. However, if any CDR file to be deleted has not been successfully sent to the specified billing server, it is left in the CDR Repository and a notification or alarm is raised. A flag file is created during the configured maintenance window, which denies access to the CDR files for third party billing applications and the CDR onDemand Service. The flag file is removed after the maintenance window has expired.

For detailed procedures for configuring the CDR Repository Manager and customer billing servers, see the "CDR Repository Manager Configuration" chapter in the Cisco Unified CallManager CDR Analysis and Reporting Administration Guide.

CDR onDemand Service

The CDR onDemand Service is a SOAP/HTTPS-based service that runs on the CDR Repository node. It receives SOAP requests for CDR file name lists based on a user-specified time interval (up to a maximum of one hour) and returns all lists fitting the time duration specified in the request.

The CDR onDemand Service can also handle requests for delivering a specific CDR file to a specified destination through (s)FTP. The CDR onDemand service can only be activated on the CDR Repository node as it has to access the CDR files in the repository. This service is prohibited during the maintenance window. For detailed information on the CDR onDemand Service, see the Cisco Unified CallManager Developers Guide for Release 5.0(4).

Types of Call Information Records

Cisco Unified CallManager generates two different types of call information records: Call Detail Records (CDRs) and Call Management Records (CMRs). CDRs store information about the endpoints of the call and other call control/routing aspects. CMRs contain diagnostic information about the quality of the streamed audio and/or video of the call. More than one CMR can exist per CDR.

The CDRs relate to the CMRs via the two globalCallID columns:

globalCallID_callManagerId

globalCallId_callId

When the Call Diagnostics service parameter is set to true, the system generates up to two CMRs 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 ASCII files at the end of the call. Only completed calls and failed calls generate CDRs and CMRs. Cisco Unified CallManager does not perform any post processing on CDRs or CMRs.

Global Call Identifier

The Cisco Unified CallManager allocates a global call identifier (GlobalCallID) each time that a Cisco Unified IP Phone is taken off hook or a call is received from a gateway.

The CDR table (Table 1) lists CDRs that are written 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 also 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.

Table 1 Sample CDR Table

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 the GlobalCallID 4 call ended.

Number Translations

The Cisco Unified CallManager can perform translations on the digits that a user dials. The translated number, not the actual dialed digits, appears in the CDR.

For example, many companies translate "911" calls to "9-911," so the caller does not need to dial an outside line in an emergency. In these cases, the CDR contains "9911" even though the user dials "911."


Note Gateways can 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 that is referenced, if partitions are defined. When partitions exist, fully identifying a phone requires both values because extension numbers may not be unique.

The Partition field stays empty when a call ingresses through a gateway. When a call egresses through a gateway, the Partition field shows the partition to which the gateway belongs.

If the dial plan allows callers to use the # key for speed dialing, the # key goes into the database when it is used. For example, the Called Party Number field may contain a value such as "902087569174#."

In this release, the Party Number fields may include SIP URIs instead of the traditional calling/called party number.

CDRs use the Partition/Extension Numbers shown in Table 2:

Table 2 Partition/Extension Numbers in CDRs 

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 that is associated with the CallingPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

For calls that ingress through a gateway, this field remains blank.

originalCalledPartyNumberPartition

This number identifies the partition name that is associated with the OriginalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.

finalCalledPartyNumberPartition

This number identifies the partition name that is associated with the FinalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.

lastRedirectDnPartition

This number identifies the partition name that is associated with the LastRedirectDn field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.

For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.


Timestamps

Timestamps within a CDR 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 Linux OS.

The CDR includes the UTC timestamps shown in Table 3:

Table 3 UTC Timestamps in CDRs

Field
Description

dateTimeOrigination

For outgoing calls, this field designates the time the device goes off hook.

For incoming calls, this field designates the time the SETUP message is received.

dateTimeConnect

This field designates the time the devices connect and speech begins. This field shows a zero if the call never connects.

dateTimeDisconnect

This field designates the time the call disconnects. This field shows a zero if the call never connects.


Call Release Cause Codes

The CDR includes two call release cause codes: OrigCause and DestCause. When the originating party releases the call, the OrigCause gets populated. When the terminating party releases the call, or the call is rejected, the DestCause gets populated. When unpopulated, the release cause code value shows zero.

The "Call Release Cause Codes" section lists the call release cause code values per ITU specification Q.850. For on-net call legs, the Cisco Unified CallManager determines the call release cause code value. For off-net call legs, the far-end switch determines the call release cause code value.

IP Addresses

The CDR file displays IP addresses 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 decimal notation.


Note The file displays a negative number when the low byte of the IP address has the most significant bit set.


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


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

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

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

Step 4 The IP address displays in the dotted decimal format:
192.168.18.188


When working with CDRs, you may want to read other tables in the CAR database to obtain information about the type of device in each CDR because the correlation between devices in the Device table and the IP address that is listed in the CDR is not straightforward.

Call Types

A successful call between two parties logs one CDR. Each CDR contains all fields, but some fields may not be used. If a field is not used, see the default values in the CDR definitions table. When supplementary services are involved in a call, additional CDRs may be written.

In addition to the CDR, a call may involve one CMR per endpoint. In a successful call between two parties who are each using an IP phone, two CMRs are written: one for the originator and one for the destination of the call.

This section describes the records written for different call types in the system.

Successful On-Net Calls

Abandoned Calls

Calls with Busy or Bad Destinations

Forwarded or Redirected Calls

Pickup Calls

Transferred Calls

Conference Calls

Precedence Calls (MLPP)

Malicious Calls

Conference Drop Any Party

Immediate Divert (to Voicemail)

Video Calls

Successful On-Net Calls

A successful call between two Cisco Unified IP Phones generates a single 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


Abandoned Calls

The logging of calls with zero duration represents an optional action. If logging calls with zero duration is enabled, the following actions occur:

All calls generate a CDR.

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 that are associated with them, the destIpAddr, and the dateTimeConnect fields all remain blank. All calls that are not connected have a duration of 0 second. When a call is abandoned, the cause code contains 0.

If the user dials a directory number and abandons the call before it connects, the FirstDest and FinalDest fields and their associated partitions contain the directory number and the partition to which the call would have been extended. The DestIp field remains blank and the duration specifies 0 second.

The following table contains two examples:

A—Extension 2001 going off hook then on hook (when the CdrLogCallsWithZeroDurationFlag is set at True).

B—Extension 2001 calls 2309 but 2001 hangs up (abandons) the call before it is answered.

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

A

2001

Accounts

   

16

0

0

B

2001

Accounts

2309

 

16

0

0


Calls with Busy or Bad Destinations

These calls will all be logged as a normal call with all relevant fields containing data. The Calling or Called Party Cause fields contain a cause code indicating why the call was not connected, and the Called Party IP and Date/Time Connect fields are blank. All unsuccessful calls are logged, even if zero duration calls are not being logged (CdrLogCallsWithZeroDurationFlag set at True or False, a duration of zero, and a DateTimeConnect value of zero).

The following table contains three examples:

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

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

C—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
Duration

B

2001

Accounts

902920262226

PSTN

0

17

0

C

2001

Accounts

902920100000

PSTN

0

1

0

D

2001

Accounts

902920262226

PSTN

0

38

0


Forwarded or Redirected Calls

Forwarded calls generate a single CDR and show the Calling Party, Original Called Number, Last Redirecting Number, Final Called Number, and the associated partitions. 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 CDRs for forwarded calls match those for normal calls, except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields contain the directory number and partition for the destination that was originally dialed by the originator of the call. If the call gets forwarded, the finalCalledPartyNumber and finalCalledPartyNumberPartition fields differ and contain the directory number and partition of the final destination of the call.

Also, when a call is forwarded, the lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that forwarded or redirected the call.

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 messaging

 
Calling
Party
Original Called Party
Original Called Partition
Final
Called
Party
Final
Called
Partition
Last
Redirect
Party
Last
Redirect
Partition
Duration
OriginalCalled
Party Redirect OnBehalfOf
Last Redirect
Redirect OnBehalfOf

A

02920262227

2001

ACNTS

2309

MKTG

2001

ACNTS

120

5

5

B

02920262227

2001

ACNTS

6000

VMAIL

2309

MKTG

60

5

5


Pickup Calls

Cisco Unified CallManager includes two pickup modes: Pickup and Auto Pickup. This section describes the CDRs for each mode.

Pickup

Pickup calls work like forwarded calls. The CDRs for pickup calls match those for normal calls except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields contain the Directory Number and partition for the destination that was originally dialed by the originator of the call.

If the call is picked up, the finalCalledPartyNumber and finalCalledpartyNumberPartition fields will differ and contain the Directory Number and partition of the phone that picked up the call. Also, when a call is picked up, the lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that redirected this call.

The origTermination, destTermination, lastRedirect, and Join OnBehalfOf fields contain 16 (Pickup) and the redirect reason field contains 5 (Pickup).

Pickup CDRs look the same for all types of pickup: Pickup, Group Pickup and Other Pickup.

Pickup Example

1. A call comes in from the PSTN to extensions 2000, 2001 and 2002, which are in the same pickup group.

2. Extension 2002 picks up the call that is ringing on 2001.

3. Extension 2002 answers the call, and the call connects between the PSTN caller and extension 2002.

Call ID
Orig Cause
Calling Party
Dest Cause
Original Called Party
Final Called Party
Last Redirect Party
Orig Termina-tion On
BehalfOf
Dest Termina-tion On BehalfOf
Last Redirect On
BehalfOf
Last Redirect Reason
Join On
BehalfOf

22

0

9728131234

16

2001

2002

2001

16

16

16

5

16


Auto Pickup

Auto Pickup works like call pickup with auto answer. The call connects automatically so there is no need for the last answer softkey press. The system generates two CDRs for Auto Pickup, and these CDRs have the same Call ID.

The first CDR is generated for the original call. This CDR will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields equal to 16 (Pickup), which indicates that the call terminated on behalf of the pickup feature.

The second CDR represents the final call after it was picked up. This CDR will have the lastRedirectOnBehalfOf and the joinOnBehalfOf fields set to 16 (Pickup), which indicates that the system joined the call on behalf of the Pickup feature. The lastRedirectReason contains the redirect reason of 5 (Pickup).

Auto Pickup CDRs look the same for all types of auto pickup: Auto Pickup, Auto Group Pickup, and Auto Other Pickup.

Auto Pickup Example

1. A call comes in from the PSTN to extension 2001; 2002 and 2002 are in the same pickup group.

2. Extension 2002 picks up the call that is ringing on 2001.

3. The call automatically connects between the PSTN caller and extension 2002.

Call ID
Orig Cause
Calling Party
Dest Cause
Original Called Party
Final Called Party
Last Redirect Party
Orig Termina-tion On BehalfOf
Dest Termina-tion On BehalfOf
Last Redirect On
BehalfOf
Last Redirect Reason
Join On
BehalfOf

11

126

9728131234

126

2001

2001

2001

16

16

0

0

0

11

0

9728131234

16

2002

2002

2001

16

16

16

5

16


Transferred Calls

A single CDR cannot show all the data necessary for a call transfer because it is too complex. Each time a call is transferred, the Cisco Unified CallManager terminates the CDR for that call and initiates a new CDR.

Calls that are transferred have multiple CDRs logged for them, as follows:

1. Original call from party A to party B.

2. Call from the transferring party (party A or B) to the transfer destination (party C).

3. Call from the transferred party (party A or B) to the destination (party C).

The first CDR is the original placed call. The second CDR is the setup call (consultative/announcement) used to initiate the transfer. The third CDR is the transferred call itself. The first two CDRs have the origCause_value and destCause_value set to Split (126).

They also have the origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields set to Transfer (10) to indicate that these calls were involved in a transfer. The transferred leg of the call has the joinOnBehalfOf field set to Transfer (10) to indicate this call resulted from a transfer. Therefore, all legs of the transfer can be tied back to a single call.

The following examples are not an exhaustive set, and are intended to illustrate the records that would be generated under the stated circumstances. This is intended to help clarify what records are generated on transferred calls.

Example 1

A calls B, A transfers B to C. The three calls logged are:

1. Call from A to B

2. Call from A to C

3. Call from B to C

If the call was a blind transfer, then the call from A to C will have a duration of zero seconds. If the call was a consultation transfer, then all calls will have non-zero durations. Original Called Party and Call Party Number fields are the same.

Example 2

A calls B, B transfers A to C. The three calls logged are:

1. Call from A to B

2. Call from B to C

3. Call from A to C

If the call was a blind transfer, then the call from B to C will have a duration of zero seconds. If the call was a consultation transfer, then all calls will have non-zero durations. Original Called Party and Call Party Number fields are the same.

Example 3

A calls B, B transfers A to C on a blind transfer. C is Call Forwarded on No Answer to D. The calls logged are:

1. Call from A to B

2. Call from B to C

3. Call from A to D

Since the call was a blind transfer, then the call from B to C has a duration of zero seconds. The call from A to D will have the Original Called Party field set to "C", and the Called Party Number field set to "D".

Transfer Without Consultation

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 (duration is zero) to extension 2002.

C—Extension 2001 completes the transfer, dropping out of the call, and 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
OrigCall Term On BehalfOf
DestCall Term On BehalfOf
Join On BehalfOf
Duration

A

2001

ACNTS

101

3071111

PSTN

102

126

126

10

10

0

120

B

2001

ACNTS

103

2002

ACNTS

104

126

126

10

10

0

0

C

3071111

PSTN

102

2002

ACNTS

104

0

16

0

0

10

350


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 Unified 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 table contains 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
Dest Cause
OrigCall Term On BehalfOf
DestCall Term On BehalfOf
Join On BehalfOf
Duration

A

2001

ACNTS

101

3071111

PSTN

102

126

126

10

10

0

120

B

2001

ACNTS

103

2002

ACNTS

104

126

126

10

10

0

30

C

3071111

PSTN

102

2002

ACNTS

104

0

16

0

0

10

350


Conference Calls

Two major operational factors exist for conference call CDRs:

1. When the conference decreases to two parties, the two parties connect directly and release the conference resource. This change generates an additional CDR for the call between the last two parties in the conference call.

For example, if four people are connected in a conference call (Amy, Dustin, Spencer, Ethan), when Ethan hangs up three people remain in the conference call that is connected to the conference bridge (Amy, Dustin, Spencer). When Spencer hangs up, only two people remain in the conference call (Amy and Dustin). The system joins Amy and Dustin directly and the conference resource gets released. Directly joining Amy and Dustin creates an additional CDR between the last two parties in the conference.

2. The conference controller information is added to the comment field in the CDR. This information identifies the conference controller. No need now exists to examine the consultation call to determine who is the conference controller. The following example shows this information:

Comment field = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD"

The conference controller DN + conference controller device name uniquely identifies the conference controller. A need for the device name exists in the case of shared lines.

If the call is involved in multiple conference calls, the comment field contains multiple conference controller information. This may occur when the conference goes down to two parties, and one of these parties starts another conference. If this is the case, the last conference controller information in the comment field identifies the conference controller.

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

One CDR for the original call

Three CDRs for the parties that are connected to the conference

One CDR for each setup call

One CDR for the final two parties in the conference

The setup calls can be associated with the correct call leg in the conference by examining the calling leg ID and the called leg ID.

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

The call legs that are connected to the conference have the following values for these fields:

finalCalledPartyNumber—represents a conference bridge "b0019901001"

origCalledPtyRedirectOnBehalfOf—set to Conference (4)

lastRedirectRedirectOnBehalfOf—set to Conference (4)

joinOnBehalfOf—set to Conference (4)

comment—identifies the conference controller

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

3071111 hangs up and leaves 2001 and 2309 in the conference. Because only two participants remain in the conference, the conference features directly join the two, and they talk for another 55 seconds.

Calling Party
Calling Partition
Calling Leg
Original Called Party
Original Called Partition
Called Leg
Final Called Party
Final Called Partition
Last Redirect Party
Last Redirect Reason
Orig Conversation
Id

2001

ACNTS

101

2309

MKTG

102

2309

MKTG

2001

0

0

2001

ACNTS

101

2309

MKTG

115

b0029901001

 

b0029901001

0

1

2309

ACNTS

101

b0029901001

 

116

b0029901001

 

b0029901001

0

1

3071111

PSTN

101

b0029901001

 

117

b0029901001

 

b0029901001

0

1

2001

ACNTS

105

3071111

PSTN

106

3071111

PSTN

3071111

0

0

2001

ACNTS

101

2309

MKTG

102

2309

MKTG

b0029901001

98

0v


OrigCall
Termination OnBehalfOf
DestCall
Termination OnBehalfOf
Original
CalledParty
Redirect
OnBehalfOf
Last
Redirect
OnBehalfOf
Join
OnBehalfOf
Duration
Comment

4

4

0

0

0

60

 

12

0

4

4

4

360

ConfControllerDn=2001;ConfController DeviceName=SEP0003E333FEBD

12

0

4

4

4

360

ConfControllerDn=2001;ConfController DeviceName=SEP0003E333FEBD

4

4

4

4

4

360

ConfControllerDn=2001;ConfController DeviceName=SEP0003E333FEBD

4

4

0

0

0

20

 

12

42

0

4

4

55

ConfControllerDn=2001;ConfController DeviceName=SEP0003E333FEBD


Precedence Calls (MLPP)

Precedence calls take place the same as other calls except the precedence level fields get set in the CDR. Also, when a higher-level precedence call preempts a call, the cause codes indicate the reason for the preemption.

The following table contains an example CDR for this scenario:

User A (2001) calls another IP phone by dialing a precedence pattern (precedence level 2).

User A (2001) calls another IP phone by dialing a precedence pattern (precedence level 3).

User A receives a higher-level precedence call from another network (precedence level 1).

The higher precedence level call preempts the first call.

Calling
Party
Calling
Partition
Origin Precedence Level
Original Called Party
Original Called Partition
Dest Precedence Level
Orig Cause
Dest Cause

2001

CMD

2

826001

FIRE

2

0

16

2001

CMD

3

836001

FIRE

3

0

16

9728552001

GEN

1

6001

FIRE

1

16

0

2001

CMD

2

826001

FIRE

2

0

9

9728552001

GEN

1

826001

FIRE

1

0

16


Malicious Calls

When a call gets identified as a malicious call (button press), the local Cisco Unified CallManager network flags the call. The Comment field flags the malicious call.

The following table contains an example CDR of a customer call that gets marked as malicious.

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

9728552001

CUST

5555

ACNTS

0

16

"callFlag=MALICIOUS"


Conference Drop Any Party

The Conference Drop Any Party feature terminates calls that look the same as other calls except for a new cause code. The cause code identifies calls that get terminated by this feature.

The following table contains an example CDR for a call that was connected to a conference and dropped by this feature.

Calling
Party
Calling
Partition
Original Called Party
Orig Cause
Original Called Partition
Called Leg
Dest Cause
Final Called
Party
Final Called
Partition
Last Redirect Party

2001

ACNTS

2309

0

MKTG

102

16

2309

MKTG

2001