Learn to diagnose, fix, and prevent DROP status calls in ViciDial; understand the technical causes, check configurations, validate SIP/IAX2 connectivity, and implement compliance-safe solutions that maintain call quality and regulatory standards.
Prerequisites
Before diving into this guide, ensure you have:
- ViciDial 2.14+ installed (preferably 2.14.1 or later for stability fixes)
- Asterisk 11+ or 13+ (Asterisk 16+ recommended for production)
- Root or sudo access to your ViciDial server(s)
- Database access (MySQL/MariaDB) with credentials for the
asteriskdatabase - Basic knowledge of Asterisk, SIP protocol, and Linux command line
- SSH access to your dialer and call server(s)
- Asterisk CLI experience (comfortable running
asterisk -rxcommands) - Access to ViciDial web admin interface (
/vicidial/admin.php) - Log file access (
/var/log/asterisk/messages,/var/log/asterisk/full)
Understanding DROP Status in ViciDial
What is DROP Status?
In ViciDial, a call logged with DROP status means the call was initiated and answered by the system, but was terminated before it reached an available agent or the call was dropped during transfer/connection. The call leg was established at some point in the call path, then disconnected abnormally.
DROP differs from other statuses:
- NO ANS = Called party didn't answer within the timeout period
- BUSY = Called party returned busy signal
- DROP = Call was answered/connected but terminated unexpectedly
- HANGUP = Agent or system deliberately ended the call
Where DROP Calls Are Logged
ViciDial records call outcomes in multiple locations:
-- Primary table for inbound/outbound call logs
SELECT * FROM vicidial_log
WHERE status = 'DROP'
AND call_date >= DATE_SUB(NOW(), INTERVAL 1 DAY)
LIMIT 50;
-- Agent-specific call dispositions
SELECT * FROM vicidial_closer_log
WHERE call_status = 'DROP'
AND call_date >= DATE_SUB(NOW(), INTERVAL 1 DAY);
-- For carrier/trunk issues
SELECT * FROM vicidial_carrier_log
WHERE status = 'DROP';
Root Causes of DROP Status Calls
1. SIP Trunk/Provider Issues (Most Common)
Symptom: Calls drop shortly after being answered or routed.
Causes:
- Carrier terminating calls due to authentication failures
- SIP ALG (Application Layer Gateway) issues on NAT/firewall
- Codec mismatch between ViciDial and provider
- Missing or incorrect SIP credentials
- Trunk quality or congestion at provider's end
- One-way audio leading to system drop
Check carrier logs:
# Monitor SIP traffic to/from your carrier trunk
sudo asterisk -rx "sip show peers"
# Watch live SIP messages
sudo tcpdump -i any -n -s 0 'tcp port 5060 or udp port 5060' -w /tmp/sip_capture.pcap
# Analyze the capture
sudo wireshark /tmp/sip_capture.pcap
Typical configuration issue:
; File: /etc/asterisk/sip-vicidial.conf
; WRONG: Missing or incomplete trunk definition
[carrier_trunk]
type=peer
host=sip.provider.com
username=your_account_id
secret=your_password
; Missing: insecure setting, nat, or port
; CORRECT:
[carrier_trunk]
type=peer
host=sip.provider.com
port=5060
username=your_account_id
secret=your_password
insecure=port,invite
nat=yes
context=from-carrier
disallow=all
allow=ulaw
allow=alaw
dtmfmode=rfc2833
2. Asterisk Kernel Module Issues
Symptom: Calls drop randomly across all trunks equally.
Check dahdi or timing module:
# Check for kernel timing module
lsmod | grep dahdi
lsmod | grep ztdummy
# If missing and needed:
sudo modprobe ztdummy
sudo /etc/init.d/asterisk restart
# Check for kernel panics or messages
sudo dmesg | tail -50
3. Memory or CPU Exhaustion
Symptom: Drops increase during peak hours; gradual performance degradation.
Monitor system resources:
# Real-time system load
top -b -n 1 | head -20
# Check free memory
free -h
# Check Asterisk process memory usage
ps aux | grep asterisk | grep -v grep
# Long-term monitoring
vmstat 2 10
# Disk I/O (can impact logging, thus call handling)
iostat -x 1 5
If memory is low:
# Increase swap if needed (temporary measure)
sudo dd if=/dev/zero of=/swapfile bs=1G count=4
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# Better: Restart Asterisk during off-peak
sudo service asterisk restart
4. Database Connection Issues
Symptom: Calls are answered but dropped when agent disposition is attempted; logs show partial entries.
Check database connectivity:
# Test MySQL connection
mysql -u asterisk -p$ASTDBPASS asterisk -e "SELECT COUNT(*) FROM vicidial_log WHERE call_date >= DATE_SUB(NOW(), INTERVAL 1 HOUR);"
# Check for locked tables
mysql -u asterisk -p$ASTDBPASS asterisk -e "SHOW OPEN TABLES WHERE in_use > 0;"
# Verify database credentials in ViciDial config
cat /etc/vicidial/vicidial.conf | grep -i mysql
Database configuration fix:
# File: /etc/asterisk/res_mysql.conf
[asterisk]
dbhost=localhost
dbname=asterisk
dbuser=asterisk
dbpass=YourStrongPassword
dbport=3306
dbsock=/var/run/mysqld/mysqld.sock
5. Call Queue/Agent Not Available
Symptom: Calls are routed but agent queue is full; calls dropped instead of queued.
Check ViciDial campaign settings:
# Web admin path: /vicidial/admin.php
# Navigate to: Campaigns > [Your Campaign] > Edit Campaign
# Check:
# - Agent dial timeout (should be 30-45 seconds)
# - Max channels allowed per agent
# - Queue settings (should allow queuing)
Or via MySQL:
SELECT campaign_id, campaign_name, dial_timeout, agent_max_calls
FROM vicidial_campaigns
WHERE campaign_id = 'YOUR_CAMPAIGN_ID';
-- If dial_timeout is too short, increase it:
UPDATE vicidial_campaigns
SET dial_timeout = 45
WHERE campaign_id = 'YOUR_CAMPAIGN_ID';
6. Firewall/NAT Dropping Idle Connections
Symptom: Calls drop after ~30 seconds consistently; happens across different carriers.
Cause: Stateful firewall or NAT timing out connections.
Fix:
; File: /etc/asterisk/sip-vicidial.conf
[general]
; Reduce SIP keepalive interval (default 60 seconds)
keepalive=20
; For REGISTER-based authentication:
; Enable OPTIONS keepalives
session-timers=accept
session-timers-mode=uas
Check firewall rules:
# List current iptables rules for SIP/RTP
sudo iptables -L -n -v | grep -E '5060|5061|10000'
# Typical needed rules:
sudo iptables -A INPUT -p udp --dport 5060 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 5060:5090 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT
7. RTP/Audio Stream Issues
Symptom: Calls connect but audio stops; call hangs briefly then drops.
Verify RTP port range:
; File: /etc/asterisk/rtp.conf
[general]
rtpstart=10000
rtpend=20000
rtpsecure=no
; For NAT environments:
; /etc/asterisk/sip-vicidial.conf
[general]
externip=YOUR_PUBLIC_IP
localnet=YOUR_PRIVATE_NET/24
Test RTP connectivity:
# Capture RTP packets to verify they're flowing
tcpdump -i any 'udp portrange 10000-20000' -c 100 -w /tmp/rtp.pcap
# Check for packet loss
wireshark /tmp/rtp.pcap
# Monitor during a test call
asterisk -rx "core set verbose 3"
# Make a test call and observe console for RTP debug output
Diagnostic Commands & Log Analysis
Check Recent DROP Calls
# SSH into your ViciDial server and run:
mysql -u asterisk -p$ASTDBPASS asterisk << 'EOF'
SELECT
call_id,
callerid,
phone_number,
call_date,
call_duration,
status,
agent_log_id
FROM vicidial_log
WHERE status = 'DROP'
AND call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY call_date DESC
LIMIT 100;
EOF
Parse Asterisk Full Logs
# Search for SIP/IAX2 errors related to drops
sudo grep -i "sip.*drop\|drop.*sip\|hangup\|connection" /var/log/asterisk/full | tail -100
# Find specific call IDs
sudo grep "CALL_ID_HERE" /var/log/asterisk/full | head -50
# Count drops by hour
sudo grep "status = 'DROP'" /var/log/asterisk/messages | awk -F'[: ]' '{print $1":"$2}' | sort | uniq -c
Enable Verbose Logging (Temporary Diagnostic)
# SSH into Asterisk CLI
sudo asterisk -r
# In Asterisk CLI:
core set verbose 3
core set debug 3
sip set debug peer carrier_trunk_name
# Make a test call, observe output
# Disable after diagnostics:
core set verbose 0
core set debug 0
# Exit CLI:
exit
Check Asterisk Uptime and Restart History
# Current uptime
sudo asterisk -rx "core show uptime"
# Check syslog for Asterisk restarts
sudo grep -i "asterisk.*start\|asterisk.*restart" /var/log/syslog | tail -20
Configuration Fixes for Common DROP Issues
Fix 1: Enable SIP Reinvite and Proper Media Handling
; File: /etc/asterisk/sip-vicidial.conf
[general]
; Allow direct media when possible (reduces latency, fewer drops)
directmedia=yes
directrtpsetup=yes
; But disable for problematic carriers:
; directmedia=no
; Proper codec settings
disallow=all
allow=ulaw
allow=alaw
allow=h264
; Session timers (RFC 4028) to detect broken connections
session-timers=accept
session-timers-mode=originate
Fix 2: Increase Timeouts and Retries
; File: /etc/asterisk/sip-vicidial.conf
[general]
; Increase SIP timeout for slow networks
siptimer=100
; Retry failed INVITES
retrans=1000
maxretrans=5
; Per-trunk settings:
[carrier_trunk]
host=sip.provider.com
username=your_id
secret=your_secret
; Increase timeout for this specific trunk if it's slow
rtptimeout=60
rtpholdtimeout=300
Fix 3: Fix NAT and Firewall Issues
; File: /etc/asterisk/sip-vicidial.conf
[general]
; Required for NAT environments
nat=yes
externip=YOUR_PUBLIC_IP
localnet=10.0.0.0/8
; Enable ICE for better NAT traversal
icesupport=yes
Fix 4: Database Connection Pooling
# File: /etc/asterisk/res_odbc.conf
[asterisk]
driver=mysql
server=localhost
user=asterisk
password=your_password
database=asterisk
poolsize=10
max_connections=20
Fix 5: Asterisk Memory and Thread Limits
# File: /etc/default/asterisk (or /etc/asterisk/asterisk.conf)
# Ensure adequate file descriptors
ulimit -n 8192
# In /etc/asterisk/asterisk.conf:
[options]
threadpool=yes
maxcallbitrate=384
Compliance Considerations When Fixing DROP Calls
FCC/TCPA Regulations (US)
Key requirements when debugging DROP calls:
- Do NOT artificially retry dropped calls without user consent
- Do NOT exceed call frequency limits (TCPA: no more than reasonable frequency per consumer)
- Maintain LIDB accuracy (Line Information Database) — ensure dropped calls are not re-queued under false pretenses
- Honor Do-Not-Call — if a call drops, verify the number isn't on DNC list before redialing
ViciDial compliance checks:
-- Ensure drop calls aren't auto-retried without proper hooks
SELECT COUNT(*) FROM vicidial_log
WHERE status = 'DROP'
AND retry_flag = 1
AND call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR);
-- Verify DNC compliance
SELECT COUNT(*) FROM vicidial_log vl
WHERE vl.status = 'DROP'
AND EXISTS (
SELECT 1 FROM vicidial_dnc_phone_number dpn
WHERE dpn.phone_number = vl.phone_number
)
AND vl.call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR);
GDPR/CCPA Privacy
- Log retention: Don't keep DROP call recordings longer than necessary
- Audio files: Ensure dropped calls don't leave audio artifacts in
/var/spool/asterisk/ - PII handling: Mask phone numbers in logs if required by local law
# Clean up old call recordings
find /var/spool/asterisk/monitor -name "*.wav" -type f -mtime +30 -delete
# Check for orphaned recordings from dropped calls
find /var/spool/asterisk -type f -name "*.wav" -newer /var/log/asterisk/messages.1 | wc -l
HIPAA (Healthcare)
If you're a covered entity:
- Encrypt recordings of dropped calls (even if partial)
- Audit access logs to dropped call recordings
- Secure disposal — don't just delete; overwrite sectors
# Securely wipe dropped call recordings
sudo shred -vfz -n 3 /path/to/old/recordings/*.wav
Performance Optimization to Reduce DROPs
1. Optimize MySQL for High Call Volume
# File: /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
; Increase max connections
max_connections=500
; Improve query speed
query_cache_type=1
query_cache_size=64M
query_cache_limit=2M
; Better innodb performance
innodb_buffer_pool_size=4G
innodb_log_file_size=512M
; Avoid timeouts on long queries
wait_timeout=28800
interactive_timeout=28800
Restart MySQL:
sudo service mysql restart
2. Tune Asterisk Channels and Threads
; File: /etc/asterisk/asterisk.conf
[options]
; Allow more concurrent channels
maxchannels=5000
; Thread pool for better concurrency
threadpool=yes
; Increase file descriptor limit
maxfd=8192
; Higher priority for Asterisk process
priority=high
3. RTP Buffer and Audio Tuning
; File: /etc/asterisk/res_rtp_asterisk.conf
[general]
; Adaptive jitter buffer (reduces dropped audio)
jbenable=yes
jbforce=yes
jbmaxsize=200
jbresyncthreshold=1000
4. Monitor Channel/Call Metrics
# Check active channels
sudo asterisk -rx "core show channels"
# Check SIP peers' state
sudo asterisk -rx "sip show peers"
# Detailed diagnostics:
sudo asterisk -rx "core show channels verbose" | grep -i drop
Troubleshooting Section
DROP Rate Suddenly Increased
Step 1: Check for recent changes
# Review recent ViciDial config changes
ls -lt /etc/asterisk/*.conf | head -5
ls -lt /etc/vicidial/*.conf | head -5
# Check Asterisk version/restart history
sudo grep -i "asterisk.*loaded\|asterisk.*start" /var/log/syslog | tail -10
Step 2: Verify trunk/carrier status
# Check carrier trunk registration status
sudo asterisk -rx "sip show registry"
# Verify carrier is responding
sudo asterisk -rx "sip show peers" | grep -i carrier
# Test connectivity to carrier
mtr -c 10 sip.carrier.com
Step 3: Check ViciDial logs
# Look for errors in ViciDial logs
tail -100 /var/log/asterisk/messages | grep -i "error\|fail\|drop"
# Check vicidial_log directly for DROP spike
mysql -u asterisk -p$ASTDBPASS asterisk -e "
SELECT DATE(call_date) as date, HOUR(call_date) as hour, COUNT(*) as drops
FROM vicidial_log
WHERE status = 'DROP'
AND call_date >= DATE_SUB(NOW(), INTERVAL 48 HOUR)
GROUP BY DATE(call_date), HOUR(call_date)
ORDER BY call_date DESC;
"
DROP Calls from Specific Carrier Only
Step 1: Isolate the issue to carrier trunk
# Filter drops by trunk
mysql -u asterisk -p$ASTDBPASS asterisk -e "
SELECT carrier_id, COUNT(*) as drop_count
FROM vicidial_log
WHERE status = 'DROP' AND call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY carrier_id
ORDER BY drop_count DESC;
"
Step 2: Test carrier trunk independently
# Dial test number through specific trunk
sudo asterisk -rx "channel originate Local/9991234567@from-internal application Wait 10"
# Monitor SIP messages for that carrier only
tcpdump -i any 'host CARRIER_IP and port 5060' -w /tmp/carrier_test.pcap
Step 3: Contact carrier and provide evidence
- Provide dropped call IDs and timestamps
- Share SIP capture for failed calls
- Ask carrier to check their logs for
CANCELorBYEmessages
DROP with "One-Way Audio"
Symptom: Call connects, agent can hear caller, caller hears nothing.
# Check RTP routing in your infrastructure
sudo iptables -L -n | grep -i rtp
# Verify no asymmetric routing:
mtr -c 5 CALLER_CARRIER_IP
mtr -c 5 CALLER_INBOUND_IP
# Capture RTP to inspect quality
tcpdump -i any 'udp portrange 10000-20000' -A -c 50
Common fix: Disable directmedia for problematic routes
; /etc/asterisk/sip-vicidial.conf
[specific_carrier_with_rtp_issues]
type=peer
host=sip.problematic-carrier.com
; ...other config...
directmedia=no ; Force all audio through Asterisk
directrtpsetup=no
DROP with "Resource Unavailable" Error
In Asterisk CLI logs, you'll see error codes like 488 or 480.
Root cause usually:
- No available agent in campaign
- Agent busy or offline
- Campaign max channels exceeded
Fix:
-- Increase max channels in campaign
UPDATE vicidial_campaigns
SET max_calls_queue = 100,
dial_timeout = 45
WHERE campaign_id = 'YOUR_CAMPAIGN';
-- Verify agents are in proper state
SELECT user_id, status, calls_today
FROM vicidial_users
WHERE user_group = 'YOUR_GROUP'
AND user_id NOT IN ('ADMIN','DEBUG')
ORDER BY calls_today DESC;
DROP Calls with Partial Recording
Symptom: Call recording exists but only captures partial audio; call dropped mid-call.
# List partial recordings
find /var/spool/asterisk/monitor -name "*.wav" -type f -size -50k -mtime -1
# Check if Asterisk ran out of disk space
df -h /var/spool/asterisk/
# If disk full, archive old recordings
tar -czf /backup/recordings_archive_$(date +%Y%m%d).tar.gz /var/spool/asterisk/monitor/*.wav
rm /var/spool/asterisk/monitor/*.wav
# Increase monitoring partition if frequently full
# (Usually requires partition resizing — contact your hosting provider)
Monitoring and Alerting for Future DROP Issues
Create a DROP Monitoring Script
#!/bin/bash
# File: /usr/local/bin/monitor_drop_calls.sh
# Runs every 5 minutes; alerts if DROP rate exceeds threshold
THRESHOLD=5 # Alert if more than 5 drops per 5-min interval
DB_USER="asterisk"
DB_PASS="$ASTDBPASS"
DB_HOST="localhost"
DB_NAME="asterisk"
RECENT_DROPS=$(mysql -u $DB_USER -p$DB_PASS -h $DB_HOST $DB_NAME -se "
SELECT COUNT(*) FROM vicidial_log
WHERE status = 'DROP'
AND call_date >= DATE_SUB(NOW(), INTERVAL 5 MINUTE);
")
if [ "$RECENT_DROPS" -gt "$THRESHOLD" ]; then
echo "ALERT: $RECENT_DROPS DROP calls in last 5 minutes" | \
mail -s "ViciDial DROP Alert" [email protected]
# Optional: Log to syslog
logger -t vicidial_monitor "DROP call count: $RECENT_DROPS"
fi
Add to crontab:
*/5 * * * * /usr/local/bin/monitor_drop_calls.sh
Dashboard Query for Real-Time Monitoring
-- Run in phpMyAdmin or MySQL client to see real-time DROP metrics
SELECT
DATE_FORMAT(call_date, '%Y-%m-%d %H:00') as hour,
COUNT(*) as total_calls,
SUM(IF(status='DROP', 1, 0)) as drops,
ROUND(100.0 * SUM(IF(status='DROP', 1, 0)) / COUNT(*), 2) as drop_rate,
SUM(IF(status='ANSWER', 1, 0)) as answered,
SUM(IF(status='NO ANS', 1, 0)) as no_answer
FROM vicidial_log
WHERE call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY DATE_FORMAT(call_date, '%Y-%m-%d %H:00')
ORDER BY call_date DESC;
Summary
ViciDial DROP status calls indicate calls that were initiated but terminated abnormally before successful completion. The causes range from simple SIP trunk misconfiguration to complex infrastructure issues like memory exhaustion or firewall timeouts.
Key Takeaways:
Diagnosis First — Always check Asterisk logs, SIP peer status, and carrier registration before assuming misconfiguration.
Common Culprits (in order of likelihood):
- SIP trunk credentials or codec mismatch
- NAT/firewall dropping connections after ~30 seconds
- Database connection issues under load
- Insufficient system resources (memory, CPU)
- Carrier-side issues (authentication, quality)
Configuration Fixes:
- Enable proper SIP settings:
session-timers,keepalive,directmedia - Set realistic timeouts:
rtptimeout=60,siptimer=100 - Configure NAT correctly:
externip,localnet,nat=yes
- Enable proper SIP settings:
Compliance Matters:
- Don't auto-retry DROP calls without consent (FCC/TCPA)
- Secure dropped call recordings (HIPAA)
- Honor Do-Not-Call lists even for retries
- Maintain audit logs of changes
Production Best Practices:
- Monitor DROP rate continuously; alert on thresholds
- Optimize MySQL for concurrent connections
- Maintain adequate disk space for recordings
- Document all changes and test in staging first
- Keep Asterisk and ViciDial updated to latest stable versions
When to Escalate:
- If DROP rate exceeds 2-5% of total call volume
- If issue is isolated to a single carrier (likely their problem)
- If system resources are maxed (upgrade hardware)
- If you suspect database corruption (run
CHECK TABLEon vicidial_log)
By systematically working through the diagnostic steps and configuration fixes outlined in this guide, you'll resolve the vast majority of DROP call issues and maintain a stable, compliant ViciDial deployment.