Haute disponibilité de la téléphonie
Cette page dit ce que chaque mode garantit vraiment, d'après l'ADR-0173 et les descripteurs du catalogue. Aucune capacité (appels simultanés, appels par seconde) n'est annoncée : elle se mesure sur l'infrastructure du client avec SIPp. Une adresse IP virtuelle n'est pas une solution universelle.
Garanties par panne
| Panne | Nouveaux appels | Appels en cours |
|---|---|---|
Une instance Kamailio (mode ha) | repris par l'autre instance, si les opérateurs et les téléphones connaissent plusieurs adresses (DNS SRV, adresses multiples chez l'opérateur, ou répartiteur réseau) | les dialogues routés par l'instance perdue échouent sur leur requête suivante |
Un nœud Asterisk du pool (mode pool) | routés vers les autres nœuds dès que la sonde OPTIONS du dispatcher le déclare hors service | perdus : aucun état d'appel n'est partagé entre nœuds Asterisk |
Un nœud LiveKit SIP (mode redundant) ou LiveKit Server (mode distributed) | routés vers les autres nœuds | perdus pour les participants SIP de ce nœud |
Un worker d'agent IA (mode pool) | pris par un autre worker | la session de l'agent s'arrête ; la file de secours de l'agent vocal reprend l'appel |
Un relais RTPengine (mode redundant) | envoyés à un relais disponible | le média des appels qu'il ancrait est coupé |
| PostgreSQL, Redis, SeaweedFS | modes HA existants du catalogue (Patroni, Sentinel, réplication) | selon le service |
En mode single, la perte de l'instance arrête le service qu'elle porte : tous les appels et enregistrements pour
Kamailio ou Asterisk, les appels IA pour LiveKit SIP et les workers.
Détection par le dispatcher
Kamailio sonde chaque destination (nœuds Asterisk et LiveKit SIP) par des requêtes SIP OPTIONS. Les paramètres du
service kamailio fixent le rythme : probe_interval_s (10 secondes par défaut) entre deux sondes,
probe_failures (3) sondes en échec avant de déclarer la destination hors service, probe_successes (2) sondes
réussies avant de la rétablir, dispatcher_attempts destinations essayées pour un même appel. Les temps de bascule
mesurés lors des tests de panne sont publiés avec les scénarios de bout en bout (docs/fr/guides/telephony/scenarios.md).
Prérequis des modes à plusieurs instances
kamailioenha: deux instances au moins, tables de hachage répliquées par DMQ (portdmq_port), plusieurs adresses publiées aux opérateurs et aux téléphones.asteriskenpool: deux nœuds au moins, publication de la même configuration sur chaque nœud du pool par Navin Enterprise.livekit,livekit-sip,livekit-egress,livekit-ingress: Redis en haute disponibilité partagé par le serveur et ses services.livekit-agentsenpool: deux workers au moins inscrits sous le même nom d'agent.
Le Manager n'installe un mode à plusieurs instances que si ses contrôles HA réussissent.
Limites
- Un appel en cours sur un nœud Asterisk, LiveKit SIP ou RTPengine perdu est perdu ; aucune reprise d'appel n'est promise.
- La bascule de Kamailio dépend du client SIP en face (opérateur, téléphone, softphone) : il doit essayer une autre adresse.
- Les enregistrements en cours d'écriture sur un nœud perdu ne sont pas récupérés.
- Les tests de charge et de panne multi-hôtes se font sur un environnement dédié, jamais vers un opérateur sans son accord.