VICIdial Remote Agent Setup: NAT Traversal, WebRTC, and SIP Configuration

Remote work is no longer optional for call centers. Whether you are scaling into new geographies, hiring from a broader talent pool, or maintaining business continuity, your VICIdial deployment needs to handle agents who are not sitting on the same LAN as your Asterisk server. The challenge is that VoIP was designed for local networks, and the moment you introduce NAT, consumer firewalls, and variable internet connections, things break in ways that are difficult to diagnose.

This guide walks through every layer of remote agent configuration in VICIdial: choosing between SIP and WebRTC, solving NAT traversal, tuning Asterisk, locking down security, and optimizing audio quality for agents working from home.

SIP vs. WebRTC for Remote Agents

Before touching any configuration, you need to decide how remote agents will connect their audio. There are two paths, and each has real trade-offs.

Traditional SIP Softphones

With SIP, agents install a softphone application (Zoiper, MicroSIP, Linphone, or similar) on their workstation. The softphone registers to your Asterisk server over SIP (UDP 5060 or TCP 5060) and sends/receives RTP audio on a range of UDP ports.

Advantages:

• Mature technology with decades of optimization
• Lower CPU overhead on the server
• Codec flexibility (G.711, G.729, Opus)
• Works with hardware SIP phones if needed
• Better call quality ceiling when properly configured

Disadvantages:

• Requires NAT traversal configuration on both ends
• Agents must install and configure software
• Firewall rules are more complex (SIP signaling + RTP range)
• ALG (Application Layer Gateway) on consumer routers frequently mangles SIP packets
• Harder to troubleshoot remotely when an agent’s home network is the problem

WebRTC (Built-in Browser Phone)

VICIdial has included WebRTC support since version 2.14. Agents connect audio through their web browser using the same interface they already use for the agent screen. No softphone installation required.

Advantages:

• Zero software installation for agents
• Automatically traverses NAT (WebRTC was designed for it)
• Uses DTLS-SRTP encryption by default
• Single port (443/TCP for HTTPS, plus TURN relay if needed)
• Dramatically simpler agent onboarding

Disadvantages:

• Higher server CPU usage (transcoding between WebRTC codecs and carrier codecs)
• Opus codec may need transcoding to G.711 for PSTN handoff
• Browser updates can occasionally break WebRTC behavior
• Slightly higher latency compared to well-configured SIP
• Requires valid TLS certificates on the VICIdial web server

Our Recommendation

For centers with 25+ remote agents, we generally recommend WebRTC as the primary path. The reduction in support tickets from NAT and firewall issues more than offsets the slight audio quality trade-off. Keep SIP as a fallback for agents who have persistent WebRTC issues or who need hardware phones.

VPN vs. Direct SIP for Remote Agents

A common question from operations managers: should remote agents connect through a VPN, or should they connect directly to the Asterisk server over the internet? Both approaches work, and each solves different problems.

Direct SIP/WebRTC Connection (No VPN)

This is the standard approach covered in the rest of this guide. Agents connect directly from their home network to your Asterisk server.

Advantages:

• Simpler for agents — no VPN client to install or maintain
• Lower latency — audio packets take the shortest path
• WebRTC handles NAT automatically with ICE/STUN/TURN
• No VPN infrastructure to manage

Disadvantages:

• Asterisk ports (5060, 8089, 10000-20000) must be internet-facing
• Larger attack surface for SIP brute-force and scanning bots
• SIP ALG on consumer routers can mangle packets
• Harder to enforce security policies on agent workstations

VPN Connection

Agents establish a VPN tunnel to your network first, then their SIP/WebRTC traffic flows through the tunnel as if they were on the LAN.

Advantages:

• Asterisk stays behind the firewall — no public-facing SIP ports
• Eliminates NAT traversal entirely (agent appears to be on the LAN)
• Encrypted tunnel protects all traffic, not just media
• Can enforce security policies through the VPN (antivirus checks, OS version requirements)

Disadvantages:

• Adds 10-50ms latency depending on VPN protocol and server location
• VPN client must be installed and maintained on every agent workstation
• Split-tunnel vs. full-tunnel decision affects audio quality
• VPN server becomes a single point of failure for all remote agents
• Some VPN protocols (OpenVPN over TCP) add significant jitter to UDP VoIP traffic

