One-way audio: the usual suspects

The call connects, one party hears the other, and the other hears silence. Signalling clearly worked — the call was established — so the fault is in the media path only. That narrows things immediately.

NAT and the address in the SDP

The most common cause by a wide margin. A phone behind NAT advertises its private address in the SDP as where audio should be sent. The far end dutifully sends audio to 192.168.x.x, which is unreachable from where it sits.

Audio flows one way — from the private side outward — because that direction opens the NAT mapping. The other direction has nowhere to go.

The fix is something that rewrites the SDP: a session border controller, a SIP-aware ALG, or the phone being configured with its public address. Read the SDP in a capture and the problem is visible directly.

RTP ports not permitted

Firewalls get a rule for SIP on 5060 and nothing for RTP, which uses a wide dynamic range — commonly 10000-20000 UDP. Signalling passes, media does not. The rule that permits the media is often assumed rather than checked.

Asymmetric routing

If audio takes different paths in each direction and a stateful device sits in one of them, the direction without established state is dropped.

Half-open firewall state

UDP has no handshake, so firewalls infer sessions from the first packet outward. If the far end sends first, there may be no state permitting it.

Working it

# does audio arrive at all?
tcpdump -ni eth0 udp portrange 10000-20000 and host <far end>
# what did each side advertise?
sngrep          # inspect the SDP in INVITE and 200 OK

Determine first whether RTP is arriving at the silent end. If it is arriving and not being played, the problem is the device or the codec. If it is not arriving, follow it backwards — and check what address was advertised, because that is where it was sent.