One-Way Audio in VoIP Calls

1. How RTP audio routing works

When a SIP call connects, the two endpoints negotiate media addresses in the SDP. The c= line (connection data) and m= line port tell each endpoint where to send RTP packets. If either endpoint sends to the wrong address or port — or if a firewall blocks packets in one direction — you get one-way audio.

The SIP signaling (INVITE, 200 OK, ACK) is completely separate from the RTP media stream. A successful call setup with a working SIP ladder does not guarantee the media path is correct.

2. Which direction is broken?

Before diagnosing, establish which direction has the problem:

• Caller can hear, callee cannot — RTP from caller to callee is blocked or misdirected. The callee's receive path is broken.
• Callee can hear, caller cannot — RTP from callee to caller is blocked or misdirected. The caller's receive path is broken.
• Neither can hear — both directions are broken, or the call connected but no RTP was negotiated at all (check for a=sendonly or a=inactive in the SDP).

In a PCAP, look at the source and destination IP/port of RTP packets. If you only see packets flowing one way, you've confirmed the direction of the problem.

3. Eight common causes

4. NAT — the most common culprit

NAT causes one-way audio when an endpoint behind NAT advertises its private IP in the SDP. The fix depends on your architecture:

Option A — STUN (best for IP phones and softphones)

Configure your endpoint to use a STUN server. STUN discovers the public IP/port and the endpoint uses that in the SDP instead of the private IP. Works well for simple NAT but not symmetric NAT.

Option B — SBC with media anchoring

Configure a Session Border Controller to anchor all media through itself. The SBC rewrites both the originating and terminating SDP to point to itself, eliminating NAT traversal issues for both endpoints.

Option C — nat=yes / localnet in Asterisk

In Asterisk, set nat=yes (chan_sip) or configure local_net in pjsip.conf to instruct Asterisk to rewrite the SDP c= line with its external IP. Set externip or externhost to your public IP address.

How to confirm NAT is the issue

In your SIP trace, find the SDP in the INVITE or 200 OK. Check the c= line. If it contains a private IP (10.x, 172.16-31.x, 192.168.x) and the remote endpoint is on a different network, that's your problem.

5. Diagnosing from a PCAP

A PCAP gives you the most definitive diagnosis for one-way audio. Look for:

1. RTP stream presence — filter on rtp in Wireshark. Do you see two streams or one? If only one stream exists, the sending side is the problem.
2. Destination addresses — where are the RTP packets going? Cross-reference against the SDP c= lines. If the destination matches a private IP that's unreachable, NAT is the cause.
3. RTCP receiver reports — RTCP RR packets contain jitter, packet loss, and fraction lost statistics. A high fraction-lost in one direction points to the broken direction.
4. Packet timestamps — gaps in RTP timestamps indicate packets are being dropped somewhere in the path. Consistent gaps suggest a firewall rate limit or buffer overflow.

6. Fix checklist

• Check the SDP c= line — does it contain a private RFC 1918 address?
• Verify firewall rules allow RTP traffic in both directions on the negotiated port range
• Confirm no a=sendonly or a=inactive attributes are stuck in the SDP after a hold/resume
• If using an SBC, verify it's rewriting SDP for both directions symmetrically
• Check SRTP crypto lines — both sides must have matching crypto suites and keys
• After a transfer or re-INVITE, verify the new SDP contains valid, reachable addresses
• Test with a softphone on the same network segment to eliminate NAT as a variable

7. Analyze your trace automatically

Upload your PCAP to SIPSymposium and get an instant diagnosis — private IP detection in SDP, RTP stream direction analysis, RTCP statistics, and SRTP validation all in one report.