Side-by-Side Comparison

Factor	Direct SIP/WebRTC	VPN + SIP
Added latency	0ms	10-50ms (WireGuard) to 30-100ms (OpenVPN TCP)
Agent setup complexity	Low (WebRTC) / Medium (SIP)	High (VPN client + SIP config)
Server attack surface	Higher — SIP/RTP ports exposed	Lower — only VPN port exposed
NAT traversal needed	Yes	No (agent is “on LAN”)
Audio quality impact	None	Slight — VPN adds jitter, especially OpenVPN
Best VPN protocol for VoIP	N/A	WireGuard (lowest overhead, UDP-native)
Scalability	Linear — each agent connects independently	Limited by VPN server bandwidth/CPU

Our Recommendation

For operations under 100 agents, use direct WebRTC connections with proper TURN server deployment. The simplicity and lower latency outweigh the security benefits of a VPN, especially when WebRTC already encrypts media with DTLS-SRTP.

For operations over 100 agents or those in regulated industries (healthcare, finance) where compliance requires encrypted tunnels for all traffic, use WireGuard VPN. WireGuard adds only 1-3ms of latency on typical connections, runs over UDP (matching VoIP traffic patterns), and is dramatically simpler than OpenVPN or IPsec. Avoid OpenVPN in TCP mode for VoIP traffic — the TCP retransmission overhead creates jitter spikes that cause audio artifacts.

If you do use a VPN, configure split-tunnel mode so only traffic destined for the VICIdial server goes through the VPN. Full-tunnel mode routes all internet traffic (including video streaming, web browsing) through your network, consuming VPN server bandwidth and adding latency to VoIP that gains nothing.

NAT Traversal: The Core Problem

When an agent sits behind a home router, their SIP phone sends packets with a private IP address (like 192.168.1.50) in the SIP headers and SDP body. Your Asterisk server sees the packet arriving from the router’s public IP, but the SIP protocol itself contains the private IP. This mismatch causes one-way audio, registration failures, and calls that connect but drop after 30 seconds.

How NAT Breaks SIP

Here is what happens step by step:

1. Agent’s softphone sends a SIP REGISTER with Contact: <sip:agent@192.168.1.50:5060>
2. The home router NATs this to the public IP, say 74.125.20.100:12345
3. Asterisk receives the packet from 74.125.20.100:12345 but the SIP header says 192.168.1.50:5060
4. Asterisk tries to send RTP audio to 192.168.1.50:5060 — which is unreachable
5. Result: one-way audio or no audio

STUN Servers

STUN (Session Traversal Utilities for NAT) lets the client discover its own public IP address. The softphone sends a binding request to a STUN server, which responds with the public IP and port it sees. The softphone then uses this information in its SIP headers.

For SIP softphones, configure the STUN server in the softphone settings:

STUN Server: stun.l.google.com:19302

Or run your own STUN server using coturn:

# Install coturn
yum install coturn -y

# /etc/turnserver.conf
listening-port=3478
listening-ip=0.0.0.0
external-ip=YOUR_PUBLIC_IP
realm=your-vicidial-domain.com
server-name=your-vicidial-domain.com
fingerprint
lt-cred-mech
user=vicidial:a-strong-password-here
no-tls
no-dtls
# Only enable STUN, not TURN (we'll add TURN later if needed)
no-tcp-relay

TURN Servers

STUN fails in roughly 15% of NAT scenarios (symmetric NAT, strict corporate firewalls). TURN (Traversal Using Relays around NAT) is the fallback. It relays all media through the TURN server, which guarantees connectivity at the cost of additional server bandwidth and latency.

For WebRTC, TURN is essential. Browsers will attempt direct connections first, then fall back to TURN automatically via the ICE (Interactive Connectivity Establishment) framework.

# /etc/turnserver.conf (full STUN + TURN config)
listening-port=3478
tls-listening-port=5349
listening-ip=0.0.0.0
external-ip=YOUR_PUBLIC_IP
relay-ip=YOUR_PUBLIC_IP
realm=your-vicidial-domain.com
server-name=your-vicidial-domain.com
fingerprint
lt-cred-mech
user=vicidial:a-strong-password-here
total-quota=100
stale-nonce=600
cert=/etc/letsencrypt/live/your-domain/fullchain.pem
pkey=/etc/letsencrypt/live/your-domain/privkey.pem
cipher-list="ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA384"
no-multicast-peers

