ViciDial VDAD Not Dialing — AST_VDadapt Process Troubleshooting

Learn how to diagnose and fix the AST_VDadapt process when ViciDial campaigns fail to initiate outbound calls, with real configuration examples, database queries, and step-by-step debugging commands.

Prerequisites

Before starting this troubleshooting guide, you should have:

• A production or test ViciDial installation (v2.13+) with Asterisk 13+ running
• SSH access to the ViciDial server with root or sudo privileges
• Basic familiarity with ViciDial campaign setup and Asterisk dialplan concepts
• Access to the ViciDial MySQL database (typically asterisk database)
• Understanding of ViciDial architecture: lead lists, campaigns, inbound/outbound routes, and carrier definitions
• The ability to check system logs in /var/log/asterisk/messages
• A test campaign configured and ready to dial

Understanding ViciDial's Dialing Architecture

What is AST_VDadapt?

AST_VDadapt is the Asterisk Adaptive Dialing engine—the core process responsible for initiating outbound calls in ViciDial. When agents are logged into a campaign, AST_VDadapt monitors the lead list, applies dialing rules (predictive, preview, manual), and generates Asterisk channels to make the actual phone calls.

The process runs as a background daemon and communicates with:

• ViciDial MySQL database — reads leads, campaign settings, carrier routes
• Asterisk dialplan — executes SIP/IAX channels via extensions-vicidial.conf
• ViciDial agent interface — receives real-time dialing commands
• System clock — enforces DNC (Do Not Call), time-based call rules

When VDAD is not dialing, no outbound calls are initiated, and agents see a frozen lead screen.

High-Level Call Flow

1. Agent logs into campaign → AST_VDadapt spawns a dialer thread
2. VDAD reads active leads from vicidial_list table
3. VDAD checks campaign settings in vicidial_campaigns and vicidial_carrier_log
4. VDAD determines outbound carrier/trunk from vicidial_carrier_log
5. VDAD executes Asterisk dialplan: exten => XXXXXX,n,Dial(SIP/trunk/number)
6. Call is logged to vicidial_log and vicidial_closer_log

If VDAD fails at any step, the call never dials.

Checking If AST_VDadapt Is Running

Verify Process Status

Start by confirming the AST_VDadapt process is actually running on your system:

ps aux | grep -i vdadapt | grep -v grep

Expected output (you should see one or more processes):

asterisk  12345 0.5 2.3 412344 95212 ?    Ssl  10:45   0:12 /usr/bin/perl /usr/share/astguiclient/AST_VDadapt.pl
asterisk  12346 0.4 1.8 398764 71256 ?    Ssl  10:45   0:08 /usr/bin/perl /usr/share/astguiclient/AST_VDadapt.pl

If no processes appear, the dialer is not running.

Restart the AST_VDadapt Service

ViciDial typically manages AST_VDadapt through init scripts or systemd:

# For systems with systemd
systemctl restart vicidial-astguiclient

# For older SysV init systems
/etc/init.d/vicidial-astguiclient restart

# Manual restart (if scripts don't work)
killall AST_VDadapt.pl
sleep 2
/usr/share/astguiclient/AST_VDadapt.pl &

Wait 10 seconds, then verify with ps aux again.

Check AST_VDadapt Logs

AST_VDadapt writes debugging output to /var/log/asterisk/ or a dedicated log file:

tail -f /var/log/asterisk/messages | grep -i vdadapt

Or check the ViciDial-specific log directory:

ls -lh /var/log/vicidial/
tail -f /var/log/vicidial/vdadapt.log

Look for errors like:

• Database connection failed
• No carriers available
• Campaign paused
• No agents logged in

Database Configuration and Lead List Issues

Verify Campaign Is Active

VDAD will not dial if the campaign itself is paused or disabled. Check the campaign status:

SELECT campaign_id, campaign_name, active, dial_method, 
       max_leads_for_24hrs, agents_logged_in 
FROM vicidial_campaigns 
WHERE campaign_id = 'TEST_CAMPAIGN';

Key fields to verify:

• active = Y (must be active)
• dial_method = ADAPT, MANUAL, INBOUND, or BLENDED (common values)
• agents_logged_in > 0 (at least one agent must be logged in)

If active = 'N', activate it:

UPDATE vicidial_campaigns 
SET active = 'Y' 
WHERE campaign_id = 'TEST_CAMPAIGN';

Check for Available Leads

AST_VDadapt cannot dial if there are no leads in the list. Query the lead table:

