Table Of Contents

Understanding Cisco Call Detail Records

CDR Processing

Cisco Unified Communications Manager 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 Termination Cause Codes

IP Addresses

Call Types

Successful On Net Calls

Abandoned Calls

Calls with Busy or Bad Destinations

Short Calls

Forwarded or Redirected Calls

Pickup Calls

Pickup

Auto Pickup

Transferred Calls

Transfer Without Consultation

Transfer with Consultation

Conference Calls

Meet-Me Conferences

Ad Hoc Conference Linking

Precedence Calls (MLPP)

Malicious Calls

Conference Drop Any Party

Immediate Divert (to Voice-Messaging System)

Video Calls

Call Monitoring and Call Recording

AAC and iLBC Calls

Mobility

Intercom

Original Calling Party on Transfer

Interpreting Cisco Personal Assistant Data in the CDRs

Personal Assistant Direct Call

Personal Assistant Interceptor Going to Media Port and Transferring the Call

Personal Assistant Interceptor Going Directly to Destination

Personal Assistant Interceptor Going to 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)

Personal Assistant Conferencing

Call Scenarios

Normal Calls (IP Phone to IP Phone)

Abandoned Calls

Calls With Busy or Bad Destinations (Unsuccessful Calls)

Forwarded Calls

Call Pickup

Pickup

Auto Pickup

Legacy Call Pickup

Transferred Calls

Conference Calls

Secure Meet-Me Conference

Ad Hoc Conference Linking

Conference Linking using Join

Conference Linking Using Transfer or Direct Transfer

Removing a Party From a Linked Conference

Removing a Party (Controller) From a Linked Conference

Removing the Linked Conference

Call Park

Call Park Pickup

Call Park Reversion

Precedence Calls (MLPP)

Malicious Calls

Immediate Divert (to Voice-Messaging System)

Barge

cBarge

Video Calls

Forced Authorization Code (FAC)

Client Matter Code (CMC)

Call Secured Status

DTMF Method

RSVP

Redirection (3xx) Calls

Replaces Calls

Refer Calls

Monitor Calls

Recording Calls

AAC and iLBC Calls

Mobility

Intercom Calls

CDR Field Descriptions

CMR Field Descriptions (Diagnostic)

K-Factor Data in CMRs

Codec Types

Call Termination Cause Codes

Redirect Reason Codes

OnBehalfof Codes

Related Topics

Related Documentation

Understanding Cisco Call Detail Records

---

This chapter describes the format and logic of the call detail records (CDRs) and call management records (CMRs) that the Cisco Unified Communications Manager Release 6.1(1) system generates. You can use this information for post-processing activities such as generating billing records and network analysis. The chapter describes how to access the CDR/CMR files and how to interpret fields in the files.

When you install your system, the system enables CDRs by default. CMRs remain disabled by default. You can enable or disable CDRs or CMRs at any time that the system is in operation. You do not need to restart Cisco Unified Communications Manager for the change to take effect. The system responds to all changes within a few seconds. The system enables CMR or diagnostic data separately from CDR data.

This chapter contains the following topics:

•CDR Processing

•Cisco Unified Communications Manager CDR Overview

•Call Types

•Interpreting Cisco Personal Assistant Data in the CDRs

•Call Scenarios

•CDR Field Descriptions

•CMR Field Descriptions (Diagnostic)

•K-Factor Data in CMRs

•Codec Types

•Call Termination Cause Codes

•Redirect Reason Codes

•OnBehalfof Codes

•Related Topics

•Related Documentation

CDR Processing

Cisco Unified Communications Manager generates two different types of call information records: CDRs and CMRs. The CDR records store information about a call. The CMR records store information about the quality of the streamed audio of the call. The CDR records relate to the CMR records by way of two GlobalCallID columns: Global CallID callManagerId and GlobalCallID Called. Depending upon the call scenario, more than one CMR may exist for each CDR.

When Cisco Unified Communications Manager places or receives a call, the system generates a CDR record when the call terminates. The system writes the CDR to a flat file (text file). Inside the Cisco Unified Communications Manager, the Call Control process generates CDR records. The system writes records when significant changes occur to a given call, such as ending the call, transferring the call, redirecting the call, splitting the call, joining a call, and so forth.

When CDR records are enabled, Call Control generates one or more CDR records for each call. The system sends these records to EnvProcessCdr, where they are written to the flat files. The number of records that are written varies by type of call, and the call scenario. When Diagnostics are enabled, the device generates CMR records for each call. The system writes one CMR record for each IP phone that is involved in the call or for each Media Gateway Control Protocol (MGCP) gateway. The system also sends these records to EnvProcessCdr where they get written to flat files.

The Cisco Unified Communications Manager generates CDR and CMR records but does not perform any post processing on the records. The system writes the records to comma-delimited flat files and periodically passes them to the CDR Repository. The CDR and CMR files represent a specific filename format within the flat file.

Filename Format

The following example shows the full format of the filename: tag_clusterId_nodeId_datetime_seqNumber

•tag—Identifies the type of file, either CDR or CMR

•clusterId—Identifies the cluster

•nodeId—Identifies the node

•datetime—UTC time in yyyymmddhhmm format

•seqnumber—Sequence number

Two examples of filenames follow:

•cdr_Cluster1_01_200404021658_1

•cmr_Cluster1_02_200404061011_6125

Flat File Format

The CDR and CMR flat files have the following format:

•Line 1—List of field names comma separated

•Line 2—List of field type comma separated

•Line 3—Data comma separated

•Line 4—Data comma separated

The following example shows a flat file:

Line1-"cdrRecordType","globalCallID_callManagerId","globalCallID_callId","origLegCallIdent
ifier",...

Line2-INTEGER,INTEGER,INTEGER,INTEGER,...

Line3-1,1,388289,17586046,...

Line4-1,1,388293,17586054,...

---

Note If the value of the CDR Log Calls With Zero Duration Flag parameter is True, the system writes all calls to a flat file. See the "Configuring CDR Service Parameters" section on page 2-2 for additional information about this parameter.

---

Cisco Unified Communications Manager CDR Overview

The following sections provide a brief description of how CDRs are generated and managed in Cisco Unified Communications Manager.

•CDR Management

•Types of Call Information Records

CDR Management

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

•Collects the CDR /CMR files from the Cisco Unified Communications Manager node to the CDR Repository node.

•Maintains the CDR/CMR files on the CDR Repository node.

•Allows third-party applications to retrieve CDR/CMR files on demand through a SOAP interface.

•Accepts on-demand requests for searching file names.

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

•Monitors disk usage of CDR/CMR files on the CDR Repository node.

•Periodically deletes CDR/CMR files that were successfully delivered. You can configure the amount of storage that is used to store flat files. The post-processing applications can later retrieve the buffered historical data to re-get any lost, corrupted, or missing data. The CDRM feature, which is not aware of the flat file format, does not manipulate the file contents.

CDRM comprises two default services, the CDR Agent and the CDR Repository Manager, and one activate service, CDR onDemand Service.

CDR Agent

As part of the CDRM feature, a resident component on every node within a Cisco Unified Communications Manager cluster acts as the CDR Agent. On a node where both Cisco Unified Communications Manager and the CDR Agent are running, Cisco Unified Communications Manager writes the CDRs into CDR flat files (CSV format) with a special control character ("_") that is prefixed to the filename by the call-processing module and indicates that the file is not available for transfer. If this control character is not present, the system assumes the file to be available for transfer and sends the file to the designated CDR Repository node. Upon successful transfer, the system deletes the local copy of the file.

Reliability gets the highest priority for the CDRM feature. CDRs comprise very important financial data, so the goal of this feature is to guarantee that no CDR is lost. The Cisco Unified Communications Manager 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 the 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.

CDR Repository Manager

Within a Cisco Unified Communications Manager cluster, one instance of the CDR Repository Manager runs on the CDR Repository node. It manages CDR files that are received from the Cisco Unified Communications Manager nodes and periodically sends the files to the specified customer/third-party billing servers.

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

If any external billing server is specified in CDRM configuration, the system creates a soft link to the file in a directory that is 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. If the delivery is successful, the system removes the soft link in the destination directory.

Every Cisco Unified Communications Manager node can generate one CDR file and one CMR file every minute for up to 1 hour. You can configure the maximum disk space that is used for storage of CDR files on the CDR Repository node through provisioning. The File Manager component of the CDR Repository Manager runs hourly. When the File Manager runs, it deletes files with dates outside the configured preservation duration. It also checks whether disk usage has exceeded the high water mark. If so, the system deletes the processed CDR files until the low water mark is reached, starting with the oldest files. However, if any CDR file to be deleted was not successfully sent to the specified billing server, the system leaves it in the CDR Repository, and raises a notification or alarm. The system creates a flag file during the configured maintenance window, which denies access to the CDR files for the CDR onDemand Service. The system removes the flag file after the maintenance window expires.

For detailed procedures for configuring the CDR Repository Manager and customer billing servers, see the "CDR Repository Manager Configuration" section in the Cisco Unified Serviceability 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 1 hour) and returns all lists that fit the duration that the request specifies.

The CDR onDemand Service can also handle requests for delivering a specific CDR file to a specified destination through (s)FTP. The system can activate the CDR onDemand service on the CDR Repository node as it has to access the CDR files in the repository. The system prohibits service during the maintenance window. For detailed information on the CDR onDemand Service, see the Cisco Unified Communications Manager Developers Guide for Release 6.1(1).

Types of Call Information Records

Cisco Unified Communications Manager 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 Communications Manager does not perform any post processing on CDRs or CMRs.

This section contains the following topics:

•Global Call Identifier

•Number Translations

•Partitions and Numbers

•Timestamps

•Call Termination Cause Codes

Global Call Identifier

The Cisco Unified Communications Manager 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 10-1) lists CDRs that are written to the CDR 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 10-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 Communications Manager 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 that are shown in Table 10-2:

Table 10-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 Communications Manager 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 Communications Manager 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 Communications Manager 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 Communications Manager 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). 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 operating system.

The CDR includes the UTC timestamps that are shown in Table 10-3:

Table 10-3 UTC Timestamps in CDRs

Field	Description
dateTimeOrigination	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	This field designates the time that the devices connect and speech begins. This field shows a zero if the call never connects.
dateTimeDisconnect	This field designates the time that the call disconnects. This field shows a zero if the call never connects.

Call Termination Cause Codes

The CDR includes two call termination 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 termination cause code value shows zero.

Table 10-8 lists the call termination cause code values per ITU specification Q.850. For On Net call legs, the Cisco Unified Communications Manager determines the call termination cause code value. For Off Net call legs, the far-end switch determines the call termination cause code value.

IP Addresses

The system stores IP addresses as unsigned integers. 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 get 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 get 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, the system writes two CMRs: one for the originator and one for the destination of the call.

This section describes the CDRs that are written for different call types in the system.

•Successful On Net Calls

•Abandoned Calls

•Calls with Busy or Bad Destinations

•Short Calls

•Forwarded or Redirected Calls

•Pickup Calls

•Transferred Calls

•Conference Calls

•Meet-Me Conferences

•Ad Hoc Conference Linking

•Precedence Calls (MLPP)

•Malicious Calls

•Conference Drop Any Party

•Immediate Divert (to Voice-Messaging System)

•Video Calls

•Call Monitoring and Call Recording

•AAC and iLBC Calls

•Mobility

•Intercom

•Original Calling Party on Transfer

Successful On Net Calls

A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.

Successful On Net Call CDR Examples

The following table contains two examples:

•A—A 60-second call that the caller terminates

•B—A 60-second call that the called party clears

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

Abandoned Calls CDR Examples

The following table contains two examples:

•A—Extension 2001 goes off hook then on hook (when the CdrLogCallsWithZeroDurationFlag is set to 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

The system logs all these calls as normal calls with all relevant fields containing data. The Calling or Called Party Cause fields contain a cause code that indicates why the call was not connected, and the Called Party IP and Date/Time Connect fields remain blank. The system logs all unsuccessful calls, 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).

Calls with Busy or Bad Destinations CDR Examples

The following table contains three examples:

•A—Call to PSTN number; party is 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
A	2001	Accounts	902920262226	PSTN	0	17	0
B	2001	Accounts	902920100000	PSTN	0	1	0
C	2001	Accounts	902920262226	PSTN	0	38	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 CDR. 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.

Short Call CDR Example

The following table contains an example of a successful On Net call with a duration of less than 1 second that the called party cleared.

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

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.

Forward or Redirected Call CDR Examples

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 system

	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 Communications Manager includes two pickup modes: Pickup and Auto Pickup. The following sections describe these calls:

•Pickup

•Auto Pickup

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 Call CDR 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 no need exists for the last answer softkey press. The system generates two CDRs for Auto Pickup, and these CDRs have the same Call ID.

The system generates the first CDR 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 CDR Example

1. A call comes in from the PSTN to extension 2001; 2001 and 2002 reside 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 that is necessary for a call transfer because it is too complex. Each time that a call is transferred, the Cisco Unified Communications Manager 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 represents the original placed call. The second CDR represents the setup call (consultative/announcement) that is used to initiate the transfer. The third CDR represents 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 that this call resulted from a transfer; therefore, all legs of the transfer can be tied back to a single call.

Transferred Calls CDR Examples

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

Example 1

A calls B; A transfers B to C. The three logged calls follow:

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, the call from A to C will have a duration of zero seconds. If the call was a consultation transfer, all calls will have non-zero durations. Original Called Party and Call Party Number fields match.

Example 2

A calls B; B transfers A to C. The three logged calls follow:

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, the call from B to C will have a duration of zero seconds. If the call was a consultation transfer, all calls will have non-zero durations. Original Called Party and Call Party Number fields match.

Example 3

A calls B; B transfers A to C on a blind transfer. C gets Call Forwarded on No Answer to D. The calls that are logged follow:

1. Call from A to B

2. Call from B to C

3. Call from A to D

Because the call was a blind transfer, 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 gets 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.

Transfer Without Consultation CDR Examples

The following table contains three examples:

•A—Call from extension 2001 to a PSTN number sustains 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 Communications Manager 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.

Transfer with Consultation CDR Examples

The following table contains three examples:

•A—Call from extension 2001 to a PSTN number sustains 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

Three 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 connect 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 system adds the conference controller information 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 identify 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 situation 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.

3. The party that added the participant, known as the requestor party, appears in the CDR comment field. The tags for the requestor information include ConfRequestorDn and ConfRequestorDeviceName. The party that requested to remove a participant, known as the drop requestor, appears in the CDR comment field. The tags for the drop requestor information include DropConfRequestorDn and DropConRequestorDeviceName.

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

You can 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 holds special significance to the Cisco Unified Communications Manager. 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"

•origCalledPartyRedirectOnBehalfOf—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).

Conference Calls CDR Examples

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; 2001 then 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

Meet-Me Conferences

A meet-me conference occurs when several parties individually dial into a conference bridge at a predetermined time.

The Cisco Secure Conference feature uses the existing callSecuredStatus field to display the highest security status that a call reaches. For meet-me conferences, the system clears calls that try to join the conference but do not meet the security level of the meet-me conference with a terminate cause = 58 (Bearer capability not presently available).

Meet-Me Conference CDR Examples

The following table contains an example CDR for the following scenario. 5001 specifies the dial-in number. The conference bridge device signifies special significance to the Cisco Unified Communications Manager, and calls to the conference bridge appear as forwarded calls; that is, User A 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."

•User A (2001) calls into a meet-me conference bridge with the phone number 5001.

•User B (2002) calls into a meet-me conference bridge with the phone number 5001.

•User C (2003) calls into a meet-me conference bridge with the phone number 5001.

	Calling Party	Calling Partition	Original Called Party	Original Called Partition	Final Called Party	Final Called Partition	Last Redirect Party	Last Redirect Partition	Duration
A	2001	Accounts	5001		b0019901001		b0019901001		70
B	2002	Accounts	5001		b0019901001		b0019901001		65
C	2003	Accounts	5001		b0019901001		b0019901001		80

Ad Hoc Conference Linking

The advanced ad hoc conference linking feature allows you to link multiple ad hoc conferences together by adding an ad hoc conference to another ad hoc conference as if it were an individual participant. You can also use the methods that are available for adding individual participants to an ad hoc conference to add another conference to an ad hoc conference.

CDRs that the advanced ad hoc conference linking feature generates include a field called OrigConversationId. This field associates the conference bridges that are involved in a linked conference. The Comment field of the CDR adds the ConfRequestorDN and ConfRequestorDeviceName tags to indicate add/drop of participants of the conference by a non-controller of the conference.

Two types of conference linking exist:

•Linear—No more than two ad hoc conferences can link directly to any participating conference.

•Nonlinear—Three or more ad hoc conferences that link directly to another conference. The system does not permit this type of linking by default because potentially negative impact on conference resources exists.

Linear Ad Hoc Conference Linking Using Join CDR Example

The following table contains example CDRs for this scenario:

•Alice (1000) calls Bob (1001). This represents an original call.

•Bob (1001) conferences in Carol (1002) This represents a consultation call.

•Dave (1003) calls Carol (1002). This represents an original call.

•Dave (1003) conferences in Ed (1004) This represents a consultation call.

•The system creates two separate conferences. Carol takes part in both conferences. At this point, the system generates CDR1, CDR2, CDR3, and CDR4.

•Carol (1002) joins the two conferences through a conference bridge (b002990122). At this point, the system generates CDR5.

•Dave (1003) joins the two conferences through a conference bridge (b002990122). At this point, the system generates CDR6.

•Ed (1004) leaves the conference. The system generates CDR7.

•Dave (b002990122) leaves the conference. The system generates CDR8.

•Alice (1000) leaves the conference. The system generates CDR9.

•Bob (1001) leaves the conference. The system generates CDR10.

•Carol (1002) leaves the conference. The system generates CDR11.

Calling Party Number	globalCallID-callid	Original Leg Call Identifier	Dest Leg Call Identifier	Original Called Party Number	Final Called Party Number	Last RedirectDn	OrigCall Termination OnBehalfOf
1000 (CDR1)	1	11	12	1001	1001	1001	4
1001 (CDR2)	2	13	14	1002	1002	1002	4
1003 (CDR3)	3	21	22	1002	1002	1002	4
1003 (CDR4)	4	23	24	1004	1004	1004	4
1002 (CDR5)	3	22	25	b0029901222	b0029901222	1003	4
1003 (CDR6)	3	21	26	b0029901222	b0029901222	1003	0
1004 (CDR7)	3	24	27	b0029901222	b0029901222	1003	0
b0029901222 (CDR8)	1	25	28	b0029901001	b0029901001	10020	0
1000 (CDR9)	1	11	15	b0029901001	b0029901001	1001	0
1001 (CDR10)	1	12	16	b0029901001	b0029901001	1001	0
1002 (CDR11)	1	14	17	b0029901001	b0029901001	1001	0

This is a continuation of the previous table.