Start and enable the service:

systemctl enable coturn
systemctl start coturn

Asterisk NAT Configuration

Asterisk needs to be told how to handle NATted endpoints. The two critical settings live in your SIP peer configuration.

The nat= Parameter

In /etc/asterisk/sip.conf (or in the peer definition within VICIdial’s admin interface under Phones), set:

[remote-agent-template](!)
type=friend
host=dynamic
nat=force_rport,comedia
qualify=yes
qualifyfreq=30

Here is what each nat option does:

• force_rport: Asterisk ignores the port in the SIP Via header and instead uses the port the packet actually arrived from. This solves the “SIP says port 5060, but NAT mapped it to port 23456” problem.
• comedia: Short for “connection-oriented media.” Asterisk ignores the IP/port in the SDP (media description) and instead sends RTP to the IP/port where it receives RTP from the agent. This solves one-way audio.

Together, force_rport,comedia tells Asterisk: “Don’t trust what the SIP headers say about where this agent is. Look at where the packets are actually coming from, and send responses there.”

The externip and localnet Settings

In the [general] section of sip.conf:

[general]
externip=YOUR_PUBLIC_IP
localnet=192.168.0.0/255.255.0.0
localnet=10.0.0.0/255.0.0.0
localnet=172.16.0.0/255.240.0.0

This tells Asterisk: “If a SIP endpoint is NOT on one of these local networks, use externip in the SIP headers instead of the internal IP.” Without this, Asterisk sends its private IP to remote agents, causing the same NAT problem in reverse.

If your public IP changes (dynamic IP from your ISP), use externhost instead:

externhost=sip.your-domain.com
externrefresh=60

RTP Port Range

Define a manageable RTP port range in /etc/asterisk/rtp.conf:

[general]
rtpstart=10000
rtpend=20000

This gives you 10,000 ports, enough for 5,000 concurrent calls. For a 25-50 agent center, you could narrow this to 10000-12000, which simplifies firewall rules.

WebRTC Setup with VICIdial

VICIdial’s built-in WebRTC support uses the WebPhone feature. Here is how to configure it end to end.

Step 1: Enable WebRTC in Asterisk

Add the WebSocket transport to sip.conf or http.conf:

; In /etc/asterisk/http.conf
[general]
enabled=yes
enablestatic=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/letsencrypt/live/your-domain/fullchain.pem
tlsprivatekey=/etc/letsencrypt/live/your-domain/privkey.pem

In sip.conf, allow the WebSocket transport:

[general]
transport=udp,ws,wss

Step 2: Configure Phone Entries for WebRTC

In VICIdial Admin, go to Phones and create or edit phone entries for remote agents. Key settings:

Phone Type: WebPhone
Protocol: SIP
Registration: Dynamic
NAT: force_rport,comedia
Transport: wss
Encryption: yes
AVPF: yes
ICE Support: yes

Or directly in the Asterisk peer config:

[webrtc-agent](!)
type=friend
host=dynamic
transport=wss
nat=force_rport,comedia
encryption=yes
avpf=yes
icesupport=yes
dtlsenable=yes
dtlsverify=fingerprint
dtlscertfile=/etc/asterisk/keys/asterisk.pem
dtlssetup=actpass
disallow=all
allow=opus
allow=ulaw

Step 3: Enable WebPhone in VICIdial

In the VICIdial Admin interface:

1. Go to System Settings and set WebPhone URL to your WSS endpoint
2. Under User Groups, enable WebPhone for the remote agent groups
3. In Phones, set the phone entry to use WebPhone with the appropriate server

The agent login screen will show a “WebPhone” checkbox. When enabled, audio runs through the browser via WebRTC instead of requiring an external softphone.

Step 4: TURN Server Integration

Configure VICIdial to pass TURN credentials to the WebRTC client. In the system settings or the WebPhone configuration:

TURN Server: turn:your-domain.com:3478
TURN Username: vicidial
TURN Password: a-strong-password-here

