These two get reported together and treated as one problem. They are not. Understanding which you are actually looking at cuts the diagnosis time substantially.
Waiting for Ring
The agent screen shows this while it waits for VICIdial to report that a call has been placed to their conference. Stuck there means the loop between Asterisk, the database and the agent’s browser is broken somewhere.
Check the AGI Line First
This is the most common cause by a wide margin. Every outbound dialplan entry needs the call_log AGI at priority 1:
exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,n,Dial(SIP/mytrunk/${EXTEN:1},,tTo)
exten => _91NXXNXXXXXX,n,Hangup()Without it, the call connects but nothing registers the channel against the agent’s session. The screen waits forever for an event that will never arrive.
Check what is actually loaded — not what you think you saved in the admin interface:
asterisk -rx "dialplan show default" | head -40Confirm the AGI listener is alive:
netstat -tlnp | grep 4577
screen -ls | grep ASTlistenIf ASTlisten is not running, restart the daemons:
/usr/share/astguiclient/ADMIN_keepalive_ALL.pl --restartCheck the Screens
VICIdial’s state machine runs across several perl processes. If one has died, symptoms surface in the agent interface rather than as an obvious error.
screen -lsYou want ASTfastlog, ASTVDauto, ASTVDadapt, ASTupdate, ASTsend and ASTlisten. Any missing process explains this behaviour. Check why before restarting:
tail -100 /var/log/astguiclient/process.logA repeatedly dying screen usually means a perl module problem or a database connection failure, and restarting just delays the next occurrence.
Check Database Load
The agent interface polls the database frequently. Under load, or with a crashed table, those queries stall and the screen hangs.
SHOW PROCESSLIST;Long-running queries against vicidial_live_agents or vicidial_auto_calls point at a locking or table problem:
mysqlcheck -u cron -p1234 --check asterisk | grep -v "OK$"A crashed vicidial_live_agents table produces exactly this symptom, for every agent at once.
Check the Browser Side
If it affects one agent only and their phone is registered, look at their connection. The agent interface needs to reach the server continuously. A flaky connection or an aggressive corporate proxy will break the polling.
Confirm the phone is up:
asterisk -rx "sip show peer 8001"And that the time on the agent’s machine is not wildly off — VICIdial compares timestamps and a large skew causes odd interface behaviour.
Dial Timed Out
Different problem entirely. Asterisk dialled, waited, and gave up.
Read the Actual Hangup Cause
asterisk -rvvvvvsip set debug peer mytrunkPlace a test call and read the response. The SIP code tells you who is refusing:
| Response | Meaning |
|---|---|
| No response at all | Packets not reaching the carrier — firewall or routing |
| 403 Forbidden | Carrier rejecting your traffic. IP not whitelisted, or account suspended |
| 404 Not Found | Number format wrong. Usually the dial prefix not stripped |
| 480 Temporarily Unavailable | Far end unreachable |
| 503 Service Unavailable | Carrier at capacity, or your channel limit hit |
| 487 Request Terminated | Your side cancelled — this is the timeout itself |
Turn debug off afterwards:
sip set debug offCheck the Number Being Sent
If every call to a particular format fails, the dial prefix is probably not being stripped:
exten => _9X.,n,NoOp(DIALING: ${EXTEN:1})Watch the CLI. If it shows 915551234567 rather than 15551234567, your ${EXTEN:1} is missing or the pattern is matching a different rule than you expect.
Check the Timeout Value
Dial(SIP/mytrunk/${EXTEN:1},30,tTo)Thirty seconds is standard for predictive campaigns. If your carrier is slow to return ringback on certain routes, legitimate calls get cut at 30 and logged as timeouts. Raise it to 45 and see whether the rate changes.
The campaign’s Dial Timeout in Admin → Campaigns → Detail interacts with this. If the campaign timeout is shorter than the dialplan timeout, the campaign wins.
Check Channel Capacity
If timeouts appear only at peak, you are hitting a limit:
asterisk -rx "core show channels count"Compare to what your carrier permits concurrently. Exceeding it produces 503s that surface as timeouts. Lower the auto dial level or buy more channels — there is no configuration fix for a hard channel cap.
Check the Trunk Itself
asterisk -rx "sip show registry"
asterisk -rx "sip show peers"A registration that has silently dropped will cause every call to time out while the admin interface still shows the carrier as active.
Telling Them Apart Quickly
Run this while an agent reports the problem:
asterisk -rx "core show channels"That one command sorts most reports into the right bucket immediately, which is worth more than any individual fix below it.
