How to Read a SIP Trace: A Practical Guide

A SIP trace is the only honest record of what your voice network actually did. CDRs lie by omission, dashboards lag, and end-user reports are second-hand. The trace is first-hand, byte-for-byte. Yet most engineers open one and stare at 8,000 lines of UDP traffic for half an hour before finding the message that explains the failure, when a methodical reader gets there in three minutes.

This guide is a practitioner workflow, not a protocol reference. It assumes you already know what an INVITE is and what a 486 means. If you do not, the companion piece SIP Call Flow Explained Step by Step walks every message in a typical call, and SIP Response Codes: The Complete Guide covers each code in detail. What this article covers is everything that happens between “open the capture” and “I found the root cause”: where traces come from, the tools that make them readable, the four-step method that gets you to the decisive message fast, the patterns to recognise first, and how to package what you find into a ticket a carrier will actually act on.

What a SIP Trace Actually Is

The phrase “SIP trace” gets used for three different things, and confusing them wastes the most time at the start of an investigation. A full PCAP is every byte on the wire, including TCP/UDP headers, RTP, RTCP, and anything else sharing the same interface; it is what tcpdump and Wireshark produce. A SIP-only trace is the same data filtered down to the SIP messages, often stored as a HEP stream into a central database, captured by an SBC’s internal logger, or exported from Wireshark with the non-SIP frames stripped. A SIP log is a textual rendering an application produced from its own SIP stack, typically with timestamps and decoded headers but not the underlying packets; useful for state but not for protocol-level pathology.

For most failures, the SIP-only trace is the right artefact: it captures every signaling message, lets you correlate across legs, and avoids the size penalty of audio packets. For media problems (one-way audio, choppy speech, missing in-band DTMF), you need the full PCAP because that is the only place the RTP actually lives. For “I cannot tell what the SBC did,” the SBC’s own internal trace is unbeatable, because it shows the message as the SBC received it on one leg, the modifications applied in the middle, and the message as it left on the other leg, all in one file.

The corollary is that when someone hands you a trace and asks you to look at it, the first question is “what kind of trace, and from where on the path?” A SIP-only export from a softswitch will never show you a missing RTP problem, no matter how long you stare at it.

Where to Capture, and With What

Picking the capture point matters more than picking the tool. Capture where the problem is suspected, not where it is convenient. If the carrier insists the call left their network cleanly, capture on the SBC’s carrier-facing interface and prove the message that arrived. If a Teams Direct Routing call is failing on the ringback, capture on the Teams-facing leg of the SBC and look at what Teams sent.

On Linux, tcpdump is the default capture engine and writes PCAPs that any tool can read. A typical command for a busy SBC is tcpdump -i any -s 0 -w trace.pcap, which captures both UDP and TLS SIP plus the RTP range the SBC is configured to use. The -s 0 flag disables snaplen truncation so full packets are written; without it, a 1500-byte INVITE gets clipped at 96 bytes and the body is missing. On the SBC itself, native capture is almost always preferable: it sees the message at the application layer, not just the wire, which means encrypted SIP is already decrypted and B2BUA leg correlation is automatic.

Wireshark is the GUI standard, and despite the steep learning curve it is the most powerful viewer once you know three menus. sngrep is the right tool when you only have SSH and a terminal; its ncurses interface shows live SIP traffic and ladder diagrams without needing to copy a PCAP back to your laptop. HOMER is the right answer for retention and search across an estate: every SBC and proxy ships SIP via HEP to a central capture node, and a single web UI lets you find a call from yesterday by phone number, IP, or Call-ID. ProSBC ships with a built-in SIP trace, a live Wireshark capture feature, and MOS scoring per call, so the SBC itself is the capture point of first resort for any call that touched it.

The Four-Step Reading Workflow

Every productive trace-reading session follows the same four steps in the same order. Skipping a step usually leaves you guessing.

Step 1: Scope to the one dialog you care about

A typical SBC PCAP from a five-minute window can contain hundreds of dialogs. Trying to read the file end-to-end is the most common mistake. Filter aggressively. If you have the Call-ID, filter on it directly: in Wireshark, sip.Call-ID == "a84b4c76e66710@192.0.2.10". If you only have a phone number, sip.from contains "+15145551234" or sip.to contains "+15145551234" will land you within a few seconds of the call. Once you have one packet from the dialog, right-click and “Follow” the SIP conversation to pull the whole exchange into its own window.

If the call traversed a B2BUA, this step gives you only one leg. The companion leg has a different Call-ID. You can find it by matching the two on time and on phone number, or on the Contact header the SBC inserted, or by looking inside the SBC’s own trace where the relationship is recorded explicitly.

Step 2: Classify the failure phase

