u/Weekly_Specialist879

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.