Calling Party Number	DestCall Termination OnBehalfOf	LastRedirect Redirect Reason	LastRedirect Redirect OnBehalfOf	Original ConversationID	Destination Conversation ID	Comment
1000 (CDR1)	4	0	0	0	0
1001 (CDR2)	4	0	0	0	0
1003 (CDR3)	4	0	0	0	0
1003 (CDR4)	4	0	0	0	0
1002 (CDR5)	4	98	4	0	2222	ConfControllerDn=1003;ConfCont rollerDeviceName=SEP0003E333FA D1;ConfRequestorDn-1003;ConfRe questorDeviceName=SEP0003E333 FAD1
1003 (CDR6)	0	98	4	0	2222	ConfControllerDn=1003;ConfCont rollerDeviceName=SEP0003E333FA D1;ConfRequestorDn-1003;ConfRe questorDeviceName=SEP0003E333 FAD1
1004 (CDR7)	0	98	4	0	2222	ConfControllerDn=1003;ConfControllerDeviceName=SEP0003E333FAD1;ConfRequestorDn-1003;ConfRequestorDeviceName=SEP0003E333 FAD1
B0029901222 (CDR8)	0	98	4	2222	1111	ConfControllerDn=1003;ConfControllerDeviceName=SEP0003E333FAD1;ConfRequestorDn-1003;ConfRequestorDeviceName=SEP0003E333 FAD1
1000 (CDR9)	0	98	4
1001 (CDR10)	0	98	4
1002 (CDR11)	0	98	4

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.

Precedence Calls CDR Example

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 Communications Manager network flags the call. The Comment field flags the malicious call.

Malicious Calls CDR Example

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 the calls that this feature terminates.

Conference Drop Any Party CDR Example

The following table contains an example CDR for a call that connects to a conference and gets 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
2001	ACNTS	2309	16	MKTG	115	0	b0029901001		b0029901001
2309	ACNTS	b0029901001	0		116	128	b0029901001		b0029901001
3071111	PSTN	b0029901001	16		117	0	b0029901001		b0029901001
2001	ACNTS	2309	16	PSTN	106	0	3071111	PSTN	30711111

Orig ConversationID	OrigCall Termination OnBehalfOf	DestCall Termination OnBehalfOf	OriginalCalledPty Redirect OnBehalfOf	LastRedirect Redirect OnBehalfOf	Join OnBehalfOf	Duration
0	4	4	0	0	0	60
1	12	0	4	4	4	360
1	13	0	4	4	4	200
1	4	4	4	4	4	360
0	4	4	0	0	0	20

Immediate Divert (to Voice-Messaging System)

CDRs for Immediate Divert calls take place the same as forwarded calls except values exist for origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf fields.

Immediate Divert CDR Example

The following table contains an example CDR for this scenario:

Calling Party	Calling Partition	Original Called Party	Original Called Partition	Final Called Party	Final Called Partition	Last Redirect Party	Last Redirect Partition	Duration	OrigCalled Party Redirected OnBehalfOf	Last Redirect Redirect OnBehalfOf
02920262227		2001	ACNTS	2309	MKTG	2001	ACNTS	120	5	5
02920262227		2001	ACNTS	6000	VMAIL	2309	MKTG	60	5	5

Video Calls

The following table contains an example CDR for a video call for this scenario:

•Calling party 51234 calls the called party 57890.

•100 = H.261

•187962284 = 172.19.52.11

•288625580 = 172.19.52.17

•320 - 320

Video Calls CDR Example

•2 = QCIF

Calling Party	Calling Partition	Calling Leg	Original Called Party	Original Called Partition	Called Leg	Orig VideoCap_ Codec	Orig VideoCap_ Bandwidth	Orig VideoCap_ Resolution	OrigVideo Transport Address_IP	OrigVideo Transport Address_Port
51234	CISCO	101	57890	CISCO	102	100	320	2	187962284	49208

Dest VideoCap_ Codec	Dest VideoCap_Bandwidth	Dest VideoCap_Resolution	DestVideo Transport Address_IP	DestVideo Transport Address_Port
100	320	2	288625580	49254

Call Monitoring and Call Recording

The system generates CDRs for the Call Monitoring and Call Recording features by using existing CDR fields.

For both monitoring and recording, the monitoring calls and recording calls have one-way media. The media fields stay empty for one side of the call for one-way media CDRs.

The destConversationID field of the Call Monitoring CDR matches the agent call leg identifier in the CDR of the call that is monitored and links together the Call Monitoring CDR and the CDR of the monitored call.

The origConversationID field of the two Call Recording CDRs matches the agent call leg identifier in the Recording Call CDR and links together the Call Recording CDR and the CDR of the recorded call.

Call Monitoring CDR Examples

The following table contains example CDRs for a monitor call with the following scenarios:

•Example A—Customer 9728134987 calls the agent 30000, and the agent answers. Supervisor 40003 monitors the call. The destConversationID from the monitoring call matches the destLegCallIdentifier of the monitored call.

•Example B—Agent 30000 calls the customer 9728134987, and the customer answers. The supervisor 40003 monitors the call. The destConversationID from the monitoring call matches the origLegCallIdentifier of the monitored call.

	Global Call ID callid	Orig Leg Call Identifier	Dest Leg Call Identifier	Calling Party Number	Orig Called Party Number	Final Called Party Number	Last RedirectDn	Orig Cause Values
A—Monitored Call	7	16777230	16777231	9728134987	30000	30000	30000	16
A—Monitoring Call	10	16777232	16777235	4003	b001501001	b001501001	b001501001	0
B—Monitored Call	71	16777299	16777300	30000	9728134987	9728134987	9728134987	16
B—Monitoring Call	101	16777932	16777935	40003	b001501002	b001501002	b001501002	0

Dest Cause Value	Orig Called Party Redirect Reason	last Redirect Redirect Reason	Orig Called Party Redirect OnBehalfOf	last Redirect Redirect OnBehalfOf	dest Conversation ID
0	0	0			0
0	370	370	28	28	16777231
0	0	0			0
0	370	370	28	28	16777299

Call Recording CDR Examples

The following table contains example CDRs for recording calls with the following scenarios:

•Example A—Customer 9728134987 calls the agent 30000, and the agent answers. The recording feature creates two recording calls to the recording device. This action results in two additional CDRs: one for the agent voice and another for the customer voice. The origConversationID from the recording CDRs match the destLegCallIdentifier of the recorded CDR. In this example, the customer hangs up.

•Example B—Agent 30000 calls the customer 9728134987, and the customer answers. The recording feature creates two recording calls to the recording device. This action results in two additional CDRs: one for the agent voice and another for the customer voice. The origConversationID from the recording CDRs matches the origLegCallIdentifier of the recorded CDR. In this example, the agent hangs up.

	Global Call ID callid	Orig Leg Call Identifier	Dest Leg Call Identifier	Calling Party Number	Orig Called Party Number	Final Called Party Number	Last RedirectDn	Orig Cause Values
A—Recorded Call	7	16777110	16777111	9728134987	30000	30000	30000	16
A—Recording Call CDR1	10	16777120	16777121	30000	90000	90000	90000	0
A—Recording Call CDR2	11	16777122	16777123	30000	90000	90000	90000	0
B—Recorded Call	71	16777113	16777114	30000	9728134987	9728134987	9728134987	16
B—Recording Call CDR1	100	16777220	16777221	30000	90000	90000	90000	16
B—Recording Call CDR2	110	16777222	16777223	30000	90000	90000	90000	16

Dest Cause Value	Orig Called Party Redirect Reason	last Redirect Redirect Reason	Orig Called Party Redirect OnBehalfOf	last Redirect Redirect OnBehalfOf	Orig Conversation ID
0	0	0			0
0	354	354	27	27	16777111
0	354	354	27	27	16777111
0	0	0			0
0	354	354	27	27	16777113
0	354	354	27	27	16777113

AAC and iLBC Calls

The Advanced Audio Codec (AAC) specifies a bandwidth voice codec that provides improved voice fidelity. This codec also provides equal or improved sound quality over older codecs with lower bit rates. AAC includes the following features:

•For AAC calls, the codec specifies Media_Payload_AAC 42.

•The maxFramesPerPacket specifies 1.

•Internet Low Bit Rate Codec (iLBC) enables graceful speech quality degradation in a lossy network where frames get lost. For iLBC calls, the codec specifies Media_Payload_ILBC = 86.

The system adds an audio bandwidth field to the CDR for AAC and iLBC calls.

Field Names	Definitions
origMediaCap_bandwidth	This integer field contains the audio bandwidth.
destMediaCap_bandwidth	This integer field contains the audio bandwidth.

The system populates the bandwidth fields based on the following table:

Codec	Bandwidth
G711Alaw64k	64
G711Alaw56k	56
G711Ulaw64k	64
G711Ulaw56k	56
G722_64k	64
G722_56k	56
G722_48k	48
G7231	7
G728	16
G729	8
G729AnnexA	8
G729AnnexB	8
G729AnnexAwAnnexB	8
XV150_MR_729A	8
NSE_VBD_729A	8
GSM_Full_Rate	13
GSM-Half_Rate	7
GSM_Enhanced_Full_Rate	13
Wide_Band_256k	256
Is11172AudioCap	0
Is13818AudioCap	0
Data64	64
Data56	56
GSM	13
G7221_32K	32
G7221_24K	24
AAC	256
ILBC	15k or 13k

AAC Calls CDR Example

The following table contains an example CDR for a call with AAC codec.

Calling party 51234 calls the called party 57890.

Global Call ID callid	Orig Leg Call Identifier	Dest Leg Call Identifier	Calling Party Number	Orig Called Party Number	Final Called Party Number	Last RedirectDn	Orig Cause Values	Dest Cause Value	Orig MediaCap Payload Capability
121	101	102	51234	57890	57890	57890	0	16	42

Orig MediaCap Bandwidth	Dest MediaCap Payload Capability	Dest MediaCap Bandwidth
256	42	256

iLBC Calls CDR Example

The following table contains an example CDR for a call with iLBC codec.

Calling party 51234 calls the called party 57890.

Global Call ID callid	Orig Leg Call Identifier	Dest Leg Call Identifier	Calling Party Number	Orig Called Party Number	Final Called Party Number	Last RedirectDn	Orig Cause Values	Dest Cause Value	Orig MediaCap Payload Capability
121	101	102	51234	57890	57890	57890	0	16	86

Orig MediaCap Bandwidth	Dest MediaCap Payload Capability	Dest MediaCap Bandwidth
15	86	15

Mobility

The system supports the following Mobility features:

•Hand-In

•Hand-Out

•Cell Pickup

•Interactive Voice Response (IVR)

The system generates a standard CDR for every call that uses the Mobility feature. When a call is split, redirected, or joined by the Mobility feature, the corresponding OnBehalfOf code represents a new value that is designated to the Mobility feature. The CAR Loader checks the following OnBehalfOf fields:

•origCallTerminationOnBehalfOf

•destCallTerminationOnBehalfOf

•origCalledPartyRedirectOnBehalfOf

•lastRedirectRedirectOnBehalfOf

•joinOnBehalfOf

If any of the preceding OnBehalfOf codes has the Mobility code of 24, the CDR has the Mobility call type that is determined by the CAR Loader. Four redirectResource codes apply for Mobility features: Hand-In (code 303), Hand-Out (code 319), Cell Pickup (code 335), and IVR (code 399).

Mobility CDR Examples

A dual-mode phone with the Enterprise number of 22285 and a cell number of 9728324124 exists. The following table contains example CDRs for mobility calls that use the dual-mode phone in the following scenarios:

•Example A—Mobility Follow Me: 22202 calls 22285, and both 22285 and 9728324124 ring. The cell phone answers the call. The parties talk for 80 seconds.

•Example B—Mobility Hand-In: A call goes to the cell phone. The parties talk for 39 seconds; the dual-mode phone gets carried into the Enterprise network, and the call gets switched from the cell network to the Enterprise network. The call lasts for another 15 seconds.

•Example C—Mobility Hand-Out: The handout number (H-number) specifies 555123. A call gets made to the Enterprise number 22285. They talk for 21 seconds; the dual-mode phone then gets carried out of the Enterprise network and into the cell network. The call gets switched from the Enterprise network to the cell network (9728324124). The call lasts another 39 seconds.

•Example D—Mobility Cell Pickup: A call gets made and established to 22285. They talk for 40 seconds; then, Cell Pickup gets invoked. The call gets switched from the Enterprise phone to the cell phone. The call continues for another 111 seconds.

•Example E—Mobility IVR: A call comes into the Cisco Unified Communications Manager with a string (DID#RemoteDest#TargetNum#). The call gets redirected to the TargetNum. 9728131234 calls into an IVR, and data gets collected. The target destination specifies 812345 and the call gets redirected to 812345. The call connects for 60 seconds.

	Global Call ID callid	Orig Leg Call Identifier	Dest Leg Call Identifier	Calling Party Number	Orig Called Party Number	Final Called Party Number	Last RedirectDn	Orig Cause Values
A—Follow Me Call CDR	861	22481077	22481078	22202	22285	9728324124	22285	16
B—Mobility HandIn - Call to cell #9728324214 CDR	864	22481083	22481085	22202	919728324124	919728324124	9199728324124	393216
B—HandIn Call to the Enterprise CDR	864	22481083	22481087	22202	22285	22285	22285	0
C—HandOut Enterprise Call to 22285 CDR	964	22481093	22481094	22202	22285	22285	22285	393216
C—HandOut Server Call from Cell Phone to H-Number CDR	965	22481095	22481096	9728324124	555123	555123	555123	393216
C—HandOut Call CDR	964	22481093	22481095	22202	9728324124	9728324124	9728324124	0
D—Mobility Cell Pickup Enterprise Call to 22285 CDR	555	22481111	22481112	22202	22285	22285	22285	393216
D—Mobility Cell Pickup Server Call to Cell Phone CDR	566	22481222	22481223		9728324124	9728324124	9728324124	0
D—Mobility Final Handout Call CDR	964	22481111	22481222	22202	9728324124	9728324124	0728324124	0
E—Mobility IVR CDR	12345	16677100	16677102	9728131234	8005559876	812345	8005559876	0

Dest Cause Value	Last Redirect Redirect Reason	Last Redirect Redirect OnBehalOf	Orig Termination OnBehalfOf	Dest Termination OnBehalfOf	Joint OnBehalfOf	Duration
0	0	0			0	80
393216	0	0	24	24	0	39
16	303	24	24	12	24	15
393216	0	0	24	24	0	21
393216	0	0	24	24	0	0
16	319	24	24	12	24	39
393216	0	0	24	24	0	40
0	0	0	24	24	0	0
16	335	24	24	12	24	111
16	399	24	0	0	N/A	60

Intercom

The Intercom feature provides one-way audio; therefore, the CDR reflects one-way audio. For talk-back intercom, two-way audio exists, and the CDR reflects two-way audio.

The Intercom feature requires a partition (intercom partition) and existing CDR partition fields get used to identify intercom calls.

Intercom CDR Example

Phone 20000 invokes the intercom in the following scenarios:

•Example A—Whisper Intercom: The configured intercom partition specifies "intercom."

•Example B—Talk-Back Intercom: Phone 20000 presses the Intercom button. 20001 invokes talk-back and talks to 20000. The configured intercom partition specifies "intercom."

	Global Call ID callid	Orig Leg Call Identifier	Dest Leg Call Identifier	Calling Party Number	Orig Called Party Number	Final Called Party Number	Orig Cause Values	Dest Cause Value
A—Whisper Intercom CDR	1111000	21822467	21822468	20000	20001	20001	16	0
B—Talk-Back Intercom CDR	1111000	21822469	21822470	20000	20001	20001	16	0T

Orig Media Transport Address IP	Orig Media Transport Address Port	Dest Media Transport Address IP	Dest Media Transport Address Port	Orig Called Party Number Partition	Calling Party Number Partition	Final Called Party Number Partition	Duration
0	0	-47446006	28480	Intercom	Intercom	Intercom	5
-131332086	29458	-47446006	29164	Intercom	Intercom	Intercom	5

Original Calling Party on Transfer

This feature changes the calling party number for a consultation call of a Cisco Unity or Cisco Unity Connection-initiated call transfer. The CDR of the consultation call shows that the original caller calls the transfer destination, not that the Cisco Unity or Cisco Unity Connection port calls the transfer destination.

You must configure this feature in the service parameters in Cisco Unified Communications Manager. See additional information at "Configuring CDR Service Parameters" section on page 2-2.

Original Calling Party on Transfer CDR Example

4001 calls 4002. 4002 transfers the call to 4003. The system generates three CDRs:

•The call between the original parties (4001 to 4002).

•The consultation call between the transferring party (4002) to the final transfer destination (4003).

•The call from the transferred party (4001) to the transfer destination (4003).

Call	CallingPartyNumber	originalCalledPartyNumber
1	4001	4002
2	4002	4003
3	4001	4003

---

Note No originalCallingParty field exists in the CDR.

---

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 incoming 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 name of the called person. 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 provides the following 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 Interceptor Going to Multiple Destinations

•Personal Assistant Conferencing

Personal Assistant Direct Call

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

Personal Assistant Direct Call CDR Example

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, 2101 specifies the calling number.

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2101	16777217	PAManaged	16777219	2004	Phones	2000	1023970182	2000	Phones	34
2004	16777221	Phones	16777222	2105	PAManaged	2105	1023970182	2105	PAManaged	0
2101	16777217	PAManaged	16777222	2105	PAManaged	2105	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 actions. See the sections on "Transfer Without Consultation" section and "Forwarded or Redirected Calls" section.

Personal Assistant Interceptor Going to Media Port and Transferring the Call CDR Example

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 Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2002	16777234	Phones	16777285	2105	PAManaged	2105	1023970478	2105	PAManaged	2
2101	16777230	PAManaged	16777232	2002	PA	2105	1023970478	21xx	" "	9
2105	16777235	PAManaged	16777230	2101	" "	" "	1023970483	" "	" "	5

.

Personal Assistant Interceptor Going Directly to Destination

This scenario can have two different cases: with no rules and with rules.

Personal Assistant Going Directly to Destination with No Rules CDR Example

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 it 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	OrigLeg Call Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Number	Final Called Party Number Partition	Original Called Party Number	Original Called Party Number Partition	Last Redirect DN	Last Redirect DN Partition	Duration (secs)
2101	16777240	PAManaged	16777242	2105	PA	2105	1023970710	21XX	" "	8

Personal Assistant Going Directly to Destination with Rule to Forward Calls to a Different Destination CDR Example

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	OrigLeg Call Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Number	Final Called Party Number Partition	Original Called Party Number	Original Called Party Number Partition	Last Redirect DN	Last Redirect DN Partition	Duration (secs)
2101	16777240	PAManaged	16777242	2110	PA	2105	1023970710	21XX	" "	8

Personal Assistant Interceptor Going to Multiple Destinations

This scenario can have several different cases. In each case, 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).

