Connection Problems
Use this guide for connection error, processing error, NO AUDIO, 403 responses, or any "AMDY can't reach our server" symptom.
Step 1 — Run the connection check
From your VICIdial telephony server:
curl -sk https://download.amdy.io/proxy_check.py | python3 - --runs 10
This runs 10 test probes from your server out to AMDY and reports the result of each. Healthy output ends with All IPs healthy.
Faster single-probe alternative (just confirms outbound to the detection ports works at all):
telnet api.amdy.io 2443
telnet api.amdy.io 2700
Connected → you can reach AMDY. Connection refused / hang / timeout → your outbound to that port is blocked. The detection client connects with TLS on 2443 first and falls back to plain 2700; allow both outbound if you can.
Step 2 — Match your result
| What you see | Likely cause | What to do |
|---|---|---|
curl: (6) Could not resolve host |
DNS isn't working on the server | Check /etc/resolv.conf and restart your resolver |
curl: (7) Failed to connect |
Outbound HTTPS (port 443) is blocked | Allow outbound traffic to download.amdy.io |
status=403 on every run |
Your server's public IP isn't allow-listed yet | Send the full check output to AMDY support to be allow-listed |
A mix of 200 and 403 |
Some of your outbound IPs are allowed, others aren't | Send the full output — the missing IPs will be added |
python3: command not found |
The installer hasn't been run | Run the installer for your system — see Setup & installation |
SyntaxError: future feature annotations... |
The server's Python is too old | Use Python 3.8 or newer; the installer provides a current version |
| Some IPs show ✓, others refused or timeout | Your firewall blocks outbound to those specific IPs — not an AMDY allow-list issue | Open outbound to ports 2443 and 2700 broadly (see "Intermittent errors" below) |
All runs succeed but logs still show connection error |
A firewall is blocking part of the return path | See "Intermittent errors" below |
NO AUDIO on calls |
Call audio (RTP) isn't reaching AMDY | Add firewall rules to allow RTP media, not just signaling |
Intermittent errors (works sometimes, fails sometimes)
If the connection check passes but you still get occasional connection error results:
- Open your firewall for outbound traffic to ports 2443 and 2700, rather than pinning specific IP addresses. AMDY's address set changes regularly, so a fixed list of "today's IPs" will break.
- Re-run the connection check after any infrastructure change — a new proxy, a NAT change, an ISP change, or a data-center move.
- Confirm the server's date and time are correct. A large clock skew breaks secure connections.
- If only some campaigns are affected, check whether they route through a different outbound proxy than the one you tested.
- If calls end with HANGUP AUDIO_TIMEOUT and ${AMDSTATUS} / ${AMDCAUSE} come out empty on extension 8370, the call is dropping while waiting for AMDY — same outbound blockage. Opening the firewall to ports 2443 and 2700 typically resolves it. The connection check above can still show All IPs healthy in this case, because it tests HTTPS to the gateway, not the call's outbound port.
Escalating
If you still see 403s after testing, send AMDY support the full output of the connection check — the list of outbound IPs with their hit counts. That is exactly what's needed to allow-list any missing addresses. See Contacting support.