Freeze one connection and event chronology
Record installed branch and maintenance release, manager user, connection type, authentication time, login Events value, every later Events or Filter action and response, WaitEvent request and timeout where applicable, Ping/Pong, raw message boundaries, client receive timestamps, parser output, storage writes and reconnects.
Classify the first symptom: no events, one missing class, one missing event name, events only after polling, timeout with an otherwise live connection, delayed processing, duplicated storage rows or a gap across reconnect.
Separate authorization from the session mask
Confirm the manager user has read permission for the target event class, then inspect the login and current-session event masks. Events: off suppresses event delivery even when the action side of the connection works; a selected mask can intentionally omit other classes.
Use a correlated Events action only when a runtime change is intended. Preserve its ActionID and response, then generate a safe known event. Do not broaden write or command permissions merely to diagnose a read-side subscription.
Evaluate configured filters as a set
Inspect the effective manager.conf user section. With include filters present, an event must match at least one include before excludes are considered. A case mismatch in name() or a header criterion aimed at the wrong message field can produce a correctly quiet stream.
Test the narrowest expected event name and header value against the documented method. Keep legacy full-payload regular expressions separate from the recommended advanced syntax and record the installed configuration actually loaded by Asterisk.
Reconstruct dynamic filters after every reconnect
List each successful Filter action in connection order. Dynamic filters belong only to the current manager session and disappear when it closes; reconnecting can therefore widen the stream if the client fails to restore them. Conversely, replaying additions without understanding include and exclude interaction can narrow the stream unexpectedly.
The Filter action requires system permission and may bypass configured filters. Treat that as a privileged session mutation, not a generic consumer preference.
Debug HTTP WaitEvent and TCP readers separately
For HTTP manager use, confirm WaitEvent is issued on the authenticated session, note its seconds-based timeout, collect every returned event and avoid overlapping poll requests until installed behavior has been verified. -1 is an indefinite server-side wait, not a client liveness guarantee.
For persistent TCP, verify frame boundaries, continuous reads, backpressure and socket-close handling instead of adding WaitEvent. A successful Ping/Pong establishes a responsive manager connection, not a functioning event pipeline.
Explain delay, duplication and gaps downstream
Compare the raw AMI stream with parsed and stored records. Client retries, two active consumers, reconnect overlap or non-idempotent writes can duplicate an event that Asterisk emitted once. A reconnect does not create a documented replay contract, so reconstruct current state with bounded snapshot actions when continuity matters.
Keep action-generated list events, unsolicited lifecycle events and business outcomes in separate envelopes. No PBX, AMI session, manager user, permission, configuration file, socket, HTTP session, event queue, channel, bridge, packet, media stream or live call was inspected or tested for this diagnostic.
Classify custom UserEvent failures separately
The UserEvent diagnostic adds producer, schema, correlation and business-outcome checks to the delivery pipeline.
Treat DeviceStateList as a bounded event list
The AMI device-state diagnostic requires the matching completion boundary before publishing a device-state snapshot.
Choose the matching presence event scope
The AMI presence-state diagnostic checks both every-provider PresenceStateChange and hint-scoped PresenceStatus delivery.
Trace ExtensionStatus through the manager delivery path
The AMI extension-state diagnostic checks maintenance release, permission, event mask, filters and raw CALL-class frames.
Check action visibility before event delivery
The AMI missing-action diagnostic verifies that the initiating action is registered, visible and correctly framed before tracing its related events.
Require the conference list completion marker
The ConfBridge list diagnostic distinguishes a complete empty snapshot from filtered rows or a missing Complete event.
Apply the general event pipeline to ConfBridge identities
The ConfBridge event diagnostic adds conference lifetime, participant identity and talk-threshold checks to the event-delivery workflow.
Verify parking snapshot framing before declaring a call missing
The AMI parking diagnostic avoids inventing undocumented completion events and retains raw list frames.
Correlate queue-member events without inventing ActionID
The AMI queue-member diagnostic uses exact queue, interface, node and bounded time.
Do not make one missing queue event the withdrawal verdict
The queue caller-control diagnostic checks response, later snapshot and dialplan return independently.
A missing change event is not the final ringing verdict
The ring-in-use diagnostic checks event authorization, later snapshot, state and offer separately.
A missing queue-log row is not an AMI event-filter verdict
The QueueLog diagnostic follows storage and ingestion after the action response.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 AMI Events action ↗
- Asterisk 22 AMI Events action ↗
- Asterisk 23 AMI Filter action ↗
- Asterisk 22 AMI Filter action ↗
- Asterisk 23 AMI WaitEvent action ↗
- Asterisk 22 AMI WaitEvent action ↗
- Asterisk AMI event filtering ↗
- Asterisk Manager TCP/IP API ↗
- Asterisk 23 AMI Login action ↗
- Asterisk 23 AMI Ping action ↗
- Asterisk 23 AMI UserEvent action ↗
- Asterisk 22 AMI UserEvent action ↗
- Asterisk 23 AMI UserEvent event ↗
- Asterisk 22 AMI UserEvent event ↗
- Asterisk 23 UserEvent dialplan application ↗
- Asterisk 22 UserEvent dialplan application ↗
- Asterisk AMI command syntax ↗
- Asterisk 23 AMI DeviceStateChange action ↗
- Asterisk 22 AMI DeviceStateChange action ↗
- Asterisk 23 AMI DeviceStateList action ↗
- Asterisk 22 AMI DeviceStateList action ↗
- Asterisk 23 AMI DeviceStateChange event ↗
- Asterisk 22 AMI DeviceStateChange event ↗
- Asterisk 23 AMI DeviceStateListComplete event ↗
- Asterisk 22 AMI DeviceStateListComplete event ↗
- Asterisk 23 DEVICE_STATE function ↗
- Asterisk 22 DEVICE_STATE function ↗
- Asterisk device state fundamentals ↗
- Asterisk extension state and hints ↗
- Asterisk 23 AMI PresenceState action ↗
- Asterisk 22 AMI PresenceState action ↗
- Asterisk 23 AMI PresenceStateList action ↗
- Asterisk 22 AMI PresenceStateList action ↗
- Asterisk 23 AMI PresenceStateChange event ↗
- Asterisk 22 AMI PresenceStateChange event ↗
- Asterisk 23 AMI PresenceStatus event ↗
- Asterisk 22 AMI PresenceStatus event ↗
- Asterisk 23 AMI PresenceStateListComplete event ↗
- Asterisk 22 AMI PresenceStateListComplete event ↗
- Asterisk 23 PRESENCE_STATE function ↗
- Asterisk 22 PRESENCE_STATE function ↗
- Asterisk presence-state fundamentals ↗
- Asterisk state query and manipulation ↗
- Asterisk 23 AMI ExtensionState action ↗
- Asterisk 22 AMI ExtensionState action ↗
- Asterisk 23 AMI ExtensionStateList action ↗
- Asterisk 22 AMI ExtensionStateList action ↗
- Asterisk 23 AMI ExtensionStatus event ↗
- Asterisk 22 AMI ExtensionStatus event ↗
- Asterisk 23 AMI ExtensionStateListComplete event ↗
- Asterisk 22 AMI ExtensionStateListComplete event ↗
- Asterisk 23 EXTENSION_STATE function ↗
- Asterisk 22 EXTENSION_STATE function ↗
- Asterisk 23 HINT function ↗
- Asterisk 22 HINT function ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.