Asterisk AMI queue caller priority and withdrawal controls

Resolve one live queue entry before control

Start with the responding node, installed Asterisk release, loaded app_queue module, manager account, exact case-sensitive queue and the waiting caller's current channel name. Use a completed QueueStatus sequence to capture the QueueEntry fields that matter: queue, position, channel, Uniqueid, wait and priority. Caller-ID is descriptive data, not the control identity.

Channel names are live runtime identities and can change across a new call or Local-channel topology. Preserve the action request, response, ActionID, before snapshot and relevant lifecycle events on one clock. Do not use a stale screen row, phone number or Linkedid where the action requires the caller channel.

Change priority without promising the next answer

QueueChangePriorityCaller requires Queue, Caller, Priority and Immediate. The Caller is the caller channel on that queue. The generated branch-22 and branch-23 pages say Immediate: yes causes the priority change to be reflected immediately and changes the channel position. They do not document an omitted-field default or a priority range, so supply an explicit supported value and verify it on the installed branch.

A later completed QueueStatus snapshot can show QueueEntry priority and position. That is queue-order evidence, not proof that this caller will be offered to the next member, ring, answer, bridge or receive two-way media. Queue strategy, member eligibility, simultaneous events and caller departure can still change the outcome.

Request withdrawal and preserve optional information

QueueWithdrawCaller requires the exact Queue and caller Channel; optional WithdrawInfo is stored for retrieval in QUEUE_WITHDRAW_INFO only when the call is successfully withdrawn. The action requests return from the queue to dialplan processing. Treat the response as request evidence rather than proof that the caller has already left.

Asterisk 20 upgrade notes state that the caller is signaled to leave whenever it can and explicitly warn that departure is not guaranteed. They also describe using the optional value after successful withdrawal, for example to choose later dispatch logic. Keep that value non-secret, bounded and validated before using it as a routing selector.

Separate lifecycle events from action correlation

QueueCallerJoin, QueueCallerLeave and QueueCallerAbandon are AGENT-class unsolicited lifecycle events with channel and queue fields; the generated schemas reviewed here do not list ActionID. They can support a timeline, but the site does not invent direct request correlation or claim that every withdrawal must be represented by one particular event.

Use exact queue, channel, Uniqueid, timestamps and transport continuity to reconcile events. A leave event is not a bridge, answer, hangup cause or proof that the intended dialplan branch ran. An abandon event reports caller abandonment with position and hold-time fields; it is not automatically evidence of an operator-requested withdrawal.

Verify the postcondition that belongs to each action

For a priority change, obtain a fresh completed QueueStatus response for the same queue and match the exact live channel or Uniqueid; compare priority and position without assuming causal exclusivity. For withdrawal, confirm the caller is absent from a later complete queue snapshot, then observe the next dialplan location and read QUEUE_WITHDRAW_INFO only after successful return from Queue().

Retain queue logs, CDR and CEL as separate histories. None substitutes for the action response, current queue membership or executed dialplan. A reporting dashboard can also lag its underlying source. If the caller answered, abandoned, timed out or hung up during the control window, record that competing lifecycle instead of forcing the action into a success narrative.

Validate one disposable caller and negative cases

In an approved nonproduction window, place one disposable caller in one disposable queue and capture its exact channel from a completed snapshot. Change priority with an explicit Immediate value, then request withdrawal with a non-sensitive marker and validate the response, later queue membership, dialplan continuation and variable value independently.

Exercise wrong queue, stale channel, denied manager account, already-departed caller, unsupported release and interrupted event-stream cases. Avoid production callers because changing priority or leaving a queue changes treatment. No PBX, module, queue, manager account, session, caller, channel, dialplan, event stream, log, endpoint, packet, audio or live call was inspected or tested; documentation does not establish availability, compatibility, timing, persistence, priority effect, withdrawal, routing or caller outcome.

Record custom caller markers without replacing lifecycle proof

The AMI QueueLog guide keeps request fields and custom rows separate from withdrawal, departure and dialplan continuation.