One-Way Audio: A Packet-Level Walkthrough

One-way audio is the most frustrating VoIP problem to troubleshoot without a packet capture. The call connects. Both sides see the call as active. One person talks and the other person hears them. But the audio only flows in one direction. Nobody can figure out why, because from the signaling perspective, the call is fine.

The answer is almost always visible in the packets if you know where to look. This walkthrough follows a one-way audio scenario from call setup through media flow, showing exactly what goes wrong and how the packet capture reveals it.

The setup

Two phones are trying to have a conversation:

• Phone A is inside an office behind a NAT router. Its local IP is 192.168.1.50. The office's public IP is 203.0.113.10.
• Phone B is at a remote site with a public IP of 198.51.100.20.

Phone A calls Phone B through a SIP provider. The signaling goes through the provider's proxy. The media (RTP audio) is supposed to flow directly between the two phones.

The INVITE: where the problem is planted

Phone A sends an INVITE to Phone B. Inside the INVITE is an SDP body that tells Phone B where to send audio:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>
Call-ID: [email protected]
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp

v=0
o=- 20001 20001 IN IP4 192.168.1.50
c=IN IP4 192.168.1.50
m=audio 18000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

The critical line is c=IN IP4 192.168.1.50. This is Phone A telling Phone B: "send my audio to 192.168.1.50 port 18000." But 192.168.1.50 is a private RFC 1918 address. It only exists inside Phone A's office network. Phone B has no route to it.

This is where the problem starts. The INVITE looks perfectly normal. The call will complete successfully. But the media path is broken from the beginning.

The 200 OK: the other side responds correctly

Phone B receives the INVITE (routed through the provider) and answers:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>;tag=def456
Call-ID: [email protected]
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp

v=0
o=- 30001 30001 IN IP4 198.51.100.20
c=IN IP4 198.51.100.20
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Phone B's SDP says c=IN IP4 198.51.100.20. This is a public IP. Phone A can reach it. So far, Phone B has done everything right.

The call is now established. Both sides think the call is active. Here is what happens next.

The media: one direction works, one does not

Phone A to Phone B (works):

Phone A starts sending RTP packets from 192.168.1.50:18000 to 198.51.100.20:20000. These packets hit Phone A's NAT router, which rewrites the source address from 192.168.1.50:18000 to the public address 203.0.113.10:49152 (or whatever ephemeral port the router assigns). Phone B receives audio from 203.0.113.10:49152. The audio plays fine.

In the packet capture on Phone B's side, you see:

203.0.113.10:49152 -> 198.51.100.20:20000  RTP PCMU
203.0.113.10:49152 -> 198.51.100.20:20000  RTP PCMU
203.0.113.10:49152 -> 198.51.100.20:20000  RTP PCMU

Phone B hears Phone A perfectly.

Phone B to Phone A (fails):

Phone B tries to send RTP to the address Phone A advertised in the SDP: 192.168.1.50:18000. Phone B sends packets to 192.168.1.50:18000. These packets go nowhere. 192.168.1.50 is not routable on the public internet. They are either dropped immediately by Phone B's router (because it has no route to a private address) or they get lost somewhere in transit.

In the packet capture on Phone A's side, you see:

192.168.1.50:18000 -> 198.51.100.20:20000  RTP PCMU
192.168.1.50:18000 -> 198.51.100.20:20000  RTP PCMU
192.168.1.50:18000 -> 198.51.100.20:20000  RTP PCMU

Phone A's outbound audio is being sent. But there are zero inbound RTP packets from Phone B. Phone A hears silence.

This is one-way audio. Phone B hears Phone A. Phone A hears nothing.

What the packet capture reveals

If you open this capture in Wireshark and go to Telephony > RTP > RTP Streams, you see two streams for this call:

| Source | Destination | Packets | Lost | Jitter | |--------|------------|---------|------|--------| | 192.168.1.50:18000 | 198.51.100.20:20000 | 4800 | 0 | 2.1ms | | 198.51.100.20:20000 | 192.168.1.50:18000 | 0 | - | - |

The first stream (Phone A to Phone B) has 4800 packets, no loss, low jitter. That direction is fine. The second stream (Phone B to Phone A) has zero packets captured at Phone A's end. The audio never arrived.

If you captured on Phone B's side instead, you would see Phone B sending packets to 192.168.1.50:18000 and getting no ICMP unreachable response, no error of any kind. The packets just disappear.

The fix

The root cause is that Phone A advertised a private IP in its SDP. The fix depends on your setup:

STUN. Configure Phone A to use a STUN server. Before placing a call, the phone sends a request to the STUN server, which replies with the phone's public IP and port. The phone then uses this public address in its SDP instead of 192.168.1.50. Phone B sends audio to the public address, the NAT router recognizes the return traffic, and forwards it to Phone A.

SIP provider media proxy. Many SIP providers run a media proxy that rewrites the SDP to insert the proxy's address. Both sides send audio to the proxy, and the proxy relays it. This solves the NAT problem at the cost of adding a hop (and potentially more latency and jitter). Most hosted PBX providers do this by default.

Disable SIP ALG. If your router has SIP ALG enabled, it may be rewriting SDP addresses incorrectly, making the problem worse instead of better. The universal recommendation from VoIP providers is to turn it off. ALG implementations are notoriously buggy and create more problems than they solve.

Symmetric RTP. Some phones and PBXs support symmetric RTP, which means they send RTP from the same port they expect to receive on. Combined with the NAT router's connection tracking (which creates a pinhole for return traffic on the same port mapping), this can fix one-way audio without STUN. Your phone or PBX may call this "NAT keep-alive" or "comedia" mode.

Variations on the theme

Both sides behind NAT

If both Phone A and Phone B are behind NAT routers and both advertise private IPs, you get zero-way audio: neither side can reach the other. The call connects (signaling goes through the provider's proxy) but nobody hears anything.

Audio works initially then stops

NAT mappings have timeouts. If a call is on hold or the conversation goes quiet for several minutes, the NAT router may expire the UDP pinhole. When audio resumes, the mapping is gone and return packets can no longer reach the internal phone. This looks like one-way audio that started working and then broke mid-call.

One-way audio only on transfers

Call transfers trigger a re-INVITE that renegotiates the media session. If the new SDP has the same private IP problem, the transferred call will have one-way audio even though the original call was fine. This happens because the original NAT mapping was specific to the original RTP port pair, and the transfer creates a new media session.

Finding this in your own captures

The pattern is always the same: look at the SDP in the INVITE and the 200 OK. If either side has a private IP (10.x.x.x, 172.16-31.x.x, 192.168.x.x) in the c= line, and the other side is on a different network, you have found the problem.

If you have a pcap file and want to skip the manual analysis, the PCAP Analyzer extracts every SIP dialog, identifies the media addresses from the SDP, maps the RTP streams, and flags asymmetric media flow. It shows you which direction has packets and which does not, along with the SDP addresses that explain why.

SIP Call Stories approaches the same capture from the signaling side: it tells each call's story in plain English — what happened, how long setup took, which side ended it, and what every failure code means.

Both tools process your capture in memory and never store it. Only the extracted analysis comes back to your browser.