Personal Assistant Interceptor Going to Multiple Destinations CDR Examples

The following sections contain examples of each case. The tables contain example CDRs for each of these scenarios:

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

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

•User A calls personal assistant and says, "call User B."

•User B answers the call at 2110 extension.

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2004	16777262	Phones	16777263	2110	PAManaged	2110	1023971303	2110	PAManaged	6
2101	16777258	PAManaged	16777260	2004	Phones	2000	1023971303	2000	Phones	22
2110	16777263	PAManaged	16777258	2101	" "	" "	1023971312	" "	" "	9

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

•User A calls personal assistant and says, "call User B."

•User B answers the call at 2120 extension.

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2001	16777269	Phones	16777270	2110	PAManaged	2110	1023971456	2110	PAManaged	0
2001	16777272	Phones	16777273	2120	PAManaged	2120	1023971467	2120	PAManaged	4
2101	16777265	PAManaged	16777267	2001	Phones	2000	1023971467	2000	Phones	37
2120	16777273	PAManaged	16777265	2101	" "	" "	1023971474	" "	" "	7
2110	16777275	PAManaged	0	" "	" "	" "	1023971476	" "	" "	0

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

•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 2105 (the original destination) represents the third destination in this case.

---

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2002	16777281	Phones	16777282	2110	PAManaged	2110	1023971602	2110	PAManaged	0
2002	16777284	Phones	16777285	2120	PAManaged	2120	1023971615	2120	PAManaged	0
2101	16777277	PAManaged	16777279	2002	Phones	2000	1023971619	2000	Phones	38
2002	16777287	Phones	16777288	2105	PAManaged	2105	1023971619	2105	PAManaged	0
2101	16777277	PAManaged	16777288	2105	PAManaged	2105	1023971627	2105	PAManaged	7
2105	16777289	PAManaged	0	" "	" "	" "	1023971629	" "	" "	0

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

•User A calls personal assistant and says, "call User B."

•User B answers the call at extension 2110.

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2003	16777295	Phones	16777296	2110	PAManaged	2110	1023971740	2110	PAManaged	4
2101	16777291	PAManaged	16777293	2003	PA	2105	1023971740	21XX	" "	10
2110	16777296	PAManaged	16777291	2101	" "	" "	1023971749	" "	" "	9

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

•User A calls personal assistant and says, "call User B."

•User B answers the call at extension 2120.

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2004	16777302	Phones	16777303	2110	PAManaged	2110	1023971815	2110	PAManaged	0
2004	16777305	Phones	16777306	2120	PAManaged	2120	1023971824	2120	PAManaged	3
2101	16777298	PAManaged	16777300	2004	PA	2105	1023971824	21XX	" "	22
2120	16777306	PAManaged	16777298	2101	" "	" "	1023971832	" "	" "	8

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

•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), which User B then answers.

---

Note 2110 (the original destination) represents the third destination in this case.

---

Calling Party Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition	Original Called Party Num	Original Called Party Number Partition	Last Redir DN	Last Redirect DN Partition	Duration (secs)
2001	16777312	Phones	16777313	2110	PAManaged	2110	1023971923	2110	PAManaged	0
2001	16777315	Phones	16777316	2120	PAManaged	2120	1023971936	2120	PAManaged	0
2101	16777308	PAManaged	16777310	2001	PA	2105	1023971940	21XX	" "	30
2001	16777318	Phones	16777319	2105	PAManaged	2105	1023971940	2105	PAManaged	0
2101	16777308	PAManaged	16777319	2105	PAManaged	2105	1023971953	2105	PAManaged	12

Personal Assistant Conferencing

Personal assistant conferencing acts similar to the ad hoc conferences call type. For more information, see the "Conference Calls" section.

Personal Assistant Conferencing CDR Example

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 Num	Orig LegCall Identifier	Calling Party Number Partition	DestLeg Identifier	Final Called Party Num	Final Called Party Number Partition
2003	16777345	Phones	16777346	2105	PAManaged
2101	16777340	PAManaged	16777342	2003	Phones
2003	16777350	Phones	16777351	2002	PAManaged
2003	16777342	Phones	16777347	2110	" "
2110	16777351	PAManaged	16777352	b00110201001	" "
2105	16777346	PAManaged	16777349	b00110201001	" "
2101	16777340	PAManaged	16777348	b00110201001	" "

This table continues with this additional information.

Original Called Party Number	Original Called Party Number Partition	Last Redirect DN	Last Redirect DN Partition	Duration (seconds)
2105	1023972575	2105	PAManaged	6
2000	1023972576	2003	Phones	62
2110	1023972595	2110	PAManaged	39
b00110201001	1023972601	b00110201001	" "	25
b00110201001	1023972609	b00110201001	" "	14
b00110201001	1023972610	b00110201001	" "	34
b00110201001	1023972610	b00110201001	" "	34

Call Scenarios

Each normal call between two parties logs one CDR. Each CDR contains all fields that are identified in preceding scenarios, but some fields may not be used. If a field is not used, it stays blank if it is an ASCII string field or shows "0" if it is a numeric field. When supplementary services are involved in a call, more CDRs may get written.

In addition to the CDR, one CMR per endpoint may get involved in a call. In a normal call between two parties with each using an IP phone, two CMRs get written, one for the originator, and one for the destination of the call.

This section describes the records that are written for different call types, including all records for each call and important fields that are shown in summary tables for easy viewing and comparison.

•Normal Calls (IP Phone to IP Phone)

•Abandoned Calls

•Calls With Busy or Bad Destinations (Unsuccessful Calls)

•Forwarded Calls

•Call Pickup

•Legacy Call Pickup

•Transferred Calls

•Conference Calls

•Secure Meet-Me Conference

•Ad Hoc Conference Linking

•Call Park

•Precedence Calls (MLPP)

•Malicious Calls

•Immediate Divert (to Voice-Messaging System)

•Barge

•cBarge

•Video Calls

•Forced Authorization Code (FAC)

•Client Matter Code (CMC)

•Call Secured Status

•Secure Meet-Me Conference

•DTMF Method

•RSVP

•Redirection (3xx) Calls

•Replaces Calls

•Refer Calls

•Monitor Calls

•Recording Calls

•AAC and iLBC Calls

•Mobility

•Intercom Calls

Normal Calls (IP Phone to IP Phone)

Normal calls log three records per call; one CDR and two CMRs, one for each endpoint. In the CDR, the "originalCalledPartyNumber" field contains the same Directory Number as the "finalCalledPartyNumber" field.

Examples of Successful Calls

A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.

•The caller terminates a 60-second call. Because the calling party hangs up, the orig_CauseValue specifies 16 (Normal Clearing).

Field Names	CDR
globalCallID_callId	1
origLegCallIdentifier	100
destLegCallIdentifier	101
callingPartyNumber	2001
originalCalledPartyNumber	2309
finalCalledPartyNumber	2309
lastRedirectDn	2309
origCause_Value	16
dest_CauseValue	0
duration	60

•The called party clears a 60-second call. Because the called party hangs up, the dest_CauseValue specifies 16 (Normal Clearing).

Field Names	CDR
globalCallID_callId	1
origLegCallIdentifier	100
destLegCallIdentifier	101
callingPartyNumber	2001
originalCalledPartyNumber	2309
finalCalledPartyNumber	2309
lastRedirectDn	2309
origCause_Value	0
dest_CauseValue	16
duration	60

Abandoned Calls

Consider the logging of calls with zero duration as optional. Normally, these records do not get logged. If logging calls with zero duration is enabled, all calls will generate a CDR.

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

If the user dials a Directory Number and then abandons the call before it connects, the origCalledPartyNumber and finalcalledPartyNumber fields and their associated partitions contain the directory number and partition to which the call would have been extended. The destIPAddress field remains blank and the duration equals zero.

Examples of Abandoned Calls

•Extension 2001 goes off hook, then on hook.

Field Names	CDR
globalCallID_callId	1
origLegCallIdentifier	100
destLegCallIdentifier	0
callingPartyNumber	2001
originalCalledPartyNumber
finalCalledPartyNumber
lastRedirectDn
origCause_Value	16
dest_CauseValue	0
duration	0

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

Field Names	CDR
globalCallID_callId	2
origLegCallIdentifier	200
destLegCallIdentifier	201
callingPartyNumber	2001
originalCalledPartyNumber	2309
finalCalledPartyNumber	2309
lastRedirectDn	2309
origCause_Value	16
dest_CauseValue	0
duration	0

Calls With Busy or Bad Destinations (Unsuccessful Calls)

These calls get logged as a normal call with all relevant fields that contain data. The Calling or Called Party Cause field contains a cause code that indicates why the call does not connect, and the Called Party IP and Date/Time Connect fields remain blank. All unsuccessful calls get logged, even if zero duration calls are not logged.

Examples of Unsuccessful Calls

•Call to PSTN number, but party already engaged (cause 17 = user busy)

Field Names	CDR
globalCallID_callId	3
origLegCallIdentifier	300
destLegCallIdentifier	301
callingPartyNumber	2001
originalCalledPartyNumber	9728134987
origCause_Value	0
dest_CauseValue	17
duration	0

•Call to PSTN number, but number does not exist (cause 1 = number unavailable)

Field Names	CDR
globalCallID_callId	4
origLegCallIdentifier	302
destLegCallIdentifier	303
callingPartyNumber	2001
originalCalledPartyNumber	9728134987
origCause_Value	1
dest_CauseValue	0
duration	0

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

Field Names	CDR
globalCallID_callId	5
origLegCallIdentifier	304
destLegCallIdentifier	305
callingPartyNumber	2001
originalCalledPartyNumber	9728134987
origCause_Value	0
dest_CauseValue	38
duration	0

Forwarded Calls

Call Forwarding uses the redirect call primitive to forward the call. Features that use the redirect call primitive will have similar CDRs. Some of the important CDR fields for forwarded calls follow:

•The originalCalledPartyNumber contains the number of the original called party.

•The finalCalledPartyNumber represents the number that answered the call.

•The lastRedirectDn field specifies the number that performed the last redirect.

•The origCalledPartyRedirectReason represents the reason that the call was redirected the first time. For call forwarding, this field can contain Call Forward Busy=1, Call Forward No Answer=2, Call Forward All=15.

•The lastRedirectRedirectReason specifies the reason that the call was redirected the last time. For call forwarding, this field can contain Call Forward Busy=1, Call Forward No Answer=2, Call Forward All=15.

•The origCalledPartyRedirectOnBehalfOf field identifies which feature redirects the call for the first redirect. For call forwarding, this field specifies 5 (Call Forward).

•The lastRedirectRedirectOnBehalfOf field identifies which feature redirects the call for the last redirect. For call forwarding, this field specifies 5 (Call Forward).

Forwarding Examples

•CFA Example - Call comes in from the PSTN to extension 2001; the call gets forwarded (CFA) to 2309, where the call is answered, and talk occurs for 2 minutes.

Field Names	CDR
globalCallID_callId	12345
origLegCallIdentifier	100
destLegCallIdentifier	102
callingPartyNumber	9728134987
originalCalledPartyNumber	2001
finalCalledPartyNumber	2309
lastRedirectDn	2001
origCause_Value	0
dest_CauseValue	16
origCalledPartyRedirectReason	15
lastRedirectRedirectReason	15
origCalledPartyRedirectOnBehalfOf	5
lastRedirectRedirectOnBehalfOf	5
duration	120

•Multiple Hop CFA & CFNA Example - Call comes in from the PSTN to extension 1000; the call gets forwarded (CFA) to 2000; then, the call gets forwarded (CFNA) to the voice-messaging system (6000) where the caller leaves a message.

Field Names	CDR
globalCallID_callId	12346
origLegCallIdentifier	102
destLegCallIdentifier	105
callingPartyNumber	9728134987
originalCalledPartyNumber	1000
finalCalledPartyNumber	6000
lastRedirectDn	2000
origCause_Value	0
dest_CauseValue	16
origCalledPartyRedirectReason	15
lastRedirectRedirectReason	2
origCalledPartyRedirectOnBehalfOf	5
lastRedirectRedirectOnBehalfOf	5
duration	15

•Multiple Hop CFNA & CFB Example - Call comes in from the PSTN to extension 4444; the call gets forwarded (CFNA) to 5555; then, it gets forwarded (CFB) to 6666 where the call is answered, and they talk for 30 seconds.

Field Names	CDR
globalCallID_callId	12347
origLegCallIdentifier	106
destLegCallIdentifier	108
callingPartyNumber	9728134987
originalCalledPartyNumber	4444
finalCalledPartyNumber	6666
lastRedirectDn	5555
origCause_Value	16
dest_CauseValue	0
origCalledPartyRedirectReason	2
lastRedirectRedirectReason	1
origCalledPartyRedirectOnBehalfOf	5
lastRedirectRedirectOnBehalfOf	5
duration	30

Call Pickup

Two types of call pickup exist in Cisco Unified Communications Manager:

•Pickup

•Auto Pickup

The CDRs differ slightly for each type of call pickup.

Pickup

Pickup Call Example

A call comes in from the PSTN to extensions 2000, 2001, and 2002. These extensions are in the same pickup group. Extension 2002 picks up the call that is ringing on 2001. Extension 2002 answers the call, and the call connects between the PSTN caller and extension 2002.

Field Names	Pickup Call CDR
globalCallID_callId	22
callingPartyNumber	9728131234
originalCalledPartyNumber	2001
finalCalledPartyNumber	2002
lastRedirectDn	2001
origCause_Value	0
dest_CauseValue	16
origTerminationOnBehalfOf	16
destTerminationOnBehalfOf	16
lastRedirectOnBehalfOf	16
lastRedirectReason	5
joinOnBehalfOf	16

Auto Pickup

Auto Pickup acts like call pickup with auto answer. The user does not need to press the last answer softkey. The call automatically connects. Two CDRs get generated for Auto Pickup. These CDR will have the same Call ID.

•The first CDR gets generated for the original call. This CDR will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields equal to 16 (Pickup). This indicates that the call was 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). This indicates that the call was joined on behalf of the Pickup feature. The lastRedirectReason contains the redirect reason of 5 (Pickup).

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

Auto Pickup Example

•Auto Pickup Example - Call from the PSTN to extension 2001; 2001 and 2002 exist in the same pickup group. 2002 picks up the call that is ringing on 2001; the call automatically connects between the PSTN caller and 2002. They talk for 2 minutes.

Field Names	Original Call CDR	Pickup CDR
globalCallID_callId	11	11
origLegCallIdentifier	12345	12345
destLegCallIdentifier	12346	12347
callingPartyNumber	9728134987	9728134987
originalCalledPartyNumber	2001	2002
finalCalledPartyNumber	2001	2002
lastRedirectDn	2001	2001
origCause_Value	393216	16
dest_CauseValue	393216	0
origTerminationOnBehalfOf	16	12
destTerminationOnBehalfOf	16	16
lastRedirectRedirectReason	0	5
lastRedirectRedirectOnBehalfOf	0	16
joinOnBehalfOf	0	16
duration	0	120

Legacy Call Pickup

Legacy Call Pickup calls act very similar to forwarded calls. Legacy Call Pickup uses the redirect call control primitive just like call forwarding. Some of the important CDR fields for Legacy Call Pickup calls follow.

•The originalCallPartyNumber contains the number of the original called party.

•The finalCalledPartyNumber specifies the number of the party that picked up the call.

•The lastRedirectDn field specifies the number that was ringing when the call was picked up.

•The origCalledPartyRedirectReason specifies the reason that the call was redirected the first time. For call pickup calls this field can contain Call Pickup = 5.

•The lastRedirectRedirectReason specifies the reason that the call was redirected the last time. For call pickup, this field can contain Call Pickup = 5.

•The origCalledPartyRedirectOnBehalfOf field identifies which feature redirects the call for the first redirect. For call pickup, this field specifies Pickup = 16.

•The lastRedirectRedirectOnBehalfOf field identifies which feature redirects the call for the last redirect. For call pickup, this field specifies Pickup = 16.

Legacy Call Pickup Example

Call from the PSTN to extension 2001; 2001 and 2002 exist in the same pickup group. 2002 picks up the call that is ringing on 2001. 2002 answers the call, and the call connects between the PSTN caller and 2002. They talk for 2 minutes.

Field Names	CDR
globalCallID_callId	22
origLegCallIdentifier	1
destLegCallIdentifier	2
callingPartyNumber	9728134987
originalCalledPartyNumber	2001
finalCalledPartyNumber	2002
lastRedirectDn	2001
origCause_Value	0
dest_CauseValue	16
origCalledPartyRedirectReason	0
lastRedirectRedirectReason	5
origCalledPartyRedirectOnBehalfOf	16
lastRedirectRedirectOnBehalfOf	16
duration	120

Transferred Calls

Calls that are transferred generate multiple CDRs. One CDR exists for the original call, one for the consultation call, and another for the final transferred call.

For the original call, the origCause_value and destCause_value gets set to split = 393216, which indicates the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields get set to Transfer = 10 to indicate that this call was involved in a transfer.

For the consultation call, the origCause_value and destCause_value gets set to split = 393216, which indicates that the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields get set to Transfer = 10 to indicate that this call was involved in a transfer.

For the final transferred call, the joinOnBehalfOf field gets set to Transfer = 10 to indicate that this call resulted from a transfer.

Transfer Examples

The following examples which are not an exhaustive set, illustrate the records that would be generated under the stated circumstances. These examples help clarify what records are generated on transferred calls.

•Blind Transfer from the Calling Party - Call from extension 2001 to a PSTN number, they talk for 120 seconds. 2001 initiates a blind transfer to 2002. CDR 1 (original call) shows a call from extension 2001 to a PSTN number, talking for 120 seconds. CDR 2 (consultation call) shows a call from 2001 to extension 2002. CDR 3 represents the final transferred call where 2001 completes the transfer, drops out of the call, and leaves a call between the PSTN and 2002.

Field Names	Original Call CDR	Consultation Call CDR	Final Transferred CDR
globalCallID_callId	1	2	1
origLegCallIdentifier	101	103	102
destLegCallIdentifier	102	104	104
callingPartyNumber	2001	2001	3071111
originalCalledPartyNumber	3071111	2002	2002
finalCalledPartyNumber	3071111	2002	2002
lastRedirectDn	3071111	2002	2001
origCause_Value	393216	393216	16
dest_CauseValue	393216	393216	0
origTerminationOnBehalfOf	10	10	0
destTerminationOnBehalfOf	10	10	0
joinOnBehalfOf	0	0	10
duration	120	0	360

•Consultation Transfer from the Calling Party - Call from extension 2001 to a PSTN number; they talk for 60 seconds. 2001 initiates a consultation transfer to 2002 and talks for 10 seconds before the transfer completes. The final transferred call talks for 360 seconds. CDR 1 (original call) shows a call from extension 2001 to a PSTN number, talking for 60 seconds. CDR 2 (consultation call) shows a call from 2001 to extension 2002, talking for 10 seconds. CDR 3 represents the final transferred call where 2001 completes the transfer, drops out of the call, and leaves a call between the PSTN and 2002.

