Installing the telephony through the Manager
The whole telephony infrastructure is installed through the installation wizard of the Navin Manager (permission
services:install on the cluster); no service is installed by hand. Every service has its reference page generated
from its descriptor: Asterisk,
Kamailio,
RTPengine,
LiveKit,
LiveKit SIP,
LiveKit Egress,
LiveKit Ingress and
voice agent workers.
Supported systems
| Service | Ubuntu 24.04 | Debian 13 | RHEL |
|---|---|---|---|
asterisk | 20.6.0 (distribution package) | no: no asterisk package | no: EPEL only has Asterisk 18, out of upstream support |
kamailio | 5.7.4 | 6.0.1 | no: no maintained package in RHEL or EPEL |
rtpengine | 11.5.1.18 | 12.5.1.31 | no: no package |
livekit, livekit-sip, livekit-egress, livekit-ingress | yes | yes | yes (binary or Podman) |
livekit-agents | yes (Python 3.12, 3.11 or 3.10) | yes | yes |
The planner refuses a host whose system lacks the package (packages_unavailable): place the Asterisk nodes on
Ubuntu 24.04. The offline bundle mirrors the repositories of the build machine.
Installation order
- Existing base. PostgreSQL (optional, for a copy of the CDR and CEL through
cdr_pgsql), Redis (required by LiveKit, LiveKit SIP and Egress; highly available for the modes with several instances), SeaweedFS (for Egress and the recordings), LiteLLM (for the voice agents), Prometheus and Alloy. asterisk, modesingleorpool.livekit(already there in most installations, kept as it is), thenlivekit-sip, thenlivekit-egresswhen the calls of the AI agents must be recorded by LiveKit.rtpengine, only for difficult NAT, media anchoring required by the carrier or media interconnection.kamailio, bound toasterisk(required),livekit-sipandrtpengine(optional): the Manager writes the dispatcher list from these bindings.navin-enterprise(or its upgrade), with its telephony bindings (next section).livekit-agents, bound tolivekit,navin-enterpriseandlitellm.
The wizard shows the real order computed from the bindings before installing.
Modes
| Service | Default mode | Mode with several instances |
|---|---|---|
asterisk | single (1 node) | pool (2 nodes or more behind the dispatcher of Kamailio) |
kamailio | single | ha (2 instances or more, tables replicated through DMQ) |
rtpengine | single | redundant (2 relays or more) |
livekit | single | distributed (on Redis) |
livekit-sip | single | redundant (on highly available Redis) |
livekit-egress | single | pool |
livekit-agents | single (1 worker) | pool (2 workers or more) |
A mode with several instances is installed only when its high availability checks pass. What each mode really guarantees is described in High availability.
Ports
| Service | Port | Exposure |
|---|---|---|
| Kamailio | 5060 UDP and TCP, 5061 TLS (SIP), 7443 WSS (softphones) | public (carriers, phones, browsers) |
| Kamailio | 5071 HTTP or HTTPS (JSONRPC, /metrics) | administration network |
| Asterisk | 5070 UDP and TCP (SIP from Kamailio and LiveKit SIP only) | internal signalling network |
| Asterisk | 8088 HTTP, 8089 HTTPS (ARI, /metrics), 5038 AMI, 5039 AMI TLS | administration network |
| Asterisk | 10000 to 19999 UDP (RTP, SRTP, DTLS-SRTP) | media network |
| LiveKit SIP | 5090 UDP and TCP (SIP), 20000 to 29999 UDP (RTP) | internal and media |
| RTPengine | 2223 UDP (ng protocol), 30000 to 39999 UDP | administration and media |
| LiveKit Server | 7880 (signalling), 50000 to 50100 UDP | existing |
The planner refuses two services on the same port of a host. The Manager firewall opens AMI, ARI, JSONRPC and the
metrics only to the declared networks (admin_networks).
Bindings with Navin Enterprise
The navin-enterprise service of the catalogue receives through its bindings the addresses and secrets of the
engines: asterisk_ami, asterisk_ari, kamailio (JSONRPC), livekit and livekit_sip. The secrets stay in the
vault; the Control Plane never returns them through its API. The livekit-agents workers authenticate to the Control
Plane with an API key of a tenant with the scope telephony:voice-worker.
Once the services are installed, the platform administrator declares the PBX pool in the portal (see
Configuration in the portal); the PBX pools page of the Telephony section reads the
inventory of the Manager (GET /v1/telephony/infrastructure) to offer the installed services.
Verification
- In Services of the Manager, every service is running and its health checks are green (Asterisk:
core show uptime, modulesres_pjsip,res_ari,app_queue,cdr_managerloaded, AMI login accepted). - In the portal, Telephony then PBX pools: the preview of a publication of the pool succeeds.
- The matrix of the end to end scenarios will be in the scenario page of the telephony (
docs/en/guides/telephony/scenarios.md).