SIP Packet Capture and Analysis with Wireshark and Homer

Why Packet Capture Is Essential

In VoIP operations, when something goes wrong, softswitch logs do not always tell the complete story. Packet capture lets you see exactly what was transmitted on the network: every SIP message, every RTP packet, every error response. For ISPs, contact centers, and carriers, mastering packet analysis is a fundamental skill for resolving problems quickly and definitively.

The good news is that the SipPulse platform was designed to simplify SIP signaling troubleshooting, offering integrated logging and trace capabilities, plus native integration with capture tools like Homer.

Wireshark: The Reference for SIP Analysis

Wireshark is the most comprehensive tool for network protocol analysis, including SIP and RTP. It can read captures made locally or import pcap files from remote servers.

Essential SIP Filters

Use these display filters to focus on relevant traffic:

• sip - shows only SIP packets
• sip.Method == "INVITE" - only INVITEs (call initiation)
• sip.Method == "REGISTER" - only endpoint registrations
• sip.Status-Code >= 400 - only error responses (4xx, 5xx, 6xx)
• sip.Call-ID == "abc123@host" - filters by a specific call
• rtp - shows only RTP packets (media)
• rtcp - shows only RTCP packets (quality reports)

Call Flow Visualization

Wireshark has a native feature for visualizing SIP call flow. Access it via Telephony > SIP Flows or Telephony > VoIP Calls. This visualization shows the sequence of SIP messages between endpoints in a ladder diagram format, making it easy to identify where the call fails.

RTP Analysis

To analyze audio quality, use Telephony > RTP > RTP Streams. Wireshark displays jitter, packet loss, and inter-packet delta statistics for each RTP stream. You can even play back the captured audio to hear the problem.

sngrep: SIP Analysis in the Terminal

sngrep is a command-line tool that captures and displays SIP traffic in real time on the terminal. It is extremely useful for quick troubleshooting on production servers without a graphical interface:

sngrep -d eth0 port 5060

sngrep displays SIP messages in call flow format directly in the terminal, allowing you to navigate between calls, view the full content of each message, and filter by Call-ID, From, To, or SIP method.

Install via package manager: apt install sngrep (Debian/Ubuntu) or yum install sngrep (CentOS/RHEL).

Integrated Troubleshooting with SipPulse SBC and SoftSwitch

Before resorting to external capture tools, the SipPulse platform offers integrated troubleshooting capabilities that resolve the majority of day-to-day scenarios.

Logging and Trace in the SipPulse SBC

The SipPulse SBC, supporting up to 4000 concurrent calls and available in UNI, NNI, and NNI-CC variants, offers detailed logging of all SIP transactions passing through the equipment. Since the SBC sits at the network edge, it captures both the inbound (upstream) and outbound (downstream) sides of each call, allowing you to compare SIP messages on both sides and quickly identify where the failure occurs.

TLS/SRTP support in the SipPulse SBC also allows inspecting the signaling of encrypted calls directly in the equipment's logs, something that passive capture tools like tcpdump cannot do without access to private keys.

Detailed CDRs in the SipPulse SoftSwitch

The SipPulse SoftSwitch, with capacity for up to 1000 CAPS and operating as both Class 4 and Class 5, generates complete CDRs that include SIP response codes, duration, negotiated codec, and quality metrics. These records allow you to identify failure patterns (by route, time, destination) without needing to capture packets on the network.

Homer / SIPCAPTURE: Production-Scale Capture with SipPulse Integration

For production environments with high call volumes, capturing with tcpdump or Wireshark does not scale. Homer (SIPCAPTURE) solves this problem with a distributed architecture based on the HEP protocol (Homer Encapsulation Protocol).

How It Works

1. The softswitch, SBC, or SIP proxy sends copies of SIP messages to Homer via HEP (UDP, port 9060 by default).
2. Homer stores the messages in a database (PostgreSQL or MySQL).
3. The web interface allows searching calls by number, Call-ID, date/time and viewing the call flow.

Native SipPulse + Homer Integration via HEP