SELECT COUNT(*) as total_leads, 
       SUM(CASE WHEN status = 'NEW' THEN 1 ELSE 0 END) as new_leads,
       SUM(CASE WHEN status = 'CALLBACK' THEN 1 ELSE 0 END) as callback_leads
FROM vicidial_list 
WHERE campaign_id = 'TEST_CAMPAIGN';

Expected result: total_leads > 0 and new_leads > 0 (or appropriate status for your campaign).

If total_leads = 0, import or add leads:

INSERT INTO vicidial_list 
(campaign_id, phone_number, phone_code, status, gmt_offset_now)
VALUES 
('TEST_CAMPAIGN', '5551234567', '1', 'NEW', '-5');

Verify DNC List and Do-Not-Call Rules

If your leads exist but aren't dialing, they may be blocked by DNC (Do-Not-Call) rules. Check the vicidial_dnc_list table:

SELECT COUNT(*) as dnc_count 
FROM vicidial_dnc_list 
WHERE phone_number IN 
  (SELECT phone_number FROM vicidial_list 
   WHERE campaign_id = 'TEST_CAMPAIGN' AND status = 'NEW');

If a high percentage of your test leads are in the DNC list, remove them temporarily:

DELETE FROM vicidial_dnc_list 
WHERE phone_number = '5551234567';

Check campaign-level DNC enforcement:

SELECT campaign_id, dnc_enforce_state, dnc_enforce_county 
FROM vicidial_campaigns 
WHERE campaign_id = 'TEST_CAMPAIGN';

• dnc_enforce_state = 'Y' — respects state-level DNC
• dnc_enforce_county = 'Y' — respects county/regional DNC

Outbound Route and Carrier Configuration

List Configured Carriers

VDAD must have at least one carrier (trunk) configured for the campaign. Query the carrier table:

SELECT carrier_id, carrier_name, active, calling_codec, 
       technology, outbound_proxy 
FROM vicidial_carrier_log 
WHERE campaign_id = 'TEST_CAMPAIGN' OR campaign_id = 'AGENT' OR carrier_id = 'default_carrier';

If no carriers appear, create one:

INSERT INTO vicidial_carrier_log 
(carrier_id, carrier_name, active, technology, calling_codec, campaign_id)
VALUES 
('SIP_CARRIER', 'SIP Trunk', 'Y', 'SIP', 'ULAW', 'TEST_CAMPAIGN');

Verify SIP/IAX Peer Configuration

Check that the carrier's trunk is defined in Asterisk. Look in /etc/asterisk/sip-vicidial.conf:

[sip_carrier_trunk]
type=peer
host=sip.carrierhost.com
port=5060
username=your_account_id
secret=your_sip_password
fromuser=your_account_id
fromdomain=sip.carrierhost.com
insecure=port,invite
context=from-vicidial
disallow=all
allow=ulaw
allow=gsm
canreinvite=no
nat=yes
qualify=yes
qualifyfreq=60

Verify the peer is loaded in Asterisk:

asterisk -rx "sip show peers"

Look for your carrier trunk in the output. If it's not listed, reload the SIP config:

asterisk -rx "module reload res_sip" 
# or for old SIP stack
asterisk -rx "sip reload"

Link Campaign to Carrier

Ensure the campaign is mapped to an active carrier in the ViciDial web admin:

1. Log into /vicidial/admin.php
2. Navigate to Campaigns → select your campaign
3. In the Carrier Outbound section, select a carrier
4. Save

Or verify via database:

SELECT campaign_id, carrier_id 
FROM vicidial_campaigns 
WHERE campaign_id = 'TEST_CAMPAIGN';

If carrier_id is NULL or empty, update it:

UPDATE vicidial_campaigns 
SET carrier_id = 'SIP_CARRIER' 
WHERE campaign_id = 'TEST_CAMPAIGN';

Asterisk Dialplan and Extensions Configuration

Check extensions-vicidial.conf Syntax

ViciDial's dialplan must be syntactically correct. Check for errors:

asterisk -rx "dialplan show from-vicidial" | head -20

If you see errors, validate the configuration file:

asterisk -nf -c
# Then at the Asterisk console:
dialplan show from-vicidial
quit

Common issues in /etc/asterisk/extensions-vicidial.conf:

• Missing context definitions
• Malformed Dial() applications
• Incorrect priority numbering
• Unclosed brackets or quotes

Reload Dialplan

