Asterisk queues: member state, caller outcomes and evidence

Keep five states separate

A loaded queue, a caller admitted to it, a member listed in it, a member currently eligible and a call bridged to that member are different facts. Registration or SIP qualification does not establish queue membership, and membership does not establish that the member is unpaused, available or outside wrap-up. A ring attempt does not establish that the member answered.

Start with one queue, one caller and one expected member. Record the queue name, member interface, state interface, membership type, device status, pause reason, in-call flag and wrap-up value. The Asterisk QueueMemberStatus event exposes those fields, but it reports current state rather than proving a completed call.

Bind membership to the right state source

AddQueueMember() identifies the callable interface separately from the optional stateinterface used for device-state tracking. Its arguments can also set penalty, member name, initial pause state, pause reason and member-specific wrap-up time. If the state interface does not represent the device that should govern availability, the member can appear in the queue while eligibility follows the wrong state source.

Treat the ADDED, MEMBERALREADY and NOSUCHQUEUE results as operation outcomes, not call acceptance. On FreePBX-managed systems, use the supported GUI or documented dynamic-agent controls rather than editing generated queue files.

Pause deliberately and record its scope

PauseQueueMember() and the AMI QueuePause action can pause or unpause a member in one named queue. When the queue is omitted, the operation applies across every queue to which that member belongs. Supply a reason where the workflow supports one: Asterisk can expose it in manager events and write the dialplan application's reason to the queue log.

A paused member is not the same as a logged-out member or an unreachable endpoint. Record the queue scope, prior state, reason and exact undo step before changing production. PQMSTATUS=PAUSED confirms that the pause operation found a member; it does not prove that a waiting caller subsequently reached someone.

Use snapshots and events for live state

Use queue show in the Asterisk CLI for a focused runtime inspection and the AMI QueueStatus action when an authorized integration needs a structured snapshot. QueueStatus can filter by queue and member. A QueueMemberStatus or QueueMemberPause event records a state transition; neither a snapshot nor an event stream is a historical call ledger.

Compare the live state with the intended configuration and capture it at the reproduction time. Limit AMI credentials and event access to the required queues and data. A dashboard that says “available” is only as current as its last successful snapshot or event and the state source behind it.

Branch on the caller outcome

The Queue() application does not answer a channel automatically. If the caller should hear queue media, the dialplan must deliberately provide Answer(), Progress() or Ringing() as appropriate to the call path. When Queue() returns, inspect QUEUESTATUS rather than treating every return as the same failure. Documented results include TIMEOUT, FULL, JOINEMPTY, LEAVEEMPTY, JOINUNAVAIL, LEAVEUNAVAIL, CONTINUE and WITHDRAW.

ABANDONED=TRUE indicates that no member answered the caller. QUEUEWAIT and QUEUEWAIT_MS describe wait time, while answered and dialed timing variables describe other boundaries. An AgentConnect event is stronger evidence than a ring attempt because it is raised when a member answers and is bridged to the caller. Preserve the caller and destination linked identifiers when correlating legs.

Use the queue log for historical outcomes

The queue log, stored by default at /var/log/asterisk/queue_log, records queue-specific events with a timestamp, call unique ID, queue, member channel, event name and event parameters. Events such as ENTERQUEUE, CONNECT, completion, transfer, abandonment and empty-queue exits describe different boundaries. A normal CDR may not carry that same queue detail.

For one authorized reproduction, preserve the relevant queue-log lines, AMI or CLI snapshot, dialplan branch and call identifiers. Redact caller information before sharing. Correlate timestamps and identifiers instead of assuming adjacent lines belong to the same call. Log presence proves that an event was written; it does not by itself prove audio quality, agent procedure or caller satisfaction.

Run a small acceptance matrix

Test the same member idle, paused, busy or unavailable, and removed or logged out. Include a caller timeout and one answered call. For each case, predict the member state, whether the interface should be attempted, the Queue() return or bridge outcome, the expected queue-log event and the rollback.

If Asterisk attempts the member but the phone never rings, continue with endpoint and SIP signaling evidence. If the member is never selected, stay at queue membership, state, pause and policy boundaries. Restore the baseline after the matrix and update agent procedures when the cause is a stale login or pause rather than compensating with broader ringing rules.

Do not substitute user presence for member eligibility

A user's presence selection does not automatically change device availability or queue routing. Use the device-state and hints guide to distinguish the state provider and any hint aggregation, then keep queue membership, state interface, pause, wrap-up, ring-in-use and strategy in this guide's evidence chain.

Bind FreePBX caller symptoms to Queue outcomes

The FreePBX caller-side diagnostic follows one managed queue call through QUEUESTATUS, wait evidence, member offers, the queue log and the final FreePBX destination. Runtime observations remain evidence; durable corrections stay with the FreePBX-owned record.

Trace a missing or misattributed queue-log record

The queue-log diagnostic follows one queued caller through the configured file or realtime target, native and custom event identity, retention and reporting. It does not turn log presence into proof of audible media or caller outcome.

Separate queue configuration from manager snapshots

Use the AMI queue-snapshot guide for point-in-time summary and detailed status without turning either into historical or call-outcome proof.

Separate membership controls from queue call outcomes

The AMI queue-member control guide distinguishes interface, state interface, pause, penalty, eligibility, ringing and answer.

Separate queue configuration reload from statistics reset

The AMI queue reload and reset guide distinguishes runtime members, rules and parameters from reset counters, historical logs and caller outcomes.

Separate priority ordering from withdrawal and answer

The AMI queue caller-control guide scopes priority, position, queue departure, dialplan continuation and call outcome.

Do not collapse member state into ring-in-use policy

The queue-member ring-in-use guide separates StateInterface, numeric status, eligibility, offer and answer.

Keep custom markers distinct from native queue events

The AMI QueueLog guide does not let a custom label inherit CONNECT, abandon, transfer or completion semantics.