r/VICIdial

Hey all — long-time lurker, sharing what we've been building because we want the honest edge cases from people who actually run Vicidial in production.


We've been wiring up automated agents (AI, but the AI part is not really the point of this post) to run as Vicidial seats. The constraint we set ourselves up front:
- **No server-side patches.** Touching the Vicidial source or schema kills the support contract for any real install. Not an option.
- **No headless Chromium per agent.** Tried it, like everyone else does. ~400 MB RSS per seat, breaks every time viciphone ships a CSS change, the cron jobs lose their minds when 50 of them start at once. Dead end.

So the approach is a Go process that speaks the same protocols viciphone does, without the browser around them:

- SIP signalling over WSS to Asterisk's wss port, same handshake viciphone does (DTLS-SRTP for media, ICE for NAT).
- The viciphone HTTP endpoints: `agent_login`, `vicidial_manager_send`, `conf_exten_check`, the keepalive endpoint, disposition save, pause/resume — same URLs, same params, same cookies viciphone uses.
- One registered SIP leg per AI seat. Vicidial sees a normal agent. The `vicidial_live_agents` row updates the way it does for any agent.
- Agent stats, dispositions, list_id, campaign_id, hopper draws — all flow through Vicidial's normal paths because the dialer is just talking to a registered endpoint, same as it always has.

What's working today:

- Inbound and outbound calls land, get answered, get dispositioned, hangup cleanly.
- Pause / resume tracks correctly in `vicidial_agent_log`.
- Memory cost is roughly 20–30 MB RSS per active seat instead of ~400 MB. ~50 AI seats fit on a small VM where 50 viciphones wouldn't.
- Dial method tested with RATIO and ADAPT_TAPERED. Outbound list rotation works.


What's still flaky / things we're hunting:

- **3-way and warm transfers** — the conference logic works in the happy path but we've seen the AI seat occasionally not leave the conf cleanly when the human supervisor drops first. Suspect a `conf_exten_check` race, still digging.
- **Manual dial / preview dial flows** are less tested than predictive.
- **NOANSWER / NA / DROP** dispositioning under sudden carrier congestion — Vicidial's expected state transitions are mostly documented by reading the code, and we have at least one path where the agent goes to PAUSED instead of READY after a fast hangup chain. Reproducing intermittently.
- **Recording**: we let Vicidial handle MixMonitor on the Asterisk side rather than recording in our process, so that part is "Vicidial's job and it works", but we haven't stress-tested at full agent count yet.


What we **don't** do (in case anyone's wondering):

- We don't talk to Asterisk AMI directly. Everything goes through Vicidial's existing HTTP surface, the same way viciphone does. That's deliberate — AMI access feels like the kind of thing a Vicidial upgrade would silently break.
- We don't touch the database. Reads or writes. Vicidial owns its own state.

Tested against: Vicidial v2.14-895a.

**The ask, if you've made it this far:**

1. What viciphone behavior have you seen in production that's *not* obvious from reading the code? Cookies that get re-issued, endpoints that quietly changed between releases, anything where the docs say one thing and the wire says another.
2. If you've automated Vicidial seats before — even via headless browser — what broke under load that we should specifically be testing for?
3. Anyone with a campaign that's heavy on 3-way / warm transfer / supervisor barge — what does the conf_exten_check + manager_send sequence look like in your environment? We want to make sure we match it before we put this anywhere near a real hopper.


DMs are open if anyone wants to compare notes on the protocol details specifically. Not selling anything, not pointing anywhere — just want the production-Vicidial sanity check before we trust this further than our lab.


Thanks for reading.

Hi,

We right now have a 10year old system running vicidial v5 or something old. Our current usage is only manuall dials inbound and outbound(30:70 inboud:outbound), no predective or auto dialer.

Our peak concurrent calls were max 7. 23 agents setup but mostly they are on idle and calls are dialed as I say manual.

We are planning to expand our operations to multiple locations, so can go 4x from here, 28 parallel calls. Right now one location local server will have 3 more office connect to this. This is not something immediate but over next 5 years

We want to also move to viciphone webrtc from our 3cx, main reason we are also doing this is we also want to move to vicidial v12.

Here we would want have server preferably dell, which can handle ~10 parallel calls now as i said also in future upto ~30 calls

What can be a good server here, preferably looking at something around 1500 -1700usd.

Appreciate any help