Configure CDR on Cisco CUCM

If you run voice workloads on Cisco Unified Communications Manager and want hard numbers instead of hand‑waving about call quality, you need Call Detail Records wired correctly from day one, especially when your call analytics stack lives on Hong Kong servers for low‑latency access across Asia. This guide walks through a practical, operator‑style configuration process, from enabling logging to shipping files to remote collectors, while quietly optimizing for search intent around CDR, Cisco CUCM, Hong Kong servers, VoIP analytics.

1. What CDR Gives You Beyond “Calls Are Working”

Most CUCM clusters are installed, calls go through, and everyone moves on—until finance asks for cost breakdowns or operations needs proof that “the line was actually busy.” CDR is the thing that keeps you from guessing. Each completed call generates structured records that can be pushed to billing, troubleshooting dashboards, or long‑term archives in your preferred data center.

• Per‑call visibility: who called whom, from where, and for how long.
• Routable context: trunks, gateways, partitions, calling search spaces, device pools.
• Correlation handles: global unique call IDs used to stitch legs across clusters.
• Data gravity: records can be streamed to external systems, including clusters running in Hong Kong for regional reporting.

Engineers care because this data lets you answer practical questions: which gateway is overloaded, which site is abusing international routes, or which carrier is quietly degrading media quality at peak hours. With a well‑tuned CDR pipeline you stop relying on screenshots and start pushing SQL or API queries into your analytics stack.

2. CDR vs CMR: Two Streams, One Story

CUCM generates two complementary artifacts per call: CDR and CMR. Treat them as different lenses on the same session rather than two unrelated logs. Most deployments enable both, but very few teams document why they exist or what each stream should be used for.

1. CDR (Call Detail Record)
   • Focus: commercial and operational details.
   • Fields: timestamps, calling/called numbers, directory numbers, hunt pilots, route patterns.
   • Usage: billing, capacity planning, high‑level SLA reports, fraud detection.
2. CMR (Call Management Record)
   • Focus: media path and quality metrics.
   • Fields: jitter, packet loss, round‑trip time, codec, MOS‑like scores.
   • Usage: troubleshooting “bad call” tickets, validating QoS policies, peeking into cross‑border routes from or to Hong Kong.

From a design perspective, you can treat CDR as the outer shell and CMR as the payload describing what really happened on the wire. When CMR is disabled, you still get a solid billing feed, but you lose the physics behind user complaints. For clusters serving remote sites via Hong Kong hubs, it is often the CMR data that tells you whether the problem lives in your WAN, last‑mile ISP, or upstream carrier.

3. Preflight Checks Before You Touch Any Knobs

Before logging into Cisco Unified CM Administration ready to flip flags, spend a few minutes checking prerequisites. Skipping this usually leads to “CDR configured, nothing arrives” bugs that are annoying to debug once production traffic is hitting the cluster.

• Access and roles
  • Ensure you have administrator credentials for both Cisco Unified CM Administration and Cisco Unified Serviceability.
  • Confirm change windows and backup coverage in case you need to roll back.
• Cluster topology
  • Document which node is Publisher and which are Subscribers.
  • Note which node will act as primary CDR Repository Manager; by default this is on the Publisher, but it can be reassigned.
• External collector design
  • Decide where the downstream system lives: on‑prem rack, public cloud, or Hong Kong servers dedicated to VoIP analytics.
  • Clarify whether that box is under hosting or colocation so you know who owns OS‑level hardening and storage expansion.
• Network path and security
  • Confirm IP connectivity from CUCM nodes to the external SFTP or FTP endpoint.
  • Work with security to document allowed ports, jump hosts, and any enforced encryption standards.

Once these are in place, you can move into CUCM itself and avoid most of the “it should be working” back‑and‑forth between voice and network teams.

4. Enabling CDR and Diagnostics in CUCM

The first concrete step is toggling CDR and call diagnostics at the service‑parameter level. This is where you tell CUCM which events should result in a record and which ones can be skipped for noise or volume reasons. A small change here decides whether your downstream database is lean and query‑friendly or full of junk entries you never use.

1. Navigate to Service Parameters
   • Sign in to Cisco Unified CM Administration on the Publisher.
   • Go to System > Service Parameters.
   • Select the CallManager service on the node that handles most call processing (often all nodes in larger clusters).
2. Turn on CDR generation
   • Locate the CDR Enabled Flag parameter and set it to True.
   • Decide how to treat short or failed calls via CDR Log Calls with Zero Duration.
   • For fraud analysis and troubleshooting, many teams deliberately log zero‑duration calls to see patterns of failed attempts.