After any changes to /etc/asterisk/extensions-vicidial.conf, reload:

asterisk -rx "dialplan reload"

Verify the reload was successful:

asterisk -rx "core show uptime" | grep "Asterisk uptime"

Verify Outbound Dial Context

Check the dialplan for outbound calls. The typical pattern is:

asterisk -rx "dialplan show outbound-vicidial@from-vicidial"

Expected output should show extensions for your carriers. If empty or missing, check /etc/asterisk/extensions-vicidial.conf for the outbound context definition:

[outbound-vicidial]
exten => _X.,n,Dial(SIP/carrier_name/${EXTEN},45,tTwW)
exten => _X.,n,Hangup()

Agent Login and Session Issues

Verify Agents Are Logged In

VDAD only dials if agents are active in a campaign. Check the agent session table:

SELECT user, campaign_id, status, channel 
FROM vicidial_agent_log 
WHERE campaign_id = 'TEST_CAMPAIGN' 
  AND event_epoch > (UNIX_TIMESTAMP() - 300) 
ORDER BY event_epoch DESC;

Expected: You should see at least one agent with status = 'READY' or 'PAUSED'.

If no agents are logged in, log one in via /agc/vicidial.php (the agent screen).

Check Agent Campaign Assignment

The agent must be assigned to the campaign:

SELECT user, campaign_id, active 
FROM vicidial_users 
WHERE user = 'AGENT1';

Verify:

• campaign_id matches your test campaign
• active = 'Y'

If the agent isn't assigned to the campaign, add them in the admin panel or via SQL:

UPDATE vicidial_users 
SET campaign_id = 'TEST_CAMPAIGN', active = 'Y' 
WHERE user = 'AGENT1';

Check Agent Status in Real Time

Monitor the agent's Asterisk channel while they're logged in:

asterisk -rx "core show channels"

Look for a channel matching the agent's user ID. If no channel appears, the agent's SIP client connection is not active.

Memory and System Resource Constraints

Check System Memory and Load

AST_VDadapt and Asterisk are memory-intensive. If system resources are exhausted, dialing will stall:

free -m
top -b -n 1 | head -15

Look for:

• Memory: Free memory should be > 20% of total RAM
• Load average: Should be < 4x the number of CPU cores
• Swap usage: Should be minimal (< 10% of swap)

If memory is critically low:

systemctl stop vicidial-astguiclient
asterisk -rx "graceful shutdown"
sleep 30
# Clear caches
sync && echo 3 > /proc/sys/vm/drop_caches
# Restart
asterisk -r &
sleep 5
systemctl start vicidial-astguiclient

Monitor AST_VDadapt Memory Usage

Track VDadapt's memory consumption over time:

watch -n 5 'ps aux | grep -i vdadapt | grep -v grep'

If a single process exceeds 500MB, restart the daemon:

killall -9 AST_VDadapt.pl
sleep 2
/usr/share/astguiclient/AST_VDadapt.pl &

Database Connection Issues

Verify MySQL Connectivity from Asterisk User

The asterisk system user must be able to connect to the ViciDial MySQL database:

sudo -u asterisk mysql -h localhost -u asterisk -p'asterisk_db_password' asterisk -e "SELECT COUNT(*) FROM vicidial_list;"

If this fails with "access denied" or "connection refused", verify:

1. MySQL service is running:

   systemctl status mysql
   # or
   systemctl status mariadb
   

2. Asterisk user credentials in /etc/asterisk/asterisk.conf:

   [asterisk-db]
   dbhost = localhost
   dbname = asterisk
   dbuser = asterisk
   dbpass = asterisk_db_password
   

3. MySQL user grants:

   GRANT ALL ON asterisk.* TO 'asterisk'@'localhost' IDENTIFIED BY 'asterisk_db_password';
   FLUSH PRIVILEGES;
   

Check for Database Locks

Long-running queries or deadlocks can block AST_VDadapt. Check for blocked processes:

SHOW PROCESSLIST;

Look for queries with long Time values or State = 'Locked'. Kill problematic queries:

KILL QUERY 12345;  -- Replace 12345 with the process ID

Verify vicidial_log Permissions

The asterisk user must have write access to log tables. Test an insert:

sudo -u asterisk mysql -h localhost -u asterisk -p'asterisk_db_password' asterisk -e \
"INSERT INTO vicidial_log (user, campaign_id, phone_number, call_date, call_time_start) 
 VALUES ('test', 'TEST_CAMPAIGN', '5551234567', NOW(), '00:00:00');"

