VoIP.info Guide

Asterisk AMI command inventory and permission evidence

Use ListCommands and the administrator CLI to distinguish the actions visible to one manager user from the actions registered by the running Asterisk instance.

Reviewed 2026-10-29Asterisk branch-23-generated and branch-22-generated ListCommands references plus official AMI syntax, v2 specification, manager-command, change/versioning, permission, module-loader and network-security documentation reviewed October 16, 2026; installed branch and maintenance release, build, package and module set, manager user, read and write authorizations, session mask, action registration, request framing, parameters, target objects, response, related events and service outcome remain deployment specific; no PBX, module, package, manager user, manager session, request, response, event, configuration file, channel, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Inventory the exact manager session

Record the running Asterisk branch and maintenance release, build and package source, server identity, manager username, transport, connection time and client version. Send a uniquely generated ActionID with Action: ListCommands, retain the complete response and keep credentials out of the record.

ListCommands returns an action name and synopsis for every manager command available to that authenticated user. It is a session-scoped authorization view, not a declaration that every action compiled into Asterisk is visible.

Treat ListCommands as a user-scoped view

Search the returned headers for the exact action name and preserve its published synopsis. A listed action establishes that the current user may see that registered action at that time. It does not establish that particular parameters, object names or downstream service behavior will succeed.

An absent action is ambiguous until another surface is checked. The user may lack the relevant write authorization, the session may use a different account or host, the owning module may not be loaded, or the installed branch, maintenance release, package or build may not register that action.

Compare the administrator-side registry

From an authorized local administrative console, manager show commands lists registered manager actions and manager show command <action> provides action detail. Record the same running process and time window as the manager session. Do not expose the console or its broader command surface to an untrusted client.

If the CLI lists an action that the user-scoped ListCommands response omits, investigate the manager account and its effective manager.conf write classes. If both omit it, investigate branch support, packaging, loaded modules and registration before changing authorization.

Keep availability separate from syntax and targets

AMI messages use Header: value lines and a blank-line terminator. An action message begins with Action; response and event messages begin with their own message types. Preserve the exact action spelling, every supplied header and the raw response instead of treating an SDK constant or documentation example as runtime evidence.

A visible command can still reject an unsupported field, malformed value, unavailable object or unsafe operation. Conversely, an Error response and its optional Message describe this request; they are not a stable cross-version fault taxonomy.

Reconcile version and module boundaries

AMI uses a major, breaking and non-breaking version scheme associated with the corresponding Asterisk major release. Actions may be added during a major line, so an old client library or static allow-list can lag the running instance. Compare the installed branch and maintenance release with the action's generated documentation and the live inventory.

When an owning module is relevant, keep package presence, loaded state, action registration and manager-user visibility as separate checkpoints. Loading or reloading a module is a privileged service change, not the first diagnostic step.

Correlate responses, events and business outcome

The v2 specification defines Response: Success or Response: Error, with an optional Message. Some actions also produce related events. Use the unique ActionID where the action and related events support it, and require the documented completion event or other transaction boundary before declaring an event list complete.

A Success response proves only the action-level contract it documents. Verify the target object and intended operational result separately, retain negative tests where appropriate and grant only the write classes required. No PBX, module, manager session, request, response, event, channel, packet, media stream or live call was inspected or tested for this guide.

Authenticate before interpreting command visibility

The AMI session-authentication guide establishes server, manager identity and connection lifetime before comparing user-scoped commands.

Confirm core-query visibility before parsing values

The core status and settings diagnostic separates action availability and authorization from response-schema or value disputes.

Confirm queue-query visibility before parsing rows

The queue-snapshot diagnostic separates action visibility and authorization from empty filters or incomplete response series.

Confirm mailbox action visibility before interpreting an empty result

The mailbox-query diagnostic separates unavailable or denied actions from wrong context, stale storage and parser behavior.

Confirm the installed voicemail action before parsing

The voicemail-user diagnostic separates unavailable, denied, unsupported and incomplete results.

Check maintenance release before an MWI control

The AMI MWI control diagnostic treats an unavailable version-sensitive action separately from denial or bad state.

Distinguish denied inventory from an empty conference list

The ConfBridge list diagnostic verifies module and permission before interpreting runtime state.

Inventory ConfBridge actions before widening control rights

The ConfBridge control diagnostic uses same-account action inventory before interpreting a failed or unavailable control.

Scope parking write and observation permissions separately

