Agent stations on Vicidial — hardphone vs WebRTC vs softphone tradeoffs and the MeetMe room model

Vicidial® agents need a phone endpoint to receive the call — "phone" here meaning a SIP endpoint, in whatever form. The agent also needs a browser at the Vicidial agent GUI. The two are decoupled in Vicidial's architecture: the GUI controls the call, the phone endpoint carries the audio. Picking the right phone form factor is what we cover here, plus the often-confusing MeetMe conference model that underlies it all.

The MeetMe model — why agent audio works the way it does

Vicidial's predictive engine doesn't ring an agent's phone for each call. Instead, at the start of the agent's shift, the agent "logs in" — which means their phone joins a private MeetMe conference room (one per agent). The conference is held silently when there's no call to bridge.

When the dialer finds an answered call, it bridges that channel into the agent's MeetMe room. The agent hears the audio without their phone re-ringing. Hang up the call, the dialer drops it from the room, and the agent is back to held silence waiting for the next bridge.

Implications:

• The agent's phone is on a long-running call from login to logout — it never re-rings. Whatever endpoint they use, it needs to sit happily on a 4-hour SIP call without dropping.
• Audio quality is end-to-end between the called party and the agent through the MeetMe conference. Codec choice matters for both legs.
• If the agent's network drops momentarily and the SIP call re-registers, they're disconnected from their MeetMe and will miss bridges until they re-log into Vicidial. Stable agent connectivity is non-negotiable.

Option A: Hardphones

An IP desk phone (Polycom, Yealink, Snom, Grandstream) registered as a SIP extension to the ViciBox server. Most stable option; agents pick up a familiar handset. Cost is the upfront hardware (~$80-150/phone) and the per-agent provisioning.

Best for: a permanent in-office team. Agents don't have to debug audio. Headset port handles agent acoustics.

Worst for: remote agents — you're shipping hardware, dealing with home NAT, and supporting whatever ISP they're on.

Vicidial extension config: Admin → Phones → Add. Set extension to a numeric ID, generate a password, set protocol=SIP, active=Y. Provision the phone with that extension number, password, and the ViciBox VPS as the SIP server. Audio codec: G.711 ulaw (US) or alaw (EU) for predictive — Opus is tempting but not all SIP endpoints behave on long MeetMe calls with Opus.

Option B: WebRTC in the agent's browser

The agent's browser is the SIP endpoint — no install, no hardware. ViciBox ships with the necessary WebRTC support already in the agent interface; you enable it per-phone.

Best for: remote agents, hot-desking, BYOD shops. Zero shipping. Onboarding is "open this URL with a headset plugged in."

Worst for: any environment with flaky agent-side networking — WebRTC is much more sensitive than hardphones to packet loss, and the failure mode is choppy audio rather than a clean reconnect.

WebRTC requires a real TLS certificate on the ViciBox web endpoint (browsers refuse WSS over self-signed). See the WebRTC article in this category for the per-step setup. The short version: install a real cert via certbot, enable WSS on Asterisk's HTTP server, configure the per-agent phone with protocol=WEBRTC in the Vicidial phone record, have the agent use a wired headset (USB or 3.5mm — Bluetooth adds latency that breaks call rhythm).

Option C: Desktop softphones (Zoiper, X-Lite, MicroSIP)

A SIP softphone runs on the agent's PC, registered to the ViciBox server like a hardphone would be. Less stable than a hardphone (depends on the agent's OS staying responsive), more stable than WebRTC.

Best for: intermediate setups — your agents have their own machines, but you don't want to depend on browser audio. MicroSIP (Windows, free) is the workhorse; Zoiper Free works cross-platform with banner ads, Zoiper Pro is paid.

Worst for: diverse OS environments — softphone configuration drift across Windows, macOS, and Linux is the ongoing tax.

Provisioning is the same as the hardphone path; the agent just enters credentials in the softphone instead of plugging them into a desk phone.

Which to pick

Codec choices for the agent leg

Predictive dialing rewards codec stability over codec quality. For carrier-leg → MeetMe → agent-leg, you want:

• G.711 ulaw end-to-end in the US. Carrier almost certainly supports it, MeetMe is happy with it, hardphones default to it.
• G.711 alaw end-to-end in EU (LYLIX Frankfurt) for similar reasons.
• Avoid Opus on long MeetMe calls — clean theoretically, in practice some hardphones have memory leaks and Asterisk's transcoding load is non-trivial at scale.
• G.729 only if your carrier requires it for cost reasons and you've licensed the codec module. Most carriers now accept G.711 without surcharge.

Common failure modes

• Agent's headset is Bluetooth. 150-300ms of added latency. Calls feel laggy, agents talk over the prospect. Mandate wired headsets.
• Agent's home upload is asymmetric DSL. Tolerable for single calls, breaks when their kid starts a Zoom upload. Document a minimum upload spec (1 Mbps sustained per agent for G.711) as part of remote-agent onboarding.
• Agent leaves MeetMe by hanging up the wrong way. Vicidial expects them to use the GUI's Pause/Resume; if they put the desk phone on hook, the MeetMe drops and they miss bridges. Train on this once.
• Browser tab backgrounded with WebRTC agent. Chrome throttles background tabs; the agent stops getting bridges. WebRTC agents should keep the Vicidial tab foregrounded.