Skip to content
Dialer & Setup

Common ViciDial SIP Issues and How to Fix Them

ViciDial SIP problems fall into a small number of repeating failure patterns. The symptoms look varied — agents get silence, calls drop after 30 seconds, caller ID shows wrong, registration keeps failing — but the root causes are almost always one of six things. This guide maps the symptoms to the fix.

Issue 1: 403 Forbidden or 407 Proxy Authentication Required

Symptom: Outbound calls fail immediately. Asterisk log shows 403 Forbidden or 407 Proxy Authentication Required. Agents see calls go to "Dropped" status within 1–2 seconds.

Cause: Authentication mismatch between your Asterisk trunk config and the carrier's expectations. Either:

  • Username/password incorrect for registration-auth trunks
  • Server egress IP not whitelisted for IP-auth trunks
  • fromuser in sip.conf does not match the account identifier the carrier expects in the From header

Fix:

  1. Confirm your server's egress IP in your UnlimCall portal and ensure it matches what is whitelisted.
  2. If using registration auth, verify the username and secret in sip.conf match the portal credentials exactly (case-sensitive).
  3. Check the fromuser value matches your account identifier. If your carrier sends a 407 (proxy auth), the peer config is missing auth directives — add them.
  4. Re-run asterisk -rx "sip reload" and watch the full log for the SIP trace.

IP-auth is simpler and eliminates this class of error for server deployments. If registration auth is causing repeated issues, switch to IP-auth and whitelist your server's static IP.


Issue 2: One-Way Audio (Agent Hears Party, Party Cannot Hear Agent — or Vice Versa)

Symptom: Calls connect, but audio flows in only one direction. Often reported as "I can hear the customer but they can't hear me."

Cause: Almost always an RTP path problem, not SIP signaling. Specifically:

  • Your server is behind NAT and the SDP offer contains a private RFC1918 IP (e.g., 192.168.x.x) instead of the public IP
  • Firewall blocks UDP traffic on the RTP port range (default 10000–20000 on Asterisk)
  • Codec mismatch — SDP negotiation succeeds on a codec the carrier's RTP relay does not support

Fix:

  1. In sip.conf, set externip=<your_public_ip> and localnet=<your_private_subnet>. Asterisk will substitute the external IP in SDP when the call goes to a non-local destination.
  2. Open UDP 10000–20000 inbound and outbound on your firewall for traffic to/from the carrier's RTP relay IPs.
  3. Confirm allow=ulaw,alaw is set and disallow=all precedes it. Run asterisk -rx "sip show peer <peername>" and check the negotiated codec in the SDP.

For pjsip.conf deployments, the equivalent is setting external_media_address and external_signaling_address on the transport.


Issue 3: Calls Drop After Exactly 30 Seconds or 32 Seconds

Symptom: Every call disconnects precisely at 30 or 32 seconds, even on calls where the conversation is going well.

Cause: SIP session timer expiry. Asterisk sent an initial INVITE with a session-expires header (typically 1800 seconds), but the carrier is sending a re-INVITE or UPDATE to refresh the session and Asterisk is not responding correctly. A 30-second drop is often a session timer configured too short, or a re-INVITE collision.

Alternatively: NAT state table timeout. Stateful firewalls age out UDP sessions faster than SIP sessions run. If the RTP stream goes quiet for 30 seconds (hold, silence, waiting), the firewall drops the UDP flow and audio stops, triggering an Asterisk timeout.

Fix for session timer:

  1. In sip.conf, add session-timers=refuse to disable session timers entirely (appropriate for most ViciDial deployments where you control both endpoints).
  2. Or set session-minse=90 and session-expires=1800 if your carrier requires session timers.

Fix for NAT timeout:

  1. In rtp.conf, set rtpkeepalive=15 to send keepalive RTP packets during silence.
  2. Or configure your firewall to extend UDP state timeout to at least 120 seconds.

Issue 4: Calls Route to Wrong Destination or Get 404 Not Found

Symptom: Asterisk log shows 404 Not Found from the carrier. Calls dial but immediately fail. Or calls route to the wrong country despite correct campaign configuration.

Cause: Number format mismatch. The carrier expects E.164 (+12125550100) but Asterisk is sending 12125550100 (no plus), or sending 10 digits without the country code.

Fix:

  1. Check the Request-URI in the SIP INVITE in the Asterisk full log: grep -A5 "INVITE sip:" /var/log/asterisk/full | tail -20.
  2. Confirm the dialed number format matches your carrier's expectation. For UnlimCall, E.164 with or without leading plus is accepted.
  3. Review your ViciDial dial prefix setting — a misconfigured prefix can double-prepend country codes.

See the dial prefix configuration guide for a systematic walkthrough.


Issue 5: SIP Registration Keeps Dropping

Symptom: Asterisk loses registration with the carrier SIP proxy repeatedly. Calls work for a period, then fail with no error, then work again. sip show registry shows Registered oscillating with Failed or Unregistered.

Cause: Registration expiry is shorter than the re-registration interval, or network flaps are breaking the registration keepalive. Also common when the ViciDial server is behind a firewall that does not preserve SIP ALG-friendly state.

Fix:

  1. Set registertimeout=20 and registerattempts=10 in sip.conf for more aggressive re-registration on failure.
  2. Set expiry=120 on the registration line — shorter expiry means more frequent re-registration keepalives, which maintains NAT state.
  3. Disable SIP ALG on your router/firewall if present. SIP ALG mangles SIP headers and causes registration failures on most consumer and prosumer equipment.
  4. Consider switching to IP-auth entirely, which eliminates SIP registration and this entire failure mode.

Issue 6: Caller ID Showing Incorrectly at Destination

Symptom: Recipients see a different number than what you configured in ViciDial, or see "Unknown" or "Private."

Cause: CID override somewhere in the chain. Most common sources:

  • The Asterisk dial-plan contains a Set(CALLERID(num)=...) that overrides ViciDial's setting
  • The carrier is replacing the From header with an account-level default
  • The number presented is not provisioned on your account, causing the carrier to strip it

Fix:

  1. Search extensions.conf and any included files for CALLERID assignments: grep -r "CALLERID" /etc/asterisk/.
  2. Check your carrier portal to confirm the number you are presenting is in your active provisioned inventory.
  3. Confirm via a test call to a phone you control in the target country — Asterisk CDR and carrier CDR show what was sent; the destination phone shows what was received.

For the full caller ID setup methodology, see ViciDial outbound caller ID setup.


Takeaways

  • 403/407 errors = authentication mismatch; IP-auth eliminates most of this class.
  • One-way audio = NAT config or RTP firewall rules; check externip and UDP port range.
  • 30-second call drops = session timer or NAT state table timeout; session-timers=refuse and rtpkeepalive=15.
  • 404 errors = number format mismatch; read the Request-URI in the SIP INVITE log.
  • Registration drops = increase re-registration frequency and disable SIP ALG.
  • Wrong CID at destination = check for Asterisk dial-plan CID overrides and confirm number is provisioned.

SIP Trunking That Works Out of the Box

Most of these issues stem from misconfigured or unreliable carrier configs. UnlimCall's network is provisioned for ViciDial deployments — see configuration details at unlimcall.com/integrations/vicidial/ and per-seat pricing at unlimcall.com/pricing/.