Where are my trunks in VICIdial admin?

If you opened VICIdial admin → Admin → Carriers and found an empty list, nothing is broken — that’s expected. VICIfast never writes to VICIdial’s Carriers table. Your outbound routing lives in two files we manage on the box: /etc/asterisk/vicifast-trunks.conf (the SIP side) and /etc/asterisk/vicifast-trunks-dialplan.conf (the dialplan, included from extensions.conf). Both are rendered straight from the platform database.

Why the Carriers table stays empty

VICIdial’s Carriers screen was built for hand-managed Asterisk installs, where the admin textarea was the only way to inject a dialplan entry. We render the dialplan file directly, so a Carriers row would just duplicate state — and a second source of truth is exactly how hand-built dialers drift.

What to use instead

• Add, edit, or disable a trunk — dashboard → Servers → your server → Trunks tab, then Add trunk (or click a trunk’s row to open its drawer).
• Point a campaign at a trunk — open the trunk’s drawer → Routing & campaigns and link the campaign there. Linking sets the campaign’s dial prefix to the trunk’s 4-digit prefix (trunks draw from the 9000–9499 pool).
• Build a failover route — the Failover routes pill in the same tab. Routes try several outbound trunks in order and get their own prefix from the 9500–9999 pool.
• TCPA per trunk — the drawer’s Compliance (TCPA) section; see TCPA compliance (/help/tcpa-compliance).

If you’d rather edit files by hand

You can — but both managed files warn in their header: they are rewritten end-to-end on every trunk operation, so manual edits are overwritten the next time you save anything in the Trunks tab. For a custom dialplan that survives, use the trunk drawer → Dialplan & advanced → Custom dialplan (advanced). Your version is stored on the trunk and re-applied on every save.

On an older server?

Very early VICIfast servers had trunks written straight into pjsip.conf. If that’s you, open a support ticket — we run a one-shot migration that strips the old blocks, writes the two managed files from current platform state, and reloads PJSIP and the dialplan. It’s idempotent, so running it twice is harmless.