DEV Community

Dialphone Limited
Dialphone Limited

Posted on

VoIP Troubleshooting: 10 Problems I See Every Week and How to Fix Them

I run a VoIP consultancy. These are the 10 problems I troubleshoot most frequently, in order of how often I see them. Each one has a specific fix.

1. One-Way Audio (I can hear them, they can't hear me)

Frequency: Almost daily
Cause: NAT traversal failure — your phone sends RTP to the provider, but the provider's RTP cannot reach your phone because the firewall blocks inbound UDP.

Fix:

  1. Disable SIP ALG on your router (this is the cause 80% of the time)
  2. Open UDP ports 10000-20000 inbound
  3. Enable STUN on your phone/PBX
  4. If behind double NAT, set the external IP in your PBX's SIP settings

2. Calls Drop After 30-32 Seconds

Frequency: 3-4 times per week
Cause: SIP session timer mismatch. The initial INVITE gets through, but the SIP re-INVITE at the session timer interval (usually 30 seconds) is blocked.

Fix:

  1. Check firewall for stateful SIP inspection rules — disable them
  2. Increase SIP timer to 1800 seconds on your PBX
  3. Verify SIP ALG is off (yes, again — this causes everything)

3. Choppy Audio or Robot Voice

Frequency: 2-3 times per week
Cause: Network quality issues — either jitter > 30ms, packet loss > 1%, or bandwidth contention.

Fix:

  1. Run a jitter/loss test to your provider during the problem times
  2. Implement QoS (DSCP EF for RTP, CS3 for SIP)
  3. Put voice on a dedicated VLAN
  4. If on WiFi — switch to Ethernet (WiFi is the #1 cause of choppy audio)

4. Echo on Calls

Frequency: 2 times per week
Cause: Either acoustic echo (speakerphone reflecting audio back) or electrical echo (impedance mismatch on analog lines).

Fix:

  • Acoustic echo: Use a headset instead of speakerphone, or use a conference phone with proper echo cancellation
  • Electrical echo: If using an ATA (analog adapter), adjust the hybrid balance setting
  • Both: Enable echo cancellation (G.168) on the PBX if available

5. Phone Keeps Unregistering

Frequency: 2 times per week
Cause: NAT timeout — the firewall closes the UDP mapping before the phone re-registers.

Fix:

  1. Set phone registration interval to 60 seconds (not 3600)
  2. Enable keep-alive packets (SIP OPTIONS every 30 seconds)
  3. Set UDP timeout on firewall to > 120 seconds for SIP traffic

6. Cannot Hear Ring-Back Tone (Silent Wait After Dialing)

Frequency: 1-2 times per week
Cause: Early media (183 Session Progress) is not flowing correctly.

Fix:

  1. Enable "early media" support on your PBX
  2. Verify RTP ports are open (same fix as one-way audio)
  3. Check codec mismatch — if outbound codec is different from what the far end expects

7. Caller ID Shows Wrong Number

Frequency: Weekly
Cause: Outbound caller ID is not configured correctly on the SIP trunk.

Fix:

  1. Set the "From" header to your main business number
  2. Set P-Asserted-Identity to the specific user's DID
  3. Verify with your provider that your numbers are registered for outbound caller ID

8. Voicemail Not Working

Frequency: Weekly
Cause: Usually a call routing issue — calls to voicemail are going to the wrong destination.

Fix:

  1. Verify the voicemail extension number in PBX
  2. Check no-answer timeout (should be 20-25 seconds, not 10)
  3. Verify voicemail-to-email is configured with correct SMTP settings

9. Transfer Failures

Frequency: Weekly
Cause: SIP REFER method is not supported by one side of the call, or the REFER with Replaces header is being blocked.

Fix:

  1. Enable REFER support on your PBX
  2. If blind transfers fail but attended transfers work — it is a REFER issue
  3. As a workaround, use attended transfers (conference and drop) instead of blind

10. Intermittent Quality at Specific Times

Frequency: Weekly
Cause: Bandwidth contention — usually a backup job, Windows updates, or video streaming consuming bandwidth during business hours.

Fix:

  1. Run a bandwidth test during the problem period
  2. Schedule backups and updates outside business hours
  3. Implement QoS to prioritize voice traffic
  4. Consider a dedicated internet circuit for voice

The Universal Debug Tool

When all else fails, capture a SIP trace. Every PBX has the ability to log SIP messages. Read the SIP headers — they will tell you exactly where the call is failing.

INVITE sip:+15551234567@provider SIP/2.0
Via: SIP/2.0/UDP your-pbx:5060
From: "Your Name" <sip:1001@your-pbx>
To: <sip:+15551234567@provider>
Enter fullscreen mode Exit fullscreen mode

If the INVITE goes out but you never see a 100 Trying — it is a network/firewall issue. If you see a 4xx/5xx response — the error code tells you exactly what is wrong.

companies such as VestaCall (https://vestacall.com) that prioritize uptime over features includes built-in SIP trace tools in their admin portal, so you can debug without CLI access.

Top comments (0)