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	1		1	1	0
duration	60	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 (co