CUCM Call Detail Records (CDR) – Complete Guide to Configuration, Analysis, and Reporting

Cisco Unified Communications Manager generates two types of records for every call that traverses your voice infrastructure: Call Detail Records (CDRs) and Call Management Records (CMRs). This guide covers how to configure, read, and use those records for reporting, billing, security, and troubleshooting.

In practical terms, call detail records capture the metadata of every call: who called whom, when the call started and ended, how long it lasted, and what happened (answered, busy, failed). CDR data captures caller identity, destination, and timestamps, but CDRs do not capture the audio content of calls. They record metadata about them. This makes CDR data essential for billing, compliance, and security investigations, while also serving operations teams who need to trace call routing problems or verify system behavior.

The stakes are real. Telecom fraud losses reached $38.95 billion in 2023, making CDR analysis a basic due-diligence requirement for compliance and security teams. CDR data allows organizations to calculate call costs by user or department, and CDR records can serve as digital evidence in legal proceedings. CUCM's native reporting tool, cdr analysis and reporting (CAR), provides browser-based reports, while many organizations also forward CDR files to external billing or analytics platforms via FTP/SFTP for deeper analysis.

The rest of this article walks through enabling CDR/CMR, understanding cdr data and cdr files, working with CAR, and building workflows for cdr analysis, cdr reports, and call history investigations.

CDR vs CMR: What CUCM Actually Logs

CUCM produces two complementary record types. CDRs capture call flow and billing information, while CMRs (sometimes called diagnostic records or called diagnostic records) capture call quality metrics. Both CDRs and CMRs are generated as flat files by CUCM, but they serve different purposes.

What CDRs contain: CDRs capture call details like duration and parties involved. Typical fields include the calling party number, called party (original vs. final), start/end timestamps, call duration, termination cause codes, device names, and gateway or trunk information. CDRs capture routing data, origination and destination numbers, connection time, and disconnect causes. CDRs are used primarily for billing and call tracking, and they are useful for billing, tracking user call volume, and evaluating network capacity.

What CMRs contain: Call management records provide Quality of Service diagnostics such as packet loss, jitter, and latency. CMRs provide metrics on call quality such as jitter and latency, plus codec information, MOS scores (when available), and bandwidth usage. CMRs are essential for diagnosing voice quality issues.

A single human call can generate multiple call leg records. Transfers, forwards, hunt groups, and conference calls each produce additional cdr records. Each CDR file can contain multiple rows for a single call. Key fields in CDRs include callingPartyNumber, finalCalledPartyNumber, and globalCallID_callId, which serve as correlation identifiers. Analysts join CDR and CMR records on globalCallID_callId and globalCallID_callManagerId to build a complete picture.

CDR data consists of two parts: call flow and billing information, and call quality metrics. For billing and high-level call history, CDR alone is sufficient. For call quality troubleshooting, SLA reporting, or QoS investigations, you need cmr data alongside your cdr records.

Enabling CDR and CMR in CUCM

CDR generation is disabled by default in CUCM. If you skip this step, your cluster produces no call records at all.

To enable CDR, navigate to cisco unified cm administration, then System > Service Parameters. Select each node running the cisco callmanager service, locate the cdr enabled flag service parameter, and set it to True. You must repeat this for every server in the cluster that processes calls. Set the 'CDR Enabled Flag' to True to enable CDR on each node.

To generate CMRs alongside your CDRs, find the "Call Diagnostics Enabled" parameter in the same service parameter page and set diagnostics enabled to True (or "Enabled Only When CDR Enabled Flag is True"). Enable 'Call Diagnostics Enabled' to generate CMRs. This tells the callmanager service to write cmr records containing quality metrics for each call leg where the endpoint supports diagnostics.

Consistency matters. If only the publisher has CDR enabled but subscribers do not, calls processed by those subscribers will be missing from cdr data entirely. This leads to incomplete cdr analysis and inaccurate cdr reports. Every node that handles calls must have matching flag service parameter settings.

These changes do not require a service restart. They take effect when the next set of cdr files is generated according to the configured cdr file time interval. However, you should also consider setting the "CDR Log Calls with Zero Duration Flag" to True. Without it, calls that never connect (abandoned, misdials, signaling errors) won't appear in your call history, which can be critical for fraud detection and help-desk troubleshooting.

