Asterisk CDR and CEL: which record answers the question?

Choose the record from the question

Use a call detail record when the consumer needs Asterisk's summary of communication between Party A and Party B: start, answer and end time, disposition, duration, billsec and identifiers. Use Channel Event Logging when the question needs the channel-state chronology behind transfers, bridge membership, Local-channel behavior or multiple participants. Neither record family is a packet trace, audio record or automatic match for a carrier's billing model.

Define the expected unit before counting anything: one customer conversation, one Asterisk channel, one Party A-to-Party B relationship, one dial attempt or one billable segment. A completed call can produce several CDRs, while one CEL-backed reconstruction requires application-specific logic.

Read a CDR as a relationship lifecycle

A CDR moves through single, dial and bridge relationships before it is finalized and dispatched. A bridge break, transfer, failed dial, channel hangup or explicit fork can finalize one record and allow another to begin. Asterisk documents that hold does not itself appear in the CDR, and that multi-party bridges create records for channel pairings. One row therefore cannot be assumed to describe every action in a call.

Keep uniqueid, linkedid and sequence together. uniqueid identifies the Party A channel, linkedid associates related channels, and the sequence helps distinguish records that otherwise share identifiers. Preserve Party A and Party B perspective when interpreting caller, destination, disposition and timing.

Make CDR policy explicit

Record the running Asterisk version and the effective cdr.conf values before changing a report. Global enablement, the default per-channel state, unanswered and congestion handling, cancel disposition, hangup-logic behavior, dial-change handling and bridge-state handling can all change record presence or shape. The unanswered option specifically governs calls that never set an outgoing Party B; calls offered to an outgoing line retain separate behavior.

Batch mode also changes when evidence becomes visible. Size and time thresholds delay backend submission, while an unsafe termination can lose buffered records. safeshutdown and the runtime batch count are lifecycle evidence, not proof that a database accepted a row. Several configuration controls are version-sensitive, and ignorestatechanges cannot be changed by reload.

Use CEL as ordered per-channel events

CEL emits selected event types to enabled backends. Each record includes a partial snapshot of its primary channel and may add event-specific data such as a bridge identifier or peer. Asterisk guarantees event ordering for a given primary channel, but not across different primary channels. A reconstruction must therefore correlate unique and linked identifiers and apply declared ordering rules; sorting every row only by wall-clock time is not a complete call model.

Choose event types and backend deliberately. General cel.conf selection and the backend-specific configuration are separate layers, and an enabled CEL engine does not prove the intended events reached CSV, ODBC, PostgreSQL, SQLite, AMI or another consumer. Enabling CEL now cannot recreate historical events that were never recorded.

Prove dispatch, storage and consumption separately

For either record family, identify the loaded backend, effective target, permissions, connection state, schema and current error evidence. Use one known-present control record from the same interval. Distinguish record finalization, engine dispatch, backend acceptance, durable storage, import or indexing and the final report query. An empty dashboard can be a filter, tenant, normalization or timezone problem even when Asterisk wrote the source row.

Validate with authorized answered, unanswered and transferred examples only when those cases are in scope. Keep raw records and report output separate, document clock source and timezone conversion, and do not represent a successful SIP dialog as proof of backend storage—or a stored row as proof of signaling, RTP or audible media.

Protect, reconcile and change with evidence

Call metadata can expose identities, relationships, schedules and operational patterns without containing audio. Restrict access, define retention, redact shared extracts and preserve the original under the applicable audit policy. CEL commonly increases record volume, so capacity and deletion behavior require an explicit review.

For a billing dispute, compare the same interval, timezone, number normalization, call direction, answer definition, charging increment and rounding rule. Preserve unexplained differences rather than rewriting PBX history to force agreement. Change only the demonstrated owner—CDR policy, dialplan control, event selection, backend, schema or downstream query—and retain a rollback trigger. No PBX, channel, call, CDR, CEL event, backend, database, report, billing calculation or retention workflow was tested for this guide.

Account for Local-channel optimization before interpreting records

A Local destination creates ;1 and ;2 channel halves. When that pair optimizes out, Asterisk finalizes its associated CDRs and can create new records for relationships in the merged bridge; properties placed on the optimizing Local channels are not propagated. The Local-channel lifecycle guide maps those channels to AMI optimization and bridge events. Correlate linkedid, uniqueid, sequence and channel name instead of counting each Local half or each resulting CDR as an independent customer call.

Correlate call-file jobs beyond the archive status

A call file's archived Completed, Expired or Failed status describes the spool originate boundary. Correlate a safe external job ID with CDR or CEL and application records when the real question is whether a later destination answered or a workflow completed.

Carry AMI correlation into call records

Keep AMI ActionID, channel Uniqueid and application idempotency key as distinct identifiers. The AMI Originate guide uses the action and event pair for attempt evidence, then CDR, CEL or application records for the downstream result the product actually promises.

Carry ARI request identity into lifecycle evidence

Keep the business idempotency key, requested ARI channel IDs and Asterisk channel identifiers distinct. The ARI origination guide uses HTTP and Stasis events for control-path evidence, then bridge, CDR, CEL or application records for the promised outcome.

Diagnose the event path before rewriting a reconstruction

The CEL event diagnostic starts with one expected per-channel sequence, then checks selected events and applications, backend dispatch, durable storage, per-Primary ordering and downstream idempotency. It does not use a wall-clock sort across several channels as proof of global order.

Keep queue events distinct from CDR and CEL

A CDR summary or CEL chronology does not substitute for queue-specific admission, offer, connection and exit events. Use the queue-log diagnostic when the missing evidence belongs to the dedicated queue log.

Correlate teardown handlers before interpreting records

The hangup-handler diagnostic follows the per-channel stack and final Hangup event before deciding whether a missing or duplicate CDR or CEL result began in dialplan teardown or downstream storage.

Correlate bridge exit before interpreting later records

The after-bridge diagnostic follows BridgeEnter, BridgeLeave, dialplan entry and Hangup on the same channel before treating CDR or CEL output as continuation evidence.

Do not substitute a CLI filter group for call records

The LOG_GROUP guide distinguishes a transient channel filter selector from call identifiers, CDR disposition and CEL event history.

Correlate bridge events without turning them into billing proof

The AMI bridge-control guide joins ActionID, bridge IDs and channel IDs while leaving CDR and CEL ownership separate.

Do not turn a transfer event into billing proof

The AMI transfer-control guide preserves event topology while leaving target result and record ownership separate.

Keep abort and callback legs distinct in records

The AMI cancel-and-recovery guide separates explicit abort, re-bridge, recall and target attempts.

Retain Local and surviving identities in call records

The AMI Local optimization guide correlates both halves, linked identity and the post-optimization party set.

Keep snapshot identity distinct from historical call records

The AMI channel snapshots guide relates channel, unique, linked and bridge identifiers without merging their roles.

Do not use a filtered event stream as a complete call record

The AMI event-delivery guide keeps event receipt, gaps, historical records and call outcomes distinct.

Do not substitute custom telemetry for call records

The AMI UserEvent guide treats an application message as a separate contract, not a complete CDR or CEL history.

Do not use CDR or CEL as a recording-file receipt

The AMI MixMonitor diagnostic correlates channel identity and time but verifies file close, decoding and retention independently.

Do not collapse queue statistics reset into CDR or CEL deletion

The AMI queue reload and reset guide keeps runtime queue counters and historical call records as separate stores.

Do not replace CDR or CEL with a custom queue marker

The AMI QueueLog guide treats queue-log, CDR, CEL and channel evidence as independent histories.