If the insert fails, rebuild table permissions:

GRANT INSERT, UPDATE, SELECT ON asterisk.vicidial_log TO 'asterisk'@'localhost';
GRANT INSERT, UPDATE, SELECT ON asterisk.vicidial_list TO 'asterisk'@'localhost';
GRANT INSERT, UPDATE, SELECT ON asterisk.vicidial_campaigns TO 'asterisk'@'localhost';
FLUSH PRIVILEGES;

Real-World Configuration Example

Here's a complete, working configuration for a test campaign:

Campaign Setup

-- Create a test campaign
INSERT INTO vicidial_campaigns 
(campaign_id, campaign_name, active, dial_method, agents_logged_in, 
 rate_frame, calls_queued, carrier_id, max_leads_for_24hrs)
VALUES 
('TEST_CAMPAIGN', 'Test Campaign', 'Y', 'ADAPT', 0, 
 60, 10, 'SIP_CARRIER', 100);

-- Assign a user to the campaign
UPDATE vicidial_users 
SET campaign_id = 'TEST_CAMPAIGN', active = 'Y' 
WHERE user = 'test_agent';

-- Insert test leads
INSERT INTO vicidial_list 
(campaign_id, phone_number, status, gmt_offset_now, entry_date)
VALUES 
('TEST_CAMPAIGN', '5551234567', 'NEW', '-5', NOW()),
('TEST_CAMPAIGN', '5559876543', 'NEW', '-5', NOW()),
('TEST_CAMPAIGN', '5552468135', 'NEW', '-5', NOW());

Asterisk SIP Peer Configuration

; /etc/asterisk/sip-vicidial.conf

[SIP_CARRIER]
type=peer
host=sip.provider.com
port=5060
username=myaccount
secret=mypassword
fromuser=myaccount
fromdomain=sip.provider.com
insecure=port,invite
context=from-vicidial
disallow=all
allow=ulaw
allow=gsm
canreinvite=no
nat=yes
qualify=yes
qualifyfreq=60
maxcallbitrate=384

Dialplan Extension

; /etc/asterisk/extensions-vicidial.conf

[outbound-vicidial]
exten => _1[2-9]XX[2-9]XXXXXX,1,Dial(SIP/SIP_CARRIER/${EXTEN},45,tTwW)
exten => _1[2-9]XX[2-9]XXXXXX,n,Hangup()

exten => _[2-9]XX[2-9]XXXXXX,1,Dial(SIP/SIP_CARRIER/1${EXTEN},45,tTwW)
exten => _[2-9]XX[2-9]XXXXXX,n,Hangup()

Troubleshooting

Symptom: AST_VDadapt Process Crashes Repeatedly

Cause: Database connection loss, memory leak, or segmentation fault.

Solution:

1. Check Asterisk logs for core dumps:

   dmesg | tail -20
   ls -lh /tmp/core*
   

2. Monitor AST_VDadapt startup:

   # Kill any existing processes
   killall -9 AST_VDadapt.pl
   sleep 2
   
   # Run in foreground with verbose output
   /usr/share/astguiclient/AST_VDadapt.pl --debug 2>&1 | tee /tmp/vdadapt_debug.log
   

3. Watch for errors in the output. Common crashes:

   • DBI->connect failed — MySQL unavailable
   • Can't locate Asterisk/AGI.pm — Missing Perl module
   • Segmentation fault — Corrupt Asterisk installation

4. Rebuild Perl modules if needed:

   cd /usr/src/asterisk-version/
   make menuselect
   # Select extra modules if needed
   make install
   

Symptom: Calls Dial but Hang Up Immediately

Cause: Incorrect carrier settings, NAT issues, or codec mismatch.

Solution:

1. Monitor the actual SIP traffic:

   asterisk -rx "sip set debug on"
   # Attempt a call
   # Watch the output for SIP errors
   asterisk -rx "sip set debug off"
   

2. Check the carrier's SIP authentication:

   asterisk -rx "sip show peers" | grep SIP_CARRIER
   

   Look for UNREACHABLE status. If so, verify host/port/auth in the config.

3. Test carrier connectivity:

   # Direct SIP REGISTER test
   sipsak -U -C sip:[email protected] -l 0 -s sip:sip.provider.com
   

4. Force codec to ULAW (most compatible):

   [SIP_CARRIER]
   disallow=all
   allow=ulaw
   

