One-Way Audio: A Structured Diagnosis Tree

Few VoIP symptoms produce as much wasted time as one-way audio. The call rings, both sides answer, the signalling looks clean, and yet only one party can hear the other. Engineers reach for "it must be NAT" and start chasing pinholes. Sometimes that is right. Often it is not. One-way audio has at least six distinct root causes, each with its own fingerprint in the trace, and each requiring a different fix. Treating "one-way audio" as a single failure mode is the reason these tickets sit open for days.

This post is a structured diagnosis tree. We will walk the six causes in roughly the order you should check them, give each a PCAP fingerprint you can verify in Wireshark or tshark, and finish with a single-page decision tree you can pin above your desk.

A note on scope: we are talking about an established call (200 OK, ACK, and RTP starting on both legs) where audio fails in one direction. We are not covering "no audio at all" (codec mismatch, missing SDP answer, port-zero rejection, total media-plane failure) or "audio quality" problems (packet loss, jitter, codec quality). Those are separate trees. One-way audio specifically means: media flowing in one direction, none in the reverse.

What the trace can tell you in 30 seconds

Before walking the six causes, three Wireshark moves let you triage most one-way audio tickets in well under a minute. Make them muscle memory.

First, open the capture, go to Telephony → RTP → RTP Streams. Wireshark will list every distinct RTP stream by source IP, destination IP, SSRC, and packet count. A normal bidirectional call shows two streams of roughly equal packet count (typically 50 packets/s × call duration for G.711 at ptime=20). A one-way call shows either two streams with very different packet counts, or only one stream at all. That distinction alone splits the six causes into two families: "RTP is being sent in both directions but one side is dropping it" versus "RTP is only being sent in one direction in the first place."

Second, with the streams listed, click Analyze to see the per-direction packet counts, jitter, and loss. If both directions show comparable counts but only one side hears audio, the failure is downstream of the RTP arrival, not in the transit path. That points to the receiving endpoint or its decoder, often a codec or SRTP issue.

Third, in any capture point along the path, filter rtp and look at the source and destination IPs. If the SDP told both sides to send to a public IP that is not present in the actual RTP source field, you have an SDP-versus-reality mismatch. This is the NAT family of failures, and a paired capture (one on each side of the NAT or SBC) will confirm where the address rewriting broke.

These three moves orient you. Now to the six causes.

Cause 1: NAT pinhole asymmetry

