Asterisk call is missing from CDR output

Identify the missing record before changing CDR policy

Choose one authorized call and preserve its timestamp and timezone, linkedid, uniqueid values, channel names, caller and called identities, dialplan context, answer state, hangup cause and transfer or bridge history. Establish which exact row the consumer expected: one logical call, one channel, one attempted destination or a billing segment. Asterisk CDRs summarize call relationships; they are not a packet trace or a guaranteed one-row-per-SIP-dialog ledger.

Search the backend using immutable identifiers and a bounded time range before searching only displayed telephone numbers. Normalization, privacy treatment, forwarded identities, account codes and timezone conversion can make an existing row look absent. Preserve the raw result and the report query separately so a presentation or export filter is not mistaken for failed CDR creation.

On a FreePBX system, first use the FreePBX CDR report investigation to separate the GUI query and database row from the Asterisk engine and backend. This prevents a report-filter problem from becoming an unnecessary CDR configuration change.

Confirm the CDR engine and intended call type

Inspect the running Asterisk version, loaded CDR core and backend modules, effective CDR configuration and module status through supported runtime views. Confirm whether unanswered calls are expected: Asterisk documents that explicitly disabling unanswered records can omit some inbound calls, while calls offered to an outgoing line have different behavior. Keep inbound abandon, failed originate, busy destination, cancelled fork and answered bridge as separate cases.

Compare start, answer and end timing plus disposition with the CDR specification rather than converting every zero billsec or NO ANSWER row into a missing call. A CDR may be created only when its lifecycle finalizes, and an active channel or bridge can delay the evidence the report expects. Do not reload modules or change unanswered-call policy until one call's lifecycle is understood.

Inspect channel association and dialplan controls

Follow the exact channel and its related Party A and Party B channels through Dial, Local channels, transfers, parking, queues and bridges. The CDR specification defines association rules that can produce a record shape different from the initial SIP leg. Compare linkedid and sequence as well as telephone identities before declaring a segment lost.

Search owned dialplan and applications for CDR controls. CDR_PROP(disable) can disable CDRs on a channel; deprecated NoCDR() suppresses records; ResetCDR() changes start and answer times and can clear variables; ForkCDR() creates another linked record. On FreePBX, identify the supported module or custom include that owns the generated dialplan. Do not edit generated files or remove a compliance control merely to make a row appear.

Trace submission into the selected backend

Establish which backend is authoritative for this report: CSV, database, ODBC, PostgreSQL or another loaded module. Confirm its effective configuration, file or table target, permissions, connection state and recent error messages. A loaded backend does not prove every record was accepted, and a database table does not prove the report reads that table, schema or tenant.

Compare a known-present control call made in the same window. If batch mode is active, record the configured size and time thresholds and the runtime buffer count before calling the row missing. Asterisk warns that an unsafe termination can lose buffered records; safeshutdown can block a normal shutdown until submission, but it does not prove backend acceptance. Check process lifetime, disk and database health, schema alignment and rejected writes without exposing credentials or broad production data. If a record exists in a raw backend but not the application, move the investigation to the import, indexing, timezone, tenant or report-filter boundary instead of changing Asterisk.

Use CEL when the question exceeds a CDR summary

Asterisk documents CDR and Channel Event Logging as different reporting systems. CEL records channel-state events and is intended for reconstructing more complex call behavior than a summarized CDR can express. CEL ordering is guaranteed for records sharing one primary channel, not across different primary channels, so preserve each unique ID, linked ID, event type and bridge relationship instead of trusting a global timestamp sort. Use existing, properly scoped CEL evidence to understand transfers, multiple bridges or channel lifetimes; do not assume enabling CEL retroactively reconstructs a missing historical call.

CEL has its own event selection, backend and storage requirements. General event selection and backend-specific configuration are separate layers. Adding CEL changes volume, retention, privacy and operational load. Treat a proposed CEL deployment as a separately reviewed observability change with access control, capacity, rollback and data-lifecycle approval—not as an automatic repair for one missing CDR.

Correct one owner and prove the complete path

Correct only the demonstrated owner: call-type policy, dialplan CDR control, channel association expectation, backend configuration, database schema or downstream query. Preserve the previous configuration and rollback trigger. When records support billing, regulation, emergency review or personnel decisions, reconcile the change with the governing retention and audit process rather than regenerating or editing rows informally.

Repeat the original call and one known-good control. Confirm channel and bridge completion, expected CDR finalization, backend acceptance and the exact consumer query. Check unanswered, answered and transferred examples only if they are in scope. No PBX, call, channel, CDR, CEL event, backend, database, billing rule, report or retention workflow was tested for this guide.

Do not use missing CEL events to redefine CDR completeness

A CDR and CEL answer different questions. When the CDR exists but a channel-event reconstruction is incomplete, continue with the CEL diagnostic rather than changing CDR policy to manufacture a chronology.

Check teardown execution before changing the CDR backend

When a custom teardown step owns record preparation, use the hangup-handler diagnostic to prove channel ownership, LIFO order, run and return before treating backend storage as the first failure.