Asterisk AMI queue-member control is accepted but agent state is wrong

Freeze one disputed control transaction

Preserve node and release, app_queue state, configuration owner, manager account permissions and filters, request and response, ActionID, exact queue, Interface, MemberName, StateInterface, penalty, paused value, reason, relevant queue-member events, pre-change and post-change QueueStatus snapshots, endpoint state, ring attempt and caller result. Redact credentials and personal numbers.

Classify the first apparent mismatch: rejected action, wrong queue or interface, all-queue scope, hidden event, stale or incomplete snapshot, later overwrite, device-state disagreement, pause, wrap-up, ring-in-use policy, no ring attempt, no answer or media failure.

Prove queue, interface and state identity

Compare the literal queue and member Interface in the request with the snapshot and event. Do not substitute a display MemberName or the device-state StateInterface. If a label is reused or a PJSIP contact changes, retain the actual member location and state source that Asterisk reported.

For add, compare every optional supplied field with QueueMemberAdded. For remove, require the exact queue and interface in QueueMemberRemoved and the later absence from a completed snapshot. Neither transition establishes endpoint registration, call-state cleanup or persistence after configuration regeneration.

Reconcile response, event visibility and later snapshot

Confirm action write authority separately from read access to AGENT-class events. Inspect the AMI event mask and filters, transport continuity and parser retention. The reviewed member event schemas do not document ActionID; correlate conservatively by node, exact queue, exact interface and bounded time rather than fabricating a request field.

Preserve a completed QueueStatus transaction after the change. An accepted response with no visible event can be an observation problem, while a matching event followed by different snapshot state can indicate a later controller or queue transition. Repair the earliest demonstrated boundary.

Explain apparently wrong availability from independent fields

Read Paused, PausedReason, numeric Status, InCall, Ringinuse, Wrapuptime, membership type, penalty and relevant timestamps separately. A reachable device can remain paused or in wrap-up; an unpaused member can still be unavailable, in a call or excluded by strategy. Penalty changes relative ordering but does not guarantee an offer.

If the member state is correct but calls do not ring, continue through queue strategy, caller admission, member selection, dial attempt and endpoint response. If a call rings but audio fails, move to bridge and RTP evidence without undoing a correct queue-member change.

Check omitted-queue scope and configuration persistence

For QueuePause and QueuePenalty, determine whether the request omitted Queue. The documented result then spans every queue to which the interface belongs. Inspect each membership instead of treating a multi-queue change as random drift. QueueAdd and QueueRemove retain their required exact queue scope.

Identify whether another manager client, agent login workflow, dialplan, queue rule or FreePBX-generated configuration reapplied state. Runtime success does not by itself prove survival across module reload, PBX restart or GUI apply. Compare stored configuration, generated files and runtime snapshot without editing generated files blindly.

Repair minimally and retest the full boundary

Correct only the proved permission, identifier, queue scope, event filter, collector completeness, later overwrite, device-state source, pause, penalty, wrap-up, strategy or endpoint defect. Repeat with one disposable member, explicit queue scope and captured before-and-after snapshots; verify any omitted-queue test only where all memberships may safely change.

Keep membership, eligibility, ring attempt, answer, media and caller outcome as separate results. No PBX, module, queue, member, configuration, manager account, session, event stream, endpoint, packet, audio or live call was inspected or tested for this diagnostic; availability, compatibility, persistence and call behavior remain deployment specific.

Do not substitute caller priority for member penalty evidence

The queue caller-control diagnostic resolves the live caller channel before testing caller-scoped actions.

Trace a disputed ring-in-use change through its own event

The ring-in-use diagnostic verifies exact member identity, later snapshot and call-path evidence.