Asterisk CEL events are missing, duplicated or apparently out of order

Freeze one expected event sequence and its question

Start with one authorized call or channel workflow and state which evidence is missing, repeated or unexpectedly ordered. Preserve time and timezone, Asterisk version, channel names, uniqueid, linkedid, expected event types, bridge or transfer identifiers, backend and downstream query. Define whether the consumer needs a per-channel chronology, a linked call reconstruction, a billing input or an operational trace.

CEL is finer-grained than CDR, but it is not a packet capture, audio recording or ready-made human-call row. A successful call does not prove CEL collection, and one visible event does not prove that every related channel or configured event reached durable storage.

Prove the CEL engine and event selection

Asterisk 22 documents CEL as disabled by default in cel.conf; the events list is case-sensitive and omits the AST_CEL prefix. Record the effective enable, events, apps and date-format settings from the running system. ALL selects all documented events, while APP_START and APP_END also depend on the case-insensitive application list.

Compare the expected event with the configured selection before touching a database. Some events are conditional: an ANSWER record may not occur for every channel-state path, and APP_END is not guaranteed on hangup. Enabling or expanding CEL now cannot recreate events from an earlier call.

Separate engine publication from backend storage

CEL publishes only selected event types to enabled backends. Confirm the required backend module is loaded, then inspect its own configuration, target, credentials, permissions, schema and current error evidence. AMI and RADIUS are configured in cel.conf; custom CSV, ODBC, PostgreSQL, SQLite and TDS use separate backend files.

Treat event creation, CEL-engine selection, backend dispatch, backend acceptance, durable storage, import or indexing and the final query as independent checkpoints. A loaded module does not prove a writable target, and a database connection does not prove that the requested event type was selected.

Correlate records without inventing global order

Asterisk guarantees CEL ordering for a given Primary channel but not relative ordering across different Primary channels. Reconstruct each channel first with uniqueid, event type and timestamp, then relate channels with linkedid, bridge identifiers, peer data and event-specific extra fields. Do not sort a multi-channel export by wall-clock time and treat that result as an authoritative global sequence.

CHAN_START introduces a Primary and CHAN_END closes it, except that LINKEDID_END can follow. Bridge entry and exit use the entering or leaving channel as Primary and carry bridge context; peer is used for those bridge records. Apparent duplication can therefore be correct evidence from two channels or several bridge relationships.

Localize true duplicates and version mismatches

When identical-looking rows remain, compare the complete event identity, Primary channel, identifiers, backend source, import batch and consumer key. Multiple enabled backends, repeated imports, retry behavior, a non-idempotent downstream job or a query join can duplicate displayed rows without the CEL engine emitting the same record twice. Preserve raw source and ingestion metadata before deleting anything.

Also compare the installed version with the event vocabulary. The current specification removes older bridge, conference and generic transfer record types from Asterisk 12 onward and uses bridge-enter, bridge-exit and specific transfer records instead. A report that expects a retired event can appear incomplete even when current events are present.

Correct one owner and accept the full path

Correct only the first demonstrated divergence: engine enablement, selected event or application, missing backend module, backend configuration, permissions, schema, clock conversion, importer idempotency or query logic. Preserve the previous configuration, privacy approval, capacity impact and rollback. Do not enable every event indefinitely merely to repair a downstream filter.

Replay one authorized representative workflow after the change and verify expected per-channel order, cross-channel correlation, backend acceptance, durable storage and downstream result separately. Include transfer, bridge, Local-channel or multi-party cases only when the real requirement uses them. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.

Separate handler order from CEL order

The hangup-handler diagnostic reconstructs the per-channel handler stack and AMI lifecycle. Handler LIFO order, h-extension timing and CEL delivery are not one guaranteed sequence.