New Call Data Records – A Deep Dive

Major upgrade to Call Data Records (CDR) System in 3CX.

Following on from yesterday’s V20 Update 6 Alpha release, this post explains the new Call Data Records (CDR) system in 3CX where we’ve streamlined CDR into a single table: cdr_output. We break down the old structure, reveal the new design, and spotlight the technical wins that are transforming how call data works. Read on for full details.

The Legacy Setup: A Fragmented Bottleneck

Originally, 3CX’s CDR / call data was split across four tables: cl_calls, cl_participants, cl_party_info, and cl_segments. Each stored distinct elements of the call lifecycle: timestamps, participant data, and routing details – forcing complex SQL JOINs to piece together a full record. This multi-table design increased query overhead, and bogged down performance for generating reports. For cloud-scale analytics or real-time reporting, the structure simply couldn’t keep up.

The New Approach: cdr_output

We’ve overhauled this into cdr_output, a single-table solution that consolidates all call data into one efficient table. Timestamps, participants, routing, and outcomes – everything’s unified, eliminating the need for JOINs. JOIN is required only for Recording Data which is now in its own table cdr_recordingsout. At 3CX we’ve always been able to scale to thousands of users. This lean architecture further strengthens our scaleability, slashes complexity, boosts query speed, and primes 3CX for cloud-ready analytics. It’s a bold rethink of data engineering, built to deliver precision and power.

Advancement #1: All Your Data In One Smart Table

Legacy: Multi-table JOINs throttled performance—a real headache for digging into call insights.
New: cdr_output packs everything – source, destination, timestamps, outcomes—into one compact table. It’s flat and simple, cutting out the relational clutter so BI analysts can easily follow call flows.

Why It Rocks:

• Faster Queries: Ditches multi-table complexity for single-table speed – queries scale smoothly, no matter the data size.
• Cloud-Ready: Slides right into data lakes or BI tools—no extra prep needed.
• Analyst Win: Call paths are clear and quick to trace, saving hours of hassle.

Tech Edge: Indexes on cdr_id and call_history_id turbocharge PostgreSQL for lightning-fast lookups, even with massive datasets. Keeping call_history_id links in-table slashes SQL overhead, boosts speed, and trims data bloat.

Advancement #2: Every Row Tells The Story

Legacy: Thin metadata left report analysts guessing – why did a call fail? Where’s the context? Who transferred to whom?
New: cdr_output embeds a rich attribute set:

• termination_reason (e.g., “cancelled”, “dst_participant_terminated”)
• termination_reason_details (e.g., “forward_all”, “completed_elsewhere”)
• creation_method (e.g., “route_to”, “divert”)
• creation_forward_reason (e.g., “polling”, “busy”)
• continuation_reason (e.g., “polling”, “forward_all”)

Impact:

• Total Clarity: Every row is a full story – no more piecing together clues.
• Smarter Insights: Powers KPIs like drop rates or queue stats, no extra work required.
• Endgame Explained: Instantly see how, why, when, and who ended a call.

Tech Edge: termination_reason_details fuels pinpoint analysis (think SQL GROUP BY from Grafana or PowerBi), while the UUID-based cdr_id is now GUID standard 00000000-01db-87c1-1bab-07aa0000000d to allow BI tools nail date-time and call order right out of the box. It’s all there – how a call started, moved and ended.

Advancement #3: Who’s Calling Who, Made Simple

Legacy: Participant roles were poorly defined – source vs. destination required cross-table inference, guesswork, nested operations, Multiple JOINS and performance hogs.
New: cdr_output tames previous SQL JOIN tangles with a series of cleanly split features:

• source_participant_id (used for tracking)
• source_participant_phone_number (e.g., “+1305305305”)
• destination_dn_name (e.g., “Dana White”)
• Flags like source_participant_is_incoming and destination_participant_is_already_connected