14.12.2 14.12.1 14.12.0 14.11.0 14.10.0 14.9.0 14.8.0 14.7 14.6 14.5 14.4 14.3
14.12.2 14.12.1 14.12.0 14.11.0 14.10.0 14.9.0 14.8.0 14.7 14.6 14.5 14.4 14.3
Breadcrumbs

VRS Upgrade Guide from 14.12.0 to 14.12.1

Upgrade VRS from 14.12.0 to 14.12.1

Follow these steps in order.

This guide covers Cisco (docker-compose-cisco.yml / install-cisco.sh) and EFCX (docker-compose-efcx.yml / install-efcx.sh). Optional steps call out where Cisco and EFCX differ.

Before you start

  • You have SSH/login access to the VRS server

  • You know your database type: PostgreSQL 14+ or SQL Server (Cisco database vrs), or Media Server fusionpbx access (EFCX)

  • You know the database host, username, and password (ask DBA if needed)

  • You are already on 14.12.0 (or have completed the 14.11.0 → 14.12.0 upgrade)

Step 1 — Backup your settings and database

Save a copy of your current settings file so nothing is lost:

Bash
cp recording-solution/docker/config.env ~/config.env.backup

Check the backup exists:

Bash
ls -l ~/config.env.backup

Also back up the VRS metadata database before you change files or run schema scripts.

Cisco — PostgreSQL example (database vrs only — not keycloak_vrs):

Bash
pg_dump -h <db_host> -U <db_user> -d vrs -F c -f ~/vrs-14.12.0-backup.dump

Cisco — SQL Server example (adjust path/name as your DBA requires):

Bash
sqlcmd -S <db_host> -U <db_user> -P <db_password> -Q "BACKUP DATABASE [vrs] TO DISK = N'C:\\Backup\\vrs-14.12.0.bak' WITH INIT"

EFCX — PostgreSQL on the Media Server (database fusionpbx):

Bash
pg_dump -h 127.0.0.1 -U fusionpbx -d fusionpbx -F c -f ~/fusionpbx-14.12.0-backup.dump

Step 2 — Stop VRS

Cisco:

Bash
cd ~
cd recording-solution
docker compose --env-file docker/config.env -f docker/docker-compose-cisco.yml down

EFCX:

Bash
cd ~
cd recording-solution
docker compose -f docker/docker-compose-efcx.yml down

Wait until this command finishes.

Step 3 — Get the 14.12.1 files

Go to the directory that contains recording-solution (usually your home directory), keep the old folder as a backup, and clone the 14.12.1 branch:

Bash
cd ~
mv recording-solution recording-solution-14.12.0
git clone -b 14.12.1 https://gitlab.expertflow.com/voice-recording-solution/recording-solution.git

Check that you are on the 14.12.1 branch:

Bash
cd recording-solution
git branch --show-current
cd ..

It should print 14.12.1.

Put your settings back:

Bash
cp ~/config.env.backup recording-solution/docker/config.env

If you use your own SSL certificates, copy them from the old folder:

Bash
cp recording-solution-14.12.0/config/certificates/server.crt recording-solution-14.12.0/config/certificates/server.key recording-solution/config/certificates/

The shipped compose files already use these image tags — you do not need to edit tags manually:

  • front-end → 14.12.1

  • apis → 14.12.1

  • jtapi-connector (Cisco) → 14.12.1

  • archival-process (if used) → 14.12.1

  • freeswitch-mixer (mixed-session) → stays 14.12.0 — do not change it to 14.12.1

Mixer: This patch does not ship a new mixer image. Confirm the mixer line still shows freeswitch-mixer:14.12.0 after clone. Do not bump it.

Verify (Cisco example):

Bash
grep -E 'apis:|front-end:|jtapi-connector:|archival-process:|freeswitch-mixer:' recording-solution/docker/docker-compose-cisco.yml

If you changed the old compose file (for example, uncommented archival-process or consul, or changed volume paths), make the same changes in the new file:

Bash
# Cisco
diff recording-solution-14.12.0/docker/docker-compose-cisco.yml recording-solution/docker/docker-compose-cisco.yml

# EFCX
diff recording-solution-14.12.0/docker/docker-compose-efcx.yml recording-solution/docker/docker-compose-efcx.yml

