Why Calls Are Dropping in VICIdial and How to Fix It

Understanding Call Drops in VICIdial

A dropped call in VICIdial can mean different things depending on who experiences it. The customer hears silence and hangs up. The agent sees the call disappear from their screen mid-conversation. The dialer logs a DISCONNECT or DEAD status without a clear reason. Each scenario points to a different root cause, and misdiagnosing the problem leads to wasted hours tweaking the wrong settings.

Call drops sit at the intersection of your VICIdial application, Asterisk PBX, SIP carriers, network infrastructure, and agent workstations. A stable vicidial setup addresses each layer, but drops often appear after scaling — more agents, higher dial levels, or a new carrier — when a previously invisible bottleneck surfaces.

This guide provides a systematic troubleshooting approach. Work through the categories in order: server health, SIP configuration, carrier issues, network, and dialer settings. Most drop problems fall into one or two categories and can be resolved without rebuilding your entire deployment.

Server Health and Resource Exhaustion

VICIdial runs on Asterisk, which is CPU and I/O intensive during high-volume dialing. When your vicidial server runs out of resources, calls fail silently or drop mid-conversation. This is the first thing to check because it affects all campaigns and agents simultaneously.

CPU and Memory Pressure

Monitor CPU usage during peak dialing hours. Sustained CPU above 80% causes Asterisk to drop channels. Each active call consumes CPU for codec transcoding, recording, and RTP processing. A server sized for 20 agents will drop calls when you scale to 40 without upgrading hardware.

• Run top or htop during peak hours — look for asterisk and mysqld processes consuming excessive CPU
• Check RAM usage — insufficient memory causes swapping, which introduces audio delay and dropped channels
• Review disk I/O — call recording to a slow disk can block Asterisk channel operations
• Verify no runaway cron jobs or log rotation scripts compete for resources during business hours
• Check MySQL slow query log — database bottlenecks delay hopper updates and call processing

Asterisk Channel Limits

Asterisk has a maximum concurrent channel limit defined in asterisk.conf (maxcalls or maxload). If your dial level generates more simultaneous channels than the limit, excess calls are rejected or dropped. Calculate your peak channel count: agents × dial level × average ring time factor. A 30-agent campaign at dial level 3.0 can generate 90+ concurrent outbound channels before any inbound or transfer traffic.

If you use managed vicidial hosting, your provider should monitor these metrics proactively. Self-hosted deployments need manual monitoring via tools like Nagios, Zabbix, or VICIdial's built-in server performance screen.

SIP Timer and Protocol Configuration

SIP session timers and RTP timeouts are among the most common causes of calls dropping at predictable intervals — typically 15, 30, or 60 seconds into a conversation. These drops happen because one side of the call sends a SIP re-INVITE or session timer refresh that the other side does not acknowledge.

SIP Session Timers

Many SIP carriers enable session timers (RFC 4028) with a minimum session interval of 1800 seconds or less. If Asterisk and the carrier disagree on session timer handling, the call drops when the timer expires. Check your carrier trunk settings in Admin → Carriers and the corresponding sip.conf or PJSIP endpoint configuration.

• In sip.conf or pjsip.conf, set session-timers=refuse or session-expires and min-se appropriately
• Match the carrier's session timer requirements — some carriers require session-timers=originate
• Test with a single carrier trunk before applying changes globally
• After changes, restart Asterisk and test a 5-minute call to verify the drop is resolved

RTP Timeout Settings

Asterisk monitors RTP (audio) packets and hangs up if no media flows for rtptimeout seconds (default 60). If NAT or firewall issues interrupt RTP flow, the call drops even though both parties are still talking. Increase rtptimeout and rtpholdtimeout in asterisk.conf cautiously — higher values delay detection of genuinely dead calls.

Detailed SIP carrier configuration is covered in our SIP carrier setup guide. Carrier-specific timer requirements vary significantly between providers.

SIP Carrier and Trunk Problems

Your SIP carrier is the bridge between VICIdial and the PSTN. Carrier-side issues cause drops that look like VICIdial problems but originate upstream.

Concurrent Channel Limits

Every SIP trunk has a maximum concurrent call capacity. When your dialer exceeds this limit, the carrier rejects new calls or drops existing ones. Check your carrier portal for current usage versus your plan limit. If you regularly hit 80%+ capacity, upgrade your trunk or add a second carrier for overflow.

Carrier-Side Timeouts

Some carriers enforce maximum call duration limits (e.g., 2 or 4 hours) or silence timeouts that disconnect calls with no audio activity. Long hold times during call transfers can trigger carrier silence detection. Work with your carrier to understand their timeout policies and adjust hold music or comfort noise settings.

Codec Mismatch and Transcoding

If VICIdial negotiates ulaw but the carrier sends alaw (or vice versa), Asterisk must transcode, adding CPU load and potential audio issues. Standardize on ulaw for US calling and ensure both your carrier trunks and agent phones use the same codec. Disable unused codecs in sip.conf to prevent unintended negotiation.

Network and NAT Configuration

