OBELISK R82 FIX9 - ADMINISTRATION AND SPECIAL CASES

Follow INSTALL.txt for first installation. Use this reference for non-default
configuration, maintenance, backups and recovery. Read only the section needed:
1. Paths, PHP and web address
2. Remote database and privileges
3. Schedules and retention
4. Interruptions and full recovery
5. Configuration backups
6. Updates, checks and recovery-copy cleanup
7. License expiry and data access
8. Devices and call monitoring

1. PATHS, PHP AND WEB ADDRESS

For another directory directly under /var/www/html, add
--path=/var/www/html/your-site to every install.sh command. For a different PHP
CLI, also add --php=/absolute/path/php. Keep these values for --resume and
scheduling commands. Do not extract the kit inside the website.
Use an interactive SSH terminal; there is no unattended-install mode. Keep the
kit in its own directory: integrity checks also reject extra files. There is
no uninstall command; plan removal separately rather than deleting shared PBX
configuration or SQL sources.

--database=name identifies the SOURCE CDR/queue-log database; the application
database name is requested separately. Keep the source value in later runs.
--base-url=https://pbx.example.com supplies the web server without /obelisk;
http://IP:port is also accepted.
--resume reuses the saved address unless explicitly corrected as described in
section 4. --check-existing checks a server with an
existing site or Obelisk jobs; it does not update, delete or authorize replacing
that site.

CUSTOM ASTERISK FILES

Active #include, #tryinclude and #exec directives are not supported in these
three files under /etc/asterisk: queues_custom_general.conf,
extensions_custom.conf and manager_custom.conf. They stop preflight (--check
or --check-existing) and installation, including AMI existing or manual mode.
The check inspects the files before the AMI choice; that choice cannot bypass it.
Commented directives are distinct from active directives.

Keep a backup of the custom files and referenced configuration. Have the PBX
administrator review the directives, their dependencies and the affected queue,
dialplan and AMI configuration before retrying. Do not remove or comment out
directives blindly to pass the check. The installer does not follow or rewrite
their dependency tree; it preserves existing custom content when refusing it.
Any necessary PBX configuration change must be planned and validated explicitly.

Web PHP and PHP CLI may have different settings. Enable ZIP on both for updates.
Sodium and 64-bit PHP are required for 2FA and backups; backups also need zlib.
The web server must enforce the supplied .htaccess rules. Browsers need access
to www.gstatic.com for Google Charts and the configured map provider
(tile.openstreetmap.org by default).

During installation, harmless test files are briefly created in the new
directory before database objects are created. A public file must be reachable
and private paths must be protected. Unchanged test files and empty test
directories are then removed. This check remains mandatory for HTTP and HTTPS.

HTTP is allowed after a warning and operator confirmation. For HTTPS, the
certificate is verified first. If verification fails (self-signed, expired,
hostname/IP mismatch or unrecognized CA), the installer reports the reason
and asks whether to continue. Acceptance applies only to this site probe:
it does not import system CAs or change TLS for SMTP, AI or license services.
Your browser may request its own confirmation when opening the site.

Private IP addresses and internal names are supported; no public domain is
required. If a public hostname points to a NAT address the PBX cannot reach,
use an internal address that reaches the same site, or configure local DNS
or /etc/hosts. The installer does not change DNS, select a loopback address
automatically or switch HTTPS to HTTP: it uses the address you select.

Connection failures, a different site or exposed private files still stop
the check. Accepting a certificate does not bypass these errors. --check
checks prerequisites; the actual web probe runs during installation.

WEB PROBE DIAGNOSTICS

For an HTTP redirect (3xx), check the intended final address, scheme, port and
virtual host. The probe does not follow redirects. The selected address must
reach this site's files directly, including the private-path checks; a redirect
to a login page is not evidence that those files are protected.
For a server error (5xx), check the web-server configuration and error log at the
reported time. An Apache AllowOverride setting that does not permit FileInfo
can reject directives in the supplied .htaccess; it is one possible cause,
not an automatic diagnosis. Check the log before changing server settings.
An invalid or interrupted HTTP response also stops the probe. Review the server
or proxy response and logs, correct the cause and repeat the installation or
supported resume command. These errors do not certify access protection.

