Single node
Start with one call-processing node and local database where the workload and availability requirements permit.
Architecture
The MiRTA PBX web layer manages provider and tenant operations. MySQL holds shared configuration and state; Asterisk nodes process calls.
Tenants have logically separate configuration, dialplans and permissions within shared application, database and call-processing layers. Manage access through user profiles and tenant assignments.
Start with one call-processing node and local database where the workload and availability requirements permit.
Pool Asterisk nodes with shared realtime configuration. Plan database replication, SIP routing and failure handling together.
High availability depends on database replication, SIP routing and tested failure handling. Active calls may end when a node fails; test call routing and database recovery in your topology.
| MiRTA PBX capability | Provider responsibility |
|---|---|
| Tenant administration and access controls | Create tenants, assign permissions and support your customers. |
| SIP routing and call flows | Supply carriers and numbers; configure and test signaling, media and interoperability. |
| Shared database and node configuration | Provide compute, storage and networking; secure, monitor, back up and recover the service. |
| Single-node and clustered deployment | Size and test physical or virtual infrastructure for concurrency, codecs, recordings, queues and integrations. |
Server capacity depends on workload and infrastructure. Software and Asterisk integration support are included; operational services are arranged separately. See inclusions and exclusions.
Bring expected concurrency, carrier layout and availability goals to review the topology and pilot tests.