Some VoIP Troubleshooting Checklists and Tools

Post Views: 1,546

Here are several VoIP troubleshooting checklists and tools, organized by focus area to help quickly identify and resolve common issues. These checklists are especially useful for IT admins, NOC teams, and VoIP engineers. Are they “the bees knees” of troubleshooting VoIP? No. In fact, if you have feedback or comments on improving these lists, please please let me know. Links to providing feedback are below.

A General VoIP Troubleshooting Checklist

Is the VoIP phone/device powered on?
Is the device connected to the correct VLAN or network segment?
Can the phone reach the VoIP server (ping/sip trace)?
Are DNS settings correct (especially for SIP proxy resolution)?
Are NAT/firewall rules interfering with VoIP ports (e.g., SIP 5060, RTP 10000-20000)?
Is the firmware/software up to date on the device or softphone?
Are QoS settings in place for VoIP traffic?
Are other phones experiencing the same issue?

One-Way or No Audio Checklist

Is SIP signaling successful (200 OK received)?
Are RTP ports open on both ends?
Is NAT traversal (STUN/TURN/ICE or SIP ALG) correctly configured?
Is the media stream (RTP) using the correct IP address and port?
Are both endpoints using compatible codecs?
Use Wireshark: Is RTP traffic present in both directions?

Call Drop or Failure Checklist

Is the SIP registration active and not expiring prematurely?
Are SIP OPTIONS/Keepalives being blocked?
Is there a re-INVITE or BYE causing unintended termination?
Is jitter/latency/packet loss degrading the call quality?
Check for SIP 408 (Request Timeout), 503 (Service Unavailable), 487 (Cancelled) in logs.
Are SIP timers configured appropriately (T1, T2, etc.)?

Poor Call Quality Checklist (Jitter, Delay, Choppy Audio)

Measure jitter, delay, and packet loss with tools like ping, iperf, or VoIPmonitor.
Ensure QoS (DSCP tagging, traffic prioritization) is implemented on WAN/LAN.
Is the network experiencing congestion (e.g., high CPU/bandwidth utilization)?
Use RTP stream analysis in Wireshark for MOS and jitter graphs.
Verify that VoIP traffic isn’t traversing VPN tunnels without proper optimization.

SIP Signaling & Registration Checklist

Is the SIP server reachable (ping, telnet to port 5060/5061)?
Are credentials correct (username, password, domain)?
Are SIP messages visible using sngrep, sipsak, or Wireshark?
Are SIP registration attempts getting 401/403/404 responses?
Is there any SIP ALG causing SIP header mangling?
Is TLS used? Are certificates valid and trusted?

Wireshark Troubleshooting Checklist

Honestly – you have to start with a full set of Wireshark Profiles. Go here, and look for the NetSci-SIP, NetSci-SDP, NetSci-RTP, NetSci-RTCP, NetSci-VoIPQoS profiles, download them, and install them in Wireshark. These are game changers. Most of the checklist items below are simple one-button-click filters in these profiles.

First some general checklist items:

Simply find calls in your capture quickly: Telephony > VoIP Calls
Filter on SIP (sip) and RTP (rtp) protocols.
Analyze SIP ladder diagrams for failed negotiation or call teardown.
Use Telephony > VoIP Calls and RTP Stream Analysis.
Identify errors and retransmissions, 4xx/5xx errors, or dropped INVITE requests.
Look for mismatched SDP (e.g., wrong media IP, codec negotiation failure).

Now let’s get more detailed: this is my usual process when using the profiles in Wireshark:

SIP/SDP – use the SIP and SDP profiles
- Telephony> VoIP Calls
- Play Streams
  - SIP Statistics
  - SIP Errors
  - Port Numbers
- Communications Ladder – the process
  - SIP Flows
  - SIP Flow Sequence
RTP – use the RTP profile
- 20 msec delta times
- Sequence Numbers
- Telephony> RTP Streams
- Select Stream> Analyze
- Statistics
RTCP
- Look for those statistics in columns in the RTCP profile
QoS – use the profile to hunt down issues with QoS settings/markings in the IP headers

General VoIP Troubleshooting Tools

Here is a VoIP Troubleshooting Toolkit, aligned with the checklists above, including specific tools and scripts for each troubleshooting area. These will help streamline and automate analysis where possible.