Before reading any message in detail, decide which phase of the call broke. The three options are setup (anything from the initial INVITE up to the final ACK confirming the connection), mid-call (after the media session is fully established but before an intentional hang up), and teardown (BYE and its response). Setup failures are by far the most common, and the ladder diagram tells you the phase at a glance: if you never see a 200 OK to the INVITE, you are in setup; if you see 200 OK followed by RTP and then a BYE earlier than expected, you are in mid-call; if BYE happens at the right time but the call counts as failed in the CDR, you are in teardown or post-call accounting.

Step 3: Read the decisive header or code

Setup failures resolve on one of three things almost every time: the final response code, the SDP body of the 200 OK (or its absence), and the authentication headers in any 401 or 407. A 488 Not Acceptable Here points you at the SDP; a second consecutive 401 or 407 response or a 407 followed by no second INVITE at all points to an authentication or credential mismatch; a 408 with no provisional response at all points at transport. Mid-call failures resolve on the BYE’s Reason header or its absence, the RTP timing, and any re-INVITEs in between. Teardown failures are unusual; when they happen, the CSeq numbering and the From/To tags will tell you whether you are looking at the same dialog the CDR thinks closed.

Step 4: Confirm in the media if needed

If the trace says the call connected but the user heard nothing, the SIP signaling is innocent and the RTP is guilty. Open Telephony → RTP → Stream Analysis in Wireshark, select the stream for the leg in question, and look at the packet count, jitter, and delta. Zero packets received with non-zero packets sent is one-way audio caused by a NAT problem. Steady packets with bursts of 60ms+ delta is jitter caused by buffering somewhere upstream. A stream that runs for two seconds and then stops is a media gateway that crashed mid-call. The signaling looks fine in all three cases.

Wireshark in Practice

Three menus carry almost all of the analytical weight: VoIP Calls, Flow Sequence, and the display filter bar. Everything else is decoration.

Telephony → VoIP Calls scans the capture for SIP and H.323 dialogs and lists them in a table with start time, duration, status, and codec. This is the first place to go on any new PCAP because it tells you in five seconds how many calls are in the file, which ones succeeded, and which ones failed. Selecting a call and clicking “Flow Sequence” generates a ladder diagram showing every SIP message and RTP stream in chronological order, with timestamps and arrow direction. This view alone resolves the majority of “what happened during this call” questions.

The display filter is the lever that turns 8,000-packet captures into 30-packet captures. The filters that earn their keep:

• sip shows only SIP packets.
• sip.Call-ID == "..." isolates one dialog.
• sip.Method == "INVITE" lists every call attempt in the file.
• sip.Status-Code >= 400 lists every failure.
• rtp shows only RTP packets; rtcp shows the quality reports.
• tcp.analysis.retransmission reveals TCP retransmissions when SIP runs over TCP.
• frame.time >= "2026-05-25 14:30:00" slices by absolute time when you know roughly when the failure happened.

For RTP analysis, Telephony → RTP → RTP Streams lists every audio stream Wireshark detected, with packet count, jitter, lost packets, and MOS estimates derived from those metrics. Right-clicking a stream and choosing “Analyze” gives you the per-packet jitter and delta values; “Play Streams” decodes the audio when the codec is G.711, which is the fastest way to confirm whether the audio that arrived was actually intelligible.

sngrep When You Only Have a Terminal

When the only thing between you and the SBC is an SSH session, sngrep is the right tool. Run sngrep with no arguments and it captures live SIP from all interfaces; run sngrep -I trace.pcap and it opens a previously captured file. The interface shows a list of dialogs at the top, a ladder diagram for the selected dialog at the bottom, and lets you press Enter on any message to see the full headers. The whole workflow above (scope, classify, decide on the deciding header) works inside sngrep just as well as in Wireshark, and the latency advantage of working directly on the SBC is meaningful when the alternative is copying a multi-gigabyte PCAP across a WAN.

The one limitation is media. sngrep is signaling-only, so when an RTP investigation is needed, you still have to fall back to a PCAP. Most production workflows use both: sngrep for quick triage on the SBC, Wireshark for deeper analysis once a specific call has been identified.

Five Patterns to Recognise Before Reading Headers

Most production failures match one of five trace signatures. Recognising the signature first saves the time you would otherwise spend reading every header in sequence.

The retransmission storm appears as repeated identical SIP requests with the same branch parameter and increasing time gaps (500ms, 1000ms, 2000ms, 4000ms, 8000ms, 16000ms, 32000ms before Timer B fires). It means the next hop never sent a provisional response. Either the next hop is down, or a firewall is silently dropping the request, or the next hop received it but cannot route it.

The Timer B drop at 32 seconds is the consequence of the retransmission storm. The originating user agent gives up exactly 32 seconds after the first INVITE and returns 408 Request Timeout to the application. Calls that “ring for 32 seconds and then fail” without ever hitting the called endpoint are nearly always this pattern.