Network problems cause drops that are intermittent and hard to reproduce — the worst kind for troubleshooting. Focus on the path between your vicidial server, your SIP carrier, and your agent phones.

NAT and Firewall Settings

VICIdial servers behind NAT must have correct externip and localnet settings in sip.conf or rtp.conf. Incorrect NAT configuration causes one-way audio (see our one-way audio fix guide) and can also cause calls to drop when RTP pinholes close. Ensure UDP ports 10000–20000 (RTP) and 5060 (SIP) are open on your firewall.

Packet Loss and Jitter

VoIP requires consistent, low-latency network delivery. Packet loss above 1% or jitter above 30ms causes audio breakup that leads to hang-ups. Run mtr or ping tests from your vicidial server to your carrier's SIP gateway. Test agent connections too — remote agents on poor home internet connections experience drops that appear to be server-side.

• Use wired Ethernet for agents whenever possible — Wi-Fi introduces jitter and packet loss
• Configure QoS on your router to prioritize SIP and RTP traffic
• Remote agents should use a VPN with adequate bandwidth (minimum 1 Mbps per agent for G.711)
• Monitor asterisk -rx 'rtp show stats' for packet loss on active channels

VICIdial Dialer Settings That Cause Drops

Application-level settings in VICIdial can cause calls to drop or fail to connect properly. These are often overlooked because the server and carrier appear healthy.

Aggressive Dial Levels

Running dial levels too high for your agent count generates excessive outbound channels. When a live answer occurs, Asterisk must bridge the customer to an agent instantly. If no agent is available, the call is abandoned — the customer experiences a drop. Lower your dial level until abandonment rate stays below 3%.

Hopper and Dial Timeout Settings

The campaign dial timeout (default 60 seconds) controls how long the dialer rings before giving up. If set too short, calls drop before the customer answers. If set too long, channels are tied up on unanswered rings, reducing capacity. The dial timeout in VICIdial should match your carrier's ring timeout to avoid orphaned channels.

Answering Machine Detection

AMD analyzes the first few seconds of audio to detect voicemail. False positives — hanging up on a live person because AMD thinks it is a machine — feel like dropped calls to the customer. If agents report drops in the first 3–5 seconds of answered calls, review AMD sensitivity settings in the campaign configuration. Consider disabling AMD for high-value campaigns.

Step-by-Step Diagnostic Procedure

1. Identify the pattern: Do drops happen at a fixed time interval (SIP timers), randomly (network/carrier), or only during peak hours (server overload)?
2. Check Asterisk logs: grep for HANGUP, WARNING, and ERROR in /var/log/asterisk/full during a drop event
3. Review VICIdial carrier logs: Admin → Carrier Log Report for SIP response codes (408 Timeout, 487 Request Terminated, 503 Service Unavailable)
4. Test a single call: Place a manual dial from an agent extension and stay on for 10 minutes — if it drops, the issue is server/carrier, not dialer logic
5. Isolate the carrier: Test each carrier trunk individually by disabling others temporarily
6. Monitor server resources: Run vmstat 1 during peak dialing and correlate CPU spikes with drop events
7. Check agent-side issues: If only remote agents experience drops, test their network path with a SIP softphone outside VICIdial
8. Review recent changes: New carrier, dial level increase, server migration, or firewall rule change are common triggers

Document each test result. Most drop investigations narrow to one root cause within 2–3 hours of systematic testing. Avoid changing multiple settings simultaneously — you need to know which change fixed the problem.

Preventing Future Call Drops

Once you resolve the immediate issue, implement monitoring to catch regressions before agents notice.

• Set up server monitoring alerts for CPU, RAM, and disk usage thresholds
• Schedule weekly review of VICIdial disconnect/disposition reports for unusual patterns
• Maintain a baseline of normal drop rate (typically under 1% of connected calls) and alert on deviations
• Keep Asterisk and VICIdial updated — bug fixes for channel handling are released regularly
• Capacity plan before scaling — add server resources or carriers before increasing agent count or dial level
• Test carrier changes in a sandbox campaign before moving production traffic

When to Escalate to Your Carrier or Host

If systematic testing points to the carrier — SIP 503 errors, consistent drops at carrier timeout intervals, or capacity rejections — open a ticket with your SIP provider including Asterisk logs, timestamps, and affected caller IDs. Reputable carriers have NOC teams that can trace call paths on their side.

For managed hosting customers, provide your vicidial support team with the diagnostic results from this guide. They can check server-side metrics, Asterisk configuration, and carrier trunk health faster than an external investigation.

Conclusion

Dropped calls in VICIdial are almost always diagnosable with structured troubleshooting. Start with server resources, then SIP timers, carrier capacity, network quality, and finally dialer settings. The pattern of drops — fixed intervals, peak-hour clustering, or randomness — tells you which layer to investigate first. Fix the root cause rather than masking symptoms with timeout adjustments, and implement monitoring to prevent recurrence.

Stable outbound calling requires alignment across your vicidial server, SIP carriers, and agent network. Invest in proper vicidial hosting infrastructure and carrier relationships upfront, and drop rates stay low as you scale.