High availability of the telephony
This page states what every mode really guarantees, from ADR-0173 and the descriptors of the catalogue. No capacity (concurrent calls, calls per second) is announced: it is measured on the infrastructure of the client with SIPp. A virtual IP address is not a universal solution.
Guarantees per failure
| Failure | New calls | Calls in progress |
|---|---|---|
One Kamailio instance (mode ha) | taken by the other instance, when the carriers and the phones know several addresses (DNS SRV, several addresses at the carrier, or a network load balancer) | the dialogs routed by the lost instance fail on their next request |
One Asterisk node of the pool (mode pool) | routed to the other nodes as soon as the OPTIONS probe of the dispatcher declares it down | lost: no call state is shared between Asterisk nodes |
One LiveKit SIP node (mode redundant) or LiveKit Server node (mode distributed) | routed to the other nodes | lost for the SIP participants of this node |
One AI agent worker (mode pool) | taken by another worker | the session of the agent stops; the fallback queue of the voice agent takes the call |
One RTPengine relay (mode redundant) | sent to an available relay | the media of the calls it anchored is cut |
| PostgreSQL, Redis, SeaweedFS | existing HA modes of the catalogue (Patroni, Sentinel, replication) | depends on the service |
In mode single, the loss of the instance stops the service it carries: every call and registration for Kamailio
or Asterisk, the AI calls for LiveKit SIP and the workers.
Detection by the dispatcher
Kamailio probes every destination (Asterisk and LiveKit SIP nodes) with SIP OPTIONS requests. The parameters of the
kamailio service set the pace: probe_interval_s (10 seconds by default) between two probes, probe_failures (3)
failed probes before the destination is declared down, probe_successes (2) successful probes before it is active
again, dispatcher_attempts destinations tried for one call. The failover times measured during the failure tests
are published with the end to end scenarios (docs/en/guides/telephony/scenarios.md).
Prerequisites of the modes with several instances
kamailioinha: two instances at least, hash tables replicated through DMQ (portdmq_port), several addresses published to the carriers and the phones.asteriskinpool: two nodes at least, the same configuration published to every node of the pool by Navin Enterprise.livekit,livekit-sip,livekit-egress,livekit-ingress: highly available Redis shared by the server and its services.livekit-agentsinpool: two workers at least registered under the same agent name.
The Manager installs a mode with several instances only when its HA checks pass.
Limits
- A call in progress on a lost Asterisk, LiveKit SIP or RTPengine node is lost; no call recovery is promised.
- The failover of Kamailio depends on the SIP client in front (carrier, phone, softphone): it must try another address.
- The recordings being written on a lost node are not recovered.
- Load and multi host failure tests are run on a dedicated environment, never toward a carrier without its consent.