Cleanup removes only probe files whose contents still match and empty probe
directories. Changed or unexpected content is preserved and incomplete cleanup
stops installation. Inspect the named destination before retrying; do not delete
the directory blindly or remove customer content to force the probe to pass.
For a corrected saved address, follow the --resume rules in section 4.

2. REMOTE DATABASE AND PRIVILEGES

The remote application account must already exist and allow connections from
the PBX; its credentials are preserved. It needs SELECT on FreePBX sources,
Obelisk data access, CREATE TEMPORARY TABLES and the required routine/event
privileges. The SQL administrator provisions objects and only the declared
application table grants; the plan shows them before changes. --check does not
grant privileges. The website does not need CREATE/ALTER on application tables.

The application account also needs DROP for the explicit report reset
(truncate_cons): MySQL/MariaDB require it for TRUNCATE. Limit this privilege to
these 11 tables in the Obelisk database: out_all_n_risp, qagent, qname,
queue_answer, queue_connect, queue_enterqueue, queue_ringnoanswer, queue_stats,
queue_unanswer, storep and storep_out. Do not grant it on FreePBX sources,
on the whole database or globally (*.*).

For a new local account, the installer grants DROP on those tables. For an
existing remote account, the DBA must provide any missing DROP privileges;
automatic table-grant provisioning does not add them. This is separate from
the administrative account used for updates and recovery (section 6).

obelisk_job_health needs SELECT, INSERT and UPDATE, not DELETE or CREATE.
After creating the object, installation and updates can provision declared
grants if the SQL administrator has authority to grant them. Source access
and unrelated privileges are preserved.

On MySQL, the administrator must be able to create obelisk_routine_grants and
read routine-grant metadata. The local account receives SELECT only on the view,
not mysql.*. For remote accounts, SELECT on the Obelisk database also covers
the view; otherwise the DBA must grant SELECT on it before --resume.
MariaDB does not require this view.

Do not edit privileges during an update or recovery: SQL cannot distinguish
identical simultaneous grants. Rollback revokes only the grants added and
recorded by its own plan.

EMAIL DELIVERY AND REPORT TIME ZONE

In Administration > System and utilities, the email section includes
SMTP authentication. Keep it enabled to use a username and password.
Disable it only when the mail server authorizes this PBX to send without
credentials: saved values are retained and are not sent. Always specify a
valid sender address in this mode. SMTP encryption is configured separately.
Incomplete configuration or an invalid sender is reported in administrative
checks; correct it before sending reports or alerts.

The configured PBX report time zone also controls Today and other date
shortcuts in non-AI reports. It must match the time zone of the FreePBX data;
changing it does not convert previously imported call dates.

3. SCHEDULES AND RETENTION

A completed installation enables the Obelisk schedules and requests activation
of its database events. Check the reported status. A scheduled feature still
requires its own license, SMTP or AI settings where applicable.

Recording deletion and retention have separate administrative switches. Choose
the retention policy before enabling deletion. Enabling a schedule alone does
not enable those switches.

Recordings whose analysis was already suspended remain suspended after an
update. In Administration, open Automatic analysis status, check the reported
cause, then put the affected recording back in the queue using Return to queue.
You can also select multiple recordings as described in UPDATE MANAGEMENT.
Updating does not reset attempt counters or automatically retry suspended analyses.

Keep the original installer kit. Its schedule commands are:

  sudo bash install.sh --disable-jobs
  sudo bash install.sh --activate-jobs

Include the same --path and --php options used at installation. These commands
manage Obelisk jobs and events; they do not stop FreePBX.

4. INTERRUPTIONS AND RECOVERY

If installation stops after saving its state, correct the reported problem and
resume from the same installer kit, using the same path and PHP options:

  sudo bash install.sh --resume

If the web address was wrong and web verification has not yet succeeded, you
can correct it while resuming, for example:

  sudo bash install.sh --resume --base-url=http://192.168.1.10:8080

Use the actual address and port, without /obelisk. This correction is allowed
only before database, system or site changes begin. Other saved settings remain
unchanged; the full web check runs again and requires fresh confirmation for
HTTP or an invalid certificate. Do not delete the state to force a change after
this stage.

