What ViciPhone needs: Asterisk 13+ and real SSL certs

Before a single agent can take a call on ViciPhone, two infrastructure requirements have to be true, and skipping either one is the usual reason a fresh setup never registers and you spend an afternoon chasing the wrong thing. ViciPhone is the browser Softphone built for VICIdial, and a softphone is just a phone implemented in software instead of a physical handset. This post explains why Asterisk 13 and genuine SSL are non-negotiable, what each one is doing under the hood, and how to confirm both before you start debugging conf templates or agent settings.

Asterisk 13 or higher, on every server

Native WebRTC support arrived in Asterisk 13. Earlier releases cannot terminate the secure WebSocket and media that a browser phone expects, so the version floor is a hard line, not a recommendation you can stretch. The requirement applies to every Asterisk server an agent might land on, not just the one you happened to test first. If you run more than one box, a single old server in the mix means agents who get routed to it find a phone that never comes up, while everyone else is fine, which makes the problem look intermittent and maddening to chase.

On the media side, voice still travels over RTP, the real-time transport protocol, exactly the same as any other VoIP call on the system. What changes with a browser phone is that the signalling and media negotiation are wrapped for WebRTC, and that wrapping is precisely the part Asterisk 13 added. Older boxes speak RTP perfectly well for hardphones; they just cannot do the browser-side negotiation.

Authentic SSL certificates everywhere

You must have authentic SSL certificates for every Asterisk server and webserver that agents log into. Authentic means issued by a recognised certificate authority, not self-signed. Browsers will not grant microphone access or open a secure WebSocket to a host whose certificate they do not trust, and there is no override flag that survives a real production rollout. This is closely related to SIP over TLS, which is SIP carried over a TLS-encrypted channel: the certificate is what makes that channel trusted in the first place, so a missing cert and a broken phone are the same failure seen from two angles.

• Certificate on the webserver that serves the agent screen.
• Certificate on every Asterisk server the phone connects to.
• Issued by a real certificate authority. Self-signed certs fail silently in the browser.

How the two requirements gate a login

flowchart TD
  A[Agent opens phone] --> B{Cert trusted by browser}
  B -- No --> C[No mic and no socket]
  B -- Yes --> D{Asterisk 13 or higher}
  D -- No --> E[WebRTC not supported]
  D -- Yes --> F[Phone registers and takes calls]

Both gates have to pass, in that order. A trusted certificate with an old Asterisk still fails, and a current Asterisk behind a self-signed certificate fails too. Treat them as a two-item checklist you confirm before touching anything else: load the agent screen, check there is no browser security warning, then verify the Asterisk version on the box the agent actually reaches. Only after both are green is it worth looking at conf templates or phone settings.

The wider picture of browser and external phones lives in our pillar on VICIdial remote agents, and the step-by-step setup is in how to set up the ViciPhone WebRTC softphone. If sourcing and renewing certificates across servers sounds like a chore you would rather skip, our managed plans provision a box with Asterisk and valid SSL already configured.