Core CUCM CDR Architecture and Data Flow

Understanding how CUCM produces and moves cdr data is essential for troubleshooting gaps in reporting. The pipeline has four stages: the callmanager service writes flat files, the CDR Agent copies them, the cdr repository manager organizes them, and CAR processes them into a database.

CDRs are generated on subscriber nodes and stored locally before being imported into a database. Each node running the callmanager service writes CDR and CMR flat files into local directories based on the cdr file time interval. The CDR Agent, a network service running on every call-processing node, polls for new files approximately every six seconds. When it finds them, it transfers them to the publisher's cdr_repository directory and deletes the local copies after successful transfer.

On the publisher, the cdr repository manager takes over. It organizes incoming files into date-based directories, creates symbolic links for CAR loading and for external billing server destinations, and manages retention. The CDR Repository Manager maintains files for a configurable number of days, enforcing disk usage limits through high and low water mark thresholds.

CDR files can be sent to up to three billing servers simultaneously using FTP or SFTP. Enterprise environments typically integrate with SIEM, billing, or analytics platforms for advanced cdr analysis and reporting.

The car scheduler service then reads from the cdr_repository and inserts raw data into the car database for web-based reporting. Understanding this pipeline is key to troubleshooting "no cdr data" issues, delays in cdr reports, or files waiting on individual CUCM nodes.

Key CUCM CDR Enterprise Parameters

Enterprise Parameters are cluster-wide settings that control how and when CUCM creates and exports cdr files. They are edited through System > Enterprise Parameters in cisco unified cm administration.

CDR File Time Interval controls the duration each flat file covers. The default value is 1 minute, and CDR File Time Interval can be set from 1 to 1440 minutes (24 hours). Lower intervals (1–5 minutes) provide near-real-time access, which is ideal for security monitoring. Higher intervals reduce file churn but delay data availability.

Cluster ID identifies your cluster in exported cdr files. The default value is "StandAloneCluster," with a maximum of 50 characters (alphanumeric plus dot and dash). When integrating multiple clusters into a central analytics or billing platform, a unique and descriptive cluster id (e.g., "EMEA_PROD_01") prevents data from being misattributed. Valid values include letters, numbers, dots, and dashes only.

CDRonDemand throttling parameters control how many get_file and get_file_list queries per minute external systems can make against the publisher. Defaults are approximately 10 and 20 respectively. These protect the publisher from overload when third-party tools pull cdr files via SOAP or web services.

Tuning recommendations:

• Leave the cdr file time interval at 1–5 minutes for security-focused environments
• Use a clear naming convention for your cluster id
• Align throttling settings with the volume of external queries your billing server or SIEM generates

Enterprise Parameter updates apply when new flat files are created and typically do not require service restarts.

CUCM CDR Services: CallManager, CDR Agent, Repository Manager

Three CUCM components are central to cdr data handling. Think of them as writer, mover, and organizer.

CallManager (Writer): The core call-processing engine on each node. It creates CDR/CMR flat files per the cdr file time interval and writes them into local directories on the node's file system. Organizations use CDRs for monitoring call activity and troubleshooting, and this service is what generates cdrs in the first place.

CDR Agent (Mover): Runs as a network service on every node that runs the callmanager service. It polls local directories every few seconds for new cdr files, securely transfers them to the publisher's cdr_repository, and deletes local copies upon successful transfer. If CDR Agent is not running on a subscriber, that node's calls silently disappear from the central repository.

CDR Repository Manager (Organizer): Active on the publisher. It builds the directory structure (car, destination1–3, preserve, processed, trans, tmp), controls disk usage via high/low water marks, manages data retention, and sends files to external billing or analytics servers.

When any of these three components fails or is misconfigured, the symptoms are predictable: missing cdr files on the publisher, cdr backlogs on subscribers, gaps in CAR reports, or incomplete call history in external tools. Administrators should regularly verify service status using cisco unified serviceability (Control Center – Network Services) and monitor disk usage on /var/log/active/cm/cdr_repository using CLI tools like file list activelog.