If you enter administrative SQL credentials different from those already saved
during this resume, the installer verifies them and asks whether to replace the
credentials in the private updater profile. Confirm only if you intend to use
the new account or password for that database. The server, port, databases and
connection type must stay the same. If you decline, the profile is preserved
and you can resume later. Unreadable or unsafe profiles and profiles for another
target are preserved and require DBA review. This confirmation concerns an
interrupted first installation; it does not change SQL accounts, grants or the
credentials used by the website's runtime account.

Do not delete installation state or replace the kit to force a retry. Retain
the diagnostic log identified by the installer. Remove credentials and personal
data before sharing any diagnostic output.

PRIVATE SQL PROFILE RECOVERY (ONLY WHEN REPORTED)

An interrupted publication may leave a temporary link to the SQL profile,
causing the protection check to reject it. Do not delete files or change
permissions manually. Stop any active installer/update processes and run this
preview from the original kit directory, using the actual application path:

  sudo python3 support/recover_sql_profile.py /var/www/html/obelisk

Only after PREVIEW OK, confirm with:

  sudo python3 support/recover_sql_profile.py /var/www/html/obelisk --apply

The checks preserve the profile contents and remove only the recognized
temporary link. No installation/update process may run during either command.
FreePBX and SQL need not be stopped. If STOP appears, preserve the files and
request assistance. After RECOVERED, resume using the original kit and options.
This is not a normal installation step.

FULL BACKUPS AND RECOVERY

Back up the complete Obelisk database, including its data, views, routines,
events, triggers and database definition with its character set and collation.
If the dump does not include
CREATE DATABASE, record that definition and recreate the destination with the
same character set and collation before restoring. Retain the SQL account and
grants separately. Also back up kernel_settings.php, the license, the configured
two-factor encryption key and the recording files you need to retain. Preserve
the private installer state directory reported at completion under
/var/lib/obelisk-installer/ and /etc/cron.d/obelisk. The original installer kit
alone does not replace that state. Keep the normal FreePBX/source backups too.

Test recovery in an isolated destination where database events and Obelisk jobs
cannot run automatically until validation is complete. A second schema on the
same active SQL server is not sufficient isolation. When restoring a dump through
the MariaDB/MySQL command-line client, preserve comments with --comments so that
routine metadata remains available. A database backup does not contain external
audio or private configuration files.

The 2FA encryption key is a file outside the SQL database. Its default path is
data/obelisk_2fa.key.php within the site; use the actual configured path if it
was changed. Losing this file prevents decryption of existing 2FA secrets.

For MySQL, preserve the definer account used by obelisk_routine_grants and its
metadata-reading privileges. A restored view remains bound to its original
schema name. For a different destination schema, the SQL administrator must
resolve the old view and explicitly reprovision the guard for that schema with:

  sudo php utility/provision_routine_guard.php --interactive

Run this from the installed site's directory using the correct PHP CLI. The
utility asks for the database, SQL administrator and existing runtime account;
the SQL administrator password is hidden and is not saved. It grants only
SELECT on the restricted view. It refuses a conflicting or old-schema view.
It does not import data, alter procedures or change database collations.

Worker monitoring requires SELECT, INSERT and UPDATE on the Obelisk database's
obelisk_job_health table. DELETE and table-creation rights are not needed.
The installer provisions these object-level rights after creating the table,
provided the SQL administrator can grant them. Updates handle the new objects
explicitly declared by their package, preserving existing rights.

5. CONFIGURATION BACKUP AND RESTORE

Open Administration > Backup and restore. Choose an archive password of at least
12 Unicode characters and at most 1,024 UTF-8 bytes. Spaces and accents remain
part of the password. Existing backups remain compatible. Confirm your administrator password and download
the backup.
The PHP web runtime needs Sodium, zlib and 64-bit integers for this feature;
Administration > Installation check reports missing dependencies.
Store the archive and its password securely and separately from this server.

The backup page displays the upload limits of the PHP runtime serving the site.
These limits can differ from PHP CLI. To support archives up to the application
limit of 16 MiB, configure web PHP with upload_max_filesize of at least 16M and
post_max_size of at least 20M, with file uploads and POST data reading enabled.
The page reserves 16 KiB of the request limit for the other form fields.
Lower limits remain usable for smaller archives, but a downloaded backup may
require increasing those limits before it can be uploaded for restoration.
The page explains rejected uploads; it does not change the server's PHP settings.
Web-server or proxy request limits can also reject a request before PHP receives
it and must be adjusted in that environment when necessary.