This ensures agents behind symmetric NAT can still connect.

Firewall Rules and Security

Remote agents mean your Asterisk server is exposed to the internet. This is the single biggest security risk in any VoIP deployment. SIP brute-force attacks and toll fraud are constant threats.

Required Ports

For SIP-based remote agents:

# SIP signaling
iptables -A INPUT -p udp --dport 5060 -j ACCEPT
iptables -A INPUT -p tcp --dport 5060 -j ACCEPT

# RTP media
iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT

# STUN/TURN
iptables -A INPUT -p udp --dport 3478 -j ACCEPT
iptables -A INPUT -p tcp --dport 3478 -j ACCEPT

For WebRTC-only remote agents:

# HTTPS (WebRTC signaling via WSS)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# TURN relay (TCP fallback)
iptables -A INPUT -p tcp --dport 3478 -j ACCEPT
iptables -A INPUT -p udp --dport 3478 -j ACCEPT

# TURN TLS
iptables -A INPUT -p tcp --dport 5349 -j ACCEPT

Notice that WebRTC needs far fewer open ports. This is a significant security advantage.

Fail2Ban for SIP

Install and configure Fail2Ban to block SIP brute-force attempts:

# /etc/fail2ban/jail.local
[asterisk]
enabled = true
port = 5060,5061
filter = asterisk
logpath = /var/log/asterisk/messages
maxretry = 3
bantime = 86400
findtime = 600

The Asterisk filter (/etc/fail2ban/filter.d/asterisk.conf) should catch failed registration attempts:

[Definition]
failregex = NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Username/auth name mismatch
            NOTICE.* <HOST> failed to authenticate as '.*'
            NOTICE.* .*: No registration for peer '.*' \(from <HOST>\)
            NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*'

SIP Peer Security

Never use weak passwords for SIP peers. Generate strong credentials:

openssl rand -base64 24

In the peer configuration:

[1001]
secret=kX7mN2pQ9vR4sW8yA3bF6hJ0  ; generated, not guessable
deny=0.0.0.0/0.0.0.0
permit=0.0.0.0/0.0.0.0            ; allow from anywhere (remote agents)
call-limit=2                       ; prevent toll fraud abuse

For environments where agents have static IPs (office-based remote sites), lock down the permit field to those specific IPs.

Rate Limiting with iptables

Add rate limiting to slow down SIP scanning bots:

iptables -A INPUT -p udp --dport 5060 -m recent --set --name SIP
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 60 --hitcount 20 --name SIP -j DROP

Audio Quality Optimization for Remote Workers

Home internet connections are unpredictable. Here is how to maximize audio quality despite variable network conditions.

Codec Selection

For remote agents, codec choice matters more than in a LAN environment:

Codec	Bandwidth	Quality	CPU	Best For
G.711 (ulaw)	87 kbps	Excellent	Low	LAN, stable connections
G.729	31 kbps	Good	Medium	Low bandwidth, licensed
Opus	6-510 kbps	Excellent	Medium	WebRTC, variable bandwidth

For SIP remote agents, use G.711 if bandwidth is sufficient (most home connections have plenty). G.729 saves bandwidth but adds transcoding overhead and requires a license per concurrent channel.

For WebRTC agents, Opus is the native codec and adapts its bitrate dynamically. It is the best choice for variable home internet.

Configure codec priority in the peer:

[remote-sip-agent]
disallow=all
allow=ulaw
allow=alaw
allow=g729    ; fallback for bad connections

[remote-webrtc-agent]
disallow=all
allow=opus    ; native WebRTC codec
allow=ulaw    ; fallback

Jitter Buffer Configuration

Jitter (variation in packet arrival time) is the primary quality killer for remote agents. Configure Asterisk’s jitter buffer:

; In sip.conf [general] or per-peer
jbenable=yes
jbforce=yes
jbmaxsize=200       ; max buffer in ms
jbresyncthreshold=1000
jbimpl=adaptive      ; adapts to network conditions
jblog=no             ; disable in production for performance

The adaptive jitter buffer adjusts its size based on observed network conditions, which is critical for home internet connections that vary throughout the day.

QoS and DSCP Marking