CAR Scheduler, CAR Web Service, and CDRonDemand

Three services sit on top of raw cdr data to enable cdr analysis and reporting directly from CUCM.

CAR Scheduler runs on the publisher and periodically loads CDR/CMR files from cdr_repository into the car database. It follows a configurable schedule (default: 24×7 continuous loading) with options for load-only-CDR or include-CMR modes. It also purges old records when hitting size or record limits. The maximum size of the CAR database is 6 GB, and CDR data retention is capped at 6 GB or approximately 2 million records across key tables.

CAR Web Service is a feature service on the publisher that exposes the car web interface, typically at https://<CUCM-FQDN>:8443/car/. This service must be activated through cisco unified serviceability > Tools > Service Activation. Without it, running cdr reports, performing cdr searches, or accessing call history through a browser is not possible.

CDRonDemand is a SOAP/HTTPS service that allows external systems to query for cdr files within a time window (up to 1 hour) and deliver them to SFTP/FTP targets. It supports get_file_list (returns filenames for a given date range) and get_file (extracts a specific file). This is useful for just-in-time analytics or forensic collection of specific call information.

Configuration entry points include cisco unified serviceability > Tools > Service Activation and CDR Management. Practical considerations: because the car database has a hard size limit, long-term retention in CAR alone is risky. Organizations should offload cdr data to external systems for archival and deep analysis.

Understanding CUCM CDR File Structure and Directories

All CDR/CMR files ultimately reside on the CUCM publisher under /var/log/active/cm/cdr_repository. Understanding the directory layout and file naming conventions matters for automation and troubleshooting.

The high-level directory structure includes:

CAR uses the car/yyyyMMdd symbolic links to know which cdr files to load. External billing servers fetch from their respective destinationX/yyyyMMdd directories.

A typical CDR filename follows a pattern like cdr_StandAloneCluster_01_20260124-0100-0105_1.log, encoding the prefix (cdr vs cmr), cluster id, node sequence number, timestamp window, and file sequence. CDRs are stored as comma-separated flat files in CUCM, and CDR files are generated as comma-separated flat files.

To verify healthy file flow, check that:

• New date directories appear daily in preserve/
• processed/ contains older days' files
• trans/ and tmp/ are usually small

Large accumulations in tmp or trans indicate downstream processing issues. Use CLI commands like file list activelog /cm/cdr_repository/<folder>/<date> to quickly inspect file counts and sizes, especially after configuration changes or outages.

Key CUCM CDR Fields and How to Interpret Them

Cisco CDRs can contain over 100 columns depending on version and configuration, but a small subset explains most operational questions about call history, routing, and troubleshooting.

Identity and routing fields:

• callingPartyNumber – the calling party number (originator)
• originalCalledPartyNumber – the first called number dialed
• finalCalledPartyNumber – the finalcalledpartynumber cdr field, showing where the call actually terminated (differs from original when forwarding, hunt groups, or pickup occurs)
• redirectingPartyNumber – the party that forwarded or transferred the call
• origDeviceName / destDeviceName – the physical endpoints involved

CDRs track metadata about who, when, and how a call was made. CDRs log call activity that can help troubleshoot call quality issues and analyze traffic patterns.

Timing fields: dateTimeOrigination marks call start, dateTimeConnect marks answer, and dateTimeDisconnect marks end. The duration field is in seconds. A zero value for dateTimeConnect with non-zero ringDuration indicates a call that rang but was never answered, giving it a zero duration in terms of conversation.

Termination cause codes: CDRs include origCause_value and destCause_value, which help identify call failures. Codes like "normal call clearing" indicate expected behavior, while "no circuit available" or "call rejected" point to routing failures or carrier issues. These codes are critical for distinguishing user behavior from network problems.

Device and gateway indicators: origIpAddr, destIpAddr, outgoing/incoming trunk fields, and route pattern information help map calls to specific phones, CTI devices, gateways, and SIP trunks along the call path.

CMR quality fields: When paired with CDR, cmr records add jitter, packetLoss, latency, codec, and MOS indicators. Thresholds like latency greater than 150 ms or packet loss above 1–2% generally correlate with poor user-perceived call quality.

