Most VoIP problems come down to one of three things: signaling failing (SIP), media failing (RTP), or the network mangling one or both in transit. Packet captures tell you which. Everything else is a hypothesis.
Capture location matters
Capture at the problem point, not adjacent to it. On a PBX or SBC, capture the interface facing the phones or the carrier trunk — not the management interface or a mirror port three hops away. On a client site, capture at the edge device or directly on the phone VLAN.
For remote captures on a server or SBC where you cannot run a GUI:
# SIP signaling only, 60 seconds, save to file
tcpdump -i eth0 -w capture.pcap -G 60 -W 1 'udp port 5060 or tcp port 5060'
# All traffic to/from a specific phone
tcpdump -i eth0 -w phone.pcap host 10.10.5.42
# SIP plus RTP media streams
tcpdump -i eth0 -w voip.pcap 'udp port 5060 or udp portrange 10000-20000'
Pull the PCAP to Wireshark for analysis.
First thing in Wireshark
Telephony → VoIP Calls — all calls in the capture with their outcomes. Select a call, click Flow Sequence, and you have the full SIP trace in one view.
Telephony → RTP → RTP Streams — each media leg with packet counts, loss percentage, and jitter.
These two views answer most questions without diving into individual packets.
What the SIP messages tell you
| Message | What it means |
|---|---|
| REGISTER + 200 OK | Successful registration |
| REGISTER + 401/403 | Auth failure — credentials or IP restriction |
| REGISTER + 408 | Timeout — network path problem |
| INVITE → TRYING → RINGING → 200 OK → ACK | Normal call setup |
| INVITE → 486 Busy Here | Called party busy |
| INVITE → 480 / 503 | Unavailable — carrier side failure |
For one-way audio: open the SIP INVITE and the 200 OK. Look at the c= line in the SDP body — that is the IP address each side wants to receive media on. If you see a private address (192.168.x.x, 10.x.x.x) going out to an external carrier, that is your problem. The carrier cannot send RTP to an address it cannot route to.
What the RTP streams tell you
- One direction shows zero packets → that explains exactly which side has no audio. The path delivering RTP in that direction is broken.
- Packets present at the SBC, zero at the endpoint → firewall or routing is dropping media in the last hop.
- Both directions present but audio is distorted → packet loss or codec mismatch, not a missing path.
Wireshark lets you play back each RTP stream — useful for confirming which direction is actually silent before spending time on root cause.
SIP ALG
If something changed on the firewall — new router, firmware update, ISP change — and calls broke, check for SIP ALG before anything else. SIP ALG rewrites SIP headers and SDP as packets pass through, and it almost always corrupts the addresses that media routing depends on. The result is private IPs leaking into SDP headers that go to external carriers, corrupt Contact headers, and broken RTP paths.
The fix is to disable it. Flat NAT with explicit port forwarding for SIP and RTP is more predictable than any SIP ALG implementation I have seen.
Fixed-interval call drops
Calls dropping at a consistent interval — 15, 30, or 60 minutes — are almost never a network quality problem. They are a session timer problem.
Look at the Session-Expires header in the INVITE and 200 OK. SIP requires re-INVITE or UPDATE messages to refresh the session before the timer expires. If those messages are blocked, time out, or get a rejection, the call terminates cleanly at the timer boundary. It looks like a normal BYE; it is actually the timer firing.
Check in the capture whether the re-INVITE or UPDATE is being sent, and whether it receives a 200 OK before the timer boundary.
Security patterns visible in captures
A SIP scan looks like hundreds of REGISTER attempts from a single external IP with sequential or varied usernames:
sip.Method == "REGISTER" && ip.src != <your-known-carrier-range>
If the server has already logged thousands of authentication attempts from external IPs and nobody noticed — which is common — this filter surfaces it immediately in any recent capture.
Unencrypted SIP on a path that should require TLS: filter for sip and check whether you can read headers (Method, Call-ID, From, To, Contact) in plaintext. If you can, the signaling is unencrypted. For environments handling payment-related calls or with compliance requirements, this is typically a PCI DSS or policy finding.
Working reference
The questions that drive analysis:
- Did the endpoint register successfully?
- Was the call set up end-to-end, or did it fail before audio started?
- Where in the path did the failure occur — client, PBX, trunk, carrier?
- Is media present in both directions?
- Does packet loss, reordering, or jitter in the RTP streams match the reported symptom?
Keeping a library of known-good captures from working deployments speeds this up. Comparison against a working baseline is faster than analysis from first principles every time.
References: RFC 3261 — SIP · RFC 3550 — RTP · ITU-T G.114 — one-way latency threshold · Wireshark VoIP analysis