Cisco Unified Communications Manager records call history in Call Detail Records. Those records are useful only after an administrator collects them, interprets Cisco timestamps and call legs, and turns the fields into reports. This guide explains what the records contain, what Cisco CAR provides, how CUCM sends records to another reporting system, and where continuous Cisco CDR reporting software fits.
What is a Cisco CDR?
A Cisco Call Detail Record describes a call leg processed by CUCM. Common fields identify the calling and called parties, origination and connection times, disconnect time, duration, routing devices, and disconnect causes. Transfers, forwards, and conferences can produce multiple records for what a user considers one call, so reporting logic must reconstruct the complete journey instead of counting every row as a separate customer call.
Cisco also produces Call Management Records, commonly called CMR or diagnostic records. CMR data describes media quality, including packet loss, jitter, latency, and the amount of media sent or received. CDR answers who called, where the call went, and how long it lasted. CMR helps investigate how the media path performed.
CDR and CMR together are often called CDR data, but they solve different reporting problems.
How CUCM moves CDR files
On current CUCM releases, call-processing nodes send records to the publisher. The CDR Repository Manager preserves the files according to the cluster configuration and can deliver them to configured billing application servers using FTP or SFTP.
The normal external-reporting path is:
- Enable CDR generation on the call-processing nodes that need to be reported.
- Enable zero-duration records when missed and unanswered calls must be analyzed.
- Configure the external collector as a billing application destination.
- Confirm that CUCM is delivering new files.
- Parse and normalize the records before creating reports.
For a one-time investigation, an administrator can also export Cisco CDR and CMR records manually. Manual export is useful for an audit or troubleshooting exercise. It becomes difficult when managers need a report every morning or an alert shortly after a call.
What Cisco CAR provides
CUCM includes CDR Analysis and Reporting, usually called CAR. CAR consumes CDR and CMR data from the cluster and provides built-in reports for users, gateways, traffic, billing, and system activity. It is useful for native administrative reporting and should not be confused with the CDR Repository Manager, which is responsible for file handling and billing-server delivery.
CAR may be enough when:
- only occasional built-in reports are required;
- the reporting audience already has appropriate CUCM access;
- the retention and report formats fit the operational requirement;
- no cross-system or cross-vendor view is needed.
An external reporting layer becomes relevant when reports must run continuously, combine several clusters or phone systems, retain normalized history, expose dashboards to non-CUCM users, or apply business-specific rules.
Reporting questions the records can answer
Complete call history
CDR fields can reconstruct incoming, outgoing, internal, transferred, forwarded, and abandoned call activity. Correct reporting accounts for multiple call legs and uses call identifiers to avoid double counting.
Missed and abandoned calls
Unanswered calls require zero-duration CDR logging. Duration, connection time, called-party fields, and disconnect causes can then distinguish calls that connected from calls that rang without an answer. Hunt pilots and forwarded calls require additional grouping logic. The detailed workflow is covered in How to Track Missed Calls on Cisco CUCM.
Gateway and trunk activity
Calls can be grouped by originating or destination device, route pattern, gateway, or trunk-related fields to examine traffic distribution and busy periods. This supports capacity investigation, but a CDR traffic report is not a substitute for real-time network or voice-quality monitoring.
Extension and department activity
After extensions are mapped to people, departments, or sites, reports can compare call volume, duration, answer behavior, and frequently dialed destinations. The mapping layer is business data; CUCM CDR does not inherently know the organization’s reporting hierarchy.
Call accounting
Outbound call records can be matched to configured rate rules for cost allocation by extension, department, account code, or site. Accuracy depends on the available dialed-number fields and the rate configuration, not on CDR collection alone.
Alerts
A continuous CDR stream can drive rules for emergency-number calls, repeated missed calls, international dialing, or other patterns. The alert can only include location or organizational context that has been configured and associated with the relevant device or extension.
CDR reporting is different from call recording
CDR contains metadata about call handling. It does not contain the audio conversation. CMR contains media diagnostics, not recording media. A reporting system that consumes CDR and CMR therefore does not replace Cisco call recording, contact-center routing, dial-plan administration, or real-time infrastructure monitoring.
This distinction matters during evaluation: decide whether the requirement is call history and analytics, voice-quality diagnostics, audio recording, or contact-center reporting before selecting a tool.
Evaluating an external Cisco reporting system
Confirm these facts before installation:
- exact CUCM, Business Edition, UCME, or gateway platform and release;
- enabled CDR/CMR services and zero-duration record settings;
- supported delivery protocol and network path;
- collector operating-system and outbound-access requirements;
- call-history, retention, report, and alert requirements;
- how multiple call legs, hunt pilots, and forwarded calls are interpreted;
- which users need reporting access without CUCM administration rights.
PBXDom documents its current CUCM, legacy Call Manager, UCME, UC500, and Cisco gateway collection paths on the Cisco call reporting page. Check the exact deployment there before starting self-setup or scheduling a guided connection.
