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.

The Phase 2 installer itself runs from the same first shell Phase 1 left you at; there is no second ISO to attach and no console session to abandon partway through. That continuity is part of why this stage's checklist can move directly from installation into verification without an intervening reboot-and-reconnect step.

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.

Run Phase 2 and check Asterisk's own status

Ask Asterisk for its version and its own uptime directly. Neither command changes configuration or places a call. On this build, Asterisk is not a systemd service — `systemctl is-active asterisk` reports inactive even while Asterisk runs perfectly well inside its own screen session — so systemd is never the right place to ask this question. Asterisk's own console is.

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.

screen -ls

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: confirming PJSIP has endpoints and contacts configured, without needing a carrier to prove it. An endpoint is a configured identity PJSIP knows about — an extension, a trunk definition, or a phone; a contact is a specific address that endpoint has registered from. On a fresh lab with no phones plugged in yet, expect endpoints to exist as configuration with few or no contacts registered against them.

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 be perfectly well configured and still show no contacts, simply because nothing has registered against it yet. That is a registration problem to chase on the phone or trunk side, not a reason to suspect the endpoint's own configuration is wrong.

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

Continue to the detailed ViciBox 12 installation walkthrough next — it retraces Phase 1 and Phase 2 in full step-by-step detail — and then to the read-only database account lesson before you run a single SQL query against this lab. 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.