While you cannot control the agent’s home network QoS, you can mark packets leaving your server so that any QoS-aware network equipment along the path gives VoIP traffic priority:

; In /etc/asterisk/rtp.conf
[general]
tos_audio=ef         ; Expedited Forwarding (DSCP 46)
cos_audio=5

; In sip.conf
tos_sip=cs3          ; SIP signaling
cos_sip=3

Agent Network Requirements

Document minimum requirements for remote agents:

• Download speed: 1 Mbps minimum (5 Mbps recommended)
• Upload speed: 512 Kbps minimum (2 Mbps recommended)
• Latency: Under 150ms to server
• Jitter: Under 30ms
• Packet loss: Under 1%
• Connection type: Wired Ethernet strongly recommended (Wi-Fi adds jitter)

Provide agents with a quick test they can run:

# Ping test to VICIdial server
ping -c 100 your-vicidial-server.com

# Check for packet loss and latency variation
# Look for: avg latency < 150ms, 0% packet loss

Home Network QoS Settings for Remote Agents

While you cannot control the internet between the agent’s ISP and your server, you can optimize the agent’s local network. Home router QoS (Quality of Service) settings prioritize VoIP traffic over downloads, streaming, and other bandwidth consumers on the same home network.

Why Home QoS Matters

A typical home network scenario: the agent is on a call, and someone in the household starts a Netflix stream or a large download. Without QoS, the router treats all packets equally. The download saturates the upload queue (TCP ACKs), VoIP packets get queued behind hundreds of download ACK packets, and the agent hears choppy audio or the customer gets silence gaps of 200-500ms.

With QoS configured, the router identifies VoIP packets and moves them to the front of the queue, keeping latency and jitter low even when the connection is saturated.

Router-Specific QoS Instructions

Provide agents with instructions for their specific router brand. Here are the most common configurations:

ASUS routers (RT-AX series, RT-AC series):

1. Log into router at 192.168.1.1 or router.asus.com
2. Go to Adaptive QoS > QoS
3. Enable QoS and set your Upload Bandwidth and Download Bandwidth to 85% of your actual speeds (this headroom prevents bufferbloat)
4. Set mode to Adaptive QoS or Traditional QoS
5. Under priority rules, drag VoIP/Messaging to the Highest priority tier
6. Click Apply

Netgear routers:

1. Log into router at 192.168.1.1 or routerlogin.net
2. Go to QoS Setup under Advanced
3. Enable QoS and set Internet Bandwidth (use fast.com to measure actual speeds)
4. Under QoS Priority Rule, add a rule for your VICIdial server IP with Highest priority
5. Click Apply

TP-Link routers:

1. Log into router at 192.168.0.1 or tplinkwifi.net
2. Go to Advanced > QoS
3. Enable QoS and enter upload/download bandwidth at 85% of actual
4. Add a High Priority rule for traffic to your VICIdial server IP
5. Save settings

Generic approach (works on most routers): If the router does not have application-aware QoS, create a priority rule based on the VICIdial server IP address. Any traffic to/from that IP gets highest priority. This catches both SIP signaling and RTP audio.

The DSCP Approach (Advanced)

If agents have routers that support DSCP-based QoS (most business-grade routers and some consumer models), configure Asterisk to mark outbound packets with DSCP values:

; Already configured on your server in rtp.conf
[general]
tos_audio=ef         ; DSCP 46 — Expedited Forwarding
cos_audio=5

; In sip.conf
tos_sip=cs3          ; DSCP 24 — SIP signaling
cos_sip=3

Then configure the agent’s router to prioritize packets marked with DSCP EF (46). This is more reliable than IP-based rules because it works regardless of which server IP the agent connects to.

Agent Network Testing Script

Provide agents with this simple test they can run to verify their network is ready for VoIP:

# Test 1: Latency and packet loss to VICIdial server
ping -c 100 your-vicidial-server.com
# Target: avg < 100ms, 0% packet loss

# Test 2: Jitter measurement (requires mtr)
mtr --report --report-cycles 100 your-vicidial-server.com
# Target: Jvg column < 15ms on all hops

# Test 3: Upload bandwidth
curl -o /dev/null -w "%{speed_upload}" -T /dev/zero http://speedtest-server --max-time 10
# Target: > 1 Mbps upload