The authentication loop appears as INVITE, 401 Unauthorized (or 407 Proxy Authentication Required), second INVITE with an Authorization header, followed immediately by a second consecutive 401 or 407 response. The recipient is rejecting the digest credential. Almost always a mismatched realm string between the SBC and the upstream provider, or a clock skew that invalidates the nonce.

The codec mismatch appears as INVITE with an SDP offer listing several codecs, 488 Not Acceptable Here, no media. The two sides could not agree on a codec. Either the SDP offer lists codecs the recipient does not support, or the recipient is configured to only accept a codec the originator did not offer. A properly configured SBC’s transcoding capability hides this problem from both sides.

The one-way audio with clean signaling appears as a complete INVITE-200-ACK sequence, RTP flowing in one direction, no RTP in the other, and a BYE 30 to 90 seconds later when one side gives up. The SIP trace is innocent. The cause is almost always a NAT problem in the SDP c= line, an asymmetric firewall, or a media path that never actually opened on one side.

Encrypted Traces and the Key-Log File

A call running over TLS on port 5061 is not readable in Wireshark without decryption keys. There are three ways to recover readability. The first is to capture on an SBC that decrypts the SIP at the application layer, which makes encryption invisible to the trace tool. The second is to capture on the wire and decrypt later using a TLS key-log file, set via the SSLKEYLOGFILE environment variable on a client that supports it; Wireshark reads the log under Preferences → Protocols → TLS → “Pre-Master-Secret log filename”. The third is to inspect the unencrypted intermediate point on a B2BUA SBC, which terminates TLS on ingress and may re-originate TLS on egress; the trace from the SBC’s internal logger sees the cleartext in between.

SRTP follows the same principle. The key exchange happens either in the SDP body (SDES, where the master key is embedded in plain text inside the SIP message) or over DTLS-SRTP on the media path. With SDES, an unencrypted SIP trace plus the corresponding RTP capture gives you everything you need to decode the audio. With DTLS-SRTP, no key log means no decode, and the SBC’s internal capture is again the path of least resistance.

The B2BUA Gotcha: One Call, Two Traces

A B2BUA SBC splits a single call into two completely independent SIP dialogs. The ingress leg has its own Call-ID, From-tag, To-tag, CSeq counter, and Via chain; the egress leg has different values for every one of those fields. To Wireshark, the two legs are unrelated dialogs that happen to share a time window and a phone number.

Reading a B2BUA trace correctly means correlating the legs explicitly. The signals that link them are the Contact header the SBC inserts (the same SBC address appears on both legs), the timing (the second leg’s INVITE always follows the first leg’s INVITE within a few milliseconds), and the phone numbers in the From and To URIs. The cleanest source of correlation, when available, is the SBC’s own log, which records the ingress and egress Call-IDs side by side and dumps both legs into a single trace file. A capture taken on either leg in isolation will mislead any investigator unfamiliar with the architecture, because half the call appears to be missing.

The same principle applies to SIP header manipulation: a header that exists on the ingress leg may have been rewritten, added, or removed before it appears on the egress leg. If a downstream system claims it never received a header you can see in the ingress trace, the egress trace is the one that settles the argument.

Packaging Evidence for a Carrier Ticket

Half the time spent on a SIP trace is for someone else: the carrier opening a P2 ticket, the platform vendor’s support team, the firewall admin who needs proof their device is dropping traffic. The format of the evidence determines whether the ticket gets actioned today or sits in a queue for a week.

The right artefact is a filtered PCAP containing only the dialog in question. In Wireshark, the workflow is File → Export Specified Packets, with “Marked packets only” or “Displayed packets” selected after a display filter has reduced the view to the one Call-ID. The resulting file is typically a few hundred kilobytes, opens cleanly in any SIP-aware tool, and contains nothing the recipient does not need.

A good ticket attachment includes three things. First, the PCAP filtered to one dialog. Second, a plain-text annotation naming the suspected hop, the suspected message, and the suspected behaviour, in the form “INVITE at packet 47 contains codec G.729 in the SDP; the 488 response at packet 49 indicates the carrier did not accept it; please confirm whether G.729 is supported on this trunk.” Third, the time, time zone, and CDR ID of the call, so the recipient can correlate against their own logs without guessing.

Anonymise where appropriate. Phone numbers and IP addresses in real customer traces are routinely regulated data, and a PCAP forwarded to a third party carries everything the original capture saw. Tools like tcprewrite and Wireshark’s own anonymisation plugins can replace numbers and addresses without breaking the SIP message structure.

Frequently Asked Questions

Conclusion

Reading a SIP trace is mostly about scoping aggressively, classifying the failure phase before reading any headers, and recognising the five common signatures so the deciding message is the third or fourth one you look at, not the four hundredth. The tool you use matters less than the discipline of the workflow. Wireshark on a workstation, sngrep on an SBC, the SBC’s own built-in trace, and a central HOMER deployment for retention all read the same underlying data, and a confident operator moves between them depending on whether the immediate question is about media, signaling, history, or vendor-side dispute.