One-way audio — where one party hears the other but not the reverse — is the single most reported VoIP fault, and it is nearly always a media path problem rather than a signalling one. The call connects because SIP got through; the audio fails because RTP did not.
Work through these in order.
1. Turn off SIP ALG
Start here, always. SIP Application Layer Gateway is a feature on consumer and small-business routers that rewrites SIP packets as they pass through. It was designed to help with NAT and it is now the leading cause of one-way audio, because the rewriting is frequently wrong.
Disable it on every router between your endpoints and the internet. On many devices it is enabled by default and buried under a name like "SIP transformations" or "VoIP passthrough".
2. Check symmetric RTP and NAT settings
Endpoints behind NAT advertise their private IP in the SDP body. The far end dutifully sends audio to an address that is unreachable from the public internet.
Ensure your endpoints and PBX are configured for symmetric RTP — sending media back to the address the audio actually arrived from, rather than the address advertised in the SDP. This one setting resolves a large share of cases.
3. Verify the RTP port range is open
SIP signalling on 5060 gets attention; the RTP media range often does not. Confirm the full UDP port range used for media is permitted outbound and that return traffic is allowed. Firewalls that permit signalling but drop media produce exactly this symptom.
4. Look at codec negotiation
If the two ends cannot agree on a codec, you can end up with a connected call carrying no usable audio in one direction. Check what each side offers and answers. A transcoding media proxy removes this class of problem entirely by bridging codecs in the middle.
5. Capture the traffic
If the first four steps have not resolved it, stop guessing and take a packet capture at both ends. You are answering one question: is RTP arriving at all in the failing direction?
- RTP arriving but not played — endpoint or codec problem
- RTP not arriving — NAT, firewall or routing problem upstream
- RTP arriving from an unexpected address — asymmetric routing
The capture converts a vague complaint into a specific fault, and it is what any competent carrier will ask for anyway.
6. Anchor the media
When endpoints sit behind NAT you do not control — remote agents, customer sites, carriers that will not accept media from an unknown IP — the durable fix is to stop trying to make direct media work. A media proxy terminates and re-originates RTP at a public, well-peered point of presence, so both legs talk to an address that is always reachable.
That also gives you a single place to measure jitter, loss and MOS, which turns the next quality complaint into a data question rather than an argument.
A note on intermittent cases
Faults that appear only on some calls are usually route-dependent, not configuration-dependent. Correlate failures against the carrier and destination in your CDRs before touching endpoint settings — a configuration problem would fail consistently.
