Cucm 9.1 CDR Admin Guide

Cisco Unified Communications Manager Call Detail Records
Administration Guide, Release 9.1(1)

First Published: December 20, 2012
Last Modified: December 20, 2012
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
Text Part Number: OL-28260-01
2013 Cisco Systems, Inc. All rights reserved.

C ONT E NT S
PA R T I Cisco call detail records 1
C H A P T E R 1 Cisco call detail records 3
CDR management 3
CDR Agent 4
CDR Repository Manager 4
CDR onDemand Service 5
Cisco Unified Communications Manager upgrades and CDR data 5
CDR database backup and recovery 6
Documentation related to CDR 6
C H A P T E R 2 CDR processing 7
Record processing 7
C H A P T E R 3 Call information record types 9
Call information record types 9
Global call identifier 10
Number translations 11
Partitions and numbers 11
Timestamps 13
Call clearing causes 13
Convert signed decimal value to IP address 13
PA R T I I Call detail records 15
C H A P T E R 4 CDR Examples 17
AAC calls 17
Abandoned calls 20
Cisco Unified Communications Manager Call Detail Records Administration Guide, Release 9.1(1)
OL-28260-01 iii
Ad hoc conference linking 21
Conference linking using join 22
Conference linking using transfer or Direct Transfer 24
Linked conference party removal 26
Linked conference party (controller) removal 28
Linked conference removal 31
Agent greeting calls 34
Barge 35
Call monitoring 38
Call park 40
Call park pickup 40
Call park reversion 41
Call pickup 42
Pickup 43
Auto pickup 43
Call recording 45
Call secured status 47
Calling party normalization 48
Calls with busy or bad destinations 49
cBarge 51
Client matter code (CMC) 52
Conference calls 53
Operational factors 56
Conference drop any party 57
Original calling party on transfer 58
DTMF method 59
End-to-End Call Trace 60
Forced authorization code (FAC) 64
Forwarded or redirected calls 65
Hunt list support 68
H.239 71
iLBC calls 73
Immediate divert (to voice-messaging system) 75
Intercom calls 78
IPv6 calls 79
iv OL-28260-01
Contents
Legacy Call Pickup 84
Local route groups and called party transformation 85
Logical partitioning calls 87
Malicious calls 89
Meet-Me conferences 89
Mobility 90
Normal calls (Cisco Unified IP Phone to Cisco Unified IP Phone) 95
Original calling party on transfer 96
Personal assistant calls 97
Personal assistant direct call 97
Personal assistant interceptor going to media port and transferring call 98
Personal assistant interceptor going directly to destination 98
Example personal assistant interceptor going directly to destination with no rules
CDR 99
Example personal assistant going directly to destination with rule to forward calls
to different destination CDR 99
Personal assistant interceptor going to multiple destinations 99
Personal assistant conferencing 102
Precedence calls (MLPP) 103
Redirection (3xx) calls 105
Refer calls 106
Replaces calls 106
RSVP 108
Secure conference Meet-Me 110
Short calls 111
SIP call with URL in CallingPartyNumber field 111
Successful on net calls 112
Transferred calls 112
Video calls 116
Video conference calls 117
C H A P T E R 5 Cisco call detail records field descriptions 121
CDR field descriptions 121
Routing reason values for external call control 148
OL-28260-01 v
Contents
C H A P T E R 6 Cisco call detail records codes 151
Codec types 151
Call termination cause codes 153
Redirect reason codes 159
OnBehalfof codes 162
PA R T I I I Call management records 165
C H A P T E R 7 Call management records 167
Call management records 167
CMR processing 167
Set up CMRs 168
CPU utilization 169
C H A P T E R 8 Cisco call management record field descriptions 171
CMR field descriptions 171
C H A P T E R 9 Cisco call management records K-factor data 177
K-factor data 177
C H A P T E R 1 0 Example Cisco call management records 181
CMR examples 181
vi OL-28260-01
Contents
PAR T I
Cisco call detail records
Cisco call detail records, page 3
CDR processing, page 7
Call information record types, page 9
C HAP T E R 1
Cisco call detail records
This chapter provides information about the format and logic of the call detail records (CDRs) that the Cisco
Unified Communications Manager system generates. You can use this information for post-processing
activities such as generating billing records and network analysis.
When you install your system, the system enables CDRs by default. Call management records (CMRs)
remain disabled by default. You can enable or disable CDRs or CMRs at any time that the system is in
operation. You do not need to restart Cisco Unified Communications Manager for the change to take effect.
The system responds to all changes within a few seconds. The system enables CMR or diagnostic data
separately from CDR data.
CDR management, page 3
Cisco Unified Communications Manager upgrades and CDR data, page 5
CDR database backup and recovery, page 6
Documentation related to CDR, page 6
CDR management
The CDR Management (CDRM) feature, a background application, supports the following capabilities:
Collects the CDR/CMR files from the Cisco Unified Communications Manager server or node to the
CDR Repository server or node.
Collects and maintains the CDR/CMR files on the server where you configure CAR.
Maintains the CDR/CMR files on the CDR Repository node or CDR server.
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 server or node.
Sends CDR/CMR files to up to three customer billing servers via FTP/SFTP.
Monitors disk usage of CDR/CMRfiles on the server where you configure CARor on the CDRRepository
server or node.
OL-28260-01 3
Periodically deletes CDR/CMR files that were successfully delivered. You can configure the amount of
storage that is used to store flat files. Predefined storage limits exist. If the storage limits are exceeded,
the CDR Repository Manager deletes old files to reduce the disk usage to the preconfigured low water
mark. 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.
The CDRM feature handles CDR files and CMR files in the same manner. Note
CDRM comprises two default services, the CDR Agent and the CDR Repository Manager, and one activate
service, CDR onDemand Service.
Related Topics
Call information record types, on page 9
CDR Agent, on page 4
CDR onDemand Service, on page 5
CDR processing, on page 7
CDR Repository Manager, on page 4
CMR processing, on page 167
CDR Agent
As part of the CDRM feature, a resident component on the server or node within a Cisco Unified
Communications Manager installation acts as the CDRAgent. On the server or node where both Cisco Unified
Communications Manager and the CDR Agent are running, Cisco Unified Communications Manager writes
the CDRs into CDR flat files in comma separated value (CSV) format. A special control character (_) that
is prefixed to the filename by the call processing module that indicates that the file is not available for transfer.
If this control character is not present, the system assumes that the file is available for transfer, and the CDR
Agent then SFTPs those files to the designated CDR repository node. Upon successful transfer, the system
deletes the local copy of the file.
Reliability gets the highest priority for the CDRM feature. CDRs comprise very important financial data, so
the goal of this feature is to guarantee that no CDR is lost. The Cisco Unified Communications Manager
continuously writes CDRs to flat files, closes existing flat files, and opens new ones.The number of records
that are written varies by the type of call and the significant changes that occur during a call: such as, ending
the call, transferring the call, redirecting the call, splitting the call, or joining the call.
On Linux platforms, the CDR Agent collects the CDR/CMR flat files that the Cisco Unified
Communications Manager generates and sends these files to the publisher through SFTP. The Windows
versions of do not support SFTP. On Windows platforms, the CDR Agent copies the files directly from
the subscriber disk to the shared publisher disk.
Note
CDR Repository Manager
Within a Cisco Unified Communications Manager server or cluster, one instance of the CDR Repository
Manager runs on the CDR Repository server or node. It manages CDR files that are received from the Cisco
4 OL-28260-01
CDR management
Unified Communications Manager nodes and periodically sends the files to the specified customer/third-party
billing servers via FTP/SFTP.
When the file arrives on the CDR Repository server or node, the CDR Repository Manager detects it. The
system archives the file in a directory that is dedicated to the date that is indicated by the UTC timestamp that
was placed in the file name when the file was created.
If any external billing server is specified in the CDRM configuration, the system creates an empty file in each
of the corresponding folders for CAR and the billing servers, if CAR or the corresponding billing server is
activated. The CDRAgent monitors newCDR/CMRfiles that are generated on CallManager servers or nodes
by the call processing component. It sends the files to the CDR Repository node and then deletes the local
copy after the file is pushed out. The file sender component of the CDR Repository Manager detects these
empty files and sends the file to the destination with the specified method. If the delivery is successful, the
system removes the empty file in the destination directory.
Every Cisco Unified Communications Manager 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 in the CDR
Repository 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 configuring the CDR Repository Manager and customer billing servers, see the
CDR Repository Manager Configuration section in the Cisco Unified Serviceability Administration Guide.
CDR onDemand Service
The CDR onDemand Service, is a SOAP/HTTPS-based service, that runs on the CDR Repository server or
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 an SFTP API. All SFTP connections require userid and password information for each
session setup. A separate SFTP session gets set up for every file that is sent, and the session is closed after
the file has been sent. The system can activate the CDR onDemand service on the CDR Repository node
because it has to access the CDR files in the repository. The system prohibits service during the maintenance
window. For detailed information on the CDR onDemand Service, see the Cisco Unified Communications
Manager Developers Guide.
Cisco Unified Communications Manager upgrades and CDR data
When you upgrade from an earlier version of Cisco Unified Communications Manager to a later version of
Cisco Unified Communications Manager, you may not be able to upgrade all your CDR data. For additional
information about the limitations that affect the amount of CDR data that may be available after upgrade, see
the section titled Upgrading the CAR Database in the CDR Analysis and Reporting Administration Guide.
You may also need to refer to the latest Data Migration Assistant User Guide and the latest upgrade
documentation.
OL-28260-01 5
Cisco Unified Communications Manager upgrades and CDR data
CDR database backup and recovery
Be sure that the CAR and CDR Disaster Recovery Service (DRS) is integrated into the Cisco Unified
Communications Manager DRS. See the latest release of the Disaster Recovery SystemAdministration Guide.
Documentation related to CDR
The following documents contain additional information related to CDRs:
Cisco Unified Serviceability Administration Guide
See the Configuring the CDR Repository Manager chapter in the Cisco Unified Serviceability
Administration Guide.
CDR Analysis and Reporting Administration Guide
See the Activating CAR section in the Configuring CDR Analysis and Reporting Tool chapter found
in the CDR Analysis and Reporting Administration Guide.
Cisco Unified Communications Manager Developers Guide
Disaster Recovery System Administration Guide
6 OL-28260-01
CDR database backup and recovery
C HAP T E R 2
CDR processing
This chapter provides information about how CDRs are processed.
Record processing, page 7
Record processing
Cisco Unified Communications Manager generates two different types of call information records: CDRs and
CMRs. The CDRrecords store information about a call. The CMRrecords store information about the quality
of the streamed audio of the call. The CDR records relate to the CMR records by way of two GlobalCallID
columns: Global CallID callManagerId and GlobalCallID Called. Depending upon the call scenario, more
than one CMR may exist for each CDR.
When Cisco Unified Communications Manager places or receives a call, the system generates a CDR record
when the call terminates. The system writes the CDR to a flat file (text file). Inside the Cisco Unified
Communications Manager, the Call Control process generates CDR records. The system writes records when
significant changes occur to a given call, such as ending the call, transferring the call, redirecting the call,
splitting the call, joining a call, and so forth.
When CDR records are enabled, Call Control generates one or more CDR records for each call. The system
sends these records to EnvProcessCdr, where they are written to the flat files. The number of records that are
written varies by type of call and the call scenario. When Diagnostics are enabled, the device generates CMR
records for each call. The system writes one CMR record for each IP phone that is involved in the call or for
each Media Gateway Control Protocol (MGCP) gateway. The systemalso sends these records to EnvProcessCdr
where they get written to flat files.
The Cisco Unified Communications Manager generates CDR and CMR records but does not perform any
post processing on the records. The system writes the records to comma-delimited flat files and periodically
passes them to the CDR Repository. The CDR and CMR files represent a specific filename format within the
flat file.
Filename format
The following example shows the full format of the filename:
tag_clusterId_nodeId_datetime_seqNumber
tagIdentifies the type of file, either CDR or CMR.
OL-28260-01 7
clusterIdIdentifies the cluster or server where the Cisco Unified Communications Manager
database resides.
nodeIdIdentifies the node
datetimeUTC time in yyyymmddhhmm format
seqnumberSequence number
Two examples of the filenames follow:
cdr_Cluster1_01_200404021658_1
cmr_Cluster1_02_200404061011_6125
For Cisco Unified Communications Manager Business Edition 5000 installations, the value assigned to
the clusterId equals 01.
Note
Flat file format
The CDR and CMR flat files have the following format:
Line 1List of field names comma separated
Line 2List of field type comma separated
Line 3Data comma separated
Line 4Data comma separated
The following example shows a flat file:
Line1-cdrRecordType,globalCallID_callManagerId,globalCallID_callId,origLegCallIdentifier,...
Line2-INTEGER,INTEGER,INTEGER,INTEGER,...
Line3-1,1,388289,17586046,...
Line4-1,1,388293,17586054,...
If the value of the CDR Log Calls With Zero Duration Flag parameter is True, the system writes all calls
to a flat file. See the Configuring CDR Service Parameters section in the CDR Analysis and Reporting
Administration Guide for additional information about this parameter.
Note
Related Topics
Cisco call detail records, on page 3
Cisco call management record field descriptions, on page 171
Call information record types, on page 9
Documentation related to CDR, on page 6
8 OL-28260-01
Record processing
C HAP T E R 3
Call information record types
This chapter describes the two types of call information records that Cisco Unified Communications Manager
generates: Call Detail Records (CDRs) and Call Management Records (CMRs), also called call diagnostic
records.
Call information record types, page 9
Global call identifier, page 10
Number translations, page 11
Partitions and numbers, page 11
Timestamps, page 13
Call clearing causes, page 13
Convert signed decimal value to IP address, page 13
Call information record types
Cisco Unified Communications Manager generates two different types of call information records: Call Detail
Records (CDRs) and Call Management Records (CMRs), also called call diagnostic records. 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 of the call. More than one CMR can exist per CDR.
CMRs are supported by Cisco Unified IP Phones, Cisco 7960 series phones, and Media Gateway Control
Protocol (MGCP) gateways. If one of these endpoints is involved in a call, it will generate a CMR record after
the call terminates. Each endpoint in the call generates a separate CMR record. If the call involves endpoints
that do not support call diagnostics, no record gets generated for that endpoint. A call from a Cisco 7960
phone to an H.323 gateway will generate one CMR record (from the Cisco 7960 phone).
CDRs relate to the CMRs via two globalCallID columns:
globalCallID_callManagerId
globalCallId_callId
When the Call Diagnostics service parameter is set to True, the system generates up to two CMRs for each
call. Each type of call, such as conference calls, call transfers, forwarded calls, and calls through gateways,
produce a set of records that get written to ASCII files at the end of the call. Only completed calls and failed
OL-28260-01 9
calls generate CDRs and CMRs. Cisco Unified Communications Manager does not performany post processing
on CDRs or CMRs.
Related Topics
Call management records, on page 167
CDR processing, on page 7
Cisco call detail records, on page 3
Global call identifier
The Cisco Unified Communications Manager allocates a global call identifier (GlobalCallID_callId) each
time that a Cisco Unified IP Phone is taken off hook or a call is received from a gateway. The
GlobalCallID_callId is allocated sequentially on a Cisco Unified Communications Manager server, independent
of calls running on other call servers in the cluster. Cisco Unified Communications Manager writes the
GlobalCallID_callId value to a disk file for every 1,000th call. When Cisco Unified Communications Manager
restarts for any reason, it assigns the next 1000th number to the next GlobalCallID_callId.
For example, when a successful call gets made, the GlobalCallID_callId value in the CDR specifies 1001.
For the next call, the GlobalCallID_callId value specifies 1002, and so on. When Cisco Unified Communications
Manager restarts, the value for the next call in the CDRgets assigned 2001. The numbers continue sequentially
from there until Cisco Unified Communications Manager restarts again. For the next restart, the
GlobalCallID_callId value specifies 3001.
The maximumvalue that gets assigned to the GlobalCallID_callId is limited to 24 bits. When this limitation
occurs, the GlobalCallID_callId value gets reset to 1.
Note
The GlobalCallID_callIds in the CDR file may not be in sequential order in the CDR flat file. If a call with
GlobalCallID_callId = 1 lasts longer than the call with GlobalCallID_callId = 2, then the CDR records for
GlobalCallId_callId = 2 are written before GlobalCallId_callId = 1. GlobalCallID_callIds may be completely
missing from the CDR flat file. If the first CDR record has GlobalCallID_callId = 1, and the second CDR has
GlobalCallID_callId = 3, that does not mean that the CDR for GlobalCallID_callId = 2 is missing.
GlobalCallID_callId = 2 did not meet the criteria to generate a CDR. The failure to generate a CDR can occur
because while the first and third call were successful, the second call was never completed; or,
GlobalCallID_callId = 2 could be part of a conference call. Each call leg in a conference call is assigned a
GlobalCallID_callId that is overwritten in the conference GlobalCallID_callId. The original GlobalCallID_callId
may not appear in the CDR flat file.
If the GlobalCallID_callId field is missing from the CDR record, CAR generates an error for that particular
record. Additional information on CDR errors is available in the Configuring CDR Error Reports chapter
of the CDR Analysis and Reporting Administration Guide.
10 OL-28260-01
Global call identifier
For Cisco Unified Communications Manager Release 5.x and later releases, the value in the GlobalCallId
CDR field survives over Cisco Unified Communications Manager restarts. In Release 4.x and earlier
releases, even though the GlobalCallId field is time-based, the field gets reused under conditions of heavy
traffic. Because of this behavior, problems can occur with customer billing applications and the ability of
CAR to correlate CMRs with CDRs and to correlate conference call CDRs. For Release 5.x and later
releases, GlobalCallId redesign ensures the field retains a unique value, at least for a certain number of
days. Now, the last used globalCallId_callId value gets written to disk periodically (for every x number
of calls). The value gets retrieved after a Cisco Unified Communications Manager restart, and the new
globalCallId_callId value begins with this number plus x.
Note
Number translations
The Cisco Unified Communications Manager can perform translations on the digits that a user dials. The
translated number, not the actual dialed digits, appears in the CDR.
For example, many companies translate 911 calls to 9-911, so the caller does not need to dial an outside
line in an emergency. In these cases, the CDR contains 9911 even though the user dials 911.
Gateways can perform further modifications to the number before the digits are actually output through
the gateway. The CDR does not reflect these modifications.
Note
Partitions and numbers
Within a CDR, a combination of extension number and partitions 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#.
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 the following table:
Table 1: Partition/Extension Numbers in CDRs
Description Phone Number
This party placed the call. For transferred calls, the transferred
party becomes the calling party.
callingPartyNumber
This number designates the originally called party, after any digit
translations have occurred.
originalCalledPartyNumber
OL-28260-01 11
Number translations
Description Phone Number
For forwarded calls, this number designates the last party to receive
the call.
For non-forwarded calls, this field shows the original called party.
finalCalledPartyNumber
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.
lastRedirectDn
This number identifies the partition name that is associated with
the CallingPartyNumber field. This field uniquely identifies this
number because the Cisco Unified Communications Manager
supports multiple Cisco Unified IP Phones with the same extension
number in different partitions.
For calls that ingress through a gateway, this field remains blank.
callingPartyNumberPartition
the OriginalCalledPartyNumber field. This field uniquely identifies
this number because the Cisco Unified Communications Manager
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.
originalCalledPartyNumberPartition
the FinalCalledPartyNumber field. This field uniquely identifies
this number because the Cisco Unified Communications Manager
to the gateway.
finalCalledPartyNumberPartition
the LastRedirectDn field. This field uniquely identifies this number
because the Cisco Unified Communications Manager supports
multiple Cisco Unified IP Phones with the same extension number
in different partitions.
to the gateway.
lastRedirectDnPartition
The calling party number outpulsed from the device. outpulsedCallingPartyNumber
The called party number outpulsed from the device. outpulsedCalledPartyNumber
12 OL-28260-01
Partitions and numbers
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 following table displays the UTC timestamps that get included in the CDR.
Table 2: UTC Timestamps in CDRs
Description Format Field
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.
This field always gets populated.
UTC dateTimeOrigination
This field designates the time that the devices connect.
This field shows a zero if the call never connects.
UTC dateTimeConnect
This field designates the time that the call disconnects. This field gets
set even if the call never connects. The time gets stored as UTC.
This field always gets populated.
UTC dateTimeDisconnect
Call clearing causes
The CDR includes two call clearing 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 cause code value shows zero.
Table 6: Call Termination Cause Codes, on page 153 lists the call clearing cause code values per ITU
specification Q.850. For On Net call legs, the Cisco Unified Communications Manager determines the cause
code value. For Off Net call legs, the far-end switch determines the cause code value.
Convert signed decimal value to IP address
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.
OL-28260-01 13
Timestamps
The file displays a negative number when the low byte of the IP address has the most significant bit set. Note
For example, the IP address 192.168.18.188 displays as -1139627840. To convert this IP address, perform
the following procedure:
Procedure
Step 1 Convert the database display (-1139627840) to a hex value.
The hex value equals 0xBC12A8C0.
Step 2 Reverse the 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
What to Do Next
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.
14 OL-28260-01
Convert signed decimal value to IP address
PAR T II
Call detail records
CDR Examples, page 17
Cisco call detail records field descriptions, page 121
Cisco call detail records codes, page 151
C HAP T E R 4
CDR Examples
This chapter provides examples of the call detail records (CDRs) that the Cisco Unified Communications
Manager Release system generates for all call types. You can use this information for post-processing
activities such as generating billing records and network analysis.
When you install your system, the system enables CDRs by default. You can enable or disable CDRs at any
time that the system is in operation. You do not need to restart Cisco Unified Communications Manager for
the change to take effect. The system responds to all changes within a few seconds.
AAC calls, page 17
AAC calls
Advanced Audio Coding-Low Delay (AAC-LD) is a super-wideband codec that provides excellent speech
and music quality at various bit rates. The audio quality scales up with the bit rate. Two mutually incompatible
RTP payload formats are supported: mpeg4-generic and MP4A-LATM.
For AAC-LD (mpeg4-generic) calls, the codec type (payload capability) value 42 is used.
For AAC-LD (MP4A-LATM) calls, a separate codec type value is used for each supported bit rate. The codec
type values are 43 (128K), 44 (64K), 45 (56K), 46 (48K), 47 (32K), and 48 (24K).
The system adds an audio bandwidth field to the CDR for AAC-LD calls.
Definitions Field Names
This integer field contains the audio bandwidth. origMediaCap_bandwidth
This integer field contains the audio bandwidth. destMediaCap_bandwidth
The system populates the bandwidth fields based on the following table:
Bandwidth Codec
64 G711Alaw64k
56 G711Alaw56k
OL-28260-01 17
Bandwidth Codec
64 G711mu-law64k
56 G711mu-law56k
64 G722 64k
56 G722 56k
48 G722 48k
7 G7231
16 G728
8 G729
8 G729AnnexA
0 Is11172AudioCap
0 Is13818AudioCap
8 G729AnnexB
8 G729AnnexAwAnnexB
13 GSM Full Rate
7 GSM Half Rate
13 GSM Enhanced Full Rate
256 Wideband 256K
64 Data 64k
56 Data 56k
32 G7221 32K
24 G7221 24K
256 AAC-LD (mpeg4-generic)
128 AAC-LD (MP4A-LATM) 128K
18 OL-28260-01
AAC calls
Bandwidth Codec
13 GSM
15 or 13 iLBC
32 iSAC
8 XV150 MR 729A
8 NSE VBD 729A
AAC-LD (mpeg4-generic) calls CDR example
This example applies to a call with AAC-LD (mpeg4-generic) codec:
AAC CDR Field Names
121 globalCallID_callId
101 origLegCallIdentifier
102 destLegCallIdentifier
51234 callingPartyNumber
57890 originalCalledPartyNumber
57890 finalCalledPartyNumber
57890 lastRedirectDn
0 origCause_Value
16 dest_CauseValue
42 origMediaCap_payloadCapability
256 origMediaCap_Bandwidth
42 destMediaCap_payloadCapability
OL-28260-01 19
AAC calls
AAC CDR Field Names
256 destMediaCap_Bandwidth
Related Topics
Cisco call detail records field descriptions, on page 121
Cisco call detail records codes, on page 151
Example Cisco call management records, on page 181
Abandoned calls
The logging of calls with zero duration represents an optional action. If logging calls with zero duration is
enabled, the following actions occur:
All calls generate a CDR.
If the call is abandoned, such as when a phone is taken off hook and placed back on hook, various fields
do not contain data. In this case, the originalCalledPartyNumber, finalCalledPartyNumber, the partitions
that are associated with them, the destIpAddr, and the dateTimeConnect fields all remain blank. All calls
that are not connected have a duration of 0 second. When a call is abandoned, the cause code contains
0.
If the user dials a directory number and abandons the call before it connects, the FirstDest and FinalDest
fields and their associated partitions contain the directory number and the partition to which the call
would have been extended. The DestIp field remains blank, and the duration specifies 0 second.
You must enable the CDR Log Calls With Zero Duration Flag service parameter to log calls with
zero duration. This parameter enables or disables the logging of CDRs for calls which lasted less than
1 second. See the Configuring CDR Service Parameters section in the CDR Analysis and Reporting
Administration Guide for more information.
Note
Examples of abandoned calls
1 Extension 2001 goes off hook, then on hook.
CDR Field Names
originalCalledPartyNumber
20 OL-28260-01
AAC calls
CDR Field Names
finalCalledPartyNumber
lastRedirectDn
16 origCause_Value
0 dest_CauseValue
0 duration
2 Extension 2001 calls 2309, but 2001 hangs up (abandons) the call before it is answered.
CDR Field Names
2309 lastRedirectDn
16 origCause_Value
0 dest_CauseValue
0 duration
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 CDRadds the ConfRequestorDNand ConfRequestorDeviceName tags to indicate add/drop of participants
of the conference by a non-controller of the conference.
OL-28260-01 21
AAC calls
The following scenarios show some of the various CDRs:
Related Topics
Conference linking using join, on page 22
Conference linking using transfer or Direct Transfer, on page 24
Linked conference party removal, on page 26
Linked conference party (controller) removal, on page 28
Linked conference removal, on page 31
Conference linking using join
The direction of the call between the bridges depends upon which of the two calls that involve Carol is primary.
The primary call survives, and the secondary call gets redirected to the conference.
Alice calls Bob, and Bob conferences in Carol (Conference 1). Dave calls Carol, and conferences in Ed
(Conference 2). Two separate conferences get created. Carol exists in both conferences. At this point, CDR1,
CDR2, CDR3, and CDR4 get generated.
Carol joins the two conferences. At this point, CDR5 gets generated.
When the remaining parties hang up, the remaining CDRs get generated in the order that the parties leave the
conference.
Conference linking using join example
CDR6: Dave ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Ed
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
3 3 4 3 2 1 globalCallID_callId
22 22 23 21 13 11 origLegCallIdentifier
26 25 24 22 14 12 destLegCallIdentifier
1003 1002 1003 1003 1001 1000 callingPartyNumber
b0029901222 b0029901222 1004 1002 1002 1001 originalCalledPartyNumber
b0029901222 b0029901222 1004 1002 1002 1001 finalCalledPartyNumber
1003 1003 1004 1002 1002 1001 lastRedirectDn
4 4 4 4 4 4 origTerminationOnBehalfOf
4 4 4 4 4 4 destTerminationOnBehalfOf
98 98 0 0 0 0 lastRedirectRedirectReason
4 4 0 0 0 0 lastRedirectRedirectOnBehalfOf
22 OL-28260-01
AAC calls
CDR6: Dave ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Ed
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
0 0 0 0 0 0 origConversationID
2222 2222 0 0 0 0 destConversationID
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
CDR11: Bob ->
Conference
Bridge
(conference
call)
CDR10: Alice ->
Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge
(conference
call)
CDR8: Ed ->
Conference
Bridge
(conference
call)
CDR7: Dave ->
Conference
Bridge
(conference
call)
Field Names
1 1 1 3 3 globalCallID_callId
12 11 17 24 21 origLegCallIdentifier
16 15 28 27 26 destLegCallIdentifier
1001 1000 b0029901001 1004 1003 callingPartyNumber
b0029901001 b0029901001 b0029901222 b0029901222 b0029901222 originalCalledPartyNumber
b0029901001 b0029901001 b0029901222 b0029901222 b0029901222 finalCalledPartyNumber
1001 1001 1002 1003 1003 lastRedirectDn
0 0 0 0 0 origTerminationOnBehalfOf
0 0 0 0 0 destTerminationOnBehalfOf
98 98 4 98 98 lastRedirectRedirectReason
4 4 10 4 4 lastRedirectRedirectOnBehalfOf
0 0 0 0 0 origConversationID
2222 2222 2222 2222 2222 destConversationID
OL-28260-01 23
AAC calls
CDR11: Bob ->
Conference
Bridge
(conference
call)
CDR10: Alice ->
Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge
(conference
call)
CDR8: Ed ->
Conference
Bridge
(conference
call)
CDR7: Dave ->
Conference
Bridge
(conference
call)
Field Names
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
Comment
Conference linking using transfer or Direct Transfer
Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol and conferences in Ed (Conference
2). Two separate conferences get created; Carol exists in both conferences. At this point, CDR1, CDR2, CDR3,
and CDR4 get generated.
Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob exist
in Conference 1 while Dave and Ed are in Conference 2. When the remaining parties hang up, the remaining
CDRs get generated in the order in which the parties leave the conference.
The direction of the call between the bridges depends on which of the two calls that involve Carol is the
primary call. The primary call side represents the calling party of the transferred call.
Note
Conference linking using transfer or Direct Transfer example
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
24 OL-28260-01
AAC calls
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
1003 1001 1004 1002 1002 1001 lastRedirectDn
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
CDR11: Bob ->
Conference
Bridge
(conference
call)
CDR10: Alice ->
Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge
(conference
call)
CDR8: Ed ->
Conference
Bridge
(conference
call)
CDR7: Dave ->
Conference
Bridge
(conference
call)
Field Names
1001 1000 b0029901001 1004 1003 callingPartyNumber
b0029901001 b0029901001 b0029901222 b0029901222 b0029901222 originalCalledPartyNumber
b0029901001 b0029901001 b0029901222 b0029901222 b0029901222 finalCalledPartyNumber
1001 1001 1002 1003 1003 lastRedirectDn
0 0 0 0 0 origTerminationOnBehalfOf
OL-28260-01 25
AAC calls
CDR11: Bob ->
Conference
Bridge
(conference
call)
CDR10: Alice ->
Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge
(conference
call)
CDR8: Ed ->
Conference
Bridge
(conference
call)
CDR7: Dave ->
Conference
Bridge
(conference
call)
Field Names
0 0 0 0 0 destTerminationOnBehalfOf
4 4 10 4 4 lastRedirectRedirectOnBehalfOf
0 0 111 0 0 origConversationID
1111 1111 2222 2222 2222 destConversationID
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
Comment
Linked conference party removal
CDRs get generated in the order in which the parties leave a conference. When the remaining conference only
has two parties, the two parties get joined directly together.
Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed
(Conference 2). Two separate conferences get created; Carol participates in both conferences. At this point,
CDR1, CDR2, CDR3, and CDR4 get generated.
in Conference 1 while Dave and Ed are in Conference 2. Conference 1 and Conference 2 get transferred
together. Carol hangs up and leaves only two parties in Conference 1.
Because only two parties exist in the conference, Bob and the conference link get joined together. At this
point, CDR7, CDR8, and CDR9 get generated. Because Bob is the controller in Conference 1, Bob represents
the calling party in the call between Bob and Conference 2. When the remaining parties hang up, the remaining
CDRs get generated in the order in which the parties leave the conference.
If Bob is not a controller and the chaining occurs before Bob joins Conference 1, the call between Bob
and Conference 2 gets generated in the opposite direction from what is shown in the CDRs.
Note
The direction of the call between the final two parties of a conference depends on who has been in the
conference the longest. The party that has been in the conference the longest becomes the calling party.
26 OL-28260-01
AAC calls
Removing a Party from a Linked Conference Example
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
1003 1001 1004 1002 1002 1001 lastRedirectDn
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
CDR12: Ed ->
Conference
Bridge
(conference
call)
CDR11: Dave
-> Conference
Bridge
(conference
call)
CDR10: Bob ->
Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge ->
Conference
Bridge
CDR8: Bob ->
Conference
Bridge
(conference
call)
CDR7: Alice ->
Conference
Bridge
(conference
call)
Field Names
OL-28260-01 27
AAC calls
CDR12: Ed ->
Conference
Bridge
(conference
call)
CDR11: Dave
-> Conference
Bridge
(conference
call)
CDR10: Bob ->
Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge ->
Conference
Bridge
CDR8: Bob ->
Conference
Bridge
(conference
call)
CDR7: Alice ->
Conference
Bridge
(conference
call)
Field Names
1003 1001 1000 b0029901222 1001 1001 callingPartyNumber
b0029901222 b0029901222 b0029901222 b0029901001 b0029901001 b0029901001 originalCalledPartyNumber
b0029901222 b0029901222 b0029901222 b0029901001 b0029901001 b0029901001 finalCalledPartyNumber
1003 1003 b0029901001 1002 1001 1001 lastRedirectDn
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
Linked conference party (controller) removal
CDRs get generated in the order in which the parties leave a conference. When the remaining conference only
has two parties, these two parties get joined directly together.
Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol and conferences in Ed (Conference
2). Two separate conferences get created; Carol participates in both conferences. At this point, CDR1, CDR2,
CDR3, and CDR4 get generated.
in Conference 1, while Dave and Ed are in Conference 2. Conference 1 and Conference 2 get transferred
together. Bob hangs up which leaves only two parties that are connected to Conference 1.
28 OL-28260-01
AAC calls
Because only two parties exist in Conference1, Alice and the conference link get joined directly together. At
this point, CDR7, CDR8, and CDR9 get generated. Because Alice has been in the conference longer, she
becomes the calling party in the call between Alice and Conference 2. When the remaining parties hang up,
the remaining CDRs get generated in the order in which the parties leave the conference.
The direction of a call between the final two parties of a conference depends on who has been in the
conference the longest. The party that has been in the conference the longest becomes the calling party.
Note
Removing a controller from a linked conference example
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
1003 1001 1004 1002 1002 1001 lastRedirectDn
OL-28260-01 29
AAC calls
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
CDR12: Ed ->
Conference
Bridge
(conference
call)
CDR11: Dave
-> Conference
Bridge
(conference
call)
CDR10: Alice
-> Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge ->
Conference
Bridge
CDR8: Alice ->
Conference
Bridge
(conference
call)
CDR7:
Conference
Bridge ->
Conference
Bridge
Field Names
1004 1003 1001 b0029901001 1000 1001 callingPartyNumber
b0029901222 b0029901222 b0029901222 b0029901001 b0029901001 b0029901001 finalCalledPartyNumber
1003 1003 b0029901001 1002 1001 1001 lastRedirectDn
30 OL-28260-01
AAC calls
CDR12: Ed ->
Conference
Bridge
(conference
call)
CDR11: Dave
-> Conference
Bridge
(conference
call)
CDR10: Alice
-> Conference
Bridge
(conference
call)
CDR9:
Conference
Bridge ->
Conference
Bridge
CDR8: Alice ->
Conference
Bridge
(conference
call)
CDR7:
Conference
Bridge ->
Conference
Bridge
Field Names
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
Linked conference removal
Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed
(Conference 2). Two separate conferences get created; Carol participates in both conferences. At this point,
CDR1, CDR2, CDR3, and CDR4 get generated.
in Conference 1, while Dave and Ed are in Conference 2. Conference 1 and Conference 2 get transferred
together.
Bob presses the ConfList softkey and has Alice, Bob, and the conference link Conference shown in the list.
Bob selects Conference and presses the Remove softkey. At this point, CDR7, CDR8, and CDR9 get
generated. The conference link gets removed, which leaves two parties in the conference.
The remaining two parties get joined together. In Conference 1, Alice and Bob get joined together, and in
Conference 2, Dave and Ed get joined together. When the remaining parties hang up, the remaining CDRs
get generated in the order in which the parties leave the conference.
Removing the linked conference example
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
OL-28260-01 31
AAC calls
CDR6: Carol ->
Conference
Bridge
(conference
call)
CDR5: Carol ->
Conference
Bridge
(conference
call)
CDR4: Dave ->
Carol
(consultation
call)
CDR3: Dave ->
Carol (original
call)
CDR2: Bob ->
Carol
(consultation
call)
CDR1: Alice ->
Bob (original
call)
Field Names
1003 1001 1004 1002 1002 1001 lastRedirectDn
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
Comment
CDR12: Bob->
Alice
CDR11: Ed ->
Conference
Bridge
(conference
call)
CDR10: Dave
-> Conference
Bridge
(conference
call)
CDR9: Bob ->
Conference
Bridge
CDR8: Alice ->
Conference
Bridge
(conference
call)
CDR7:
Conference
Bridge ->
Conference
Bridge
Field Names
1003 1004 1003 1001 1000 b0029901222 callingPartyNumber
1004 b0029901222 b0029901222 b0029901001 b0029901001 b0029901001 finalCalledPartyNumber
b0029901222 1003 1003 1001 1001 1002 lastRedirectDn
32 OL-28260-01
AAC calls
CDR12: Bob->
Alice
CDR11: Ed ->
Conference
Bridge
(conference
call)
CDR10: Dave
-> Conference
Bridge
(conference
call)
CDR9: Bob ->
Conference
Bridge
CDR8: Alice ->
Conference
Bridge
(conference
call)
CDR7:
Conference
Bridge ->
Conference
Bridge
Field Names
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
Comment
CDR13: Dave -> Ed Field Names
b0029901222 originalCalledPartyNumber
b0029901222 lastRedirectDn
0 origTerminationOnBehalfOf
0 destTerminationOnBehalfOf
98 lastRedirectRedirectReason
4 lastRedirectRedirectOnBehalfOf
0 origConversationID
OL-28260-01 33
AAC calls
CDR13: Dave -> Ed Field Names
0 destConversationID
ConfControllerDn=10
03;ConfControllerDe
viceName=SEP0003E33
3FAD1;ConfRequestor
Dn-1003;ConfRequest
orDeviceName=SEP000
3E333FAD1
Comment
Agent greeting calls
The Agent Greeting call feature instructs Cisco Unified Communications Manager to play a prerecorded
announcement to the customer automatically after successful media connection to the agent device occurs.
Both the agent and the customer hear the Agent Greeting.
Example of an agent greeting call
1 The customer (1001) calls the agent (1006).
2 The agent (1006) answers the call. The customer and the agent connect.
3 The Agent Greeting call feature instructs Cisco Unified Communications Manager to play a prerecorded
announcement to the customer automatically after successful media connection to the agent device occurs.
This causes an IVR (1000) to connect to the Built-In Bridge (BIB) of agent phone. Both the agent and the
customer hear the Agent Greeting.
4 The customer-agent call ends. ACDRgets generated for the customer-to-agent call. ACDRgets generated
for the IVR (1000) to BIB of agent phone.
The CDR for the IVR to agent BIB specifies the comment AgentGreeting=<agentCI>. The OnBehalfOf field
is set to 33 and redirectReason code is set to 752 for Agent Greeting call.
Call From IVR to Agent BIB Call From Customer to Agent Field Names
270002 270001 globalCallID_callId
22980861 22980857 origLegCallIdentifier
22980862 22980858 destLegCallIdentifier
1000 1001 callingPartyNumber
b00121104001 1006 originalCalledPartyNumber
b00121104001 1006 finalCalledPartyNumber
0 12 origCallTerminationOnBehalfOf
33 0 destCallTerminationOnBehalfOf
34 OL-28260-01
AAC calls
Call From IVR to Agent BIB Call From Customer to Agent Field Names
33 0 origCalledPartyRedirectOnBehalfOf
33 0 lastRedirectRedirectOnBehalfOf
752 0 origCalledPartyRedirectReason
752 0 lastRedirectRedirectReason
22980858 0 destConversationId
33 joinOnBehalfOf
AgentGreeting=22980858 comment
9 23 duration
Related Topics
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
reflect a value of Barge = 15, and the redirect reason fields specify Barge = 114.
Barge examples
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.
Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call
Identifier) of the barged call.
Note
Barge Call CDR Original Call CDR Field Names
OL-28260-01 35
AAC calls
Barge Call CDR Original Call CDR Field Names
b001501001 40001 origCalledPartyNumber
b001501001 40001 lastRedirectDn
0 16 origCause_Value
0 0 dest_CauseValue
15 origCalledPartyRedirectOnBehalfOf
15 joinOnBehalfOf
16777231 0 destConversationID
All the parties get conferenced together; then, 40001 hangs up.
Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call
Note
Final Call 2 CDR Barge Call 1 CDR Original Call CDR Field Names
9 9 9 globalCallID_callId
16777236 16777238 16777236 origLegCallIdentifier
16777238 16777241 16777237 destLegCallIdentifier
40003 40001 40003 callingPartyNumber
40001 b001501001 40001 origCalledPartyNumber
40001 b001501001 40001 finalCalledPartyNumber
40001 b001501001 40001 lastRedirectDn
16 393216 0 origCause_Value
36 OL-28260-01
AAC calls
0 393216 16 dest_CauseValue
0 114 0 origCalledPartyRedirectReason
0 114 0 lastRedirectRedirectReason
12 15 origTerminationOnBehalfOf
12 15 12 destTerminationOnBehalfOf
15 joinOnBehalfOf
0 16777237 0 destConversationID
All the parties get conferenced together; then, 40001' (another shared line and phone) presses the Barge
softkey. 40003 hangs up first.
All CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call
Note
b001501001 b001501001 40001 origCalledPartyNumber
b001501001 b001501001 40001 finalCalledPartyNumber
b001501001 b001501001 40001 lastRedirectDn
OL-28260-01 37
AAC calls
15 15 12 origTerminationOnBehalfOf
destTerminationOnBehalfOf
15 15 origRedirectRedirectOnBehalfOf
15 15 joinOnBehalfOf
16777251 16777250 0 destConversationID
Related Topics
Call monitoring
The system generates CDRs for the Call Monitoring feature by using existing CDR fields.
The monitoring calls have one-way media. The media fields stay empty for one side of the call for one-way
media CDRs.
The destConversationID field of the Call Monitoring CDR matches the agent call leg identifier in the CDR
of the call that is monitored and links together the Call Monitoring CDR and the CDR of the monitored call.
Call monitoring examples
1 The customer (9728134987) calls the agent (30000), and the agent answers. The supervisor (40003)
monitors the call. The destConversationID from the monitoring call matches the destLegCallIdentifier of
the monitored call.
Monitoring Call CDR Monitored Call CDR Field Names
38 OL-28260-01
AAC calls
0 0 dest_CauseValue
2 The agent (30000) calls the customer (9728134987), and the customer answers. The supervisor (40003)
monitors the call. The destConversationID from the monitoring call matches the origLegCallIdentifier of
the monitored call.
0 0 dest_CauseValue
OL-28260-01 39
AAC calls
Related Topics
Call park
Call Park generates two CDRs, one for the original call that gets parked and another for the call that gets
picked up or reverted. These CDRs will have the same globalCallID_callId.
Related Topics
Call park pickup, on page 40
Call park reversion, on page 41
Call park pickup
When the call is parked, the call gets split. The original call generates a CDR. The
origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR.
When the parked call gets retrieved, the user goes off hook and enters the park code. This call joins with the
parked call. Because the user who is picking up the call gets joined with the parked call, the system treats the
user as the originator of the call, and the parked user gets treated as the destination. This means that the
callingPartyNumber field of the call contains the directory number of the user who is picking up the call,
and the originalCalledNumber and finalCalledNumber fields contain the directory number of the parked
user. The lastRedirectDn field contains the park code that is used to pick up the call. The
lastRedirectRedirectReason field specifies Call Park Pickup = 8. The lastRedirectRedirectOnBehalfOf
field should specify Call Park = 3.
Call park pickup CDR example
50003 calls 50002; 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code
(44444).
Parked Call That Is Picked Up
CDR
Original Call That Is Parked
CDR
Field Names
40 OL-28260-01
AAC calls
Parked Call That Is Picked Up
CDR
Original Call That Is Parked
CDR
Field Names
50003 50002 originalCalledPartyNumber
50003 50002 finalCalledPartyNumber
44444 50002 lastRedirectDn
16 393216 dest_CauseValue
12 3 destTerminationOnBehalfOf
3 0 joinOnBehalfOf
60 4 duration
Call park reversion
When a call is parked and not picked up, the call park reversion timer expires and redirects 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 CDRdiffers slightly. When the Call Pickup Reversion timer expires,
the call gets redirected to the called party.
When the call is parked, the call gets split. This action generates a CDR for the original call. The
origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR,
the same as the Call Park Pickup scenario.
When the Call Park Reversion timer expires, the call gets redirected to the called party. The
origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields specify Call Park = 3.
The origCalledPartyRedirectReason field specifies Call Park = 7, and the lastRedirectRedirectReason
field specifies Call Park Reversion = 11.
OL-28260-01 41
AAC calls
Call park reversion CDR example
Call Park Reversion Example 50003 calls 50002; 50002 presses the Park softkey. Nobody picks up
the parked call; the parked call reverts to 50002, and 50002 answers.
Reverted Call CDR Original Call That Is Parked
CDR
Field Names
3 0 joinOnBehalfOf
60 7 duration
Call pickup
There are two types of call pickup in Cisco Unified Communications Manager: Pickup and Auto Pickup. The
CDR records appear slightly different for these two types of call pickup.
Related Topics
Pickup, on page 43
42 OL-28260-01
AAC calls
Auto pickup, on page 43
Pickup
Pickup CDR example
A call comes in from the PSTN to extensions 2000, 2001, and 2002. These extensions reside in the same
pickup group. Extension 2002 picks up the call that is ringing on 2001. Extension 2002 answers the call, and
the call connects between the PSTN caller and extension 2002.
Pickup Call CDR Field Names
2001 lastRedirectDn
0 origCause_Value
16 dest_CauseValue
16 lastRedirectOnBehalfOf
5 lastRedirectReason
16 joinOnBehalfOf
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 CDRs have the same Call
ID.
The first CDRgets generated for the original call. This CDRwill have the origTerminationOnBehalfOf
and destTerminationOnBehalfOf fields equal to 16 (Pickup). This value indicates that the call got
terminated on behalf of the Pickup feature.
OL-28260-01 43
AAC calls
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 value indicates that
the call was joined 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.
When the Service Parameter Auto Call Pickup Enabled is set to True for an IP Phone and a Cisco Unified
Communications Manager receives an incoming call that the IP phone picks up, the prefix digit defined
in the Translation Pattern is added to the callingPartyNumber in CDR. However, the prefix digit is not
added when the Service Parameter Auto Call Pickup Enabled is set to False.
Note
Auto pickup CDR example
Auto Pickup Example - Call goes from the PSTN to extension 2001; 2001 and 2002 exist in the same
pickup group. 2002 picks up the call that rings on 2001; the call automatically connects between the
PSTN caller and 2002. They talk for 2 minutes.
The prefix digits defined in the Translation Pattern only applies to basic call. Note
Pickup CDR Original Call CDR Field Names
44 OL-28260-01
AAC calls
Pickup CDR Original Call CDR Field Names
16 0 joinOnBehalfOf
120 0 duration
Call recording
The system generates CDRs for the Call Recording feature by using existing CDR fields.
The recording calls have one-way media. The media fields stay empty for one side of the call for one-way
media CDRs.
The origConversationID field of the two Call Recording CDRs matches the agent call leg identifier in the
Recording Call CDR and links together the Call Recording CDR and the CDR of the recorded call.
Call recording CDR examples
1 The customer (9728134987) calls the agent (30000), and the agent answers. The Recorder's DN is 90000.
The recording feature creates two recording calls to the recording device, which results in two additional
CDRs: one for the agent voice, and another for the customer voice. The origConversationID from the
recording CDRs matches the destLegCallIdentifier of the recorded CDR. In this scenario, the customer
hangs up.
0 0 dest_CauseValue
OL-28260-01 45
AAC calls
16777111 0 origConversationID
2 The agent (30000) calls the customer (9728134987), and the customer answers. The Recorder's DN is
90000. The recording feature creates two recording calls to the recording device, which results in two
additional CDRs: one for the agent voice, and another for the customer voice. The origConversationID
field from the recording CDRs will match the origLegCallIdentifier field of the recorded CDR. In this
scenario, the agent hangs up.
0 0 dest_CauseValue
16777113 0 origConversationID
Related Topics
46 OL-28260-01
AAC calls
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, and later the call changes to secured, the CDR contains
1 for Secured even though different portions of the call have different status values. The callSecuredStatus
field identifies the security status of the call.
Call secured status CDR examples
1 Encrypted Call - The system encrypts the call between 20000 and 20001. The parties talk for 5 minutes.
CDR Field Names
20001 origCalledPartyNumber
0 origCause_Value
16 dest_CauseValue
2 callSecuredStatus
300 duration
2 Authenticated Call - The call between 20000 and 20001 gets authenticated (not encrypted). The parties
talk for 10 minutes.
CDR Field Names
OL-28260-01 47
AAC calls
CDR Field Names
0 origCause_Value
16 dest_CauseValue
1 callSecuredStatus
600 duration
Related Topics
Calling party normalization
This feature provides the support of the international escape code "+" to Cisco Unified Communications
Manager. This addition enhances the dialing capabilities of dual-mode phones and improves callbacks for
companies in different geographical locations.
The callingPartyNumber, originalCalledPartyNumber, finalCalledPartyNumber, lastRedirectDNfields,
and the new fields, outpulsedCallingPartyNumber and outpulsedCalledPartyNumber, may now contain
a "+" in the CDR. The device reports the Calling Party Number that it outpulsed back to Call Control only if
calling party normalization/localization takes place. If calling party normalization/localization occurs, the
action gets recorded in the CDR in the new field outpulsedCallingPartyNumber.
Calling party normalization CDR examples
1 A call gets placed from a Dallas PSTN to an enterprise phone. The 7-digit calling number comprises
500 1212; the Dallas area code displays 972. The calling party transformation contains +1972. The
callingPartyNumber field in the CDR contains +1 972 500 1212 (global format). The new field
outpulsedCallingPartyNumber contains the localized number 500 1212.
Values Field Names
48 OL-28260-01
AAC calls
Values Field Names
+19725001212 callingPartyNumber
5001212 outpulsedCallingPartyNumber
60 duration
1 A call gets placed from an enterprise phone to a Dallas PSTN. The extension of the enterprise phone
comprises 12345; the fully qualified number comprises 9725002345. Calling party transformation checks
the external phone number mask feature. The callingPartyNumber field in the CDR contains +1 972 500
2345 (global format). The new field outpulsedCallingPartyNumber contains the localized number
9725002345.
Values Field Names
+19725002345 callingPartyNumber
9725002345 outpulsedCallingPartyNumber
60 duration
Related Topics
Calls with busy or bad destinations
The systemlogs all these calls as normal calls, and all relevant fields contain data. The Calling or Called Party
Cause fields contain a cause code that indicates why the call does not connect, and the Called Party IP and
Date/Time Connect fields remain blank. The system logs all unsuccessful calls, even if zero duration calls
are not being logged (CdrLogCallsWithZeroDurationFlag set at True or False, a duration of zero, and a
DateTimeConnect value of zero).
Examples of unsuccessful calls CDRs
1 Call goes to PSTN number, but party already is engaged (cause 17 = user busy)
OL-28260-01 49
AAC calls
CDR Field Names
0 origCause_Value
17 dest_CauseValue
0 duration
2 Call goes to PSTN number, but number does not exist (cause 1 = number unavailable)
CDR Field Names
1 origCause_Value
0 dest_CauseValue
0 duration
3 Call to PSTN fails because PSTN trunks are out of order (cause 38 = Network Out Of Order).
CDR Field Names
50 OL-28260-01
AAC calls
CDR Field Names
0 origCause_Value
38 dest_CauseValue
0 duration
Related Topics
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 CDR example
40003 calls 40001, and 40001 answers; 40001' (shared line) on another phone presses the cBarge button.
Final Call CDR cBarge Call CDR
3
cBarge Call CDR
2
cBarge Call CDR
1
Orig Call CDR Field Names
40001 40003 40001 40001 40003 callingPartyNumber
40003 b0029901001 b0029901001 b0029901001 40001 originalCalledPartyNumber
40003 b0029901001 b0029901001 b0029901001 40001 finalCalledPartyNumber
b0029901001 40001 40001 b0029901001 40001 lastRedirectDn
16 393216 393216 16 393216 origCause_Value
0 393216 393216 0 393216 dest_CauseValue
OL-28260-01 51
AAC calls
Final Call CDR cBarge Call CDR
3
cBarge Call CDR
2
cBarge Call CDR
1
0 98 98 98 0 origCalledPartyRedirectReason
4 4 4 4 destTerminationOnBehalfOf
4 4 4 origCalledRedirectOnBehalfOf
4 4 4 4 lastRedirectRedirectOnBehalfOf
4 4 4 4 joinOnBehalfOf
1 16777220 16777220 16777220 0 Conversation ID
360 360 360 60 duration
Comment
Orig Call CDR
ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD cBarge Call CDR 1
ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD Final Call CDR
Related Topics
Client matter code (CMC)
When the CMC feature gets invoked, the system writes the client matter code into the CDR. The
clientMatterCode field contains the client matter code that the caller enters.
CMC CDR example
10000 calls 2142364624; the user gets prompted for a client matter code and enters 11111. The caller answers
the call and talks for 10 minutes.
52 OL-28260-01
AAC calls
Values Field Names
0 origCause_Value
16 dest_CauseValue
11111 clientMatterCode
600 duration
Related Topics
Conference calls
Multiple records get logged for calls that are part of a conference. The number of CDR records that get
generated depends on the number of parties in the conference. One CDRexists for each party in the conference;
one CDR for the original placed call, one CDR for each setup call that get used to join other parties to the
conference, and one CDR for the last two parties that get connected in the conference. For a three-party, ad
hoc conference, six CDRs exist: one CDR for the original call, three CDRs for the parties that get connected
to the conference, one CDR for each setup call, and one CDR for the final two parties in the conference. You
can associate the setup calls with the correct call leg in the conference by examining the calling leg ID and
called leg ID.
The conference bridge device represents special significance to the Cisco Unified Communications Manager,
and calls to the conference bridge appear as calls to the conference bridge device. A special number in the
form b0019901001 shows the conference bridge port. Records show all calls into the conference bridge,
regardless of the actual direction; however, by examining the setup call CDRs, you can determine the original
direction of each call.
You can find the conference controller information in the comment field of the CDR. The format of this
information follows:
OL-28260-01 53
AAC calls
Comment field = ConfControllerDn=1000;ConfControllerDeviceName=SEP0003
The conference controller DN + conference controller device name uniquely identify the conference
controller. The system needs the device name in the case of shared lines.
If the call is involved in multiple conference calls, the comment field contains multiple conference
controller information. This situation can 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.
The call legs that are connected to the conference include the following information fields:
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 have the following
characteristics:
The origCallTerminationOnBehalfOf field gets set to Conference = 4.
The destCallTerminationOnBehalfOf field gets set to Conference = 4.
Conference call CDR example
Call goes 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.
Each conference call leg gets shown as placing a call into the conference bridge. The system shows the
call as a call into the bridge, regardless of the actual direction of the call.
Note
Final CDR Conference
CDR 3
Conference
CDR 2
Conference
CDR 1
Setup Call
CDR
54 OL-28260-01
AAC calls
CDR 3
Conference
CDR 2
Conference
CDR 1
Setup Call
CDR
2309 b0029901001 b0029901001 b0029901001 3071111 2309 originalCalledPartyNumber
2309 b0029901001 b0029901001 b0029901001 3071111 2301 finalCalledPartyNumber
b0029901001 b0029901001 b0029901001 b0029901001 3071111 2001 lastRedirectDn
16 393216 393216 16 0 393216 origCause_Value
0 393216 393216 393216 0 393216 dest_CauseValue
0 0 0 0 0 0 origCalledPartyRedirectReason
0 4 4 4 0 0 origCalledRedirectOnBehalfOf
4 4 4 4 0 0 joinOnBehalfOf
0 1 1 1 0 0 Conversation ID
55 360 360 360 20 60 duration
Comment
Orig Call CDR
ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD Setup Call CDR
ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD Conference CDR 1
OL-28260-01 55
AAC calls
Comment
Final CDR
Related Topics
Operational factors
Three major operational factors exist for conference call CDRs:
1 When a conference decreases to two parties, the two parties connect directly and release the conference
resource. This change generates an additional CDRfor the call between the last two parties in the conference
call.
For example, if four people connect in a conference call (Amy, Dustin, Spencer, Ethan), when Ethan hangs
up, three people remain in the conference call that is connected to the conference bridge (Amy, Dustin,
Spencer). When Spencer hangs up, only two people remain in the conference call (Amy and Dustin). The
system joins Amy and Dustin directly, and, the conference resource gets released. Directly joining Amy
and Dustin creates an additional CDR between the last two parties in the conference.
2 The system adds the conference controller information to the comment field in the CDR. This information
identifies the conference controller. No need now exists to examine the consultation call to determine who
is the conference controller. The following example shows this information:
Comment field = ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD
The conference controller DN + conference controller device name uniquely identify the conference
controller. A need for the device name exists in the case of shared lines.
If the call is involved in multiple conference calls, the comment field contains multiple conference
controller information. This situation may occur when the conference goes down to two parties, and
one of these parties starts another conference. If this is the case, the last conference controller
information in the comment field identifies the conference controller.
3 The party that added the participant, known as the requestor party, appears in the CDR comment field.
The tags for the requestor information include ConfRequestorDn and ConfRequestorDeviceName. The
party that requested to remove a participant, known as the drop requestor, appears in the CDR comment
field. The tags for the drop requestor information include DropConfRequestorDn and
DropConRequestorDeviceName.
Calls that are part of a conference have multiple records that are logged for them. The number of CDRs that
get 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.
56 OL-28260-01
AAC calls
One CDR for each setup call.
One CDR for the final two parties in the conference.
You can associate the setup calls with the correct call leg in the conference by examining the calling leg ID
and the called leg ID.
The conference bridge device holds special significance to the Cisco Unified Communications Manager. Calls
to the conference bridge appear as calls to the conference bridge device. A special number in the form
b0019901001 shows the conference bridge port. All calls get shown into the conference bridge, regardless
of the actual direction. You can determine the original direction of each call by examining the setup call CDRs.
The call legs that are connected to the conference have the following values for these fields:
finalCalledPartyNumberRepresents a conference bridge b0019901001.
origCalledPartyRedirectOnBehalfOfSet to Conference (4).
lastRedirectRedirectOnBehalfOfSet to Conference (4).
joinOnBehalfOfSet to Conference (4).
commentIdentifies the conference controller.
The original placed call and all setup calls that get used to join parties to the conference have the following
values for the fields:
origCallTerminationOnBehalfOfSet to Conference (4).
destCallTerminationOnBehalfOfSet to Conference (4).
Conference drop any party
The Conference Drop Any Party feature terminates calls that look the same as other calls except for a new
cause code. The cause code identifies the calls that this feature terminates.
Conference drop any party CDR example
The following table contains an example CDR for a call that connects to a conference and gets dropped by
this feature.
Last Redirect
Party
Final Called
Partition
Final Called
Party
Dest
Cause
Called
Leg
Original
Called
Partition
Orig
Cause
Original
Called Party
Calling
Partition
Calling
Party
2001 MKTG 2309 16 102 MKTG 0 2309 ACNTS 2001
b0029901001 b0029901001 0 115 MKTG 16 2309 ACNTS 2001
b0029901001 b0029901001 128 116 0 b0029901001 ACNTS 2309
b0029901001 b0029901001 0 117 16 b0029901001 PSTN 3071111
30711111 PSTN 3071111 0 106 PSTN 16 2309 ACNTS 2001
OL-28260-01 57
AAC calls
Duration Join
OnBehalfOf
LastRedirect
Redirect
OnBehalfOf
OriginalCalled
Pty Redirect
OnBehalfOf
DestCall
Termination
OnBehalfOf
OrigCall
Termination
OnBehalfOf
Orig
Conversation
ID
60 0 0 0 4 4 0
360 4 4 4 0 12 1
200 4 4 4 0 13 1
360 4 4 4 4 4 1
20 0 0 0 4 4 0
Related Topics
Original calling party on transfer
This feature changes the calling party number for a consultation call of a Cisco Unity or Cisco Unity
Connection-initiated call transfer. The CDR of the consultation call shows that the original caller calls the
transfer destination, not that the Cisco Unity or Cisco Unity Connection port calls the transfer destination.
You must configure this feature in the service parameters in Cisco Unified Communications Manager. See
additional information in the Configuring CDRService Parameters section of the CDRAnalysis and Reporting
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).
originalCalledPartyNumber CallingPartyNumber Call
4002 4001 1
4003 4002 2
4003 4001 3
58 OL-28260-01
AAC calls
No originalCallingParty field exists in the CDR. Note
DTMF method
These fields identify the Dual Tone Multi-Frequency (DTMF) method that gets used for the call.
DTMF CDR examples
1 No Preference Example - The DTMF method that gets used during this call represents No Preference/Best
Effort. This call connects for 1 minute.
CDR Field Names
0 origCause_Value
16 dest_CauseValue
0 origDTMFMethod
0 destDTMFMethod
60 duration
1 Preferred OOB Example - The DTMF method that is used during this call represents OOB Preferred.
This call remains connected for 1 minute.
CDR Field Names
OL-28260-01 59
AAC calls
CDR Field Names
0 origCause_Value
16 dest_CauseValue
1 origDTMFMethod
1 destDTMFMethod
60 duration
Related Topics
End-to-End Call Trace
The End-to-End Call Trace feature facilitates tracing calls that traverse multiple Cisco voice products, such
as Unified CM, Cisco IOS Gateways, and other products.
End-toEnd Call Trace example
1 H323 - Calling party 1003 calls 1004 via H.323 trunk.
Values FieldNames
1 cdrRecordType
1 globalCallID_callManagerId
1221263718 dateTimeOrigination
1 origNodeId
60 OL-28260-01
AAC calls
Values FieldNames
0 origSpan
1897990154 origIpAddr
16 origCause_value
4 origPrecedenceLevel
1897990154 origMediaTransportAddress_IP
19824 origMediaTransportAddress_Port
20 origMediaCap_maxFramesPerPacket
19654114 destLegIdentifier
1 destNodeId
19654114 destSpan
424630538 destIpAddr
0 destCause_value
4 destPrecedenceLevel
-1759442934 destMediaTransportAddress_IP
27508 destMediaTransportAddress_Port
20 destMediaCap_maxFramesPerPacket
1221263720 dateTimeConnect
1221263721 dateTimeDisconnect
1003 lastRedirectDn
OL-28260-01 61
AAC calls
Values FieldNames
c8868f84-0f4e-452c-a814-bf97a7fe69fc Pkid
1 Duration
SEP003094C2B08C origDeviceName
self-loop destDeviceName
12 origCallTerminationOnBehalfOf
0 destCallTerminationOnBehalfOf
3 origDTMFMethod
4 destDTMFMethod
10.8.33.113 origIpv4v6Addr
10.8.33.151 destIpv4v6Addr
0 IncomingProtocolID
IncomingProtocolCallRef
2 OutgoingProtocolID
0053C43F6701B18C030004010A082171 OutgoingProtocolCallRef
2 Q931 - 1004 calls 1003 via Q931.
Values FieldNames
1 cdrRecordType
1 globalCallID_callManagerId
1221263350 dateTimeOrigination
1 origNodeId
62 OL-28260-01
AAC calls
Values FieldNames
2 origSpan
0 origCause_value
20 origMediaCap_maxFramesPerPacket
19654112 destLegIdentifier
1 destNodeId
0 destSpan
-1759442934 destIpAddr
16 destCause_value
20 destMediaCap_maxFramesPerPacket
1221263351 dateTimeConnect
1221263352 dateTimeDisconnect
1003 lastRedirectDn
OL-28260-01 63
AAC calls
Values FieldNames
b576bd8d-9703-4f66-ae45-64ae5c04738e Pkid
1 Duration
BRI/S1/SU0/P1@nw052b-3640.cisco.com origDeviceName
SEP003094C2D263 destDeviceName
0 origCallTerminationOnBehalfOf
12 destCallTerminationOnBehalfOf
1 origDTMFMethod
3 destDTMFMethod
4 IncomingProtocolID
01-1004-1003 IncomingProtocolCallRef
0 OutgoingProtocolID
OutgoingProtocolCallRef
Related Topics
Forced authorization code (FAC)
When the FAC feature gets invoked, the system writes the authorization description and level into the CDR.
For security reasons, the actual authorization code does not get written to the CDR.
The authCodeDescription field contains the description of the authorization code.
The authorizationLevel field contains the level of authorization that is associated with the authorization
code.
64 OL-28260-01
AAC calls
FAC CDR example
45000 calls 9728134987; the system prompts the user for an authorization code and enters 12345. FAC code
12345 gets configured as level 1 and name Legal1. The caller answers the call and talks for 2 minutes.
Values Field Names
0 origCause_Value
16 dest_CauseValue
Legal1 authCodeDescription
1 authorizationLevel
120 duration
Related Topics
Forwarded or redirected calls
Forwarded calls generate a single CDRand showthe Calling Party, Original Called Number, Last Redirecting
Number, Final Called Number, and the associated partitions. If the call gets forwarded more than twice, the
intermediate forwarding parties do not populate in the CDR.
Call forwarding can occur on several conditions (always, busy, and no answer). The condition under which
the call gets 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.
OL-28260-01 65
AAC calls
Also, when a call gets forwarded, the lastRedirectDn and lastRedirectDnPartition fields contain the directory
number and partition of the last phone that forwarded or redirected the call.
Call Forwarding uses the redirect call primitive to forward the call. Features that use the redirect call primitive
have similar CDRs. Some of the important CDR fields for forwarded calls follow:
The originalCalledPartyNumber contains the number of the original called party.
The finalCalledPartyNumber represents the number that answered the call.
The lastRedirectDn field specifies the number that performed the last redirect.
The origCalledPartyRedirectReason represents the reason that the call was redirected the first time.
For call forwarding, this field can contain Call Forward Busy=1, Call Forward No Answer=2, Call
Forward All=15.
The lastRedirectRedirectReason specifies the reason that the call was redirected the last time. For call
forwarding, this field can contain Call Forward Busy=1, Call Forward No Answer=2, Call Forward
All=15.
The origCalledPartyRedirectOnBehalfOf field identifies which feature redirects the call for the first
redirect. For call forwarding, this field specifies 5 (Call Forward).
The lastRedirectRedirectOnBehalfOf field identifies which feature redirects the call for the last redirect.
For call forwarding, this field specifies 5 (Call Forward).
Forwarded calls CDR examples
1 CFA - 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.
CDR Field Names
2001 lastRedirectDn
0 origCause_Value
16 dest_CauseValue
15 origCalledPartyRedirectReason
66 OL-28260-01
AAC calls
CDR Field Names
120 duration
2 Multiple Hop CFA & CFNA - Call comes in from the PSTN to extension 1000; the call gets forwarded
(CFA) to 2000; then, the call gets forwarded (CFNA) to the voice-messaging system (6000) where the
caller leaves a message.
CDR Field Names
2000 lastRedirectDn
0 origCause_Value
16 dest_CauseValue
15 duration
3 Multiple Hop CFNA & CFB - 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.
CDR Field Names
OL-28260-01 67
AAC calls
CDR Field Names
5555 lastRedirectDn
16 origCause_Value
0 dest_CauseValue
30 duration
Related Topics
Hunt list support
Hunt list examples
1 Answered Calls - In this example, calls go to a hunt list and a member of the hunt list answers the call.
Cisco Unified IP Phones 3001, 3002, 3003 and 3004 are part of the hunt list. The display names for
the phones are 3001-Name, 3002-Name, 3003-Name and 3004-Name, respectively.
Hunt Pilot 2000 is associated with a hunt list. Hunt pilot 2000 is configured with display name as
2000-Name.
Phone 1000 calls hunt pilot 2000; call is offered at 3001 and answered.
68 OL-28260-01
AAC calls
When the service parameter, Show Line Group Member DN in finalCalledPartyNumber CDR Field, is set
to True, the following values from the table display in the CDR.
CDR Field Names
Phone 1000 origDeviceName
Phone 3001 destDeviceName
2000 huntPilotDN
huntPilotPartition
When the service parameter, Show Line Group Member DN in finalCalledPartyNumber CDR Field, is set
to False, the following values in the table display in the CDR.
CDR Field Names
2000 huntPilotDN
huntPilotPartition
OL-28260-01 69
AAC calls
1 Abandoned or Failed Calls - In this example, calls go to a hunt list and a member of the hunt list abandons
or fails the call.
Cisco Unified IP Phones 3001, 3002, 3003 and 3004 are part of the hunt list.
Hunt Pilot 2000 is associated with a hunt list.
Phone 1000 calls hunt pilot 2000; call is offered at 3001 and abandoned. When the service parameter,
ShowLine Group Member DN, in finalCalledPartyNumber CDRfield is set to True, the following
values from the table display in the CDR:
CDR Field Names
huntPilotDN
huntPilotPartition
7 calledPartyPatternUsage
Because the call does not get answered, the huntPilotDN is not available in the CDR. The PatternUsage (7
= PATTERN_HUNT_PILOT) field gets set to 7 to indicate that the call was made to a hunt pilot. When the
service parameter is enabled, the finalCalledPartyNumber field denotes the member hunt DN and the
originalCalledPartyNumber field denotes the huntPilot DN.
When the service parameter, Show Line Group Member DN, in the finalCalledPartyNumber CDR field is
set to False, the following values in the table display in the CDR:
CDR Field Names
70 OL-28260-01
AAC calls
CDR Field Names
huntPilotDN
huntPilotPartition
7 calledPartyPatternUsage
Because the call is not answered, the huntPilotDN is not available in the CDR. The PatternUsage (7 =
PATTERN_HUNT_PILOT) field gets set to 7 to indicate that the call was made to a hunt pilot. When the
service parameter is not enabled, the finalCalledPartyNumber field denotes the member hunt DN.
H.239
Cisco Unified Communications Manager supports H.239. This feature defines the procedures for use of up
to two video channels in H.320-based systems and for labeling individual channels with a role of presentation
or live. This procedure indicates the requirements for processing the channel and the role of the channel
content in the call. Role labels apply to both H.320 and H.245 signaling-based systems.
Several new CDR fields support a second video channel for both the origination and destination devices. This
CDR provides an example of these new fields.
H.239 CDR example
When A and B declare H.239 capability in Terminal Capability Set (TCS) and one, or both, of the endpoints
initiates the receiving channel to have an extended video channel in an H.239 mechanism for presentation or
video feed, the new CDR fields display in the CDR in addition to the existing fields of a video call.
Calling party 51234 calls the called party 57890. Let 103 represent H.264, 187962284 represents 172.19.52.11,
288625580 represents 172.19.52.17, and 352 represents 352K.
CDR Field Names
OL-28260-01 71
AAC calls
CDR Field Names
0 origCause_Value
16 destCause_Value
103 origVideoCap_Codec
352 origVideoCap_Bandwidth
0 origVideoCap_Resolution
187962284 origVideoTransportAddress_IP
2406 origVideoTransportAddress_Port
103 destVideoCap_Codec
352 destVideoCap_Bandwidth
0 destVideoCap_Resolution
288625580 destVideoTransportAddress_IP
2328 destVideoTransportAddress_Port
103 origVideoCap_Codec_Channel2
352 origVideoCap_Bandwidth_Channel2
0 origVideoCap_Resolution_Channel2
187962284 origVideoTransportAddress_IP_Channel2
2410 origVideoTransportAddress_Port_Channel2
0 origVideoChannel_Role_Channel2
103 destVideoCap_Codec_Channel2
352 destVideoCap_Bandwidth_Channel2
0 destVideoCap_Resolution_Channel2
72 OL-28260-01
AAC calls
CDR Field Names
288625580 destVideoTransportAddress_IP_Channel2
2330 destVideoTransportAddress_Port_Channel2
0 destVideoChannel_Role_Channel2
Related Topics
CDR field descriptions, on page 121
iLBC calls
Internet Low Bit Rate Codec (iLBC) enables graceful speech quality degradation in a lossy network where
frames get lost. For iLBC calls, the codec specifies Media_Payload_ILBC = 86.
The system adds an audio bandwidth field to the CDR for iLBC calls.
Definitions Field Names
This integer field contains the audio bandwidth. origMediaCap_bandwidth
This integer field contains the audio bandwidth. destMediaCap_bandwidth
The system populates the bandwidth fields based on the following table:
Bandwidth Codec
64 G711Alaw64k
56 G711Alaw56k
64 G711mu-law64k
56 G711mu-law56k
64 G722 64k
56 G722 56k
48 G722 48k
7 G7231
16 G728
OL-28260-01 73
AAC calls
Bandwidth Codec
8 G729
8 G729AnnexA
0 Is11172AudioCap
0 Is13818AudioCap
8 G729AnnexB
8 G729AnnexAwAnnexB
13 GSM Full Rate
7 GSM Half Rate
13 GSM Enhanced Full Rate
256 Wideband 256K
64 Data 64k
56 Data 56k
32 G7221 32K
24 G7221 24K
256 AAC-LD (mpeg4-generic)
13 GSM
15 or 13 iLBC
32 iSAC
74 OL-28260-01
AAC calls
Bandwidth Codec
8 XV150 MR 729A
8 NSE VBD 729A
iLBC call CDR example
This example applies to a call with iLBC codec.
iLBC CDR Field Names
0 origCause_Value
16 dest_CauseValue
Related Topics
Immediate divert (to voice-messaging system)
Immediate Divert (IDivert) gets invoked in three different call states:
OL-28260-01 75
AAC calls
You can invoke the IDivert feature while the incoming call is ringing. The CDR for the ringing case
acts very similar to call forwarding, but the origCalledPartyRedirectOnBehalfOf and the
lastRedirectRedirectOnBehalfOf fields specify Immediate Divert = 14.
You can invoke the IDivert feature while the call is connected or on hold. These scenarios generate two
CDRs. Both CDRs have the same globalCallID_CallId field. The first CDR applies to the original
connection, and the second CDR applies to the call redirected to the voice-messaging system. The first
call has the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields set to Immediate
Divert = 14.
The call that gets redirected to the voice-messaging systemhas the origCalledPartyRedirectOnBehalfOf
and lastRedirectRedirectOnBehalfOf fields set to Immediate Divert = 14.
IDivert CDR examples
1 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.
If the call gets redirected by IDivert in the Alerting state, only one CDR gets generated. Note
Original call CDR Field Names
16 origCause_Value
0 dest_CauseValue
14 joinOnBehalfOf
76 OL-28260-01
AAC calls
2 IDivert during Connect 40003 calls 40001, and 40001 answers the call. 40001 decides to divert the
caller to the voice-messaging system and presses the IDivert softkey. 40003 gets diverted to the
voice-messaging system 40000.
Because the call gets connected before the redirect, two CDRs get generated: one for the original connected
call, and another for the call that is diverted to the voice-messaging system.
Diverted Call CDR Original Connected Call CDR Field Names
40001 40001 origCalledPartyNumber
0 0 dest_CauseValue
14 joinOnBehalfOf
Related Topics
OL-28260-01 77
AAC calls
Intercom calls
The Intercom feature provides one-way audio; therefore, the CDR reflects one-way audio. For talk-back
intercom, two-way audio exists, and the CDR reflects two-way audio.
The Intercom feature requires a partition (intercom partition), and existing CDR partition fields get used to
identify intercom calls.
The following two examples show CDRs for intercom.
Intercom CDR examples
1 Whisper Intercom- Phone 20000 invokes the intercom. The configured intercompartition name specifies
Intercom.
Original Call CDR Field Names
16 origCause_Value
0 dest_CauseValue
Intercom origCalledPartyNumberPartition
Intercom callingPartyNumberPartition
Intercom finalCalledPartyNumberPartition
5 duration
78 OL-28260-01
AAC calls
2 Talk-Back Intercom - Phone 20000 presses the intercom button. 20001 invokes Talk-Back and talks to
20000. The configured intercom partition name specifies Intercom.
16 origCause_Value
0 dest_CauseValue
-131332086 origMediaTransportAddress_IP
Intercom origCalledPartyNumberPartition
Intercom callingPartyNumberPartition
Intercom finalCalledPartyNumberPartition
5 duration
Related Topics
IPv6 calls
Cisco Unified Communications Manager supports IPv6 in this release. There are two new fields in the CDR
for this feature:
OL-28260-01 79
AAC calls
origIpv4v6AddrThis field identifies the IP address of the device that originates the call signaling.
The field can be in either IPv4 or IPv6 format depending on the IP address type that gets used for the
call.
destIpv4v6AddrThis field identifies the IP address of the device that terminates the call signaling.
The field can be in either IPv4 or IPv6 format depending on the IP address type that gets used for the
call.
The following CDR examples display IPv6 with successful and unsuccessful calls.
Successful calls
1 A talks to B; A hangs up. A is configured as v4_only and B is configured as v4_only. The new fields
origIpv4v6Addr and destIpv4v6Addr get populated with the format of their respective v4 addresses.
Values Field Names
2309 lastRedirectDn
1878566390 destIpAddr
60 duration
origIpv4v6Addr anddestIpv4v6Addr get populated with the format of their respective v6 addresses.
Values Field Names
80 OL-28260-01
AAC calls
Values Field Names
2309 lastRedirectDn
0 origIpAddr
0 destIpAddr
2001:fecd:ba23:cd1f:dcb1:1010:9234:40881 origIpv4v6Addr
2001:420:1e00:e5:217:8ff:fe5c:2fa9 destIpv4v6Addr
60 duration
origIpv4v6Addr and destIpv4v6Addr get populated with the format of their respective v4/v6 addresses.
Values Field Names
2309 lastRedirectDn
60 duration
OL-28260-01 81
AAC calls
4 A talks to B; A hangs up. A is configured as v4_v6 and B is configured as v4_only. In this case, media
negotiates v4. The new fields origIpv4v6Addr and destIpv4v6Addr get populated with the format of
their respective v4 addresses.
Values Field Names
2309 lastRedirectDn
60 duration
5 A talks to B; A hangs up. A is configured as v4_v6 and B is configured as v6_only. In this case, media
negotiates v6. The new fields origIpv4v6Addr and destIpv4v6Addr get populated with the format of
their respective v6 addresses.
Values Field Names
2309 lastRedirectDn
82 OL-28260-01
AAC calls
Values Field Names
0 destIpAddr
2001:420:1e00:e5:217:8ff:fe5c:2fa9 destIpv4v6Addr
60 duration
Unsuccessful calls
1 A calls B; A abandons the call. A is configured as v4_only and B is configured as v6_only. The new field
origIpv4v6Addr gets populated with the format of its v4 address. The new field destIpv4v6Addr does
not get populated.
Values Field Names
2309 lastRedirectDn
destIpv4v6Addr
0 duration
2 A calls B; the call fails. A is configured as v6_only and B is configured as v4_v6. The new field
origIpv4v6Addr gets populated with the format of its v6 address. The new field destIpv4v6Addr does
not get populated in this case.
OL-28260-01 83
AAC calls
Values Field Names
2309 lastRedirectDn
0 origIpAddr
0 destIpAddr
destIpv4v6Addr
0 duration
Related Topics
Legacy Call Pickup
Legacy Call Pickup calls act similar to forwarded calls. Legacy Call Pickup uses the redirect call control
primitive like call forwarding. Some of the important CDR fields for Legacy Call Pickup calls follow:
The originalCallPartyNumber field contains the number of the original called party.
The finalCalledPartyNumber field specifies the number of the party that picks up the call.
The lastRedirectDn field specifies the number that rings when the call gets picked up.
The origCalledPartyRedirectReason field specifies the reason that the call gets redirected the first
time. For call pickup calls, this field can contain Call Pickup = 5.
The lastRedirectRedirectReason field specifies the reason that the call gets 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.
84 OL-28260-01
AAC calls
The lastRedirectRedirectOnBehalfOf field identifies which feature redirects the call for the last redirect.
For call pickup, this field specifies Pickup = 16.
Legacy Call 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 rings on 2001. 2002 answers the call, and the call connects between the PSTN caller and 2002. They talk
for 2 minutes.
CDR Field Names
2001 lastRedirectDn
0 origCause_Value
16 dest_CauseValue
120 duration
Related Topics
Local route groups and called party transformation
In this release, Cisco Unified Communications Manager supports the new feature, local route groups and
called party transformation. The device reports the Called Party Number that it outpulsed back to Call Control
OL-28260-01 85
AAC calls
only if called party transformation occurs. This action gets recorded in the CDR in the new field
outpulsedCalledPartyNumber.
Local route groups and called party normalization CDR example
A call gets placed from an enterprise phone in Dallas to the PSTN; the dialed number specifies 9.5551212.
The translation causes the called party number to take the digits as dialed by the originator, discard PreDot
and add the Prefix +1 214.
The finalCalledPartyNumber in the CDR comprises the globally unique E.164 string +12145551212.
If a San Jose gateway gets selected, it transforms the global string +1 214 555 1212 into 12145551212, and
if a Dallas gateway gets selected, the global string gets transformed into 2145551212.
The device returns this global string to Call Control as the outpulsedCalledPartyNumber; it gets recorded
in the CDR.
The following CDR gets created if the San Jose gateway gets selected.
Values Field Names
+12145551212 originalCalledPartyNumber
2309 lastRedirectDn
16 origCause_Value
0 dest_CauseValue
60 duration
12145551212 outpulsedCalledPartyNumber
The following CDR gets created if the Dallas gateway gets selected.
Values Field Names
86 OL-28260-01
AAC calls
Values Field Names
+12145551212 originalCalledPartyNumber
+12145551212 finalCalledPartyNumber
+12145551212 lastRedirectDn
16 origCause_Value
0 dest_CauseValue
60 duration
2145551212 outpulsedCalledPartyNumber
Related Topics
Logical partitioning calls
The Telecom Regulatory Authority of India (TRAI) requires that voice traffic over an enterprise data network
and a PSTNnetwork remain separate. The logical partitioning feature ensures that a single systemcan be used
to support both types of calls as long as calls that pass through a PSTN gateway can never directly connect
to a VoIP phone or VoIP PSTN gateway in another geographic location (geolocation).
CDR example for call termination cause code CCM_SIP_424_BAD_LOCATION_INFO
A SIP trunk call goes from cluster1 to cluster2. The call contains a geolocation header but does not include
an XML location. Cluster2 releases the call with a SIP Status code of 424 (bad location information [decimal
value = 419430421]).
Cause code CCM_SIP_424_BAD_LOCATION_INFO gets logged for calls that are cleared because of bad
location information by the SIP trunk on the Cisco Unified Communications Manager. The remote endpoint
on the SIP trunk can send the 424 SIP Status code for cases when the geolocation information is bad for some
of the following reasons:
The geolocation header indicates the inclusion of PIDF-LO, but the message body does not carry this
information.
The geolocation header has a CID header that refers to a URL, but no corresponding Content-IP header
with the same URL exists.
The geolocation header has a URL other than the CID header (that is a SIP, or SIPS URL).
Refer to additional CDR examples for more information on other call termination cause codes.
OL-28260-01 87
AAC calls
Values Field Names
9900 lastRedirectDn
0 origCause_Value
419430421 dest_CauseValue
0 duration
CDR Example for Call Termination Cause Code 503
Call 82291002 from cluster1 gets call-forwarded to the PSTN 41549901. A call occurs from cluster2 from
DN 89224001 to cluster1 DN 82291002. The call gets denied because of logical partitioning with a call
termination cause code of CCM_SIP_503_SERVICE_UNAVAIL_SER_OPTION_NOAVAIL [decimal value
of -1493172161]) for the dest_CauseValue.
Cause code CCM_SIP_503_SERVICE_UNAVAIL_SER_OPTION_NOAVAIL gets logged for calls that get
cleared because of restricted logical partitioning policy checks during the call establishment phase (basic call,
call forwarding, call pickup, call park, meet-me conferences, and so forth). Refer to additional CDRexamples
for more information on other call termination cause codes.
Values Field Names
88 OL-28260-01
AAC calls
Values Field Names
0 origCause_Value
-1493172161 dest_CauseValue
0 duration
Related Topics
CDR Examples, on page 17
Malicious calls
When a call gets identified as a malicious call (button press), the local Cisco Unified Communications Manager
network flags the call. The Comment field flags the malicious call.
Malicious calls CDR example
The following table contains an example CDR of a customer call that gets marked as malicious.
Comment Dest
Cause
Orig
Cause
Original
Called
Partition
Original
Called
Party
Calling
Partition
Calling
Party
callFlag=MALICIOUS 16 0 ACNTS 5555 CUST 9728552001
Related Topics
Meet-Me conferences
Ameet-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).
OL-28260-01 89
AAC calls
Meet-Me conference CDR example
The following table contains an example CDR for the following scenario. 5001 specifies the dial-in number.
The conference bridge device signifies special significance to the Cisco Unified Communications Manager,
and calls to the conference bridge appear as forwarded calls; that is, User Aphones the predetermined number
(5001); 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.
Duration Last
Redirect
Partition
Last
Redirect
Party
Final
Called
Partition
Final
Called
Party
Original
Called
Partition
Original
Called
Party
Calling
Partition
Calling
Party
70 b0019901001 b0019901001 5001 Accounts 2001 A
65 b0019901001 b0019901001 5001 Accounts 2002 B
80 b0019901001 b0019901001 5001 Accounts 2003 C
Related Topics
Mobility
Cisco Unified Communications Manager supports the following Mobility features:
Hand-In
Hand-Out
Cell Pickup
Interactive Voice Response (IVR)
The system generates a standard CDR for every call that uses the Mobility features. When a call gets split,
redirected, or joined by the Mobility feature, the corresponding OnBehalfOf code represents a new value that
is designated to the Mobility feature. The CAR Loader checks the following OnBehalfOf fields:
origCallTerminationOnBehalfOf
destCallTerminationOnBehalfOf
origCalledPartyRedirectOnBehalfOf
lastRedirectRedirectOnBehalfOf
joinOnBehalfOf
90 OL-28260-01
AAC calls
If any of the preceding OnBehalfOf codes has the Mobility code of 24, the CDR has the Mobility call type
that the CARLoader determines. Four RedirectReason codes apply for Mobility features: Hand-In (code 303),
Hand-Out (code 319), Cell Pickup (code 335), and IVR (code 399).
Mobility CDR examples
1 Mobility Follow Me - A dual-mode phone has the Enterprise number of 22285 and the cell number of
9728324124. 22202 calls 22285, and both 22285 and 9728324124 ring. The cell phone answers the call.
The system generates a single CDR for this Follow Me call. The parties talk for 80 seconds.
Follow Me Call CDR Field Names
16 origCause_Value
0 dest_CauseValue
origTerminationOnBehalfOf
destTerminationOnBehalfOf
0 joinOnBehalfOf
80 duration
2 Mobility HandIn - A dual-mode phone with the Enterprise number of 22285 and the cell number of
9728324124 calls to the cell phone 9728324214. They talk for 39 seconds; then, the dual-mode phone
gets carried into the Enterprise network, and the call gets switched from the cell network to the Enterprise
network. The parties continue to talk for another 15 seconds.
OL-28260-01 91
AAC calls
HandIn Call to the Enterprise
CDR
Call to cell #9728324214 CDR Field Names
24 0 joinOnBehalfOf
15 39 duration
3 Mobility HandOut - A dual-mode phone has the Enterprise number of 22285 and the cell number of
9728324124. The handout number (H-number) specifies 555123. A call goes to the Enterprise number
22285. They talk for 21 seconds; then, the dual-mode phone gets carried out of the Enterprise network
and into the cell network. The call gets switched from the Enterprise network to the cell network
(9728324124). The parties continue to talk for another 39 seconds.
Handout Call CDR Server Call from cell
phone to H-Number
CDR
Enterprise Call to
22285 CDR
Field Names
92 OL-28260-01
AAC calls
Handout Call CDR Server Call from cell
phone to H-Number
CDR
Enterprise Call to
22285 CDR
Field Names
9728324124 555123 22285 originalCalledPartyNumber
9728324124 555123 22285 finalCalledPartyNumber
9728324124 555123 22285 lastRedirectDn
24 0 0 lastRedirectRedirectOnBehalfOf
24 0 0 joinOnBehalfOf
39 0 21 duration
4 Mobility Cell Pickup - A dual-mode phone with the Enterprise number of 22285 and the cell number of
9728324124, establishes a call to the Enterprise number 22285. They talk for 40 seconds; then, Cell Pickup
gets invoked. The call gets switched from the Enterprise phone to the cell phone. The parties continue to
talk for another 111 seconds.
Final Handout Call
CDR
Server Call to Cell
Phone CDR
Enterprise Call to
22285 CDR
Field Names
22285
22285
22285 22285 22285 lastRedirectDn
OL-28260-01 93
AAC calls
Final Handout Call
CDR
Server Call to Cell
Phone CDR
Enterprise Call to
22285 CDR
Field Names
111 0 40 duration
5 Mobility IVR - A call comes into the Cisco Unified Communications Manager with string
DID#RemoteDest#TargetNum#. The call gets redirected to the TargetNum. 9728131234 calls into an
IVR, and data gets collected. The target destination specifies 812345, and the call gets redirected to 812345.
The call remains connected for 60 seconds.
Redirected Call CDR Field Names
0 origCause_Value
16 dest_CauseValue
94 OL-28260-01
AAC calls
Redirected Call CDR Field Names
60 duration
Related Topics
Normal calls (Cisco Unified IP Phone to Cisco Unified 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.
Successful normal calls CDR examples
A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.
1 The caller terminates a 60-second call. Because the calling party hangs up, the orig_CauseValue specifies
16 (Normal Clearing).
CDR Field Names
2309 lastRedirectDn
16 origCause_Value
0 dest_CauseValue
60 duration
OL-28260-01 95
AAC calls
2 The called party clears a 60-second call. Because the called party hangs up, the dest_CauseValue specifies
16 (Normal Clearing).
CDR Field Names
2309 lastRedirectDn
0 origCause_Value
16 dest_CauseValue
60 duration
Related Topics
Original calling party on transfer
This feature changes the calling party number for a consultation call of a Cisco Unity or Cisco Unity
Connection-initiated call transfer. The CDR of the consultation call shows that the original caller calls the
transfer destination, not that the Cisco Unity or Cisco Unity Connection port calls the transfer destination.
You must configure this feature in the service parameters in Cisco Unified Communications Manager. See
additional information at Configuring CDR Service Parameters section of the CDR Analysis and Reporting
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).
96 OL-28260-01
AAC calls
originalCalledPartyNumber CallingPartyNumber Call
4002 4001 1
4003 4002 2
4003 4001 3
No originalCallingParty field exists in the CDR. Note
Related Topics
Personal assistant calls
This section contains information about Personal Assistant Calls.
Related Topics
Personal assistant direct call, on page 97
Personal assistant interceptor going to media port and transferring call, on page 98
Personal assistant interceptor going directly to destination, on page 98
Personal assistant interceptor going to multiple destinations, on page 99
Personal assistant conferencing, on page 102
Personal assistant direct call
A personal assistant direct call acts similar to the Blind Transfer from the Calling Party call type.
Personal assistant direct call CDR example
The following table contains an example CDR for this scenario:
User A (2101) calls Personal Assistant route point (2000) and says call User B.
The call transfers to User B (2105). In this case, User B did not configure any rules.
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.
Note
In all cases, 2101 specifies the calling number.
OL-28260-01 97
AAC calls
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party
Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
34 Phones 2000 1023970182 2000 Phones 2004 16777219 PAManaged 16777217 2101
0 PAManaged 2105 1023970182 2105 PAManaged 2105 16777222 Phones 16777221 2004
5 PAManaged 2105 1023970191 2105 PAManaged 2105 16777222 PAManaged 16777217 2101
Related Topics
Transferred calls, on page 112
Personal assistant interceptor going to media port and transferring call
This scenario acts similar to Blind Transfer from the Calling Party and Forwarded Calls actions.
Personal assistant interceptor going to media port and transferring the call CDR example
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.
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party
Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
9 " " 21xx 1023970478 2105 PA 2002 16777232 PAManaged 16777230 2101
5 " " " " 1023970483 " " " " 2101 16777230 PAManaged 16777235 2105
Related Topics
Forwarded or redirected calls, on page 65
Transferred calls, on page 112
Personal assistant interceptor going directly to destination
This scenario can have two different cases: with rules and with no rules.
98 OL-28260-01
AAC calls
Example personal assistant interceptor going directly to destination with no rules CDR
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).
Duration(secs) Last
Redirect
DN
Partition
Last
Redirect
DN
Original
Called Party
Number
Partition
Original
Called
Party
Number
FinalCalled
Party
Number
Partition
Final
Called
Party
Number
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Number
8 " " 21XX 1023970710 2105 PA 2105 16777242 PAManaged 16777240 2101
Example personal assistant going directly to destination with rule to forward calls to different destination CDR
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.
Duration(secs) Last
Redirect
DN
Partition
Last
Redirect
DN
Original
Called Party
Number
Partition
Original
Called
Party
Number
FinalCalled
Party
Number
Partition
Final
Called
Party
Number
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Number
8 " " 21XX 1023970710 2105 PA 2110 16777242 PAManaged 16777240 2101
Personal assistant interceptor going to multiple destinations
This scenario can have several different cases. In each case, User B (2105) configures a rule to reach him at
extension 2110 or 2120. This rule can 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 following 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)
OL-28260-01 99
AAC calls
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.
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party
Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
9 " " " " 1023971312 " " " " 2101 16777258 PAManaged 16777263 2110
Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at second destination)
User B answers the call at 2120 extension.
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party
Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
7 " " " " 1023971474 " " " " 2101 16777265 PAManaged 16777273 2120
0 " " " " 1023971476 " " " " " " 0 PAManaged 16777275 2110
Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at third destination)
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.
100 OL-28260-01
AAC calls
2105 (the original destination) represents the third destination in this case. Note
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
0 " " " " 1023971629 " " " " " " 0 PAManaged 16777289 2105
Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at first destination)
User B answers the call at extension 2110.
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party
Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
10 " " 21XX 1023971740 2105 PA 2003 16777293 PAManaged 16777291 2101
9 " " " " 1023971749 " " " " 2101 16777291 PAManaged 16777296 2110
Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at second destination)
User B answers the call at extension 2120.
OL-28260-01 101
AAC calls
Duration
(secs)
Last
Redirect DN
Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party
Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
22 " " 21XX 1023971824 2105 PA 2004 16777300 PAManaged 16777298 2101
8 " " " " 1023971832 " " " " 2101 16777298 PAManaged 16777306 2120
Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at third destination)
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.
2110 (the original destination) represents the third destination in this case. Note
Duration
(secs)
Last Redirect
DN Partition
Last
Redir
DN
Original
Called Party
Number
Partition
Original
Called
Party
Num
Final Called
Party Number
Partition
Final
Called
Party
Num
DestLeg
Identifier
Calling Party
Number
Partition
OrigLegCall
Identifier
Calling
Party
Num
30 " " 21XX 1023971940 2105 PA 2001 16777310 PAManaged 16777308 2101
Personal assistant conferencing
Personal assistant conferencing acts similar to the ad hoc conferences call type.
Personal assistant conferencing CDR example
102 OL-28260-01
AAC calls
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.
Final Called Party
Number Partition
Final Called Party
Num
DestLeg
Identifier
Calling Party
Number Partition
OrigLegCall
Identifier
Calling
Party Num
PAManaged 2105 16777346 Phones 16777345 2003
Phones 2003 16777342 PAManaged 16777340 2101
PAManaged 2002 16777351 Phones 16777350 2003
" " 2110 16777347 Phones 16777342 2003
" " b00110201001 16777352 PAManaged 16777351 2110
" " b00110201001 16777349 PAManaged 16777346 2105
" " b00110201001 16777348 PAManaged 16777340 2101
This table continues with this additional information.
Duration
(seconds)
Last Redirect DN
Partition
Last Redirect DN Original Called Party
Number Partition
Original CalledParty
Number
6 PAManaged 2105 1023972575 2105
62 Phones 2003 1023972576 2000
39 PAManaged 2110 1023972595 2110
25 " " b00110201001 1023972601 b00110201001
14 " " b00110201001 1023972609 b00110201001
34 " " b00110201001 1023972610 b00110201001
34 " " b00110201001 1023972610 b00110201001
Related Topics
Conference calls, on page 53
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.
OL-28260-01 103
AAC calls
Precedence call CDR examples
1 A call to another IP phone occurs by dialing a precedence pattern (precedence level 2).
Precedence Call CDR Field Names
0 origCause_Value
16 dest_CauseValue
2 A precedence call gets received from another network (precedence level 1).
Precedence Call CDR Field Names
16 origCause_Value
0 dest_CauseValue
3 A call gets preempted by a higher precedence level call.
104 OL-28260-01
AAC calls
Higher Level Call CDR Original call CDR Field Names
826001 826001 origCalledPartyNumber
0 0 origCause_Value
1 2 origPrecedenceLevel
1 2 destPrecedenceLevel
Redirection (3xx) calls
This example shows CDRs for a the redirection feature (3xx).
When a call is redirected by the Redirection Feature (3xx), the origCalledPartyRedirectOnBehalfOf and
lastRedirectRedirectOnBehalfOf fields specify Unified CM Redirection = 19. The
origCalledPartyRedirectReason and the lastRedirectRedirectReason fields specify Redirection = 162.
Redirection (3xx) CDR example
Activate CFA on phone 10010 that is running SIP (registered to Cisco Unified Communications Manager)
with a CFA destination of 10000. 35010 calls 10010, which is CFA to 10000. The call gets redirected from
10010 to 10000. 10000 answers the call and talks for 1 minute.
OL-28260-01 105
AAC calls
0 origCause_Value
16 dest_CauseValue
19 joinOnBehalfOf
60 duration
Refer calls
See the replaces calls topic for an example of Refer with Replaces.
Related Topics
Replaces calls, on page 106
Replaces calls
The examples show CDRs for various types of Replaces calls.
Replaces CDR examples
1 Invite with Replaces Phone 35010 that is running SIP calls phone 35020 that is running SIP. The transfer
button gets pressed on 35010, and a call gets placed to SCCP phone 3000, 3000 answers the call; then,
phone 35010 completes the transfer. The final transferred call occurs between 35020 and 3000.
When the transfer is complete, the systemsends an Invite with Replaces to Cisco Unified Communications
Manager.
Note
Reverted Call CDR Original Call CDR Field Names
106 OL-28260-01
AAC calls
Reverted Call CDR Original Call CDR Field Names
18 0 joinOnBehalfOf
60 5 duration
2 Refer with Replaces Phone 35010 that is running SIP calls SCCP 3000, the transfer button gets pressed
on 35010, and a call is placed to SCCP 3001; 3001 answers the call; then, phone 35010 completes the
transfer. The final transferred call occurs between 3000 and 3001.
When the transfer completes, a Refer with Replaces gets sent to Cisco Unified Communications Manager. Note
Final Transferred Call
CDR
Consultation Call CDR Original Call CDR Field Names
OL-28260-01 107
AAC calls
CDR
17 0 0 origCalledPartyRedirectOnBehalfOf
25 4 25 duration
RSVP
These fields identify the status of RSVP reservation for the call. Be aware that the Cisco Unified
Communications Manager RSVP CDR status field value gets concatenated, and the system retains the last
32 status values for the call.
For example, if a call is established with Optional policy, and the initial RSVP reservation is successful,
and then it subsequently loses its bandwidth reservation and then regains its bandwidth reservation after retry,
for several times during middle of the call, the call ends with a successful RSVP reservation. The CDR shows
the following string as the Unified Communication RSVP reservation status for that particular stream:
2:5:2:5:2:5:2 (success:lost_bw:success:lost_bw:success:lost_bw:success).
RSVP call CDR examples
1 The example represents a call that gets established with Optional policy, and the initial RSVP reservation
succeeds. The parties talk for 5 minutes.
108 OL-28260-01
AAC calls
CDR Field Names
0 origCause_Value
16 dest_CauseValue
2 origDTMFMethod
2 destDTMFMethod
300 duration
2 The example represents a call that is established with Optional policy, and the initial RSVP reservation
succeeds, then it loses its bandwidth reservation but regains it after a retry. The parties talk for 1 minute.
CDR Field Names
0 origCause_Value
16 dest_CauseValue
OL-28260-01 109
AAC calls
CDR Field Names
2:5:2 origDTMFMethod
2:5:2 destDTMFMethod
60 duration
Secure conference Meet-Me
The following example shows a CDR for a meet-me secure conference. 35010 calls into a secure meet-me
conference, but 35010 is a non-secure phone. Because 35010 does not meet the minimum security level of
the meet-me conference, the call gets cleared with the cause code of 58 (meet-me conference minimumsecurity
level not met).
Secure conference Meet-Me CDR example
Call to the Meet-Me Conference CDR Field Names
58 origCause_Value
0 dest_CauseValue
110 OL-28260-01
AAC calls
Short calls
A short call, with a CdrLogCallsWithZeroDurationFlag set at True and a duration of less than 1 second,
appears as a zero duration call in the CDR. The DateTimeConnect field, which shows the actual connect
time of the call, differentiates these calls from failed calls. For failed calls (which never connected), this value
equals zero.
Short calls 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.
Duration DateTime
Connect
Dest
Cause
Orig
Cause
Original
Called Partition
Original
Called Party
Calling
Partition
Calling
Party
0 973795815 16 0 Marketing 2309 Accounts 2001
SIP call with URL in CallingPartyNumber field
Calling and called parties can have SIP calls where the extension number is a URL. The extension number
can use all printable ASCII characters. Do not leave any spaces in the URL. For example, extension 1000
1001 does not get accepted as a valid URL.
Printable ASCII characters represent characters with ASCII code (in decimal) from 33 to 126. Note
SIP call with URL in CallingPartyNumber field CDR example
The SIP trunk of the Cisco Unified Communications Manager receives an incoming call. The call contains a
SIP URL for the callingPartyNumber.
Values Field Names
bob@abc.com callingPartyNumber
2309 lastRedirectDn
OL-28260-01 111
AAC calls
Values Field Names
16 origCause_Value
0 dest_CauseValue
60 duration
Successful on net calls
A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.
Successful On Net call CDR examples
The following table contains two examples:
AA 60-second call that the caller terminates
BA 60-second call that the called party clears
Duration Dest
Cause
Orig
Cause
Original Called
Partition
Original Called
Party
Calling
Partition
Calling
Party
60 0 16 Marketing 2309 Accounts 2001 A
60 16 0 Marketing 2309 Accounts 2001 B
Transferred calls
Calls that are transferred generate multiple CDRs. One CDRexists for the original call, one for the consultation
call, and another for the final transferred call.
For the original call, the origCause_value and destCause_value gets set to split = 393216, which indicates
the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields get
set to Transfer = 10 to indicate that this call was involved in a transfer.
For the consultation call, the origCause_value and destCause_value fields get set to split = 393216, which
indicates that the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf
fields get set to Transfer = 10 to indicate that this call was involved in a transfer.
For the final transferred call, the joinOnBehalfOf field gets set to Transfer = 10 to indicate that this call
resulted from a transfer.
Transferred calls CDR 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.
112 OL-28260-01
AAC calls
Blind transfer from the calling party CDR example
Call goes 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.
Final Transferred CDR Consultation Call CDR Original Call CDR Field Names
360 0 120 duration
Consultation transfer from the calling party CDR example
Call goes 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.
CDR2 (consultation call) shows a call from2001 to extension 2002, talking for 10 seconds. CDR3 represents
the final transferred call where 2001 completes the transfer, drops out of the call, and leaves a call between
the PSTN and 2002.
CDR
OL-28260-01 113
AAC calls
CDR
360 10 60 duration
Blind transfer from the called party CDR example
Call goes from 50000 to 50001; they talk for 120 seconds. 50001 initiates a blind transfer to 50002. CDR 1
(original call) shows a call from extension 50001 to 50002, talking for 120 seconds. CDR 2 (consultation
call) shows a call from 50001 to extension 50002. CDR 3 represents the final transferred call where 50001
completes the transfer, drops out of the call, and leaves a call between 50000 and 50002.
CDR
114 OL-28260-01
AAC calls
CDR
360 0 120 duration
Consultation transfer from the called party CDR example
Call goes from 50000 to 50001; they talk for 120 seconds. 50000 initiates a blind transfer to 50002. CDR 1
(original call) shows a call from extension 50000 to a 50001, talking for 120 seconds. CDR 2 (consultation
call) shows a call from 50000 to extension 50002. CDR 3 represents the final transferred call where 50000
completes the transfer, drops out of the call, and leaves a call between 50001 and 50002.
CDR
360 0 120 duration
OL-28260-01 115
AAC calls
Video calls
The following example shows a CDR for a video call.
Video calls CDR 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.
Video Call CDR Field Names
0 origCause_Value
16 dest_CauseValue
100 origVideoCap_Codec
320 origVideoCap_Bandwidth
2 origVideoCap_Resolution
187962284 origVideoTransportAddress_IP
49208 origVideoTransportAddress_Port
100 destVideoCap_Codec
320 destVideoCap_Bandwidth
2 destVideoCap_Resolution
288625580 destVideoTransportAddress_IP
49254 destVideoTransportAddress_Port
116 OL-28260-01
AAC calls
Video conference calls
Calls that are part of a video conference have multiple records logged. The number of CDR records that are
generated depends on the number of parties in the video conference. One CDR record exists for each party
in the video conference, one for the original placed call, one for each setup call that was used to join other
parties to the video conference, and one for the last two parties that are connected in the video conference.
Therefore, for a three party ad hoc video conference, six CDR records exist:
1 record for the original call
3 records for the parties that connected to the conference
1 record for each setup call
1 record for the final two parties in the conference
You can associate the setup calls with the correct call leg in the conference by examining the calling leg ID
and called leg ID.
The conference bridge device has special significance to the Cisco Unified Communications Manager, and
calls to the conference bridge appear as calls to the conference bridge device. A special number in the form
"b0019901001" shows the conference bridge port.
All calls in or out of the conference bridge get shown going into the conference bridge, regardless of the actual
direction. By examining the setup call CDR records, 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 will contain multiple conference
controller information. This could happen in case 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 that are connected to the conference will have 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 fields:
The origCallTerminationOnBehalfOf field gets set to (Conference = 4).
OL-28260-01 117
AAC calls
The destCallTerminationOnBehalfOf field gets set to (Conference = 4).
Video conference call CDR example
1 Call from 2001 to 2309; 2309 answers, and they talk for 60 seconds.
2 2001 presses the conference softkey and dials 3071111.
3 307111 answers and talks for 20 seconds; 2001 presses the conference softkey to complete the conference.
4 The three members of the conference talk for 360 seconds.
5 3071111 hangs up; 2001 and 2309 stay in the conference. Because only two participants remain in the
conference, the conference feature joins the two directly together, and they talk for another 55 seconds.
Each video conference call leg gets shown 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.
Note
CDR 3
Conference
CDR 2
Conference
CDR 1
Setup Call
CDR
Orig Call CDR FieldNames
2309 b0029901001 b0029901001 b0029901001 3071111 2309 originalCalledPartyNumber
2309 b0029901001 b0029901001 b0029901001 3071111 2309 finalCalledPartyNumber
b0029901001 b0029901001 b0029901001 b0029901001 3071111 2001 lastRedirectDn
16 393216 393216 16 0 393216 origCause_Value
0 393216 393216 393216 0 393216 dest_CauseValue
103 103 103 103 103 103 origVideoCap_Codec
320 320 320 320 320 320 origVideoCap_Bandwidth
0 0 0 0 0 0 origVideoCap_Resolution
552953152 -945658560 -822647488 552953152 552953152 552953152 origVideoTransportAddress_IP
5445 5445 5445 5445 5445 5445 origVideoTransportAddress_Port
103 103 103 103 103 103 destVideoCap_Codec
118 OL-28260-01
AAC calls
CDR 3
Conference
CDR 2
Conference
CDR 1
Setup Call
CDR
Orig Call CDR FieldNames
320 320 320 320 320 320 destVideoCap_Bandwidth
0 0 0 0 0 0 destVideoCap_Resolution
-822647488 -666216182 -666216182 -666216182 -945658560 -822647488 destVideoTransportAddress_IP
5445 10001 10004 10000 10002 5445 destVideoTransportAddress_Port
0 0 0 0 0 0 origCalledPartyRedirectReason
0 4 4 4 0 0 origCalledRedirectOnBehalfOf
4 4 4 4 0 0 joinOnBehalfOf
0 1 1 1 0 Conversation ID
55 360 360 360 60 duration
Comment
Orig Call CDR
ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD Setup Call CDR
Final CDR
OL-28260-01 119
AAC calls
120 OL-28260-01
AAC calls
C HAP T E R 5
Cisco call detail records field descriptions
This chapter defines all fields in the current CDRs in the order in which they appear in the CDR.
CDR field descriptions, page 121
Routing reason values for external call control, page 148
CDR field descriptions
The following table describes all fields in the current CDRs in the order in which they appear.
Table 3: CDR Field Descriptions
Description Range of
Values
Field Name
This field defines the type of record. The following
valid values apply:
0Start call detail record (not used)
1End call detail record (CDR)
2CMR record
Default - For CDRs, this field always remains 1.
0, 1, 2 cdrRecordType
This field designates a unique Cisco Unified
Communications Manager identity.
The Global Call ID comprises two fields:
globalCallID_callId globalCallID_callManagerId
All records that are associated with a standard call
have the same Global Call ID in them.
Default - Ensure this field always is populated.
Positive
Integer
OL-28260-01 121
Values
Field Name
This field designates a unique call identity value that
is assigned to each call. The system allocates this
identifier independently on each call server. Values
get chosen sequentially when a call begins. A value
gets assigned for each call, successful or
unsuccessful. When Cisco Unified Communications
Manager restarts, it checks the file for the current
globalCallID_callId number and assigns the next
1000th number to the next GlobalCallID_callId.
The Global Call ID consists of two fields:
globalCallID_callId globalCallID_callManagerId
All records that are associated with a standard call
have the same Global Call ID in them.
For Cisco Unified Communications Manager
Release 5.x and later releases, the value in
the GlobalCallId CDR field survives over
Cisco Unified Communications Manager
restarts. In Release 4.x and earlier releases,
even though the GlobalCallId field is
time-based, the field gets reused under
conditions of heavy traffic. Because of this
behavior, problems can occur with customer
billing applications and the ability of CAR
to correlate CMRs with CDRs and to
correlate conference call CDRs. For Release
5.x and later releases, GlobalCallId redesign
ensures the field retains a unique value, at
least for a certain number of days. Now, the
last used globalCallId_callId value gets
written to disk periodically (for every x
number of calls). The value gets retrieved
after a Cisco Unified Communications
Manager restart, and the new
globalCallId_callId value begins with this
number plus x.
Note
Positive
Integer
globalCallID_callId
This field identifies the originating leg of a call. Be
aware that this value is unique within a cluster. If the
leg of a call persists across several sub-calls, and
consequently several CDRs (as during a call transfer),
this value remains constant.
Positive
Integer
origLegCallIdentifier
122 OL-28260-01
Values
Field Name
This field identifies the date and time when the user
goes off hook or the date and time that the H.323
SETUP message is received for an incoming call.
The time gets stored as UTC.
Integer dateTimeOrigination
This field identifies the server, or node within a
cluster, to which the originator of the call is
registered at the time that the call is made.
Positive
Integer
origNodeId
For calls that originate at a gateway, this field
indicates the B-channel number of the T1, PRI, or
BRI trunk where the call originates, or a zero value
for FXS or FXO trunks.
For H.323 gateways, the span number remains
unknown, and this field contains the call leg ID of
the originator.
For calls that did not originate at a gateway, the value
specifies zero.
Default - This field gets populated based on these
rules.
0, Positive
Integer
origSpan
This field identifies the v4 IP address of the device
that originates the call signaling.
For Cisco Unified IP Phones, this field specifies the
v4 address of the phone.
For PSTN calls, this field specifies the v4 address of
the H.323 gateway.
For intercluster calls, this field specifies the
v4 address of the remote Cisco Unified
Communications Manager.
Default - 0. If the v4 address does not exist for the
originating device, this field equals 0. This field gets
populated based on these rules.
Integer origIpAddr
OL-28260-01 123
Values
Field Name
This field specifies a numeric string of up to 25
characters that indicates the calling party number if
the calling party is identified with a directory
number.
If the calling party uses a blended address in the
identity headers, this field contains the directory
number portion of the blended address.
For calls that originate at a Cisco Unified IP Phone,
this field shows the extension number of the line that
is used.
For incoming H.323 calls, this field specifies the
value that is received in the Calling Party Number
field in the Setup message. This field reflects any
translations that are applied to the Calling Party
Number before it arrives at the Cisco Unified
Communications Manager (such as translations at
the gateway).
For server calls, where Cisco Unified
Communications Manager originates a half call
without a calling party, this field may remain empty.
CallingPartyNumber could contain a SIP URI.
Default - This field gets populated based on these
rules.
Text String callingPartyNumber
This field specifies the calling party login user ID.
The format of this field specifies UTF_8.
Default - Empty string . If the user ID does not
exist, this field stays empty.
Unicode
UTF_8
callingPartyUnicodeLoginUserID
For clearing causes that are received over ISDN
signaling links, this field specifies the Location field
that is indicated in the ISDN release message. See
topics related to call termination cause codes for a
list of the valid values per Q.850.
For clearing causes that are created internally by the
Cisco Unified Communications Manager, this value
specifies zero.
Default - 0
0 to 15 origCause_location
124 OL-28260-01
Values
Field Name
For calls that are cleared by the originating party,
this field reflects the reason for clearance.
Cisco Unified Communications Manager currently
uses the Q.850 codes and some Cisco Unified
Communications Manager defined codes. See topics
related to call termination cause codes for a listing.
For calls that are cleared by the terminating party,
this field specifies zero.
In addition to the standard values that are described
in Q.850, when a call is split by a feature
(transfer/conference), the CDR terminates, and this
field gets set to 393216. This represents a proprietary
value for this field.
Default - 0
0 to 129 origCause_value
For MLPP, each call leg includes a precedence level.
This field represents the precedence level of the
original leg.
Precedence 0 = FLASH OVERRIDE/
EXECUTIVE OVERRIDE
Precedence 1 = FLASH
Precedence 2 = IMMEDIATE
Precedence 3 = PRIORITY
Precedence 4 = ROUTINE
Default - 4
0 to 4 origPrecedenceLevel
that originates the media for the call.
the H.323 gateway.
v4 address of the remote phone.
Default - 0. If media is not established or the address
is not v4, this field equals 0.
0, Integer origMediaTransportAddress_IP
OL-28260-01 125
Values
Field Name
This field identifies the IP port number that is
associated with the OrigMediaTransportAddress_IP
field.
Default - 0. If media is not established, this field
stays 0.
0, Positive
Integer
origMediaTransportAddress_Port
This field identifies the codec type that the originator
uses to transmit media.
uses the following payload capability values: 0, 1-16,
18-20, 25, 32, 33, 81-86. See topics related to codec
types for a listing of the valid values.
stays 0.
0, Positive
Integer
origMediaCap_payloadCapability
This field identifies the number of milliseconds of
data per packet that the originating party sends. This
field normally gets set to 10, 20, or 30 for G.729 or
G.711 codecs, but the field can store any nonzero
value.
stays 0.
0, Positive
Integer
origMediaCap_maxFramesPerPacket
This field is not used in the current release of Cisco
Unified Communications Manager.
Default - This field will remain 0.
0 origMediaCap_g723BitRate
uses to transmit video (H.261, H.263, or H.264.)
stays 0.
0,
100 = H.261,
101 = H.263,
103 = H.264
origVideoCap_Codec
This field identifies the bandwidth that is measured
in units of kbps.
stays 0.
0, Positive
Integer
origVideoCap_Bandwidth
126 OL-28260-01
Values
Field Name
This field indicates the transmitting resolution. In
the case of H.264 codec or SIP device, this field
refers to the max transmitting resolution the device
can transmit for this call.
stays 0.
0,
1 = SQCIF,
2 = QCIF,
3 = CIF,
4 = CIF4,
5 = CIF16
6 = H263
custom
resolution
7 = W360P
8 = VGA
9 = W448P
10 =
HD720P
11 =
HD1080P
12 = CIF2
origVideoCap_Resolution
that originates the call.
Default - 0. If media is not established or the address
is not v4, this field stays 0.
0, Integer origVideoTransportAddress_IP
This field identifies the video RTP port that is
associated with the origVideoTransportAddress_IP
field.
stays 0.
0, Positive
Integer
origVideoTransportAddress_Port
OL-28260-01 127
Values
Field Name
This field gives the status of the RSVP audio
reservation from originator to terminator.
0 No reservation.
1 RSVP Reservation Failure condition at call setup
or feature invocation.
2 RSVP Reservation Success condition at call setup
3 RSVP Reservation No Response (RSVP Agent)
condition at call setup or feature invocation.
4 RSVP Mid Call Failure Preempted condition
(preempted after call setup).
5 RSVP Mid Call Failure Lost Bandwidth condition
(includes all mid-call failures except MLPP
preemption).
Default 0
0 to 5 origRSVPAudioStat
This field gives the status of the RSVP video
reservation from originator to terminator.
0 No reservation.
4 RSVP MID Call Failure Preempted condition
5 RSVP MID Call Failure Lost Bandwidth
condition (includes all mid-call failures except MLPP
preemption).
Default 0
0 to 5 origRSVPVideoStat
This field identifies the terminating leg of a call. This
value remains unique within a cluster. If the leg of
a call persists across several sub-calls and,
consequently, several CDRs (as during a call
transfer), this value remains constant.
Default - 0. If the destination cannot be reached, this
field stays 0.
0, Positive
Integer
destLegCallIdentifier
128 OL-28260-01
Values
Field Name
This field identifies the location, or node within a
cluster, to which the terminating party of the call is
registered at the time that the call is made.
field stays 0.
0, Positive
Integer
destNodeId
For calls that are received at a gateway, this field
indicates the B channel number of the T1, PRI, or
BRI trunk where the call is received, or a zero value
for FXS or FXO trunks.
For H.323 gateways, the span number remains
unknown, and this field contains the call leg ID of
the destination.
For calls not terminating at a gateway, the value
specifies zero.
field stays 0.
0, Positive
integer
destSpan
that terminates the call signaling.
the H.323 gateway.
v4 address of the remote Cisco Unified
field stays 0. If the v4 address does not exist for this
device, the field equals 0.
0, Integer destIpAddr
OL-28260-01 129
Values
Field Name
This field specifies the number to which the original
call was presented, prior to any call forwarding. If
translation rules are configured, this number reflects
the called number after the translations have been
applied.
If a blended address is used for the called party, this
field specifies the directory number portion of the
blended address.
This field represents a numeric string of up to 48
characters that can be either digits or a SIP URL.
Default - Empty string . If destination cannot be
reached, or if the called party number is a directory
URI, this field stays empty.
Text String originalCalledPartyNumber
This field specifies the phone number to which the
call finally gets presented, until it is answered or
rings out. If no forwarding occurs, this number shows
the same number as the originalCalledPartyNumber.
If the call finally gets presented to a directory URI,
the field remains empty.
If a blended address is used, this field specifies the
directory number portion of the blended address
For calls to a conference bridge, this field contains
the actual identifier of the conference bridge, which
is an alphanumeric string (for example,
b0019901001).
This field represents an alphanumeric string that can
be either digits or a SIP URL.
reached, this field stays empty.
Text String finalCalledPartyNumber
The final called party field specifies the login user
ID. The format of this field specifies UTF_8.
Default - Empty string . If the user ID does not
exist, this field stays empty.
Unicode
UTF_8
finalCalledPartyUnicodeLoginUserID
130 OL-28260-01
Values
Field Name
For clearing causes that are received over ISDN
signaling links, the ISDN release message indicates
this location field. See topics related to call
termination cause codes for a listing of the valid
values per Q.850.
For clearing causes that Cisco Unified
Communications Manager creates internally, this
value equals zero.
field stays 0.
0 to 15 destCause_location
For calls that the destination party cleared, this field
reflects the reason for the clearance. See topics
related to call termination cause codes for a listing
of the valid values per Q.850.
For calls that the originating party clears, this field
stays zero.
In addition to the standard values that are described
in Q.850, when a call gets split by a feature
(transfer/conference), the CDR terminates, and this
field gets set to 393216. This represents a proprietary
value for this field.
field stays 0.
0 to 129 destCause_value
For MLPP, each call leg has a precedence level. This
field represents the destination legs precedence level.
Precedence 0 = FLASH OVERRIDE
Precedence 1 = FLASH
Precedence 2 = IMMEDIATE
Precedence 3 = PRIORITY
Precedence 4 = ROUTINE
Default - 4
0 to 4 destPrecedenceLevel
OL-28260-01 131
Values
Field Name
that terminates the media for the call.
For Cisco Unified IP Phones, this field designates
the v4 address of the phone.
For PSTN calls, this field designates the v4 address
of the H.323 gateway.
For intercluster calls, this field shows the v4 address
of the remote phone.
Default - 0. If the destination cannot be reached or
the IP address of the destination is not v4, this field
stays 0.
0, Integer destMediaTransportAddress_IP
This field identifies the IP port number that is
associated with the DestMediaTransportAddress_IP
field.
field stays 0.
0, Positive
Integer
destMediaTransportAddress_Port
This field identifies the codec type that the
terminating party uses to transmit media.
uses the following payload capability values: 0, 1-16,
18-20, 25, 32, 33, 81-86. See topics related to codec
types for a listing of the valid values.
field stays 0.
0, Positive
Integer
destMediaCap_payloadCapability
This field identifies the number of milliseconds of
data per packet that the terminating party of the call
sends. This field normally gets set to 10, 20, or 30
for G.729 or G.711 codecs but can store any nonzero
value.
This field can specify zero if the media is never
established.
field stays 0.
0, Positive
Integer
destMediaCap_maxFramesPerPacket
This field is not used in the current release of Cisco
Default - This field stays 0.
0 destMediaCap_g723BitRate
132 OL-28260-01
Values
Field Name
terminating party uses to transmit video (H.261,
H.263, or H.264).
field stays 0.
0,
100 = H.261,
101 = H.263,
103 = H.264
destVideoCap_Codec
This field identifies the bandwidth, and is measured
in units of kbps.
field stays 0.
0, Positive
Integer
destVideoCap_Bandwidth
This field indicates the transmitting resolution. In
the case of H.264 codec or SIP device, this field
refers to the max transmitting resolution the device
can transmit for this call.
stays 0.
0,
1 = SQCIF,
2 = QCIF,
3 = CIF,
4 = CIF4,
5 = CIF16
6 = H263
custom
resolution
7 = W360P
8 = VGA
9 = W448P
10 =
HD720P
11 =
HD1080P
12 = CIF2
destVideoCap_Resolution
that receives the call.
Default - 0. If the destination cannot be reached or
the IP address of the destination is not v4, this field
stays 0.
0, Integer destVideoTransportAddress _IP
This field identifies the video RTP port that is
associated with the destVideoTransportAddress_IP
field.
field stays 0.
0, Positive
Integer
destVideoTransportAddress_Port
OL-28260-01 133
Values
Field Name
This field designates the status of the RSVP audio
reservation from terminator to originator.
0 No reservation.
(includes all mid call failures except MLPP
preemption).
Default 0
0 - 5 destRSVPAudioStat
This field designates the status of the RSVP video
reservation from terminator to originator.
0 No reservation.
(includes all mid call failures except MLPP
preemption).
Default 0
0 - 5 destRSVPVideoStat
This field identifies the date and time that the call
connects. The time gets stored as UTC. If the call is
never answered, this value shows zero.
Default - 0. If the call is never connected, this field
stays 0.
0, Integer dateTimeConnect
134 OL-28260-01
Values
Field Name
This field identifies the date and time when the call
is cleared. This field gets set even if the call never
connects. The time gets stored as UTC.
Integer dateTimeDisconnect
This field specifies a numeric string of up to 25
characters. The numeric string can contain digits or
a SIP URL.
For forwarded calls, this field specifies the phone
number of the next to last hop before the call reaches
its final destination. If only one hop occurs, this
number matches the OriginalCalledPartyNumber.
If a blended address is used for call addressing, this
field contains only the directory number portion of
the blended address.
For calls that are not forwarded, this field matches
the OriginalCalledPartyNumber and the
FinalCalledPartyNumber.
b0019901001).
Default - Empty string . If the call is never
redirected, or if the next to last hop address is a
directory URI, this field remains empty.
Text String lastRedirectDn
This field identifies a text string that the database
uses internally to uniquely identify each row. This
text string provides no meaning to the call itself.
Default - A unique ID should always populate this
field.
Text String pkid
This field uniquely identifies the partition name that
is associated with the OriginalCalledPartyNumber
field because Cisco Unified Communications
Manager supports multiple Cisco Unified IP Phones
with the same extension number in different
partitions.
For calls that egress through an H.323 gateway, this
field uniquely specifies the partition name that is
associated with the route pattern that points to the
gateway.
Default - Empty string . If the original called party
does not have a partition, this field remains empty.
Text String originalCalledPartyNumberPartition
OL-28260-01 135
Values
Field Name
is associated with the CallingPartyNumber field
because Cisco Unified Communications Manager
supports multiple Cisco Unified IP Phones with the
same extension number in different partitions.
For calls that ingress through an H.323 gateway, this
field remains blank.
Default - Empty string . If the original called party
Text String callingPartyNumberPartition
is associated with the FinalCalledPartyNumber field
because Cisco Unified Communications Manager
supports multiple Cisco Unified IP Phones with the
same extension number in different partitions.
field uniquely specifies the partition name that is
associated with the route pattern that points to the
gateway.
Default - Empty string . If the final called party
Text String finalCalledPartyNumberPartition
is associated with the LastRedirectDn field because
Cisco Unified Communications Manager supports
multiple Cisco Unified IP Phones with the same
extension number in different partitions.
field specifies the partition name that is associated
with the route pattern that points to the gateway.
Default - Empty string . If the last redirecting Party
does not have a partition or the call was never
redirected, this field stays empty.
Text String lastRedirectDnPartition
This field identifies the difference between the
Connect Time and Disconnect Time. This field
specifies the time that the call remains connected, in
seconds. This field remains zero if the call never
connects or if it connects for less than 1 second.
Default - 0
0, Positive
integer
duration
This field specifies the text string that identifies the
name of the originating device.
Text String origDeviceName
136 OL-28260-01
Values
Field Name
This field specifies the text string that identifies the
name of the destination device.
Default - Empty string . If the original device does
not have a name, this field stays empty.
Text String destDeviceName
This field specifies code that identifies why the
originator was terminated.
For example, if the originator of the call hangs up
the phone, the OnBehalfOf code shows 12 for
Device. If the call terminates because of a transfer,
the OnBehalfOf code shows 10 for Transfer.
See topics related to CDRfield descriptions for a list
of the codes. This release added new OnBehalfOf
codes.
Default - 0
0, Positive
Integer
origCallTerminationOnBehalfOf
This field specifies code that identifies why the
destination was terminated.
For example, if the originator of the call hangs up
the phone, the OnBehalfOf code shows 12 for
Device. If the call terminates because of a transfer,
the OnBehalfOf code shows 10 for Transfer.
codes.
Default - 0
0, Positive
Integer
destCallTerminationOnBehalfOf
This field specifies code that identifies the reason
for redirection of the original called party.
For example, if the original called party was
redirected because of a conference, the OnBehalfOf
code specifies 4.
codes.
Default - 0
0, Positive
Integer
origCalledPartyRedirectOnBehalfOf
OL-28260-01 137
Values
Field Name
for redirection of the last redirected party.
For example, if the last redirected party was
redirected on behalf of a conference, the OnBehalfOf
code specifies 4.
codes.
Default - 0
0, Integer lastRedirectRedirectOnBehalfOf
This field identifies the reason for a redirect of the
original called party.
See topics related to redirect reason codes for a
complete list of the codes.
Default - 0
0, Integer origCalledPartyRedirectReason
This field identifies the last redirect reason for
redirection.
See topics related to redirect reason codes for a
complete list of the codes.
Default - 0
0, Integer lastRedirectRedirectReason
This field specifies a unique identifier that is used to
identify the parties of a conference call.
For conference chaining scenarios, the
origConversationID and destConversationID fields
identify which conferences are chained together.
Default - 0
0, Integer destConversationID
This field specifies a unique ID that identifies a
cluster of Cisco Unified Communications Managers.
The field is generated at installation and is not used
by Cisco Unified Communications Manager. The
fields globalCallId_ClusterId + globalCallId_CMId
+ globalCallId_CallId make up this unique key.
Default - This field should always be populated.
Text String globalCallId_ClusterId
138 OL-28260-01
Values
Field Name
for a join.
For example, if the join takes place on behalf of a
transfer, the OnBehalfOf code specifies 10.
of the codes.
Default - 0
0, Integer joinOnBehalfOf
This field allows features to add text to the CDRs.
This text can describe details about the call.
For example, the following field flags malicious
calls:
TagCallFlag
ValueMALICIOUS
Default - Empty string .
Text String Comment
This field provides a description of the FAC.
Default - Empty string or null.
Text String authCodeDescription
This field displays the level of the FAC.
Default - 0
0, Integer authorizationLevel
Before the system extends a call, the user enters a
client matter code that can be used for assigning
account or billing codes to calls. This field displays
the client matter code.
Text String clientMatterCode
This field displays the DTMF method that the
originator uses.
0 - No DTMF - Use ANY matched DTMF.
1 - OOB - Use OOB if endpoints behind SIPTrunk
support it.
2 - 2833 - Use RFC2833 if endpoints behind
SIPTrunk support it.
3 - OOB and 2833 - Use both KPML and RFC2833
if endpoints behind SIPTrunk can support both.
4 - Unknown
Default - 0 (No preference)
0, Positive
Integer
origDTMFMethod
OL-28260-01 139
Values
Field Name
This field displays the DTMF method that the
destination uses.
0 - No DTMF - Use ANY matched DTMF.1 - OOB
- Use OOB if endpoints behind SIPTrunk support
it.2 - 2833 - Use RFC2833 if endpoints behind
SIPTrunk support it.3 - OOB and 2833 - Use both
KPML and RFC2833 if endpoints behind SIPTrunk
can support both.4 - Unknown.
Default - 0 (No preference)
0, Positive
Integer
destDTMFMethod
This field displays the highest security status that is
reached during a call. For example, if the call is
originally unsecured, then later the call changes to
secured, the CDR contains 1 for Secured even
though different portions of the call have different
status values.
0 - Non-secured
1 - Authenticated (not encrypted)
2 - Secured (encrypted)
Default - 0 (Non-secured)
0, Positive
Integer
callSecuredStatus
This field identifies the conference ID that is
associated with the originating leg of the call. In most
cases, this field equals 0.
For conference chaining scenarios, the
origConversationID and destConversationID fields
identify which conferences are chained together.
Default - 0
Integer origConversationID
This field displays the media bandwidth that is used
at the origination of the call.
Default - 0
0, Positive
Integer
origMediaCap_Bandwidth
This field displays the media bandwidth that is used
at the destination of the call.
Default - 0
0, Positive
Integer
destMediaCap_Bandwidth
This field displays the Forced Authorization Code
(FAC) that is associated with the call.
Text String authorizationCodeValue
140 OL-28260-01
Values
Field Name
This field comprises an alphanumeric string of up to
50 characters.
The calling party number gets outpulsed from the
device. This field gets populated only when
normalization or localization takes place at the
device.
Text String outpulsedCallingPartyNumber
50 characters.
The called party number gets outpulsed from the
device. This field gets populated only when
normalization or localization takes place at the
device.
Text String outpulsedCalledPartyNumber
64 characters.
This field identifies the IP address of the device that
originates the call signalling. The field can be either
IPv4 or IPv6 format depending on the type of IP
address that gets used for the call.
For Cisco Unified IP Phones, this field is the address
of the Cisco Unified IP Phone. For PSTN calls, this
field is the address of the gateway. For intercluster
calls, this field is the address of the remote Cisco
The IP address is either in dotted decimal format or
in colon separated hexadecimal format.
Default - The IP address of the originating device as
reported by the device or used for the call after media
negotiation.
Text string origIpv4v6Addr
OL-28260-01 141
Values
Field Name
64 characters.
This field identifies the IP address of the device that
terminates the call signalling. The field can be either
in IPv4 or IPv6 format depending upon the type of
IP address that gets used for the call.
For Cisco Unified IP Phones, this field is the address
of the Cisco Unified IP Phone. For PSTN calls, this
field is the address of the gateway. For intercluster
calls, this field is the address of the remote Cisco
The IP address is either in dotted decimal format or
in colon separated hexadecimal format.
Default - Empty String or null. If the destination
does not get reached, this field stays empty.
Text string destIpv4v6Addr
uses to transmit video (H.261, H.263, or H.264) for
the second video channel.
Default - 0. If media does not get established, this
field displays 0. Also, if H.239 and BFCP are not
supported for this call, this field displays 0
0,
100 = H.261,
101 = H.263,
103 = H.264,
origVideoCap_Codec_Channel2
This field identifies the bandwidth measured in units
of kbps for the second video channel.
supported for this call, this field displays 0.
0, Positive
integer
origVideoCap_Bandwidth_Channel2
142 OL-28260-01
Values
Field Name
This field indicates the transmitting resolution for
the second video channel. In the case of H.264 codec
or SIP device, this field refers to the maximum
transmitting resolution the device can transmit for
this call.
stays 0. Also, if H.239 and BFCP are not supported
for this call, this field displays 0.
0,
1 = SQCIF,
2 = QCIF,
3 = CIF,
4 = CIF4,
5 = CIF16
6 = H263
custom
resolution
7 = W360P
8 = VGA
9 = W448P
10 =
HD720P
11 =
HD1080P
12 = CIF2
origVideoCap_Resolution_Channel2
that originates the call for the second video channel.
0, Integer origVideoTransportAddress_IP_Channel2
This field identifies the video RTP port associated
with the origH239VideoTransportAddress_IP field
for the second video channel.
0, Positive
integer
origVideoTransportAddress_Port_Channel2
This field identifies the H.239 video channel role of
the device that originates.
field displays 0. Also, if H.239 is not supported, this
field displays 0.
0 =
Presentation
role,
1 = Live role,
Positive
integer
origVideoChannel_Role_Channel2
OL-28260-01 143
Values
Field Name
terminating party uses to transmit video (H.261,
H.263, or H.264) for the second video channel.
field stays 0. Also, if H.239 and BFCP are not
0,
100 = H.261,
101 = H.263,
103 = H.264
destVideoCap_Codec_Channel2
This field identifies the bandwidth measured in units
of kbps for the second video channel.
0, Positive
integer
destVideoCap_Bandwidth_Channel2
This field indicates the transmitting resolution for
the second video channel. In the case of H.264 codec
or SIP device, this field refers to the maximum
transmitting resolution the device can transmit for
this call.
stays 0. Also, if H.239 and BFCP are not supported
for this call, this field displays 0.
0,
1 = SQCIF,
2 = QCIF,
3 = CIF,
4 = CIF4,
5 = CIF16
6 = H263
custom
resolution
7 = W360P
8 = VGA
9 = W448P
10 =
HD720P
11 =
HD1080P
12 = CIF2
destVideoCap_Resolution_Channel2
that receives the call.
0, Integer destVideoTransportAddress_IP_Channel2
144 OL-28260-01
Values
Field Name
This field identifies the video RTP port associated
with the destH239VideoTransportAddress_IP field.
0, Positive
integer
destVideoTransportAddress_Port_Channel2
This field identifies the H.239 video channel role of
the device that receives the call.
field displays 0. Also, if H.239 is not supported, this
field displays 0.
0 =
Presentation
role,
1 = Live role,
Positive
integer
destVideoChannel_Role_Channel2
This field identifies the protocol (SIP, H.323,
CTI/JTAPI, or Q.931) used between Cisco Unified
CM and the upstream voice product in the call path.
0 =
Unknown,
1 = SIP,
2 = H323,
3 =
CTI/JTAPI,
4 = Q931,
Integer
IncomingProtocolID
This field identifies the globally unique call reference
identification for the protocol. The value is received
from the upstream voice product. The value is
alphanumeric and truncated to 32 characters.
Varchar(32) IncomingProtocolCallRef
This field identifies the protocol (SIP, H.323,
CTI/JTAPI, or Q.931) used between Cisco Unified
CM and the downstream voice product in the call
path.
0 =
Unknown,
1 = SIP,
2 = H323,
3 =
CTI/JTAPI,
4 = Q931,
Integer
OutgoingProtocolID
This field identifies the globally unique call reference
identification for the protocol. The value is passed
to the next downstream voiced product. The value
is alphanumeric and truncated to 32 characters.
Varchar(32) OutgoingProtocolCallRef
OL-28260-01 145
Values
Field Name
This field, which is used with the external call control
feature, displays the reason why the call was
intercepted for the current call. See topics related to
routing reason values for external call control for a
list of reasons.
Default value is 0.
Positive
Integer
currentRoutingReason
feature, displays the reason why the call was
intercepted for the first time. See topics related to
routing reason values for external call control for a
list of reasons.
Default value is 0.
Positive
Integer
origRoutingReason
feature, displays why the call was intercepted for the
last time. See topics related to routing reason values
for external call control for a list of reasons.
Default - Empty string.
Positive
Integer
lastRedirectingRoutingReason
This field indicates the hunt pilot DNthrough which
the call is routed.
Text String huntPilotDN
This field indicates the partition for the hunt pilot
DN.
Text String huntPilotPartition
This field indicates the pattern of the called party.
Default value specifies 5 (PATTERN_ROUTE).
If the huntPilotDN is populated, use the
huntPilotDN field value as the hunt pilot.
If the huntPilotDN is not available, check the
pattern usage (7 =PATTERN_HUNT_PILOT)
in the CDR table to identify the call type. If
this call is a hunt list call, use the
finalCalledPartyNumber as the huntPilotDN.
Positive
Integer
calledPartyPatternUsage
This field specifies whether the call has been put into
a queue or not. A value of 0 means that the call is
not put into any queue; 1 means the call has been put
into a queue.
Positive
Integer
wasCallQueued
146 OL-28260-01
Values
Field Name
This field specifies how long a caller has been put
into a queue. The value is specified in second. The
value is 0 if the call is never put into any queue.
Positive
Integer
totalWaitTimeInQueue
This field specifies an alphanumeric string of up to
254 characters that identifies the calling party if the
calling party uses a directory URI for call addressing.
If the calling party uses a blended address in the
identity headers, this field contains the directory URI
portion of the blended address.
Default - Empty string . If the calling party does
not use a directory URI, the field stays empty.
Text String callingPartyNumber_uri
This field specifies a string of up to 254
alphanumeric characters that specifies the directory
URI to which the original call was addressed, prior
to any call forwarding, provided the call was
addressed to a directory URI.
If a blended address is used for the called party, this
field specifies the directory URI portion of the
blended address.
reached, or if the called party is a directory number,
this field stays empty.
Text String originalCalledPartyNumber_uri
254 characters that indicate the directory URI address
to which the call finally gets presented, if the final
address is a directory URI. If no forwarding occurs,
this field shows the same directory URI as the
originalCalledPartyNumber_uri field.
If a blended address is used for the called number,
this field specifies the directory URI portion of the
blended address
b0019901001).
reached, or if a directory number is used for called
addressing, this field stays empty.
Text String finalCalledPartyNumber_uri
OL-28260-01 147
Values
Field Name
254 characters.
For forwarded calls that use a directory URI for
addressing, this field specifies the directory URI of
the next to last hop before the call reaches its final
destination. If only one hop occurs, this number
matches the originalCalledPartyNumber_uri.
If a blended address is used, this field contains only
the directory URI portion of the blended address.
For calls that are not forwarded, this field matches
the originalCalledPartyNumber_uri and the
finalCalledPartyNumber_uri.
b0019901001).
Default - Empty string . If the call is never
redirected, or if the address is a directory number,
this field remains empty.
Text String lastRedirectDn_uri
Related Topics
Call termination cause codes, on page 153
Codec types, on page 151
Convert signed decimal value to IP address, on page 13
Global call identifier, on page 10
Redirect reason codes, on page 159
Routing reason values for external call control, on page 148
Routing reason values for external call control
Cisco Unified Communications Manager supports the external call control feature, which enables an adjunct
route server to make call-routing decisions for Cisco Unified Communications Manager by using the Cisco
Unified Routing Rules Interface. When you configure external call control, Cisco Unified Communications
Manager issues a route request that contains the calling party and called party information to the adjunct route
server. The adjunct route server receives the request, applies appropriate business logic, and returns a route
response that instructs Cisco Unified Communications Manager on how the call should get routed, along with
any additional call treatment that should get applied.
148 OL-28260-01
The adjunct route server can instruct Cisco Unified Communications Manager to allow, divert, or deny the
call, modify calling and called party information, play announcements to callers, reset call history so adjunct
voicemail and IVR servers can properly interpret calling/called party information, and log reason codes that
indicate why calls were diverted or denied.
The following table includes the reasons that can display for the currentRoutingReason, origRoutingReason,
or lastRedirectingRoutingReason fields.
Table 4: Routing Reason Values for External Call Control
Description Reason Field Value
This value indicates that the route server did not return
a routing directive to the Cisco Unified
PDPDecision_NONE 0
This value indicates that Cisco Unified
Communications Manager allowed a call.
PDPDecision_Allow_Fulfilled 1
Communications Manager disallowed a call.
PDPDecision_Allow_Unfulfilled 2
Communications Manager diverted the call.
PDPDecision_Divert_Fulfilled 3
Communications Manager was not able to divert the
call.
PDPDecision_Divert_Unfulfilled 4
Communications Manager forwarded the call.
PDPDecision_Forward_Fulfilled 5
Communications Manager was unable to forward the
call.
PDPDecision_Forward_Unfulfilled 6
Communications Manager rejected the call.
PDPDecision_Reject_Fulfilled 7
Communications Manager was not able to reject the
call.
PDPDecision_Reject_Unfulfilled 8
Related Topics
Redirect reason codes, on page 159
OL-28260-01 149
150 OL-28260-01
C HAP T E R 6
Cisco call detail records codes
This chapter provides information about the codec types and codes that are used in the Call Detail Record
fields.
Codec types, page 151
Call termination cause codes, page 153
Redirect reason codes, page 159
OnBehalfof codes, page 162
Codec types
The following table contains the compression and payload types that may appear in the codec fields.
Table 5: Codec Types
Description Value
NonStandard 1
G711Alaw 64k 2
G711Alaw 56k 3
G711mu-law 64k 4
G711mu-law 56k 5
G722 64k 6
G722 56k 7
G722 48k 8
G7231 9
OL-28260-01 151
Description Value
G728 10
G729 11
G729AnnexA 12
Is11172AudioCap 13
Is13818AudioCap 14
G.729AnnexB 15
G.729 Annex AwAnnexB 16
GSM Full Rate 18
GSM Half Rate 19
GSM Enhanced Full Rate 20
Wideband 256K 25
Data 64k 32
Data 56k 33
G7221 32K 40
G7221 24K 41
AAC-LD (mpeg4-generic) 42
AAC-LD (MP4A-LATM) 128K 43
GSM 80-
ActiveVoice 81
152 OL-28260-01
Codec types
Description Value
G726 32K 82
G726 24K 83
G726 16K 84
iLBC 86
iSAC 89
H261 100
H263 101
Vieo 102
H264 103
H224 106
Related Topics
Call termination cause codes
The following tables contain call termination cause codes that may appear in the Cause fields in CDRs.
Cause Code is defined in call control as Natural number. It is a 32 bit unsigned (long) positive integer
with values ranging from 0 to +4,294,967,295.
Note
Table 6: Call Termination Cause Codes
Description Code
No error 0
Unallocated (unassigned) number 1
No route to specified transit network (national use) 2
No route to destination 3
OL-28260-01 153
Description Code
Send special information tone 4
Misdialed trunk prefix (national use) 5
Channel unacceptable 6
Call awarded and being delivered in an established channel 7
Preemption 8
Preemptioncircuit reserved for reuse 9
Normal call clearing 16
User busy 17
No user responding 18
No answer from user (user alerted) 19
Subscriber absent 20
Call rejected 21
Number changed 22
Non-selected user clearing 26
Destination out of order 27
Invalid number format (address incomplete) 28
Facility rejected 29
Response to STATUS ENQUIRY 30
Normal, unspecified 31
No circuit/channel available 34
Network out of order 38
Permanent frame mode connection out of service 39
Permanent frame mode connection operational 40
Temporary failure 41
154 OL-28260-01
Description Code
Switching equipment congestion 42
Access information discarded 43
Requested circuit/channel not available 44
Precedence call blocked 46
Resource unavailable, unspecified 47
Quality of Service not available 49
Requested facility not subscribed 50
Service operation violated 53
Incoming calls barred 54
Incoming calls barred within Closed User Group (CUG) 55
Bearer capability not authorized 57
Bearer capability not presently available 58
Inconsistency in designated outgoing access information and subscriber class 62
Service or option not available, unspecified 63
Bearer capability not implemented 65
Channel type not implemented 66
Requested facility not implemented 69
Only restricted digital information bearer capability is available (national use) 70
Service or option not implemented, unspecified 79
Invalid call reference value 81
Identified channel does not exist 82
A suspended call exists, but this call identity does not 83
Call identity in use 84
No call suspended 85
OL-28260-01 155
Description Code
Call having the requested call identity has been cleared 86
User not member of CUG (Closed User Group) 87
Incompatible destination 88
Destination number missing and DC not subscribed 90
Invalid transit network selection (national use) 91
Invalid message, unspecified 95
Mandatory information element is missing 96
Message type nonexistent or not implemented 97
Message is not compatible with the call state, or the message type is nonexistent or not implemented 98
An information element or parameter does not exist or is not implemented 99
Invalid information element contents 100
The message is not compatible with the call state 101
Call terminated when timer expired; a recovery routine executed to recover from the error 102
Parameter nonexistent or not implemented - passed on (national use) 103
Message with unrecognized parameter discarded 110
Protocol error, unspecified 111
Precedence Level Exceeded 122
Device not Preemptable 123
Out of bandwidth (Cisco specific) 125
Call split (Cisco specific) 126
Interworking, unspecified 127
Precedence out of bandwidth 129
Call Control Discovery PSTN Failover (Cisco specific) 131
IME QOS Fallback (Cisco specific) 132
156 OL-28260-01
Description Code
PSTN Fallback locate Call Error (Cisco specific) 133
PSTN Fallback wait for DTMF Timeout (Cisco specific) 134
IME Failed Connection Timed out (Cisco specific) 135
IME Failed not enrolled (Cisco specific) 136
IME Failed socket error (Cisco specific) 137
IME Failed domain blacklisted (Cisco specific) 138
IME Failed prefix blacklisted (Cisco specific) 139
IME Failed expired ticket (Cisco specific) 140
IME Failed remote no matching route (Cisco specific) 141
IME Failed remote unregistered (Cisco specific) 142
IME Failed remote IME disabled (Cisco specific) 143
IME Failed remote invalid IME trunk URI (Cisco specific) 144
IME Failed remote URI not E164 (Cisco specific) 145
IME Failed remote called number not available (Cisco specific) 146
IME Failed Invalid Ticket (Cisco specific) 147
IME Failed unknown (Cisco specific) 148
Table 7: Cisco-Specific Call Termination Cause Codes
Description Hex Value
Code
Decimal Value
Code
Conference Full (was 124) 0x40000 262144
Call split (was 126)This code applies when a call terminates during a
transfer operation because it was split off and terminated (was not part of
the final transferred call). This code can help you to determine which calls
terminated as part of a feature operation.
0x60000 393216
Conference drop any party/Conference drop last party (was 128) 0x70000 458752
CCM_SIP_400_BAD_REQUEST 0x1000029 16777257
OL-28260-01 157
Code
Decimal Value
Code
CCM_SIP_401_UNAUTHORIZED 0x2000015 33554453
CCM_SIP_402_PAYMENT_REQUIRED 0x3000015 50331669
CCM_SIP_403_FORBIDDEN 0x4000015 67108885
CCM_SIP_404_NOT_FOUND 0x5000001 83886081
CCM_SIP_405_METHOD_NOT_ALLOWED 0x600003F 100663359
CCM_SIP_406_NOT_ACCEPTABLE 0x700004F 117440591
CCM_SIP_407_PROXY_AUTHENTICATION_REQUIRED 0x8000015 134217749
CCM_SIP_408_REQUEST_TIMEOUT 0x9000066 150995046
CCM_SIP__410_GONE 0xB000016 184549398
CCM_SIP_411_LENGTH_REQUIRED 0xC00007F 201326719
CCM_SIP_413_REQUEST_ENTITY_TOO_LONG 0xE00007F 234881151
CCM_SIP_414_REQUEST_URI_TOO_LONG 0xF00007F 251658367
CCM_SIP_415_UNSUPPORTED_MEDIA_TYPE 0x1000004F 268435535
CCM_SIP_416_UNSUPPORTED_URI_SCHEME 0x1100007F 285212799
CCM_SIP_420_BAD_EXTENSION 0x1500007F 83886207
CCM_SIP_421_EXTENSION_REQUIRED 0x1600007F 369098879
CCM_SIP_423_INTERVAL_TOO_BRIEF 0x1800007F 402653311
CCM_SIP_424_BAD_LOCATION_INFO 0x19000015 419430421
CCM_SIP_480_TEMPORARILY_UNAVAILABLE 0x40000012 1073741842
CCM_SIP_481_CALL_LEG_DOES_NOT_EXIST 0x41000029 1090519081
CCM_SIP_482_LOOP_DETECTED = 0x42000000 +
EXCHANGE_ROUTING_ERROR
0x42000019 1107296281
CCM_SIP_483_TOO_MANY_HOOPS 0x43000019 1124073497
CCM_SIP_484_ADDRESS_INCOMPLETE 0x4400001C 1140850716
CCM_SIP_485_AMBIGUOUS 0x45000001 1157627905
158 OL-28260-01
Code
Decimal Value
Code
CCM_SIP_486_BUSY_HERE 0x46000011 1174405137
CCM_SIP_487_REQUEST_TERMINATED 0x4700001F 1191182367
CCM_SIP_488_NOT_ACCEPTABLE_HERE 0x4800001F 1207959583
CCM_SIP_491_REQUEST_PENDING 0x4B000011 1258291217
CCM_SIP_493_UNDECIPHERABLE 0x4D000011 1291845649
CCM_SIP_500_SERVER_INTERNAL_ERROR 0x54000029 1409286185
CCM_SIP_502_BAD_GATEWAY 0x56000026 1442840614
CCM_SIP_503_SERVICE_UNAVAILABLE 0x57000029 1459617833
CCM_SIP_503_SERVICE_UNAVAILABLE_SER_OPTION_NOAV 0xA700003F 2801795135
CCM_SIP__504_SERVER_TIME_OUT 0x58000066 1476395110
CCM_SIP_505_SIP_VERSION_NOT_SUPPORTED 0x5900007F 1493172351
CCM_SIP_513_MESSAGE_TOO_LARGE 0x5A00007F 1509949567
CCM_SIP_600_BUSY_EVERYWHERE 0xA1000011 2701131793
CCM_SIP_603_DECLINE 0xA2000015 2717909013
CCM_SIP_604_DOES_NOT_EXIST_ANYWHERE 0xA3000001 2734686209
CCM_SIP_606_NOT_ACCEPTABLE 0xA400001F 2751463455
Redirect reason codes
The following table contains the available Redirect Reason Codes that may appear in a record.
Q.931 Standard Redirect Reason Codes
Description Value
Unknown 0
Call Forward Busy 1
Call Forward No Answer 2
OL-28260-01 159
Description Value
Call Transfer 4
Call Pickup 5
Call Park 7
Call Park Pickup 8
CPE Out of Order 9
Call Forward 10
Call Park Reversion 11
Call Forward all 15
Nonstandard Redirect Reason Codes
Call Deflection 18
Blind Transfer 34
Call Immediate Divert 50
Call Forward Alternate Party 66
Call Forward On Failure 82
Conference 98
Barge 114
Aar 129
Refer 130
Replaces 146
Redirection (3xx) 162
SIP-forward busy greeting 177
Call Forward Unregistered 178
Follow Me (SIP-forward all greeting) 207
Out of Service (SIP-forward busy greeting) 209
160 OL-28260-01
Description Value
Time of Day (SIP-forward all greeting) 239
Do Not Disturb (SIP-forward no answer greeting) 242
Unavailable (SIP-forward busy greeting) 257
Away (SIP-forward no answer greeting) 274
Mobility HandIn 303
Mobility HandOut 319
Mobility Follow Me 335
Recording 354
Monitoring 370
Mobility IVR 399
Mobility Cell Pickup 415
Click to Conference 418
Forward No Retrieve 434
Forward No Retrieve Send Back to Parker 450
Call Control Discovery (indicates that the call is redirected to a PSTN
failover number)
464
Intercompany Media Engine (IME) 480
IME Connection Timed Out 496
IME Not Enrolled 512
IME Socket Error 528
IME Domain Blacklisted 544
IME Prefix Blacklisted 560
IME Expired Ticket 576
IME Remote No Matching Route 592
OL-28260-01 161
Description Value
IME Remote Unregistered 608
IME Remote IME Disabled 624
IME Remote Invalid IME Trunk URI 640
IME Remote URI not E164 656
IME Remote Called Number Not Available 672
IME Invalid Ticket 688
IME Unknown 704
IME PSTN Fallback 720
Presence Enabled Routing 738
Agent Greeting 752
Native Call Queuing, queue a call 786
Native Call Queuing, de-queue a call 802
Native Call Queuing, redirect to the second destination when no agent is
logged in
818
Native Call Queuing, redirect to the second destination when the queue is
full
834
Native Call Queuing, redirect to the second destination when the maximum
wait time in queue is reached
850
OnBehalfof codes
The following table contains the available OnBehalfof Codes that may appear in a CDR record.
Table 8: OnBehalfof Codes
Description Value
Unknown 0
CctiLine 1
162 OL-28260-01
OnBehalfof codes
Description Value
Unicast Shared Resource Provider 2
Call Park 3
Conference 4
Call Forward 5
Meet-Me Conference 6
Meet-Me Conference Intercepts 7
Message Waiting 8
Multicast Shared Resource Provider 9
Transfer 10
SSAPI Manager 11
Device 12
Call Control 13
Immediate Divert 14
Barge 15
Pickup 16
Refer 17
Replaces 18
Redirection 19
Callback 20
Path Replacement 21
FacCmc Manager 22
Malicious Call 23
Mobility 24
Aar 25
OL-28260-01 163
OnBehalfof codes
Description Value
Directed Call Park 26
Recording 27
Monitoring 28
CCDRequestingService 29
Intercompany Media Engine 30
FallBack Manager 31
Presence Enabled Routing 32
AgentGreeting 33
NativeCallQueuing 34
164 OL-28260-01
OnBehalfof codes
PAR T III
Call management records
Call management records, page 167
Cisco call management record field descriptions, page 171
Cisco call management records K-factor data, page 177
Example Cisco call management records, page 181
C HAP T E R 7
This chapter describes the format and logic of the call management records (CMRs) that the Cisco Unified
Communications Manager system generates, and how to access the CMR files.
Call management records, page 167
CMR processing, page 167
Set up CMRs, page 168
CPU utilization, page 169
The Cisco Unified Communications Manager system generates call management records (CMRs) . You can
use this information for post-processing activities such as generating billing records and network analysis.
When you install your system, CMRs remain disabled by default. You can enable or disable CMRs at any
time that the system is in operation. You do not need to restart Cisco Unified Communications Manager for
the change to take effect. The system responds to all changes within a few seconds. The system enables CMR
or diagnostic data separately from CDR data.
Related Topics
Cisco call management records K-factor data, on page 177
CMR processing
The CMR records store information about the quality of the streamed audio of the call.
When Cisco Unified Communications Manager places or receives a call, the system generates a CDR record
when the call terminates. The system writes the CDR to a flat file (text file). Inside the Cisco Unified
Communications Manager, the call control process generates CDR records. The system writes records when
significant changes occur to a given call, such as ending the call, transferring the call, redirecting the call,
splitting the call, joining a call, and so forth.
OL-28260-01 167
When CMR records are enabled, 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 sends these records to EnvProcessCdr where they get written to flat files.
The Cisco Unified Communications Manager generates CMRrecords but does not performany post processing
on the records. The system writes the records to comma-delimited flat files and periodically passes them to
the CDR Repository. The 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
tagIdentifies the type of file, either CDR or CMR.
clusterIdIdentifies the cluster or server where the Cisco Unified Communications Manager database
exists.
nodeIdIdentifies the node.
datetimeSpecifies UTC time in yyyymmddhhmm format.
seqnumberSpecifies sequence number.
An example of the filename follows:
cmr_Cluster1_02_200404061011_6125
For Cisco Unified Communications Manager Business Edition 5000 installations, the value that is assigned
to the clusterId equals 01.
Note
Flat file format
The CMR flat files have the following format:
Line 1List of field names in comma separated format.
Line 2List of field types in comma separated format.
Line 3Data in comma separated format.
Line 4Data in comma separated format.
The following example shows a flat file:
Line1-cmrRecordType,globalCallID_callManagerId,globalCallID_callId,origLegCallIdentifier,...
Line2-INTEGER,INTEGER,INTEGER,INTEGER,...
Line3-1,1,388289,17586046,...
Line4-1,1,388293,17586054,...
Set up CMRs
You can configure CMRs on the Service Parameters Configuration windowin Cisco Unified Communications
Manager Administration. To access the Service Parameters Configuration window, open Cisco Unified
168 OL-28260-01
Set up CMRs
Communications Manager Administration and choose System> Service Parameters. Choose the Advanced
button to display the complete list of Service Parameters. Select the Call Diagnostics Enabled parameter.
This parameter determines whether the system generates CMRs, also called call 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.
CPU utilization
Cisco has performed basic testing to measure CPU utilization when CDRs and/or CMRs are enabled. The
CPU utilization testing was measured on subscribers and was not measured on the publishers. Your actual
results can vary because of the CDR Loader settings and the CDR Management settings for external billing
servers. The following table displays the results of these tests.
Be aware that these tests were performed with Cisco Unified Communications Manager Release 8.0(1). Note
Table 9: CDR and CMR CPU Utilization
% Increase in
Total CPU
% Increase in
Cisco Unified
CM CPU
Average %
Increase in Total
CPU Utilization
Average %
Increase in
Cisco Unified
CM CPU
Utilization
CDRs and CMRs Enabled/Disabled
- - 11.15 6.17 CDRs disabled, CMRs disabled
8.57 13.18 12.10 6.99 CDRs enabled, CMRs disabled
0.86 3.43 11.24 6.38 CDRs disabled, CMRs enabled
17.02 24.92 13.04 7.71 CDRs enabled, CMRs enabled
OL-28260-01 169
CPU utilization
170 OL-28260-01
CPU utilization
C HAP T E R 8
Cisco call management record field descriptions
This chapter describes the field descriptions of the Call Management Records (CMRs).
CMR field descriptions, page 171
CMR field descriptions
The following table contains the fields, range of values, and field descriptions of the CMRs in the order in
which they appear in the CMR.
Table 10: CMR Field Descriptions
Values
Field Name
This field specifies the type of this specific
record. The following valid values apply:
0Start call detail record (not used)
1End call detail record
2CMR record
Default - For CMRs, this field always specifies
2.
0, 1, or 2 cdrRecordType
OL-28260-01 171
Values
Field Name
This field specifies a unique Cisco Unified
Communications Manager identity.
This field makes up half of the Global Call
ID. The Global Call ID comprises the
following fields:
globalCallId_callId
globalCallID_callManagerID
All records that are associated with a standard
call have the same Global Call ID in them.
Positive
Integer
This field specifies a unique call identity value
that gets assigned to each call. The system
allocates this identifier independently on each
call server. Values get chosen sequentially
when a call begins. Each call, successful or
unsuccessful, receives value assignment.
This field makes up half the Global Call ID.
The Global Call ID comprises the following
two fields:
globalCallId_callId
globalCallID_callManagerID
All records that are associated with a standard
call have the same Global Call ID in them.
Positive
Integer
globalCallId_callId
This field specifies the server, or node within
the Cisco Unified Communications Manager
cluster, where this record gets generated.
Positive
Integer
nodeId
This field identifies the call leg to which this
record pertains.
Positive
Integer
callIdentifier
This field specifies the directory number of
the device from which these diagnostics are
collected.
Integer directoryNumber
172 OL-28260-01
Values
Field Name
This field represents the approximate time that
the device goes on hook. Cisco Unified
Communications Manager records the time
when the phone responds to a request for
diagnostic information.
Integer dateTimeStamp
This field designates the total number of
Routing Table Protocol (RTP) data packets
that the device transmits since starting
transmission on this connection. The value
remains zero if the connection is set to receive
only mode.
Default - 0
Integer numberPacketsSent
This field specifies the total number of payload
octets (that is, not including header or
padding) that the device transmits in RTP data
packets since starting transmission on this
connection. The value remains zero if the
connection is set to receive only mode.
Default - 0
Integer numberOctetsSent
This field specifies the total number of RTP
data packets that the device has received since
starting reception on this connection. The
count includes packets that are received from
different sources if this is a multicast call. The
value remains zero if the connection is set in
send only mode.
Default - 0
Integer numberPacketsReceived
This field specifies the total number of payload
octets (that is, not including header or
padding) that the device has received in RTP
data packets since starting reception on this
connection. The count includes packets that
are received from different sources if this is a
multicast call. The value remains zero if the
connection is set in send only mode.
Default - 0
Integer numberOctetsReceived
OL-28260-01 173
Values
Field Name
This field designates the total number of RTP
data packets that have been lost since the
beginning of reception. This number
designates the number of packets that were
expected, less the number of packets that were
actually received, where the number of packets
that were received includes any that are late
or duplicates. Thus, packets that arrive late do
not get counted as lost, and the loss may be
negative if duplicate packets exist. The number
of packets that are expected designates the
extended last sequence number that was
received, as defined next, less the initial
sequence number that was received. The value
remains zero if the connection was set in send
only mode. For detailed information, see RFC
1889.
Default - 0
Integer numberPacketsLost
This field provides an estimate of the statistical
variance of the RTP data packet interarrival
time, measured in milliseconds and expressed
as an unsigned integer. The interarrival jitter
J specifies the mean deviation (smoothed
absolute value) of the difference D in packet
spacing at the receiver, compared to the sender
for a pair of packets. RFC 1889 contains
detailed computation algorithms. The value
remains zero if the connection was set in send
only mode.
Default - 0
Integer jitter
174 OL-28260-01
Values
Field Name
This field designates value that is an estimate
of the network latency, expressed in
milliseconds. This value represents the average
value of the difference between the NTP
timestamp that the RTP Control Protocol
(RTCP) messages indicates and the NTP
timestamp of the receivers, measured when
these messages are received. Cisco Unified
Communications Manager obtains the average
by summing all estimates then dividing by the
number of RTCP messages that have been
received. For detailed information, see RFC
1889.
Default - 0
CMR records will not show latency
for all phone loads. For example, for
SIP 9.2.1 and 9.2.2, the latency will
not show, as it has not been
implemented in these loads.
Note
Integer latency
This field identifies a text string that the
database uses internally to uniquely identify
each row. This text string provides no meaning
to the call itself.
Default - The system always populates this
field with a unique ID.
Text String pkid
This field identifies the partition of the
directory number.
Default - Empty string, . This field may
remain empty if no partition exists.
Text String directoryNumberPartition
This field identifies the name of the device.
Default - Empty string . This field may
remain empty if no device name exists.
Text String deviceName
OL-28260-01 175
Values
Field Name
This field designates a unique ID that
identifies a single Cisco Unified
Communications Manager, or a cluster of
Cisco Unified Communications Managers.
The system generates this field during
installation, but Cisco Unified
Communications Manager does not use it:
globalCallId_ClusterId +
globalCallId_callManagerId +
globalCallId_callId.
Text String globalCallId_ClusterId
This field contains a variable number of voice
quality metrics. This field comprises a string
of voice quality metrics that are separated by
a semicolon.
The format of the string follows:
fieldName=value;fieldName=value.precision
This example shows voice quality data, but
the names may differ.
"MLQK=4.5000;MLQKav=4.5000;
MLQKmn=4.5000;MLQKmx=4.5000;MLQKvr=0.95;
CCR=0.0000;ICR=0.0000;ICRmx=0.0000;
CS=0;SCS=0
See topics related to K-factor data
stored in Cisco Unified
Communications Manager CMRs for
a complete list of K-Factor data.
Note
Text String varVQMetrics
Related Topics
176 OL-28260-01
C HAP T E R 9
Cisco call management records K-factor data
This chapter provides information about the K-factor data that is present in the Cisco call management records
(CMRs).
K-factor data, page 177
K-factor data
K-factor represents an endpoint mean opinion score (MOS) estimation algorithmthat is defined in ITUstandard
P.VTQ. It represents a general estimator that is used to estimate the mean value of a perceptual evaluation of
speech quality (PESQ) population for a specific impairment pattern.
MOS relates to the output of a well designed listening experiment. All MOS experiments use a five-point
PESQ scale as defined in ITU standard P.862.1, which describes the PESQ as an objective method for
end-to-end speech quality assessment of narrow-band telephone networks and speech codecs.
The MOS estimate provides a number that is inversely proportional to frame loss density. Clarity decreases
as more frames are lost or discarded at the receiving end. Consider the loss or discarding of these frames as
concealment. Concealment statistics measure packet (frame) loss and its effect on voice quality in an impaired
network.
K-factor represents a weighted estimate of average user annoyance due to distortions that are caused by
effective packet loss such as dropouts and warbles. It does not estimate the impact of delay-related impairments
such as echo. It provides an estimate of listening quality (MOS-LQO) rather than conversational quality
(MOS-CQO), and measurements of average user annoyance range from1 (poor voice quality) to 5 (very good
voice quality).
K-factor gets trained or conditioned by speech samples from numerous speech databases, where each training
sentence or network condition that is associated with a P.862.1 value has a duration of 8 seconds. For more
accurate scores, the system generates k-factor estimates for every 8 seconds of active speech.
Consider K-factor and other MOS estimators to be secondary or derived statistics because they warn a network
operator of frame loss only after the problem becomes significant. Packet counts, concealment ratios, and
concealment second counters represent primary statistics because they alert the network operator before
network impairment has an audible impact or is visible through MOS.
The following table displays the K-factor date that is stored in the Cisco Unified Communications Manager
CMRs.
OL-28260-01 177
Table 11: K-Factor Data Stored in Cisco Unified Communications Manager CMRs
D&I User Interface Text and Description Phone Display Name Field Name
Cumulative Conceal Ratio represents the
cumulative ratio of concealment time over speech
time that is observed after starting a call.
Cum Conceal Ratio CCR
Interval Conceal Ratio represents an interval-based
average concealment rate that is the ratio of
concealment time over speech time for the last
3 seconds of active speech.
Interval Conceal Ratio ICR
Interval Conceal Ratio Max represents the
maximumconcealment ratio that is observed during
the call.
Max Conceal Ratio ICRmx
Conceal Secs represents the time during which
some concealment is observed during a call.
Conceal Secs CS
Severely Conceal Secs represents the time during
which a significant amount of concealment is
observed. If the concealment that is observed is
usually greater than 50 milliseconds or
approximately 5 percent, the speech probably does
not seem very audible.
Severely Conceal Secs SCS
MOS Listening Quality K-factor provides an
estimate of the MOS score of the last 8 seconds of
speech on the reception signal path.
MOS LQK MLQK
MOS Listening Quality K-factor Min represents
the minimum score that is observed since the
beginning of a call and represents the worst
sounding 8-second interval.
Min MOS LQK MLQKmn
MOS Listening Quality K-factor Max represents
the maximum score that is observed since the
beginning of a call and represents the best sounding
8-second interval.
Max MOS LQK MLQKmx
MOS Listening Quality K-factor Avg8 represents
the running average of scores that are observed
since the beginning of a call.
Avg MOS LQK MLQKav
The following table displays the devices that support K-factor (varQMetrics) in the CMR.
The K-factor support legend follows:
XSupported by phones that are running both SCCP and SIP
178 OL-28260-01
K-factor data
SSCCP feature only
SISIP feature only
GAvailable on Cisco 5510 DSPs only
Table 12: Devices That Support K-factor (varVQMetrics) in CMRs
K-factor (varVQMetrics) Support in CMR Device
X Cisco Unified IP Phone 7906
S Cisco Unified IP Phone 7940
X Cisco Unified IP Phone 7942-G
X Cisco Unified IP Phone 7942-G/GE
S Cisco Unified IP Phone 7960
X Cisco Unified IP Phone 7962-G
G 3x MGCP Gateways
G 5x MGCP Gateways
OL-28260-01 179
K-factor data
Related Topics
180 OL-28260-01
K-factor data
C HAP T E R 10
Example Cisco call management records
This chapter provides examples of call management records (CMRs).
CMR examples, page 181
CMR examples
The following examples of CMRs get generated during a normal call (IP phone to IP phone). Normal calls
log three records per call: one CDR and two CMRs (one for each endpoint).
These examples represent a call between directory number 1010 and 1014. See related topics for a sample of
the CDR that gets generated during a normal call.
CMR 1
AAC CDR Field Names
2 cdrRecordType
1 globalCallID_callManagerid
1 nodeId
28141535 callIdentifier
1010 directoryNumber
1202412060 dateTimeStamp
358 numberPacketsSent
61576 numberOctetsSent
351 numberPacketsReceived
OL-28260-01 181
AAC CDR Field Names
60372 numberOctetsReceived
1 numberPacketsLost
0 jitter
0 latency
e95df5b1-2914-4a03-befb-0f58bf16392d pkid
directoryNumberPartition
SEP003094C39BE7 deviceName
StandAloneCluster globalCallId_ClusterId
MLQK=0.0000;MLQKav=0.0000;
CCR=0.0000;ICR=0.0000;ICRmx=0.0000;CS=0; SCS=0
varVQMetrics
CMR 2
AAC CDR Field Names
2 cdrRecordType
1 globalCallID_callManagerid
1 nodeId
28141536 callIdentifier
1004 directoryNumber
1202412060 dateTimeStamp
352 numberPacketsSent
60544 numberOctetsSent
356 numberPacketsReceived
61232 numberOctetsReceived
1 numberPacketsLost
182 OL-28260-01
CMR examples
AAC CDR Field Names
0 jitter
0 latency
545ff25a-5475-4882-af09-c7b714802703 pkid
directoryNumberPartition
SEP007EBBA6376 deviceName
StandAloneCluster globalCallId_ClusterId
MLQK=0.0000;MLQKav=0.0000;
CCR=0.0000;ICR=0.0000;ICRmx=0.0000;CS=0; SCS=0
varVQMetrics
Related Topics
Normal calls (Cisco Unified IP Phone to Cisco Unified IP Phone), on page 95
OL-28260-01 183
CMR examples
184 OL-28260-01
CMR examples
I NDE X
A
AAC calls 17
AAC calls CDR example 17
abandoned calls 20
abandoned calls CDR example 20
ad hoc conference linking 21
Agent Greeting Calls 34
authCodeDescription 121
CDR field name 121
authorizationCodeValue 121
CDR field name 121
authorizationLevel 121
CDR field name 121
auto pickup 43
CDR example 43
B
Backup CDR data 6
barge 35
CDR examples 35
billing server 3, 4, 169
blind transfer from the called party 112
CDR example 112
blind transfer from the calling Party 112
CDR example 112
C
call control process 7, 167
call Diagnostics enabled service parameter 168
call management records 167, 171, 177, 181
K-Factor data 177
call monitoring 38
CDR examples 38
call park 40
call park pickup 40
CDR example 40
call park reversion 41
CDR example 41
call pickup 42
call recording 45
CDR example 45
call secured status 47
CDR example 47
call secured status scenarios 47
call termination cause codes 153
Cisco-specific, table 153
table 153
called party normalization 85
CDR example 85
called party transformation 85
callIdentifier 171
CMR field name 171
calling party normalization 48
CDR example 48
callingPartyNumber 111, 121
CDR field name 121
URL 111
callingPartyNumberPartition 121
CDR field name 121
callingPartyUnicodeLoginUserID 121
CDR field name 121
calls 87
logical partitioning 87
calls with busy or bad destinations 49
callSecuredStatus 121
CDR field name 121
CAR 3, 7, 9, 17, 121, 151
CDR/CMR records configuration 3, 7, 9, 17, 121, 151
cBarge 51
CDR example 51
CDR Agent 4
CDR example 87, 111
SIP call with URL in callingpartynumber field 111
CDR Log Calls With Zero Duration Flag service parameter 20
CDR Management 3
CDR onDemand Service 5
CDR processing 167
OL-28260-01 IN-1
CDR repository 7, 167
CDR Repository Manager 4
CDRM feature 3
cdrRecordType 121, 171
CDR field name 121
CMR field name 171
Cisco Unified IP Phone 177
K-Factor support 177
Cisco-specific call termination cause codes 153
table 153
client matter code 52
CDR example 52
clientMatterCode 121
CDR field name 121
CMC 52
CDR example 52
CMR 168
configuring 168
CMR Field Descriptions (Diagnostic) 171
table 171
CMR records 171, 181
codec types 151
table 151
comment 121
CDR field name 121
conference call 53
CDR example 53
conference calls 53
conference drop any party 57
CDR example 57
conference linking 21, 24, 31
removing the linked conference 31
using transfer or direct transfer 24
conference linking using join 22
conference linking using join CDR example 22
conference linking using transfer or direct transfer 24
CDR example 24
configuring CMRs 168
consultation transfer from the called party 112
CDR example 112
consultation transfer from the calling party 112
CDR example 112
CPU utilization 169
D
dateTimeConnect 121
CDR field name 121
dateTimeDisconnect 121
CDR field name 121
dateTimeOrigination 121
CDR field name 121
dateTimeStamp 171
CMR field name 171
destCallTerminationOnBehalfOf 121
CDR field name 121
destCause_location 121
destCause_value 121
CDR field name 121
destConversationID 121
CDR field name 121
destDeviceName 121
CDR field name 121
destDTMFMethod 121
CDR field name 121
destIpAddr 121
CDR field name 121
destLegCallIdentifier 121
CDR field name 121
destMediaCap_Bandwidth 121
CDR field name 121
destMediaCap_g723BitRate 121
CDR field name 121
destMediaCap_maxFramesPerPacket 121
CDR field name 121
destMediaCap_payloadCapability 121
CDR field name 121
destMediaTransportAddress_IP 121
CDR field name 121
destMediaTransportAddress_Port 121
CDR field name 121
destNodeId 121
CDR field name 121
destPrecedenceLevel 121
CDR field name 121
destRSVPAudioStat 121
CDR field name 121
destRSVPideoStat 121
CDR field name 121
destSpan 121
CDR field name 121
destVideoCap_Bandwidth 121
CDR field name 121
destVideoCap_Codec 121
CDR field name 121
destVideoCap_Resolution 121
CDR field name 121
destVideoTransportAddress_IP 121
CDR field name 121
destVideoTransportAddress_Port 121
CDR field name 121
deviceName 171
CMR field name 171
devices 177
K-Factor support 177
IN-2 OL-28260-01
Index
directoryNumber 171
CMR field name 171
directoryNumberPartition 171
CMR field name 171
DTMF 59
CDR example 59
DTMF method 59
duration 121
CDR field name 121
E
EndtoEnd Call Trace 60
EndtoEnd Call Trace Example 60
external call control 148
routing reason values 148
F
FAC 64
CDR example 64
filename format 7, 167
finalCalledPartyNumber 121
CDR field name 121
finalCalledPartyNumberPartition 121
CDR field name 121
finalCalledPartyUnicodeLoginUserID 121
CDR field name 121
flat file format 7, 167
forced authorization code 64
CDR example 64
forwarded calls 65
CDR example 65
G
global call identifier 10
globalCallId_callId 171
CMR field name 171
globalCallID_callId 121
CDR field name 121
globalCallID_callManagerId 171
CMR field name 171
globalCallID_callManagerID 121
CDR field name 121
globalCallId_ClusterId 121, 171
CDR field name 121
CMR field name 171
H
H.239 71
CDR example 71
I
idivert 75
iDivert 75
CDR example 75
iLBC call 73
CDR example 73
iLBC calls 73
immediate divert 75
CDR example 75
immediate divert to voice-messaging system 75
intercom calls 78
CDR example 78
international escape code 48
Internet Low Bit Rate Codec 73
IP addresses 13
IPv6 calls 79
J
jitter 171
CMR field name 171
joinOnBehalfOf 121
CDR field name 121
K
K-Factor data 177
L
lastRedirectDn 121
CDR field name 121
lastRedirectDnPartition 121
CDR field name 121
lastRedirectRedirectOnBehalfOf 121
CDR field name 121
lastRedirectRedirectReason 121
CDR field name 121
latency 171
CMR field name 171
legacy call pickup 84
CDR example 84
OL-28260-01 IN-3
Index
local route groups 85
CDR example 85
M
malicious calls 89
CDR example 89
meet-me conference 89
CDR example 89
mobility 90
CDR example 90
mobility cell pickup 90
CDR example 90
mobility follow me 90
CDR example 90
mobility handin 90
CDR example 90
mobility handout 90
CDR example 90
mobility IVR 90
CDR example 90
mobility scenarios 90
N
nodeId 171
CMR field name 171
normal calls 95
CDR example 95
number translations 11
numberOctetsReceived 171
CMR field name 171
numberOctetsSent 171
CMR field name 171
numberPacketsLost 171
CMR field name 171
numberPacketsReceived 171
CMR field name 171
numberPacketsSent 171
CMR field name 171
O
on-net calls 112
CDR example 112
OnBehalfOf codes 162
table 162
origCalledPartyRedirectOnBehalfOf 121
CDR field name 121
origCalledPartyRedirectReason 121
CDR field name 121
origCallTerminationOnBehalfOf 121
CDR field name 121
origCause_location 121
CDR field name 121
origCause_value 121
CDR field name 121
origConversationID 121
CDR field name 121
origDeviceName 121
CDR field name 121
origDTMFMethod 121
CDR field name 121
original calling party on transfer 58, 96
CDR example 58, 96
originalCalledPartyNumber 121
CDR field name 121
originalCalledPartyNumberPartition 121
CDR field name 121
origIpAddr 121
CDR field name 121
origLegCallIdentifier 121
CDR field name 121
origMediaCap_Bandwidth 121
CDR field name 121
origMediaCap_g72.3BitRate 121
CDR field name 121
origMediaCap_maxFramesPerPacket 121
CDR field name 121
origMediaCap_payloadCapability 121
CDR field name 121
origMediaTransportAddress_IP 121
CDR field name 121
origMediaTransportAddress_Port 121
CDR field name 121
origNodeId 121
CDR field name 121
origPrecedenceLevel 121
CDR field name 121
origRSVPAudioStat 121
CDR field name 121
origRSVPVideoStat 121
CDR field name 121
origSpan 121
CDR field name 121
origVideoCap_Bandwidth 121
CDR field name 121
origVideoCap_Codec 121
CDR field name 121
origVideoCap_Resolution 121
CDR field name 121
origVideoTransportAddress_IP 121
CDR field name 121
IN-4 OL-28260-01
Index
origVideoTransportAddress_Port 121
CDR field name 121
outpulsedCalledPartyNumber 121
CDR field name 121
outpulsedCallingPartyNumber 121
CDR field name 121
P
partitions and numbers 11
personal assistant calls 97
personal assistant conferencing 102
CDR example 102
personal assistant direct call 97
CDR example 97
personal assistant interceptor going directly to destination 99
CDR example 99
personal assistant interceptor going to media port and transferring
the call 98
CDR example 98
personal assistant interceptor going to multiple destinations 99
CDR example 99
personal media interceptor going directly to destination 98
pickup 43
CDR example 43
pkid 121, 171
CDR field name 121
CMR field name 171
precedence calls (MLPP) 103
CDR example 103
R
redirect reason codes 159
table 159
redirected calls 65
redirection (3xx) 105
CDR example 105
Redirection (3xx) calls 105
refer calls 106
removing a controller from a linked conference 28
CDR example 28
removing a party (controller) from a linked conference 28
removing a party from a linked conference 26
CDR example 26
removing the linked conference 31
CDR example 31
replaces calls 106
CDR example 106
routing reason values 148
for external call control 148
RSVP 108
CDR example 108
S
secure conference meet-me 110
CDR example 110
service parameter 20, 168
call diagnostics enabled 168
CDR Log Calls With Zero Duration Flag 20
short calls 111
CDR example 111
SIP call with URL 111
successful calls 79
IPv6 CDR examples 79
successful on-net calls 112
CDR examples 112
support for dialing "+" 48
CDR example 48
T
timestamps 13
transferred calls 112
CDR example 112
types of codec 151
table 151
U
understanding 167
unsuccessful call 49
CDR example 49
unsuccessful calls 79
IPv6 CDR examples 79
upgrading Cisco Unified CM 5
V
varVQMetrics 171
CMR field name 171
video calls 116
CDR example 116
video conference calls 117
CDR example 117
OL-28260-01 IN-5
Index
IN-6 OL-28260-01
Index

Cucm 9.1 CDR Admin Guide

Uploaded by

Copyright:

Available Formats

Cucm 9.1 CDR Admin Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cucm 9.1 CDR Admin Guide

Uploaded by

Copyright:

Available Formats

What does the document discuss?

What are some examples of call records discussed in the document?

Cisco Unified Communications Manager Call Detail Records

Administration Guide, Release 9.1(1)

2013 Cisco Systems, Inc. All rights reserved.

You might also like