Working with Raw CDR Files: CSV, Excel, and Scripts

CUCM cdr files are comma-separated flat files that can be opened with text editors or imported into Microsoft Excel, LibreOffice, Python, R, Splunk, or SQL databases. Common methods to access CDRs include the CAR tool and exported CDR files pulled via SFTP.

Small-environment workflow: Download CDR files via CAR or SFTP, open in Excel using Data > From Text with comma delimiter, set column types appropriately, and filter on fields like callingPartyNumber and dateTimeOrigination to analyze call history for a specific user id or directory number.

Formatting quirks to watch for:

• IP addresses (origIpAddr, destIpAddr) are often stored as signed integers requiring conversion to dotted-decimal notation
• Timestamps are typically Unix epoch values requiring conversion to human-readable format
• Some fields appear only in files destined for external billing apps, not in manual exports

Scripting for scale: For larger volumes, parsing cdr records with Python (pandas), PowerShell, or SQL imports is far more practical than manual Excel work. You can join CDR and CMR files on globalCallID_callId, filter by date range or called number, and build repeatable workflows for regular cdr analysis and reporting.

Best practices for handling large cdr data sets include splitting files by date, normalizing time zones, and pre-filtering by calling or called number. CDR data can be accessed through the CAR tool interface for ad-hoc work, but ongoing operations usually require a dedicated reporting stack for continuous monitoring of call detail records.

CDR Analysis and Reporting (CAR) – Roles, Settings, and Access

CAR is CUCM's built-in web tool for generating cdr reports, investigating call history, and monitoring call quality and traffic without exporting raw data files.

Roles and access control:

Roles are managed via CUCM user groups such as "Standard CAR Admin Users." Each role can log in to the car web interface.

Essential pre-configuration: Before generating your first reports, configure mail server details for report delivery, dial plan definitions (local vs. long distance vs. international) for accurate billing of call costs, gateway definitions with port counts for utilization reports, and system preferences like currency and time zone.

