Asterisk AMI extension-state queries, lists and hint evidence

Name the extension and context exactly

AMI ExtensionState checks one Exten in one Context. If that extension has a loaded hint, Asterisk derives the answer from the connected device state or states and returns the hint plus status. The context is therefore part of the identifier, not a display label that a client may omit or guess.

Confirm the installed branch, action response, loaded dialplan and exact context before interpreting the number. EXTENSION_STATE() defaults an omitted context to default, but the AMI action documents both Exten and Context; do not transfer the dialplan function default into an AMI request.

Treat extension state as a hint aggregate

A device-state provider describes one device, while extension state can aggregate several devices named by a dialplan hint. The HINT() function exposes the mapped device string, and the hint syntax can include multiple devices plus a separate presence provider. Preserve that mapping with the observation.

An extension-state answer is not a registration, contact, channel or queue-member record. Even an idle aggregate does not prove that an endpoint is reachable, that a new call will be accepted, or that the user is available.

Close ExtensionStateList at its completion

ExtensionStateList produces a sequence of ExtensionStatus events followed by ExtensionStateListComplete. Buffer the rows and publish the snapshot only after the completion event; compare its ListItems count with accepted rows. Missing completion means an incomplete transaction, not an authoritative empty list.

The action documents ActionID, but the generated row and completion schemas do not list it. Retain raw frames and verify the installed release and client library. When row correlation is not demonstrated, serialize list requests on that manager session instead of assigning interleaved rows by assumption.

Preserve status numbers, text and removal signals

ExtensionStatus publishes Status and StatusText. The documented numeric values include idle, in use, busy, unavailable, ringing, combined in-use-and-ringing, hold and combined in-use-and-hold, plus -1 for a removed hint and -2 for a removed extension. Preserve the raw number and text together rather than treating a negative value as merely offline.

The EXTENSION_STATE() function uses strings such as NOT_INUSE, INUSE, RINGINUSE, HOLDINUSE and ONHOLD; these names do not exactly match AMI text such as Idle. Build any translation explicitly and test it against the installed branch rather than joining records by spelling.

Version-gate live ExtensionStatus events

The single query is documented from Asterisk 0.4 and the list from Asterisk 13. The generated ExtensionStatus event carries later maintenance-release markers, including Asterisk 22.1.0, and is raised when a hint changes because device state changed. Confirm the exact maintenance release before requiring that event shape.

Keep device-driven ExtensionStatus separate from presence-driven PresenceStatus. A hint can map both device and presence sources, but the event names, triggers and payloads are not interchangeable.

Verify subscription and call outcomes separately

A loaded hint, a direct response, a complete list and a live hint event are PBX-side evidence. SIP SUBSCRIBE acceptance, NOTIFY delivery and endpoint lamp rendering require their own records. Registration, qualification, queue eligibility, routing, answer, two-way media and business availability remain separate outcomes.

Apply manager read permissions, event masks and filters deliberately, retain timestamps and raw frames, and validate the consumer at its owner. No PBX, module, manager session, dialplan, hint, state provider, subscription, endpoint, packet, media stream or live call was inspected or tested for this guide.

Verify the loaded hint before reading its state

The AMI runtime dialplan guide covers exact creation, replacement and removal of a context-bound hint priority.