Field Names	Original Call CDR	Consultation Call CDR	Final Transferred Call CDR
globalCallID_callId	1	2	1
origLegCallIdentifier	111	113	112
destLegCallIdentifier	112	114	114
callingPartyNumber	2001	2001	3071111
originalCalledPartyNumber	3071111	2002	2002
finalCalledPartyNumber	3071111	2002	2002
lastRedirectDn	50001	50001	2001
origCause_Value	393216	393216	16
dest_CauseValue	393216	393216	0
origTerminationOnBehalfOf	10	10	0
destTerminationOnBehalfOf	10	10	0
joinOnBehalfOf	0	0	10
duration	60	10	360

•Blind Transfer from the Called Party - Call from 50000 to 50001; they talk for 120 seconds. 50001 initiates a blind transfer to 50002. CDR 1 (original call) shows a call from extension 50001 to 50002, talking for 120 seconds. CDR 2 (consultation call) shows a call from 50001 to extension 50002. CDR 3 represents the final transferred call where 50001 completes the transfer, drops out of the call, and leaves a call between 50000 and 50002.

Field Names	Original Call CDR	Consultation Call CDR	Final Transferred Call CDR
globalCallID_callId	1	2	1
origLegCallIdentifier	200	202	200
destLegCallIdentifier	201	203	203
callingPartyNumber	50000	50001	50000
originalCalledPartyNumber	50001	50002	50002
finalCalledPartyNumber	50001	50002	50002
lastRedirectDn	50001	50001	50001
origCause_Value	393216	393216	16
dest_CauseValue	393216	393216	0
origTerminationOnBehalfOf	10	10	0
destTerminationOnBehalfOf	10	10	0
joinOnBehalfOf	0	0	10
duration	120	0	360

•Consultation Transfer from the Called Party - Call from 50000 to 50001, they talk for 120 seconds. 50000 initiates a blind transfer to 50002. CDR 1 (original call) shows a call from extension 50000 to a 50001, talking for 120 seconds. CDR 2 (consultation call) shows a call from 50000 to extension 50002. CDR 3 represents the final transferred call where 50000 completes the transfer, drops out of the call, and leaves a call between 50001 and 50002.

Field Names	Original Call CDR	Consultation Call CDR	Final Transferred Call CDR
globalCallID_callId	1	2	1
origLegCallIdentifier	200	202	201
destLegCallIdentifier	201	203	203
callingPartyNumber	50000	50001	50000
originalCalledPartyNumber	50001	50002	50002
finalCalledPartyNumber	50001	50002	50002
lastRedirectDn	50001	50001	50001
origCause_Value	393216	393216	16
dest_CauseValue	393216	393216	0
origTerminationOnBehalfOf	10	10	0
destTerminationOnBehalfOf	10	10	0
joinOnBehalfOf	0	0	10
duration	120	0	360

Conference Calls

Multiple records get logged for calls that are part of a conference. The number of CDR records 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, one CDR for each setup call that was used to join other parties to the conference, and one CDR for the last two parties that connected in the conference. For a three-party ad-hoc conference, six CDRs would exist: one CDR for the original call, three CDRs for the parties that are connected to the conference, one CDR for each setup call, and one CDR for the final two parties in the conference. You can associate the setup calls with the correct call leg in the conference by examining the calling leg ID and called leg ID.

The conference bridge device has special significance to the Cisco Unified Communications Manager, and 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. Records show all calls into the conference bridge, regardless of the actually direction; however, by examining the setup call CDRs, you can determine the original direction of each call.

You can find the conference controller information in the comment field of the CDR. The format of this information follows:

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

•The conference controller DN + conference controller device name uniquely identify the conference controller. The system needs the device name in the case of shared lines.

•If the call is involved in multiple conference calls, the comment field contains multiple conference controller information. This situation could 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 will identify the conference controller.

The call legs connected to the conference include the following fields information:

•The finalCalledPartyNumber field contains the conference bridge number "b0019901001."

•The origCalledPtyRedirectOnBehalfOf field gets set to Conference = 4.

–The lastRedirectRedirectOnBehalfOf field gets set to Conference = 4.

–The joinOnBehalfOf field gets set to (Conference = 4).

–The comment field identifies the conference controller.

–The destConversationID field remains the same for all members in the conference. You can use this field to identify members of a conference call.

The original placed call and all setup calls that were used to join parties to the conference will have the following characteristics:

•The origCallTerminationOnBehalfOf field gets set to Conference = 4.

•The destCallTerminationOnBehalfOf field gets set to Conference = 4.

Conference Example

Call from 2001 to 2309.

2309 answers and talks for 60 seconds.

2001 presses the conference softkey and dials 3071111.

307111 answers and talks for 20 seconds; then, 2001 presses the conference softkey to complete the conference.

The three members of the conference talk for 360 seconds.

3071111 hangs up and leaves 2001 and 2309 in the conference. Because only two participants are left in the conference, the conference features joins these two directly together, and they talk for another 55 seconds.

---

Note Each conference call leg gets shown as placing a call into the conference bridge. The system shows the call as a call into the bridge, regardless of the actual direction of the call.

---

Field Names	Orig Call CDR	Setup Call CDR	Conference CDR 1	Conference CDR 2	Conference CDR 3	Final CDR
globalCallID_callId	1	2	1	1	1	1
origLegCallIdentifier	101	105	101	102	106	101
destLegCallIdentifier	102	106	115	116	117	102
callingPartyNumber	2001	2001	2001	2309	3071111	2001
originalCalledPartyNumber	2309	3071111	b0029901001	b0029901001	b0029901001	2309
finalCalledPartyNumber	2309	3071111	b0029901001	b0029901001	b0029901001	2309
lastRedirectDn	2001	3071111	b0029901001	b0029901001	b0029901001	b0029901001
origCause_Value	393216	0	16	393216	393216	16
dest_CauseValue	393216	0	393216	393216	393216	0
origCalledPartyRedirectReason	0	0	0	0	0	0
lastRedirectRedirectReason	0	0	0	0	0	98
origTerminationOnBehalfOf	4	4	12	12	4	12
destTerminationOnBehalfOf	4	4	0	0	4	4
origCalledRedirectOnBehalfOf	0	0	4	4	4	0
lastRedirectRedirectOnBehalfOf	0	0	4	4	4	4
joinOnBehalfOf	0	0	4	4	4	4
Conversation ID	0	0	1	1	1	0
duration	60	20	360	360	360	55

Comment
Orig Call CDR
Setup Call CDR	ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD
Conference CDR 1	ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD
Conference CDR 2	ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD
Conference CDR 3	ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD
Final CDR

Secure Meet-Me Conference

The following example shows a CDR for a meet-me secure conference. 35010 calls into a secure meet-me conference, but 35010 is a non-secure phone. Because 35010 does not meet the minimum security level of the meet-me conference, the call is cleared with the cause code of 58 (meet-me conference minimum security level not met).

Secure Conference Example

Field Names	Call to the Meet-Me Conference CDR
globalCallID_callId	5045247
origLegCallIdentifier	123456879
destLegCallIdentifier	123456999
callingPartyNumber	35010
originalCalledPartyNumber	50000
finalCalledPartyNumber	50000
lastRedirectDn	50000
origCause_Value	58
dest_CauseValue	0
origCalledPartyRedirectReason	0
lastRedirectRedirectReason	0
origCalledPartyRedirectOnBehalfOf	0
lastRedirectRedirectOnBehalfOf	0
origTerminationOnBehalfOf	6
destTerminationOnBehalfOf	6

Ad Hoc Conference Linking

The ad hoc conference linking feature generates many different CDRs depending on the circumstances of the conference. The following scenarios show some of the different CDRs:

•Conference Linking using Join

•Conference Linking Using Transfer or Direct Transfer

•Removing a Party From a Linked Conference

•Removing a Party (Controller) From a Linked Conference

•Removing the Linked Conference

Conference Linking using Join

The direction of the call between the bridges depends upon which of Carol's two calls is primary. The primary call survives and the secondary call is redirected to the conference.

Alice calls Bob, and Bob conferences in Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2). Two separate conferences are created. Carol is in both conferences. At this point CDR1, CDR2, CDR3, and CDR4 are generated.

Carol joins the two conferences. At this point CDR5 is generated.

When the remaining parties hang up, the remaining CDRs are generated in the order that the parties leave the conference.

Conference LInking using Join Example

Field Names	CDR1: Alice -> Bob (original call)	CDR2: Bob -> Carol (consultation call)	CDR3: Dave -> Carol (original call)	CDR4: Dave -> Ed (consultation call)	CDR5: Carol -> Conference Bridge (conference call)	CDR6: Dave -> Conference Bridge (conference call)
globalCallID_callId	1	2	3	4	3	3
origLegCallIdentifier	11	13	21	23	22	21
destLegCallIdentifier	12	14	22	24	25	26
callingPartyNumber	1000	1001	1003	1003	1002	1003
originalCalledPartyNumber	1001	1002	1002	1004	b0029901222	b0029901222
finalCalledPartyNumber	1001	1002	1002	1004	b0029901222	b0029901222
lastRedirectDn	1001	1002	1002	1004	1003	1003
origTerminationOnBehalfOf	4	4	4	4	4	0
destTerminationOnBehalfOf	4	4	4	4	4	0
lastRedirectRedirectReason	0	0	0	0	98	98
lastRedirectRedirectOnBehalfOf	0	0	0	0	4	4
origConversationID	0	0	0	0	0	0
destConversationID	0	0	0	0	2222	2222
Comment					ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControl lerDn=1003; ConfControl lerDeviceNa me=SEP0003E 333FAD1;Con fRequestorD n-1003;Conf RequestorDe viceName=SE P0003E333FA D1

Field Names	CDR7: Ed -> Conference Bridge (conference call)	CDR8 Dave -> Conference Bridge (conference call)	CDR9: Alice -> Conference Bridge (conference call)	CDR10: Bob -> Conference Bridge (conference call)	CDR11: Carol -> Conference Bridge (conference call)
globalCallID_callId	3	1	1	1	1
origLegCallIdentifier	24	25	11	12	14
destLegCallIdentifier	27	28	15	16	17
callingPartyNumber	1004	b0029901222	1000	1001	1002
originalCalledPartyNumber	b0029901222	b0029901001	b0029901001	b0029901001	b0029901001
finalCalledPartyNumber	b0029901222	b0029901001	b0029901001	b0029901001	b0029901001
lastRedirectDn	1003	1002	1001	1001	1001
origTerminationOnBehalfOf	0	0	0	0	0
destTerminationOnBehalfOf	0	0	0	0	0
lastRedirectRedirectReason	98	98	98	98	98
lastRedirectRedirectOnBehalfOf	4	4	4	4	4
origConversationID	0	2222
destConversationID	2222	1111
Comment	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Conference Linking Using Transfer or Direct Transfer

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2) Two separate conferences are created; Carol is in both conferences. At this point CDR1, CDR2, CDR3, and CDR4 are generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob are in Conference 1 while Dave and Ed are in Conference 2. When the remaining parties hang up, the remaining CDRs are generated in the order the parties leave the conference.

---

Note The direction of the call between the bridges depends on which of Carol's two calls is the primary call. The primary call side is the calling party of the transferred call.

---

Field Names	CDR1: Alice -> Bob (original call)	CDR2: Bob -> Carol (consultation call)	CDR3: Dave -> Carol (original call)	CDR4: Dave -> Carol (consultation call)	CDR5: Carol -> Conference Bridge (conference call)	CDR6: Carol -> Conference Bridge (conference call)
globalCallID_callId	1	2	3	4	1	3
origLegCallIdentifier	11	13	21	23	14	22
destLegCallIdentifier	12	14	22	24	17	25
callingPartyNumber	1000	1001	1003	1003	1002	1002
originalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
finalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
lastRedirectDn	1001	1002	1002	1004	1001	1003
origTerminationOnBehalfOf	4	4	4	4	10	10
destTerminationOnBehalfOf	4	4	4	4	10	10
lastRedirectRedirectReason	0	0	0	0	98	98
lastRedirectRedirectOnBehalfOf	0	0	0	0	4	4
origConversationID	0	0	0	0	0	0
destConversationID	0	0	0	0	1111	2222
Comment					ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Conference Linking Using Transfer or Direct Transfer Example

Field Names	CDR7: Dave-> Conference Bridge (conference call)	CDR8: Ed -> Conference Bridge (conference call)	CDR9: Conference Bridge-> Conference Bridge	CDR-10: Alice -> Conference Bridge (conference call)	CDR11: Bob-> Conference Bridge (conference call)
globalCallID_callId	3	3	1	1	1
origLegCallIdentifier	21	24	17	11	12
destLegCallIdentifier	26	27	28	15	16
callingPartyNumber	1003	1004	b0029901001	1000	1001
originalCalledPartyNumber	b0029901222	b0029901222	b0029901222	b0029901001	b0029901001
finalCalledPartyNumber	b0029901222	b0029901222	b0029901222	b0029901001	b0029901001
lastRedirectDn	1003	1003	1002	1001	1001
origTerminationOnBehalfOf	0	0	0	0	0
destTerminationOnBehalfOf	0	0	0	0	0
lastRedirectRedirectReason	98	98	4	98	98
lastRedirectRedirectOnBehalfOf	4	4	10	4	4
origConversationID	0	0	1111	0	0
destConversationID	2222	2222	2222	1111	1111
Comment	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD

Removing a Party From a Linked Conference

CDRs are generated in the order the parties leave a conference. When the remaining conference only has two parties, the two parties are joined directly together.

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2) Two separate conferences are created; Carol is in both conferences. At this point CDR1, CDR2, CDR3, and CDR4 are generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob are in Conference 1 while Dave and Ed are in Conference 2. Conference 1 and Conference 2 are transferred together. Carol hangs up, and leaves only two parties in Conference 1.

Because there are only two parties in the conference, Bob and the conference link are joined together. At this point, CDR7, CDR8, and CDR9 are generated. Because Bob is the controller in Conference 1, Bob is the calling party in the call between Bob and Conference 2. When the remaining parties hang up, the remaining CDRs are generated in the order the parties leave the conference.

---

Note If Bob is not a controller and the chaining occurs before Bob joins Conference 1, the call between Bob and Conference 2 is generated in the opposite direction of what is shown in the CDRs.

---

The direction of the call between the final two parties of a conference depends on who has been in the conference the longest. The party that has been in the conference the longest becomes the calling party.

Removing a Party from Linked Conference Example

Field Names	CDR1: Alice -> Bob (original call)	CDR2: Bob -> Carol (consultation call)	CDR3: Dave -> Carol (original call)	CDR4: Dave -> Carol (consultation call)	CDR5: Carol -> Conference Bridge (conference call)	CDR6: Carol -> Conference Bridge (conference call)
globalCallID_callId	1	2	3	4	1	3
origLegCallIdentifier	11	13	21	23	14	22
destLegCallIdentifier	12	14	22	24	17	25
callingPartyNumber	1000	1001	1003	1003	1002	1002
originalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
finalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
lastRedirectDn	1001	1002	1002	1004	1001	1003
origTerminationOnBehalfOf	4	4	4	4	10	10
destTerminationOnBehalfOf	4	4	4	4	10	10
lastRedirectRedirectReason	0	0	0	0	98	98
lastRedirectRedirectOnBehalfOf	0	0	0	0	4	4
origConversationID	0	0	0	0	0	0
destConversationID	0	0	0	0	1111	2222
Comment					ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Field Names	CDR7: Alice-> Conference Bridge (conference call)	CDR8: Bob-> Conference Bridge (conference call)	CDR9: Conference Bridge-> Conference Bridge	CDR-10: Bob -> Conference Bridge (conference call)	CDR11: Dave-> Conference Bridge (conference call)	CDR12: Ed -> Conference Bridge (conference call)
globalCallID_callId	1	1	3	3	3	3
origLegCallIdentifier	11	12	25	11	12	24
destLegCallIdentifier	15	16	28	15	16	27
callingPartyNumber	1000	1001	b0029901222	1000	1001	1004
originalCalledPartyNumber	b0029901001	b0029901001	b0029901001	b0029901222	b0029901222	b0029901222
finalCalledPartyNumber	b0029901001	b0029901001	b0029901001	b0029901222	b0029901222	b0029901222
lastRedirectDn	1001	1001	1002	b0029901001	1003	1003
origTerminationOnBehalfOf	16	4	4	4	0	0
destTerminationOnBehalfOf	0	4	4	4	0	0
lastRedirectRedirectReason	98	98	4	98	98	98
lastRedirectRedirectOnBehalfOf	4	4	10	4	4	4
origConversationID	0	0	2222	0	0	0
destConversationID	1111	1111	1111	2222	2222	2222
Comment	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Removing a Party (Controller) From a Linked Conference

CDRs are generated in the order the parties leave a conference. When the remaining conference only has two parties, these two parties are joined directly together.

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2) Two separate conferences are created; Carol is in both conferences. At this point CDR1, CDR2, CDR3, and CDR4 are generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob are in Conference 1, while Dave and Ed are in Conference 2. Conference 1 and Conference 2 are transferred together. Bob hangs up, leaving only two parties connected to Conference 1.

Because there are only two parties in Conference1, Alice and the conference link are joined directly together. At this point, CDR7, CDR8, and CDR9 are generated. Because Alice has been in the conference longer, she becomes the calling party in the call between Alice and Conference 2. When the remaining parties hang up, the remaining CDRs are generated in the order the parties leave the conference.

---

Note The direction of a call between the final two parties of a conference depends on who has been in the conference the longest. The party that has been in the conference the longest becomes the calling party.

---

Removing a Controller from a Linked Conference Example

