Solving One-Way Audio Problems in VoIP Calls

In the world of VoIP, one-way audio issues are the network equivalent of a conversation where one person is shouting into a canyon and only hearing silence in return. The signaling works, the call is established, and everything looks fine — except that one party can’t hear the other.

It’s frustrating for the end user, and it can be tricky to diagnose — but with a methodical approach, it’s usually solvable.

Let’s walk through how to track down and fix this kind of problem.

What Causes One-Way Audio?

While there are many possible root causes, most one-way audio problems fall into one of two main categories:

A “closed gate” somewhere in the voice path
Most VoIP calls involve media (RTP) streams flowing directly between two endpoints — and those streams must be able to pass through any firewalls, NAT devices, or routers in their path. If one side’s audio packets are being blocked — or are sent to the wrong place — then the other party hears nothing.
A media relay (SBC or media gateway) is failing
Sometimes the RTP stream is meant to be relayed through a Session Border Controller or media gateway, especially in networks involving SIP-to-TDM translation or NAT traversal. If that relay device has a misconfiguration or is malfunctioning, it might drop audio in one direction.

Step-by-Step: How to Diagnose One-Way Audio

Here’s how we recommend tackling this problem.

1. Start with SIP signaling — check the SDP

Your first step is to inspect the SIP INVITE and 200 OK messages, specifically the SDP (Session Description Protocol) section, which defines where each side wants to send and receive RTP.

Look for:

IP addresses in the c= line
- Are they publicly routable?
- Are they valid and reachable from the other endpoint?
- An IP address of 0.0.0.0 is a special case that signals a media stream should be disabled — so that’s a definite clue if you see it.
Directional attributes like a=sendonly, a=recvonly, or a=inactive
- These indicate whether a device is willing to send, receive, or both.
- If one side is advertising sendonly, and the other isn’t prepared to receive, the result is predictable silence.
Port numbers in the m= line
- Make sure they’re valid and within the expected RTP range.
- Also verify that firewalls are not blocking those ports.

This step often reveals obvious misconfigurations. For example, an SBC might be advertising a private IP in the SDP instead of its public-facing address, which would mean the far-end device is sending RTP to an unreachable destination.

2. Identify the media path topology

Next, figure out the intended flow of RTP.

Are the endpoints supposed to send media directly to each other?
Or is there an intermediary device (like an SBC, media gateway, or B2BUA) in the middle?

This will help you know where to look if the packets aren’t flowing as expected.

3. Use packet captures to track the RTP

If the SDP checks out, it’s time to take packet captures — ideally on both sides of the call and on any intermediate devices that support it.

What you’re looking for:

Do RTP packets leave the sending device?
Do they arrive at the receiving device?
Does the intermediate SBC/gateway receive and forward them properly?

This step helps pinpoint the exact spot where the packets go missing.

You can also use tools like Wireshark to listen to the captured audio stream and verify which direction is missing. This is especially helpful when both directions have RTP packets but only one is intelligible.

4. Investigate the culprit device

Once you’ve found the spot where the packets disappear, dig into the configuration or logs of that device.

Some common issues we see:

Firewall rules blocking certain ports or IP ranges
NAT traversal settings not correctly applied
Media anchoring disabled on SBCs, leading to asymmetric RTP
Codec mismatches or media negotiation failures
Resource exhaustion, where the device is overloaded and dropping traffic

Conclusion: One-Way Audio Doesn’t Have to Be a Mystery

While it can feel puzzling at first, one-way audio is usually a detective story with a clear ending. Start with SIP signaling, trace the media path, capture the packets, and the culprit will reveal itself.

If you need help tracking it down — or designing a network that avoids these issues in the first place — we’d be happy to help. We’ve got deep experience with SBCs, SIP traces, NAT traversal, and the various quirks of media gateways.

Drop us a line, and we’ll help make sure your voice is heard — in both directions.