Symptom: Leads in vicidial_list but VDAD Reports "No Leads Available"

Cause: Lead status filtering, date/time constraints, or VDAD logic blocking.

Solution:

1. Check lead statuses directly:

   SELECT status, COUNT(*) 
   FROM vicidial_list 
   WHERE campaign_id = 'TEST_CAMPAIGN' 
   GROUP BY status;
   

   VDAD typically dials only NEW, CALLBACK, or RECALL statuses. Verify your campaign calls the right statuses.

2. Check for timezone/callback time constraints:

   SELECT phone_number, status, entry_date, callback_date, callback_time 
   FROM vicidial_list 
   WHERE campaign_id = 'TEST_CAMPAIGN' 
     AND status = 'CALLBACK' 
     AND callback_date IS NOT NULL;
   

   If callback times are in the future, they won't dial until that time arrives.

3. Reset stuck leads to NEW:

   UPDATE vicidial_list 
   SET status = 'NEW' 
   WHERE campaign_id = 'TEST_CAMPAIGN' 
     AND status IN ('DNCL', 'XDEL');
   

Symptom: "ERROR: No Carrier Available" in VDAD Logs

Cause: Campaign not linked to carrier, or carrier is inactive/offline.

Solution:

1. Verify carrier assignment:

   SELECT carrier_id FROM vicidial_campaigns 
   WHERE campaign_id = 'TEST_CAMPAIGN';
   

2. Verify carrier is active:

   SELECT carrier_id, active FROM vicidial_carrier_log 
   WHERE carrier_id = 'SIP_CARRIER';
   

3. Test Asterisk can reach the carrier:

   asterisk -rx "sip show peers" | grep -i carrier
   

   Look for OK status, not UNREACHABLE.

4. Force a manual dial test via Asterisk console:

   asterisk -r
   channel originate SIP/SIP_CARRIER/5551234567 application wait 10
   

   If this fails, the carrier is not configured correctly in Asterisk.

Symptom: High CPU Usage by AST_VDadapt, Dialing Is Slow

Cause: Inefficient database queries, large lead lists, or CPU contention.

Solution:

1. Profile the AST_VDadapt process:

   strace -c -p $(pgrep AST_VDadapt | head -1) 2>&1 | head -30
   

2. Identify slow database queries:

   -- Enable slow query log
   SET GLOBAL slow_query_log = 'ON';
   SET GLOBAL long_query_time = 2;
   -- Then check
   TAIL /var/log/mysql/slow.log
   

3. Add indexes to improve query performance:

   CREATE INDEX idx_campaign_status ON vicidial_list (campaign_id, status);
   CREATE INDEX idx_dnc_phone ON vicidial_dnc_list (phone_number);
   

4. Limit the number of AST_VDadapt processes:

   ps aux | grep AST_VDadapt | grep -v grep | wc -l
   

   More than 3-4 processes may indicate runaway spawning. Restart:

   killall -9 AST_VDadapt.pl
   sleep 2
   /usr/share/astguiclient/AST_VDadapt.pl &
   

Summary

ViciDial VDAD not dialing is typically caused by one of these categories:

1. Process Issues: AST_VDadapt not running, crashing, or unable to connect to MySQL
2. Database Configuration: Missing leads, inactive campaigns, or agent login failures
3. Carrier/Trunk Issues: Missing or inactive SIP/IAX carrier, incorrect authentication, unreachable host
4. Dialplan Issues: Malformed extensions, missing contexts, or syntax errors
5. System Resources: Insufficient memory, high CPU load, or disk I/O bottlenecks

Quick Troubleshooting Checklist:

• ✅ Is AST_VDadapt process running? ps aux | grep AST_VDadapt
• ✅ Is the campaign active? SELECT active FROM vicidial_campaigns WHERE campaign_id = ?
• ✅ Are there leads to dial? SELECT COUNT(*) FROM vicidial_list WHERE campaign_id = ? AND status = 'NEW'
• ✅ Is an agent logged in? SELECT user FROM vicidial_agent_log WHERE campaign_id = ?
• ✅ Is the carrier configured and online? asterisk -rx "sip show peers"
• ✅ Does the dialplan load without errors? asterisk -rx "dialplan reload"
• ✅ Can MySQL be reached? mysql -u asterisk -p asterisk -e "SELECT 1"

Follow the sections above in order, test each component, and you'll identify the root cause. Most production VDAD failures are resolved within 15 minutes once you narrow down which subsystem is failing.