Field Names	CDR1: Alice -> Bob (original call)	CDR2: Bob -> Carol (consultation call)	CDR3: Dave -> Carol (original call)	CDR4: Dave -> Carol (consultation call)	CDR5: Carol -> Conference Bridge (conference call)	CDR6: Carol -> Conference Bridge (conference call)
globalCallID_callId	1	2	3	4	1	3
origLegCallIdentifier	11	13	21	23	14	22
destLegCallIdentifier	12	14	22	24	17	25
callingPartyNumber	1000	1001	1003	1003	1002	1002
originalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
finalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
lastRedirectDn	1001	1002	1002	1004	1001	1003
origTerminationOnBehalfOf	4	4	4	4	10	10
destTerminationOnBehalfOf	4	4	4	4	10	10
lastRedirectRedirectReason	0	0	0	0	98	98
lastRedirectRedirectOnBehalfOf	0	0	0	0	4	4
origConversationID	0	0	0	0	0	0
destConversationID	0	0	0	0	1111	2222
Comment					ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Field Names	CDR7: Conference Bridge -> Conference Bridge	CDR8: Alice-> Conference Bridge (conference call)	CDR9: Conference Bridge-> Conference Bridge	CDR-10: Alice -> Conference Bridge (conference call)	CDR11: Dave-> Conference Bridge (conference call)	CDR12: Ed -> Conference Bridge (conference call)
globalCallID_callId	1	1	3	3	3	3
origLegCallIdentifier	12	11	25	11	21	24
destLegCallIdentifier	16	15	28	25	26	27
callingPartyNumber	1001	1000	b0029901222	1001	1003	1004
originalCalledPartyNumber	b0029901001	b0029901001	b0029901001	b0029901222	b0029901222	b0029901222
finalCalledPartyNumber	b0029901001	b0029901001	b0029901001	b0029901222	b0029901222	b0029901222
lastRedirectDn	1001	1001	1002	b0029901001	1003	1003
origTerminationOnBehalfOf	4	16	4	4	0	0
destTerminationOnBehalfOf	4	0	4	4	0	0
lastRedirectRedirectReason	98	98	4	98	98	98
lastRedirectRedirectOnBehalfOf	4	4	10	4	4	4
origConversationID	0	0	2222	0	0	0
destConversationID	1111	1111	1111	2222	2222	2222
Comment	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Removing the Linked Conference

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2) Two separate conferences are created; Carol is in both conferences. At this point CDR1, CDR2, CDR3, and CDR4 are generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob are in Conference 1, while Dave and Ed are in Conference 2. Conference 1 and Conference 2 are transferred together.

Bob presses the ConfList softkey and has Alice, Bob, and the conference link "Conference" shown in the list. Bob selects "Conference" and presses the Remove softkey. At this point, CDR7, CDR8, and CDR9 are generated. The conference link is removed, leaving two parties in the conference.

The remaining two parties are joined together. In Conference 1, Alice and Bob are joined together, and in Conference 2, Dave and Ed are joined together. When the remaining parties hang up, the remaining CDRs are generated in the order the parties leave the conference.

Removing the Linked Conference Example

Field Names	CDR1: Alice -> Bob (original call)	CDR2: Bob -> Carol (consultation call)	CDR3: Dave -> Carol (original call)	CDR4: Dave -> Carol (consultation call)	CDR5: Carol -> Conference Bridge (conference call)	CDR6: Carol -> Conference Bridge (conference call)
globalCallID_callId	1	2	3	4	1	3
origLegCallIdentifier	11	13	21	23	14	22
destLegCallIdentifier	12	14	22	24	17	25
callingPartyNumber	1000	1001	1003	1003	1002	1002
originalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
finalCalledPartyNumber	1001	1002	1002	1004	b0029901001	b0029901222
lastRedirectDn	1001	1002	1002	1004	1001	1003
origTerminationOnBehalfOf	4	4	4	4	10	10
destTerminationOnBehalfOf	4	4	4	4	10	10
lastRedirectRedirectReason	0	0	0	0	98	98
lastRedirectRedirectOnBehalfOf	0	0	0	0	4	4
origConversationID	0	0	0	0	0	0
destConversationID	0	0	0	0	1111	2222
Comment					ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Field Names	CDR7: Conference Bridge > Conference Bridge	CDR8: Alice-> Conference Bridge (conference call)	CDR9: Bob -> Conference Bridge	CDR-10: Dave-> Conference Bridge (conference call)	CDR11: Ed-> Conference Bridge (conference call)	CDR12: Bob -> Alice
globalCallID_callId	3	1	1	3	3	3
origLegCallIdentifier	25	11	12	21	24	21
destLegCallIdentifier	28	15	16	26	27	24
callingPartyNumber	b0029901222	1000	1001	1003	1004	1003
originalCalledPartyNumber	b0029901001	b0029901001	b0029901001	b0029901222	b0029901222	b0029901222
finalCalledPartyNumber	b0029901001	b0029901001	b0029901001	b0029901222	b0029901222	1004
lastRedirectDn	1002	1001	1001	1003	1003	b0029901222
origTerminationOnBehalfOf	4	4	4	16	0	0
destTerminationOnBehalfOf	4	4	4	0	0	0
lastRedirectRedirectReason	4	98	98	98	98	98
lastRedirectRedirectOnBehalfOf	10	4	4	4	4	4
origConversationID	2222	0	0	0	0	0
destConversationID	1111	1111	1111	2222	2222	0
Comment	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1001;Co nfController DeviceName=S EP0003E333FE BD;ConfReque storDn-1001; ConfRequesto rDeviceName= SEP0003E333F EBD	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Field Names	CDR13: Dave -> Ed
globalCallID_callId	3
origLegCallIdentifier	21
destLegCallIdentifier	24
callingPartyNumber	1003
originalCalledPartyNumber	b0029901222
finalCalledPartyNumber	1004
lastRedirectDn	b0029901222
origTerminationOnBehalfOf	0
destTerminationOnBehalfOf	0
lastRedirectRedirectReason	98
lastRedirectRedirectOnBehalfOf	4
origConversationID	0
destConversationID	0
Comment	ConfControll erDn=1003;Co nfController DeviceName=S EP0003E333FA D1;ConfReque storDn-1003; ConfRequesto rDeviceName= SEP0003E333F AD1

Call Park

Call Park will generate two CDRs, one for the original call that is parked and another for the call that is picked up or reverted. These CDRs will have the same globalCallID_callId. This section contains the following CDR examples:

•Call Park Pickup

•Call Park Reversion

Call Park Pickup

When the call is parked, the call gets split. The original call generates a CDR. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR.

When the parked call is retrieved, the user goes off hook and enters the park code. This call joins with the parked call. Because the user who is picking up the call is joined with the parked call, the system treats the user as the originator of the call, and the parked user gets treated as the destination. This means that the callingPartyNumber of the call contains the directory number of the user who is picking up the call, and the originalCalledNumber and finalCalledNumber contains the directory number of the parked user. The lastRedirectDn contains the park code that is used to pick up the call. The lastRedirectRedirectReason specifies Call Park Pickup = 8. The lastRedirectRedirectOnBehalfOf should specify Call Park = 3.

Call Park Example

50003 calls 50002; 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code (44444).

Field Names	Original Call That Is Parked CDR	Parked Call That Is Picked Up CDR
globalCallID_callId	1	1
origLegCallIdentifier	20863957	20863961
destLegCallIdentifier	20863958	20863957
callingPartyNumber	50003	50001
originalCalledPartyNumber	50002	50003
finalCalledPartyNumber	50002	50003
lastRedirectDn	50002	44444
origCause_Value	393216	0
dest_CauseValue	393216	16
origCalledPartyRedirectReason	0	0
lastRedirectRedirectReason	0	8
origCalledPartyRedirectOnBehalfOf	0	0
lastRedirectRedirectOnBehalfOf	0	3
origTerminationOnBehalfOf	3	0
destTerminationOnBehalfOf	3	12
joinOnBehalfOf	0	3
duration	4	60

Call Park Reversion

When a call is parked and not picked up, the call park reversion timer will expire and redirect the call to the called party. In this case, the system generates two CDRs. The first CDR appears the same as the preceding Call Park Pickup scenario, but the second CDR differs slightly. When the Call Pickup Reversion timer expires, the call gets redirected to the called party.

When the call is parked, the call gets split. This action generates a CDR for the original call. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR, the same as the Call Park Pickup scenario.

When the Call Park Reversion timer expires, the call gets redirected to the called party. The origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields specify Call Park = 3. The origCalledPartyRedirectReason field specifies Call Park = 7, and the lastRedirectRedirectReason field specifies Call Park Reversion = 11.

Call Park Reversion Example

•Call Park Reversion Example - 50003 calls 50002; 50002 presses the Park softkey. Nobody picks up the parked call; it reverts to 50002, and 50002 answers.

Field Names	Original Call That Is Parked CDR	Reverted Call CDR
globalCallID_callId	2	2
origLegCallIdentifier	20863963	20863963
destLegCallIdentifier	20863964	20863967
callingPartyNumber	50003	50003
originalCalledPartyNumber	50002	50002
finalCalledPartyNumber	50002	50002
lastRedirectDn	50002	50002
origCause_Value	393216	0
dest_CauseValue	393216	16
origCalledPartyRedirectReason	0	7
lastRedirectRedirectReason	0	11
origCalledPartyRedirectOnBehalfOf	0	3
lastRedirectRedirectOnBehalfOf	0	3
origTerminationOnBehalfOf	3	3
destTerminationOnBehalfOf	3	12
joinOnBehalfOf	0	3
duration	7	60

Precedence Calls (MLPP)

With precedence calls, everything basically remains the same for all calls: normal calls, forwarded calls, transferred calls, and so forth. The differences include the precedence level fields that are set in the CDR, and when a call is preempted by a higher level precedence call, the cause codes indicate the reason for the preemption.

Precedence Call Examples

•Call to another IP phone by dialing a precedence pattern (precedence level 2).

Field Names	Precedence Call CDR
globalCallID_callId	100
origLegCallIdentifier	12345
destLegCallIdentifier	12346
callingPartyNumber	2001
origCalledPartyNumber	826001
origCause_Value	0
dest_CauseValue	16
origPrecedenceLevel	2
destPrecedenceLevel	2

•Received precedence call from another network (precedence level 1)

Field Names	Precedence Call CDR
globalCallID_callId	102
origLegCallIdentifier	11111
destLegCallIdentifier	11112
callingPartyNumber	9728552001
origCalledPartyNumber	6001
origCause_Value	16
dest_CauseValue	0
origPrecedenceLevel	1
destPrecedenceLevel	1

•Call gets preempted by a higher precedence level call.

Field Names	Original call CDR	Higher Level Call CDR
globalCallID_callId	10000	10001
origLegCallIdentifier	12345678	12345680
destLegCallIdentifier	12345679	12345681
callingPartyNumber	2001	9728551234
origCalledPartyNumber	826001	826001
origCause_Value	0	0
dest_CauseValue	9	16
origPrecedenceLevel	2	1
destPrecedenceLevel	2	1

Malicious Calls

When a call is identified as a malicious call (button press), the local network Cisco Unified CallManager flags the call. The "comment" field gets used to flag the malicious call.

Malicious Call Example

•Customer call marked as malicious.

Field Names	Original call CDR
globalCallID_callId	1
origLegCallIdentifier	100
destLegCallIdentifier	101
callingPartyNumber	9728552001
origCalledPartyNumber	5555
origCause_Value	0
dest_CauseValue	16
Comment	callFlag=MALICIOUS

Immediate Divert (to Voice-Messaging System)

Immediate Divert (IDivert) gets invoked in three different call states:

•You can invoke the IDivert feature while the incoming call is ringing. The CDR for the ringing case acts very similar to call forwarding, but the origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf fields specify Immediate Divert = 14.

•You can invoke the IDivert feature while the call is connected or on hold. These scenarios generate two CDRs. Both CDRs have the same globalCallID_CallId field. The first CDR applies to the original connection, and the second CDR applies to the call redirected to the voice-messaging system. The first call will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields set to Immediate Divert = 14.

•The call that is redirected to the voice-messaging system will have the origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields set to Immediate Divert = 14.

IDivert Examples

•IDivert during Alerting - 40003 calls 40001, and while 40001 is ringing, 40001 presses the IDivert button and call diverts to the voice-messaging system 40000.

---

Note If the call is redirected by IDivert in the Alerting state, only one CDR gets generated.

---

Field Names	Original call CDR
globalCallID_callId	37
origLegCallIdentifier	16777327
destLegCallIdentifier	16777329
callingPartyNumber	40003
origCalledPartyNumber	40001
finalCalledPartyNumber	40000
lastRedirectDn	40001
origCause_Value	16
dest_CauseValue	0
origCalledPartyRedirectReason	50
lastRedirectRedirectReason	50
origCalledPartyRedirectOnBehalfOf	14
lastRedirectRedirectOnBehalfOf	14
joinOnBehalfOf	14

•IDivert during Connect - 40003 calls 40001, and 40001 answers the call. 40001 decides to divert the caller to the voice-messaging system and presses the IDivert softkey. 40003 gets diverted to the voice-messaging system 40000.

Because the call was connected before the redirect, two CDRs get generated: one for the original connected call, and another for the call diverted to the voice-messaging system.

Field Names	Original Connected Call CDR	Diverted Call CDR
globalCallID_callId	38	38
origLegCallIdentifier	16777330	16777330
destLegCallIdentifier	16777331	16777332
callingPartyNumber	40003	40003
origCalledPartyNumber	40001	40001
finalCalledPartyNumber	40001	40000
lastRedirectDn	40001	40001
origCause_Value	0	16
dest_CauseValue	0	0
origCalledPartyRedirectReason	0	50
lastRedirectRedirectReason	0	50
origCalledPartyRedirectOnBehalfOf		14
lastRedirectRedirectOnBehalfOf		14
origTerminationOnBehalfOf	14	14
destTerminationOnBehalfOf	14	12
joinOnBehalfOf		14

Barge

When a shared line uses the barge feature, the origCalledPartyNumber, finalCalledPartyNumber, and lastRedirectDn represent the conference bridge number `b00...'. The redirect and join OnBehalfOf fields have a value of Barge = 15, and the redirect reason fields specify Barge = 114.

Barge Examples

•Barge Example 1- 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40003 hangs up.

---

Note Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.

---

Field Names	Original Call CDR	Barge Call CDR
globalCallID_callId	7	7
origLegCallIdentifier	16777230	16777232
destLegCallIdentifier	16777231	16777235
callingPartyNumber	40003	40003
origCalledPartyNumber	40001	b001501001
finalCalledPartyNumber	40001	b001501001
lastRedirectDn	40001	b001501001
origCause_Value	16	0
dest_CauseValue	0	0
origCalledPartyRedirectReason	0	114
lastRedirectRedirectReason	0	114
origCalledPartyRedirectOnBehalfOf		15
lastRedirectRedirectOnBehalfOf		15
joinOnBehalfOf		15
destConversationID	0	16777231

•Barge Example 2- 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40001 hangs up.

---

Note Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.

---

Field Names	Original Call CDR	Barge Call CDR	Final Call CDR
globalCallID_callId	9	9	9
origLegCallIdentifier	16777236	16777238	16777236
destLegCallIdentifier	16777237	16777241	16777238
callingPartyNumber	40003	40001	40003
origCalledPartyNumber	40001	b001501001	40001
finalCalledPartyNumber	40001	b001501001	40001
lastRedirectDn	40001	b001501001	40001
origCause_Value	0	393216	16
dest_CauseValue	16	393216	0
origCalledPartyRedirectReason	0	114	0
lastRedirectRedirectReason	0	114	0
origTerminationOnBehalfOf		15	12
destTerminationOnBehalfOf	12	15	12
lastRedirectRedirectOnBehalfOf		15
joinOnBehalfOf		15
destConversationID	0	16777237	0

•Barge Example 3- 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40001' (another shared line and phone) presses the Barge softkey. 40003 hangs up first.

---

Note All CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.

---

Field Names	Original Call CDR	Barge Call 1 CDR	Barge Call 2 CDR
globalCallID_callId	14	14	14
origLegCallIdentifier	16777249	16777251	16777255
destLegCallIdentifier	16777250	16777254	16777258
callingPartyNumber	40003	40001	40001
origCalledPartyNumber	40001	b001501001	b001501001
finalCalledPartyNumber	40001	b001501001	b001501001
lastRedirectDn	40001	b001501001	b001501001
origCause_Value	16	0	0
dest_CauseValue	0	0	0
origCalledPartyRedirectReason	0	114	114
lastRedirectRedirectReason	0	114	114
origTerminationOnBehalfOf	12	15	15
destTerminationOnBehalfOf
origRedirectOnBehalfOf		15	15
lastRedirectRedirectOnBehalfOf		15	15
joinOnBehalfOf		15	15
destConversationID	0	16777250	16777251

cBarge

The cBarge feature acts very similar to the conference feature. When a shared line uses the cBarge feature, the origCalledPartyNumber, finalCalledPartyNumber and lastRedirectDn represent the conference bridge number `b00...'. The redirect and join OnBehalfOf fields have a value of Conference = 4, and the redirect reason fields specify Conference = 98.

cBarge Examples

•cBarge Example - 40003 calls 40001, and 40001 answers; 40001' (shared line) on another phone presses the cBarge button.

Field Names	Orig Call CDR	cBarge Call CDR 1	cBarge Call CDR 2	cBarge Call CDR 3	Final Call CDR
globalCallID_callId	49	49	49	49	49
origLegCallIdentifier	1677346	1677348	1677347	1677346	1677347
destLegCallIdentifier	1677347	1677353	1677351	1677352	1677346
callingPartyNumber	40003	40001	40001	40003	40001
originalCalledPartyNumber	40001	b0029901001	b0029901001	b0029901001	40003
finalCalledPartyNumber	40001	b0029901001	b0029901001	b0029901001	40003
lastRedirectDn	40001	b0029901001	40001	40001	b0029901001
origCause_Value	393216	16	393216	393216	16
dest_CauseValue	393216	0	393216	393216	0
origCalledPartyRedirectReason	0	98	98	98	0
lastRedirectRedirectReason	0	98	98	98	98
destTerminationOnBehalfOf	4		4	4	4
origCalledRedirectOnBehalfOf		4	4	4
lastRedirectRedirectOnBehalfOf		4	4	4	4
joinOnBehalfOf		4	4	4	4
Conversation ID	0	16777220	16777220	16777220	1
duration	60	360		360	360

Comment
Orig Call CDR
cBarge Call CDR 1	ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
cBarge Call CDR 2	ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
cBarge Call CDR 3	ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
Final Call CDR	ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD

Video Calls

The following example shows a CDR for a video call.

Video Calls Example

•Example - Calling party 51234 calls the called party 57890. In the following example, let 100 = H.261, 187962284 = 172.19.52.11, 288625580 = 172.19.52.17, 320 = 320K, and 2 = QCIF.

Field Names	Video Call CDR
globalCallID_callId	121
origLegCallIdentifier	101
destLegCallIdentifier	102
callingPartyNumber	51234
origCalledPartyNumber	57890
finalCalledPartyNumber	57890
lastRedirectDn	57890
origCause_Value	0
dest_CauseValue	16
origVideoCap_Codec	100
origVideoCap_Bandwidth	320
origVideoCap_Resolution	2
origVideoTransportAddress_IP	187962284
origVideoTransportAddress_Port	49208
destVideoCap_Codec	100
destVideoCap_Bandwidth	320
destVideoCap_Resolution	2
destVideoTransportAddress_IP	288625580
destVideoTransportAddress_Port	49254

Forced Authorization Code (FAC)

When the FAC feature is invoked, the system writes the authorization description and level into the CDR. For security reasons, the actual authorization code does not get written to the CDR.

•The authCodeDescription field contains the description of the authorization code.

•The authorizationLevel field contains the level of authorization that is associated with the authorization code.

FAC Example

