Installation

This page reorganizes the MiRTA PBX installation flow into an operational checklist. Use it as a starting point, then adapt paths, hostnames, IP addresses, package versions, and credentials to the server being installed.

Scope and Prerequisites

The legacy installation notes describe an automatic installer that has been proven on CentOS Stream 9 64-bit. Even with the installer, several manual configuration steps are still required after the base packages are installed.

Requirement	What to Prepare
Server access	Root shell access to a fresh server, with network access to download packages and MiRTA PBX updates.
Hostname	A meaningful hostname for the PBX node. Do not leave the system hostname set to a generic localhost value.
License details	The MiRTA PBX name and key values supplied for the installation.
Network plan	The node private IP address, public IP address when NAT is used, local network range, and any additional cluster node IP addresses.
Database plan	A local database for a single node, or a shared/replicated database design for a cluster.

Prepare the Server

1. Copy the MiRTA PBX installer script to /usr/local/src on the new server.
2. Install any missing download tools needed to retrieve packages or the installer.
3. Confirm the server hostname and change it before continuing if it is still generic.
4. Move to /usr/local/src and run the installer in kernel mode.
5. Reboot the server so the latest kernel is active.
6. Return to /usr/local/src and run the installer normally.

cd /usr/local/src
./installMirtaPBX.sh Kernel
reboot
cd /usr/local/src
./installMirtaPBX.sh

When the installer completes without blocking errors, Asterisk and VoIPmonitor should be compiled and installed. The MiRTA PBX SSH key is installed automatically during the kernel check, installation, or upgrade phase.

Configure the Application and Database

1. Open the MiRTA PBX application directory. The exact path can vary by operating system and installation layout.
2. Edit the database configuration include file and enter the supplied MiRTA PBX name and key values.
3. Run the protected application upgrade utility to download the latest MiRTA PBX version.
4. Run the database upgrade utility.
5. Convert the database content to UTF-8.
6. Convert the database tables to InnoDB.
7. Run the upgrade check utility.

cd /var/www/html/pbx
vi include/db.inc.php
cd protected
php manualUpgrade.php
cd ..
php dodbupgrade
cd protected
php convert_to_utf8.php
php convert_to_innoDB.php
cd ..
php checkupgrade.php now

 

The first database upgrade can produce warnings and notices while the schema is being aligned. Review blocking errors, but do not treat every notice as a failed installation.

If the upgrade check reports that the system timezone is not configured, set the correct date.timezone value in the PHP runtime configuration and run the check again.

Configure the Local Asterisk Node

Configure Asterisk so the PBX node can reach itself and, later, any other cluster nodes. The node peer name should match the short server name used by the operating system and by the PBX node record.

SIP Peer

Add a peer entry for the local node in the SIP configuration. Replace the peer name, secret, and host address with values for the server being installed.

[IC-PBX01]
context=fromotherpbx
type=friend
defaultuser=IC-PBX01
secret=<strong-random-secret>
host=<node-ip-address>
qualify=yes
insecure=port,invite

If the server uses a private IP address behind NAT, add the public IP address and local network range to the SIP general configuration.

externip=<public-ip-address>
localnet=<private-network>/<mask>

Reload the SIP configuration and verify that the local peer is reachable before continuing.

Manager Interface

Add the local node IP address to the Asterisk manager configuration. Use a strong manager secret, deny access by default, permit localhost and the node IP address, then reload the manager interface.

For clustered systems, repeat the same manager access pattern for each node that must communicate with the PBX services.

Device State

In the Asterisk AGI configuration area, create the device-state configuration from the sample file and list the IP addresses for every server that belongs to the cluster. A single-node installation should still list the local node IP address.

Complete the First Web Configuration

1. Log in to the MiRTA PBX web interface using the temporary administrator credentials supplied for the installation.
2. Open Admin > Settings.
3. Set the International Prefix, Trunk Prefix, License Key, VoIPmonitor retention, and Call History retention.
4. Enable the options needed for the installation, such as extension status display, administrator visibility across tenants, and at least one DID selection format.
5. Save the settings.
6. Run the web interface upgrade action.
7. Log out and log in again so database upgrade changes are applied to the session.
8. Open Admin > PBX Nodes and add the PBX node.
9. Set the node Peer Name to match the operating system node name.
10. Change the administrator password immediately.
11. Reboot the server and confirm the services return correctly.

Cluster Installations

A cluster installation follows the same base process as a single-node installation, then adds node-to-node consistency and database sharing requirements.

Area	Cluster Requirement
SIP and manager configuration	Enter the peer and manager access information for all nodes. Keep the configuration consistent on each node, except for node-specific public IP settings.
Realtime registrations	Confirm the node-specific SIP registration view created when PBX nodes are added, then enable the matching registration view for the node being configured.
Application settings	Enable SIP registration view usage in both the web application configuration and the AGI configuration area.
Device state	List every cluster node IP address in the device-state configuration.
Database	All nodes must share a common database. Multi-master replication is preferred over a single central database server.
Scheduled jobs	Daily housekeeping, cost computation, and fax mailbox checks should run only once in the cluster. Disable duplicate scheduled jobs on the other nodes.

Optional Services

Additional Daemons

A normal installation configures the device-state sender and receiver daemons for automatic startup. Additional daemons should be enabled only when the related feature is required.

WebRTC and Switchboard

To use the browser phone or Switchboard features, configure Apache for secure WebSocket traffic, enable the required WebRTC settings on the extension, and complete the related values in Admin > Settings.

The Switchboard uses extension credentials. The extension user must have permission to use the Switchboard, and the extension should be configured with Opus, encryption, and WebRTC support when using the embedded phone.

Only one SIP module can handle WebSocket connections on a single Asterisk server. If both chan_sip and PJSIP WebRTC extensions are needed, use separate nodes or a clearly defined module assignment. In a cluster, one node can serve chan_sip WebRTC extensions while another serves PJSIP WebRTC extensions.

If the server is behind NAT, configure RTP/STUN support and map the private IP address to the public IP address for ICE candidates.

Asterisk Versions and ODBC

The legacy notes describe version-specific behavior for Asterisk and ODBC libraries. When installing a non-default Asterisk version, verify the required ODBC driver version and add the required maximum connection setting to each ODBC handle.

If call history records show character encoding problems, review the MySQL ODBC driver version and use the ANSI driver required by the installation notes. Upgrade database server versions carefully and only when required.

Queue Rules

If queue rules were not enabled by the installer, activate queue-rule realtime mapping in Asterisk and reload the related realtime configuration module.

Final Checklist

• The server hostname is correct and matches the PBX node peer name.
• The MiRTA PBX name, key, and license settings are saved.
• The database has been upgraded, converted, and checked.
• The local SIP peer is reachable from Asterisk.
• The Asterisk manager interface permits the required local or cluster node addresses.
• The PBX node exists in the web interface.
• The administrator password has been changed.
• The server has been rebooted and services return cleanly.