One-way audio on carrier calls: causes and fixes

One-way audio means the call connected and both sides think they are talking, but voice only travels one direction. The signaling worked; the media did not. Almost always this is a network problem: the audio packets are being dropped or sent to the wrong address because of NAT, a wrong public IP, or a closed port range.

Signaling and media are two separate streams

A VoIP call has two halves that travel separately. The SIP (Session Initiation Protocol) signaling (INVITE, 200 OK, ACK) sets the call up and rides on port 5060. The actual audio rides on RTP, a different protocol on a high UDP port range. When you hear one-way audio, signaling reached the Carrier fine — otherwise the call would never have connected — but RTP is only flowing one way.

The direction that is silent tells you which side cannot reach the other. If your agent hears nothing but the far end hears them, the carrier's RTP is not reaching your box. If the agent is heard but cannot hear, your box's RTP is not reaching the carrier. The fix is to make sure each side advertises a reachable address for its audio.

Where RTP gets blocked

flowchart LR
  A[Agent Phone] -->|RTP| B[VICIdial Box]
  B -->|RTP out| C{NAT / Firewall}
  C -->|wrong externip| X[Dropped]
  C -->|correct externip| D[Carrier]
  D -->|RTP back| E{RTP port range}
  E -->|closed| Y[Dropped one way]
  E -->|open 10000-20000| B

The diagram shows the two failure points. RTP leaving your box can be rewritten to the wrong source address by NAT, and RTP coming back can hit a closed UDP port range. Either one produces silence in a single direction.

The settings to check

• Public IP / externip: if your Asterisk box is behind NAT, it must advertise its public address in SDP, not the private one. Set externip (or external_media_address on PJSIP) to the real public IP, or the carrier sends audio into a private address that never arrives.
• localnet: list your private subnets so Asterisk knows which peers are local and which are remote. Get this wrong and it rewrites addresses for the wrong calls.
• RTP port range: the high UDP range (commonly 10000-20000) must be open inbound on the firewall. Port 5060 alone is not enough — that only carries signaling.
• Symmetric RTP / NAT mode: enable symmetric RTP so Asterisk replies to the address audio actually came from, instead of the address advertised in SDP. This rescues most carrier-side NAT cases.
• Codec match: a Codec mismatch can also look like dead audio. Pin one codec both sides support, such as G.711 codec (ulaw), so there is no silent re-negotiation failure.

How to confirm the fix

Place one manual test call and listen on both ends. If you want to see the media addresses being negotiated, run rtp set debug on at the Asterisk CLI and watch where the packets are addressed — a mismatch between the advertised address and the real one is the smoking gun. For a structured walk through the whole trunk setup, see our VICIdial carrier integration guide. If the call rings but never connects at all, that is a different problem — start with adding a carrier trunk correctly.

On a managed box with a fixed public IP, externip and the RTP range are set correctly from the start, so this whole class of NAT bug never shows up. If you would rather not chase audio paths through a firewall, see our plans — every box ships with a static public IP and the media ports already open.