45000 calls 9728134987; the system prompts the user for an authorization code and enters 12345. FAC code 12345 gets configured as level 1 and name Legal1. The caller answers the call and talks for 2 minutes.

Field Names	Values
globalCallID_callId	100
origLegCallIdentifier	16777123
destLegCallIdentifier	16777124
callingPartyNumber	45000
origCalledPartyNumber	9728134987
finalCalledPartyNumber	9728134987
lastRedirectDn	9728134987
origCause_Value	0
dest_CauseValue	16
authCodeDescription	Legal1
authorizationLevel	1
duration	120

Client Matter Code (CMC)

When the CMC feature is invoked, the system writes the client matter code into the CDR. The clientMatterCode field contains the client matter code that the caller entered.

CMC Example

•10000 calls 2142364624; the user gets prompted for a client matter code and enters 11111. The caller answers the call and talks for 10 minutes.

Field Names	Values
globalCallID_callId	101
origLegCallIdentifier	16777130
destLegCallIdentifier	16777131
callingPartyNumber	10000
origCalledPartyNumber	2142364624
finalCalledPartyNumber	2142364624
lastRedirectDn	2142364624
origCause_Value	0
dest_CauseValue	16
clientMatterCode	11111
duration	600

Call Secured Status

This field identifies security status of the call. It contains the highest level of security that is reached during a call. For example, if the call is originally unsecured, later the call changes to secured, the CDR contains 1 for "Secured" even though different portions of the call had different status values. The callSecuredStatus field will identify the security status of the call.

Call Secured Status Examples

•Encrypted Call Example - The system encrypts the call between 20000 and 20001. The parties talk for 5 minutes.

Field Names	CDR
globalCallID_callId	102
origLegCallIdentifier	16777140
destLegCallIdentifier	16777141
callingPartyNumber	20000
origCalledPartyNumber	20001
finalCalledPartyNumber	20001
lastRedirectDn	20001
origCause_Value	0
dest_CauseValue	16
callSecuredStatus	2
duration	300

•Authenticated Call Example - The call between 20000 and 20001 gets authenticated (not encrypted). They talk for 10 minutes.

Field Names	CDR
globalCallID_callId	103
origLegCallIdentifier	16777142
destLegCallIdentifier	16777143
callingPartyNumber	20000
origCalledPartyNumber	20001
finalCalledPartyNumber	20001
lastRedirectDn	20001
origCause_Value	0
dest_CauseValue	16
callSecuredStatus	1
duration	600

DTMF Method

These fields identify the DTMF method that is used for the call.

DTMF Call Examples

•No Preference Example - The DTMF method that is used during this call represents No Preference/Best Effort. This call connects for 1 minute.

Field Names	CDR
globalCallID_callId	200
origLegCallIdentifier	16777500
destLegCallIdentifier	16777501
callingPartyNumber	20000
origCalledPartyNumber	20001
finalCalledPartyNumber	20001
lastRedirectDn	20001
origCause_Value	0
dest_CauseValue	16
origDTMFMethod	0
destDTMFMethod	0
duration	60

•Preferred OOB Example - The DTMF method that is used during this call represents OOB Preferred. This call remains connected for 1 minute.

Field Names	CDR
globalCallID_callId	201
origLegCallIdentifier	16777502
destLegCallIdentifier	16777503
callingPartyNumber	20000
origCalledPartyNumber	20001
finalCalledPartyNumber	20001
lastRedirectDn	20001
origCause_Value	0
dest_CauseValue	16
origDTMFMethod	1
destDTMFMethod	1
duration	60

RSVP

These fields identify the status of RSVP reservation for the call. Be aware that the Cisco Unified Communications Manager RSVP CDR status field value gets concatenated, and the system retains the last 32 status values for the call.

For example, if a call is established with "Optional" policy, and the initial RSVP reservation is successful, and then it subsequently loses its bandwidth reservation and then regains its bandwidth reservation after retry, for several times during middle of the call, the call ends with a successful RSVP reservation. The CDR shows the following string as the Unified Communication RSVP reservation status for that particular stream: "2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success).

RSVP Call Examples

•The example represents a call that gets established with "Optional" policy, and the initial RSVP reservation succeeds. The parties talk for 5 minutes.

Field Names	CDR
globalCallID_callId	300
origLegCallIdentifier	16777300
destLegCallIdentifier	16777301
callingPartyNumber	20000
origCalledPartyNumber	20001
finalCalledPartyNumber	20001
lastRedirectDn	20001
origCause_Value	0
dest_CauseValue	16
origDTMFMethod	2
destDTMFMethod	2
duration	300

•The example represents a call that is established with "Optional" policy, and the initial RSVP reservation succeeds, then it loses its bandwidth reservation but regains it after a retry. The parties talk for 1 minute.

Field Names	CDR
globalCallID_callId	301
origLegCallIdentifier	16777302
destLegCallIdentifier	16777303
callingPartyNumber	20000
origCalledPartyNumber	20001
finalCalledPartyNumber	20001
lastRedirectDn	20001
origCause_Value	0
dest_CauseValue	16
origDTMFMethod	2:5:2
destDTMFMethod	2:5:2
duration	60

Redirection (3xx) Calls

This example shows CDRs for a the redirection feature (3xx).

When a call is redirected by the Redirection Feature (3xx), the origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields specify Unified CM Redirection = 19. The origCalledPartyRedirectReason and the lastRedirectRedirectReason specify Redirection = 162.

Redirection (3xx) Examples

•Redirection Example - Activate CFA on phone 10010 that is running SIP (registered to Cisco Unified Communications Manager) with a CFA destination of 10000. 35010 calls 10010, which is CFA to 10000. The call gets redirected from 10010 to 10000. 10000 answers the call and talks for 1 minute.

Field Names	Original Call CDR
globalCallID_callId	11
origLegCallIdentifier	21832023
destLegCallIdentifier	21832026
callingPartyNumber	35010
originalCalledPartyNumber	10010
finalCalledPartyNumber	10000
lastRedirectDn	10010
origCause_Value	0
dest_CauseValue	16
origCalledPartyRedirectReason	162
lastRedirectRedirectReason	162
origCalledPartyRedirectOnBehalfOf	19
lastRedirectRedirectOnBehalfOf	19
origTerminationOnBehalfOf	0
destTerminationOnBehalfOf	12
joinOnBehalfOf	19
duration	60

Replaces Calls

The examples show CDRs for various types of Replaces calls.

Replaces Examples

•Invite with Replaces - Phone 35010 that is running SIP calls phone 35020 that is running SIP. The transfer button gets pressed on 35010, and a call gets placed to SCCP phone 3000, 3000 answers the call; then, phone 35010 completes the transfer. The final transferred call occurs between 35020 and 3000.

---

Note When the transfer is complete, the system sends an Invite with Replaces to Cisco Unified Communications Manager.

---

Field Names	Original Call CDR	Reverted Call CDR
globalCallID_callId	5045247	5045248
origLegCallIdentifier	21822467	21822469
destLegCallIdentifier	21822468	21822468
callingPartyNumber	35010	35020
originalCalledPartyNumber	3000	3000
finalCalledPartyNumber	3000	3000
lastRedirectDn	3000	35010
origCause_Value	393216	0
dest_CauseValue	393216	16
origCalledPartyRedirectReason	0	0
lastRedirectRedirectReason	0	146
origCalledPartyRedirectOnBehalfOf	0	0
lastRedirectRedirectOnBehalfOf	0	18
origTerminationOnBehalfOf	18	0
destTerminationOnBehalfOf	18	12
joinOnBehalfOf	0	18
duration	5	60

•Refer with Replaces - Phone 35010 that is running SIP calls SCCP 3000, the transfer button gets pressed on 35010, and a call is placed to SCCP 3001; 3001 answers the call; then, phone 35010 completes the transfer. The final transferred call occurs between 3000 and 3001.

---

Note When the transfer completes, a Refer with Replaces gets sent to Cisco Unified Communications Manager.

---

Field Names	Original Call CDR	Consultation Call CDR	Final Transferred Call CDR
globalCallID_callId	5045245	5045246	5045245
origLegCallIdentifier	21822461	21822463	21822462
destLegCallIdentifier	21822462	21822464	21822464
callingPartyNumber	35010	35010	3000
originalCalledPartyNumber	3000	3001	3001
finalCalledPartyNumber	3000	3001	3001
lastRedirectDn	3000	3001	35010
origCause_Value	393216	393216	16
dest_CauseValue	393216	393216	0
origCalledPartyRedirectReason	0	0	130
lastRedirectRedirectReason	0	0	146
origCalledPartyRedirectOnBehalfOf	0	0	17
lastRedirectRedirectOnBehalfOf	0	0	18
origTerminationOnBehalfOf	17	18	12
destTerminationOnBehalfOf	17	18	17
joinOnBehalfOf	0	0	18
duration	25	4	25

Refer Calls

See the "Replaces Calls" section for an example of Refer with Replaces.

Monitor Calls

The following examples show CDRs for Monitor calls.

Monitor Examples

•Monitor Example 1 - The customer (9728134987) calls the agent (30000), and the agent answers. The supervisor (40003) monitors the call. The destConversationID from the monitoring call matches the destLegCallIdentifier of the monitored call.

Field Names	Monitored Call CDR	Monitoring Call CDR
globalCallID_callId	7	10
origLegCallIdentifier	16777230	16777232
destLegCallIdentifier	16777231	16777235
callingPartyNumber	9728134987	40003
originalCalledPartyNumber	30000	b001501001
finalCalledPartyNumber	30000	b001501001
lastRedirectDn	30000	b001501001
origCause_Value	16	0
dest_CauseValue	0	0
origCalledPartyRedirectReason	0	370
lastRedirectRedirectReason	0	370
origCalledPartyRedirectOnBehalfOf		28
lastRedirectRedirectOnBehalfOf		28
destConversationID	0	16777231

•Monitor Example 2 - The agent (30000) calls the customer (9728134987), and the customer answers. The supervisor (40003) monitors the call. The destConversationID from the monitoring call matches the origLegCallIdentifier of the monitored call.

Field Names	Monitored Call CDR	Monitoring Call CDR
globalCallID_callId	71	101
origLegCallIdentifier	16777299	16777932
destLegCallIdentifier	16777300	16777935
callingPartyNumber	30000	40003
originalCalledPartyNumber	9728134987	b001501002
finalCalledPartyNumber	9728134987	b001501002
lastRedirectDn	9728134987	b001501002
origCause_Value	16	0
dest_CauseValue	0	0
origCalledPartyRedirectReason	0	370
lastRedirectRedirectReason	0	370
origCalledPartyRedirectOnBehalfOf		28
lastRedirectRedirectOnBehalfOf		28
destConversationID	0	16777299

Recording Calls

The following examples show CDRs for Recording Calls.

Recording Calls Examples

•Recording Calls Example 1 - The customer (9728134987) calls the agent (30000), and the agent answers. The recording feature creates two recording calls to the recording device and results in two additional CDRs: one for the agent voice and another for the customer voice. The origConversationID field from the recording CDRs matches the destLegCallIdentifier of the recorded call. In this example, the customer hangs up.

Field Names	Recorded Call CDR	Recording Call CDR1	Recording Call CDR2
globalCallID_callId	7	10	11
origLegCallIdentifier	16777110	16777120	16777122
destLegCallIdentifier	16777111	16777121	16777123
callingPartyNumber	9728134987	30000	30000
originalCalledPartyNumber	30000	90000	90000
finalCalledPartyNumber	30000	90000	90000
lastRedirectDn	30000	90000	90000
origCause_Value	16	0	0
dest_CauseValue	0	0	0
origCalledPartyRedirectReason	0	354	354
lastRedirectRedirectReason	0	354	354
origCalledPartyRedirectOnBehalfOf		27	27
lastRedirectRedirectOnBehalfOf		27	27
destConversationID	0	16777111	16777111

•Recording Calls Example 2 - The agent (30000) calls the customer (9728134987), and the customer answers. The recording feature creates two recording calls to the recording device, and results in two additional CDRs: one for the agent voice and another for the customer voice. The origConversationID field from the recording CDR matches the origLegCallIdentifier of the recorded call. In this example, the agent hangs up.

Field Names	Recorded Call CDR	Recording Call CDR1	Recording Call CDR2
globalCallID_callId	71	100	110
origLegCallIdentifier	16777113	16777220	16777222
destLegCallIdentifier	16777114	16777221	16777223
callingPartyNumber	30000	30000	30000
originalCalledPartyNumber	9728134987	90000	90000
finalCalledPartyNumber	9728134987	90000	90000
lastRedirectDn	9728134987	90000	90000
origCause_Value	16	16	16
dest_CauseValue	0	0	0
origCalledPartyRedirectReason	0	354	354
lastRedirectRedirectReason	0	354	354
origCalledPartyRedirectOnBehalfOf		27	27
lastRedirectRedirectOnBehalfOf		27	27
destConversationID	0	16777113	16777113

AAC and iLBC Calls

The following examples show CDRs for AAC and iLBC calls.

AAC Call Example

•This example applies to a call with AAC codec.

Field Names	AAC CDR
globalCallID_callId	121
origLegCallIdentifier	101
destLegCallIdentifier	102
callingPartyNumber	51234
originalCalledPartyNumber	57890
finalCalledPartyNumber	57890
lastRedirectDn	57890
origCause_Value	0
dest_CauseValue	16
origMediaCap_payloadCapability	42
origMediaCap_Bandwidth	256
destMediaCap_payloadCapability	42
destMediaCap_Bandwidth	256

iLBC Call Example

•This example applies to a call with iLBC codec.

Field Names	iLBC CDR
globalCallID_callId	121
origLegCallIdentifier	101
destLegCallIdentifier	102
callingPartyNumber	51234
originalCalledPartyNumber	57890
finalCalledPartyNumber	57890
lastRedirectDn	57890
origCause_Value	0
dest_CauseValue	16
origMediaCap_payloadCapability	86
origMediaCap_Bandwidth	15
destMediaCap_payloadCapability	86
destMediaCap_Bandwidth	15

Mobility

The following examples show CDRs for mobility calls.

Mobility Examples

•Mobility Follow Me Example - A dual-mode phone has the Enterprise number of 22285 and the cell number of 9728324124. 22202 calls 22285, and both 22285 and 9728324124 ring. The cell phone answers the call. The system generates a single CDR for this Follow Me call. The parties talk for 80 seconds.

Field Names	Follow Me Call CDR
globalCallID_callId	861
origLegCallIdentifier	22481077
destLegCallIdentifier	22481078
callingPartyNumber	22202
originalCalledPartyNumber	22285
finalCalledPartyNumber	9728324124
lastRedirectDn	22285
origCause_Value	16
dest_CauseValue	0
lastRedirectRedirectReason	0
lastRedirectRedirectOnBehalfOf	0
origTerminationOnBehalfOf
destTerminationOnBehalfOf
joinOnBehalfOf	0
duration	80

•Mobility HandIn Example - A dual-mode phone with the Enterprise number of 22285 and the cell number of 9728324124 calls to the cell phone 9728324214. They talk for 39 seconds; then, the dual-mode phone gets carried into the Enterprise network, and the call gets switched from the cell network to the Enterprise network. The parties continue to talk for another 15 seconds.

Field Names	Call to cell #9728324214 CDR	HandIn Call to the Enterprise CDR
globalCallID_callId	864	864
origLegCallIdentifier	22481083	22481083
destLegCallIdentifier	22481085	22481087
callingPartyNumber	22202	22202
originalCalledPartyNumber	919728324124	22285
finalCalledPartyNumber	919728324124	22285
lastRedirectDn	919728324124	22285
origCause_Value	393216	0
dest_CauseValue	393216	16
lastRedirectRedirectReason	0	303
lastRedirectRedirectOnBehalfOf	0	24
origTerminationOnBehalfOf	24	24
destTerminationOnBehalfOf	24	12
joinOnBehalfOf	0	24
duration	39	15

•Mobility HandOut Example - A dual-mode phone has the Enterprise number of 22285 and the cell number of 9728324124. The handout number (H-number) specifies 555123. A call goes to the Enterprise number 22285. They talk for 21 seconds; then, the dual-mode phone gets carried out of the Enterprise network and into the cell network. The call gets switched from the Enterprise network to the cell network (9728324124). The parties continue to talk for another 39 seconds.

Field Names	Enterprise Call to 22285 CDR	Server Call from cell phone to H-Number CDR	Handout Call CDR
globalCallID_callId	964	965	964
origLegCallIdentifier	22481083	22481095	22481093
destLegCallIdentifier	22481094	22481096	22481095
callingPartyNumber	22202	9728324124	22202
originalCalledPartyNumber	22285	555123	9728324124
finalCalledPartyNumber	22285	555123	9728324124
lastRedirectDn	22285	555123	9728324124
origCause_Value	393216	393216	0
dest_CauseValue	393216	393216	16
lastRedirectRedirectReason	0	0	319
lastRedirectRedirectOnBehalfOf	0	0	24
origTerminationOnBehalfOf	24	24	24
destTerminationOnBehalfOf	24	24	12
joinOnBehalfOf	0	0	24
duration	21	0	39

•Mobility Call Pickup Example - A dual-mode phone with the Enterprise number of 22285 and the cell number of 9728324124, establishes a call to the Enterprise number 22285. They talk for 40 seconds; then, call pickup gets invoked. The call gets switched from the Enterprise phone to the cell phone. The parties continue to talk for another 111 seconds.

Field Names	Enterprise Call to 22285 CDR	Server Call to Cell Phone CDR	Final Handout Call CDR
globalCallID_callId	555	566	964
origLegCallIdentifier	22481111	22481222	22481111
destLegCallIdentifier	22481112	22481223	22481222
callingPartyNumber	22202		22202
originalCalledPartyNumber	22285	9728324124	9728324124
finalCalledPartyNumber	22285	9728324124	9728324124
lastRedirectDn	22285	9728324124	9728324124
origCause_Value	393216	0	0
dest_CauseValue	393216	0	16
lastRedirectRedirectReason	0	0	335
lastRedirectRedirectOnBehalfOf	0	0	24
origTerminationOnBehalfOf	24	24	24
destTerminationOnBehalfOf	24	24	12
joinOnBehalfOf	0	0	24
duration	40	0	111

•Mobility IVR Example - A call comes into the Cisco Unified Communications Manager with string DID#RemoteDest#TargetNum#. The call gets redirected to the TargetNum. 9728131234 calls into an IVR, and data gets collected. The target destination specifies 812345 and the call gets redirected to 812345. The call remains connected for 60 seconds.

Field Names	Redirected Call CDR
globalCallID_callId	12345
origLegCallIdentifier	16677100
destLegCallIdentifier	16677102
callingPartyNumber	9728131234
originalCalledPartyNumber	8005559876
finalCalledPartyNumber	812345
lastRedirectDn	8005559876
origCause_Value	0
dest_CauseValue	16
lastRedirectRedirectReason	399
lastRedirectRedirectOnBehalfOf	24
origTerminationOnBehalfOf	0
destTerminationOnBehalfOf	0
duration	60

