VoIP.info Guide

Asterisk AMI QueueStatus and QueueSummary snapshots

Collect queue summaries and detailed status as separate, filtered AMI transactions with explicit correlation and completion boundaries.

Reviewed 2026-10-17Asterisk branch-23-generated and branch-22-generated QueueSummary and QueueStatus action references plus official AMI v2, permission and queue documentation reviewed October 16, 2026; installed branch and maintenance release, app_queue version, server identity, manager transport, account, ACL, read and write classes, queue and member names, dynamic membership, event schema, completion behavior, clock, configuration owner, caller state, member reachability, device state and downstream collector behavior remain deployment specific; no PBX, queue, member, caller, manager configuration, account, credential, socket, session, request, response, event series, completion marker, channel, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Define the queue question before selecting an action

Record the intended Asterisk node, running branch and maintenance release, manager session, queue name, member identity and collection time. Decide whether the consumer needs a compact queue summary or a detailed status listing; do not collect a broad inventory merely because the account can.

A queue name, member interface, display label, device state and agent identity are different keys. Preserve the configured and runtime identifiers actually returned by the selected server.

Use QueueSummary for the documented summary request

The generated reference defines Action: QueueSummary with an optional Queue filter and an ActionID returned for correlation. Use an explicit queue when the question is queue-specific, preserve the complete response series supplied by the installed release and retain evidence that the transaction ended.

A summary is a point-in-time aggregate. It is not a member roster, per-caller timeline, SLA proof, historical report or call-outcome record.

Use QueueStatus for detailed filtered status

The generated reference defines Action: QueueStatus with optional Queue and Member filters plus a returned ActionID. Record whether each filter was omitted, empty or populated; an unfiltered request can describe more queues and members than the intended scope.

Retain every response item and the installed release's completion evidence before publishing a snapshot. One matching row, initial success response or quiet interval does not establish a complete list.

Correlate the entire transaction to one current session

Assign a fresh non-secret ActionID, terminate the AMI request correctly and associate every response item and completion boundary with both that identifier and the current manager connection. A reconnect starts a new session; late data from the old socket must not enter the new snapshot.

When a collector pipelines actions, arrival order alone is insufficient. Preserve raw frames so added fields, unknown event types and parser decisions can be reviewed without rerunning production queries.

Keep snapshots separate from configuration and history

A status row or summary value reports runtime state at one moment. Compare it with the effective queue configuration, dynamic member source, device state, queue log and call records when the operational question requires those facts. Do not infer why a value changed from two snapshots alone.

Queue membership, login or pause state, reachability, caller position, ringing, answer, abandonment and media each have separate evidence. A complete AMI transaction is not proof that a member could be contacted or a caller was served.

Accept the collector through bounded negative cases

Test one authorized queue, a nonexistent queue, a scoped member filter, an account without the required visibility, a reconnect and an intentionally interrupted response series in a controlled environment. Require the collector to distinguish empty, denied, malformed, incomplete and complete results without granting broad manager permissions.

No PBX, queue, member, caller, manager configuration, socket, session, response series, completion marker, channel, packet, media stream or live call was inspected or tested for this guide.

Use a completed snapshot after each queue-member mutation

The AMI queue-member control guide treats a post-change QueueStatus snapshot as a separate postcondition.

Use a later completed snapshot after QueueReload

The AMI queue reload and reset guide treats a snapshot as a separate postcondition and named rules as a separate inspection.

Use QueueEntry to resolve the live caller channel

The AMI queue caller-control guide verifies priority or later absence only after a completed same-queue snapshot.

Read Ringinuse and Status as different member fields

The ring-in-use control guide requires a completed later snapshot before interpreting the setting.

Do not use custom history as a live queue snapshot

The AMI QueueLog guide treats a custom row as historical evidence rather than current membership or caller state.

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.