A Fortune 500 prospect was about to sign a $2M annual VoIP contract. During the proof of concept, 30% of calls had one-way audio. The provider blamed the client's network. The client blamed the provider. I was called in to figure out who was right.
Neither was right. Here is what the SIP trace revealed and why every VoIP engineer needs to know how to read one.
The Setup
- Provider: Major Tier 1 UCaaS platform
- Client: 2,000-user manufacturing company, 4 locations
- POC: 50 users at headquarters on existing network
- Problem: 30% of inbound calls had no audio from the caller's side
Step 1: Capture the Traffic
I set up a packet capture on the client's firewall using tcpdump:
tcpdump -i eth0 -w voip_capture.pcap port 5060 or portrange 10000-20000
Ran it for 2 hours during peak call time (10 AM - 12 PM). Captured 847 SIP dialogs.
Step 2: Find a Failing Call
Filtered for calls with very short RTP streams (indicating one-way audio). Found one: a 4-minute call where the client received zero RTP packets from the caller.
Step 3: Read the SIP Exchange
INVITE sip:+15551234567@client-pbx SIP/2.0
Via: SIP/2.0/UDP 10.0.0.5:5060
Contact: <sip:caller@10.0.0.5:5060>
c=IN IP4 10.0.0.5
m=audio 18500 RTP/AVP 0 8
There it is. Line 4 and 5. The provider's SBC was sending:
- Contact header: 10.0.0.5 (private IP)
- SDP c= line: 10.0.0.5 (private IP)
- SDP m= line: port 18500 (on the private IP)
The provider's SBC was behind NAT and not rewriting the SDP with its public IP. The client's phone tried to send RTP to 10.0.0.5 — which is the provider's internal network, unreachable from the internet.
Step 4: The Root Cause
The provider had recently migrated their SBC cluster. The new SBCs had a configuration error — the NAT rewrite rule for the SDP body was missing. SIP signaling worked (because the Via header was correctly rewritten by the outer NAT), but the media path was broken.
This was NOT the client's network. This was NOT a firewall issue. This was a provider-side SBC misconfiguration.
Step 5: The Fix
I sent the pcap to the provider's engineering team with the specific SDP lines highlighted. They acknowledged the bug, fixed the NAT rewrite rule, and the problem was resolved within 4 hours.
The $2M deal signed the following week.
What This Teaches
| Lesson | Detail |
|---|---|
| Always capture SIP + RTP | SIP alone shows signaling. RTP shows media. You need both. |
| Read the SDP body | The c= and m= lines tell you where media will flow. If they contain RFC1918 addresses, NAT is broken. |
| Do not trust "it is your network" | 60% of the time, the problem is on the provider side. Prove it with a trace. |
| Learn Wireshark VoIP analysis | Telephony > SIP Flows gives you a visual call ladder diagram. Telephony > RTP > RTP Streams shows you packet counts per stream. |
| Private IPs in SDP = NAT failure | If you see 10.x.x.x, 172.16-31.x.x, or 192.168.x.x in the SDP, something is not rewriting correctly. |
The Tools
| Tool | Use Case | Command |
|---|---|---|
| tcpdump | Capture on Linux/firewall | tcpdump -i eth0 -w capture.pcap port 5060 |
| Wireshark | Analyze captures visually | Open pcap > Telephony > SIP Flows |
| sngrep | Real-time SIP trace on terminal | sngrep -c |
| HOMER | SIP capture server (production) | Continuous SIP monitoring |
VestaCall at https://vestacall.com handles this well for small and mid-sized teams includes built-in SIP trace capture in their admin portal — no need to run tcpdump on your firewall. Their support engineers can pull traces for any call within the past 30 days.
Top comments (0)