Intercom Calls

The following two examples show CDRs for intercom.

Intercom Examples

•Whisper Intercom Example - Phone 20000 invokes the intercom. The configured intercom partition name specifies "Intercom."

Field Names	Original Call CDR
globalCallID_callId	1111000
origLegCallIdentifier	21822467
destLegCallIdentifier	21822468
callingPartyNumber	20000
originalCalledPartyNumber	20001
finalCalledPartyNumber	20001
origCause_Value	16
dest_CauseValue	0
origMediaTransportAddress_IP	0
origMediaTransportAddress_Port	0
destMediaTransportAddress_IP	-47446006
destMediaTransportAddress_Port	28480
origCalledPartyNumberPartition	Intercom
callingPartyNumberPartition	Intercom
finalCalledPartyNumberPartition	Intercom
duration	5

•Talk-Back Intercom Example - Phone 20000 presses the intercom button. 20001 invokes Talk-Back and talks to 20000. The configured intercom partition name specifies "Intercom."

Field Names	Original Call CDR
globalCallID_callId	1111000
origLegCallIdentifier	21822469
destLegCallIdentifier	21822470
callingPartyNumber	20000
originalCalledPartyNumber	20001
finalCalledPartyNumber	20001
origCause_Value	16
dest_CauseValue	0
origMediaTransportAddress_IP	-131332086
origMediaTransportAddress_Port	29458
destMediaTransportAddress_IP	-47446006
destMediaTransportAddress_Port	29164
origCalledPartyNumberPartition	Intercom
callingPartyNumberPartition	Intercom
finalCalledPartyNumberPartition	Intercom
duration	5

CDR Field Descriptions

Table 10-4 defines all fields in the current CDRs in the order in which they appear in the CDR.

Table 10-4 CDR Field Descriptions 

Field Name	Range of Values	Description
cdrRecordType	0, 1, 2	This field defines the type of record. The following valid values apply: •0—Start call detail record (not used) •1—End call detail record (CDR) •2—CMR record Default - For CDRs, this field always remains 1.
globalCallID_callManagerId	Positive Integer	This field designates a unique Cisco Unified Communications Manager identity. The Global Call ID comprises two fields: globalCallID_callId globalCallID_callManagerId All records that are associated with a standard call have the same Global Call ID in them. Default -Ensure this field always is populated.
globalCallID_callId	Positive Integer	This field designates a unique call identity value that is assigned to each call. The system allocates this identifier independently on each call server. Values get chosen sequentially when a call begins. A value gets assigned for each call, successful or unsuccessful. When Cisco Unified Communications Manager restarts, this values resets to 1. The Global Call ID consists of two fields: globalCallID_callId globalCallID_callManagerId All records that are associated with a standard call have the same Global Call ID in them. Default - Ensure this field always is populated.
origLegCallIdentifier	Positive Integer	This field identifies the originating leg of a call. Be aware that this value is unique within a cluster. If the leg of a call persists across several sub-calls, and consequently several CDRs (as during a call transfer), this value remains constant. Default - Ensure this field always is populated.
dateTimeOrigination	Integer	This field identifies the date and time when the user goes off hook or the date and time that the H.323 Setup message is received for an incoming call. The time gets stored as UTC. Default - Ensure this field always is populated.
origNodeId	Positive Integer	This field identifies the node within a cluster to which the originator of the call is registered at the time that the call is made. Default - Ensure this field always is populated.
origSpan	0, Positive Integer	For calls that originate at a gateway, this field indicates the B-channel number of the T1, PRI, or BRI trunk where the call originates, or a zero value for FXS or FXO trunks. For H.323 gateways, the span number remains unknown, and this field contains the call leg ID of the originator. For calls that did not originate at a gateway, the value specifies zero. Default - This field gets populated based on these rules.
origIpAddr	Integer	This field identifies the IP address of the device that originated the call signaling. For Cisco Unified IP Phones, this field specifies the address of the phone. For PSTN calls, this field specifies the address of the H.323 gateway. For intercluster calls, this field specifies the address of the remote Cisco Unified Communications Manager. The "IP Addresses" section describes the IP address format. Default - This field gets populated based on these rules.
callingPartyNumber	Text String	This field specifies numeric string of up to 25 characters. For calls that originate at a Cisco Unified IP Phone, this field shows the extension number of the line that is used. For incoming H.323 calls, this field specifies the value that is received in the Calling Party Number field in the Setup message. This field reflects any translations that are applied to the Calling Party Number before it arrives at the Cisco Unified Communications Manager (such as translations at the gateway). For server calls, where Cisco Unified Communications Manager originates a half call without a calling party, this field may remain empty. CallingPartyNumber could contain a SIP URI. Default - This field gets populated based on these rules.
callingPartyUnicodeLoginUserID	Unicode - UTF_8	This field specifies the calling party login user ID. The format of this field specifies UTF_8. Default - Empty string " ". If the user ID does not exist, this field stays empty.
origCause_location	0 to 15	For clearing causes that are received over ISDN signaling links, this field specifies the Location field that is indicated in the ISDN release message. The "Call Termination Cause Codes" section lists the valid values per Q.850. For clearing causes that are created internally by the Cisco Unified Communications Manager, this value specifies zero. Default - 0
origCause_value	0 to 129	For calls that are cleared by the originating party, this field reflects the reason for clearance. Cisco Unified Communications Manager currently uses the Q.850 codes and some Cisco Unified Communications Manager defined codes. The "Call Termination Cause Codes" section lists them. For calls that are cleared by the terminating party, this field specifies zero. In addition to the standard values that are described in Q.850, when a call is split by a feature (transfer/conference), the CDR terminates, and this field gets set to 393216. This represents a proprietary value for this field. Default - 0
origPrecedenceLevel	0 to 4	For MLPP, each call leg includes a precedence level. This field represents the precedence level of the original leg. •Precedence 0 = FLASH OVERRIDE/ EXECUTIVE OVERRIDE •Precedence 1 = FLASH •Precedence 2 = IMMEDIATE •Precedence 3 = PRIORITY •Precedence 4 = ROUTINE Default - 4
origMediaTransportAddress_IP	0, Integer	This field identifies the IP address of the device that originates the media for the call. For Cisco Unified IP Phones, this field specifies the address of the phone. For PSTN calls, this field specifies the address of the H.323 gateway. For intercluster calls, this field specifies the address of the remote phone. The "IP Addresses" section describes the IP address format. Default - 0. If media is not established, this field equals 0.
origMediaTransportAddress_Port	0, Positive Integer	This field identifies the IP port number that is associated with the OrigMediaTransportAddress_IP field. Default - 0. If media is not established, this field stays 0.
origMediaCap_payloadCapability	0, Positive Integer	This field identifies the codec type that the originator uses to transmit media. Cisco Unified Communications Manager currently uses the following payload capability values: 0, 1-16, 18-20, 25, 32, 33, 81-86. The "Codec Types" section lists the valid values. Default - 0. If media is not established, this field stays 0.
origMediaCap_maxFramesPerPacket	0, Positive Integer	This field identifies the number of milliseconds of data per packet that the originating party sends. This field normally gets set to 10, 20, or 30 for G.729 or G.711 codecs, but the field can store any nonzero value. Default - 0. If media is not established, this field stays 0.
origMediaCap_g723BitRate	0	This field is not used in the current release of Cisco Unified Communications Manager. This field will remain 0.
origVideoCap_Codec	0, 100 = H.261, 101 = H.263, 102 = Vieo	This field identifies the codec type that the originator uses to transmit video (H.261, H.263, or Vieo.) Default - 0. If media is not established, this field stays 0.
origVideoCap_Bandwidth	0, Positive Integer	This field identifies the bandwidth that is measured in units of kbps. Default - 0. If media is not established, this field stays 0.
origVideoCap_Resolution	0, 1 = SQCIF, 2 = QCIF, 3 = CIF, 4 = CIF4, 5 = CIF16	This field identifies the video resolution. Default - 0. If media is not established, this field stays 0.
origVideoTransportAddress_IP	0, Integer	This field identifies the IP address of the device that originates the call. Default - 0. If media is not established, this field stays 0.
origVideoTransportAddress_Port	0, Positive Integer	This field identifies the video RTP port that is associated with the origVideoTransportAddress_IP field. Default - 0. If media is not established, this field stays 0.
origRSVPAudioStat	0 to 5	This field gives the status of the RSVP audio reservation from originator to terminator. 0 - No reservation. 1 - RSVP Reservation Failure condition at call setup or feature invocation. 2 - RSVP Reservation Success condition at call setup or feature invocation. 3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation. 4 - RSVP Mid Call Failure Preempted condition (preempted after call setup). 5 - RSVP Mid Call Failure Lost Bandwidth condition (includes all mid-call failures except MLPP preemption). Default - 0
origRSVPVideoStat	0 to 5	This field gives the status of the RSVP video reservation from originator to terminator. 0 - No reservation. 1 - RSVP Reservation Failure condition at call setup or feature invocation. 2 - RSVP Reservation Success condition at call setup or feature invocation. 3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation. 4 - RSVP MID Call Failure Preempted condition (preempted after call setup). 5 - RSVP MID Call Failure Lost Bandwidth condition (includes all mid-call failures except MLPP preemption). Default - 0
destLegCallIdentifier	0, Positive Integer	This field identifies the terminating leg of a call. This value remains unique within a cluster. If the leg of a call persists across several sub-calls and, consequently, several CDRs (as during a call transfer), this value remains constant. Default - 0. If the destination cannot be reached, this field stays 0.
destNodeId	0, Positive Integer	This field identifies the node within a cluster to which the terminating party of the call is registered at the time that the call is made. Default - 0. If the destination cannot be reached, this field stays 0.
destSpan	0, Positive integer	For calls that are received at a gateway, this field indicates the B channel number of the T1, PRI, or BRI trunk where the call is received, or a zero value for FXS or FXO trunks. For H.323 gateways, the span number remains unknown, and this field contains the call leg ID of the destination. For calls not terminating at a gateway, the value specifies zero. Default - 0. If the destination cannot be reached, this field stays 0.
destIpAddr	0, Integer	This field identifies the IP address of the device that terminates the call signaling. For Cisco Unified IP Phones, this field specifies the address of the phone. For PSTN calls, this field specifies the address of the H.323 gateway. For intercluster calls, this field specifies the address of the remote Cisco Unified Communications Manager. The "IP Addresses" section describes the IP address format. Default - 0. If the destination cannot be reached, this field stays 0.
originalCalledPartyNumber	Text String	This field specifies the number to which the original call was presented, prior to any call forwarding. If translation rules are configured, this number reflects the called number after the translations have been applied. This field represents a numeric string of up to 48 characters that can be either digits or a SIP URL. Default - empty string "". If destination cannot be reached, this field stays empty.
finalCalledPartyNumber	Text String	This field specifies the number to which the call finally gets presented, until it is answered or rings out. If no forwarding occurs, 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). This field represents a numeric string of up to 48 characters that can be either digits or a SIP URL. Default - empty string "". If destination cannot be reached, this field stays empty.
finalCalledPartyUnicodeLoginUserID	Unicode - UTF_8	The final called party field specifies the login user ID. The format of this field specifies UTF_8. Default - Empty string " ". If the user ID does not exist, this field stays empty.
destCause_location	0 to 15	For clearing causes that are received over ISDN signaling links, the ISDN release message indicates this location field. The "Call Termination Cause Codes" section lists the valid values per Q.850. For clearing causes that Cisco Unified Communications Manager creates internally, this value equals zero. Default - 0. If the destination cannot be reached, this field stays 0.
destCause_value	0 to 129	For calls that the destination party cleared, this field reflects the reason for the clearance. The "Call Termination Cause Codes" section lists the valid values per Q.850. For calls that the originating party clears, this field stays zero. In addition to the standard values that are described in Q.850, when a call gets split by a feature (transfer/conference), the CDR terminates, and this field gets set to 393216. This represents a proprietary value for this field. Default - 0. If the destination cannot be reached, this field stays 0.
destPrecedenceLevel	0 to 4	For MLPP, each call leg has a precedence level. This field represents the destination legs precedence level. •Precedence 0 = FLASH OVERRIDE •Precedence 1 = FLASH •Precedence 2 = IMMEDIATE •Precedence 3 = PRIORITY •Precedence 4 = ROUTINE Default - 4
destMediaTransportAddress_IP	0, Integer	This field identifies the IP address of the device that terminates the media for the call. For Cisco Unified IP Phones, this field designates the address of the phone. For PSTN calls, this field designates the address of the H.323 gateway. For intercluster calls, this field shows the address of the remote phone. The "IP Addresses" section describes the IP address format. Default - 0. If the destination cannot be reached, this field stays 0.
destMediaTransportAddress_Port	0, Positive Integer	This field identifies the IP port number that is associated with the DestMediaTransportAddress_IP field. Default - 0. If the destination cannot be reached, this field stays 0.
destMediaCap_payloadCapability	0, Positive Integer	This field identifies the codec type that the terminating party uses to transmit media. Cisco Unified Communications Manager currently uses the following payload capability values: 0, 1-16, 18-20, 25, 32, 33, 81-86. The "Codec Types" section lists the valid values. Default - 0. If the destination cannot be reached, this field stays 0.
destMediaCap_maxFramesPerPacket	0, Positive Integer	This field identifies the number of milliseconds of data per packet that the terminating party of the call sends. This field normally gets set to 10, 20, or 30 for G.729 or G.711 codecs but can store any nonzero value. This field can specify zero if the media is never established. Default - 0. If the destination cannot be reached, this field stays 0.
destMediaCap_g723BitRate	0	This field is not used in the current release of Cisco Unified Communications Manager. Default - This field stays 0.
destVideoCap_Codec	0, 100 = H.261, 101 = H.263, 102 = Vieo	This field identifies the codec type that the terminating party uses to transmit video (H.261, H.263, or Vieo). Default - 0. If the destination cannot be reached, this field stays 0.
destVideoCap_Bandwidth	0, Positive Integer	This field identifies the bandwidth, and is measured in units of kbps. Default - 0. If the destination cannot be reached, this field stays 0.
destVideoCap_Resolution	0, 1 = SQCIF, 2 = QCIF, 3 = CIF, 4 = CIF4, 5 = CIF16	This field identifies the video resolution. Default - 0. If the destination cannot be reached, this field stays 0.
destVideoTransportAddress _IP	0, Integer	This field identifies the IP address of the device that receives the call. Default - 0. If the destination cannot be reached, this field stays 0.
destVideoTransportAddress_Port	0, Positive Integer	This field identifies the video RTP port that is associated with the destVideoTransportAddress_IP field. Default - 0. If the destination cannot be reached, this field stays 0.
destRSVPAudioStat	0 - 5	This field designates the status of the RSVP audio reservation from terminator to originator. 0 - No reservation. 1 - RSVP Reservation Failure condition at call setup or feature invocation. 2 - RSVP Reservation Success condition at call setup or feature invocation. 3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation. 4 - RSVP Mid Call Failure Preempted condition (preempted after call setup). 5 - RSVP Mid Call Failure Lost Bandwidth condition (includes all mid call failures except MLPP preemption). Default - 0
destRSVPVideoStat	0 - 5	This field designates the status of the RSVP video reservation from terminator to originator. 0 - No reservation. 1 - RSVP Reservation Failure condition at call setup or feature invocation. 2 - RSVP Reservation Success condition at call setup or feature invocation. 3 - RSVP Reservation No Response (RSVP Agent) condition at call setup or feature invocation. 4 - RSVP Mid Call Failure Preempted condition (preempted after call setup). 5 - RSVP Mid Call Failure Lost Bandwidth condition (includes all mid call failures except MLPP preemption). Default - 0
dateTimeConnect	0, Integer	This field identifies the date and time that the call connects. The time gets stored as UTC. If the call is never answered, this value shows zero. Default - 0. If the call is never connected, this field stays 0.
dateTimeDisconnect	0, Integer	This field identifies the date and time when the call is cleared. This field gets set even if the call never connects. The time gets stored as UTC. Default - 0. If the call is never connected, this field stays 0.
lastRedirectDn	Text String	This field specifies a numeric string of up to 25 characters. The numeric string can contain digits or a SIP URL. For forwarded calls, this field specifies the phone number of the next to last hop before the call reaches its final destination. If only one hop occurs, this number matches the OriginalCalledPartyNumber. For calls that are not forwarded, this field matches the OriginalCalledPartyNumber and the FinalCalledPartyNumber. For calls to a conference bridge, this field contains the actual identifier of the conference bridge, which is an alphanumeric string (for example, b0019901001). Default - empty string "". If the call is never redirected, this field remains empty.
pkid	Text String	This field identifies a text string that the database uses internally to uniquely identify each row. This text string provides no meaning to the call itself. Default - A unique ID should always populate this field.
originalCalledPartyNumberPartition	Text String	This field uniquely identifies the partition name that is associated with the OriginalCalledPartyNumber field because Cisco Unified Communications Manager supports multiple Cisco Unified IP Phones with the same extension number in different partitions. For calls that egress through an H.323 gateway, this field uniquely specifies the partition name that is associated with the route pattern that points to the gateway. Default - empty string "". If the original called party does not have a partition, this field remains empty.
callingPartyNumberPartition	Text String	This field uniquely identifies the partition name that is associated with the CallingPartyNumber field because Cisco Unified Communications Manager supports multiple Cisco Unified IP Phones with the same extension number in different partitions. For calls that ingress through an H.323 gateway, this field remains blank. Default - empty string "". If the original called party does not have a partition, this field remains empty.
finalCalledPartyNumberPartition	Text String	This field uniquely identifies the partition name that is associated with the FinalCalledPartyNumber field because Cisco Unified Communications Manager supports multiple Cisco Unified IP Phones with the same extension number in different partitions. For calls that egress through an H.323 gateway, this field uniquely specifies the partition name that is associated with the route pattern that points to the gateway. Default - empty string "". If the final called party does not have a partition, this field remains empty.
lastRedirectDnPartition	Text String	This field uniquely identifies the partition name that is associated with the LastRedirectDn field because Cisco Unified Communications Manager supports multiple Cisco Unified IP Phones with the same extension number in different partitions. For calls that egress through an H.323 gateway, this field specifies the partition name that is associated with the route pattern that points to the gateway. Default - empty string "". If the last redirecting Party does not have a partition or the call was never redirected, this field stays empty.
duration	0, Positive integer	This field identifies the difference between the Connect Time and Disconnect Time. This field specifies the time that the call remains connected, in seconds. This field remains zero if the call never connects or if it connects for less than 1 second. Default - 0
origDeviceName	Text String	This field specifies the text string that identifies the name of the originating device. Default - Ensure this field always is populated.
destDeviceName	Text String	This field specifies the text string that identifies the name of the destination device. Default - empty string "". If the original device does not have a name, this field stays empty.
origCallTerminationOnBehalfOf	0, Positive Integer	This field 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 terminates because of a transfer, the OnBehalfOf code shows "10" for Transfer. See the "OnBehalfof Codes" section for a list of the codes. This release added new OnBehalfOf codes. Default - 0
destCallTerminationOnBehalfOf	0, Positive Integer	This field 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 terminates because of a transfer, the OnBehalfOf code shows "10" for Transfer. See the "OnBehalfof Codes" section for a list of the codes. This release added new OnBehalfOf codes. Default - 0
origCalledPartyRedirectOnBehalfOf	0, Positive Integer	This field specifies code that identifies the reason for redirection of the original called party. For example, if the original called party was redirected because of a conference, the OnBehalfOf code specifies "4." See the "OnBehalfof Codes" section for a list of the codes. This release added new OnBehalfOf codes. Default - 0
lastRedirectRedirectOnBehalfOf	0, Integer	This field specifies code that identifies the reason for redirection of the last redirected party. For example, if the last redirected party was redirected on behalf of a conference, the OnBehalfOf code specifies "4." See the "OnBehalfof Codes" section for a list of the codes. This release added new OnBehalfOf codes. Default - 0
origCalledPartyRedirectReason	0, Integer	This field identifies the reason for a redirect of the original called party. See the "Redirect Reason Codes" section for a complete list of the codes. Default - 0
lastRedirectRedirectReason	0, Integer	This field identifies the last redirect reason for redirection. See the "Redirect Reason Codes" section for a complete list of the codes. Default: 0
destConversationID	0, Integer	This field specifies a unique identifier that is used to identify the parties of a conference call. For conference chaining scenarios, the origConversationID and destConversationID fields identify which conferences are chained together. Default: 0
globalCallId_ClusterId	Text String	This field specifies a unique ID that identifies a cluster of Cisco Unified Communications Managers. The field is generated at installation and is not used by Cisco Unified Communications Manager. The fields globalCallId_ClusterId + globalCallId_CMId + globalCallId_CallId make up this unique key. Default: This field should always be populated.
joinOnBehalfOf	0, Integer	This field specifies code that identifies the reason for a join. For example, if the join takes place on behalf of a transfer, the OnBehalfOf code specifies "10." See the "OnBehalfof Codes" section for a list of the codes. Default: 0
Comment	Text String	This field allows features to add text to the CDRs. This text can describe details about the call. For example, the following field flags malicious calls: Tag—CallFlag Value—MALICIOUS Default: Empty string "".
authCodeDescription	Text String	This field provides a description of the FAC. Default: Empty string "" or null.
authorizationLevel	0, Integer	This field displays the level of the FAC. Default: 0
clientMatterCode	Text String	Before the system extends a call, the user enters a client matter code that can be used for assigning account or billing codes to calls. This field displays the client matter code. Default: Empty string "" or null.
origDTMFMethod	0, Positive Integer	This field displays the DTMF method that the originator uses. 0 - No DTMF - Use ANY matched DTMF. 1 - OOB - Use OOB if endpoints behind SIPTrunk support it. 2 - 2833 - Use RFC2833 if endpoints behind SIPTrunk support it. 3 - OOB and 2833 - Use both KPML and RFC2833 if endpoints behind SIPTrunk can support both. 4 - Unknown Default: 0 (No preference)
destDTMFMethod	0, Positive Integer	This field displays the DTMF method that the destination uses. 0 - No DTMF - Use ANY matched DTMF. 1 - OOB - Use OOB if endpoints behind SIPTrunk support it. 2 - 2833 - Use RFC2833 if endpoints behind SIPTrunk support it. 3 - OOB and 2833 - Use both KPML and RFC2833 if endpoints behind SIPTrunk can support both. 4 - Unknown. Default: 0 (No preference)
callSecuredStatus	0, Positive Integer	This field displays the highest security status that is reached during a call. For example, if the call is originally unsecured, then later the call changes to secured, the CDR contains 1 for "Secured" even though different portions of the call have different status values. 0 - Non-secured 1 - Authenticated (not encrypted) 2 - Secured (encrypted) Default: 0 (Non-secured)
origConversationID	Integer	This field identifies the conference ID that is associated with the originating leg of the call. In most cases, this field equals 0. For conference chaining scenarios, the origConversationID and destConversationID fields identify which conferences are chained together. Default: 0
origMediaCap_Bandwidth	0, Positive Integer	This field displays the media bandwidth that is used at the origination of the call. Default: 0
destMediaCap_Bandwidth	0, Positive Integer	This field displays the media bandwidth that is used at the destination of the call. Default: 0
authorizationCodeValue	Text String	This field displays the Forced Authorization Code (FAC) that is associated with the call. Default: Empty string "" or null.

