ViciBox Express lab: Phase 2 and first safe verification

Start here

ViciBox Express is the single-server Phase 2 path. After its documented installer and reboot finish, verify the telephony stack from the command line before you ever log into the web interface — a web page loading is not proof the dialer stack underneath it is healthy.

Express is named for what it is not: a multi-server cluster with separate database, web, and telephony roles split across machines. Everything runs on one host here, which is exactly what makes it the right choice for a first lab — there is only one machine's worth of status to verify, not several machines that all have to agree.

Use the vendor’s Phase 2 procedure for this installer. Follow its reboot direction, reconnect to the lab console, and then continue with the read-only checks below.

The idea in plain language

Asterisk is the telephony engine beneath VICIdial. It can be running perfectly well with no carrier connection, no campaign, no agent, and no call in progress — that is exactly the safe, quiet state you want to confirm on a first lab check, before you connect anything real to it.

The verification order in this lesson matters: confirm the engine is alive first, confirm its supporting processes came up second, confirm its telephony configuration loaded third, and only then touch the web interface. Each step rules out one layer, so that if something is eventually wrong, you already know which of the four it is not.

This ordering is also a template for troubleshooting a lab weeks from now, not just for a first install. When something in VICIdial eventually misbehaves, working from the bottom up — engine, then processes, then telephony configuration, then the web layer — will usually locate the fault faster than starting from whatever screen happened to show an error first.

After Phase 2, check Asterisk's status

Complete the vendor’s Express Phase 2 procedure linked in this article’s sources, then reboot as directed. This page verifies the result; it does not give every installer prompt. Ask Asterisk for its version and uptime. Neither command changes configuration or places a call. On the documented lab build Asterisk runs in a screen session, so a systemd status alone did not establish whether Asterisk was running. Other installations may manage it differently; check their service configuration.

asterisk -Vasterisk -rx 'core show uptime'

Confirm the screen sessions came up

Phase 2 also starts the astguiclient dialer-control processes inside detached screen sessions. Their presence is a useful second signal, independent of Asterisk's own status.

The recorded lab showed 12 sessions; that is a historical observation, not a required count or a session ID to copy to another installation.

screen -ls lists sessions for the account running it. The historical capture inspected root-owned sessions; an empty list for another user does not prove the root sessions are absent. Ask an authorized administrator to inspect the actual service-owning account.

screen -ls

Recorded lab terminal: screen sessions

Open to enlarge

Confirm PJSIP is alive, with no carrier yet

This is the deferred check from the earlier SIP-basics lesson, now run for real on a live Asterisk instance: asking PJSIP for its endpoints and contacts without placing a call. An endpoint contains peer settings; an address of record can hold dynamically registered or statically configured contacts. A fresh lab may have no PJSIP objects at all.

The distinction between an endpoint and a contact is worth sitting with, because it explains a confusing symptom you may eventually run into: an endpoint can show no contacts because no device is registered or because its configuration has no usable contact. Check the endpoint and address-of-record configuration before diagnosing the cause.

This build also runs chan_sip alongside PJSIP, listening on a separate port, and phone records created as protocol SIP on this build register through chan_sip rather than PJSIP. For those, `asterisk -rx 'sip show peers'` is the matching check — `pjsip show endpoints` will not show them, and that is expected rather than a fault.

asterisk -rx 'pjsip show endpoints'asterisk -rx 'pjsip show contacts'

Log in once, then change the default immediately

The Express installer's documented default Admin login is 6666 / 1234. Log in once to confirm the web interface itself works, then change it immediately — a stock credential pair published in vendor documentation is not a secret, regardless of how new or disposable the install is.

This matters even on a lab you intend to destroy in an hour. The habit of changing a default credential the moment you see it is the same habit that keeps a real deployment safe, and building it now, when the stakes are zero, costs nothing.

Notice, too, that this default is documented openly by the vendor rather than hidden — which is exactly the point. A published default credential is a known starting point for every install everywhere, not a secret specific to your build, so treating it as one after your first login is a mistake regardless of how isolated your lab appears to be.

The first-login-tour lesson elsewhere in this curriculum walks through that first login screen by screen. This lesson's job stops at the boundary: confirm the stack underneath is healthy, note the default, and change it — the tour picks up from there.

Ready for the next lesson

After verifying the stack, continue to the read-only database account lesson before running SQL queries. If Phase 2 is not installed yet, follow the detailed ViciBox 12 installation walkthrough first. Everything you verified here — Asterisk alive, the screen sessions present, PJSIP configured — is exactly what that installation walkthrough will ask you to reproduce and confirm again, in more detail.