Overview
Session Initiation Protocol (SIP, RFC 3261) sets up, modifies and tears down real-time sessions such as VoIP calls. From a PCAP/PCAPNG you can follow each dialog end to end: the INVITE that starts a call, the provisional responses (100 Trying, 180 Ringing, 183 Session Progress), the 200 OK and ACK that answer it, and the BYE that ends it. My Network Consultant parses every request and response and lays them out per session with their headers—Call-ID, From, To, Via, CSeq, Contact, Max-Forwards—and their SDP body, so you can see exactly where a call succeeded, stalled or failed.
- What you’ll see: requests (INVITE, REGISTER, BYE, CANCEL, ACK, OPTIONS, SUBSCRIBE, NOTIFY, …), response codes across every family (1xx/2xx/3xx/4xx/5xx/6xx), authentication challenges (401/407), busy/decline outcomes (486/603), retransmissions on UDP, and SDP media negotiation
- Best for: VoIP troubleshooting, NOC call-setup diagnosis, SOC triage, incident response, performance analysis
- Works with: UDP/TCP 5060, SIP over TLS (5061/TCP), and the related RTP media, DNS resolution (SRV/NAPTR) and TLS handshakes around a call
What to look for
- Call setup outcome: follow the INVITE dialog by Call-ID—was it answered (200 OK + ACK) or rejected (4xx/5xx/6xx)?
- Authentication challenges: a single 401/407 then a re-sent request is normal; repeated 401/407 usually means wrong or rejected credentials,
- Failure responses: 404 Not Found, 408 Request Timeout, 480 Temporarily Unavailable, 486 Busy Here, 487 Request Terminated (CANCEL), 500/503 server errors, 603 Decline,
- Registration problems: bursts of REGISTER attempts, or 423 Interval Too Brief, signalling connectivity or credential trouble,
- Retransmissions: duplicated INVITEs/responses on UDP indicate loss or an unresponsive peer (SIP retransmits because UDP is unreliable),
- SDP media mismatch: 415/488/606 or an SDP offer/answer with incompatible codecs—common cause of no-audio despite a 200 OK,
- One-way audio clues: the IP/port pairs in the SDP body point to where RTP should flow; a NAT-rewritten or unreachable address explains missing media.
Capture tips
- Capture both UDP and TCP 5060 (and 5061 for TLS) so you see whichever transport the call actually used.
- Include the RTP media streams alongside signaling to correlate a clean 200 OK with real audio flow.
- For SIP over TLS (5061), capture the TLS flow; provide keys only if policy allows deeper inspection of the signaling.
- Take a paired capture (endpoint side and proxy/SBC side) to localize where a message is lost or rewritten.
- Reproduce the failing call in a focused time window and stay within the 10 MB demo limit.
Example walkthrough
- Browse to SIP.
- Group messages by Call-ID and follow the dialog: INVITE → 100/180/183 → 200 OK → ACK, or the failure that replaced it.
- Check for authentication challenges (401/407) and confirm the request was re-sent with credentials.
- Inspect failure responses (404/408/480/486/500/503/603) to see where and why setup broke.
- Look for retransmitted INVITEs with no reply—a sign of loss or an unreachable peer on UDP.
- Open the SDP body to review codecs and media IP/ports; export the dialog as evidence for the ticket.
SIP FAQ
Requests such as INVITE, REGISTER, ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, NOTIFY, INFO, UPDATE, REFER and MESSAGE, plus responses across every family: 1xx provisional (100 Trying, 180 Ringing, 183 Session Progress), 2xx success (200 OK), 3xx redirection, 4xx client errors (401/407 auth, 403, 404, 408, 480, 486, 487), 5xx server errors (500, 503) and 6xx global failures (603 Decline, 606 Not Acceptable).
Yes. Flows on UDP or TCP port 5060 are parsed into the same per-message view. Because UDP is unreliable, SIP retransmits requests and responses, so on UDP you may see duplicated messages that the per-dialog layout groups together.
Follow the INVITE dialog by Call-ID. A missing 200 OK, a 4xx (404 Not Found, 408 Request Timeout, 480 Temporarily Unavailable, 486 Busy Here), a 5xx server error, or a 6xx (603 Decline) tells you where setup broke. Repeated 401/407 challenges point to credential problems, and retransmitted INVITEs with no reply point to loss or an unreachable peer.
Yes. When a SIP message carries a body (typically SDP), it is displayed with the message. The SDP offer and answer carry the codecs, media types and IP/port pairs used for the RTP streams, which is key to diagnosing one-way or no audio even when signaling completes with 200 OK.