VICIdial agent is live but not dialing

Define the symptom before touching the campaign

Fast answer: a green or live label on the Agent screen proves only one layer of the session. The browser, the phone, the Asterisk conference — MeetMe or ConfBridge, decided per server by the conf_engine column on the servers table, not by how old the install is — the vicidial_live_agents row, and the campaign's own dial process can disagree for several seconds, or stay split after an interrupted login.

Start with one affected agent and one timestamp. Confirm whether the agent can hear the conference, whether a lead is attached, and whether the campaign gate, the list gate or the hopper itself is what is actually empty, before you touch a dial-level setting.

Two terms carry the checks below. The hopper is VICIdial's own staging queue of leads a campaign is currently allowed to dial, refreshed on a fixed schedule rather than the instant a lead is loaded. The dial level (auto_dial_level) is the pacing number that controls how many outbound calls the dialer keeps in flight for every available agent — see vicidial-dialing-modes-pacing for what raising it actually does.

See vicidial-terminology-for-complete-beginners for the rest of this glossary.

• Record the agent ID, campaign, extension, conference and exact local time.
• Check whether the agent is READY, PAUSED, INCALL or attached to a stale lead.
• Confirm the list has callable leads for the campaign and the local call time window.

Understand the four layers in plain language

The Agent page is the browser session; the phone is the SIP or WebRTC endpoint; the conference is the Asterisk audio room; and the live-agent row is VICIdial's current database view. The hopper is simply the queue of leads eligible to be dialed next.

The browser session itself is two logins, not one: the Agent screen's first page takes only the phone login and password, and only once that succeeds does a second page ask for the agent user, password and campaign. A rejection at the first page is a phone-credential problem, not a dialer problem — see vicidial-phone-login-not-active for that specific failure and vicidial-first-agent-call for the full two-step walkthrough — and it will look identical to "not dialing" if you only glance at the final screen.

The browser phone's own audio leg registers over a secure WebSocket straight to Asterisk's listener on 8089, with no reverse proxy in front of it on this build. What actually gates a remote agent is the firewall, not the listener: firewalld's asterisk service opens 8089/tcp only to addresses in the whitelist and dynamic-list ipsets, so an agent connecting from outside both can still reach the login pages, look READY, and hear nothing — a firewall symptom wearing a dialer-not-working disguise.

Check the layers in that order. When one layer fails, later layers can look wrong as a consequence, so changing campaign settings before locating the first mismatch hides the useful evidence.

• Browser: the approved synthetic agent is logged in once.
• Audio: the endpoint is registered and joined to the expected conference.
• Dialer: the live row and hopper belong to the same approved campaign.

Correlate Asterisk and the conference with the live-agent row

Read the channel table and the conference list together. A database row without a matching conference party is evidence of a stale session, not proof the phone itself is broken.

Do not clear rows in bulk. Both app_meetme and app_confbridge can be loaded on the same Asterisk instance at once, so a meetme list or confbridge list that finds nothing is not, on its own, evidence that the other one is the real engine — confirm that from servers.conf_engine instead, the exact check vicidial-first-agent-call already walks through. Use the two list commands here only to see whether a specific party is actually present, not to discover which engine is authoritative.

asterisk -rx 'core show channels concise'asterisk -rx 'meetme list'asterisk -rx 'confbridge list'

Confirm the agent is actually READY, then look at the carrier separately

A live-agent row that never reaches READY cannot receive an automatic call, no matter how healthy the campaign or hopper are. vicidial_live_agents.status is VICIdial's own real-time view of every session on the server right now; aggregate it by status rather than reading individual rows, so a shared lab or production server's other sessions never appear in the result.

A carrier problem produces the same outward symptom — the agent is READY, the hopper has work, and still nothing rings — for a different reason. This article does not re-teach carrier setup or SIP registration: see vicidial-add-sip-carrier for connecting a trunk and carrier-dns-failure for a carrier that stops routing after it previously worked.

SELECT status, COUNT(*) AS agentsFROM vicidial_live_agents WHERE campaign_id = '<CAMPAIGN_ID>' GROUP BY statusORDER BY status;

Confirm the campaign itself is willing to dial

A campaign that is inactive, on the wrong dial method, or already at dial level 0 will never pull a lead out of the hopper for an agent, no matter how healthy that agent's session is. dial_method names the pacing method — MANUAL, RATIO, or one of the three ADAPT_* methods — and auto_dial_level is VICIdial's own pacing number for it; on a MANUAL campaign, VICIdial locks auto_dial_level at 0 by design, not as a fault to fix. See vicidial-dialing-modes-pacing for what each method and level actually does; this check only confirms which one is configured.

