How to Bulk-Insert Phone Extensions Across Multiple Servers

On a multi-server VICIdial setup, agents may land on different boxes depending on load. To make that work, the same phone extensions need to exist on every server, or an agent who gets routed to a different box suddenly has no phone. Bulk Phone Insert is built for exactly this: feed it a list of server IPs and a list of extensions, and it creates every combination in one pass.

The two lists that drive it

The page takes two text areas, each one entry per line:

1. Servers - the IP address of each existing, active server you want phones created on. They must be valid IPs that are already live in the system.
2. Phones - the Extension for each phone, letters and numbers only, no special characters.

If you list three servers and ten extensions, you get thirty phone rows - each extension created on each server. That uniformity is the whole point: it is what lets an Agent log in with the same extension no matter which box ends up answering, and it is the foundation everything else in a multi-server setup rests on.

How the matrix expands

flowchart LR
  S1[Server 10.0.0.1] --> M[Insert matrix]
  S2[Server 10.0.0.2] --> M
  S3[Server 10.0.0.3] --> M
  E1[ext cc100] --> M
  E2[ext cc101] --> M
  M --> R[cc100 and cc101 on each server]
  R --> A{Create Alias Entries?}
  A -->|YES| B[Aliases tie servers together]

Set the shared values

Every phone in the batch shares the same Registration Password and Login Password, so pick a complex registration secret since it applies to the whole set at once. Choose your Client Protocol - SIP (Session Initiation Protocol), PJSIP, or IAX2 - and set the Phone Context that decides where the phone is allowed to dial in the Dialplan; a restrictive context here is a common way to stop agents dialing outside the application. If you want same-extension entries linked across the servers for load balancing, set Create Alias Entries to YES; that mechanism is covered in what Create Alias Entries does for phone login load balancing.

Two things to do every time

• Test small first. There is no undo - run two or three extensions across the servers, confirm they register on each box, then submit the full list.
• Rebuild conf files after. The insert does not rebuild Asterisk conf files for you; trigger the rebuild manually from System Settings or the Modify Server page or the phones will not come up.

One more thing about scale: because every server gets every extension, the number of rows grows quickly. Three servers and a hundred extensions is three hundred phones, all created in one click. That is exactly why the test-small habit matters - a mistake at that scale is a lot to undo by hand.

For the full field reference behind this page, see what the Bulk Phone Insert page does, and the wider toolset in our admin bulk tools guide.

Done right, this is how you keep a multi-server estate consistent: one extension list, one submit, identical phones on every box, and aliases linking them if you want load balancing on top. The discipline is always the same - test small, then rebuild conf files - and it scales cleanly as you add servers. Most VICIfast customers run a single dedicated box rather than a cluster, which keeps phone management simple and skips the multi-server matrix entirely. See VICIfast pricing to find the right fit.