VICIdial Troubleshooting: Symptom-First Guide

VICIdial troubleshooting works fastest symptom-first: match what the floor is seeing — dropped calls, dead air on connect, one-way audio, an empty hopper, spam labels — to the layer that owns it (dialer configuration, the Asterisk server, or the carrier), then apply that layer’s fix. Most chronic dialer symptoms trace to one dominant cause, and this guide routes each symptom to its fix.

You searched a symptom, not a cause — that’s the right instinct. Find your symptom in the table below, read which layer usually owns it, and follow the link that owns the repair.

The symptom table: what breaks, which layer owns it

Symptom	Usual layer	Dominant cause	Where the fix lives
Hopper empty / leads not dialing	Dialer config	Hopper gates: cron, campaign/list state, statuses, call-time windows	This page, below
Dead air when a contact answers	Dialer config	AMD analysis time — or a real audio-path fault	This page, below
DROP percentage climbing on the real-time screen	Dialer config	Pacing outruns agents: dial method, dial level, Drop Call Seconds	This page, below
Calls dropping mid-call	Server or carrier	Carrier disconnect vs. signaling/media timeout	This page, below
Calls dying at the same second or minute mark	Server/network	Lost ACK, failed session-timer refresh, or an RTP timeout	This page, below
One-way audio	Server/network	NAT advertising a private address in SDP	One-way audio fix guide
DTMF or codec faults after setup	Dialer config	Trunk settings drift	Trunk setup guide
403 rejections in the logs	Carrier/account	Auth, CID, balance, or destination limits	SIP 403 Forbidden guide
503 bursts in the logs	Carrier	No route found or CPS limit reached	SIP 503 guide
Slow ring start after dialing	Carrier/route	Post-dial delay on the terminating path	PDD guide
Calls labeled “Scam Likely”	Network analytics	Per-carrier CID reputation scoring	Spam label fix + attestation setup
Contact rate sliding week over week	Network analytics	Reputation decay across your CID pool	Caller-ID reputation guide

The hopper, dead-air and dropped-call families are worth solving right here, because the fix is diagnosis more than configuration.

Hopper empty: leads exist, VICIdial isn’t dialing

The hopper is loaded by a script, AST_VDhopper.pl, that must run from cron every minute. If that cron entry stalls, no leads load no matter what the campaign screen says — so a silent floor starts with a cron check, not a campaign check.

When cron is fine, the script itself is a series of gates, and every gate can zero your hopper. From the script’s own logic: it only processes campaigns set active, and only pulls from lists that are attached to the campaign and active themselves. Only leads whose status appears in the campaign’s dial statuses list qualify. A lead filter, if set, excludes everything it doesn’t match.

The gate operators forget is local call time. The hopper enforces each lead’s calling window using the lead’s GMT offset against the campaign’s call-time rules — including per-state call times — so leads outside their local window are never loaded at all. A list full of West Coast numbers at 8 a.m. Eastern produces an empty hopper that fixes itself at 11. That behavior is also your TCPA calling-hours enforcement, so resist the urge to disable it in production.

A checklist circulates in the VICIdial community: set call time to 24-hour for a test, set the filter to NONE, confirm the list and campaign are both active, and confirm the lead statuses are dialable. It is community material, but each gate it tests is real in the hopper script. Two more dials to check. Hopper level is the count the script keeps the hopper filled to on each minutely run. With auto-scaling enabled, the effective level is derived from logged-in agents times dial level, with the configured level as the floor.

Dead air on connect: AMD timing vs. a real audio fault

Dead air after a contact says “hello” has two very different causes, and the first diagnostic question is whether answering machine detection is in the path.

AMD cannot begin classifying until the carrier signals Answer — the VICIdial project’s own Astricon material states detection cannot start until after the Answer signal. Every moment of analysis after that point is silence the contact hears. That is the core trade-off, in the project lead’s framing: the longer the analysis time, the better the accuracy — and the more likely the customer hangs up. The built-in Asterisk app_amd is subject to the same trade-off, and loud background noise on the contact’s end degrades every AMD engine.

So the test is simple: place a manual call with AMD off. If the dead air disappears, your fix is tuning the analysis window and routing, covered in our answering machine detection guide. If silence persists on a manual AMD-off call, you have an audio-path problem — usually NAT advertising a private address in the SDP — which the one-way audio deep dive owns.