3. Enable CMR for quality metrics
   • Find Call Diagnostics Enabled and switch it to the level you need (for example, Enabled Only When CDR Enabled Flag is True).
   • Understand that enabling full diagnostics increases volume, but the benefit for cross‑border routes terminating at Hong Kong hubs is usually worth it.

After saving changes, give the cluster some time to settle and generate calls through typical paths. You are not done just by flipping flags; you have only told CUCM to start producing data. The next job is to make sure the repository and transport layers are correctly wired.

5. Making Sure CDR Services Actually Run

Service parameters control behavior; underlying services move bytes. On more than a few real clusters, the flags are correct but the CDR Repository Manager or CDR Agent is down, leaving you with exactly zero exported files. This is where Cisco Unified Serviceability becomes your friend.

1. Check service activation
   • Log in to Cisco Unified Serviceability on the Publisher.
   • Navigate to Tools > Service Activation.
   • Verify the following are active where appropriate:
     • CDR Repository Manager on the node holding the repository.
     • CDR Agent on each node that processes calls.
2. Validate service status
   • Still in Serviceability, go to Tools > Control Center – Feature Services.
   • Confirm those same CDR services show a status of Started.
   • If they are not, start them manually and monitor logs for permissions or disk issues.
3. Review repository capacity
   • Ensure the partition hosting the CDR repository on the CUCM server has enough free space.
   • Consider log rotation policies and how often older exports are off‑loaded to your analytics platform.

Once these components run reliably, your cluster generates records and stages them locally. The last mile is getting files off the CUCM box and into your tool of choice, often a custom pipeline backed by storage and compute in a Hong Kong facility.

6. Shipping CDR Files to External Collectors

CUCM is not the place to run heavy joins or dashboards; treat it as a producer, not a warehouse. The general pattern is to let CUCM buffer CDR files and then push them to an external SFTP or FTP target, where a scheduled job or streaming process ingests them into a database or data lake.

1. Design the external endpoint
   • Decide whether your collector runs on bare‑metal under colocation, virtual machines managed as hosting, or cloud instances.
   • For regional voice footprints, many teams choose Hong Kong servers as the aggregation point because carriers and enterprise links frequently terminate there.
   • Lock in a basic SLA with whoever owns the endpoint so it does not silently run out of disk space.
2. Configure CDR Management in CUCM
   • In Cisco Unified Serviceability, open Tools > CDR Management.
   • Add a new Delivery Destination pointing to your SFTP or FTP server.
   • Set hostname or IP, port, protocol, path, username, and password.
   • Align file rotation frequency with your downstream pipeline; smaller but more frequent files are usually easier to process incrementally.
3. Harden the transport
   • Prefer SFTP over FTP to avoid moving sensitive phone numbers in clear text.
   • Restrict firewall rules to only the CUCM nodes and the collector; do not expose the collector directly to the public Internet.
   • Log inbound connections on the Hong Kong side so you can prove CDR feed continuity during audits.

At this point, a healthy cluster emits files, CDR services run, and your collector receives fresh data. The remaining tasks are verification, tuning, and integrating with whatever analytics stack you run on top.

7. Verifying the Pipeline End-to-End

Verification is where production clusters diverge from lab diagrams. It is not enough to see that “some CDR files exist.” You want to know whether records are timely, complete, and correctly lined up with what users experience in the real world.

• Use CUCM’s own reporting tools as a sanity check
  • Launch the built‑in CDR Analysis and Reporting (CAR) application.
  • Run a report for a known period where you can easily reproduce calls.
  • Confirm that call counts, durations, and key numbers match user expectations.
• Check the external collector
  • Log into the Hong Kong server or whatever box you use as the CDR endpoint.
  • Verify that new files are appearing at the expected cadence.
  • Inspect timestamps inside those files to ensure they align with your cluster’s time zone and NTP configuration.
• Test edge cases
  • Place internal, outbound, inbound, hunt group, and conference calls.
  • Trigger both successful and failed attempts to see how flags like zero‑duration logging behave.
  • Capture at least one call using each major route pattern that matters commercially.

If you see obvious gaps—for example, calls from a particular gateway missing while others look fine—focus on whether the correct nodes have CDR Agent active and whether any intermediate firewalls treat them differently.

8. Pattern-Based Troubleshooting When CDR Misbehaves

Instead of chasing each symptom ad hoc, approach CDR problems as patterns. Most broken deployments fall into a handful of categories that you can quickly confirm or rule out with basic checks.

1. No CDR anywhere
   • Verify CDR Enabled Flag and related parameters are set correctly on all relevant nodes.
   • Check that CDR services are running and not crashing due to storage or permission issues.
   • Ensure cluster time is sane; wildly incorrect clocks can confuse downstream parsers.