Access paths: Administrators log in via cisco unified serviceability > Tools > CDR Analysis and Reporting. End users access the direct URL (https://<server>:8443/car/). Common login errors (403 or IMS error codes) usually trace back to misconfigured roles or password issues.

Aligning CAR dial plan and gateway configuration with actual CUCM routing avoids misclassified calls and incorrect billing totals. Organizations should document CAR admin assignments, password rotation rules, and access review cycles to keep cisco cdr reporting aligned with security standards.

Built-in CAR Reports: User, System, Device, and QoS

CAR offers several report categories driven from cdr data. CAR generates reports for billing and compliance, and CAR allows scheduling of daily, weekly, and monthly reports with automatic email delivery.

User Reports include Individual Bills, department bills, and Top N reports (top users by call count, total duration, or charge). CDRs allow organizations to track phone usage and identify billing codes. These reports support cost allocation, abuse detection, and management oversight.

System Reports include:

• QoS Detail and Summary – tracking call quality across the cluster
• Traffic summary – calls by hour/day and by call type, essential for capacity analysis
• Authorization Code / Forced Authorization Code reports – tracking calls tied to specific projects or clients via forced authorization code entries
• Malicious call details – where enabled, logging flagged calls for security review

You can also build a custom report using CAR's filtering options to focus on specific hunt pilot dn values, route pattern usage, or outbound calls to particular destinations.

Device reports include gateway detail/summary, route group and hunt list utilization, conference bridge utilization, and voice-messaging device reports. These support capacity planning and platform right-sizing.

Reports can be generated on-demand or scheduled daily, weekly, or monthly. Zero-value date ranges appear as 0.00 or empty charts rather than being omitted. A recommended baseline set of recurring reports includes:

• Daily: traffic summary and QoS summary
• Weekly: gateway utilization and device reports
• Monthly: Top N users and department bills

Using CDR Search and Call History for Investigations

CAR's CDR Search capability is the quickest way for engineers and security teams to examine detailed call history without pulling raw files. It requires that CDR and CMR collection is properly enabled across the cluster. CDR data is crucial for security investigations, and CDR data helps identify patterns of suspicious activity.

Common search filters map directly to cdr data fields:

• User extension (calling or called party)
• Gateway or trunk (unique identifier for the path)
• Date range and time window
• Termination cause
• Malicious call flag
• Call direction (inbound, outbound, internal)

Investigation example: Suppose you suspect toll fraud on a specific extension. Filter cdr searches for that extension's outbound calls to international destinations over a weekend. Look for many short-duration or repeated attempts with zero duration connections. Export the result set to CSV for deeper analysis by security teams.

CDR Search respects CAR roles. Managers may only see calls for their departments, while administrators see cluster-wide detail records. User-level searches can underpin HR or compliance inquiries when a specific user id or directory number is under review.

Export options (typically CSV) let you feed CDR/CMR data into external tools for pattern detection, anomaly scoring, or incident response workflows. Establishing standard investigation playbooks that rely on CDR Search, such as steps to take when a phone is reported compromised, ensures teams consistently leverage CUCM call information.

Logging Calls with Zero Duration and Special Call States

Calls with zero duration are calls that never reach an answered state: abandoned calls, misdials, or calls terminating with signaling errors before media is established. By default, many of these calls may not appear in your cdr log unless you explicitly configure CUCM to capture them.

The zero duration flag is controlled by the "CDR Log Calls with Zero Duration Flag" service parameter. When set to True (and the cdr enabled flag is also True), CUCM writes CDR records even for calls with zero dateTimeConnect. This is essential for a complete call history. The parameter is sometimes referenced as log calls with zero duration logging.

CUCM always logs CDRs for calls with zero duration that end with errors (network failures, routing problems) regardless of the flag, because those records are essential for troubleshooting.

Use cases for zero-duration logging:

• Detecting robocall floods hitting a contact center
• Identifying misconfigured dial plan routes or route pattern errors
• Monitoring nuisance calls
• Investigating repeated failed attempts from a compromised endpoint

The trade-off is volume. Enabling the zero duration flag increases the total number of cdr records stored in CAR and exported to billing systems, potentially hitting the 2 million record limit sooner.

Most enterprises should enable this flag. The investigative value of capturing every call attempt, including those with a zero value for connection time, usually outweighs the storage cost. Design your cdr analysis and reporting pipelines to handle the extra volume.

Managing CDR Backlogs, Connectivity, and Billing Server Issues

One of the most common operational problems with cucm cdr infrastructure is that cdr files stop reaching external billing or analytics servers, often due to SFTP/FTP connectivity issues, cdr backlogs, or cryptographic algorithm mismatches after upgrades.

Detecting a backlog: Use CUCM CLI or cisco unified serviceability tools to inspect the cdr_repository directories. Normally, you should see only a handful of files waiting in trans or tmp at any given time. Hundreds or thousands of files indicate a processing bottleneck.

Connectivity troubleshooting checklist:

1. Verify SFTP access from a workstation using the same credentials CUCM is configured to use
2. Confirm firewalls allow port 22 (SFTP) or 21 (FTP) between publisher and billing server
3. Check that billing server hostnames resolve correctly via DNS
4. For older CUCM versions, confirm the billing server supports the SSH ciphers and Diffie-Hellman key exchange algorithms CUCM uses

CDR files can be sent to up to three billing servers, but each destination is independent. A failure reaching one billing server does not block transfers to others, though the files waiting for the failed destination will accumulate.

Remediation steps:

• Restart CDR Agent or cdr repository manager services during a maintenance window
• Clear or correct misconfigured billing server entries in CDR Management
• Temporarily disable non-critical destinations to reduce load
• Monitor the backlog as it drains

After major CUCM upgrades, network changes, or security patch rollouts, verify that cdr files are still flowing to all configured destinations. SSH cipher changes are a frequent culprit for silent transfer failures.

CDR Data Retention, Compliance, and Archiving Strategies

CUCM's built-in car database and cdr_repository directories are designed for operational reporting, not long-term regulatory data retention. Default limits (6 GB or approximately 2 million records) lead to automatic purging of older cdr data.

Compliance drivers that demand longer retention:

• Financial regulations (e.g., MiFID II requires retaining relevant communications for 5+ years)
• Healthcare audit requirements (HIPAA)
• Internal HR policies and security forensics
• Legal discovery and fraud investigations

Retaining CDRs according to data retention policies is considered a best practice. Many of these requirements extend well beyond CUCM's default retention window.

Practical archiving approaches:

• Schedule automated exports from CAR
• Pull cdr files via SFTP or CDRonDemand to a central archive
• Load CDR/CMR into data warehouses, SIEMs (Splunk, Elastic), or log management platforms for long-term storage

Integrity considerations: CDR records can serve as digital evidence in legal proceedings. If call detail records might be used as evidence, preserve original flat files in read-only storage, compute cryptographic hashes at the time of export, and maintain chain-of-custody logs separate from analytic transformations.

A documented retention policy should cover:

• CDR data volume estimates and growth projections
• Storage locations (on-premises vs. cloud)
• Access controls and encryption at rest
• Retention durations per jurisdiction and business function

Relying solely on CAR for historical cdr analysis is risky due to inevitable purges. A dedicated CDR archiving workflow should be part of core CUCM operational design, not an afterthought.

Advanced CDR Analysis Use Cases: Fraud, QoS, and Capacity Planning

Moving from raw cdr records to actionable insights requires structured analysis. Here are three concrete scenarios.

Toll-Fraud Detection: Analyze cdr data for spikes in international call volume outside business hours, many short-duration calls to high-risk destinations, or new patterns of outbound calls from devices that normally place only local calls. Telecom fraud losses are massive globally, making proactive monitoring essential. Use CDR Search or external analytics to flag anomalies in calling party number patterns, redirect chains, or unusual termination codes. Combining CDR with cmr data can reveal attempts where calls connect but media fails (unusually high packet loss or jitter).

QoS Monitoring: Leverage CMR jitter, latency, and packet-loss metrics across a date range. Correlate poor call quality scores with specific WAN links, subnets, or remote sites. Thresholds like jitter above 30–50 ms, latency above 150 ms, or packet loss above 1–2% serve as reliable warning flags. Feed these insights back into network QoS policy tuning and track improvements over time through recurring cdr reports.

Capacity Planning: Analyzing peak call times helps organizations determine if they have sufficient resources. Use traffic summary and gateway utilization reports over several months to identify peak busy hours, near-full PRI or SIP trunk utilization, and underused conference bridge capacity. This leads to concrete actions like adding trunks, rebalancing route groups, or consolidating underused resources.

Richer cdr analysis often requires joining CUCM detail records with external data sets like Active Directory attributes, site codes, or cost centers to generate reports meaningful to business stakeholders. Establish recurring review cadences: monthly fraud reviews, weekly QoS boards, and quarterly capacity reviews incorporating CDR-driven metrics.

Best Practices Checklist for Reliable CUCM CDR Operations

Here is a consolidated checklist for ensuring reliable cdr data collection, accurate cdr analysis and reporting, and efficient troubleshooting of CUCM call detail records.

Configuration:

• Enable CDR and CMR on all callmanager service nodes (CDR generation is disabled by default in CUCM)
• Enable logging for calls with zero duration
• Set a short cdr file time interval (1–5 minutes) for near-real-time visibility
• Configure a meaningful and unique cluster id

Operational Monitoring:

• Verify CDR Agent and cdr repository manager services are running via cisco unified serviceability
• Periodically inspect cdr_repository for backlogs (trans/tmp should be small)
• Validate SFTP/FTP connectivity to all billing server destinations
• Confirm car scheduler status and loading schedules

Data Management:

• Define a retention and archiving plan beyond CAR's built-in limits
• Regularly export and back up cdr files to external storage
• Keep CAR dial plan and gateway definitions in sync with CUCM configuration changes

Security and Compliance:

• Restrict CAR administrative access to authorized personnel
• Encrypt archived cdr data at rest
• Maintain audit trails for who accesses call history
• Coordinate with legal/compliance teams about evidentiary requirements for cdr records

Well-configured and well-managed CUCM CDR infrastructure turns raw call logs into a strategic asset for operations, finance, security, and compliance teams. Start by verifying that CDR collection is enabled on every node in your cluster today, and build your retention and analysis workflows from there.