To restore, upload an archive produced by this feature, enter its password and
your administrator password, then review the preview. Confirm the replacement of
current users and settings. Ensure that you know the credentials and second
factor of an administrator present in the archive. Existing sessions are closed.
Enrolled authenticator applications remain valid; old recovery codes are
invalidated and should be generated again after login. A protected copy of the
current configuration is retained before replacement. To download it from the
same page, confirm your administrator password. This recovery copy uses the
same archive password entered for the restoration.
If restoration is interrupted, follow the recovery command displayed by the page;
the application remains in maintenance until recovery has completed.

The archive covers user credentials and permissions, two-factor enrollment,
preferences, operational views, saved scenarios, branding and text settings,
supported application options, agent/queue aliases, trunk selections, number
normalization and the geographical catalogue. Database and AMI connections,
filesystem paths and IP/proxy access rules of the destination are preserved.
The archive does not move the license, audio, analysis/history, CDR/queue-log
sources or custom SQL procedure/event definitions. Keep full backups as above.
If an older archive contains invalid report-recipient addresses, the preview
asks you to correct them or leave the replacement field empty. Review the
replacement before confirming restoration. This does not prevent creating a
backup of the existing configuration.
Archives from an unsupported format/version are rejected before replacement.

6. APPLICATION AND DATABASE UPDATES

Upload a compatible update ZIP in Administration > Updates, review its file and
database plan, and run the exact assisted application command shown by the page.
The package includes application files and any database steps required by
the starting release.
Do not copy PHP files or import SQL separately to bypass this process.

From R81 Fix19, Fix20, Fix21, Fix22, R82, R82 Fix1, R82 Fix2, R82 Fix3, R82 Fix4, R82 Fix5, R82 Fix6, R82 Fix7 or R82 Fix8, apply the single R82 Fix9 update ZIP. The schema remains at 4;
the procedure retains the full SQL backup and file copies. No new preparation
package is needed. Older versions must first complete their supported update
path to Fix19.

New sites use schema 4. For versions not listed, request the package and
upgrade path compatible with the installed version.

For coordinated updates, the privileged executor uses a protected SQL
administrative profile under /etc/obelisk, outside the website and readable only
by root. The installer saves its already verified administrative connection for
both local and remote databases. Local socket authentication can work without a
password; when a password is required it is kept only in this protected profile.
On an existing site without a profile, the normal update command asks for the SQL
administrator username and hidden password in an interactive SSH terminal. For
local socket authentication without a password, leave the password empty.
Connection and required privileges are checked before maintenance, including
when a profile already exists. No extra script or manual profile creation is
needed. An existing profile is not silently overwritten or given weaker file
permissions. Ordinary web requests do not receive these credentials.

Before structural changes, the updater preserves a complete Obelisk database
recovery copy together with the affected files, and pauses affected Obelisk work.
Successful completion reopens the application. If interrupted, retain the plan
and its recovery copies. Reopen that plan in Administration > Updates and use
"Show apply command" to continue, or "Show rollback command" if database restore
has already started. Follow the terminal result and the plan status. Do not
remove maintenance markers or edit progress records to force the site open.
A database-changing rollback requires explicit --restore-database approval and
returns data to the saved point: changes after that point are lost.

Plan files and file backups are stored under data/updates/ in the site. Full
database recovery copies and their private diagnostics are stored separately
under /var/lib/obelisk/schema-updates/, in directories tied to the site and plan.
These SQL copies are not downloaded by the configuration-backup page. Use the panel’s copy-deletion command for a completed plan, as described in
UPDATE MANAGEMENT. Keep copies for as long as rollback is needed. Do not
manually delete plan directories.

The update recovery copy is separate from the configuration backup in the configuration backup section.
Updates preserve kernel_settings.php and customized .htaccess
rules. Existing licenses are preserved; an active license does not need
reactivation after the update.
Files already present but absent from the new inventory are not deleted
automatically. To review and merge Obelisk's current managed web-protection
rules, run from the installed site's directory with the correct PHP CLI:

  sudo php utility/web_protection.php --dry-run
  sudo php utility/web_protection.php --apply

