Asterisk AMI command inventory and permission evidence

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.