Choose the release before choosing the server
Use this guide to evaluate ViciBox 12.0.2 in an isolated lab with synthetic records and authorized test endpoints. ViciBox is the official bootable VICIdial distribution. Its stable label identifies the published release channel. Before choosing it for production, verify who maintains each component and how security fixes will reach the deployed system.
Release check, 14 November 2026. ViciBox lists x86-64 12.0.2 as stable and 13.1.0 Beta 6 as test-only. The stable ISO shipped with openSUSE Leap 15.6 and Asterisk 18, both past upstream end of life. ViciBox’s PHP advisory calls for PHP 8.2.35 or later on affected ViciBox 12.0 servers. That update addresses the PHP advisory. The operating-system and Asterisk maintenance questions remain separate. Before a production rollout, obtain documented security maintenance coverage for the complete stack or wait for a maintained stable release. ViciBox release history · ViciBox 12 PHP advisory · openSUSE lifecycle notice · Asterisk lifecycle
Evidence and scope. The installation sequence follows the versioned ViciBox manual. The call matrix, recovery checks, and rollback scenario are proposed acceptance tests. CoreSecTech did not install or patch ViciBox, place carrier calls, restore a backup, or run the rollback.
Prepare the host and verify the ISO
Use a dedicated x86-64 host or isolated x86-64 VM with console access and an empty target disk. Size CPU for concurrent call legs and transcoding, RAM for the web and database roles, and storage for recordings, logs, and backups. Estimate recording storage from recorded minutes per day, measured bytes per minute, and retention days. Leave space for peak writes. Measure representative load before setting a seat limit. ViciBox 12 hardware guidance
Download the matching Standard or software RAID1 image over HTTPS from the official download page. Compare the checksum of the exact file with the value listed for that image and stop on a mismatch. The published MD5 can help detect a corrupted download. It provides limited integrity checking and cannot authenticate the publisher by itself. Prefer a signed checksum or other authenticated verification if the publisher provides it for the chosen image. Official ISO downloads and checksums
Install on an isolated network
- Documented workflow — prepare the network and install the base system. Reserve an address and hostname, identify DNS, gateway, and time sources, and retain console access. Keep management and database interfaces private. Boot the verified ISO and follow Phase 1 in the ViciBox 12.0 manual. Confirm the target disk before accepting the installer’s destructive disk operation. Use the manual’s intermediate phase for network setup and updates. The current
/latest/manual describes the beta release, so use the versioned manual for this lab. ViciBox 12.0 manual · Current beta manual and earlier versions - Documented workflow — install the application roles. Follow the ViciBox 12 Phase 2 Express Box procedure for a single host. It combines the web, database, and telephony roles. If availability or load requires separate hosts, review the cluster procedure and its network dependencies before provisioning. ViciBox 12 Phase 2
- Proposed acceptance check — verify the PHP update before opening access. Use the vendor’s ViciBox 12 advisory for the update and Apache restart. Its
php -vcheck reports the command-line runtime. Also verify that Apache is using the patched PHP build and that the application loads over the intended private HTTPS endpoint. Use private administrative evidence for the runtime check. If the package update, Apache restart, or runtime verification fails, keep the lab isolated. On a multi-host deployment, check every host running Apache, including archive servers where applicable. ViciBox PHP advisory - Proposed acceptance check — secure administrative access. Permit only the management, web, signaling, and media flows required by your chosen setup. Confirm the destination and direction of each rule against the actual network and carrier documentation. Use trusted HTTPS for the correct hostname before entering admin or agent credentials. Verify the certificate name, chain, expiry, and renewal path. Replace initial credentials, use named administrator accounts, and keep carrier secrets out of tickets and logs. Preserve the firewall and host security controls. ViciBox 12 networking and SSL guidance · Asterisk network security
Configure and verify one call path at a time
Use one test phone, one named test agent, one pilot campaign, and approved test destinations. Leave predictive dialing and production lists disabled. The table gives expected outcomes for a proposed pilot.
| Step | Set up | Expected result |
|---|---|---|
| Carrier | Confirm authentication method, transport, allowed destinations, caller ID, codecs, and media networks. | The intended trunk reaches an authorized test destination. |
| Phone and agent | Assign a test phone and grant the agent access to the pilot campaign. | The agent signs in over HTTPS and the phone leg connects. |
| Outbound | Manually dial a destination you control. | The call answers with two-way audio, ends cleanly, and saves a disposition. |
| Inbound | Map a test DID to an inbound group and define the no-agent destination. | The call reaches the eligible agent or the configured fallback. |
Match the SIP driver to the installed release. For a deployment using PJSIP, these read-only examples apply to an authorized Asterisk console. Confirm the driver and command availability first. pjsip show registrations describes outbound registrations. An IP-authenticated trunk may have no entry.
core show version
pjsip show registrationsA call that connects with one-way audio calls for a media-path check. Compare the advertised RTP addresses, configured media port range, carrier networks, and actual firewall or NAT path. A successful registration verifies signaling registration. Confirm media with a controlled call. Change one setting at a time and repeat the same test. Asterisk CLI help · PJSIP outbound registrations · PJSIP and NAT · VICIdial call-center pilot guide
Monitor service and rehearse recovery
Monitor failed trunks and calls, audio problems, agent login, database health, disk use, recording failures, and unusual destinations or call volume. Back up the database, managed configuration, and recordings required by policy. Record which versions, configuration, and recovery point belong together. Rehearse a compatible restore on an isolated host with live trunks disabled. Check that a test agent can sign in, campaign settings are intact, and required sample recordings can be retrieved. Measure recovery time and verify the amount of data recovered against your targets. MariaDB restore guidance
Illustrative rollback. If inbound audio fails after a network change, pause dialing and record the affected call path and the time of the change. Restore the last known-good setting on the device that owns it, then repeat the same inbound and outbound checks. If a database migration failed, preserve the failed system for diagnosis and use the rehearsed restore plan. Reconcile records created since the recovery point before reopening service. Keep the previous system available until the replacement passes the agreed checks. Allow only one system to place live campaign calls during cutover.