VoIP problems are rarely “random”. In almost every SIP/RTP issue, the network is doing exactly what it was told — we just need visibility. Wireshark live monitoring is the fastest way to see what actually happened: SIP signaling, SDP negotiation, RTP media direction, NAT behavior, retransmissions, and codec/DTMF details.

This guide shows a production-safe workflow to capture calls, apply the right filters, decode RTP audio, and quickly diagnose common failures like one-way audio, no audio, incoming calls fail, RTP missing, and DTMF not detected.

You’ll get a practical approach that works whether your stack is: Asterisk / FreePBX, SIP softphones, SIP trunks, on-prem setups, and hybrid networks.

VoIP Call Anatomy (SIP + SDP + RTP) — What You Must Capture

A successful call has two planes:

Signaling (SIP): who calls whom, authentication, call setup/teardown
Media (RTP/SRTP): the actual audio stream

The most important thing: RTP ports are negotiated inside SDP (carried in SIP messages). That means you must capture SIP to learn where RTP should flow.

Reference reading (authoritative): Wireshark Documentation, RFC 3261 (SIP), RFC 3550 (RTP).

Before You Capture: Where to Run Wireshark (So You Don’t Miss Packets)

A capture is only as good as its vantage point. Choose one:

Best: capture on the Asterisk/FreePBX server interface that faces the SIP trunk or WAN (you see both signaling and media as the PBX sees it).
Good: capture on the edge router/firewall (if it supports port mirroring / span / packet capture).
Sometimes: capture on the client device (softphone PC) — good for WebRTC and local LAN issues.

If you have NAT involved, capture on the PBX is usually the fastest path to truth.

Live Capture Safely on Production (tcpdump → Wireshark)

On production PBX servers, running full GUI Wireshark is not ideal. Instead: capture with tcpdump and open the file in Wireshark on your laptop.

1) Identify the correct interface

ip -br a
ip route

2) Capture SIP + RTP (common UDP ranges)

Adjust RTP range to match your PBX config (many use 10000–20000, but verify).

# Replace eth0 with your real interface
# This captures: SIP (5060/5061) + RTP (10000-20000) + DNS (53) + NTP (123) for troubleshooting context
sudo tcpdump -i eth0 -s 0 -w voip-call.pcap \
  '(udp port 5060 or tcp port 5060 or udp port 5061 or tcp port 5061) or \
   (udp portrange 10000-20000) or \
   (udp port 53) or (udp port 123)'

3) Capture only a specific phone or trunk IP (recommended)

# Example: capture traffic only between PBX and one device/trunk
sudo tcpdump -i eth0 -s 0 -w voip-target.pcap host 203.0.113.10

4) Stop capture and download

# Stop tcpdump with Ctrl+C, then copy the pcap to your PC
scp root@YOUR_PBX_IP:/root/voip-call.pcap .

Wireshark can open .pcap / .pcapng directly.

Wireshark Filters You Will Use Daily (SIP, SDP, RTP)

Display filters (inside Wireshark)

sip
sdp
rtp
rtcp

Filter SIP by Call-ID (fastest way to isolate one call)

Open any SIP packet → find Call-ID value → then filter:

sip.Call-ID contains "a84b4c76e66710"

Filter by IP endpoints

ip.addr == 203.0.113.10
ip.src == 10.10.10.50 && ip.dst == 203.0.113.10

Find retransmissions (signaling stability issues)

sip && (sip.Method == "INVITE" || sip.Method == "REGISTER")

Then look for repeated INVITE/REGISTER with increasing CSeq and identical payload.

How to Find RTP Ports from SDP (This Solves “RTP Not Showing”)

If people search “RTP not showing in Wireshark”, the usual reason is: you didn’t decode the negotiated RTP ports, or your capture missed the interface.

Step-by-step

Filter sdp
Open the SDP inside 200 OK (or INVITE if early media)
Find lines like m=audio 18642 RTP/AVP 0 101

In SDP:

m=audio 18642 means the receiver expects RTP on UDP port 18642
c=IN IP4 203.0.113.10 means RTP target IP is 203.0.113.10

Example SDP snippet (typical)

v=0
o=- 169703920 169703920 IN IP4 203.0.113.10
s=-
c=IN IP4 203.0.113.10
t=0 0
m=audio 18642 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Once you know IP+port, filter RTP precisely:

udp.port == 18642 && ip.addr == 203.0.113.10

Decode and Play RTP Audio (Prove Where the Audio Breaks)