VICIdial dropped calls: two faults share one name

Two different things get reported as VICIdial dropped calls, and they have nothing in common. The first is a contact who answered and never reached an agent. VICIdial’s own status list defines DROP as “Agent Not Available — call was dropped while customer was waiting for an agent.” PDROP is its cousin: a pre-routing drop, hung up the instant the Answer signal arrives. Both mean the dialer placed more calls than the agents could absorb. Neither says anything about your carrier.

The second is a live conversation that died mid-call. The floor calls both “dropped calls,” but the real-time screen’s DROP column counts only the first kind. So before touching config, ask which one you are chasing. Pacing drops are fixed in campaign settings, and they are a compliance number. Mid-call drops are fixed in Asterisk, the network, or the carrier, and the hangup cause names which.

Pacing drops: Drop Call Seconds, Drop Action and the dial method

VICIdial’s help text defines Drop Call Seconds as “the number of seconds from the time the customer line is picked up until the call is considered a DROP,” outbound calls only. Drop Action decides what happens then. HANGUP ends the call. MESSAGE sends it to the drop extension, VOICEMAIL to a mailbox, IN_GROUP to an inbound group. The safe-harbor variants play an audio file (AUDIO) or hand the caller a call menu (CALLMENU).

The regulatory clock is shorter than most Drop Call Seconds settings. The FCC counts a telemarketing call as abandoned when no agent connects within two seconds of the person’s completed greeting, and caps abandons at 3 percent per campaign over 30 days. Our abandoned call rate guide covers the measurement. Drop Call Seconds controls what the contact hears. It does not change what the rule counts.

Pacing itself lives in Dial Method and Auto Dial Level. Auto Dial Level is lines per active agent; zero turns auto-dialing off. RATIO dials that fixed multiple. The three ADAPT methods let the dialer move the level itself against your dropped-percentage target. ADAPT_HARD_LIMIT stops aggressive dialing once the drop limit is reached, until the percentage falls again. ADAPT_TAPERED allows running over the target early in the shift and tightens as the campaign’s latest server time approaches. ADAPT_AVERAGE aims for an average drop percentage, imposing hard limits less aggressively than the other two.

In any ADAPT mode only the dialer changes the level — the ADAPT OVERRIDE box is the manual escape hatch. One more dial matters here: Dial Timeout caps how long an attempt rings before VICIdial gives up, overriding the extensions.conf timeout when it is shorter. The help text suggests 21–26 seconds when answering-machine and voicemail results run high.

A DROP percentage climbing on the real-time screen is therefore a settings problem, not a trunk problem. Lower the level or move from ADAPT_TAPERED to ADAPT_HARD_LIMIT, then watch the next hour. The carrier reaches this number only indirectly: variable post-dial delay makes the algorithm’s timing assumptions wrong, as the predictive dialer guide explains.

Mid-call drops: read the hangup cause before touching config

When calls drop, Asterisk already recorded why — the SIP response maps to a hangup cause. In Asterisk’s mapping, a carrier 403 becomes CALL REJECTED (cause 21) and a 503 becomes CONGESTION (cause 34). A rejection points at account and authorization issues; congestion points at routes and rate limits. If blocked-call codes appear, SIP 603+ (“Network Blocked”) is the FCC’s standard blocked-call code, mandatory since March 25, 2026 — our 603 guide decodes the Reason header.

One trap deserves flagging: Asterisk’s AUTO-CONGEST is not a 503 — it is a no-response INVITE timer, and no response points at reachability (a firewall, IP allowlisting, an unresponsive proxy), not at campaign settings. The 503 guide’s AUTO-CONGEST section untangles the two.

Drops that consistently hit at a fixed interval mid-call are a different family — usually session-timer or NAT keepalive issues, covered in the trunk setup guide’s troubleshooting section and decoded timer by timer below.

Drops at a fixed time mark: match the pattern to the timer

A drop that lands at the same second every call is a timer firing. Each timer has its own signature.

