Most call accounting tools ask you to change your PBX before they will report on it — add a CDR backend, edit the dialplan, open a database port, configure AMI. Q5000 does none of that. It reads the CDR table your PBX is already writing, over SSH. This guide walks the full connection, in the order the setup wizard actually asks for it.
What you need before you start
Three things, all on the PBX side:
- SSH access to the PBX — host or IP, port (usually 22), a username and a password. Q5000 authenticates with a password, not a key, so the PBX must allow password authentication over SSH.
- An account that can read the PBX config files —
/etc/freepbx.conf,/etc/vitalpbx/database.confand friends. In practice this means root, or an account with read access to those paths. This matters only for the automatic database-user step below; you can skip it by supplying a database credential yourself. - CDR already recording. If your PBX is writing call records today, you are ready. Q5000 reads them; it does not change how they are produced.
What you don't need
- No dialplan changes, and no
cdr_custom.confor other CDR backend configuration - No AMI user or AMI configuration
- No new firewall ports — MySQL is reached through the SSH tunnel, so port
3306stays closed to the outside world - No MySQL root password, in the normal path
- Nothing installed on the PBX itself
The one thing Q5000 will optionally do to your PBX is create a single least-privilege, read-only MySQL user for itself. That step is a button you press, and it is described below.
Step 1: Choose how to connect
On first run, the setup wizard offers three routes: connect over SSH, upload a CDR CSV file, or explore Demo Mode with sample data. Demo Mode is worth five minutes if you want to see the reports before wiring anything up — it uses generated data and touches nothing.
Pick Connect via SSH for a live PBX.
Step 2: Connect over SSH
Enter the host, port, username and password, then press Test SSH Connection.
The first time Q5000 reaches a new server it shows you that server's SHA256 host-key fingerprint and asks you to confirm it. Accept it once and it is remembered; if that fingerprint ever changes, Q5000 refuses the connection rather than connecting to something that might not be your PBX.
Step 3: Give Q5000 a read-only database user
This is the step people expect to be painful. Press Create Read-Only DB User.
Q5000 reads the database credentials your PBX distribution already stores in its own config
files, uses them once to create a dedicated cdrreporter_ro account with nothing but SELECT
on your CDR database, verifies that the new account can actually read the cdr table, and
fills the credentials in for you. If verification fails, it removes the half-created user
rather than leaving a mess behind. You never type a MySQL root password.
On VitalPBX this usually cannot work, because VitalPBX runs MariaDB's root account over a
unix socket only — the create fails with ERROR 1698. Q5000 handles it: it falls back to
finding an existing working credential on the box, confirms it can read a cdr table, and
fills in the username, password and database name automatically.
If both routes fail — an unusual PBX, or an SSH account too restricted to read the config files — a field appears for you to supply a privileged MySQL credential once, purely so the read-only user can be created. That is the only situation in which you type one.
Step 4: Set your rates, then pull your history
Next the wizard asks for your call rates — landline and mobile, and any international rules you bill on. Then it downloads your call history.
Q5000 does not assume your CDR layout. It asks the database which columns your cdr table
actually has and builds its query from that, which is why the same connection works across
FreePBX, Issabel, Elastix, VitalPBX and plain Asterisk installations whose schemas differ. Only SELECT
statements are ever issued — nothing is written back to your PBX.
Step 5: Import your extensions
After the first sync, Q5000 offers to import your extension list straight off the phone system, so you get names instead of numbers.
It tries several sources in turn and stops at the first one that returns rows, rather than
guessing from your distribution: the classic users and sip tables, VitalPBX's own extension
directory, then PJSIP endpoints. One caveat worth knowing — a pure PJSIP realtime setup stores
numbers without friendly names, so you will fill those in yourself or via CSV.
You review everything in a preview dialog before it is saved, and extensions are tracked per server, so the same extension number on two different PBXs stays distinct.
Step 6: PINs, extensions, or both
After every sync Q5000 looks at the last 30 days of records and works out how your site identifies callers: account codes on every call means PIN-based, none means extension-based, a mix means mixed. It sets the reporting mode accordingly and leaves it alone if you have set the mode manually.
That detection is what makes department reports come out right on shared phones and hot-desking setups. Mapping those codes to people and departments is the next job — mapping PINs and account codes to departments picks up exactly there.
No SSH? Import a CSV instead
If SSH is off the table, export your CDR and upload the file. There is no format to choose:
Q5000 detects the delimiter, normalises the column headers and maps them onto the fields it
needs — calldate, src, dst, duration, billsec and disposition. Exports from
Asterisk and FreePBX, xDR and VoIPmonitor all map cleanly, as does most anything with
recognisable column names.
Where to go next
The architectural reasoning behind the read-only user, the SSH tunnel and the multi-distro extension chain is covered in call cost tracking on FreePBX, Issabel, Elastix and VitalPBX. There is also a full end-to-end walkthrough on the videos page — "Getting started: connect your PBX from scratch" covers this guide start to finish against a live PBX.
Frequently asked questions
Do I need to change my Asterisk dialplan to use Q5000?
No. Q5000 reads the cdr table your PBX already writes. There are no dialplan changes, no
cdr_custom.conf or CDR backend configuration, no AMI setup, and nothing to install on the PBX.
Can Q5000 connect using an SSH key instead of a password? Not currently — SSH authentication is by password. The PBX must permit password authentication over SSH. The database connection itself is tunnelled through that SSH session, so MySQL is never exposed to the network.
Do I have to give Q5000 my MySQL root password? No. Q5000 reads the database credentials your PBX distribution already stores locally and uses them once to create a dedicated read-only account for itself. A privileged credential is requested only if that automatic path and its fallback both fail.
Why did the read-only user fail to create on VitalPBX?
VitalPBX runs MariaDB's root account as unix-socket-only, so a remote CREATE USER fails with
ERROR 1698. Q5000 falls back to detecting an existing working CDR credential on the server and
fills in the username, password and database name automatically.