Wireshark can decode RTP and even export audio (when it’s not encrypted). This turns “I think audio is missing” into a measurable fact.

Method A — Telephony → RTP → Streams

Go to Telephony → RTP → RTP Streams
Select the stream → click Analyze
Use Play Streams to listen direction-wise

Method B — Decode as RTP (when Wireshark didn’t auto-detect)

Right-click a UDP packet on the negotiated port
Choose Decode As…
Select RTP

If the stream shows packets one direction only, you likely have one-way audio (NAT/firewall/RTP handling).

Diagnose One-Way Audio (Most Common VoIP Ticket)

One-way audio almost always means: RTP is flowing only in one direction, or is being sent to the wrong IP/port due to NAT rewriting or SDP mismatch.

Quick checklist (what Wireshark will reveal)

RTP packets only one direction → port blocked or NAT mapping wrong
SDP contains private IP → NAT/external address misconfigured
RTP ports differ from expected range → PBX RTP range mismatch
ICMP unreachable or no response → firewall path issue

Diagnose “DTMF Not Working” (Pressing Keys Does Nothing)

For IVR/menu issues, the most common root cause is DTMF transport mismatch. In Wireshark, you want to see if telephone-event is negotiated and present.

Check SDP for DTMF

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Find DTMF packets in Wireshark

rtpevent

If you do not see telephone-event in SDP and you do not see RTPEVENT frames, then DTMF is not being sent in RFC2833/RFC4733 style (common requirement for trunks and IVRs).

Helpful background: RFC 4733 (RTP Payload for DTMF).

Diagnose “Calls Fail / 403 / 401 / No Matching Endpoint” Using SIP Details

Authentication and routing problems are visible in SIP responses. Use display filters to isolate REGISTER or INVITE and inspect response codes.

Common SIP failure patterns

401 Unauthorized → challenge is normal; failure is when it repeats without success
403 Forbidden → credentials wrong OR provider blocks IP / account / caller ID
404 Not Found → wrong DID or wrong routing on provider side
488 Not Acceptable Here → codec/SDP mismatch
503 Service Unavailable → upstream capacity or trunk down

Useful filters

sip.Method == "REGISTER"
sip.Method == "INVITE"
sip.Status-Code == 401
sip.Status-Code == 403
sip.Status-Code == 488

For SIP fundamentals: RFC 3261 (SIP).

Live Monitoring with tshark (CLI) — Quick Checks Without a GUI

On headless servers, tshark (Wireshark CLI) can extract critical info fast.

Show SIP Call-IDs and methods

tshark -r voip-call.pcap -Y sip \
  -T fields -e frame.time -e ip.src -e ip.dst -e sip.Call-ID -e sip.Method -e sip.Status-Code

Extract negotiated RTP ports from SDP

tshark -r voip-call.pcap -Y sdp \
  -T fields -e ip.src -e ip.dst -e sdp.connection_info -e sdp.media.port

Count RTP packets by direction (spot one-way audio quickly)

tshark -r voip-call.pcap -Y rtp -T fields -e ip.src | sort | uniq -c | sort -nr

Common “Wireshark Shows SIP but No RTP” Causes

Captured on wrong interface (common on multi-NIC servers): SIP may be on one interface and RTP on another, or media is hairpinned differently.
RTP is encrypted (SRTP): you will still see UDP packets, but audio decode/export won’t work without keys.
RTP range mismatch: PBX uses a different port range than your capture filter expects.
Symmetric RTP / NAT behavior: media may shift ports after negotiation (still visible, but you must follow the stream).

Tip: start with a wide capture (SIP + wide UDP), then narrow down once you discover real RTP ports.

Export Evidence for Escalation (So Providers Take You Seriously)

When escalating to an ISP/SIP provider, “audio not working” is weak. Send evidence:

Call timestamp (UTC + local time)
Caller and callee numbers
SIP Call-ID
SIP response codes (401/403/488 etc.)
SDP c= and m=audio values (IP and RTP ports)
RTP direction proof (packets one-way, or sent to wrong IP)

In Wireshark, you can right-click a SIP packet → Copy → As Printable Text for clean sharing. Avoid sharing entire PCAPs publicly (they may contain credentials and internal IPs).

Quick Takeaway

The winning workflow is simple: capture from the right place, isolate one call using Call-ID, read SDP to learn RTP targets, then confirm media direction by decoding RTP streams. With this, you can solve most VoIP issues in minutes — including one-way audio, missing RTP, codec mismatches, and DTMF failures.

Official Wireshark references: Wireshark Docs and Wireshark VoIP Calls Wiki.