One-way audio in VoIP — NAT, RTP, SDP and firewalls

First identify the missing direction#

“One-way audio” is too general. Establish who cannot hear whom and whose perspective defines the direction. If A cannot hear B, the missing path is B → A, even if the report says “no audio at A”. This distinction prevents investigation of the wrong stream.

Record four endpoints:

• device A,
• the server or media proxy on A's side,
• the server or carrier on B's side,
• device B.

Then draw the expected RTP streams. With anchored media, they typically look like this:

A  <---- RTP ---->  PBX / SBC  <---- RTP ---->  B

If the PBX does not anchor media, devices may try to communicate directly. Private SDP addresses, asymmetric routing and restrictive NAT become particularly important.

SDP says where media should flow#

SIP establishes the session; SDP describes its parameters. Check c= and m=audio on each leg:

c=IN IP4 198.51.100.40
m=audio 18462 RTP/AVP 0 8 101
a=sendrecv

Address 198.51.100.40 and port 18462 are the advertised RTP destination for the other side. Behind NAT, an application may see a private interface address while an external peer needs the public one. The SIP profile or SBC should advertise the correct external address.

Not every RFC1918 address is wrong. It can be correct on private MPLS, a VPN or a dedicated interconnect. What matters is reachability from peers on that particular leg.

Compare offer and answer:

• have both directions negotiated a codec,
• is the port 0, indicating rejection of the stream,
• has the direction been set to sendonly, recvonly or inactive,
• did a re-INVITE change the address or port to an unreachable one,
• is the RTP profile (RTP/AVP, RTP/SAVP, UDP/TLS/RTP/SAVPF) compatible with both sides?

RTP shows what actually happens#

Once advertised destinations are known, inspect packets. Record each segment:

If B's RTP reaches the PBX but is not forwarded to A, investigate the bridge, codec, channel state or media-bypass configuration. If the PBX sends towards A but packets are absent at the client, inspect the firewall, NAT and route.

Wireshark's RTP statistics help: SSRC, sequence number, timestamp, jitter and loss. UDP presence alone proves little. Packets may reach the wrong port, carry another payload type or belong to an old stream after renegotiation.

NAT changes more than an address#

NAT maps private and public addresses. For UDP, mapping can depend on the destination, idle time and device implementation. A typical scenario:

1. the phone advertises a private SDP address,
2. it sends RTP from a public mapping created by NAT,
3. the server receives packets from an address or port different from SDP,
4. the server must choose between replying to SDP and the actual source.

Symmetric RTP sends replies to the address and port from which media actually arrived. It helps in many NAT environments but cannot fix a phone that sends no RTP or a firewall blocking outbound packets.

An open firewall port does not prove a correct path#

A rule such as “UDP 10000–40000 ACCEPT” is only the start. Confirm:

• which interfaces receive and send the traffic,
• whether the rule matches the correct source address,
• whether the host has the correct return route,
• whether conntrack associates the stream with another tuple,
• whether Docker or other NAT rules change processing order,
• whether the cloud has an additional security group or ACL,
• whether the carrier sends from allowlisted addresses.

Observe external and internal interfaces with tcpdump at the same time. For example:

tcpdump -ni any udp portrange 10000-40000 -w /tmp/rtp-check.pcap

The any filter quickly confirms traffic presence, but use separate interface captures for direction analysis. Otherwise the same packet may appear more than once.

Media proxies, bypass and unexpected shortcuts#

A PBX can anchor media or allow direct flow. Media bypass reduces server load but increases network requirements between endpoints. Direct media becomes unpredictable when one client is on a LAN, another behind CGNAT, and the carrier expects the SBC's public address.

Check whether:

• bypass_media or its equivalent is enabled,
• a re-INVITE attempts to connect endpoints directly,
• the SBC rewrites SDP on both legs,
• transcoding forces media anchoring,
• recording, IVR or a queue changes the RTP path,
• a transfer creates a new bridge with different ports.

One-way audio after transfer often has a different cause from the original call. The new dialog may use another profile, gateway or NAT policy.

A codec issue can look like a network issue#

If packets are visible both ways, inspect payload types and negotiation. A dynamic payload type only has meaning in its particular SDP context. Payload 101 usually means telephone-event, but that is not guaranteed without a=rtpmap.

Common problems:

• offer and answer select G.729, but the codec module is unavailable,
• an endpoint sends a payload type other than the negotiated one,
• one leg uses SRTP and the other expects RTP without correct termination,
• one device does not support the ptime or packetisation,
• the transcoder works in only one direction or the channel has incorrect read/write codecs.

In FreeSWITCH or another B2BUA, check read and write codecs separately on both channels. A single codec shown by a CDR need not describe the entire bridge.

WebRTC adds ICE, DTLS and TURN#

In WebRTC, a single c= address is insufficient. ICE candidates describe possible host, server-reflexive and relay paths. The selected candidate pair determines the actual media route. If a call works on one network but fails behind restrictive NAT, inspect TURN and its relay port range.

Analyse:

• ICE state and the selected candidate pair,
• relay candidate reachability,
• the DTLS handshake and fingerprint,
• SRTP after DTLS completes,
• TURN port compatibility with the firewall,
• differences between UDP, TCP and TLS relaying.

The detailed model is explained in WebRTC, ICE, STUN and TURN explained.

A method that shortens diagnosis#

1. Name the missing direction: A cannot hear B means B → A fails.
2. Collect SIP and RTP at as many points along the path as possible.
3. List SDP media destinations for each leg.
4. Confirm actual packet sources and destinations.
5. Check NAT, return routes and rules at every layer.
6. Verify media anchoring, bypass and renegotiation.
7. Confirm payload types, codecs and security profiles.
8. Compare a working case with a failing one.
9. Make one change and repeat the capture.

Evidence at each segment matters most. “RTP leaves the PBX” does not prove it reaches the phone. “The firewall is open” does not prove SDP advertises a reachable address. Combining signalling, packets and topology produces a credible RCA.