Fixing NAT one-way audio in the cloud

A call connects, the agent answers, and then either the agent can hear the caller but the caller hears nothing, or the reverse. Occasionally both sides hear nothing at all. This is the classic NAT audio problem, and on a cloud server it is by far the most common audio complaint. The root cause is almost never a broken codec — it is Asterisk telling the carrier to send audio to an IP address the carrier cannot reach.

Why NAT breaks audio

When a cloud provider places your VM behind hypervisor-level NAT (Network Address Translation) NAT traversal, the OS sees a private address like 10.0.0.5 on its network interface. Asterisk reads that address from the kernel and puts it into the SDP (Session Description Protocol) body of every SIP INVITE. The SDP is the part of the SIP (Session Initiation Protocol) message that tells the other side: send your RTP audio to this IP and port.

The carrier receives the INVITE, sees the SDP instruction, and obediently sends its RTP (Real-time Transport Protocol) RTP audio stream to 10.0.0.5. That address is not routable on the public internet. The packets never arrive at your box. The agent hears silence. Meanwhile, audio going the other direction — from your server to the carrier — may work fine because your server is the one initiating the outbound RTP flow. That is why you get one-way audio One-way audio rather than total silence.

Diagnosing before you fix

First, confirm your server has a public IP on the interface or a 1:1 NAT at the hypervisor. Run curl -s https://api4.ipify.org and compare the result to ip addr show. If the two differ, you are behind NAT at the hypervisor level. Next, run a test call and capture it with asterisk -rx 'sip show channels' or look at the SDP in a SIP trace — check whether the connection address in the SDP is the private IP or the public one. If it is the private IP, that confirms the diagnosis.

flowchart TD
  A[One-way audio reported] --> B{SDP shows private IP?}
  B -- yes --> C[NAT rewrite problem]
  C --> D[Set externip and localnet in sip.conf or pjsip.conf]
  D --> E[Reload Asterisk SIP module]
  E --> F[Test call - audio OK?]
  F -- yes --> G[Fixed]
  F -- no --> H{RTP ports open?}
  H -- no --> I[Open 10000-20000 UDP on firewall]
  H -- yes --> J[Check externip value is current public IP]
  B -- no --> H

The fix: externip and localnet

Asterisk has a built-in NAT rewrite mechanism. You tell it your external public IP and the local subnet, and it substitutes the public IP into outgoing Contact headers and SDP bodies. In sip.conf this is done with two settings in the [general] section:

[general]
externip=203.0.113.42        ; your static public IP
localnet=10.0.0.0/8          ; your private subnet
nat=force_rport,comedia      ; also needed for peer-level NAT

For PJSIP (the modern Asterisk SIP stack used in recent VICIdial builds), the equivalent lives in the transport section of pjsip.conf:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=203.0.113.42
external_signaling_address=203.0.113.42
local_net=10.0.0.0/8

After editing, reload the SIP module without restarting Asterisk: asterisk -rx 'module reload chan_sip.so' (or module reload res_pjsip.so for PJSIP). Place a test call and verify the SDP now shows the public IP.

When the fix does not fully resolve the issue

If audio is still one-way after setting externip, the next thing to check is whether the RTP port range is open on the cloud firewall. A closed UDP range (commonly 10000–20000) will look identical to a NAT problem because the symptoms are the same: call connects, no audio. These two issues often appear together on a new cloud server. If both externip and the RTP range are correct but you still have audio problems, check for packet loss Packet loss or jitter Jitter on the path between your carrier and the cloud region — some cloud regions have poor peering with certain carriers.

For the broader picture of cloud networking for VICIdial, including region selection and carrier latency, see our VICIdial in the cloud guide. If you are also dealing with RTP ports being blocked, the companion post opening the RTP port range on a cloud firewall covers that separately.

Getting NAT right on a cloud VPS requires careful attention to the Asterisk config, the cloud provider's network topology, and the firewall. If you want a box where all of this is already sorted, check out VICIfast managed hosting — a fully configured server is ready in under 40 seconds.