The first command previews the changes. The second applies only the managed
protection rules while preserving additional custom rules; it does not delete
retired application files. Run Installation check afterwards. Do not remove
files or protections indiscriminately.

UPDATE CHECKS AND CREDENTIALS

From the site directory, using the same PHP CLI executable used for updates:

  sudo php utility/update.php --status --id=PLAN_ID
  sudo php utility/schema_profile.php --check

The first command reads the selected plan's status. The second checks the
existing profile and SQL access without migrations, data copies or event
changes; it may create the private diagnostic directory. It does not create a
missing profile: use the panel's apply command for first-time setup.

A prepared plan without maintenance can be retried after fixing the reported
cause. A rolled_back or failed_rolled_back plan is closed: upload the ZIP again
and use the new plan's command. For recovery_required, keep every recovery copy
and follow the indicated resume or rollback action; do not force the site open.

TRANSFER DATA AND COLLATION DIAGNOSTICS

Before the migration to schema 4, the update check examines the missing
answered-transfer rows that the migration would add. With
update_transfer_counters_invalid, use queue_stats_id and invalid_fields in the
JSON result or referenced diagnostics to locate the rejected row.
Here info1/info2/info3 identify the canonical waiting time, talk time and
position counters, respectively. They do not necessarily refer to raw source
columns with the same names: the mapping depends on the event.
Have the PBX/SQL administrator verify the source and make any necessary
correction explicitly. Invalid counters are neither corrected automatically nor skipped.
An installation already at schema 4 does not repeat this historical backfill.
When schema 4 is checked as the existing baseline, its procedure and collation
are verified without scanning the missing transfer rows. The update check is
not a general scan or repair of all historical report rows.

For a separate historical preview, run from the installed site with the correct
PHP CLI, replacing the dates with the interval to review:

  php utility/repair_report_data.php --from YYYY-MM-DD --to YYYY-MM-DD --preview

This command only previews the selected interval. Review any reported
queue_stats_id and invalid_fields before deciding on a repair. It does not
replace source review or an update recovery action. Applying historical repairs
requires the separate --apply --maintenance-confirmed options and stopping this
installation's SQL processing events and cron jobs beforehand, as --help explains.

ORDINARY QUEUE IMPORT: ERROR 1048

A 1048 import error can indicate an invalid transfer counter, but the health
message alone does not prove that cause. If the batch was rolled back, the
source event may not yet exist in queue_stats. The DBA can inspect the transfer
candidates in the next source batch with this read-only query. Replace SOURCE_DB,
APP_DB and QUEUELOG_TABLE with the configured source database, application
database and queue-log table names:

  SELECT pending.id, pending.event, pending.data1, pending.data2,
         pending.data3, pending.data4, pending.data5
  FROM (
      SELECT q.id, q.event, q.data1, q.data2, q.data3, q.data4, q.data5
      FROM `SOURCE_DB`.`QUEUELOG_TABLE` q
      JOIN `APP_DB`.`obelisk_import_state` s ON s.job = 'queue'
      WHERE q.id > s.cursor_id AND q.id <= s.source_high
      ORDER BY q.id LIMIT 5000
  ) pending
  WHERE pending.event IN ('TRANSFER', 'BLINDTRANSFER', 'ATTENDEDTRANSFER')
  ORDER BY pending.id;

This lists candidates, including potentially valid rows; it does not identify
every listed row as faulty. Check each relevant event's format and counters
against its source before planning an explicit correction. Do not change
cursor_id, UPDATE or DELETE rows, or disable SQL strict mode to bypass the error.
Keep the import status and diagnostic details for review.

COLLATION MISMATCHES

update_database_routine_collation_mismatch means the current database default
collation differs from the creation context of the queue procedure.
update_database_event_collation_mismatch concerns an SQL event's creation
collation instead. Have the DBA compare the database default with the affected
object's SHOW CREATE metadata and review the intended configuration. Obelisk
does not automatically change collations or recreate objects to bypass either
check. Keep the object definitions, backup, update plan and diagnostic reference.

