SIP call flow for troubleshooting

SIP is readable text, which makes it far easier to troubleshoot than most protocols. You do not need to know it comprehensively. You need to recognise where a failing call stopped, because the stopping point names the problem.

The normal exchange

INVITE from caller. 100 Trying — received, working on it. 180 Ringing — the far end is alerting. 200 OK — answered. ACK — confirmed. Then RTP carries the audio, and BYE ends it.

Note that the audio path is separate from the signalling path. That separation is the source of the most common voice fault there is.

Reading the failure point

No response to INVITE — it is not arriving. Routing, firewall, or the wrong destination.

403 Forbidden — arrived and was refused. Authentication or policy.

404 Not Found — the far end does not recognise the number. A dial plan problem, usually digit manipulation.

408 or 480 — no answer or unavailable. Often the destination device is not registered.

488 Not Acceptable Here — no common codec. The two ends could not agree.

Call connects, no audio — signalling worked, RTP did not. This is the classic, and it is nearly always NAT or a firewall permitting SIP and not the RTP range.

Capturing it

tcpdump -ni eth0 -s 0 port 5060 -w /tmp/sip.pcap
sngrep                                   # live, readable ladder diagram
# Wireshark: Telephony > VoIP Calls > Flow Sequence

sngrep is worth installing wherever you handle SIP. It renders live call flows as ladder diagrams and turns this from an exercise in reading text into something you can see.

The SDP body

Inside INVITE and 200 OK is a session description stating the IP address and port where each side expects audio. When a call has no audio, read those. If a device has advertised a private address across a NAT boundary, the other end is sending audio somewhere unreachable — and the SDP says so explicitly.