Freeze one disputed member and call window
Preserve node and release, app_queue state, configuration owner, manager account permissions and filters, request and response, ActionID, exact queue, Interface, MemberName, StateInterface, requested RingInUse, change event, completed before and after QueueStatus sequences, device-state sequence, caller and member channel identities, endpoint response and call outcome. Redact credentials and personal numbers.
Classify the earliest mismatch: rejected action, wrong node, wrong queue, wrong member interface, hidden event, stale or incomplete snapshot, later overwrite, wrong state source, member ineligible for another reason, no offer, endpoint refusal, no answer or media failure.
Prove target identity and request scope first
Compare the literal request Interface and Queue with the member record on the responding node. Do not substitute MemberName, an extension number, a PJSIP contact or the StateInterface. The branch-22 and branch-23 action pages show a required-looking three-field syntax but document no omission defaults or all-queue behavior; do not repair uncertainty by assuming one.
Retain the raw response. A success response is request evidence only. If FreePBX owns the queue, compare its stored setting and generated Asterisk configuration separately; a runtime AMI change is not represented as durable across a later apply, reload or restart without observation.
Correlate the change event conservatively
Find QueueMemberRinginuse on the same node with exact queue and member interface. Its schema carries the member state fields but does not list ActionID, so use timestamps and transport continuity without inventing direct correlation. Missing events require checking AGENT-class authorization, filters, disconnects and parser framing before concluding that the setting did not change.
Then obtain a completed later QueueStatus sequence and compare Ringinuse. A setting that briefly changed and was overwritten is different from a rejected action or stale dashboard. Preserve all transitions rather than selecting only the preferred value.
Validate the StateInterface and numeric status
Compare the member's exact StateInterface with the device name reported by a completed DeviceStateList sequence. DeviceStateList produces DeviceStateChange rows and a DeviceStateListComplete terminator; do not treat one row or socket quiet as a full inventory. Preserve unknown, not-in-use, in-use, busy, unavailable, ringing, ring-in-use and on-hold distinctions.
A reachable PJSIP contact is not the same fact as the device state used by the queue. Local-channel members, custom device states, shared endpoints and multiple contacts can make an extension label especially misleading. Repair the proved state source before changing queue policy to mask it.
Walk every remaining eligibility and offer boundary
At the caller decision time, check membership, pause state and reason, wrap-up, penalty, queue strategy, caller presence, InCall, numeric status and ring-in-use policy. A later snapshot can explain state but cannot recreate every instant. Preserve the actual selection and outbound channel evidence to determine whether Asterisk attempted the member.
If an offer occurred, continue through endpoint response, call waiting or forwarding behavior, answer, bridge and media. Ringinuse permission does not force an endpoint to accept another call; disabling it does not prove every non-queue path is blocked. A wrong caller outcome can begin after correct queue eligibility.
Repair one boundary and repeat a controlled test
Correct only the proved node selection, manager privilege, queue or member identity, explicit value handling, event visibility, snapshot framing, state interface, FreePBX ownership, eligibility input or endpoint behavior. Repeat with one disposable member and caller, and record action acceptance, setting event, later member record, state, selection, offer, endpoint response, answer, bridge and media separately.
No PBX, module, queue, member, manager account, session, event stream, endpoint, packet, audio or live call was inspected or tested. Availability, compatibility, accepted literals, persistence, eligibility, ringing, answer, media quality and caller outcome remain deployment specific.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.