Reader setup
Before you diagnose
- Create a read-only database account for safe VICIdial queries already completed on this host, because the call-outcome count below runs as read-only SQL.
- A curl configuration file already set up for read-only Non-Agent API calls, for example /etc/vicidial-api/readonly.cfg, so the pacing and agent-state checks need no user name or password on the command line.
- Permission to view, but not yet change, the campaign's own dial method and auto_dial_level, plus a numeric stop threshold and a defined measurement method agreed with the person responsible for abandonment limits before any pacing change.
- Expected result
- You can collect pacing, agent-state and call-outcome evidence before an authorized administrator considers a change.
- Before making changes
- Change only an authorized test campaign, one setting at a time. Stop immediately if the agreed threshold is crossed; do not wait for a full shift when the test is causing harm.
Define pacing before you describe the symptom
VICIdial's predictive pacing decides how many outbound calls to keep working per agent who currently looks free; that number is the dial level, called `auto_dial_level` in a campaign's own settings. Set above 1.0, it deliberately dials more calls than you currently have agents to answer, on the assumption that not every dialed call connects.
The symptom worth naming precisely is calls connecting with no agent actually free to take them, or an agent reporting a call landing while the real-time screen still showed them as busy a moment earlier. That is different from two genuinely simultaneous live legs landing on one agent's own line, which is outside the ordinary one-customer assignment and needs conference/transfer investigation; treat that specific report as a transfer or conference fault, not a pacing one.
A VICIdial forum thread reports this same overlap, describing calls arriving faster than agents could be freed up for them — consistent with a pacing-versus-headcount mismatch rather than one unexplained glitch.
A conference can contain several participants, including a customer, a third party and more than one agent. If two customer conversations appear to overlap, note the exact time, agent and transfer action; have the telephony owner map the conference participants and channel IDs before changing pacing. Do not dismiss a multi-party bridge as physically impossible.
Reference screenshots 3 images
Reference capture
Reference screens from the demo
Captured on an isolated VICIdial demo: Administration screens on September 24, 2026, and the idle Agent screen on August 11, 2026. Each caption states its own capture time, and every sanitized image helps you recognize a related screen; none proves that this article's call, command, or result occurred.Keep phones and users separate
Open to enlarge
Capture details
Only the fixture phone extension is shown; other rows and the server address are removed. This page identifies phone administration and does not prove registration or login success.Find the campaign the agent should use
Open to enlarge
Capture details
Only the fixture campaign row is shown; other campaigns are removed. Its columns do not prove dialing activity, performance, or a completed call.Read the real Agent screen in an idle state
Open to enlarge
Capture details
This is a real logged-in idle Agent screen with session and system identifiers redacted. Customer fields are blank, and it does not prove a placed, answered, recorded, transferred, or completed call.Pacing dials against a headcount, not a certainty
At the instant VICIdial decides to place more calls, it counts how many agents its own live-agent state currently shows as available and dials ahead of that number by the ratio `auto_dial_level` sets. If that headcount is even briefly stale — an agent mid-wrapup who has not yet changed status, for instance — the dialer places calls for capacity that does not actually exist yet, and the surplus connects arrive with nobody free.
This is why the fix is never one number taken in isolation: pacing and how accurately agent status gets reported both feed the same decision, and a change to either one changes how many calls land on nobody.
Rank the likely causes before you touch pacing
Check these roughly in order of how often each one turns out to be the answer.
- Most likely: `auto_dial_level`, or the wider dial method (VICIdial's pacing strategy — MANUAL, RATIO, or one of the adaptive modes) is simply set more aggressively than current staffing and answer rate support, or Available Only Ratio Tally is off.
- Second: an agent's live sub-status — the specific mid-workflow state the Non-Agent API's `agent_status` function reports, with documented values DEAD, DISPO, 3-WAY, PARK, RING, PREVIEW and DIAL — is not being read as busy by whatever is watching capacity, so a genuinely occupied agent still looks free.
- Third: the database itself is under enough load that live-agent status writes lag behind what is actually happening on the floor, affecting every campaign on that server at once, not just yours.
- Fourth, worth naming rather than blaming: heavier load in a virtualized environment can widen this same lag under predictive pacing without any single setting being wrong — an aggravating factor, not a root cause on its own.
Check the shipped pacing report before opening Admin
Start with the shipped Non-Agent API rather than opening Admin by hand: `campaigns_list` reports the pacing settings actually in effect for a campaign in one read-only call, including the field the export calls `dial_level`.
- Before you use it
- This function needs an API user with user_level 8 or higher and "view reports" enabled; run it before touching any setting, so you have the actual current pacing in writing, not a memory of it.
curl --fail-with-body --silent --show-error --config /etc/vicidial-api/readonly.cfg --data-urlencode "function=campaigns_list" --data-urlencode "campaign_id=<CAMPAIGN_ID>" --data-urlencode "stage=csv" --data-urlencode "header=YES"Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- One CSV row returns for the campaign, and its `dial_level` column is the number to compare against agent headcount and answer rate.
- Stop if
- An ERROR naming a permission problem means the read-only API user itself needs "view reports" enabled before this or any other reporting function will work.
Count live agent state and the PDROP-versus-DROP split together
A current agent-state snapshot and a call count over a recent window provide clues about capacity and outcomes; neither alone identifies the cause: how many agents the live-agent table currently shows in each status, and how many outbound calls in that window ended in DROP or PDROP. VICIdial's own status reference defines PDROP precisely as a call that "hung up the instant the Answer signal is received," a distinct, official capacity signature, not the same thing as a slower DROP.
Run this with your read-only account, invoked as `mysql --defaults-extra-file=/etc/vicidial-readonly.cnf -e "<statement>"`, immediately after or during the reported overlap, since live-agent counts change by the second and lose their value if you wait.
- Before you use it
- Run both together, since comparing an agent-state snapshot from one moment against a call count from a different window tells you very little.
SELECT status, COUNT(*) AS agents FROM vicidial_live_agents WHERE campaign_id = '<CAMPAIGN_ID>' GROUP BY status;SELECT status, COUNT(*) AS calls FROM vicidial_log WHERE campaign_id = '<CAMPAIGN_ID>' AND call_date BETWEEN '<START_DATETIME>' AND '<END_DATETIME>' AND status IN ('DROP','PDROP') GROUP BY status;Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- Compare the live-agent counts with the real-time screen at the same moment. The second query gives counts only; it has no denominator and cannot establish an abandonment rate or legal compliance.
- Stop if
- The live-agent counts disagree noticeably with what you can see on the floor — that points at a status-reporting lag, worth checking per-agent with the follow-up call below rather than assuming pacing alone is the cause.
Check one suspect agent's live sub-status through the API
When the counts above disagree with what you can see on the floor, check one specific agent rather than guessing which: `agent_status` reports that person's live sub-status directly from the same shipped function VICIdial itself uses, without assuming which raw table field holds it.
- Before you use it
- This function needs an API user with user_level 7 or higher and "view reports" enabled — one level lower than campaigns_list, so check permissions separately if only this call is refused.
curl --fail-with-body --silent --show-error --config /etc/vicidial-api/readonly.cfg --data-urlencode "function=agent_status" --data-urlencode "agent_user=<AGENT_USER>"Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- The response's `real_time_sub_status` field explains what that agent is actually doing right now — DISPO, 3-WAY, PARK, and the rest each mean genuinely occupied, even when the main status column alone looked free.
- Stop if
- An "AGENT NOT LOGGED IN" response means you picked someone not currently in session; rerun it against an agent who was actually on the floor during the reported overlap.
Move one lever, in a lab or off-peak window
Change one setting at a time, and agree the stop threshold before the first change, not after a bad number. If the DROP/PDROP split is the dominant evidence, lower `auto_dial_level` by no more than one small step, in Campaigns → the affected campaign's detail screen, during a lab or off-peak window, and write down the value you started from.
Record the current Available Only Ratio Tally value. Do not change it in the same test as auto_dial_level; ask the administrator to assess it separately for this build and dial method.
- Before you use it
- Note that `update_campaign`'s own field name is `auto_dial_level`, not the `dial_level` name `campaigns_list` reported earlier; sending the wrong field name will not change the setting. When a request carries no field `update_campaign` recognizes, the documented reply is `NOTICE: update_campaign NO UPDATES DEFINED` rather than an ERROR, so read the response text instead of just checking that the call returned, and confirm the value actually moved with a repeat of `campaigns_list`.
curl --fail-with-body --silent --show-error --config /etc/vicidial-api/writer.cfg --data-urlencode "function=update_campaign" --data-urlencode "campaign_id=<CAMPAIGN_ID>" --data-urlencode "auto_dial_level=<DIAL_LEVEL>"This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.
- Success looks like
- The response confirms the campaign was updated, and a repeat of `campaigns_list` shows the new value in effect.
- Stop if
- An ERROR naming "AUTO DIAL LEVEL MUST BE FROM 0 TO 18" means the value sent is outside VICIdial's own accepted range, not a permissions problem.
Verify after a full shift, not a quiet five minutes
Re-run both the agent-state and DROP/PDROP queries after one full working shift at the new level, since a quiet moment right after saving proves nothing either way.
- Compare the outcome counts with a separately verified denominator and the agreed measurement method; the sample query alone cannot calculate a rate.
- The live-agent status counts track what you can see on the real-time screen more closely than before.
- No AMD-related setting changed in the same window, so this comparison is actually clean.
When to stop and hand this to someone else
Escalate rather than continuing to step pacing down when the overlap persists even at a conservative dial level, when the database itself shows lock contention reaching beyond this one campaign, or when any live compliance or abandonment exposure is already in play — none of those improve with another small pacing change, and the last one specifically needs your compliance owner, not another edit.
Checks and sources
What was checked
- NON-AGENT_API.txt documents `campaigns_list`'s own `dial_level` export field separately from `update_campaign`'s `auto_dial_level` field, confirming the two names describe related but distinct things.
- VICIDIAL_statuses.txt defines PDROP precisely as a call that "hung up the instant the Answer signal is received," an official capacity signature distinct from a slower DROP.
Primary references
Sources
- OVERLAPPING CALLSVICIdial forum · accessed September 23, 2026
- VICIdial Non-Agent APIVICIdial · accessed September 23, 2026
- VICIdial StatusesVICIdial · accessed September 23, 2026
- ConfBridge conceptsAsterisk · accessed November 7, 2026