Asterisk AMI presence state is missing, stale or wrong

Freeze one presentity and one expected outcome

Record the installed branch and maintenance release, loaded res_manager_presencestate and func_presencestate modules, manager identity, read permissions, session mask and filters, exact provider identifier and case, writer, expected value, subtype and message, action IDs, raw AMI frames, list completion, hint context and extension, subscription evidence and the separately observed consumer result.

Classify the symptom first: query action unavailable, unknown provider, wrong direct value, incomplete list, absent change event, provider change with no hint event, correct hint event but absent NOTIFY, or correct notification but wrong endpoint or application behavior.

Prove the provider and writer before rewriting state

Use the direct PresenceState action for the exact provider and preserve its response. Determine which application, dialplan path, CLI operation or external workflow owns changes. If the intended writer uses PRESENCE_STATE(), confirm the identifier begins with CustomPresence:; the function can query other providers but cannot write them.

Do not toggle a value merely to make a lamp change. Establish initialization, valid transitions, expiry or reset behavior and the business rule that consumes the value first.

Rebuild the list at the completion boundary

Issue one PresenceStateList with a unique ActionID, retain every raw frame and wait for PresenceStateListComplete. Compare ListItems with the rows accepted by the client. An absent completion or a count mismatch makes the snapshot incomplete even if some PresenceStateChange rows arrived.

Separate the bounded list from unsolicited live changes on the same connection. Because the generated event schemas do not list ActionID, confirm actual correlation behavior before allowing concurrent list requests; otherwise serialize them.

Choose the event that matches the question

If the provider changed but the listener saw nothing, inspect CALL-class delivery, manager read permissions, the session event mask and configured or dynamic filters before blaming the writer. PresenceStateChange covers all provider changes.

If a hint-bound consumer is wrong, inspect PresenceStatus separately. That event is raised only when a hint changes due to presence and is maintenance-release-sensitive. A missing PresenceStatus does not prove that the underlying presentity never changed.

Follow the hint into subscription delivery

Confirm the loaded hint contains the expected presence provider after the device-state portion and uses the intended context and extension. Keep presence state, device state and the extension hint result separate; Asterisk does not aggregate several presence values or automatically use an away label as device unavailability.

Then inspect the actual SUBSCRIBE dialog, NOTIFY body and endpoint rendering. A correct AMI event cannot prove that a subscriber received, accepted or displayed an update, and rewriting the source value cannot repair a downstream mapping or delivery defect.

Validate privacy and the operational outcome

Presence subtype and message can contain descriptive user text. Restrict manager access, event storage and subscriber exposure, and avoid placing secrets, medical details or unnecessary location data in those fields. Preserve only the evidence required for the incident.

Verify registration, reachability, queue policy, routing, device state, lamp rendering and media through their own records. Correct the first failing boundary and repeat one bounded transition. No PBX, module, manager session, presence provider, dialplan, hint, subscription, endpoint, packet, media stream or live call was inspected or tested for this diagnostic.

Separate presence-driven and device-driven hint changes

The AMI extension-state diagnostic keeps PresenceStatus and ExtensionStatus triggers, payloads and version boundaries distinct.