For non-technical agents, direct them to speed.cloudflare.com which measures all these metrics in a browser. The “loaded latency” metric is particularly useful — it shows latency under load, which simulates real-world conditions when other devices are active on the network.

Troubleshooting Common Remote Agent Issues

One-Way Audio

Symptom: Agent can hear the customer but customer cannot hear the agent (or vice versa).

Diagnosis:

# On the Asterisk server, check RTP flow during an active call
asterisk -rx "rtp set debug on"

# Check if Asterisk is sending RTP to the correct address
asterisk -rx "sip show channel <channel-name>"

Common fixes:

1. Verify nat=force_rport,comedia is set
2. Check externip is correct
3. Ensure RTP port range is open in firewall
4. Disable SIP ALG on the agent’s home router (this is the #1 cause)

To disable SIP ALG, agents typically need to access their router admin panel. Common locations:

• Netgear: Advanced > WAN Setup > Disable SIP ALG
• Linksys: Security > Firewall > Disable SIP ALG
• TP-Link: Advanced > NAT Forwarding > ALG > Disable SIP ALG

Registration Drops

Symptom: Agent phone registers successfully but drops after 30-120 seconds.

Diagnosis:

asterisk -rx "sip show peers" | grep "remote-agent"
# Look for Qualify: OK vs. UNREACHABLE

Common fixes:

1. Set qualifyfreq=25 (keep-alive interval, must be less than NAT timeout)
2. Enable qualify=yes on the peer
3. On the softphone, set registration expiry to 60 seconds (not 3600)
4. Check if the agent’s firewall is blocking inbound UDP after a timeout

Audio Choppy or Robotic

Symptom: Audio cuts in and out or sounds distorted.

Diagnosis:

# Check for packet loss on the server side
asterisk -rx "rtp set debug on"

# Monitor system load (transcoding overhead)
top -bn1 | head -20

Common fixes:

1. Switch from Wi-Fi to wired Ethernet
2. Reduce codec bitrate (switch to G.729 or lower Opus bitrate)
3. Increase jitter buffer size
4. Have the agent close bandwidth-heavy applications
5. Check if the agent’s ISP is throttling UDP traffic

WebRTC Connection Failures

Symptom: Agent clicks WebPhone but audio never connects.

Diagnosis:

• Open browser developer tools (F12) > Console tab
• Look for WebSocket connection errors or ICE negotiation failures

Common fixes:

1. Verify TLS certificates are valid and not expired
2. Check that WSS port (8089 or 443) is accessible
3. Ensure TURN server is running and credentials are correct
4. Try a different browser (Chrome and Firefox have the best WebRTC support)
5. Check that the agent is not on a network that blocks WebSocket connections (some corporate VPNs do this)

Echo or Feedback

Symptom: The customer or agent hears an echo of their own voice.

Common fixes:

1. Require agents to use headsets (not laptop speakers/mic)
2. Enable echo cancellation in the softphone settings
3. In Asterisk, enable echocancel=yes on the channel if using DAHDI
4. Reduce the agent’s speaker volume (echo is often caused by the mic picking up speaker output)

Scaling Remote Agent Deployments

When scaling beyond 50 remote agents, consider these architectural decisions:

Dedicated Media Proxy

Run RTPproxy or RTPengine as a dedicated media relay. This offloads RTP processing from Asterisk and gives you a single point to handle NAT traversal:

# Install RTPengine
yum install rtpengine -y

# /etc/rtpengine/rtpengine.conf
[rtpengine]
interface=YOUR_PUBLIC_IP
listen-ng=127.0.0.1:2223
port-min=30000
port-max=40000
log-level=5

Geographic Distribution

For agents spread across time zones or countries, consider placing Asterisk servers or media proxies in multiple regions to reduce latency. A hub-and-spoke model with IAX2 trunking between servers keeps centralized management while distributing media handling.

Monitoring

Deploy monitoring that catches remote agent issues before they cause missed calls:

# Check registration status for all remote agents
asterisk -rx "sip show peers" | grep -c "OK"

# Alert if registration count drops below expected
EXPECTED=50
ACTUAL=$(asterisk -rx "sip show peers" | grep -c "OK")
if [ "$ACTUAL" -lt "$EXPECTED" ]; then
    echo "WARNING: Only $ACTUAL of $EXPECTED agents registered"
fi

How ViciStack Helps

Configuring remote agents involves touching Asterisk SIP settings, NAT traversal, firewall rules, codec selection, jitter buffers, TURN servers, and WebRTC — all of which interact in ways that are difficult to predict. A misconfiguration in one layer often manifests as a symptom in another, and troubleshooting across dozens of agents’ home networks is time-consuming.

ViciStack manages the entire remote agent stack for VICIdial centers running 25+ agents:

• NAT traversal configuration tuned to your specific network topology
• TURN server deployment and management so WebRTC agents always connect
• Asterisk peer templates optimized for remote connections with proper nat, qualify, and codec settings
• Firewall hardening with Fail2Ban rules and rate limiting specific to your deployment
• Audio quality monitoring that catches degradation before agents report it
• 24/7 troubleshooting for the one-way audio calls and registration drops that eat into your connect rates

We have configured remote agent setups for over 100 VICIdial call centers. We know which consumer routers mangle SIP, which ISPs throttle UDP, and which WebRTC edge cases will burn hours if you hit them unprepared.

Get a free analysis of your VICIdial remote agent setup. We will review your Asterisk configuration, identify NAT traversal gaps, and show you exactly where audio quality is being lost.

Request your free ViciStack analysis — response in under 5 minutes.

Frequently Asked Questions

How do I set up VICIdial for work-from-home agents?

The minimum setup for VICIdial remote agents requires three things: (1) Enable WebRTC in VICIdial by configuring PJSIP with WebSocket transport and installing an SSL certificate — agents then connect audio through their browser with no software to install. (2) Configure NAT traversal by setting nat=force_rport,comedia on all remote agent SIP peers and deploying a STUN/TURN server for WebRTC connections. (3) Open the required firewall ports — for WebRTC, that is port 443 (HTTPS), 8089 (WSS), and 3478 (TURN). Each remote agent needs a phone entry in VICIdial Admin configured for their connection type (WebRTC or SIP). Agents need a minimum of 5 Mbps download, 1 Mbps upload, wired Ethernet, and a USB headset.

Why do my VICIdial remote agents have one-way audio?

One-way audio is almost always a NAT traversal problem. The four most common causes in order of frequency: (1) SIP ALG is enabled on the agent’s home router — this rewrites SIP headers and breaks media negotiation. Have the agent log into their router admin and disable SIP ALG. (2) The Asterisk peer is missing nat=force_rport,comedia — without this, Asterisk sends RTP to the private IP in the SIP headers instead of the actual source IP. (3) The externip or external_media_address setting in Asterisk is wrong or missing — Asterisk advertises its private IP to remote endpoints, and they cannot route audio back. (4) The RTP port range (10000-20000 by default) is blocked by the server firewall. Check each of these in order, and you will find the cause in 95% of cases.

What is the best internet speed for VICIdial remote agents?

For reliable VoIP audio on VICIdial, agents need at minimum 1 Mbps upload and 5 Mbps download, with latency under 150ms to the server. The upload speed matters more than download for VoIP because the agent’s voice must reach the server in real time. In practice, any modern broadband connection (cable, fiber, or DSL) provides sufficient bandwidth. The real killers are latency, jitter, and packet loss. Target under 100ms latency, under 30ms jitter, and under 1% packet loss. Satellite internet (500ms+ latency) and severely congested shared connections are not suitable for call center work. Wired Ethernet to the router is strongly recommended — Wi-Fi adds variable jitter of 5-50ms that causes intermittent audio quality problems.

Related Articles

• VICIdial Server Performance Tuning — optimize the server your remote agents connect to
• VICIdial Database Partitioning for High-Volume Call Centers — keep the backend fast as you scale
• VICIdial Timezone-Aware Dialing and TCPA Compliance — manage calling windows across agent time zones
• VICIdial WebRTC Setup Guide for Remote Agents — complete WebRTC configuration for browser-based agent audio
• VICIdial Disaster Recovery & High Availability Guide — keep remote agents connected during infrastructure failures