sngrep: The SIP Troubleshooting Tool You Should Know

If you work with VoIP, and more specifically SIP long enough, eventually you find yourself staring at an INVITE, a handful of provisional responses, several IP addresses, a 200 OK, an ACK, and perhaps a BYE—and trying to mentally reconstruct what actually happened.

Wireshark can certainly do this. In fact, Wireshark remains one of the most powerful tools available for detailed VoIP packet analysis. When you combine Wireshark with our VoIP profiles – well you are in VoIP nirvana.

But sometimes Wireshark is more tool than you need.

This is where sngrep fits very nicely.

sngrep is an open-source terminal application specifically designed to capture and display SIP signaling. Rather than presenting you with individual packets, it groups SIP messages by Call-ID and displays the signaling as a call-flow or ladder diagram.

In other words, it lets you go from this:

INVITE
100 Trying
183 Session Progress
PRACK
200 OK
UPDATE
200 OK
200 OK
ACK
BYE
200 OK

to a visual sequence showing who sent each message, who received it, and in what order.

For someone troubleshooting VoIP, that can save a tremendous amount of time.

The official project describes sngrep as a terminal-based SIP message flow viewer supporting live captures as well as existing PCAP files. Current versions recognize SIP over UDP and TCP and provide partial TLS support when the necessary cryptographic support is available.

Installing sngrep

On Debian or Ubuntu, installation is generally as simple as (this includes WSL – see details on WSL below):

sudo apt update
sudo apt install sngrep

macOS users with Homebrew can install it with:

brew install sngrep

Irontec also documents packages or installation methods for Fedora/RHEL-family systems, Alpine Linux, Arch, OpenWRT and several other platforms. At the time of this writing, the current upstream release is sngrep 1.8.4.

Once installed, verify the version with:

sngrep -V

and examine the available command-line options with:

sngrep -h

Because live packet capture normally requires packet-capture privileges, many users will launch it using sudo.

Your First Capture

The simplest possible command is:

sudo sngrep

sngrep begins watching available interfaces for SIP signaling and builds a list of SIP dialogs.

The initial screen is the Call List.

Instead of seeing thousands of Ethernet frames, IP packets and UDP datagrams, you see SIP conversations.

That distinction is important.

Wireshark is fundamentally packet-oriented.

sngrep is fundamentally SIP-dialog-oriented.

Move through the dialogs with the arrow keys. Press Enter on a conversation and sngrep displays the SIP messages as a ladder diagram.

You might see something similar to:

192.168.1.25        10.10.10.5          203.0.113.20
     |                   |                    |
     |------ INVITE ---->|                    |
     |                   |------ INVITE ---->|
     |                   |<---- 100 Trying ---|
     |<---- 100 Trying --|                    |
     |                   |<---- 180 Ringing --|
     |<--- 180 Ringing --|                    |
     |                   |<------ 200 OK -----|
     |<------ 200 OK ----|                    |
     |------- ACK ------>|                    |
     |                   |------- ACK ------->|

For many SIP problems, you can identify the basic failure almost immediately.

The official documentation describes the same model: sngrep groups SIP messages by Call-ID and presents them as arrow flows similar to those commonly used in SIP documentation.

Capturing on a Particular Interface

On a system with multiple interfaces, you may want to specify exactly where sngrep should listen.

First identify the interfaces:

ip link

Then specify one:

sudo sngrep -d eth0

You can also use any:

sudo sngrep -d any

or even specify multiple interfaces in installations that support it.

The interface can also be configured permanently through the sngrep configuration file.

Don’t Capture Everything

On a busy SBC, PBX or SIP proxy, simply running:

sudo sngrep

may produce an enormous amount of traffic.

This is where capture filtering becomes important.

sngrep understands BPF capture filters, just like tcpdump and Wireshark capture filters.

For example:

sudo sngrep port 5060

or:

sudo sngrep port 5060 and udp

You could restrict the capture to a particular SIP server:

sudo sngrep host 192.168.10.20 and port 5060

The important point is that this type of filtering happens at the packet-capture level.

Packets that do not match the BPF expression are not passed along for SIP processing.

The upstream documentation gives essentially the same example:

sngrep -d eth0 -O save.pcap port 5060 and udp

That captures SIP traffic from eth0 while simultaneously writing the captured packets to a PCAP file.

Capture Filters and SIP Searches Are Not the Same Thing