Archival (if used): Matching archival-process and apis 14.12.1 builds are required for multi-leg stamped-path playback. Ensure Archive Days / retention_days is at least 2 — settings with retention_days = 1 are skipped. You do not need to re-run the EFCX fusionpbx dual-schema SQL if it was already applied in 14.12.0.

Step 4 — Database indexes (recommended for Cisco)

Cisco: Re-run the recording-solution schema script on database vrs. This is recommended for JTAPI linking and Media Recordings list grouping. The script is idempotent — it adds Mixed_Sessions / call_events lookup indexes if they are missing. There is no change to the correlation_id default.

Important: Run the script only on database vrs. Do not run it on keycloak_vrs.

Ask your DBA which option you use, then run only one option below.

Option A — PostgreSQL

Bash
cd recording-solution
psql -h <db_host> -U <db_user> -d vrs -f data/scripts/postgres.sql

Example:

Bash
psql -h 192.168.1.50 -U postgres -d vrs -f data/scripts/postgres.sql

Or in pgAdmin: open database vrs → Query Tool → open file data/scripts/postgres.sql → Run.

Option B — Microsoft SQL Server

Bash
cd recording-solution
sqlcmd -S <db_host> -U <db_user> -P <db_password> -d vrs -i data/scripts/sqlserver.sql

Or in SSMS: connect to database vrs → open data/scripts/sqlserver.sql → Execute.

If the script finishes without errors, the database part is done.

EFCX: Skip this step — these indexes are for Cisco Mixed_Sessions / call_events on database vrs, not for Media Server fusionpbx.

Step 5 — Keycloak Brute Force Detection (optional)

If you want login lockout after too many wrong passwords, enable Brute Force Detection on the realm used for VRS login and grant the confidential client service account the Admin roles described in Login account lockout (Keycloak Brute Force Detection).

Step 6 — Start VRS again

Cisco:

Bash
cd recording-solution
chmod 755 install-cisco.sh
./install-cisco.sh
docker ps

After containers are up, restart jtapi-connector once so the connector picks up the new build:

Bash
docker restart jtapi-connector

EFCX:

Bash
cd recording-solution
chmod 755 install-efcx.sh
./install-efcx.sh
docker ps

Wait until install finishes. In docker ps you should see containers such as:

  • frontend

  • backend

  • mixer (Cisco) — still on tag 14.12.0

  • keycloak (Cisco)

  • jtapi-connector (Cisco) — tag 14.12.1

  • archival-process (if enabled) — tag 14.12.1

Step 7 — Open VRS in the browser

Cisco: open https://<your-server-IP>/#/login (example: https://192.168.1.187/#/login).

EFCX: use your FQDN / port 444 URL from the Installation Guide mapping steps.

Login with your usual VRS user, then confirm:

  • Media Recordings list/search works; on EFCX, Agent Name advanced filter is a dropdown

  • On Cisco, new test calls link (JTAPI / direction present; fewer correlation_id 0 orphans)

  • If archival is used, Archive Days ≥ 2, and after the next archival run multi-leg play uses the correct archived audio per leg

  • Material Icons render without Google CDN access

  • If Keycloak BFD is configured, a locked account shows Account is locked. Try again later.

What this upgrade gives you

  • Improved Cisco call linking (JTAPI indexes, retries, recovery)

  • More reliable multi-leg archival playback (per-file stamped paths; Archive Days ≥ 2)

  • EFCX Agent Name dropdown (previously no agent-name dropdown)

  • Local Material Icons (no Google CDN dependency)

  • Clearer on-screen feedback for download and login (including lock messaging when Keycloak BFD is configured)

Rollback

If you must return to 14.12.0 after starting this upgrade:

  1. Stop VRS (docker compose ... down as in Step 2).

  2. Restore the database backup taken in Step 1 if you ran Step 4 (ask your DBA for pg_restore / SQL Server restore).

  3. Point the deployment back to the previous files: for example remove or rename the 14.12.1 recording-solution folder and restore recording-solution-14.12.0 (and ~/config.env.backup into docker/config.env if needed).

  4. Start VRS again with your 14.12.0 install script / compose flow.

Indexes added in Step 4 are additive. Rolling back images without restoring the DB backup usually still works for 14.12.0, but restoring the Step 1 backup is the safest path if anything looks wrong after the schema run.

See also: Release Notes.