This is the textbook case. The caller is behind a NAT (home router, enterprise firewall, cellular CG-NAT). The SIP signalling has been rewritten correctly (by the device's STUN, by RFC 5626 outbound, or by an SBC) so the SDP c= and m= fields advertise a public address and port that the remote peer can reach. The remote peer starts sending RTP to that public address. Audio flows from the remote side to the NATed caller.

The reverse direction fails because the NAT only created an outbound mapping for ports the NATed caller actually sent from. If the SDP advertises port 8000 but the caller's local RTP socket is bound to 9000 (and the SBC or STUN was supposed to learn and rewrite that), the NAT's outbound mapping is for 9000, and inbound RTP to 8000 has no entry to translate. The remote side's audio hits the NAT and is dropped.

Symmetric NAT is the harder variant. The NAT mapping is per destination, not per local port. The caller sends a STUN binding request, learns its public mapping for that destination, advertises it in SDP, but the remote peer's RTP traffic arrives from a different source IP than the STUN server. The NAT treats it as a new flow with no inbound state and drops it.

The fingerprint in a PCAP taken on the public side of the NAT (or on the SBC's external interface) is unmistakable: you see RTP arriving inbound, destined for the address the SDP advertised, but nothing leaves outbound from that same address. Or you see outbound RTP leaving from a different source port than the SDP advertised. The NAT is doing its job; the SDP just does not match what the NAT actually mapped.

The fix is one of three: - Force the SBC to anchor media (turn off SDP-only-rewrite). The SBC's external interface becomes the source and destination for both peers, and NAT becomes the SBC's problem to solve symmetrically. - Force the endpoint to use ICE with TURN (RFC 8656). The endpoint discovers it is behind a symmetric NAT and falls back to a TURN relay, which is reachable from any source IP. - Force the endpoint to use RFC 5626 outbound with a keep-alive (CRLF-CRLF on TCP, double-CRLF or short STUN on UDP, sent every 25-30 seconds to keep the UDP NAT mapping alive).

The SBC-anchored option is by far the most common in production. It removes the NAT problem from the endpoint and puts it on a device that can solve it correctly.

Cause 2: SDP address or port mismatch

This is the cause that looks like cause 1 in symptoms but has a different root. The SDP itself is wrong, irrespective of any NAT. The c= line advertises an address the peer cannot reach (a private RFC 1918 address leaked into a public SDP, an IPv6 address sent to a peer that only routes IPv4, a stale address from a previous session that did not get rewritten on a re-INVITE), or the m= line advertises a port that is not open on the receiving host.

The mechanism by which a private address ends up in a public SDP is usually one of three failure modes: - The endpoint did not do STUN or did not believe its STUN result, and put its local IP in c=. The remote side reads c=10.0.0.5 and sends RTP into the void. - An SBC failed to rewrite c= on the answering side because of a misconfiguration (the SBC's per-interface NAT-aware rewrite was turned off for this realm, or a transparent-proxy mode was selected). - A re-INVITE during the call carried a c= from a different network context (call moved between interfaces on the endpoint, the endpoint did not refresh its STUN learning).

The PCAP fingerprint is clear once you read the SDP carefully. Take the SDP c= and m= lines from both the offer and the answer. Compare them to the actual source IP and port of the RTP packets each side is producing. If they do not match, you have an SDP-versus-reality problem. The Telephony → RTP → RTP Streams view will show the actual RTP source and destination; the SIP filter or the sip.sdp filter will show what the SDP advertised. A side-by-side comparison takes 30 seconds.

The IPv4/IPv6 variant is sneakier. If the offer has c=IN IP6 2001:db8::5 and the answerer's network only routes IPv4, the answer might still complete (SIP does not validate IP-version compatibility automatically), and RTP simply never flows from the answerer to the offerer. The opposite direction works because the offer advertised IPv4 in its second m= line for fallback, but the answer ignored it. You see one-way audio in the IPv6-only-advertised direction.

The fix is to make the SDP match reality. For endpoints, that usually means turning on STUN and trusting the result. For SBCs, it means making sure NAT-aware rewrite is enabled on every interface that touches an untrusted network. For re-INVITEs, it means making sure the endpoint refreshes its address learning before regenerating SDP.

Cause 3: SRTP keying asymmetry

This is the cause that catches people who have just rolled out SRTP for the first time. The signalling looks clean. Both sides offered RTP/SAVP with a=crypto lines. The 200 OK acknowledged the chosen crypto suite. The call rings, both sides hear ringback (which is in-band on the signalling channel, not RTP), and after answer, audio flows in one direction only.

What has actually happened is that one side is encrypting its outbound RTP with the master key advertised in its offer, and the other side is decrypting incoming RTP with the master key it received in the answer. These keys are in opposite SDP messages by RFC 4568 design: the offerer's a=crypto advertises the key that the offerer's outbound uses, and the answerer's a=crypto advertises the key that the answerer's outbound uses. If an SBC sits in the middle and decrypts-and-re-encrypts (as it must, per RFC 3711 §3.2.2 and the SIPT-202 lesson 3.5 SBC-sees-plaintext-SRTP rule), it must rewrite both a=crypto lines on egress: the access leg uses one keypair, the core leg another.

The asymmetric failure happens when the SBC rewrites one direction's a=crypto correctly but not the other. The leg with the unrewritten a=crypto carries a key that the receiving side believes is the offerer's, but the receiving side actually receives ciphertext encrypted with a different key. The auth tag fails, the SRTP packet is dropped, and that direction goes silent. The other direction works because its key was rewritten correctly.

The PCAP fingerprint is more subtle than the NAT cases. You will see RTP arriving on both legs in roughly the right packet counts. You will not see audio. The Wireshark SRTP filter will not decrypt the packets in the failing direction (because Wireshark is using the SDP-advertised key, which is the wrong key). The endpoint's SRTP statistics, if you can get them, will show "auth tag failures" or "decryption failures" on one side and zero on the other.

The fix is to verify the SBC's SDES key rewriting is enabled and correct on both legs. The simpler verification is to look at the four a=crypto lines (offer-access-leg, answer-access-leg, offer-core-leg, answer-core-leg) and confirm all four base64-encoded inline keys are distinct. If two of them are identical, the SBC has copied a key instead of regenerating one, and that is the leg that fails. The same fingerprint appears with DTLS-SRTP if the SBC fails to terminate DTLS on one leg and re-handshake on the other (RFCs 5763, 5764, 8122).

The cause is also worth checking before reaching for it. RFC 8723 (Double SRTP) and end-to-end media encryption protocols deliberately keep the SBC unable to decrypt, but those are operator-policy choices that should be documented. If you do not believe you have deployed Double SRTP and the SBC is showing decrypt failures, the cause is misconfiguration, not policy.

Cause 4: Asymmetric routing without media anchoring

This cause is common in carrier interconnect and unusual in enterprise. Two SBCs sit in the path, each with its own routing decision, and the media path takes one route in one direction and a different route in the reverse. If only one of those routes is correctly configured (the other has a stale ACL, a misconfigured next-hop, or a firewall blocking RTP), audio works one way and fails the other.

This cause is unique among the six because the SBCs are doing what they were told: signalling SBC is anchoring signalling but the media flows direct between endpoints (SDP-only-rewrite mode, per SIPT-202 lesson 4.2 conditions). If the network between the endpoints is asymmetric in some way (BGP path selection chose different return paths, a SD-WAN policy treats inbound and outbound differently, a stateful firewall sees one direction as "new" because the outbound was not observed), then the asymmetry produces one-way audio.

The PCAP fingerprint requires captures at both endpoints and ideally a transit point in the middle. The endpoint capture on the speaking-but-not-being-heard side shows RTP leaving outbound, with the source and destination addresses matching SDP. The receiving endpoint capture shows no RTP arriving. The transit capture, if you can get one, shows the RTP entering the transit network but not exiting, meaning the asymmetry is somewhere in the network between the two endpoints, not at the endpoints themselves.

The fix in carrier environments is usually to force media anchoring at one of the SBCs in the path. Once the SBC is the source and destination for the RTP, the network sees a symmetric flow with a single pair of addresses, and the asymmetric routing problem disappears. This is one of the operational reasons SBCs exist (the policy enforcement and media anchoring reason from the canonical four-reasons taxonomy taught in SIPT-202 lesson 1.1).

The fix in enterprise environments is usually to fix the firewall ACL or the SD-WAN policy. Asymmetric routing in an enterprise is almost always a misconfiguration, not a deliberate policy. Find the stateful firewall that is dropping the return RTP because it never saw the outbound, and either widen the ACL or force the path symmetric.

Cause 5: Firewall or ACL dropping RTP in one direction

This cause looks like cause 1 (NAT asymmetry) but has nothing to do with NAT. The firewall is doing exactly what its ruleset says: permitting outbound RTP from the inside to the outside, but its rule for the reverse direction is either missing, misconfigured, or matching on the wrong tuple.

The most common variant in production: the firewall has a rule "permit RTP outbound from internal subnet to any" but no corresponding inbound rule for "permit RTP inbound from any to internal subnet on the dynamic port range." The outbound rule installs a stateful entry, but the entry expires (typical UDP idle timeout 30-60 seconds) before the call answers and starts producing media in the reverse direction, or the entry's destination port mask does not match the actual port the remote side is sending to.

The second variant: the firewall rule matches on the wrong protocol or port range. RTP is UDP on a port range typically 10000-20000 (default ranges vary by vendor: Cisco 16384-32767, Sonus/Ribbon 49152-65535, OpenSIPS RTPproxy 35000-65000). If the firewall rule was written for 10000-20000 but the SBC actually uses 49152-65535, half the calls work and half do not, depending on which port range each call's SDP m= happens to land in.

The third variant is the most insidious: the firewall is a deep-packet-inspection firewall that is "SIP-aware" and is rewriting SDP on the fly. These firewalls (often a feature of consumer-grade enterprise routers and some UTM appliances) attempt to be helpful by rewriting SDP c= and m= to use the firewall's address. They do this incorrectly often enough that they are a primary cause of one-way audio in small-business deployments. The fix is to turn off the SIP ALG on the firewall (every major vendor has a setting for this, usually called SIP ALG, SIP inspection, or Application-Layer Gateway).

The PCAP fingerprint of a firewall drop is the same as cause 1 in symptoms but distinguishable by location. A capture on the inside of the firewall shows RTP leaving and (in the cause 5 case) RTP also arriving inbound. A capture on the outside of the firewall shows RTP leaving in one direction but not entering in the other. If the inbound packets are missing on the outside-of-firewall capture but present on the inside (because the firewall's NAT translated them), you have a firewall drop. If the inbound packets are missing on both captures, the network path is asymmetric and you have cause 4.

The fix is to fix the firewall rule. The SIP ALG case is almost always fixed by disabling SIP ALG (it is rarely needed when an SBC is in the path; it is actively harmful when the SBC is also doing SDP rewriting). The dynamic-port-range case is fixed by aligning the firewall rule with the actual SBC port range.

Cause 6: Codec, payload-type, or transcoding asymmetry

This is the least common cause but the trickiest to spot when it happens. Both sides are sending RTP. Both sides are receiving RTP. The receiver simply cannot decode the audio because the payload type does not match the codec the SDP negotiated, or because a transcoding stage in the middle has produced output the receiver cannot consume.

The most common variant: dynamic payload-type mismatch across an SBC's two legs (per the RFC 3264 §6.1 dynamic-PT asymmetry discipline, which allows each leg to choose its own dynamic-PT mapping for the same codec). The access-side endpoint says "PT 96 is Opus 48000/2." The core-side endpoint, going through the SBC's per-leg SDP rewriting, says "PT 100 is Opus 48000/2." If the SBC anchors media and forwards RTP with the wrong PT in the header (because the SBC's PT-rewriting was not turned on for this codec), the receiver's RTP stack looks up PT 96 in its local table, finds nothing (because its local table maps Opus to PT 100), and discards the packet as unknown payload type.

The audio direction that fails is the one where the SBC failed to rewrite the PT. The other direction may work because its PT happened to match by coincidence or because the SBC's rewriting was correct on that side. From the outside, this looks like one-way audio.

The second variant: transcoding stage failure. The SBC was supposed to transcode G.711 to G.729 on one leg, but the transcoder is overloaded (DSP saturated, software transcoder out of CPU) or misconfigured (PCMU on one side, PCMA on the other, transcoding rule expected PCMU on both). The output is silence or noise, but the RTP packets keep arriving at the right rate. The endpoint plays silence. The other direction may work because the transcoder is healthy on that side.

The PCAP fingerprint is unique to this family of causes. The RTP packet counts on both directions are roughly equal. The packet sizes look right for the codec the SDP negotiated. The IP addresses and ports match the SDP. Nothing visibly wrong. The only signal is in the RTP header's payload type field, or in the audio waveform after decode. Wireshark's Telephony → RTP → RTP Streams → Analyze → Play Streams will play the audio. If one direction plays as silence, static, or distorted speech while the SDP and signalling look clean, you have cause 6.

The fix is at the SBC. For PT-rewriting failures: turn on dynamic PT rewriting on the affected leg, or align the dynamic-PT maps so the SBC does not need to rewrite. For transcoder failures: check the SBC's transcoding queue depth, DSP utilization, and the transcoding policy configuration. Transcoding failures often correlate with peak-hour traffic and resolve themselves when load drops, which makes them frustrating to reproduce.

The decision tree

Walk these in order. Most one-way audio tickets resolve within three steps.

Step 1: Look at the RTP Streams view in Wireshark.

If you see one stream (one direction only), the failure is upstream of the RTP arrival on the silent side. Go to step 2.

If you see two streams of roughly equal packet count, the failure is at the receiving endpoint or in a transcoding/keying stage. Go to step 4.

If you see two streams but one is dramatically smaller (or has stopped after the first few packets), go to step 3.

Step 2: Compare the SDP c=/m= to the actual RTP source and destination.

If the SDP advertised address does not match the RTP source on the silent direction (an RFC 1918 address leaked into a public SDP, an IPv6 address sent to an IPv4-only peer, a stale address from a re-INVITE), the cause is SDP mismatch (cause 2). Fix the address rewriting.

If the SDP advertised address matches and the destination is a NAT, the cause is NAT pinhole asymmetry (cause 1). Force SBC anchoring or enable ICE/TURN.

If the SDP advertised address matches and the destination is not behind NAT, the cause is firewall ACL or asymmetric routing (cause 5 or 4). Take captures at intermediate points to identify where the RTP is dropped.

Step 3: A direction started flowing and then stopped.

If RTP stopped after a fixed interval (commonly 30 or 60 seconds), the cause is firewall state expiry (a stateful firewall closed the inbound flow because the outbound stopped or never matched). This is a variant of cause 5. Fix the firewall.

If RTP stopped after a re-INVITE, the cause is an address change in the re-INVITE SDP that the SBC did not propagate. This is a variant of cause 2 surfacing mid-call. Check the re-INVITE SDP and the SBC's mid-call rewriting policy.

Step 4: Both directions have RTP but only one direction has audio.

If the endpoint reports "auth tag failures" or "decrypt failures" on the silent side, the cause is SRTP keying asymmetry (cause 3). Audit the four a=crypto lines or the DTLS-SRTP fingerprint exchange.

If the endpoint plays the silent direction's RTP and you hear silence or distortion (not nothing), the cause is codec, payload-type, or transcoding asymmetry (cause 6). Check PT rewriting and transcoder health.

That tree resolves the overwhelming majority of one-way audio tickets. The remaining edge cases (RTP injected by a third party, intentional silence suppression on one side, codec packing-rate asymmetry across a transcoder) are rare enough that walking the tree first will identify them by exclusion.

Why this matters operationally

Two engineers can spend a full day on a one-way audio ticket if they start with the wrong cause. The traditional first guess is NAT, because NAT is the cause people remember. Often the actual cause is cause 5 (firewall ACL) or cause 3 (SRTP keying), and the diagnostic effort spent on NAT is wasted. The structured tree above is the discipline of checking the easy-to-verify causes first rather than guessing.

The other operational lesson is paired captures. A single capture at one endpoint can identify some causes (cause 1's missing-mapping fingerprint, cause 2's SDP-vs-reality mismatch, cause 6's PT-mismatch). It cannot identify other causes (cause 4's network asymmetry, cause 5's firewall drop) without a second capture point to compare against. If your operations team is not already taking paired captures (one on each side of the SBC, or one on each side of the suspect firewall) as a default practice for media tickets, that is the most impactful single change you can make. The SIPT-202 course covers paired-capture analysis in depth across multiple labs because the technique is the highest-leverage diagnostic skill in voice engineering.

If you want a deeper treatment of these causes at protocol level, the SIP Train SIPT-101 course covers SDP, the offer-answer model (RFC 3264), and NAT-traversal mechanics in detail. SIPT-201 covers RTP, RTCP, and SRTP including the key-exchange mechanics that cause 3 hinges on. SIPT-202 covers SBC media anchoring, transcoding, and the operational discipline of paired-capture analysis end-to-end. Vendor-neutral, RFC-grounded, and built around the kind of trace you see on real production calls.

---

This post is part of the SIP Train Week 2 troubleshooting series. Previous Week-2 posts: "The Top 10 SIP Failure Modes and the Fingerprint Each Leaves in a Trace" (2026-05-04) and "SIP Over UDP, TCP, or TLS: The 1300-Byte Rule and What Fragmentation Actually Costs You" (2026-05-18). Next Week-2 post topic: reading a SIP ladder diagram (planned for 2026-07-13).