Drop pattern	Mechanism	Where to look
Every call dies about 32 seconds after answer	The ACK to the 200 OK never arrived. RFC 3261 §13.3.1.4 has the answering side retransmit the 200 OK for 64×T1 (T1 = 500 ms, so 32 s), then send a BYE	NAT or a SIP ALG rewriting headers
Long calls die at the same minute mark (often ~15 or ~30 min)	A session-timer refresh failed. chan_sip session-expires defaults to 1800 s, session-minse to 90 s; PJSIP timers_sess_expires is also 1800	session-timers mode in sip.conf; carrier timer support
Calls drop after a stretch of silence, or on hold	RTP timeout. Asterisk hangs up when no RTP or RTCP arrives for rtptimeout seconds (rtpholdtimeout on hold)	The media path: one-way audio, missing keepalives
Drops cluster on one trunk with CONGESTION in the log	Carrier 503, route failure or CPS limit	Carrier Log Report + 503 guide
Every attempt on a trunk congests with no SIP response	Asterisk AUTO-CONGEST no-response timer; a reachability fault	Firewall, IP allowlist, proxy

The 32-second drop is pure SIP arithmetic. When the contact answers, the far side sends 200 OK and waits for your ACK. RFC 3261 gives that wait a limit — 64 × T1 (§13.3.1.4), with T1 defaulting to 500 ms (Section 17) — so it expires at 32 seconds. If the server retransmits the 2xx response for that long without an ACK, the dialog is confirmed but the session should be terminated with a BYE. Two-way audio for half a minute, then a clean hangup, on every call, is that limit. The ACK is being lost or rewritten in transit. That is a NAT or SIP ALG problem, not a campaign setting; the SIP ALG guide has the router-side checklist.

Session timers are the minute-mark killer. Asterisk’s chan_sip defaults to session-timers=accept — it runs them only when the far end asks — with session-expires at 1800 seconds and session-minse at 90. PJSIP’s defaults are timers=yes, 1800 and 90. RFC 4028 recommends that the refresher send its re-INVITE or UPDATE once half the session interval has elapsed. So an 1800-second session is refreshed near the 15-minute mark; when that refresh fails, or the far end never sends one, the call ends near 15 or 30 minutes.

Dialer calls are short, so most floors never see this — until a long close dies at the same minute every time. Confirm the carrier honors session timers, or set session-timers=refuse on that peer to take timers out of the equation while you test.

The RTP timeout is the one operators forget they set. Asterisk’s sample sip.conf documents rtptimeout with a 60-second example: terminate the call after 60 seconds of no RTP or RTCP activity on the audio channel when not on hold. rtpholdtimeout is the on-hold equivalent, 300 seconds in the sample, and must be larger. PJSIP’s rtp_timeout defaults to 0 — off — so it only bites where someone enabled it.

A drop that follows silence, a long hold, or a one-way-audio call is this timer doing its job on a media path that stopped flowing. rtpkeepalive, off by default, sends packets to keep NAT pinholes open; the RTP explainer covers what the media stream needs from the network.

Where each layer writes its evidence

Start in VICIdial’s own reports. The real-time report shows drops per campaign as they happen. The Carrier Log Report on the hidden Admin Utilities page summarizes a date range by dial status, hangup cause and SIP response — how many attempts answered, congested or failed, and with which codes — though not per carrier ID. The Hangup Cause Report, Dial Log Report and SIP Event Report sit beside it. The backup carrier guide explains how to get a true per-carrier comparison out of them.

Then drop to Asterisk. sip set debug on (chan_sip) or pjsip set logger on prints the SIP dialog to the CLI, so you can see the INVITE, the response, and whether the ACK or the refresh ever left your box. A packet capture with tcpdump or sngrep on the SIP port is the neutral record when you and the carrier disagree. Match the call by its Call-ID header; RFC 3261 uses it to group every message in the dialog, so the carrier’s log carries the same value.

The carrier’s evidence is its own SIP response and disconnect reason for that Call-ID. Ask for it. A support desk that cannot produce a per-call disposition is telling you something about the route.

What to collect before you open a carrier ticket

• Timestamps in one stated time zone, for three to five failing calls
• The caller ID and destination number of each
• The Call-ID, SIP response code and hangup cause, from the Carrier Log Report or the CLI
• Which trunk carried the call, and whether the A/B test below moved the symptom with it
• One packet capture of a failing call
• Everything changed in the last 48 hours: firewall rules, IP allowlist, dial level, carrier

That package turns a “calls are dropping” ticket into a routing investigation the carrier can actually act on.

Proving a symptom is carrier-side before blaming config