Task	Tool/Script	Notes
Check device power and link	Built-in phone diagnostics or LLDP/CDP neighbor info	Use switch CLI (`show lldp neighbors`, `show cdp neighbors`)
Network reachability	`ping`, `traceroute`	Test to VoIP gateway, DNS, NTP servers
DNS resolution	`nslookup`, `dig`	Verify SIP server and SRV/NAPTR record resolution
SIP server connectivity	`telnet <sipserver> 5060` or `ncat`	Confirms if SIP port is reachable
Check for SIP ALG	Use `sipsak`, `nmap -p 5060 --script sip-methods`	Detect SIP mangling We have articles on nmap and sipsak and other sip tools.
QoS validation	`Wireshark` (DSCP field), router CLI (`show mls qos`, `show policy-map`)	DSCP should match EF (46) for voice

One-Way or No Audio Tools

Task	Tool/Script	Notes
RTP stream presence	`Wireshark` (filter: `rtp`)	Check SSRC and direction of streams
NAT traversal issues	`sipsak`, `sngrep`, firewall logs	Look for private IPs in SDP (e.g., `c=IN IP4 192.168.1.100`)
STUN/TURN test	`stunclient`, `trickle-ice`, `coturn logs`	Validates traversal capabilities
Codec negotiation	`Wireshark`, SIP INVITE/200 OK SDP	Look for `m=audio` and `a=rtpmap` lines
RTP port check	Use `nmap` or `netstat`	`nmap -p 10000-20000 <IP>` to see open RTP ports

Call Drop/Failure Tools

Task	Tool/Script	Notes
SIP logs	`sngrep`, `tcpdump -i any port 5060`	Use ladder view to see BYE or CANCEL messages
Packet loss/jitter	`mtr`, `pingplotter`, `VoIPmonitor`	Useful for tracing intermittent drops
SIP trace logs	From phone/gateway/softswitch	Look for session refreshes, failures, or BYEs
SIP timer validation	`Asterisk logs`, `FreeSWITCH`, or `kamailio.cfg`	Check if timers like `T1`, `T2`, `Timer B` are tuned correctly

Poor Call Quality Tools

Task	Tool/Script	Notes
MOS, jitter, packet loss	`Wireshark RTP analysis`, `VoIPmonitor`, `VQManager`	`Telephony > RTP > Stream Analysis` in Wireshark
Network performance	`iperf`, `mtr`, `smokeping`	Simulate voice UDP traffic (`iperf -u`)
QoS marking	`Wireshark`, switch/router CLI	Inspect DSCP values (expect EF/46)
Bandwidth usage	`iftop`, `ntopng`, `vnStat`	Identify network congestion or saturation
CPU/memory load	`top`, `htop`, `free -m`	High CPU usage on VoIP server can degrade performance

SIP Signaling & Registration Tools

Task	Tool/Script	Notes
SIP message capture	`sngrep`, `tcpdump`, `Wireshark`	View INVITE, REGISTER, 401/403 errors
SIP test message	`sipsak -s sip:user@domain`	Useful for testing responsiveness
TLS verification	`openssl s_client -connect sipserver:5061`	Inspect certificates and handshake
SIP registration test	`pjsua`/pjsip, `linphonec`, `sipvicious`	Full-featured CLI SIP clients
Log review	`journalctl`, `asterisk -rvvv`, `kamctl ul show`	Check registration state and expiration timers

Check out our post on PJSIP here: https://www.cellstream.com/2025/06/27/voip-troubleshooting-with-pjsip/

Check out how to use SIP Pings in our port here: https://www.cellstream.com/2025/06/25/what-are-and-how-to-use-sip-pings-in-voip/

Check out how to use the sipsak tool here: https://www.cellstream.com/2025/06/24/sip-testing-and-troubleshooting-with-sipsak/

Wireshark Troubleshooting Tasks

I will say it again: you have to start with a full set of Wireshark Profiles. Go here, and look for the NetSci-SIP, NetSci-SDP, NetSci-RTP, NetSci-RTCP, NetSci-VoIPQoS profiles, download them, and install them in Wireshark. These are game changers.

That said – here are some tasks and how to accomplish them:

