Every time a phone rings, connects, or drops in your Cisco Unified Communications Manager (CUCM) environment, a digital footprint is left behind. These footprints—Call Detail Records (CDR) and Call Management Records (CMR)—are the raw materials for understanding your organization’s communication health.
However, raw Cisco CDR data is notoriously difficult to read. It consists of comma-separated values (CSV) containing hundreds of fields that look like a chaotic wall of text. This guide explains the Cisco CDR format, defines the critical fields you need to monitor, and highlights the difference between billing data (CDR) and quality data (CMR).
Before analyzing the data, it is critical to distinguish between the two types of records CUCM generates.
| Feature | Cisco CDR (Call Detail Record) | Cisco CMR (Call Management Record) |
|---|---|---|
| Primary Function | Billing, Accounting, Traffic Analysis | Diagnostics, Quality of Service (QoS), Troubleshooting |
| What it Tracks | Who called whom, when, and for how long. | Jitter, Latency, Packet Loss, Codec usage. |
| Key Fields | callingPartyNumber, duration, origCause |
VarJitter, latency, pktsLost |
| Use Case | Cost allocation, employee productivity, capacity planning. | Diagnosing "choppy" audio, dropped calls, and poor voice quality. |
Pro Tip: You can have a CDR without a corresponding CMR (if diagnostics are disabled or the call was purely internal signaling), but effective troubleshooting requires both.
Raw Cisco CDR files are flat CSV files. When you open one in a text editor, you will see a string of integers and timestamps. To make sense of this, you need to map the data to the Cisco Data Dictionary.
A typical raw CDR line looks like this:
1, 12345, 98765, 1602345678, 120, 0, 16, ...Without a parsing tool, this is unreadable. Here is how those values map to human-readable fields:
cdrRecordType: Integer identifying if it is a Start (0), End (1), or CMR (2) record.globalCallID_callManagerId: Unique ID for the CUCM cluster node.dateTimeOrigination: Unix timestamp of when the call started.duration: Length of the call in seconds.origCause: The code explaining why the call ended (e.g., 16 = Normal Clearing).
To extract value from your analytics, focus on these high-impact fields.
These fields tell you "Who" and "Where."
callingPartyNumber: The phone number of the person initiating the call.originalCalledPartyNumber: The number originally dialed (before any forwarding or hunting).finalCalledPartyNumber: The actual number where the call landed (useful for tracking hunt group activity).origDeviceName / destDeviceName: The MAC address or name of the physical device (e.g., SEP... for IP phones).These fields tell you "When" and "How Long."
dateTimeOrigination: The precise start time (Epoch/Unix time).dateTimeConnect: When the call was actually answered. Note: If this is 0, the call was never answered.duration: The total time the call was active in seconds.These fields tell you "Why it ended."
origCause / destCause: The "Termination Cause Code." This is your primary troubleshooting tool.
See our Guide to Cisco Termination Cause Codes for a full list.
While CDRs tell you a call happened, CMRs tell you how it sounded. If users complain of "robotic voice" or echo, look at these fields:
VarJitterMeasures variation in packet arrival. High jitter (>30ms) causes robotic audio.
latencyThe delay in audio transmission. High latency results in "talk-over" issues.
pktsLostTotal voice packets dropped. Anything above 1% can severely impact clarity.
Not all "Zero Duration" calls are failed calls. A duration of 0 can simply mean the call was ringing but not answered.
dateTimeConnect: If it is 0, the call was not picked up.origCause: If it is 16, the caller hung up (Abandon). If it is 38 or 41, it was a system failure.Cisco CUCM handles Hunt Groups by generating multiple CDR rows for a single logical call. To report on Hunt Groups accurately, you must link these rows using the globalCallID_callId, which remains constant across the different "legs" of the call.
By default, CUCM stores CDR files on the publisher node. They are typically pushed via SFTP to an external billing server or reporting solution (like Metropolis) for retention and analysis.
originalCalledPartyNumber is what the user dialed. finalCalledPartyNumber is where the call was answered. These differ if the call was forwarded, transferred, or routed through a Hunt Group.
Yes, but the CdrEnabled service parameter in CUCM must be set to "True". Furthermore, for internal calls to generate a CMR (quality record), "Call Diagnostics Enabled" must also be set to "True".
Purpose-built third-party tools like Metropolis' Expo XT integrate directly with CUCM, Webex Calling, and UCCX to import and consolidate calling data automatically.
Ready to unlock the potential of your Cisco voice data?