The AMI parking guide distinguishes Park authority from CALL-class event and inventory visibility.

Keep AMI visibility attached to branch and build evidence

A command can be absent because the running branch or build never registered it, or hidden from a user-scoped inventory by authorization. The version/build diagnostic keeps those owners separate.

Inventory Getvar and Setvar for the actual manager user

Use the AMI variable diagnostic to prove action visibility and authority before changing manager permissions.

Inventory AstDB actions for the deployed branch

Use the AMI AstDB diagnostic to prove DBGetTree availability and manager authority before diagnosing data.

Verify the dynamic inbound-registration action exists

The inbound-registration diagnostic checks installed action inventory and manager authority before interpreting an empty result.

Verify endpoint-list actions and event access together

The AMI endpoint-state diagnostic checks deployed actions, manager authority, filters and parser framing before interpreting absence.

Verify AoR-list action and event access together

The AMI AoR-list diagnostic checks deployed action availability, manager authority, filters and completion before interpreting absence.

Verify both contact actions and status-event visibility

The AMI contact-state diagnostic checks action authority, event classes, filters and completion before interpreting silence.

Verify PJSIPShowAuths without broadening manager access

The AMI auth-list diagnostic checks action availability, authority and list completion before interpreting results.

Verify outbound-registration actions before automation

The runtime-control diagnostic checks installed action availability, manager authority and completed list parsing.

Do not invent an all-transport AMI action

The TransportDetail diagnostic verifies documented action scope and terminal framing before automation.

Do not invent an all-identify AMI action

The AMI IdentifyDetail diagnostic verifies action scope, association and completion before automation.

Version-gate PJSIP maintenance actions

The maintenance-mode diagnostic checks release support, modules and manager privilege before endpoint changes.

Inventory voicemail actions before interpreting mailbox state

The AMI voicemail message diagnostic distinguishes an unavailable or denied action from an absent message.

Inventory signalling actions before interpreting a no-effect result

The AMI signalling diagnostic confirms version, module and permission before media or endpoint diagnosis.

Inventory AbsoluteTimeout before interpreting timing

The AbsoluteTimeout diagnostic checks action availability and manager authority before timer or media diagnosis.

Inventory MuteAudio before interpreting silence

The MuteAudio diagnostic checks action availability, module and manager authority before media diagnosis.

Inventory ControlPlayback before media diagnosis

The ControlPlayback diagnostic checks the running action, module and manager authority before interpreting audio.

Let the runtime inventory reject removed Monitor actions

The AMI Monitor diagnostic checks exact version and res_monitor availability before changing permissions or files.

Inventory Hangup without granting Command as a shortcut

The AMI Hangup diagnostic keeps the dedicated action and CLI-equivalent Command authority in separate risk boundaries.

Inventory SendText without broadening manager authority

The AMI SendText diagnostic preserves action availability, permission and channel-driver outcome separately.

Inventory MessageSend without granting broad manager control

The AMI MessageSend diagnostic separates action availability, authority and downstream routing.

Inventory AOCMessage without broad manager authority

The AMI AOCMessage guide limits target, tariff source, message phase and sensitive fields.

Inventory the app_agent_pool surface before control

The AMI agent guide checks Agents and AgentLogoff availability, authority and event classes before relying on them.

Inventory the res_fax manager surface

The AMI fax-session guide checks FAXSessions, FAXSession and FAXStats support before interpreting missing data.

Inventory PJSIPShowResourceLists support

The AMI resource-list guide checks action and event authorization before treating missing rows as configuration evidence.

Inventory both DAHDI snapshot actions

The AMI DAHDI guide checks version and authorization before interpreting missing spans or channels.

Inventory PRI status and debug actions separately

The AMI PRI guide checks support and privilege before using one read action and three debug-control actions.

Interpret missing chan_sip actions against the installed release

The AMI chan_sip migration guide distinguishes expected removal from module and permission failures.

Inventory chan_iax2 actions before interpreting absence

The IAX2 AMI diagnostic separates unknown, denied, unavailable, empty and incompletely framed results.

Inventory bridge-technology controls before interpreting absence

The bridge-technology diagnostic separates unknown, denied, incomplete and completed-empty observations.

Inventory LoggerRotate before interpreting a denial

The LoggerRotate diagnostic separates missing action, manager authorization, acceptance and storage outcomes.

Bound remote debugging commands by authority and impact

The crash and backtrace guide requires an explicit owner and service-impact window for running captures and lock inspection.

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.