VICIdial WebRTC Not Working Outside Network? Complete Fix Guide
15+ years deploying VICIdial & Asterisk environments · Updated April 2025
Key Takeaways
- WebRTC failures outside the LAN are almost always caused by missing STUN/TURN configuration, not a VICIdial bug.
- All WebRTC traffic requires a valid SSL/TLS certificate – self-signed certificates silently block browser-based calling.
- TCP port 443 and UDP port ranges 10000–20000 must be open for media and signaling to reach remote agents.
- A properly configured coturn server resolves the majority of NAT traversal failures in external-access scenarios.
- Systematic testing – STUN first, then firewall, then SSL, then VICIdial config – is faster than random trial-and-error.
VICIdial WebRTC not working the moment agents leave your office network is one of the most disruptive problems a contact center can face, calls drop silently, softphones refuse to register, and supervisors have no idea why. The root cause is almost never VICIdial itself.
Instead, it sits in the gap between your browser-based WebRTC session and the real-world network barriers that live outside your LAN: STUN/TURN server failures, firewall port blocks, self-signed SSL certificates, and WebSocket misconfigurations. This guide documents every layer of that problem and gives you a precise, field-tested path to resolution. The same process our engineers follow on every external-access deployment.
Why VICIdial WebRTC Fails Outside the Local Network
WebRTC is a peer-to-peer communication protocol built directly into modern browsers. Unlike a traditional SIP softphone that uses a dedicated application, WebRTC uses your agent’s Chrome or Firefox session to establish audio and signaling channels. That design choice introduces a critical dependency: the browser must be able to discover its own public IP address and negotiate a media path through any NAT or firewall standing between the agent and your Asterisk server.
Inside your office LAN, this negotiation is trivial, all devices share the same private network, and NAT traversal is not required. The moment an agent works from home, a hotel, or a mobile connection, the entire picture changes. Their device sits behind a residential router with a private IP (e.g., 192.168.x.x), and the browser has no direct way to tell your server how to reach it. This is where STUN and TURN servers become essential.
The three root causes, in order of frequency
- Missing or misconfigured STUN/TURN server – the browser cannot resolve its public IP or relay media through NAT.
- Firewall blocking RTP/UDP media ports – signaling connects but audio is one-way or completely silent.
- Invalid or self-signed SSL certificate – browsers refuse to grant microphone access on non-HTTPS origins, silently killing the session.
Step 1 – Diagnose the Exact Failure Point
Before changing any configuration, identify precisely where the failure occurs. Guessing wastes hours; systematic isolation takes minutes.
Browser console errors to look for
Open Chrome DevTools (F12) and check the Console and Network tabs while the web phone loads. Common error signatures:
- ICE failed, add a TURN server: STUN negotiation failed, no relay path found
- getUserMedia error: NotAllowedError: browser denied microphone access, usually because the page is not served over HTTPS.
Quick network test from an external machine
# Test if your STUN server is reachable from outside
# Replace YOUR_SERVER_IP with your Asterisk/VICIdial server's public IP
nc -u YOUR_SERVER_IP 3478
# If you get no response after 5 seconds, UDP 3478 is blockedStep 2 – Fix STUN and TURN Server Configuration
STUN (Session Traversal Utilities for NAT) allows the browser to discover its public IP. TURN (Traversal Using Relays around NAT) goes further, it relays all media traffic through an intermediate server when a direct peer-to-peer path is impossible. For remote workers behind strict corporate or residential firewalls, TURN is not optional: it is the only path that reliably works across all network topologies.
Option A – Use Google’s public STUN server (quick test only)
You can validate that STUN works at all by pointing VICIdial’s web phone at Google’s server temporarily: stun:stun.l.google.com:19302. If audio works after this change, your own STUN server was the problem. Do not leave this in production, it creates a dependency on a third-party service and has no SLA.
Option B – Deploy coturn on your own server (recommended for production)
coturn is an open-source, production-grade STUN/TURN server. Install it on your VICIdial server or a dedicated relay node.
# Ubuntu / Debian
sudo apt-get install coturn
# Enable the service
sudo nano /etc/default/coturn
# Uncomment: TURNSERVER_ENABLED=1
Minimal /etc/turnserver.conf for a VICIdial deployment:
listening-port=3478
tls-listening-port=5349
listening-ip=YOUR_SERVER_PRIVATE_IP
external-ip=YOUR_SERVER_PUBLIC_IP
realm=yourdomain.com
server-name=yourdomain.com
lt-cred-mech
user=vicidial:STRONG_PASSWORD
log-file=/var/log/turnserver.log
no-multicast-peers
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=192.168.0.0-192.168.255.255Security note: Never run coturn with no-auth in production. An open TURN relay can be abused as a free proxy by external parties. Always enforce lt-cred-mech with strong credentials.
Step 3 – Open the Right Firewall Ports
WebRTC media travels over RTP, which uses dynamically assigned UDP ports. If your firewall is not configured to pass this traffic, agents will connect and see a registered phone, but hear nothing on calls. This “one-way audio” or “no audio” symptom is the classic signature of a firewall blocking RTP.
Required ports for VICIdial WebRTC
- TCP 443 — HTTPS for the web interface and WebSocket signaling (WSS).
- TCP 8443 — Alternative WebSocket port if configured in Asterisk’s HTTP server.
- UDP 3478 — STUN server.
- TCP/UDP 5349 — STUN/TURN over TLS.
- UDP 10000–20000 — RTP media port range (Asterisk default; verify in /etc/asterisk/rtp.conf)
- UDP 5060 — SIP signaling (if using SIP alongside WebRTC).
On a Linux server using UFW:
sudo ufw allow 443/tcp
sudo ufw allow 8443/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349
sudo ufw allow 10000:20000/udp
sudo ufw reloadStep 4 – Resolve SSL / Certificate Issues
This is the single most overlooked cause of VICIdial WebRTC not working for remote agents. Browsers enforce a strict rule: microphone access (getUserMedia) is only permitted on pages served over HTTPS with a valid, trusted certificate. A self-signed certificate triggers a browser security warning, and even if the agent clicks through it, the WebSocket connection used for phone registration will frequently fail silently.
Obtain a free, trusted certificate with Let’s Encrypt
# Install Certbot
sudo apt-get install certbot python3-certbot-apache
# Issue a certificate (replace with your real domain)
sudo certbot --apache -d vicidial.yourdomain.com
# Certbot auto-renews; verify cron job
sudo systemctl status certbot.timer
Point Asterisk's HTTP server at the certificate
Edit /etc/asterisk/http.conf:
[general]
enabled=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/letsencrypt/live/vicidial.yourdomain.com/fullchain.pem
tlsprivatekey=/etc/letsencrypt/live/vicidial.yourdomain.com/privkey.pem
Reload Asterisk after saving: sudo asterisk -rx "module reload http"
Suggested image alt text #2:“VICIdial WebRTC not working fix, SSL certificate configuration in Asterisk HTTP server settings”
Step 5 – Correct VICIdial WebRTC Settings
Once the underlying network and certificate layers are correct, verify the VICIdial-side configuration.
Navigate to Admin → Servers in the VICIdial interface and confirm the following fields on your Asterisk server record:
- Server IP – must be the public-facing IP or DNS hostname, not 127.0.0.1 or a private LAN IP.
- WebRTC allowed – set to Y.
- Web Phone URL – must use https:// and your valid domain.
- Asterisk version – WebRTC requires Asterisk 13.7+ with res_http_websocket enabled.
Verify the PJSIP or chan_sip WebRTC endpoint
In/etc/asterisk/pjsip.conf, your WebRTC endpoint section should include:
[webrtc_endpoint](!)
type=endpoint
transport=transport-wss
context=default
disallow=all
allow=opus
allow=ulaw
dtls_auto_generate_cert=yes
webrtc=yes
ice_support=yes
use_avpf=yesComplete Step-by-Step Fix Process for VICIdial WebRTC Not Working
Read the browser console. Open DevTools on the agent’s browser and look for ICE failure, WebSocket failure, or getUserMedia errors. This tells you which layer to fix first.
Test external connectivity to your server. From an external network, ping your server’s public IP and confirm TCP 443 and UDP 3478 respond. Use an online port checker if you do not have an external machine available.
Validate your SSL certificate. Visit https://vicidial.yourdomain.com:8089/ws from a browser outside your LAN. If you see a certificate error, fix SSL before anything else.
Install and configure coturn. Deploy coturn on your server, configure it with your public IP, realm, and authenticated credentials. Open UDP 3478 and TCP/UDP 5349 in your firewall.
Update VICIdial’s web phone STUN/TURN settings. In the VICIdial admin, update the web phone configuration to point at your coturn server using the authenticated TURN URL: turn:YOUR_DOMAIN:3478?transport=udp
Open RTP media ports. Confirm UDP 10000–20000 (or your configured RTP range) is open bidirectionally on your firewall and any upstream security groups.
Reload Asterisk and test. Run asterisk -rx “core reload”, then have an agent outside the LAN log into the web phone and make a test call. Check /var/log/asterisk/full for ICE negotiation messages.
Confirm media path in Asterisk logs. A successful WebRTC call will show ICE completed in the Asterisk verbose log. If it shows ICE failed, re-examine the coturn configuration and firewall rules.
Real-World Use Case: 40-Seat Remote Contact Center
A sales contact center based migrated 40 agents to remote work. All agents had been using VICIdial’s web phone without issue on the office LAN. Within 24 hours of working from home, 80% reported that calls either would not connect or had no audio. Three agents on the same ISP had no problems at all, a clue that this was not a VICIdial software issue.
Investigation revealed two compounding problems.
First, the server was using a self-signed certificate that had been added to the office browsers’ trusted stores manually, remote browsers had no such exception and silently rejected the WebSocket upgrade. Second, the company’s Asterisk server had no STUN server configured at all; it had relied on LAN-local ICE candidates that were meaningless to agents behind home routers.
The fix took four hours: a Let’s Encrypt certificate was issued for the server’s FQDN, coturn was installed and configured with authenticated credentials, and the RTP range UDP 10000–20000 was opened on the AWS security group that had been inherited from the original deployment.
After a core reload of Asterisk, all 40 agents connected successfully without any changes to their own machines. The three agents who had experienced no issues turned out to be on a business broadband line with a fixed public IP and a less restrictive NAT, which had allowed a direct media path even without TURN.
Conclusion
When VICIdial WebRTC is not working for remote agents, the fix almost always lives in one of four places: missing STUN/TURN configuration, blocked RTP media ports, an untrusted SSL certificate, or incorrect server IP settings in the VICIdial admin. None of these are complex changes in isolation, the challenge is identifying which layer is the culprit without wasting hours on trial-and-error.
Use the systematic approach in this guide: start with the browser console error, validate SSL and WebSocket connectivity, deploy an authenticated coturn instance, open the correct firewall ports, and verify your Asterisk PJSIP endpoint configuration. That sequence resolves the vast majority of external-access WebRTC failures we encounter in the field.
For contact centers running production environments, where every failed call is a lost revenue opportunity or a frustrated customer, these configurations should be validated before any remote-work rollout, not after agents start reporting problems.
Need expert help with your VICIdial WebRTC deployment?
DialerKing’s engineers have configured and stabilized WebRTC environments across hundreds of contact center deployments. If your remote agents are still experiencing issues, we can audit your setup and resolve it fast.
Find Your Perfect Role