One-way audio on a SIP call: causes and checks

CollabPlane engineering notes

The call connects, the timer runs, and one person hears nothing. Signaling worked. Media is being sent to the wrong place, blocked on the way, or arriving in a form the receiver cannot play.

Start with one question

Which direction is missing, and at which device does it stop? Everything else follows from that. Audio from A to B and audio from B to A are two separate streams, each with its own addresses and ports.

The usual causes

• A private address in the SDP. The c= line tells the far end where to send audio. If a device behind address translation offers its inside address to a public peer, the peer sends audio to an address it cannot reach.
• A firewall that allows one direction. Signaling ports are open but the media port range is not, or it is open outbound only.
• A SIP helper on a firewall or router. A device in the path rewrites addresses inside the SIP message and gets it partly wrong.
• No route back. The gateway can reach the phone subnet, but the phone subnet has no route to the address the gateway sends media from. Check which interface the gateway binds media to.
• Encryption on one side only. One leg expects SRTP and the other sends plain RTP, or the keys were not exchanged. Packets arrive and cannot be played.
• A hold that never ended. The last SDP exchange left the stream as sendonly or inactive.

Check in this order

1. Read the SDP on every leg. For each offer and answer, note the c= address, the m=audio port, and the direction attribute. An address the other side cannot route to ends the search.
2. Look at packet counters. On a Cisco CUBE, show call active voice brief shows transmitted and received packets for each leg. A leg that sends but receives nothing tells you which side to look at next. show voip rtp connections lists the local and remote addresses and ports in use.
3. Capture at the device. If packets arrive at the interface and the user still hears nothing, the problem is the payload: codec, payload type or encryption. If packets never arrive, the problem is upstream.
4. Move the capture point. Capture one hop closer to the sender each time until the packets appear.

A 200 OK means both sides agreed where to send audio. It does not mean audio got there.

Where Workbench helps

PCAP Analyzer lists every RTP stream with its packet count, loss and jitter, and matches each stream to the call that negotiated it. PCAP Comparison lines up captures from two points in the path so you can see where a stream stops.