Read the plan's state first with utility/update.php --status --id=PLAN_ID, using
the status command above. When the plan offers a check, copy its exact
"Show check command" from Administration > Updates: --check needs that plan's
--id and --plan-hash and may use a staged executor with --root. Do not substitute
a command from another plan. After the DBA resolves the cause, repeat that check.
If application already failed, follow its recorded state: failed_rolled_back
requires a new plan; recovery_required requires the indicated resume or rollback
with all recovery copies preserved. Do not delete state or maintenance markers.

A new SQL recovery copy requires free local space of at least three times the
estimated Obelisk data and index size, with a 16 MiB minimum, in addition to
space for file copies. Restoring does not create a second SQL copy: only the
16 MiB check for progress files remains. These checks do not measure free space
on a remote SQL server.

For a dedicated SQL administrative account, the DBA must provide SELECT,
INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, EXECUTE, CREATE
VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT and TRIGGER on the Obelisk
schema; global PROCESS; delegation of EXECUTE and ALTER ROUTINE; account and
routine-grant metadata access; and visibility of SQL object definitions.
Additional rights for different definers, system accounts or functions with
binary logging depend on the engine and existing objects. The --check command
checks effective requirements without granting permissions. The site's runtime
account remains separate from the administrative account.

After an administrative SQL password change, have the DBA update only this
site's /etc/obelisk/schema-updater-<identifier>.json profile, identified by its
application_root value. Keep root ownership, directory mode 0700 and file mode
0600; do not copy the profile into the site or print credentials. Do not change
the host, port or database to bypass a failure. Run --check, then retry the
plan's command. Normal updates do not replace an existing profile automatically.

UPDATE MANAGEMENT

In Administration > Updates, details show the ZIP SHA-256 fingerprint and the
expected schema versions. "Show check command" prepares an SSH command for the
selected plan: it checks files, the SQL profile and requirements without applying
the update or entering maintenance. The result is dated and describes that
moment; applying the update always repeats the checks. A missing profile is
configured by the normal apply command. The separate check is available for
new plans prepared after this update. Earlier plans retain their normal apply
procedure, which includes prerequisite checks.

If apply or rollback must use the installed updater because the release name
is unsupported or the preparation lacks updater components, details explain
the reason. Compatibility checks remain mandatory. If required components are
also missing from the installed updater, these commands are unavailable: check
installation integrity. Cleanup uses the installed updater. The check uses the
updater specified by the plan's command. Always use that command:
do not replace it with one kept from a previous update.

For completed plans, "Show command to delete copies" asks for confirmation and
prepares the SSH cleanup command. It removes the ZIP, staged files and file/SQL
recovery copies. Current application data does not change. The entry remains as
"Copies deleted", and that plan can no longer be rolled back. If cleanup stops,
repeat its command. Cleanup is blocked during updates, maintenance or incomplete
recovery. Sizes are measured by the privileged command and displayed with their
measurement date; "Not measured" does not mean zero. No age-based deletion occurs.

In "Automatic analysis status", filter the suspension reason and select up to
20 recordings on the current page. Choose "Requeue selected recordings" and
confirm the displayed count. Recordings changed in the meantime or already analyzed are not restarted.
Changing the page or filter clears the selection. Results distinguish recordings
queued again from skipped items. The "Access log" also shows the reason and
archive identifier for configuration backup operations, when available.

OPTIONAL MAINTENANCE: RETIRED APPLICATION FILES

After a completed update, preview recognized retired application files:

  sudo /usr/bin/php /var/www/html/obelisk/utility/retired_files.php --dry-run

Only ImportSqlUpgrade.php, JsonConfig.php and utility/upgrade_import_sql.php
are eligible, provided they match known original versions and are absent from
the installed release inventory. Modified or still-used files are preserved;
data, settings, audio and recovery copies are excluded.
To remove eligible files, use the plan_hash returned by the preview:

  sudo /usr/bin/php /var/www/html/obelisk/utility/retired_files.php --apply --plan-hash=PREVIEW_HASH

If files change or the operation is interrupted, create a new preview.
Cleanup never starts automatically during updates or installation.
Keep original release archives to recover retired code if needed.
To synchronize managed web rules separately, run utility/web_protection.php
with --dry-run first, then --apply; custom directives are preserved.

