Agents not getting calls

Use this guide when agents sit idle and it feels like the dialer or AMDY "went bad". The AMD plugin only classifies calls the carrier delivers; it cannot reduce how many people pick up. A sudden drop in live answers is almost always DID reputation: numbers that get spam-tagged stop being answered, and idle agents are the symptom. Reputation degrades over time, so "it was fine two weeks ago" is exactly what this looks like.

Run these in order

Step 1 — Check connectivity (the proxy check)

curl -sk https://download.amdy.io/proxy_check.py | python3 - --runs 10

• Output ends with All IPs healthy → your server reaches AMDY. Go to Step 2.
• 403 on every run → your server IP is not allow-listed yet. Send us the full output plus the server's public IP (curl ifconfig.me) and we will add it.
• A mix of 200 and 403 → some of your outbound IPs are missing. Send the full output and we will add the missing ones.
• Quick single probe instead: telnet api.amdy.io 2700. Connected = good; timeout or refused = outbound port 2700 is blocked on your firewall. Open outbound 2700 broadly rather than pinning IPs — the AMDY address set changes, so a fixed list breaks.

More detail: Connection problems.

Step 2 — Watch live detections during a test call

curl -sL https://download.amdy.io/amd-tail.sh | bash

Color-coded live log, one line per answered call: green = HUMAN, yellow = MACHINE, cyan = FAS/HONEYPOT, magenta = errors. Press Ctrl+C to stop. Raw equivalent: tail -f /var/log/astguiclient/AMD_log$(date +%Y%m%d).txt

What the lines tell you: if calls where a prospect clearly answers are marked MACHINE or FAS, detection misdrops are eating your connects. If the log shows connection error / SERVER_TIMEOUT, that is Step 1, not accuracy.

Step 3 — Confirm the install (if Step 1 was clean but calls still fail)

ls -la /var/lib/asterisk/agi-bin/amd.py
python3 -c "import websocket, mysql.connector, asterisk.agi; print('All modules loaded successfully')"
asterisk -rx 'dialplan show' | grep 8370

• The campaign's routing extension must be 8370 (AMDY), not 8369 (stock Asterisk AMD). If it is 8369, your results are not coming from us.
• One-shot install + reachability check: curl -s https://download.amdy.io/check-aiamd.sh | bash

Full detail: Install AMDY.

Step 4 — DID health check (the most common cause)

1. VICIdial: Admin → Reports → DID stats. Compare answer rates per DID over the last two weeks.
2. Look the numbers up in a DID reputation service such as FraudCentral.io.
3. Any DID showing a spam/scam label or a collapsed answer rate: pull it and rotate to fresh DIDs. This alone usually restores agent talk time.

More detail: the "Scam Likely / Spam" section of the Agent & Call Experience guide.

Step 5 — Pull recordings for the dropped calls

Do not troubleshoot accuracy from memory — work from recordings:

1. VICIdial: Reports → Export Calls Report. Date range covering the good days and today, status A, Rec Fields LOCATION, Export Type EXTENDED.
2. Upload the exported file to https://recs.amdy.io and listen.

What you will hear: a genuine voicemail repeats the phone number ("you've reached 305-555-…"). A carrier false answer (FAS) is a message like "the call has been forwarded to an automatic voice message system" — no person was ever on the line. Carriers report FAS calls as "answered", which makes your connect numbers look worse than detection does.

Send us this and we will verify on our side

1. The server's public IP: curl ifconfig.me
2. Full Step 1 output, if it was not all healthy
3. 5–10 V-prefixed caller codes from calls where "it worked" two weeks ago, and a few from today

With those we can check your allow-list, pull the exact calls, and compare results before and after the drop.