This deserves some attention because it is easy to confuse the two.

A BPF expression such as:

host 192.168.1.20 and port 5060

operates on the packets.

A match expression searches within the SIP message payload.

Suppose you are troubleshooting calls involving extension 4102.

You could use:

sudo sngrep -i "4102" port 5060

The -i makes the match expression case-insensitive.

This is useful for looking for telephone numbers, usernames, SIP domains, User-Agent values or other text contained within SIP messages.

Once a request matches the expression, sngrep can retain the following messages belonging to that dialog so you get the conversation rather than one isolated SIP packet.

This gives sngrep two very useful levels of filtering:

Packet filtering       -> BPF
SIP-content matching   -> SIP message payload

Understanding that distinction makes the command-line interface considerably easier to use.

Show Me Calls—Not All the SIP Noise

SIP systems generate much more than telephone calls.

REGISTER, OPTIONS, SUBSCRIBE, NOTIFY and other methods can produce a steady stream of signaling.

If your goal is simply to investigate calls, try:

sudo sngrep -c

The -c option limits the display to dialogs beginning with an INVITE request.

This can make an enormous difference on a production VoIP system.

Be careful, however.

If you are troubleshooting a registration problem, -c is exactly what you do not want, because REGISTER transactions are not INVITE-based calls.

Choose your filtering based on the problem you are investigating.

Reading the Ladder Diagram

This is where sngrep really earns its place in the troubleshooting toolbox.

Once you select a dialog, sngrep shows the signaling path between the participating IP addresses.

You can very quickly answer questions such as:

Did the INVITE leave the phone?

Did the PBX forward the INVITE?

Did the carrier respond?

Where did the 404 originate?

Was a 486 Busy generated by the far-end system or by an intermediate server?

Did we receive a 200 OK?

Did the caller send the ACK?

Which device generated the BYE?

How long passed between the INVITE and the 180 Ringing?

Instead of reading packets individually, you are reading the conversation.

And that is often how SIP should be troubleshot.

Look at the Actual SIP Message

A ladder diagram tells you what happened.

Eventually you will want to know why.

Move to a message in the call flow and sngrep can display the actual SIP contents.

Now you can inspect things such as:

Via:
From:
To:
Call-ID:
CSeq:
Contact:
Route:
Record-Route:
User-Agent:
Authorization:
Supported:
Allow:
Content-Type:

and, of course, the SDP body.

This is where I start paying very close attention to addresses.

For example:

c=IN IP4 192.168.1.55
m=audio 16432 RTP/AVP 0 8 101

If that information is being sent toward an Internet-based SIP provider, the private 192.168.1.55 address should immediately make you curious.

The signaling may be completely successful while the media fails.

That leads to an important troubleshooting rule:

A successful SIP call setup does not prove that the RTP path works.

SIP and RTP Are Different Problems

sngrep can capture and associate RTP information with calls. The -r option enables RTP payload capture so that RTP can also be saved into PCAP output. Current versions can also parse RTP telephone-event traffic used for events such as DTMF.

For example:

sudo sngrep -r

This can be useful when you want to see the relationship between SIP signaling and the resulting media streams.

But I would not replace Wireshark with sngrep for serious RTP analysis.

If the complaint is:

“the call doesn’t connect”

I might start with sngrep.

If the complaint is:

“the call connects but audio is only working in one direction”

I might start with sngrep to inspect the SDP, then move to Wireshark to prove what happened to the RTP.

If the complaint is:

“the audio sounds terrible”

I am almost certainly going to Wireshark for RTP sequence numbers, loss, jitter, timing and packet-level analysis.

The tools complement each other.

Opening an Existing PCAP

This may be one of sngrep’s most useful features for network engineers.

You don’t have to perform the capture with sngrep.

Suppose someone sends you:

customer-call.pcap

Open it with:

sngrep -I customer-call.pcap

sngrep reads the capture and constructs the SIP dialogs automatically.

You can also combine PCAP input with a BPF filter:

sngrep -I customer-call.pcap host 192.168.10.50

This is particularly useful when you already captured traffic with tcpdump, dumpcap, tshark or Wireshark but want a quick SIP-centric view of the results. Offline PCAP analysis is an explicitly supported use case.

In practice, I can easily imagine this workflow:

tcpdump/dumpcap
       |
       v
   capture.pcap
       |
       +------> sngrep
       |        Quick SIP flow analysis
       |
       +------> Wireshark
                Deep packet and RTP analysis

