FreePBX CDR Reports: query, record lifecycle and evidence boundaries

Define what the report is expected to prove

Sangoma describes CDR Reports as a way to query raw call-detail data and export it for custom reporting. Record the operational question first: traffic inventory, one call investigation, trend, billing input, compliance review or capacity analysis. These uses require different fields, validation, access and retention.

A visible row proves that the configured report query returned stored data. It does not by itself prove the complete human conversation, every SIP dialog, media quality, recording existence, legal retention, charge correctness or final carrier settlement. Preserve the report version, user role, query, timezone and export with the conclusion.

Preserve query, timezone and role as evidence

FreePBX exposes filters including call date, caller and outbound caller identity, DID, destination, account code, duration and disposition. Start with a bounded date range and one known call, then add one filter at a time. Record the FreePBX timezone, browser-visible range, account, result count, columns and export.

A blank report can result from time conversion, role scope, page limits or an over-constrained filter even when a database row exists. Conversely, a broad search can combine unrelated legs that share a number. Keep displayed labels, normalized numbers, database timestamps and the exact call identity separate.

Interpret one call as linked CDR relationships

Asterisk defines a CDR as the relationship between Party A and Party B. Parallel dialing, forwarding, queues, bridges, conferences and transfers can produce several records for one user-visible call. Use linkedid, uniqueid and sequence with timestamps and channel context instead of demanding one row whose source and destination match the first screen labels.

Duration is end minus start; billsec is end minus answer. Those values describe a record, not an automatic invoice rule. The receiving application must define which linked records count, how overlapping or transferred legs aggregate and which source is authoritative for charges.

Keep CDR lifecycle and storage stages distinct

Asterisk documents creation, dialing, bridging, finalization and dispatch as separate CDR states. A finalized record still needs backend submission and database acceptance before FreePBX can query it. Batch settings, shutdown behavior, backend errors, schema selection and retention can therefore create different missing or delayed-data symptoms.

Confirm the effective Asterisk configuration, enabled backend, database target, recent errors and one known-good control without dumping broad production data or credentials. FreePBX CDR Reports expects database-backed records; a flat-file backend is not automatically its source.

Use CDR controls and CEL deliberately

Asterisk can alter record behavior through configuration and dialplan controls such as CDR_PROP(disable). On a FreePBX system, identify the supported module or custom include that owns a change; do not edit generated files or enable broader collection before understanding privacy, storage and reporting effects.

Channel Event Logging records configured channel events at finer granularity and can help reconstruct complex paths, but it is a separate system with explicit event selection, backend, access and retention. Enabling CEL now cannot recreate historical events, and CEL is not a replacement CDR row or automatic billing model.

Accept reporting, export and retention end to end

For an authorized representative set, reconcile raw CDR lifecycle, backend and database acceptance, FreePBX query output and exported values as separate checkpoints. Include unanswered, parallel, forwarded, transferred, queue and conference paths that the organization actually uses. Validate aggregation and billing logic outside the PBX against written policy.

Limit access to call metadata, protect exports, define retention and deletion, back up the schema where required and test restoration away from production. Record limitations beside every report. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.

Escalate to CEL only when the question needs channel events

If a report row is present but the operational question requires bridge, transfer or channel chronology, use the Asterisk CEL diagnostic with a supported FreePBX owner. CEL event selection, backend and retention remain separate from the FreePBX CDR query and database.

Do not substitute a logger channel for call records

A CDR query, CEL event, queue log, Asterisk channel and FreePBX application log answer different questions. Use the Asterisk Logfile Settings guide when the missing evidence belongs to generated and loaded logger channels.

Do not infer queue ordering from CDR answer time alone

The queue-priority diagnostic correlates queue entry, effective priority, member offers, answer and exit; a CDR alone does not contain that complete ordering chain.

Keep Asterisk Info channels separate from durable call records

The Asterisk Info guide treats Channels as live objects and CDR as a different lifecycle. Neither a missing channel nor an aggregate active-channel count establishes whether a durable call record should exist.

Keep dashboard call counters separate from CDR history

The System Dashboard guide treats a current aggregate and durable call record as different lifecycles. A zero live count does not prove there were no historical calls, and a nonzero count does not identify a billable conversation.

Locate the first boundary before blaming the report

The QueueLog diagnostic checks file, backend, ingestion, mapping and cache stages separately.