CMR Field Descriptions (Diagnostic)

Table 10-5 contains the fields, range of values, and field descriptions of the CMRs in the order in which they appear in the CMR.

Table 10-5 CMR Field Descriptions 

Field Name	Range of Values	Description
cdrRecordType	0, 1, or 2	This field 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 Default - For CMRs, this field always specifies 2.
globalCallID_callManagerId	Positive Integer	This field specifies a unique Cisco Unified Communications Manager 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 that are associated with a standard call have the same Global Call ID in them. Default - Ensure this field always is populated.
globalCallId_callId	Positive Integer	This field specifies a unique call identity value that gets assigned to each call. The system allocates this identifier independently on each call server. Values get chosen sequentially when a call begins. Each call, successful or unsuccessful, receives value assignment. This field makes up half the Global Call ID. The Global Call ID comprises the following two fields: •globalCallId_callId •globalCallID_callManagerID All records that are associated with a standard call have the same Global Call ID in them. Default - Ensure this field always is populated.
nodeId	Positive Integer	This field specifies the node within the Cisco Unified Communications Manager cluster where this record gets generated. Default - Ensure this field always is populated.
callIdentifier	Positive Integer	This field identifies the call leg to which this record pertains. Default - Ensure this field always is populated.
directoryNumber	Integer	This field specifies the directory number of the device from which these diagnostics are collected. Default - Ensure this field always is populated.
dateTimeStamp	Integer	This field represents the approximate time that the device goes on hook. Cisco Unified Communications Manager records the time when the phone responds to a request for diagnostic information. Default - Ensure this field always is populated.
numberPacketsSent	Integer	This field designates the total number of Routing Table Protocol (RTP) data packets that the device transmits before starting transmission on this connection. The value remains zero if the connection is set to "receive only" mode. Default - 0
numberOctetsSent	Integer	This field specifies the total number of payload octets (that is, not including header or padding) that the device transmits in RTP data packets since starting transmission on this connection. The value remains zero if the connection is set to "receive only" mode. Default - 0
numberPacketsReceived	Integer	This field specifies the total number of RTP data packets that the device has received since starting reception on this connection. The count includes packets that are received from different sources if this is a multicast call. The value remains zero if the connection is set in "send only" mode. Default - 0
numberOctetsReceived	Integer	This field specifies the total number of payload octets (that is, not including header or padding) that the device has received in RTP data packets since starting reception on this connection. The count includes packets that are received from different sources if this is a multicast call. The value remains zero if the connection is set in "send only" mode. Default - 0
numberPacketsLost	Integer	This field designates the total number of RTP data packets that have been lost since the beginning of reception. This number designates the number of packets that were expected, less the number of packets that were actually received, where the number of packets that were 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 duplicate packets exist. The number of packets that are expected designates the extended last sequence number that was received, as defined next, less the initial sequence number that was received. The value remains zero if the connection was set in "send only" mode. For detailed information, see RFC 1889. Default - 0
jitter	Integer	This field 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. Default - 0
latency	Integer	This field 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 that the RTP Control Protocol (RTCP) messages indicates and the NTP timestamp of the receivers, measured when these messages are received. Cisco Unified Communications Manager obtains the average by summing all estimates then dividing by the number of RTCP messages that have been received. For detailed information, see RFC 1889. Default - 0
pkid	Text String	This field identifies a text string that the database uses internally to uniquely identify each row. This text string provides no meaning to the call itself. Default - The system always populates this field with a unique ID.
directoryNumberPartition	Text String	This field identifies the partition of the directory number. Default - Empty string, "". This field may remain empty if no partition exists.
deviceName	Text String	This field identifies the name of the device. Default - Empty string "". This field may remain empty if there is no device name.
globalCallId_ClusterId	Text String	This field designates a unique ID that identifies a cluster of Cisco Unified Communications Managers. The system generates this field during installation, but Cisco Unified Communications Manager does not use it: globalCallId_ClusterId + globalCallId_callManagerId + globalCallId_callId. Default - Ensure this field always is populated.
varVQMetrics	Text String	This field contains a variable number of voice quality metrics. This field comprises a string of voice quality metrics that are separated by a semicolon. The format of the string follows: fieldName=value;fieldName=value.precision This example shows voice quality data, but the names may differ. "MLQK=4.5000;MLQKav=4.5000;MLQKmn=4.5000;MLQKmx=4.5000;MLQKvr=0.95;CCR=0.0000;ICR=0.0000;ICRmx=0.0000;CS=0;SCS=0" Note See Table 10-6 "K-Factor Data Stored in Cisco Unified Communications Manager CMRs" for a complete list of K-Factor data.

K-Factor Data in CMRs

K-factor represents an endpoint mean opinion score (MOS) estimation algorithm that is defined in ITU standard P.VTQ. It represents a general estimator that is used to estimate the mean value of a perceptual evaluation of speech quality (PESQ) population for a specific impairment pattern.

MOS relates to the output of a well designed listening experiment. All MOS experiments use a five point PESQ scale as defined in ITU standard P.862.1, which describes the PESQ as an objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs.

The MOS estimate provides a number that is inversely proportional to frame loss density. Clarity decreases as more frames are lost or discarded at the receiving end. Consider the loss or discarding of these frames as concealment. Concealment statistics measure packet (frame) loss and its effect on voice quality in an impaired network.

K-factor represents a weighted estimate of average user annoyance due to distortions that are caused by effective packet loss such as dropouts and warbles. It does not estimate the impact of delay-related impairments such as echo. It provides an estimate of listening quality (MOS-LQO) rather than conversational quality (MOS-CQO), and measurements of average user annoyance range from 1 (poor voice quality) to 5 (very good voice quality).

K-factor gets trained or conditioned by speech samples from numerous speech databases, where each training sentence or network condition that is associated with a P.862.1 value has a duration of 8 seconds. For more accurate scores, the system generates k-factor estimates for every 8 seconds of active speech.

Consider K-factor and other MOS estimators to be secondary or derived statistics because they warn a network operator of frame loss only after the problem becomes significant. Packet counts, concealment ratios, and concealment second counters represent primary statistics because they alert the network operator before network impairment has an audible impact or is visible through MOS.

Table 10-6 displays the K-factor date that is stored in the Cisco Unified Communications Manager CMRs.

Table 10-6 K-Factor Data Stored in Cisco Unified Communications Manager CMRs 

Field Name	Phone Display Name	D&I User Interface Text and Description
CCR	Cum Conceal Ratio	Cumulative Conceal Ratio represents the cumulative ratio of concealment time over speech time that is observed after starting a call.
ICR	Interval Conceal Ratio	Interval Conceal Ratio represents an interval-based average concealment rate that is the ratio of concealment time over speech time for the last 3 seconds of active speech.
ICRmx	Max Conceal Ratio	Interval Conceal Ratio Max represents the maximum concealment ratio that is observed during the call.
CS	Conceal Secs	Conceal Secs represents the duration of time during which some concealment is observed during a call.
SCS	Severely Conceal Secs	Severely Conceal Secs represents the time during which a significant amount of concealment is observed. If the concealment that is observed is usually greater than 50 milliseconds or approximately 5 percent, the speech probably does not seem very audible.
MLQK	MOS LQK	MOS Listening Quality K-factor provides an estimate of the MOS score of the last 8 seconds of speech on the reception signal path.
MLQKmn	Min MOS LQK	MOS Listening Quality K-factor Min represents the minimum score that is observed since the beginning of a call and represents the worst sounding 8 second interval.
MLQKmx	Max MOS LQK	MOS Listening Quality K-factor Max represents the maximum score that is observed since the beginning of a call and represents the best sounding 8 second interval.
MLQKav	Avg MOS LQK	MOS Listening Quality K-factor Avg8 represents the running average of scores that are observed since the beginning of a call.

Codec Types

Table 10-7 contains the compression and payload types that may appear in the codec fields.

Table 10-7 Codec Types 

Value	Description
1	NonStandard
2	G711Alaw 64k
3	G711Alaw 56k
4	G711mu-law 64k
5	G711mu-law 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
40	G7221 32K
41	G7221 24K
42	AAC
80	GSM
81	ActiveVoice
82	G726_32K
83	G726_24K
84	G726_16K
86	iLBC
100	H261
101	H263
102	Vieo
103	H264
106	H224

Call Termination Cause Codes

The following tables contain call termination cause codes that may appear in the Cause fields in CDRs.

•"Call Termination Cause Codes"

•"Cisco-Specific Call Termination Cause Codes"

Table 10-8 Call Termination Cause Codes 

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	Non-selected 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	Meet-Me secure conference minimum security level not met
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 is 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 (Closed User Group)
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 timer expired; 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
122	Precedence Level Exceeded
123	Device not Preemptable
125	Out of bandwidth (Cisco specific)
126	Call split (Cisco specific)
127	Interworking, unspecified
129	Precedence out of bandwidth

Table 10-9 Cisco-Specific Call Termination Cause Codes 

Code	Description
262144	Conference Full (was 124)
393216	Call split (was 126) This 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 can help determine which calls terminated as part of a feature operation.
458752	Drop any party/drop last party     (was 128)
16777257	CCM_SIP_400_BAD_REQUEST
33554453	CCM_SIP_401_UNAUTHORIZED
50331669	CCM_SIP_402_PAYMENT_REQUIRED
67108885	CCM_SIP_403_FORBIDDEN
83886081	CCM_SIP_404_NOT_FOUND
100663359	CCM_SIP_405_METHOD_NOT_ALLOWED
117440591	CCM_SIP_406_NOT_ACCEPTABLE
134217749	CCM_SIP_407_PROXY_AUTHENTICATION_REQUIRED
150995046	CCM_SIP_408_REQUEST_TIMEOUT
184549398	CCM_SIP__410_GONE
201326719	CCM_SIP_411_LENGTH_REQUIRED
234881151	CCM_SIP_413_REQUEST_ENTITY_TOO_LONG
251658367	CCM_SIP_414_REQUEST_URI_TOO_LONG
268435535	CCM_SIP_415_UNSUPPORTED_MEDIA_TYPE
285212799	CCM_SIP_416_UNSUPPORTED_URI_SCHEME
83886207	CCM_SIP_420_BAD_EXTENSION
369098879	CCM_SIP_421_EXTENSION_REQUIRED
402653311	CCM_SIP_423_INTERVAL_TOO_BRIEF
1073741842	CCM_SIP_480_TEMPORARILY_UNAVAILABLE
1090519081	CCM_SIP_481_CALL_LEG_DOES_NOT_EXIST
1107296281	CCM_SIP_482_LOOP_DETECTED = 0x42000000 + EXCHANGE_ROUTING_ERROR
1124073497	CCM_SIP_483_TOO_MANY_HOOPS
1140850716	CCM_SIP_484_ADDRESS_INCOMPLETE
1157627905	CCM_SIP_485_AMBIGUOUS
1174405137	CCM_SIP_486_BUSY_HERE
1191182367	CCM_SIP_487_REQUEST_TERMINATED
1207959583	CCM_SIP_488_NOT_ACCEPTABLE_HERE
1258291217	CCM_SIP_491_REQUEST_PENDING
1291845649	CCM_SIP_493_UNDECIPHERABLE
1409286185	CCM_SIP_500_SERVER_INTERNAL_ERROR
1442840614	CCM_SIP_502_BAD_GATEWAY
1459617833	CCM_SIP_503_SERVICE_UNAVAILABLE
1476395110	CCM_SIP__504_SERVER_TIME_OUT
1493172351	CCM_SIP_505_SIP_VERSION_NOT_SUPPORTED
1509949567	CCM_SIP_513_MESSAGE_TOO_LARGE
2701131793	CCM_SIP_600_BUSY_EVERYWHERE
2717909013	CCM_SIP_603_DECLINE
2734686209	CCM_SIP_604_DOES_NOT_EXIST_ANYWHERE
2751463455	CCM_SIP_606_NOT_ACCEPTABLE

Redirect Reason Codes

Table 10-10 contains the available Redirect Reason Codes that may appear in a record.

Table 10-10 Redirect Reason Codes 

Q.931 Standard Redirect Reason Codes
Value	Description
0	Unknown
1	Call Forward Busy
2	Call Forward No Answer
4	Call Transfer
5	Call Pickup
7	Call Park
8	Call Park Pickup
9	CPE Out of Order
10	Call Forward
11	Call Park Reversion
15	Call Forward All
Nonstandard Redirect Reason Codes
18	Call Deflection
34	Blind Transfer
50	Call Immediate Divert
66	Call Forward Alternate Party
82	Call Forward On Failure
98	Conference
114	Barge
129	Aar
130	Refer
146	Replaces
162	Redirection (3xx)
177	SIP-forward busy greeting
207	Follow Me (SIP-forward all greeting)
209	Out of Service (SIP-forward busy greeting)
239	Time Of Day (SIP-forward all greeting)
242	Do Not Disturb (SIP-forward no answer greeting)
257	Unavailable (SIP-forward busy greeting)
274	Away (SIP-forward no answer greeting)
303	Mobility HandIn
319	Mobility HandOut
335	Mobility Cell Pickup
354	Recording
370	Monitoring
399	Mobility IVR

OnBehalfof Codes

Table 10-11 contains the available OnBehalfof Codes that may appear in a CDR record.

Table 10-11 OnBehalfof Codes 

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
14	Immediate Divert
15	Barge
16	Pickup
17	Refer
18	Replaces
19	Redirection
20	Callback
21	Path Replacement
22	FacCmc Manager
23	Malicious Call
24	Mobility
25	Aar
26	Directed Call Park
27	Recording
28	Monitoring

Related Topics

•CDR Analysis and Reporting Overview, page 1-1

•Getting Started with CDR Analysis and Reporting, page 2-1

•CAR System Configuration, page 3-1

•CAR Report Configuration, page 4-1

•CAR User Reports Configuration, page 5-1

•CAR System Reports Configuration, page 6-1

•CAR Device Reports Configuration, page 7-1

•CDR Search Configuration, page 8-1

•Export CDR/CMR Records Configuration, page 9-1

•CAR Report Results, page 11-1

Related Documentation

The following documents contain additional information related to CDRs:

•Cisco Unified Serviceability Administration Guide

•Cisco Communications Manager System Guide