Table Of Contents
Cisco Unified CallManager Call Detail Record Definitions, Release 5.1(3)
Contents
New and Changed Information
Configuring Cisco Unified CallManager CDR
Configuring CDR Service Parameters
Configuring CDR Enterprise Parameters
CDR Processing
Cisco Unified CallManager CDR Overview
CDR Management
CDR Agent
CDR Repository Manager
CDR onDemand Service
Types of Call Information Records
Global Call Identifier
Number Translations
Partitions and Numbers
Timestamps
Call 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
Two types of conference linking exist:
Precedence Calls (MLPP)
Malicious Calls
Conference Drop Any Party
Immediate Divert (to Voice Messaging System)
Video Calls
Original Calling Party on Transfer
Interpreting Cisco Personal Assistant Data in the CDRs
Personal Assistant Call Types
Personal Assistant Direct Call
Personal Assistant Interceptor Going to Media Port and Transferring the Call
Personal Assistant Interceptor Going Directly to Destination
Personal Assistant 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)
Examples of Successful Calls
Abandoned Calls
Examples of Abandoned Calls
Calls With Busy or Bad Destinations (Unsuccessful Calls)
Examples of Unsuccessful Calls
Forwarded Calls
Forwarding Examples
Call Pickup
Auto Pickup
Auto Pickup Example
Legacy Call Pickup
Transferred Calls
Transfer Examples
Conference Calls
Conference Example
Call Park
Call Park Pickup
Call Park Example
Call Park Reversion
Call Park Reversion Example
Precedence Calls (MLPP)
Precedence Call Examples
Malicious Calls
Malicious Call Example
Immediate Divert (to Voice-messaging System)
IDivert Examples
Barge
Barge Examples
cBarge
cBarge Examples
Video Calls
Forced Authorization Code (FAC)
FAC Example
Client Matter Code (CMC)
CMC Example
Call Secured Status
Examples
DTMF Method
DTMF Call Examples
RSVP
RSVP Call Examples
Redirection (3xx) Calls
Redirection (3xx) Examples
Replaces Calls
Refer Calls
CDR Field Descriptions
CMR Field Descriptions (Diagnostic)
K-Factor Data in CMRs
Codec Types
Call Termination Cause Codes
Redirect Reason Codes
OnBehalfof Codes
Related Documentation
Obtaining Documentation, Obtaining Support, and Security Guidelines
Cisco Unified CallManager Call Detail Record Definitions, Release 5.1(3)
This document describes the format and logic of the call detail records (CDRs) and call management records (CMRs) that the Cisco Unified CallManager Release 5.0 (and later) system generates. You can use this information for post-processing activities such as generating billing records and network analysis. This document describes how to access the CDR/CMR files 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 CallManager for the change to take effect. The system responds to all changes within a few seconds. The system enables CMRs (diagnostic data) separately from CDR data.
Contents
This document covers the following topics:
•
New and Changed Information
•Configuring Cisco Unified CallManager CDR
•CDR Processing
•Cisco Unified CallManager 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
•Related Documentation
•Obtaining Documentation, Obtaining Support, and Security Guidelines
New and Changed Information
The Release Notes for the corresponding release of Cisco Unified CallManager describe new features or changes for CDRs/CMRs that are pertinent to a specified release.
Configuring Cisco Unified CallManager CDR
CDR Analysis and Reporting (CAR) comprises a group of complementary services, which you can activate in the Service Activation window in Cisco Unified CallManager Serviceability. Before you can launch CAR from the Tools menu in Cisco Unified CallManager Serviceability, you must activate the CAR services by using the following procedure.
Procedure
Step 1 Choose Tools > Service Activation.
The Service Activation window displays.
Step 2 From the Servers drop-down list box, choose the first node of the cluster.
The window displays the service names for the server that you chose, the service type, and the activation status of the services.
Note Activate the CAR services on only the first node, where the Cisco Unified CallManager database resides.
Step 3 Check the check boxes next to the following CDR services:
•Cisco CAR Web Service
•Cisco SOAP-CDROnDemand (optional). If you are using a third-party billing application that accesses CDR data via an HTTPS/SOAP interface, activate this service.
Tip Unchecking the check boxes next to the CDR services and clicking Update deactivates the services. If you deactivate the Cisco CAR Web Service, the system removes CAR from the Tools menu on the Cisco Unified CallManager Serviceability menu.
Step 4 After you have finished making the appropriate changes, click Update.
You must also configure certain CDR service and enterprise parameters:
•Configuring CDR Service Parameters
•Configuring CDR Enterprise Parameters
Additional Information
See the "Getting Started With CDR Reporting And Analysis" chapter in the Cisco Unified CallManager CDR Reporting and Analysis Reporting Tool Administration Guide for additional information.
Configuring CDR Service Parameters
CAR relies on the data in the CDR and CMR records to generate both CAR and CDR reports. CAR requires that the CDR records be available in flat files on the CDR Repository node (the first node). Even if you do not use the CAR and CDR reporting services, you must enable certain Cisco Unified CallManager service parameters to ensure that CDR records are generated, and are generated in the manner that you can use for your particular system.
You can configure these parameters in the Service Parameters Configuration window in Cisco Unified CallManager Administration. To access the Service Parameters Configuration window, open Cisco Unified CallManager Administration and choose System > Service Parameters. Choose the Advanced button to display the complete list of Service Parameters. The following list of service parameters can affect CDR/CMR records:
•System Parameters
–CDR Enabled Flag—This parameter determines whether CDRs are generated. Valid values specify True (CDRs are generated) or False (CDRs are not generated). For this required field, the default value specifies False. Enable this parameter on all servers in the cluster.
–CDR Log Calls With Zero Duration Flag—This parameter enables or disables the logging of CDRs for calls that were never connected or that lasted less than 1 second. Cisco Unified CallManager logs unsuccessful calls (calls that result in reorder, such as might occur because of a forwarding directive failure or calls that attempt to go through a busy trunk) regardless of this flag setting. This parameter represents a required field. The default value specifies False.
•Clusterwide Parameters (Device - General)
–Call Diagnostics Enabled—This parameter determines whether the system generates call management records (CMRs), also called diagnostic records. Valid values specify Disabled (do not generate CMRs), Enabled Only When CDR Enabled Flag is True (generate CMRs only when the CDR Enabled Flag service parameter is set to True), or Enabled Regardless of CDR Enabled Flag (generates CMRs without regard to the setting in the CDR Enabled Flag service parameter). This represents a required field. The default value specifies Disabled.
–Display FAC in CDR—This parameter determines whether the Forced Authorization Code (FAC) that is associated with the call displays in the CDR. Valid values specify True (display authorization code in CDRs) or False (do not display authorization code in CDRs) for this required field. The default value specifies False.
–Show Line Group Member DN in finalCalledPartyNumber CDR Fields—This parameter determines whether the finalCalledPartyNumber field in CDRs shows the directory number (DN) of the line group member who answered the call or the hunt pilot DN. Valid values specify True (the finalCalledPartyNumber in CDRs will show the DN of the phone that answered the call) or False (the finalCalledPartyNumber in CDRs will show the hunt pilot DN). This parameter applies only to basic calls that are routed through a hunt list without feature interaction such as transfer, conference, call park, and so on. If a feature is involved in the call, the hunt pilot DN will show in the finalCalledPartyNumber field regardless of the setting in this parameter. This parameter does not apply to Cisco Unified CallManager Attendant Console. The default value for this required field specifies False.
•Clusterwide Parameters (Device - Phone)
–Add Incoming Number Prefix to CDR —This parameter determines whether Cisco Unified CallManager adds the incoming prefix (as specified in the National Number Prefix, International Number Prefix, Subscriber Number Prefix, and Unknown Number Prefix service parameters) to the calling party number in the CDRs for that call. If the destination of the call is a gateway, Cisco Unified CallManager will not add the prefix to the CDRs even if this parameter is enabled. The default value for this required field specifies False.
Configuring CDR Enterprise Parameters
Configure these CDR parameters on the Enterprise Parameters Configuration window in the Cisco Unified CallManager Administration. To access Enterprise Parameters Configuration windows, open Cisco Unified CallManager Administration and choose System -> Enterprise Parameters.
•CDR Parameters
–CDR File Time Interval—This parameter specifies the time interval for collecting CDR data. For example, if this value is set to 1, each file will contain 1 minute of CDR data (CDRs and CMRs, if enabled). The external billing server and CAR database will not receive the data in each file until the interval expires (or sometime later, depending on the CAR Loader schedule setting). Consider how quickly you want access to the CDR data when you decide what interval to set for this parameter. Setting this parameter to 60 means that each file will contain 60 minutes worth of data, but that data will not be available until the 60-minute period has elapsed, and the records are written to the CAR database. The system sends CDR files to the configured billing server(s). The default value specifies 1. The minimum value specifies 1, and the maximum value specifies 1440. The unit of measure for this required field represents a minute.
–Cluster ID—This parameter provides a unique identifier for the cluster. Because the parameter gets used in CDRs, collections of CDRs from multiple clusters can be traced to the sources. The default value specifies StandAloneCluster. The maximum length comprises 50 characters and provides a valid cluster ID that comprises any of the following characters: A-Z, a-z, 0-9, . -.
•CCM Web Services Parameters
–Allowed CDRonDemand get_file Queries Per Minute—This parameter specifies the maximum number of CDRonDemand get_file queries that are allowed per minute for the system. For this required field, the default value specifies 10. The minimum value equals 1, and the maximum value equals 20.
–Allowed CDRonDemand get_file_list Queries Per Minute—This parameter specifies the maximum number of CDRonDemand get_file_list queries that are allowed per minute for the system. For this required field, the default value specifies 20. The minimum value equals 1, and the maximum value equals 40.
CDR Processing
Cisco Unified CallManager 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 CallManager 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 CallManager, 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 CallManager 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 server where the Cisco Unified CallManager database exists
•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.
Cisco Unified CallManager CDR Overview
The following sections provide a brief description of how CDRs are generated and managed in Cisco Unified CallManager:
•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 individual nodes within a cluster 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 have been 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 CallManager cluster acts as the CDR Agent. On a node where both Cisco Unified CallManager and the CDR Agent are running, Cisco Unified CallManager writes the CDRs into CDR flat files (CSV format) with a special control character ("_") 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 CallManager nodes within a cluster continuously write CDRs to flat files, close existing flat files, and open new ones. The number of records that are written varies by the type of call and significant changes that occur during a call, such as ending the call, transferring the call, redirecting the call, splitting the call, or joining the call.
The CDR Agent periodically polls the files in a designated path (/var/log/active/cm/cdr, which is a softlink to /common/log/cdr), every 6 seconds to determine whether a CDR file is available for transfer to the CDR Repository node. Having a short interval provides an advantage because as soon as a file is available, the system can deliver it immediately to the CDR Repository node.
The CDR Agent uses a standard SFTP utility, sftp_connect.sh, to transfer CDR files from the Cisco Unified CallManager nodes to the CDR Repository node. The utility requires a batch file as input and generates a log file that indicates the results of the requested actions. The CDR Agent creates unique batch and log files for each transfer session.
In case of an SFTP failure, the component on Cisco Unified CallManager repeatedly tries to make new connections until successful. When CDR files are accumulated due to a lack of an SFTP connection, the system sends all leftover CDR files to the CDR Repository node immediately after connectivity is restored.
When the CDR Agent starts or restarts, it checks whether any CDR files remain from the previous life cycle and sends them over to the CDR Repository node.
Should SFTP fail to transfer CDR files to the CDR Repository node, the system raises an alarm.
CDR Repository Manager
Within a Cisco Unified CallManager cluster, one instance of the CDR Repository Manager runs on the CDR Repository node. It manages CDR files that are received from the Cisco Unified CallManager nodes and periodically sends the files to the specified customer/third-party billing servers via an (s)FTP connection.
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 indicated by the UTC timestamp placed in the file name when the file was created.
If any external billing server is specified in CDRM configuration, the system creates a soft link to the file that is created 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, either SFTP or FTP. If the delivery is successful, the system removes the soft link in the destination directory.
Every Cisco Unified CallManager 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 on how to configure the CDR Repository Manager and customer billing servers, see the "CDR Repository Manager Configuration" chapter in the Cisco Unified Serviceability Administration Guide.
CDR onDemand Service
The CDR onDemand Service, a SOAP/HTTPS-based service, 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 CallManager Developers Guide for Release 5.1(3).
Types of Call Information Records
Cisco Unified CallManager generates two different types of call information records: Call Detail Records (CDRs) and Call Management Records (CMRs). CDRs store information about the endpoints of the call and other call control/routing aspects. CMRs contain diagnostic information about the quality of the streamed audio and/or video of the call. More than one CMR can exist per CDR.
The CDRs relate to the CMRs via the two globalCallID columns:
•globalCallID_callManagerId
•globalCallId_callId
When the Call Diagnostics Enabled service parameter is set to True, the system generates up to two CMRs for each call. Each type of call, such as conference calls, call transfers, forwarded calls, and calls through gateways, produce a set of records that get written to ASCII files at the end of the call. Only completed calls and failed calls generate CDRs and CMRs. Cisco Unified CallManager does not perform any post processing on CDRs or CMRs.
This section contains the following topics:
•Global Call Identifier
•Number Translations
•Partitions and Numbers
•Timestamps
•Call Termination Cause Codes
Global Call Identifier
Cisco Unified CallManager allocates a global call identifier (GlobalCallID) each time that a Cisco Unified IP Phone is taken off hook or a call is received from a gateway.
The CDR table (Table 1) lists CDRs that are written at the end of a call in the order that they are written. GlobalCallIDs for active calls do not appear in the CDR table. Other global IDs also may not appear in the CDR table. For example, each call leg in a conference call gets assigned a GlobalCallID that the conference GlobalCallID overwrites. The original GlobalCallID does not appear in the CDR.
Table 1 Sample CDR Table
GlobalCallID
|
Start Time
|
End Time
|
1
|
973795815
|
973795820
|
2
|
973795840
|
973795845
|
5
|
973795860
|
973795870
|
4
|
973795850
|
973795880
|
The CDR table does not contain an entry for GlobalCallID 3 because that call was active when this record was taken. The table shows GlobalCallID 5 listed before GlobalCallId 4 because the GlobalCallID 5 call ended before the GlobalCallID 4 call ended.
Number Translations
The Cisco Unified CallManager can perform translations on the digits that a user dials. The translated number, not the actual dialed digits, appears in the CDR.
For example, many companies translate "911" calls to "9-911," so the caller does not need to dial an outside line in an emergency. In these cases, the CDR contains "9911" even though the user dials "911."
Note Gateways can perform further modifications to the number before the digits are actually output through the gateway. The CDR does not reflect these modifications.
Partitions and Numbers
Within a CDR, a combination of extension number and partition identifies each phone that is referenced, if partitions are defined. When partitions exist, fully identifying a phone requires both values because extension numbers may not be unique.
The Partition field stays empty when a call ingresses through a gateway. When a call egresses through a gateway, the Partition field shows the partition to which the gateway belongs.
If the dial plan allows callers to use the # key for speed dialing, the # key goes into the database when it is used. For example, the Called Party Number field may contain a value such as "902087569174#."
In this release, the Party Number fields may include SIP URIs instead of the traditional calling/called party number.
CDRs use the Partition/Extension Numbers that are shown in Table 2:
Table 2 Partition/Extension Numbers in CDRs
Phone Number
|
Description
|
callingPartyNumber
|
This party placed the call. For transferred calls, the transferred party becomes the calling party.
|
originalCalledPartyNumber
|
This number designates the originally called party, after any digit translations have occurred.
|
finalCalledPartyNumber
|
For forwarded calls, this number designates the last party to receive the call.
For non-forwarded calls, this field shows the original called party.
|
lastRedirectDn
|
For forwarded calls, this field designates the last party to redirect the call.
For non-forwarded calls, this field shows the last party to redirect (such as transfer and conference) the call.
|
callingPartyNumberPartition
|
This number identifies the partition name that is associated with the CallingPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that ingress through a gateway, this field remains blank.
|
originalCalledPartyNumberPartition
|
This number identifies the partition name that is associated with the OriginalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
|
finalCalledPartyNumberPartition
|
This number identifies the partition name that is associated with the FinalCalledPartyNumber field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
|
lastRedirectDnPartition
|
This number identifies the partition name that is associated with the LastRedirectDn field. This field uniquely identifies this number because the Cisco Unified CallManager supports multiple Cisco Unified IP Phones with the same extension number in different partitions.
For calls that egress through a gateway, this field specifies the partition name that is associated with the route pattern that pointed to the gateway.
|
Timestamps
Timestamps within a CDR appear in Universal Coordinated Time (UTC). 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 3:
Table 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.
The "Call Termination Cause Codes" section lists the call termination cause code values per ITU specification Q.850. For On Net call legs, the Cisco Unified CallManager 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 be written.
In addition to the CDR, a call may involve one CMR per endpoint. In a successful call between two parties who are each using an IP phone, the system writes two CMRs: one for the originator and one for the destination of the call.
This section describes the records 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
•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.
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 the CDR Log Calls With Zero Duration Flag service parameter 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 these calls as a normal call 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 (the CDR Log Calls With Zero Duration Flag 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 CDR Log Calls With Zero Duration Flag 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 CallManager includes two pickup modes: Pickup and Auto Pickup. The following sections describes these calls:
•Pickup Calls
•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 Example
1. A call comes in from the PSTN to extension 2001; 2002 and 2002 are in the same pickup group.
2. Extension 2002 picks up the call that is ringing on 2001.
3. The call automatically connects between the PSTN caller and extension 2002.
Call ID
|
Orig Cause
|
Calling Party
|
Dest Cause
|
Original Called Party
|
Final Called Party
|
Last Redirect Party
|
Orig Termina-tion On BehalfOf
|
Dest Termina-tion On BehalfOf
|
Last Redirect On
BehalfOf
|
Last Redirect Reason
|
Join On
BehalfOf
|
11
|
126
|
9728131234
|
126
|
2001
|
2001
|
2001
|
16
|
16
|
0
|
0
|
0
|
11
|
0
|
9728131234
|
16
|
2002
|
2002
|
2001
|
16
|
16
|
16
|
5
|
16
|
Transferred Calls
A single CDR cannot show all the data necessary for a call transfer because it is too complex. Each time a call is transferred, the Cisco Unified CallManager terminates the CDR for that call and initiates a new CDR.
Calls that are transferred have multiple CDRs logged for them, as follows:
1. Original call from party A to party B.
2. Call from the transferring party (party A or B) to the transfer destination (party C).
3. Call from the transferred party (party A or B) to the destination (party C).
The first CDR 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 be generated under the stated circumstances. These examples help clarify what records are 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, then the call from B to C will have a duration of zero seconds. If the call was a consultation transfer, then all calls will have non-zero durations. Original Called Party and Call Party Number fields match.
Example 3
A calls B; B transfers A to C on a blind transfer. C is Call Forwarded on No Answer to D. The calls 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 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, talking for 120 seconds.
•B—Extension 2001 initiates a transfer without consultation (duration is zero) to extension 2002.
•C—Extension 2001 completes the transfer, dropping out of the call, and leaving a call between the other two parties.
| |
Calling
Party
|
Calling
Partition
|
Calling
Leg
|
Original Called Party
|
Original Called Partition
|
Called
Leg
|
Orig Cause
|
Dest Cause
|
OrigCall Term On BehalfOf
|
DestCall Term On BehalfOf
|
Join On BehalfOf
|
Duration
|
A
|
2001
|
ACNTS
|
101
|
3071111
|
PSTN
|
102
|
126
|
126
|
10
|
10
|
0
|
120
|
B
|
2001
|
ACNTS
|
103
|
2002
|
ACNTS
|
104
|
126
|
126
|
10
|
10
|
0
|
0
|
C
|
3071111
|
PSTN
|
102
|
2002
|
ACNTS
|
104
|
0
|
16
|
0
|
0
|
10
|
350
|
Transfer with Consultation
Transfer with consultation essentially acts identical to transfer without consultation, except the duration of the middle call is not zero.
As with a transfer without consultation, Cisco Unified CallManager creates three CDRs. The first CDR reflects the call between the original two parties (A and B), the second CDR represents the consultation call between the transferring party (A) and the new party (C), and the final CDR reflects the call between B and C.
Transfer with Consultation CDR Examples
The following table contains three examples:
•A—Call from extension 2001 to a PSTN number, talking for 120 seconds.
•B—Extension 2001 places the PSTN call on hold and calls extension 2002, talking for 30 seconds.
•C—Extension 2001 completes the transfer, dropping out of the call, leaving a call between the other two parties.
| |
Calling
Party
|
Calling
Partition
|
Calling
Leg
|
Original Called Party
|
Original Called Partition
|
Called
Leg
|
Orig Cause
|
Dest Cause
|
OrigCall Term On BehalfOf
|
DestCall Term On BehalfOf
|
Join On BehalfOf
|
Duration
|
A
|
2001
|
ACNTS
|
101
|
3071111
|
PSTN
|
102
|
126
|
126
|
10
|
10
|
0
|
120
|
B
|
2001
|
ACNTS
|
103
|
2002
|
ACNTS
|
104
|
126
|
126
|
10
|
10
|
0
|
30
|
C
|
3071111
|
PSTN
|
102
|
2002
|
ACNTS
|
104
|
0
|
16
|
0
|
0
|
10
|
350
|
Conference Calls
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 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 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 CallManager. Calls to the conference bridge appear as calls to the conference bridge device. A special number in the form "b0019901001" shows the conference bridge port. All calls get shown "into" the conference bridge, regardless of the actual direction. You can determine the original direction of each call by examining the setup call CDRs.
The call legs that are connected to the conference have the following values for these fields:
•finalCalledPartyNumber—Represents a conference bridge "b0019901001"
•origCalledPtyRedirectOnBehalfOf—Set to Conference (4)
•lastRedirectRedirectOnBehalfOf—Set to Conference (4)
•joinOnBehalfOf—Set to Conference (4)
•comment—Identifies the conference controller
The original placed call and all setup calls that were used to join parties to the conference have the following values for the fields:
•origCallTerminationOnBehalfOf—Set to Conference (4).
•destCallTerminationOnBehalfOf—Set to Conference (4).
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 CallManager, 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;ConfCon-
trollerDevice-
Name=SEP0003E333FAD1;ConfReque
storDn-1003;ConfRequestorDevi-
ceName=SEP0003E333
FAD1
|
1003 (CDR6)
|
0
|
98
|
4
|
0
|
2222
|
ConfControllerDn=1003;ConfCon-
trollerDevice-
Name=SEP0003E333FAD1;ConfReque
storDn-1003;ConfRequestorDevi-
ceName=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 CallManager network flags the call. The Comment field flags the malicious call.
The following table contains an example CDR of a customer call that gets marked as malicious.
Calling Party
|
Calling Partition
|
Original Called Party
|
Original Called Partition
|
Orig Cause
|
Dest Cause
|
Comment
|
9728552001
|
CUST
|
5555
|
ACNTS
|
0
|
16
|
"callFlag=MALICIOUS"
|
Conference Drop Any Party
The Conference Drop Any Party feature terminates calls that look the same as other calls except for a new cause code. The cause code identifies the calls that this feature terminates.
Conference Drop Any Party CDR Example
The following table contains an example CDR for a call that was connected to a conference and dropped by this feature.
Calling
Party
|
Calling
Partition
|
Original Called Party
|
Orig Cause
|
Original Called Partition
|
Called Leg
|
Dest Cause
|
Final Called
Party
|
Final Called
Partition
|
Last Redirect Party
|
2001
|
ACNTS
|
2309
|
0
|
MKTG
|
102
|
16
|
2309
|
MKTG
|
2001
|
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
|
Note This table continues the Conference Drop Any Party CDR example .
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 - 320K
•2 = QCIF
Video Call CDR Example
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
|
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 CallManager. See additional information at the "Configuring CDR Service Parameters" section.
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 Call Types
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.
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. See the sections on "Transfer Without Consultation" and "Forwarded or Redirected Calls".
The following table contains an example CDR for this scenario:
•User A (2101) dials 2105.
•The Personal Assistant interceptor (21XX) picks up the call and redirects it to a media port (2002).
•Personal Assistant processes the call according to the rules (if any) and transfers the call to the destination (2105), which has not configured any rules.
Calling Party 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
|
Orig
LegCall 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
|
16777248
|
PAManaged
|
16777250
|
2110
|
PA
|
2105
|
1023970922
|
21XX
|
" "
|
5
|
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
|
" "
|
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 the preceding table, 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, be aware that one CMR per endpoint may be 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 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
•Call Park
•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
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.
•A 60-second call terminated by the caller, notice that because the calling party hangs up, the orig_CauseValue specifies 16 (Normal Clearing).
FieldNames
|
Values
|
globalCallID_callId
|
1
|
origLegCallIdentifier
|
100
|
destLegCallIdentifier
|
101
|
callingPartyNumber
|
2001
|
originalCalledPartyNumber
|
2309
|
finalCalledPartyNumber
|
2309
|
lastRedirectDn
|
2309
|
origCause_Value
|
16
|
dest_CauseValue
|
0
|
duration
|
60
|
•A 60-second call cleared by the called party, notice that because the called party hangs up, the dest_CauseValue specifies 16 (Normal Clearing).
FieldNames
|
Values
|
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 will not get logged. If logging calls with zero duration is enabled, all calls will generate a CDR.
If the call was 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 were not connected will have a duration of zero seconds. When a call is abandoned, the cause code equals zero.
If the user dialed a Directory Number and then abandoned the call before it was connected, 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.
FieldNames
|
Values
|
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.
FieldNames
|
Values
|
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 will all get logged as a normal call with all relevant fields that contain data. The Calling or Called Party Cause field contains a cause code to indicate why the call was not connected, and the Called Party IP and Date/Time Connect fields remains blank. All unsuccessful calls get logged, even if zero duration calls are not being logged.
Examples of Unsuccessful Calls
•Call to PSTN number, but party already engaged (cause 17 = user busy).
FieldNames
|
Values
|
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).
FieldNames
|
Values
|
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).
FieldNames
|
Values
|
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 originalCallPartyNumber 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 field gives the reason 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 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.
FieldNames
|
Values
|
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 voice-messaging system (6000) where the caller leaves a message.
FieldNames
|
Values
|
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.
FieldNames
|
Values
|
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 CallManager: Pickup and Auto Pickup. The CDRs for both differ slightly for these two types of call pickup.
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, and the call automatically connects between the PSTN caller and 2002. They talk for 2 minutes.
FieldNames
|
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 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 redirect the call for the last redirect. For call pickup, this field specifies Pickup = 16.
Legacy Pickup CDR 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.
FieldNames
|
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.
The original call has the origCause_value and destCause_value 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.
The consultation call has the origCause_value and destCause_value 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.
The final transferred call has the joinOnBehalfOf field set to Transfer = 10 to indicate 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.
FieldNames
|
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.
FieldNames
|
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 a 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 the 50000 and 50002.
FieldNames
|
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 the 50001 and 50002.
FieldNames
|
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 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, 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 are 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 the 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 CallManager, 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 are shown into the conference bridge, regardless of the actually direction. But 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 identifies the conference controller. You need 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 could happen in the case in which 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 includes 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 call gets shown as a call into the bridge, regardless of the actual direction of the call.
FieldNames
|
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
|
|
Call Park
Call Pickup will generate two CDRs, one for the original call that is parked and another for the call that is picked up or reverted. These CDRs will have the same globalCallID_callId.
Call Park Pickup
•When the call is parked, the call gets split. This generates a CDR for the original call. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields gets set to Call Park = 3 for this CDR.
•When the parked call is retrieved, the user goes off hook and enters the park code. This call gets joined with the parked call. Because the user who is picking up the call is joined with the parked call, the user gets treated as the originator of the call, and the parked user gets treated as the destination. This means that the callingPartyNumber of the call contains the directory number of the user who is picking up the call, and the originalCalledNumber and finalCalledNumber contains the directory number of the parked user. The lastRedirectDn contains the park code that is used to pick up the call. The lastRedirectRedirectReason specified Call Park Pickup = 8. The lastRedirectRedirectOnBehalfOf should also specify Call Park = 3.
Call Park Example
•Call Park Example - 50003 calls 50002, 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code (44444).
FieldNames
|
Original Call that is parked
|
Parked call that is picked up
|
globalCallID_callId
|
1
|
1
|
origLegCallIdentifier
|
20863957
|
20863961
|
destLegCallIdentifier
|
20863958
|
20863957
|
callingPartyNumber
|
50003
|
50001
|
originalCalledPartyNumber
|
50002
|
50003
|
finalCalledPartyNumber
|
50002
|
50003
|
lastRedirectDn
|
50002
|
44444
|
origCause_Value
|
393216
|
0
|
dest_CauseValue
|
393216
|
16
|
origCalledPartyRedirectReason
|
0
|
0
|
lastRedirectRedirectReason
|
0
|
8
|
origCalledPartyRedirectOnBehalfOf
|
0
|
0
|
lastRedirectRedirectOnBehalfOf
|
0
|
3
|
origTerminationOnBehalfOf
|
3
|
0
|
destTerminationOnBehalfOf
|
3
|
12
|
joinOnBehalfOf
|
0
|
3
|
duration
|
4
|
60
|
Call Park Reversion
When a call is parked and not picked up, the call park reversion timer will expire and redirect the call to the called party. In this case, the system generates two CDRs. The first CDR appears the same as the preceding Call Park Pickup scenario, but the second CDR differs slightly. When the Call Pickup Reversion timer expires, the call gets redirected to the called party.
When the call is parked, the call gets split. This generates a CDR for the original call. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR, the same as Call Park Pickup scenario.
•When Call Park Reversion timer expires, the call gets redirected to the called party. The origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields specify Call Park = 3. The origCalledPartyRedirectReason specifies Call Park = 7, and the lastRedirectRedirectReason specifies Call Park Reversion = 11.
Call Park Reversion Example
•Call Park Reversion Example - 50003 calls 50002; 50002 presses the Park softkey. Nobody picks up the parked call; it reverts to 50002, and 50002 answers.
FieldNames
|
Original Call that is parked
|
Reverted Call CDR
|
globalCallID_callId
|
2
|
2
|
origLegCallIdentifier
|
20863963
|
20863963
|
destLegCallIdentifier
|
20863964
|
20863967
|
callingPartyNumber
|
50003
|
50003
|
originalCalledPartyNumber
|
50002
|
50002
|
finalCalledPartyNumber
|
50002
|
50002
|
lastRedirectDn
|
50002
|
50002
|
origCause_Value
|
393216
|
0
|
dest_CauseValue
|
393216
|
16
|
origCalledPartyRedirectReason
|
0
|
7
|
lastRedirectRedirectReason
|
0
|
11
|
origCalledPartyRedirectOnBehalfOf
|
0
|
3
|
lastRedirectRedirectOnBehalfOf
|
0
|
3
|
origTerminationOnBehalfOf
|
3
|
3
|
destTerminationOnBehalfOf
|
3
|
12
|
joinOnBehalfOf
|
0
|
3
|
duration
|
7
|
60
|
Precedence Calls (MLPP)
With precedence calls everything basically stays the same for all calls: normal calls, forwarded calls, transferred calls, and so on. The differences include the precedence level fields are set in the CDR, and also when a call is preempted by a higher-level precedence call, the cause codes indicate the reason for the preemption.
Precedence Call Examples
•Call to another IP phone by dialing a precedence pattern (precedence level 2)
FieldNames
|
Precedence Call CDR
|
globalCallID_callId
|
100
|
origLegCallIdentifier
|
12345
|
destLegCallIdentifier
|
12346
|
callingPartyNumber
|
2001
|
origCalledPartyNumber
|
826001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origPrecedenceLevel
|
2
|
destPrecedenceLevel
|
2
|
•Received precedence call from another network (precedence level 1)
FieldNames
|
Precedence Call CDR
|
globalCallID_callId
|
102
|
origLegCallIdentifier
|
11111
|
destLegCallIdentifier
|
11112
|
callingPartyNumber
|
9728552001
|
origCalledPartyNumber
|
6001
|
origCause_Value
|
16
|
dest_CauseValue
|
0
|
origPrecedenceLevel
|
1
|
destPrecedenceLevel
|
1
|
•Call gets preempted by a higher precedence level call
FieldNames
|
Original call CDR
|
Higher Level Call CDR
|
globalCallID_callId
|
10000
|
10001
|
origLegCallIdentifier
|
12345678
|
12345680
|
destLegCallIdentifier
|
12345679
|
12345681
|
callingPartyNumber
|
2001
|
9728551234
|
origCalledPartyNumber
|
826001
|
826001
|
origCause_Value
|
0
|
0
|
dest_CauseValue
|
9
|
16
|
origPrecedenceLevel
|
2
|
1
|
destPrecedenceLevel
|
2
|
1
|
Malicious Calls
When a call is identified as a malicious call (button press), the local network (Cisco Unified CallManager) flags the call. The "comment" gets used to flag the malicious call.
Malicious Call Example
•Customer call marked as malicious
FieldNames
|
Original call CDR
|
globalCallID_callId
|
1
|
origLegCallIdentifier
|
100
|
destLegCallIdentifier
|
101
|
callingPartyNumber
|
9728552001
|
origCalledPartyNumber
|
5555
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
Comment
|
callFlag=MALICIOUS
|
Immediate Divert (to Voice-messaging System)
Idivert can get invoked in three different call states:
•You can invoke the IDivert feature while the incoming call is ringing. The CDR for the ringing case acts very similar to call forwarding, but the origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf specify Immediate Divert = 14.
•You can invoke the IDivert feature while the call is connected or on hold. These scenarios generate two CDRs. Both CDRs will have the same globalCallID_CallId field. The first for the original connected and a second for the call redirected to the Cisco voice-messaging system. The first call will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf field set to Immediate Divert = 14.
•The call that is redirected to the voice-messaging system will have the origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf fields set to Immediate Divert = 14.
IDivert Examples
•IDivert during Alerting - 40003 calls 40001, and while 40001 is ringing, 40001 presses the IDivert button, and call diverts to the voice-messaging system (40000).
Note If the call is redirected by IDivert in the Alerting state, only one CDR gets generated.
FieldNames
|
Original call CDR
|
globalCallID_callId
|
37
|
origLegCallIdentifier
|
16777327
|
destLegCallIdentifier
|
16777329
|
callingPartyNumber
|
40003
|
origCalledPartyNumber
|
40001
|
finalCalledPartyNumber
|
40000
|
lastRedirectDn
|
40001
|
origCause_Value
|
16
|
dest_CauseValue
|
0
|
origCalledPartyRedirectReason
|
50
|
lastRedirectRedirectReason
|
50
|
origCalledPartyRedirectOnBehalfOf
|
14
|
lastRedirectRedirectOnBehalfOf
|
14
|
joinOnBehalfOf
|
14
|
•IDivert during Connect - 40003 calls 40001,and 40001 answers the call. 40001 decides to divert the caller to the voice-messaging system and presses the IDivert softkey. 40003 gets diverted to voice-messaging system (40000).
Because the call was connected before the redirect, two CDRs are generated:
one for the original connected call, and another for the call diverted to the voice-messaging system.
FieldNames
|
Original connected call CDR
|
Diverted call CDR
|
globalCallID_callId
|
38
|
38
|
origLegCallIdentifier
|
16777330
|
16777330
|
destLegCallIdentifier
|
16777331
|
16777332
|
callingPartyNumber
|
40003
|
40003
|
origCalledPartyNumber
|
40001
|
40001
|
finalCalledPartyNumber
|
40001
|
40000
|
lastRedirectDn
|
40001
|
40001
|
origCause_Value
|
0
|
16
|
dest_CauseValue
|
0
|
0
|
origCalledPartyRedirectReason
|
0
|
50
|
lastRedirectRedirectReason
|
0
|
50
|
origCalledPartyRedirectOnBehalfOf
|
|
14
|
lastRedirectRedirectOnBehalfOf
|
|
14
|
origTerminationOnBehalfOf
|
14
|
14
|
destTerminationOnBehalfOf
|
14
|
12
|
joinOnBehalfOf
|
|
14
|
Barge
When a shared line uses the barge feature, the origCalledPartyNumber, finalCalledPartyNumber, and lastRedirectDn represent the conference bridge number `b00...'. The redirect and join OnBehalfOf fields have a value of Barge = 15, and the redirect reason fields are Barge = 114.
Barge Examples
•Barge Example 1- 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40003 hangs up.
Note Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.
FieldNames
|
Original Call CDR
|
Barge Call CDR
|
globalCallID_callId
|
7
|
7
|
origLegCallIdentifier
|
16777230
|
16777232
|
destLegCallIdentifier
|
16777231
|
16777235
|
callingPartyNumber
|
40003
|
40003
|
origCalledPartyNumber
|
40001
|
b001501001
|
finalCalledPartyNumber
|
40001
|
b001501001
|
lastRedirectDn
|
40001
|
b001501001
|
origCause_Value
|
16
|
0
|
dest_CauseValue
|
0
|
0
|
origCalledPartyRedirectReason
|
0
|
114
|
lastRedirectRedirectReason
|
0
|
114
|
origCalledPartyRedirectOnBehalfOf
|
|
15
|
lastRedirectRedirectOnBehalfOf
|
|
15
|
joinOnBehalfOf
|
|
15
|
destConversationID
|
0
|
16777231
|
•Barge Example 2- 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40001 hangs up.
Note Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.
FieldNames
|
Original Call CDR
|
Barge Call CDR
|
Final Call CDR
|
globalCallID_callId
|
9
|
9
|
9
|
origLegCallIdentifier
|
16777236
|
16777238
|
16777236
|
destLegCallIdentifier
|
16777237
|
16777241
|
16777238
|
callingPartyNumber
|
40003
|
40001
|
40003
|
origCalledPartyNumber
|
40001
|
b001501001
|
40001
|
finalCalledPartyNumber
|
40001
|
b001501001
|
40001
|
lastRedirectDn
|
40001
|
b001501001
|
40001
|
origCause_Value
|
0
|
393216
|
16
|
dest_CauseValue
|
16
|
393216
|
0
|
origCalledPartyRedirectReason
|
0
|
114
|
0
|
lastRedirectRedirectReason
|
0
|
114
|
0
|
origTerminationOnBehalfOf
|
|
15
|
12
|
destTerminationOnBehalfOf
|
12
|
15
|
12
|
lastRedirectRedirectOnBehalfOf
|
|
15
|
|
joinOnBehalfOf
|
|
15
|
|
destConversationID
|
0
|
16777237
|
0
|
•Barge Example 3- 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40001' (another shared line and phone) presses the Barge softkey. 40003 hangs up first.
Note All CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.
FieldNames
|
Original Call CDR
|
Barge Call 1 CDR
|
Barge Call 2 CDR
|
globalCallID_callId
|
14
|
14
|
14
|
origLegCallIdentifier
|
16777249
|
16777251
|
16777255
|
destLegCallIdentifier
|
16777250
|
16777254
|
16777258
|
callingPartyNumber
|
40003
|
40001
|
40001
|
origCalledPartyNumber
|
40001
|
b001501001
|
b001501001
|
finalCalledPartyNumber
|
40001
|
b001501001
|
b001501001
|
lastRedirectDn
|
40001
|
b001501001
|
b001501001
|
origCause_Value
|
16
|
0
|
0
|
dest_CauseValue
|
0
|
0
|
0
|
origCalledPartyRedirectReason
|
0
|
114
|
114
|
lastRedirectRedirectReason
|
0
|
114
|
114
|
origTerminationOnBehalfOf
|
12
|
15
|
15
|
destTerminationOnBehalfOf
|
|
|
|
origRedirectOnBehalfOf
|
|
15
|
15
|
lastRedirectRedirectOnBehalfOf
|
|
15
|
15
|
joinOnBehalfOf
|
|
15
|
15
|
destConversationID
|
0
|
16777250
|
16777251
|
cBarge
The cBarge feature acts very similar to the conference feature. When a shared line uses the cBarge feature, the origCalledPartyNumber, finalCalledPartyNumber and lastRedirectDn represent the conference bridge number `b00...'. The redirect and join OnBehalfOf fields have a value of Conference = 4, and the redirect reason fields specify Conference = 98.
cBarge Examples
•cBarge Example - 40003 calls 40001, and 40001 answers; 40001' (shared line) on another phone presses the cBarge button.
FieldNames
|
Orig Call CDR
|
cBarge Call CDR 1
|
cBarge Call CDR 2
|
cBarge Call CDR 3
|
Final Call CDR
|
globalCallID_callId
|
49
|
49
|
49
|
49
|
49
|
origLegCallIdentifier
|
1677346
|
1677348
|
1677347
|
1677346
|
1677347
|
destLegCallIdentifier
|
1677347
|
1677353
|
1677351
|
1677352
|
1677346
|
callingPartyNumber
|
40003
|
40001
|
40001
|
40003
|
40001
|
originalCalledPartyNumber
|
40001
|
b0029901001
|
b0029901001
|
b0029901001
|
40003
|
finalCalledPartyNumber
|
40001
|
b0029901001
|
b0029901001
|
b0029901001
|
40003
|
lastRedirectDn
|
40001
|
b0029901001
|
40001
|
40001
|
b0029901001
|
origCause_Value
|
393216
|
16
|
393216
|
393216
|
16
|
dest_CauseValue
|
393216
|
0
|
393216
|
393216
|
0
|
origCalledPartyRedirectReason
|
0
|
98
|
98
|
98
|
0
|
lastRedirectRedirectReason
|
0
|
98
|
98
|
98
|
98
|
destTerminationOnBehalfOf
|
4
|
|
4
|
4
|
4
|
origCalledRedirectOnBehalfOf
|
|
4
|
4
|
4
|
|
lastRedirectRedirectOnBehalfOf
|
|
4
|
4
|
4
|
4
|
joinOnBehalfOf
|
|
4
|
4
|
4
|
4
|
Conversation ID
|
0
|
16777220
|
16777220
|
16777220
|
1
|
duration
|
60
|
360
|
|
360
|
360
|
Comment
|
Orig Call CDR
|
|
cBarge Call CDR 1
|
ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
|
cBarge Call CDR 2
|
ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
|
cBarge Call CDR 3
|
ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
|
Final Call CDR
|
ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD
|
Video Calls
This is an example CDR for a video call.
Video Call CDR Example
•Example - Calling party 51234 calls the called party 57890. In the following example, let 100 = H.261, 187962284 = 172.19.52.11, 288625580 = 172.19.52.17, 320 = 320K, and 2 = QCIF.
FieldNames
|
Video Call CDR
|
globalCallID_callId
|
121
|
origLegCallIdentifier
|
101
|
destLegCallIdentifier
|
102
|
callingPartyNumber
|
51234
|
origCalledPartyNumber
|
57890
|
finalCalledPartyNumber
|
57890
|
lastRedirectDn
|
57890
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origVideoCap_Codec
|
100
|
origVideoCap_Bandwidth
|
320
|
origVideoCap_Resolution
|
2
|
origVideoTransportAddress_IP
|
187962284
|
origVideoTransportAddress_Port
|
49208
|
destVideoCap_Codec
|
100
|
destVideoCap_Bandwidth
|
320
|
destVideoCap_Resolution
|
2
|
destVideoTransportAddress_IP
|
288625580
|
destVideoTransportAddress_Port
|
49254
|
Forced Authorization Code (FAC)
When FAC feature is invoked, the system writes the authorization description and level into the CDR. For security reasons, the actual authorization code will not get written to the CDR.
•The authCodeDescription field contains the description of the authorization code.
•The authorizationLevel field contains the level of authorization that is associated with the authorization code.
FAC Example
45000 calls 9728134987, the user gets prompted for a authorization code and enters 12345. FAC code 12345 is configured as level 1 and name Legal1. The caller answers the call and talks for 2 minutes.
FieldNames
|
Values
|
globalCallID_callId
|
100
|
origLegCallIdentifier
|
16777123
|
destLegCallIdentifier
|
16777124
|
callingPartyNumber
|
45000
|
origCalledPartyNumber
|
9728134987
|
finalCalledPartyNumber
|
9728134987
|
lastRedirectDn
|
9728134987
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
authCodeDescription
|
Legal1
|
authorizationLevel
|
1
|
duration
|
120
|
Client Matter Code (CMC)
When the CMC feature is invoked, the system writes the client matter code into the CDR. The clientMatterCode field contains the client matter code that the caller entered.
CMC Example
•10000 calls 2142364624; the user is prompted for a client matter code and enters 11111. The caller answers the call and talks for 10 minutes.
FieldNames
|
Values
|
globalCallID_callId
|
101
|
origLegCallIdentifier
|
16777130
|
destLegCallIdentifier
|
16777131
|
callingPartyNumber
|
10000
|
origCalledPartyNumber
|
2142364624
|
finalCalledPartyNumber
|
2142364624
|
lastRedirectDn
|
2142364624
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
clientMatterCode
|
11111
|
duration
|
600
|
Call Secured Status
This field identifies security status of the call. It contains the highest level of security that is reached during a call. For example, if the call is originally unsecured, so that later the call changed to secured, the CDR contains 1 for "Secured" even though different portions of the call had different status values. The callSecuredStatus will identify the security status of the call.
Examples
•Encrypted Call Example - The call between 20000 and 20001 is encrypted. They talk for 5 minutes.
FieldNames
|
Values
|
globalCallID_callId
|
102
|
origLegCallIdentifier
|
16777140
|
destLegCallIdentifier
|
16777141
|
callingPartyNumber
|
20000
|
origCalledPartyNumber
|
20001
|
finalCalledPartyNumber
|
20001
|
lastRedirectDn
|
20001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
callSecuredStatus
|
2
|
duration
|
300
|
•Authenticated Call Example - The call between 20000 and 20001 is authenticated (not encrypted). They talk for 10 minutes.
FieldNames
|
Values
|
globalCallID_callId
|
103
|
origLegCallIdentifier
|
16777142
|
destLegCallIdentifier
|
16777143
|
callingPartyNumber
|
20000
|
origCalledPartyNumber
|
20001
|
finalCalledPartyNumber
|
20001
|
lastRedirectDn
|
20001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
callSecuredStatus
|
1
|
duration
|
600
|
DTMF Method
These fields identify the DTMF method that is used for the call.
DTMF Call Examples
•No Preference Example - The DTMF method that is used during this call represents No Preference/Best Effort. This call connects for 1 minute.
FieldNames
|
Values
|
globalCallID_callId
|
200
|
origLegCallIdentifier
|
16777500
|
destLegCallIdentifier
|
16777501
|
callingPartyNumber
|
20000
|
origCalledPartyNumber
|
20001
|
finalCalledPartyNumber
|
20001
|
lastRedirectDn
|
20001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origDTMFMethod
|
0
|
destDTMFMethod
|
0
|
duration
|
60
|
•Preferred OOB Example - The DTMF method that is used during this call represents OOB Preferred. This call stays connected for 1 minute.
FieldNames
|
Values
|
globalCallID_callId
|
201
|
origLegCallIdentifier
|
16777502
|
destLegCallIdentifier
|
16777503
|
callingPartyNumber
|
20000
|
origCalledPartyNumber
|
20001
|
finalCalledPartyNumber
|
20001
|
lastRedirectDn
|
20001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origDTMFMethod
|
1
|
destDTMFMethod
|
1
|
duration
|
60
|
RSVP
These fields identify the status of RSVP reservation for the call. Be aware that the Unified CM RSVP CDR status field value is concatenated and the last 32 status values are retained for the call.
For example, if a call is established with "Optional" policy, and the initial RSVP reservation is successful, and then it subsequently loses its bandwidth reservation and then regains its bandwidth reservation after retry, for several times during middle of the call, and the call ended with successful RSVP reservation, the CDR shows the following string as the Unified CM RSVP reservation status for that particular stream: "2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success).
RSVP Call Examples
•The example represents a call that is established with "Optional" policy, and the initial RSVP reservation is successful. The parties talk for 5 minutes.
FieldNames
|
Values
|
globalCallID_callId
|
300
|
origLegCallIdentifier
|
16777300
|
destLegCallIdentifier
|
16777301
|
callingPartyNumber
|
20000
|
origCalledPartyNumber
|
20001
|
finalCalledPartyNumber
|
20001
|
lastRedirectDn
|
20001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origDTMFMethod
|
2
|
destDTMFMethod
|
2
|
duration
|
300
|
•The example represents a call is established with "Optional" policy, and the initial RSVP reservation is successful, then it loses its bandwidth reservation, but regains it after a retry. Parties talk for 1 minute.
FieldNames
|
Values
|
globalCallID_callId
|
301
|
origLegCallIdentifier
|
16777302
|
destLegCallIdentifier
|
16777303
|
callingPartyNumber
|
20000
|
origCalledPartyNumber
|
20001
|
finalCalledPartyNumber
|
20001
|
lastRedirectDn
|
20001
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origDTMFMethod
|
2:5:2
|
destDTMFMethod
|
2:5:2
|
duration
|
60
|
Redirection (3xx) Calls
This example shows CDRs for a the redirection feature (3xx).
When a call is redirected by the Redirection Feature (3xx), the origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields represent CCM Redirection = 19. The origCalledPartyRedirectReason and the lastRedirectRedirectReason represent Redirection = 162.
Redirection (3xx) Examples
•Redirection Example - Activate CFA on phone 10010 that is running SIP (registered to Unified CM) with a CFA destination of 10000. 35010 calls 10010, which is CFA to 10000. The call gets redirected from 10010 to 10000. 10000 answers the call and talks for a minute.
FieldNames
|
Original Call CDR
|
globalCallID_callId
|
11
|
origLegCallIdentifier
|
21832023
|
destLegCallIdentifier
|
21832026
|
callingPartyNumber
|
35010
|
originalCalledPartyNumber
|
10010
|
finalCalledPartyNumber
|
10000
|
lastRedirectDn
|
10010
|
origCause_Value
|
0
|
dest_CauseValue
|
16
|
origCalledPartyRedirectReason
|
162
|
lastRedirectRedirectReason
|
162
|
origCalledPartyRedirectOnBehalfOf
|
19
|
lastRedirectRedirectOnBehalfOf
|
19
|
origTerminationOnBehalfOf
|
0
|
destTerminationOnBehalfOf
|
12
|
joinOnBehalfOf
|
19
|
duration
|
60
|
Replaces Calls
This example shows a CDR for a Replaces call.
Replaces Examples
•Invite with Replaces Example - Phone 35010 that is running SIP calls phone 35020 that is running SIP; the transfer button gets pressed on 35010, and a call is made to SCCP phone 3000. 3000 answers the call; then, phone 35010 completes the transfer. The final transferred call occurs between 35020 and 3000.
Note When the transfer is complete, the system sends an Invite with Replaces to Cisco Unified CallManager.
FieldNames
|
Original Call CDR
|
Reverted Call CDR
|
globalCallID_callId
|
5045247
|
5045248
|
origLegCallIdentifier
|
21822467
|
21822469
|
destLegCallIdentifier
|
21822468
|
21822468
|
callingPartyNumber
|
35010
|
35020
|
originalCalledPartyNumber
|
3000
|
3000
|
finalCalledPartyNumber
|
3000
|
3000
|
lastRedirectDn
|
3000
|
35010
|
origCause_Value
|
393216
|
0
|
dest_CauseValue
|
393216
|
16
|
origCalledPartyRedirectReason
|
0
|
0
|
lastRedirectRedirectReason
|
0
|
146
|
origCalledPartyRedirectOnBehalfOf
|
0
|
0
|
lastRedirectRedirectOnBehalfOf
|
0
|
18
|
origTerminationOnBehalfOf
|
18
|
0
|
destTerminationOnBehalfOf
|
18
|
12
|
joinOnBehalfOf
|
0
|
18
|
duration
|
5
|
60
|
•Refer with Replaces Example - Phone 35010 that is running SIP calls SCCP 3000, the transfer button gets pressed on 35010, and a call is made to SCCP 3001; 3001 answers the call; then, the phone 35010 completes the transfer. The final transferred call occurs between 3000 and 3001.
Note When the transfer is complete, a Refer with Replaces gets sent to Cisco Unified CallManager.
FieldNames
|
Original Call CDR
|
Consultation Call CDR
|
Final Transferred Call CDR
|
globalCallID_callId
|
5045245
|
5045246
|
5045245
|
origLegCallIdentifier
|
21822461
|
21822463
|
21822462
|
destLegCallIdentifier
|
21822462
|
21822464
|
21822464
|
callingPartyNumber
|
35010
|
35010
|
3000
|
originalCalledPartyNumber
|
3000
|
3001
|
3001
|
finalCalledPartyNumber
|
3000
|
3001
|
3001
|
lastRedirectDn
|
3000
|
3001
|
35010
|
origCause_Value
|
393216
|
393216
|
16
|
dest_CauseValue
|
393216
|
393216
|
0
|
origCalledPartyRedirectReason
|
0
|
0
|
130
|
lastRedirectRedirectReason
|
0
|
0
|
146
|
origCalledPartyRedirectOnBehalfOf
|
0
|
0
|
17
|
lastRedirectRedirectOnBehalfOf
|
0
|
0
|
18
|
origTerminationOnBehalfOf
|
17
|
18
|
12
|
destTerminationOnBehalfOf
|
17
|
18
|
17
|
joinOnBehalfOf
|
0
|
0
|
18
|
duration
|
25
|
4
|
25
|
Refer Calls
See the "Replaces Calls" section for an example of Refer with Replaces.
CDR Field Descriptions
Table 4 defines all fields in the current CDRs in the order in which they appear in the CDR.
Table 4 CDR Field Descriptions
Field Name
|
Range of Values
|
Description
|
cdrRecordType
|
0, 1, 2
|
This field defines the type of record. The following valid values apply:
•0—Start call detail record (not used)
•1—End call detail record (CDR)
•2—CMR
Default - For CDRs, this field always specifies 1.
|
globalCallID_callManagerId
|
Positive Integer
|
This field designates a unique Cisco Unified CallManager identity.
The Global Call ID comprises two fields: globalCallID_callId and globalCallID_callManagerId
All records that are associated with a standard call have the same Global Call ID in them.
Default - You should always ensure that this field is populated.
|
globalCallID_callId
|
Positive Integer
|
This field designates unique call identity value that is assigned to each call. This identifier gets allocated independently on each call server. Values get chosen sequentially when a call begins, and value gets assigned for each call, successful or unsuccessful. When Cisco Unified CallManager restarts, this values resets to 1.
The Global Call ID comprises two fields: globalCallID_callId and globalCallID_callManagerId
All records that are associated with a standard call have the same Global Call ID in them.
Default - You should always ensure that this field is populated.
|
origLegCallIdentifier
|
Positive Integer
|
This field identifies the originating leg of a call. This value remains unique within a cluster. If the leg of a call persists across several sub-calls, and consequently several CDRs (as during a call transfer), this value remains constant.
Default - You should always ensure that this field is populated.
|
dateTimeOrigination
|
Integer
|
This field identifies the date and time when the user goes off hook or the date and time when the H.323 Setup message is received for an incoming call. The time gets stored as UTC.
Default - You should always ensure that this field is populated.
|
origNodeId
|
Positive Integer
|
This field identifies the node within a cluster to which the originator of the call is registered at the time the call is made.
Default - You should always ensure that this field is populated.
|
origSpan
|
0, Positive integer
|
For calls originating at a gateway, this field indicates the B channel number of the T1, PRI, or BRI trunk where the call is originated, or a zero value for FXS or FXO trunks.
For H.323 gateways, the span number remains unknown, and this field contains the call leg ID of the originator.
For calls that do not originate at a gateway, the value equals zero.
Default - This field gets populated based on these rules.
|
origIpAddr
|
Integer
|
This field identifies the IP address of the device that originated the call signaling.
For Cisco Unified IP Phones, this field specifies the address of the phone.
For PSTN calls, this field specifies the address of the H.323 gateway.
For intercluster calls, this field specifies the address of the remote Cisco Unified CallManager.
The "IP Addresses" section describes the IP address format.
Default - This field gets populated based on these rules.
|
callingPartyNumber
|
Text String
|
This field specifies numeric string of up to 25 characters.
For calls that originate at a Cisco Unified IP Phone, this field shows the extension number of the line that is used.
For incoming H.323 calls, this field specifies the value that is received in the Calling Party Number field in the Setup message. This field reflects any translations that were applied to the Calling Party Number before it arrives at the Cisco Unified CallManager (such as translations at the gateway).
For server calls, where Cisco Unified CallManager originates a half call without a calling party, this field may be empty.
CallingPartyNumber could contain a SIP URI.
Default - This field gets populated based on these rules.
|
callingPartyUnicodeLoginUserID
|
Unicode - UTF_8
|
This field specifies the calling party login user ID. The format of this field specifies UTF_8.
Default - Empty string " ". If the user ID does not exist, this field remains empty.
|
origCause_location
|
0 to 15
|
For clearing causes that are received over ISDN signaling l |