That is a very effective combination.

Comparing SIP Messages

Another useful feature is message comparison.

From the call-flow display, you can select two SIP messages. sngrep provides a message-difference view that highlights lines that do not match exactly. The feature is specifically documented in the sngrep manual.

Think about comparing an INVITE before and after it passes through an SBC.

You might immediately notice changes to:

Via
Contact
Record-Route
Call-ID
SDP connection address
Media port
Codec list
P-Asserted-Identity
Diversion
Remote-Party-ID

That can be considerably faster than placing two Wireshark packet-detail panes side by side and hunting through the SIP headers manually.

Multiple Call Legs

Things become even more interesting when a B2BUA, PBX or SBC creates different SIP dialogs for different legs of a call.

The Call-ID on one side may not be the Call-ID on the other.

sngrep allows multiple dialogs to be selected from the Call List. Those dialogs can then be displayed together in the Call Flow view.

That gives you a much better picture of something like:

Phone ---> PBX ---> SBC ---> SIP Provider

rather than treating each Call-ID as an unrelated event.

For complex SIP troubleshooting, that capability alone makes sngrep worth learning.

Saving What You Find

You can write captured traffic directly to a PCAP file:

sudo sngrep -O problem-call.pcap

or combine that with an interface and capture filter:

sudo sngrep -d eth0 -O problem-call.pcap port 5060

You can also select dialogs from within the interface and save the relevant traffic rather than handing someone a giant production capture containing thousands of unrelated calls. The manual specifically notes that selected dialogs can be saved into a PCAP.

That is extremely useful when escalating a problem.

Instead of:

Here’s a 900 MB capture. Good luck.

you can provide:

Here’s the SIP conversation associated with the failed call.

That is much better troubleshooting practice.

Configuration

You do not have to customize anything before using sngrep, and I would actually recommend learning the defaults first.

When you do want persistent settings, installations generally support a system configuration file such as:

/etc/sngreprc

and a user configuration file:

~/.sngreprc

Current configuration options include settings such as:

set capture.device any
set capture.limit 50000
set capture.outfile /tmp/last_capture.pcap
set capture.buffer 2
set savepath /tmp/sngrep-captures
set filter.methods INVITE

You can also customize the columns displayed in the Call List, including fields such as SIP From, SIP To, source, destination, Call-ID, transport, state and call duration.

That can turn sngrep from an occasional troubleshooting utility into a very efficient operational tool.

What About Windows?

sngrep is primarily a Unix/Linux-style terminal application.

For Windows users, WSL provides an interesting option:

sudo apt install sngrep

inside an Ubuntu WSL distribution.

For me, one particularly useful Windows workflow would be to capture traffic using Wireshark, dumpcap or another Windows capture mechanism and then use sngrep under WSL to analyze the resulting PCAP.

I would be more cautious about assuming that a live capture from inside WSL sees exactly the same traffic as the physical Windows NIC. WSL networking introduces another network layer, so what the Linux environment can observe depends on the WSL networking configuration.

For offline SIP analysis, however, that issue disappears.

Where sngrep Fits in the Toolbox

I don’t look at sngrep as a Wireshark replacement.

I look at it as another lens.

tcpdump and dumpcap are excellent capture engines.

tshark is excellent when you want Wireshark’s dissectors from the command line.

Wireshark is excellent when you need to understand exactly what happened at the packet and protocol level.

sngrep is excellent when the question is:

What happened to this SIP conversation?

And that is a question VoIP engineers ask constantly.

My troubleshooting workflow would often look something like this:

1. Capture the traffic.

2. Open the SIP signaling in sngrep.

3. Identify the dialog and failure point.

4. Inspect the SIP headers and SDP.

5. Determine whether the problem is signaling, media or underlying transport.

6. Move into Wireshark when deeper packet-level evidence is required.

That is where sngrep shines.

It gets you from thousands of packets to one understandable call flow very quickly.

For anyone who regularly troubleshoots SIP, SBCs, PBXs, VoIP gateways or SIP trunks, sngrep belongs in the toolbox.

References

The primary project and current source code are maintained by Irontec on GitHub. sngrep on GitHub

The current command-line options and interface behavior are also documented in the sngrep manual. sngrep manual page

---

If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material.  Comments and technical discussion are always welcomed at our Patreon community or on our Discord server.  You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.