dial_prefix is a separate setting from the dial method. A literal x in the prefix means no prefix is added at all, deliberate on a no-carrier lab setup, while a real carrier route built on this build's own shipped pattern expects a literal 9 (see vicidial-add-sip-carrier). A lead that never dials at all is sometimes a prefix left set for the wrong one of those two situations.

SELECT campaign_id, active, dial_method, auto_dial_level, dial_prefix, manual_dial_prefix, omit_phone_codeFROM vicidial_campaignsWHERE campaign_id = '<CAMPAIGN_ID>';

Confirm the list is active and the lead belongs to it

A campaign can be perfectly healthy and still have nothing to dial if its list is inactive, or if the lead you are testing with was loaded under a different list or campaign than you think. Join the two tables instead of trusting either one in isolation.

SELECT list_id, active, campaign_id, COUNT(*) AS leadsFROM vicidial_listsJOIN vicidial_list USING (list_id)WHERE list_id = '<LIST_ID>'GROUP BY list_id, active, campaign_id;

Confirm dial statuses, hopper limit and the call-time window

Three more campaign settings gate the hopper directly. Dial Statuses is the campaign's own allow-list of which lead statuses are even eligible to be dialed — VICIdial's own campaigns_list function documents it in its output as dial_statuses, and update_campaign edits it through dial_status_add and dial_status_remove rather than one field you overwrite directly; confirm the literal column name on your own build before selecting it, since no reference doc shipped with this build states that raw spelling. hopper_level, from 1 to 2000, caps how many leads AST_VDhopper.pl is allowed to stage at once, and lead_filter_id points at a saved filter that narrows the hopper further, reading blank rather than a fixed placeholder string when none applies.

local_call_time decides the window itself, and it is not a fixed clock: it names a call_time_id VICIdial looks up, and every lead's own local time is computed once, at load time, from vicidial_list.gmt_offset_now rather than derived live from a timezone service. AST_VDhopper.pl refreshes the hopper every two minutes, and only for leads whose computed local time actually falls inside that window right now — a perfectly healthy campaign outside its own calling hours will show an empty hopper and nothing else. See vicidial-geo-gating-zip-validation for the full gmt_offset_now and local_call_time mechanism; this check only confirms which values this campaign is currently using.

A separate table, vicidial_campaign_statuses, holds this campaign's own status and disposition definitions — which codes exist, whether each counts as complete or human-answered — not the dial-eligible allow-list; see vicidial-statuses-dispositions for that full model. Confusing the two tables is an easy, and different, way to spend time looking at the wrong evidence.

SHOW COLUMNS FROM vicidial_campaigns WHERE Field LIKE '%dial_status%'; SELECT campaign_id, hopper_level, lead_filter_id, local_call_timeFROM vicidial_campaignsWHERE campaign_id = '<CAMPAIGN_ID>';

Check whether the hopper actually has staged work

A healthy agent cannot receive a call when the hopper has no eligible entries for this campaign, even once every gate above checks out. Use the Admin reports first, then a read-only query only when you are authorized to inspect the synthetic campaign directly.

On a MANUAL campaign this same hopper is exactly what Dial Next Number pulls from — an empty hopper is why the button does nothing, not a broken control.

The placeholder is intentionally not a real campaign ID. A non-zero count shows queued work by hopper status; it does not, on its own, prove local call time, list eligibility, carrier routing or consent — those are the checks above and the carrier articles this section links to.

SELECT campaign_id, status, COUNT(*) AS queued_leadsFROM vicidial_hopperWHERE campaign_id = '<CAMPAIGN_ID>'GROUP BY campaign_id, statusORDER BY status;

Recover narrowly, then prove the next call

After identifying the broken layer, re-establish that layer only: reconnect the phone, log the agent out cleanly from the Agent screen, or clear a proved stale session from Reports → Real-Time Report using its EMERGENCY LOG AGENT OUT control — the screen that actually owns live session state. Do not delete the vicidial_live_agents row by hand.

A recovery is complete only when a new lead leaves the hopper, an outbound channel appears, the bridge is audible, and the disposition returns the agent to the expected state.

• Watch one fresh call from hopper selection through disposition.
• Confirm the campaign dial level and drop metrics remain stable.
• Write the exact cause and evidence into the incident note.