Some symptoms live outside your servers no matter what you tune. The honest way to establish that is an A/B test: split the same campaign, the same lead-list segment, and the same caller IDs across two trunks, and compare — the backup carrier and failover guide covers standing up that second trunk. If the symptom follows the trunk — drops, dead air, failed connects concentrated on one route — it’s the route. If it follows the campaign regardless of trunk, it’s your configuration.

Post-dial delay is the cleanest carrier-side measurement: time from INVITE to the first ringing response (180 or 183). The post-dial delay guide covers how to measure it, the threshold carriers treat as troubleshooting territory, and what a dialer should tolerate.

Spam labeling is carrier-side by definition: flagging is proprietary to each carrier’s analytics engine and keyed to the caller-ID number. The VICIdial project reported in its 2021 Astricon materials that as little as five minutes and 200 calls flagged a CID, and that flags took 2–21 days to clear after a number was retired. No dialer setting fixes that — remediation and attestation signing do, as the spam label guide walks through.

When the A/B test convicts the route, the fix is a carrier built for dialer traffic. SIPNEX is an FCC-licensed carrier signing its own STIR/SHAKEN A-level attestation, with 12/6 billing built for VICIdial operations.

Frequently asked questions

Where should VICIdial troubleshooting start when the hopper is empty?

The cron entry for the hopper script — it must run every minute, and a stalled cron loads nothing regardless of campaign settings. Then walk the gates: campaign active, lists attached and active, lead statuses in the campaign’s dial statuses, lead filter not over-excluding, and local call time — leads outside their local calling window are never loaded, so timezone-heavy lists empty the hopper at certain hours by design.

What troubleshooting step proves a VICIdial problem is carrier-side?

An A/B trunk test: same campaign, same lead segment, same caller IDs, split across two carriers. If the symptom follows the trunk, the route is at fault; if it follows the campaign on both trunks, it’s your configuration. Measure post-dial delay and compare drop rates per trunk over the same hours — a per-route difference on identical traffic is the evidence a carrier’s support desk can’t argue with.

Is dead air on connect an AMD problem or a carrier troubleshooting issue?

Test with a manual, AMD-off call — that one dial separates the two. AMD can’t start analyzing until the carrier signals Answer, so its analysis window is silence the contact hears; if the manual call is clean, tune AMD. If silence persists without AMD, it’s an audio-path fault — typically NAT advertising a private address in the SDP — and belongs to network troubleshooting, not dialer tuning.

How do SIP response codes speed up VICIdial troubleshooting?

They name the failing layer before you touch anything. A 403 means the carrier refused the call — authorization, caller ID, or account limits. A 503 means no route or a rate limit. A 603+ with “Network Blocked” means analytics blocking downstream. And no response at all means reachability, not rejection — the 503 guide separates a real 503 from Asterisk’s AUTO-CONGEST. Each code family has its own fix path.

What does the DROP status mean in VICIdial reports?

Agent not available. VICIdial’s status list defines DROP as a call dropped while the customer was waiting for an agent, and PDROP as a pre-routing drop hung up the instant the Answer signal arrives. Both are pacing outcomes: the dialer placed more calls than the agents could take. A conversation that died mid-call is a different fault and is not counted in that column. Read the DROP percentage as a compliance number, and fix it in Dial Method and Auto Dial Level.

Why do long VICIdial calls drop at the same minute mark?

Session timers. Asterisk’s chan_sip defaults session-expires to 1800 seconds, and PJSIP’s timers_sess_expires default is the same. RFC 4028 has the refresher send a re-INVITE or UPDATE once half the interval has passed, so a failed refresh ends calls near 15 minutes and a missing one near 30. Short dialer calls never get there, which is why it surfaces only on long closes. Confirm the carrier honors session timers, or set session-timers=refuse on that peer while you test.

Which VICIdial setting decides when a waiting call becomes a DROP?

Drop Call Seconds, with Drop Action deciding what happens next. The help text defines Drop Call Seconds as the seconds from the moment the customer line is picked up until the call counts as a DROP, outbound only. Drop Action then hangs up, plays a message, or sends the call to voicemail, an inbound group, a safe-harbor audio file or a call menu. The FCC’s clock is two seconds after the completed greeting — the setting shapes the contact’s experience, not what the rule counts.

---

Symptom still standing after the config checks? Run the A/B test against a trunk built for dialers: FCC-licensed, A-level attestation, 12/6 billing — VICIdial carrier service or (833) 665-2220.