Operational documentation: https://obsk.io/manuals/
Component licenses: assets/vendor/notices/THIRD_PARTY_NOTICES.txt in the installed Obelisk
directory (also readable from the browser at the same relative path).

UTILITY LANGUAGE
Choose the language used for instructions and human-readable results:
  sudo -u asterisk php utility/check_installation.php --lang=en
  sudo -u asterisk php utility/clean.php --dry-run --lang=en
The available values are it, en and es. Verification defaults to it when no
language is selected; cleaning defaults to the configured report language.
Diagnostic codes remain compatible. --dry-run does not delete data.
New cleaning-JSON readers use action_code, reason_code and reason_code_counts
(code_schema_version=1), with English codes. The previous action, reason and
reason_counts fields remain available for existing readers.

RECORDINGS AND EXPORTS
A download started while a call is still being recorded includes the bytes
present when the file is opened. Wait until the call ends and download it
again to obtain the complete recording.
CSV text fields are protected against formulas. Phone numbers and identifiers
may have a leading apostrophe: import them as text in your spreadsheet to
retain prefixes and leading zeros. CSV does not store cell types.

WEB RULE PREVIEW
The update plan identifies .htaccess separately as a managed block. The
check command reports whether it will be created, changed or left unchanged.
Directives outside the Obelisk block are preserved.
If the file is modified after the update, rollback stops. Keep the plan and
recovery copies: the administrator must compare the file versions and
reconcile later customizations before retrying.

7. LICENSE EXPIRY AND DATA ACCESS

An administrative warning appears during the 14 days before expiry.
After expiry, select Administrative access on the activation page and sign in
using your normal credentials and 2FA. You can renew, read audit logs, check
the installation and export configuration backups.
These archives do not contain CDR, report history or audio. Keep complete SQL
and file backups as described in this guide. Restoring configuration or
changing operational settings requires a valid license.

AI processing, the logger and periodic reports wait for renewal. Security
alerts, technical maintenance and SQL imports continue. Deletion follows
only options already enabled. Cron schedules remain and resume on renewal.
Previews do not delete data.

OTHER ENVIRONMENT VERSIONS
The installer also accepts Debian 13 and later PHP versions; verify their
compatibility with FreePBX and its modules. Minimum requirements do not
certify every combination. Reinstallation on the same server does not restart
a demo. Ask the vendor to transfer the license before changing server or directory.

8. DEVICES AND CALL MONITORING

The extension Monitor uses the identities and device associations configured
in FreePBX (AMPUSER and DEVICE). A PJSIP endpoint created outside these
associations, or a trunk with a numeric name, does not become a visible extension
merely because its identifier is a number. Both AMI directory reads must succeed;
in particular, database show DEVICE is required. If the directory is unavailable,
the Monitor cannot rebuild the extension list. Check AMI connectivity, credentials
and responses before changing any device configuration.

An extension may have several devices, including identifiers beginning with
98, 99 or other numbers. Obelisk uses the association recorded in FreePBX,
not a prefix assumption. The Dashboard selects among devices with an observed
PJSIP call, using the same status priorities as the Monitor cards. A device with
no observed call does not hide an existing call on another associated device.
There is still one button. When the call is on an alias device, the command uses
that device. This selects a device, not an individual conversation among several
calls on the same device.

Busy or DND without an observed call does not display the monitoring command.
A queue pause alone does not prevent monitoring an existing call. User permissions
still determine which commands are available. On submission, the association and
target presence are checked again: a call may have ended or its device may have
changed since the previous refresh. An accepted request confirms AMI acceptance
of the command, not an established audio connection. Audio depends on the current
call and device state; a ringing call may not yet have a conversation to hear.
If the additional reads required for monitoring fail, the Dashboard retains
available queue statistics but does not offer the monitoring command.

NAMES AND DESCRIPTIONS

Use plain text for queue and trunk names and descriptions. The editor rejects
new HTML tags. Formatting in older values is removed for display while preserving
readable text; stored data and configuration archives are not rewritten for this
change. Accents, apostrophes and plain-text symbols remain supported.
