One-way audio on a SIP call

Get the direction right first

"A cannot hear B" means B's media is not reaching A. Half the time lost in these investigations is spent looking at the wrong stream because the fault was reported from the listener's point of view and then debugged from the sender's. Write down which endpoint is silent, invert it once, and stick to that.

What actually causes it

A private address in the SDP

The endpoint is behind NAT and advertised c=IN IP4 192.168.x.x. The far end dutifully sends RTP to an address that means something quite different on its own network, and the packets are dropped or delivered to an innocent third party. Your side hears fine; theirs hears nothing. This is the single most common cause, and it is visible in the SDP without any media analysis at all.

Latching that never happened

Most SBCs and media gateways handle the case above by ignoring the advertised address and learning the real one from the source of the first inbound RTP packet — latching, or symmetric RTP. It only works if the far end sends first. If both ends are waiting to receive before they transmit, or the far end is on hold, or an announcement server only speaks when spoken to, nothing latches and the stream stays one-way until something breaks the deadlock.

Nothing opened the pinhole

A stateful firewall or NAT lets inbound RTP through because outbound RTP created a binding for that port pair. An endpoint that receives before it sends therefore depends on a pinhole that does not exist yet. Same failure mode as latching, one layer down, and it explains why "the first two seconds are missing" and "there is no audio at all" are frequently the same bug seen at different timings.

Media anchored on one leg only

If the SBC relays media on the access leg but releases it on the core leg — direct media, media bypass, whatever the vendor calls it — then the two endpoints must have real IP connectivity to each other. Often they do not, and often it works in one direction because only one of them is behind something. Check whether the c= address the SBC advertised is the SBC's own media interface or the other endpoint's.

Direction attributes and hold

a=sendonly, a=recvonly and a=inactive mean exactly what they say, and RFC 3264 requires the answer to mirror the offer correctly. Legacy hold using c=IN IP4 0.0.0.0 still exists in the field. A box that puts a call on hold and then resumes it with an SDP the other side ignores leaves you with audio in one direction from the moment of resume — which is why "it worked until someone transferred the call" is a direction-attribute bug until proven otherwise.

Encrypted media that cannot be decrypted

With SRTP, a key or crypto-suite mismatch produces packets that arrive, fail their authentication check and get discarded. The capture looks healthy — correct addresses, correct rate, no loss — and there is still silence. If you can see RTP arriving at the receiving interface and the receiver still reports nothing, encryption is high on the list.

What to check in the trace

1. For each leg, read the c= address and the m= port out of both the offer and the answer. Those four values are the contract.
2. Count RTP packets per direction, per five-tuple. Zero packets and plenty of packets are very different diagnoses, and "some packets" (a few hundred then nothing) is a third.
3. Compare the destination of each stream with the other side's advertised c=/m=. A stream going somewhere that was never advertised is your answer.
4. Note who transmitted first, and how long after the 200 OK. Latching problems have a signature: one side starts immediately, the other never does.
5. Look for ICMP port-unreachable coming back from the media destination. It is unambiguous proof that the packets are arriving at a host that is not listening on that port.
6. Watch for a mid-call SSRC change or a sequence-number discontinuity. Those mark the moment media was re-anchored, which is usually a re-INVITE you have not read yet.
7. Check the payload types in the RTP headers against the negotiated ones, and whether the profile is RTP/AVP or RTP/SAVP.
8. Capture on both legs. A one-vantage-point capture cannot distinguish "we never sent it" from "we sent it and it was dropped downstream", and that distinction is the entire question.