Asterisk AMI PJSIP subscription list is missing, stale or incomplete

Freeze one direction and one completed snapshot

Record node, installed Asterisk release, loaded modules, manager identity and permissions, action name, unique ActionID, initial response, every detail event and the matching terminal event. Separately record the expected endpoint, event package, resource, direction and symptom time.

Classify the first divergence: action unavailable or denied; detail events filtered; completion missing; wrong direction queried; endpoint or subscription absent; row present but stale; SIP exchange fails; body differs; or the endpoint ignores a valid update.

Resolve action and AMI framing failures first

Both list actions are documented since Asterisk 12.0.0 and are provided by res_pjsip_pubsub. Verify the running branch, loaded module, installed manager action inventory, command authorization, event class, session filters and connection continuity.

Do not represent a successful initial response as a completed result. If the matching complete event is missing, preserve the partial rows for diagnosis but do not compare their count with another full inventory or declare the list empty.

Check inbound versus outbound ownership

Use the inbound action when Asterisk handles a peer SUBSCRIBE and sends NOTIFY. Use the outbound action when Asterisk sends SUBSCRIBE and receives NOTIFY. Confirm the row Role is Notifier or Subscriber as appropriate and preserve endpoint, Call-ID, state and subscription type.

A missing inbound row should send the investigation toward the received request, endpoint identification, authorization, event package and resource. A missing outbound row should send it toward the component expected to create and maintain that outbound subscription. Registration and subscription inventories are not interchangeable.

Trace the resource and state owner

For extension_state, confirm the endpoint context, exact extension, loaded hint, underlying device-state provider and required body generator. For mwi, confirm the mailbox names, mailbox-state source and whether the intended workflow is solicited or unsolicited. For another type, identify the providing module rather than forcing it into the built-in categories.

If a resource list is involved, inspect its event type, nested items, partial or full-state policy and batching interval. One successful child can leave a list subscription active while another resource is absent, and batching can intentionally hide a short-lived intermediate state.

Distinguish persisted metadata from a live exchange

After reload or restart, obtain a fresh completed snapshot and compare it with authorized SIP evidence. Subscription persistence can retain dialog and request metadata, while reliable-transport records can be marked for pruning after restart. Neither a retained row nor a vanished row alone proves current peer reachability.

Correlate the row Call-ID with the actual SUBSCRIBE, renewal, response and NOTIFY dialog. Protect the persisted packet, Contact URI, source address, caller identity and mailbox data; do not paste an unredacted persistence record into a ticket.

Correct the first owner and verify one visible result

Correct only the demonstrated layer: release or module availability, manager privilege or filter, endpoint identity, subscription context, hint, mailbox mapping, event handler, body generator, resource-list item, dialog renewal, network path or endpoint interpretation. Then capture a fresh completed snapshot and one bounded state change.

Require both protocol evidence and the intended user-visible result. A subscription row, NOTIFY response and lamp or BLF state remain separate checkpoints. No PBX, subscription, packet, phone display, mailbox lamp, BLF key or live call was inspected or tested.

Check whether the list changed after dialog setup

The AMI resource-list diagnostic applies the documented requirement to re-establish subscriptions after list changes.