The SipPulse SBC and SipPulse SoftSwitch are built on OpenSIPS, which supports the HEP protocol natively. This means that integration with Homer is direct and does not require additional agents or probes on the network. Simply configure HEP sending on the SipPulse products and all SIP messages will be automatically mirrored to Homer.

In practice, the configuration involves only enabling the proto_hep module in OpenSIPS and defining the Homer server address. The SipPulse SBC and SoftSwitch already include this capability, making Homer deployment significantly simpler than with platforms that require external capture via port mirroring or separate agents.

Advantages of Homer with SipPulse

• No impact on production traffic: HEP sends copies, it does not intercept the original traffic.
• Retroactive search: since all messages are stored, you can investigate problems that occurred hours or days ago.
• Session correlation: Homer correlates messages from the SipPulse SBC and SoftSwitch into a single call flow visualization, showing the call end to end.
• Native integration: OpenSIPS (the engine behind SipPulse products) supports HEP natively, with no need for additional probes or agents.
• Complete visibility: combining the integrated logs from SipPulse products with Homer capture, operators have full visibility into SIP signaling across the entire infrastructure.

tcpdump: Remote Capture

When you need to capture traffic on a remote server for local analysis in Wireshark, use tcpdump:

tcpdump -i eth0 -w /tmp/capture.pcap port 5060 or portrange 10000-20000

This command captures all SIP traffic (port 5060) and RTP (ports 10000-20000). Transfer the pcap file to your workstation and open it in Wireshark.

For long captures, limit file size with -c (packet count) or -G (time-based rotation):

tcpdump -i eth0 -w /tmp/capture_%Y%m%d_%H%M%S.pcap -G 3600 -c 100000 port 5060

Common Problems Visible in Traces

401/407 - Authentication Failure

Sequence: INVITE > 407 Proxy Authentication Required > ACK > INVITE (with credentials) > 401 Unauthorized. This indicates an incorrect password or unregistered user. Verify the credentials in the softswitch. In the SipPulse SoftSwitch, logs detail the exact reason for authentication rejection.

503 - Service Unavailable

The softswitch or SBC returns 503 when it cannot process the call (overload, unavailable routes, exhausted licenses). In the SipPulse SBC, check the utilization level (the equipment supports up to 4000 concurrent calls) and the availability of configured routes.

One-Way Audio

In the trace, examine the SDP in the INVITE and 200 OK. If the IP addresses in the c= field of the SDP are private addresses (10.x, 172.16-31.x, 192.168.x), the problem is NAT-related. RTP is being sent to an IP that is unreachable from the other side. The SipPulse SBC solves this problem natively, performing automatic NAT traversal for both signaling and media. WebRTC and STIR/SHAKEN support in the SBC also addresses modern NAT traversal scenarios.

Codec Mismatch

Compare the codec list in the INVITE SDP with the response in the 200 OK. If there is no common codec, the call will be rejected with 488 Not Acceptable Here. The SipPulse SBC can be configured to perform transcoding between codecs, eliminating incompatibility issues between different networks.

Timeout and Unanswered Calls

If the INVITE is sent but there is no response (not even 100 Trying), the problem could be network connectivity, a firewall blocking the SIP port, or the destination server being down. Use ping and traceroute to verify connectivity. The SipPulse SBC logs clearly show which INVITEs received no response and to which destination they were sent.

Capture Best Practices

1. Always capture with precise timestamps (-tt in tcpdump).
2. Include both SIP and RTP traffic in troubleshooting captures.
3. Label and store captures with date, time, and problem description.
4. In production, deploy Homer with HEP integrated with the SipPulse SBC and SoftSwitch for continuous capture without performance impact.
5. Protect capture files, as they may contain sensitive data (passwords in REGISTER, for example).
6. Use the integrated logs from SipPulse as the first line of investigation before resorting to network packet capture.

References

• Wireshark: https://www.wireshark.org/
• sngrep: https://github.com/irontec/sngrep
• Homer / SIPCAPTURE: https://sipcapture.org/
• HEP Protocol: https://github.com/sipcapture/HEP
• RFC 3261 - SIP: https://datatracker.ietf.org/doc/html/rfc3261
• tcpdump: https://www.tcpdump.org/