VoIP.info Troubleshooting

Asterisk AMI events are missing, filtered, delayed or duplicated

Locate the first divergence among manager permissions, the per-session event mask, configured and dynamic filters, HTTP WaitEvent queueing, TCP reads, reconnects, parsing and downstream deduplication.

Reviewed 2026-10-17Current Asterisk branch-23-generated Events, Filter, WaitEvent, Login and Ping action references, matching branch-22 Events, Filter and WaitEvent references, the official AMI event-filtering guide and Manager TCP/IP API reviewed October 16, 2026; installed branch, manager user permissions, login mask, static and dynamic filters, connection type, event queue, client parser, reconnect behavior, action concurrency, downstream storage and call activity remain deployment specific; 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 testedAdvancedDocumentation based · not lab tested

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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.