2. CDR on CUCM, but nothing on the external collector
   • Look at the CDR Management screen for transfer errors or backlogs.
   • Confirm that the SFTP or FTP daemon on the Hong Kong host is listening and accepts the configured credentials.
   • Review firewall rules and PAM or intrusion prevention logs for blocked attempts.
3. Missing CMR or incomplete quality data
   • Double‑check whether call diagnostics are enabled globally and for the right device classes.
   • Inspect phones and gateways for the ability to send RTCP or related telemetry.
   • Correlate a handful of calls by call ID to see whether the issue is selective or systemic.

As you gather these signals, document findings in the same place you keep cluster diagrams and routing plans. That way, the next engineer waking up to a CDR incident can replay your logic rather than reverse‑engineering guesses from CLI history.

9. Hong Kong-Centric Deployment Patterns

If your organisation uses Hong Kong as a central hub, you can take advantage of local hosting or colocation partners to run a purpose‑built CDR analytics stack. This reduces latency from regional CUCM clusters and keeps call data inside a jurisdiction that many multinational teams are already familiar with from a compliance point of view.

• Data locality and fan‑out
  • Multiple CUCM clusters from different countries can push their files into one Hong Kong repository.
  • From there, a downstream job can normalise fields and fan data out to billing, BI, and monitoring tools.
• Capacity and storage design
  • Use fast local storage on the collector for the last few months of hot data.
  • Archive older CDR to cheaper tiers such as object storage, while keeping indexes pointing back to those buckets.
• Security and compliance
  • Encrypt data at rest with keys managed under your organisation rather than your provider’s default.
  • Define retention policies in terms users and auditors can understand, then enforce them with automated jobs.

Whether you rent full racks under colocation or use managed hosting, the main idea is to treat CDR as a shared, long‑lived asset rather than a transient log. Hong Kong serves as the physical anchor, while your CUCM clusters simply act as producers that come and go over time.

10. Integrating CDR with Billing and Analytics

Once the plumbing is stable, CDR becomes a raw material for higher‑level systems. The value is not in the flat files themselves but in how you stitch them into billing, cost optimisation, and observability workflows. That is where engineers get to be creative.

1. Billing pipelines
   • Load CDR into a relational database or time‑series store keyed by tenant, site, or cost centre.
   • Join against carrier rate tables to produce detailed invoices or internal show‑back reports.
   • Flag suspicious call patterns in near real time—sudden spikes in international or premium‑rate traffic.
2. Quality dashboards
   • Combine CDR and CMR to map MOS scores against network paths, carriers, and time of day.
   • Highlight problem routes that repeatedly degrade when traffic exits via specific peering points.
   • Feed this data back into capacity and routing decisions in the Hong Kong hub.
3. Operational SLOs
   • Define service‑level objectives around call completion rates, median setup time, and jitter for critical sites.
   • Automate alerts when those SLOs drift, using the collector as the single truth source.

Every time you plug CDR into a new workflow, validate that the dataset actually answers the question at hand. If not, adjust CUCM configuration, your parsing logic, or the enrichment steps around country codes, carriers, and customer segments.

11. Security Practices Tailored to CDR Data

Because CDR contains dialed numbers, internal extensions, and sometimes IP addresses, you should treat it as sensitive from day zero. Many teams mistakenly assume that “it’s just metadata,” only to discover later that regulators and customers disagree.

• Transport security
  • Standardise on SFTP for transfers, with strict key management and password policies.
  • Segment CDR traffic into a controlled network zone; do not reuse credentials across other services.
• Access control
  • Give read access only to teams that genuinely need call data for their work.
  • Log every administrative action on the Hong Kong collector, including privilege escalations.
• Data minimisation
  • Mask or hash calling and called numbers when data is used for dev or test environments.
  • Rotate archives out of primary storage once they exceed your documented retention windows.

By owning these controls as part of the initial design rather than as an afterthought, you reduce the odds of painful retrofits later when legal, security, or external auditors sharpen their focus on your voice environment.

12. Closing Thoughts for Engineers Building CDR Pipelines

Configuring CDR on Cisco Unified Communications Manager is not just about flipping a few checkboxes; it is about defining how your organisation will observe, bill, and troubleshoot real‑world voice behaviour for years, especially when the data plane converges on Hong Kong servers and similar regional hubs. Done well, the pipeline from CUCM to your collector gives you a durable, query‑friendly record of every call, marrying structured data with the messy realities of networks, carriers, and users, all anchored by a clean foundation around CDR, Cisco CUCM, Hong Kong servers, VoIP analytics.