Task	Tool/Script	Notes
Capture SIP & RTP	`tcpdump -i eth0 port 5060 or portrange 10000-20000 -w voip.pcap`	Capture signaling and media in one shot
Analyze VoIP	Wireshark `Telephony > VoIP Calls`	Follow and listen to RTP streams
Reassemble streams	Wireshark `Follow UDP Stream` or `rtpdump`	For debugging stream corruption
SIP/RTP filters	`sip`, `rtp`, `udp.port==5060`, `rtcp`	Focus capture on relevant traffic
Packet loss/jitter	`Telephony > RTP > Stream Analysis`	Graph MOS, jitter, and packet loss visually

Fantastic!

Other Steps to Consider

Now let’s look at some specific “reported issues” and how to troubleshoot them by taking the suggested steps. There is some overlap with the checklists above, so make sure you are aware of both.

Audio is breaking up

The symptom is the audio from remote party is breaking up or audio from playing a file locally is breaking up.

Check that no other application is using the devices. It is common to not be able to use sound device when the device is being used by other applications.
Verify the control plane of VoIP (SIP). Verify that both ends of the call have matching settings in the SIP/SDP signaling. Check that codec is negotiated properly by both parties.
Verify the data plane of VoIP (RTP/RTCP). Check for high network jitter, packet loss, etc. using the Tools listed above.
Check if audio is breaking up when playing file locally: Checking by playing a WAV file
Check if the breakup is coming from the sound device: Checking the quality of the sound device
Check if local audio is breaking up by looping back microphone signal to the speaker: Check by looping back microphone to speaker
Check proper firmware on all devices in the conversation (if possible)
Check for a “dangling call” in PBX or switch. A dangling call is call that is left active in the PBX/switch because previous application has terminated abruptly.
Check CPU utilization

Audio drop-outs or “stutters”

The symptom is audio is sounding like it’s skipping some frames.

Verify the control plane of VoIP (SIP). Verify that both ends of the call have matching settings in the SIP/SDP signaling.
Verify the data plane of VoIP (RTP/RTCP). Check for high network jitter, packet loss, etc. using the Tools listed above.
Check for high network jitter, packet loss, etc.
Check by looping back microphone to speaker: check whether the symptom is observable when looping the microphone to the speaker locally.
Check for audio underflows/overflows
Check for a “dangling call” in PBX or switch. A dangling call is call that is left active in the PBX/switch because previous application has terminated abruptly.
Check CPU utilization

High jitter value observed by remote party

Note that normally a jitter in the transmission shouldn’t cause problems, since the jitter is not very big and the receiving party should be able to accommodate this with a de-jitter buffer. That said:

Check if this is a network condition rather than problem with transmission.
Verify the control plane of VoIP (SIP). Verify that both ends of the call have matching settings in the SIP/SDP signaling.
Verify the data plane of VoIP (RTP/RTCP). Check for high network jitter, packet loss, etc. using the Tools listed above.
Since the transmission of the RTP packet is driven by the sound device clock, the performance of the transmission is affected by the performance of the sound device. If the sound device doesn’t deliver the captured frame in timely manner, the outgoing RTP transmission will have jitter in it.

Loud static noises

Check that audio device is functioning properly and noise is not heard when looping microphone to the speaker
Verify the control plane of VoIP (SIP). Verify that both ends of the call have matching settings in the SIP/SDP signaling. Check that codec is negotiated properly by both parties.
Verify the data plane of VoIP (RTP/RTCP). Check for high network jitter, packet loss, etc. using the Tools listed above.
Be mindful with combination of sampling rate and ptime that causes non-whole number of samples.

No audio is heard in local speaker

See the One-way Audio/No Audio list above.

Check that correct device is being used
Check that no other application is using the devices. It is common to not be able to use sound device when other application is using the device.
Check IP addresses and that both flow directions are getting around NAT.
Verify the control plane of VoIP (SIP). Verify that both ends of the call have matching settings in the SIP/SDP signaling. Check that codec is negotiated properly by both parties.
Verify the data plane of VoIP (RTP/RTCP). Check for high network jitter, packet loss, etc. using the Tools listed above
.Check that speaker is functioning properly by looping-back microphone to speaker device.
Checking by playing a WAV file.
Check that the call is connected to the sound device in the conference bridge.
Check CPU utilization

No audio is heard by remote party