When running AVR and Asterisk on a cloud VPS (Hetzner, AWS, DigitalOcean, etc.) using Docker, a very common issue is:
The call connects, but there is no audio (or one-way audio).
In most cases this is caused by an incorrect NAT / network configuration in Asterisk’s pjsip.conf, especially these fields:
external_media_addressexternal_signaling_addresslocal_netThis page explains how to configure them properly in the context of avr-infra.
In the avr-infra project, the relevant file is:
asterisk/conf/pjsip.conf
By default, this file may contain placeholder values such as:
external_media_address=127.0.0.1
external_signaling_address=127.0.0.1
local_net=127.0.0.1/32
These values must be updated when running on a public cloud VPS.
Run the following command on your VPS:
curl ipinfo.io/ip
Example output (fake but realistic):
95.216.41.122
This IP should be used for:
external_media_addressexternal_signaling_addressNext, list your local network interfaces:
ip addr
Example output (simplified and fake but realistic):
lo: 127.0.0.1/8
eth0: 172.31.26.138/20
docker0: 172.17.0.1/16
br-9834d22c1f45: 172.20.0.1/16
Each of these networks should be declared in pjsip.conf via local_net.
pjsip.confOpen:
asterisk/conf/pjsip.conf
and update the NAT-related settings:
; Public IP of your VPS
external_media_address=95.216.41.122
external_signaling_address=95.216.41.122
; Local networks
local_net=127.0.0.1/8
local_net=172.31.26.138/20
local_net=172.17.0.1/16
local_net=172.20.0.1/16
⚠️ Do not leave
127.0.0.1/32as the onlylocal_netwhen running on a cloud VPS.
Asterisk needs to know all local networks (host and Docker).
If you’re using docker compose with avr-infra, you can restart only the Asterisk container:
docker compose restart avr-asterisk
Or, if you’re using a specific compose file:
docker compose -f docker-compose-openai.yml restart avr-asterisk
(adjust the filename to match your setup).
If you still have no audio, verify:
external_media_address and external_signaling_address are set to the public IP of the VPSip addr are listed as local_net10000–20000) are allowed in the firewall / security groupsavr-infra| Symptom | Likely cause | Fix |
|---|---|---|
| No audio (both sides) | Wrong external_media_address |
Set it to the VPS public IP |
| One-way audio | Missing local_net entries |
Add all local networks from ip addr |
| Works locally only | 127.0.0.1 used for everything |
Replace with real public IP and local networks |
| Random audio issues | Firewall dropping RTP | Open UDP 10000–20000 to/from the VPS |
Assume:
Public IP: 95.216.41.122
ip addr shows:
lo: 127.0.0.1/8eth0: 172.31.26.138/20docker0: 172.17.0.1/16br-9834d22c1f45: 172.20.0.1/16Then your pjsip.conf should contain:
external_media_address=95.216.41.122
external_signaling_address=95.216.41.122
local_net=127.0.0.1/8
local_net=172.31.26.138/20
local_net=172.17.0.1/16
local_net=172.20.0.1/16
After updating, restart the Asterisk container and test again.
If audio still doesn’t work after applying these settings:
pjsip.conf is being loaded inside the containerpjsip.conf and ip addr output (with sensitive data redacted) in the community for further helpIf audio is still not working after configuring pjsip.conf, you should inspect the RTP traffic inside the Asterisk container. This is the most reliable way to confirm whether RTP packets are flowing correctly in both directions (to and from the server).
docker exec -it avr-asterisk /bin/bash
This opens a shell inside the running Asterisk container.
Once inside the container, run:
asterisk -vvvvr
You should now see the Asterisk CLI prompt.
In the Asterisk CLI:
rtp set debug on
Now, whenever a call is active, you should see RTP packets scrolling in the console.
Sent RTP packet to 95.216.41.122:16432 (type 00, seq 04123, ts 153241231, len 160)
Got RTP packet from 95.216.41.122:16432 (type 00, seq 04124, ts 153241591, len 160)
You must see both directions:
Sent RTP packet to ...Got RTP packet from ...If you only see one direction, you likely have:
external_media_addressAVR includes a built-in echo test available at extension 600.
This is extremely useful to verify RTP flow without involving external providers.
If the echo test does not return audio, the issue is 100% network/NAT/RTP related, not ASR/AVR logic.
RTP debugging is essential when:
This tool allows you to directly confirm whether RTP is flowing — eliminating guesswork.
You can also reference this page whenever “no audio” issues appear in the community, since this misconfiguration is one of the most common root causes.