La haute disponibilité VoIP consiste à concevoir une plateforme téléphonique de sorte qu’aucune panne isolée, qu’il s’agisse d’un serveur, d’un lien réseau, d’un opérateur SIP ou d’une dépendance applicative, n’empêche vos clients de vous joindre. Pour un centre d’appels, un établissement de santé ou une ligne de paiement, une interruption se voit immédiatement. Voxivra conçoit et exploite des architectures basées sur Asterisk avec de la redondance à chaque niveau, en précisant toujours ce que chaque conception protège et ce qu’elle ne protège pas.
Partir des scénarios de panne
Avant de choisir une topologie de grappe, nous recensons ce qui peut tomber et l’impact pour l’organisation :
- Panne d’un nœud Asterisk : matériel, machine virtuelle, plantage ou déploiement défectueux.
- Dépendance applicative : service FastAGI ou ARI, base de données, API du CRM, fournisseur d’IA vocale.
- Réseau : connectivité du centre de données, pare-feu, équipement NAT, DNS.
- Opérateur SIP : panne de trunk ou problème de routage chez le fournisseur.
- Erreur humaine : une modification de configuration qui casse le dialplan sur tous les nœuds à la fois.
Chacun appelle une protection différente. Mettre Asterisk en grappe ne sert à rien face à une panne d’opérateur, et deux opérateurs ne servent à rien face à une erreur de dialplan déployée partout.
Topologie 1 : actif/passif
Deux serveurs Asterisk partagent une adresse IP virtuelle. Le nœud actif traite tous les appels ; le nœud passif reprend l’adresse si l’actif tombe. On l’implémente généralement avec keepalived (VRRP) ou Pacemaker et Corosync, avec une configuration synchronisée et une base de données partagée ou répliquée.
Atouts : simple à comprendre, peu de composants, compatible avec la plupart des dialplans existants. Limites : la moitié de la capacité reste inactive, la bascule prend quelques secondes, les appels en cours sur le nœud défaillant sont perdus, et il faut empêcher le « split-brain » par un mécanisme d’isolement (fencing) ou de quorum.
Nous recommandons l’actif/passif pour des volumes modérés, lorsqu’un seul serveur absorbe confortablement la pointe et que l’équipe veut une architecture exploitable sans compétences pointues en proxy SIP.
Topologie 2 : actif/actif derrière un proxy SIP
Un proxy SIP, généralement Kamailio ou OpenSIPS, reçoit toute la signalisation et répartit les appels entre plusieurs nœuds Asterisk. Le proxy est lui-même déployé en paire redondante.
Opérateurs / SBC
|
Kamailio (paire, IP virtuelle)
dispatcher + sondes OPTIONS
/ | \
Asterisk 1 Asterisk 2 Asterisk 3
\ | /
BD partagée / config / services ARI ou FastAGILe module dispatcher de Kamailio envoie périodiquement des requêtes SIP OPTIONS à chaque nœud. Un nœud qui ne répond plus est marqué inactif et ne reçoit plus de nouveaux appels jusqu’à son rétablissement. La répartition peut être circulaire, pondérée ou par hachage (par exemple sur le Call-ID), et un nœud peut être vidé progressivement pour maintenance.
Côté média, les nœuds Asterisk traitent souvent le RTP directement. Lorsque la traversée NAT, le masquage de topologie ou une adresse média publique unique sont nécessaires, on ajoute un relais comme RTPengine à côté de Kamailio.
Atouts : évolutivité horizontale, aucune capacité inactive, mises à jour nœud par nœud, une panne n’affecte que la part d’appels du nœud concerné. Exigences : la logique applicative ne doit pas dépendre du nœud qui traite l’appel. Cela suppose des services FastAGI ou ARI sans état, une configuration partagée (Asterisk Realtime ou gestion de configuration) et des données partagées ou répliquées (par exemple PostgreSQL ou une grappe MariaDB Galera).
Des sondes de santé au-delà de « le serveur répond »
Un nœud peut répondre aux OPTIONS alors que son application ARI est déconnectée ou sa base de données injoignable. De bonnes sondes reflètent la capacité réelle à servir des appels :
- sondes SIP depuis le proxy (OPTIONS) pour la joignabilité de base ;
- vérifications applicatives : WebSocket ARI connecté, FastAGI qui répond dans son délai, base de données accessible ;
- appels de test synthétiques réguliers sur le chemin réel, qui vérifient la diffusion des messages et la reconnaissance DTMF ;
- métriques et alertes sur les canaux actifs, les appels échoués, les codes de réponse SIP, la qualité RTP et l’état des enregistrements.
Un nœud qui échoue aux vérifications applicatives doit être retiré automatiquement du dispatcher, pas seulement signalé sur un tableau de bord.
Redondance des opérateurs et du réseau
- Au moins deux opérateurs SIP, ou deux chemins indépendants vers le même opérateur, avec un routage sortant qui bascule en cas d’erreur ou de délai dépassé.
- Redondance entrante : enregistrements DNS SRV ou plusieurs adresses de signalisation déclarées chez l’opérateur, pour que les appels entrants atteignent un site survivant.
- Redondance géographique lorsque l’enjeu le justifie : second site ou seconde région infonuagique, avec des numéros réacheminables rapidement.
- Dégradation maîtrisée : si le fournisseur du voicebot IA est en panne, les appels basculent vers un SVI simplifié ou directement vers une file d’attente plutôt que d’échouer.
Déploiements et tests
La plupart des pannes réelles viennent des changements. Nous utilisons une configuration versionnée, des déploiements progressifs (un nœud d’abord, puis les autres), des tests automatisés du dialplan et des applications, et des tests de charge avec des générateurs de trafic SIP avant la mise en service. La bascule est testée selon un calendrier, pas seulement sur papier : nous retirons un nœud, un opérateur, une dépendance, et vérifions le résultat.
Quelle architecture Voxivra recommande selon le contexte
| Situation | Recommandation type |
|---|---|
| Site unique, volume modéré, petite équipe | Paire actif/passif, deux opérateurs, supervision |
| Volume croissant, voicebots IA, mises en production fréquentes | Paire Kamailio + nœuds Asterisk actif/actif, applications sans état |
| Service critique, exigences réglementaires ou contractuelles | Actif/actif multisite, opérateurs géoredondants, exercices de bascule réguliers |
Nous ne promettons pas de taux de disponibilité précis sans connaître votre infrastructure et vos fournisseurs : la disponibilité résulte de chaque couche. Ce que nous livrons, c’est une architecture dont le comportement en cas de panne est compris, documenté et testé.
La haute disponibilité va de pair avec la sécurité VoIP, car une attaque ou une fraude est aussi une panne. Si vous quittez un serveur unique vieillissant, notre service de migration téléphonique couvre la transition sans interruption, et notre équipe support et conseil peut exploiter la plateforme avec vous. Pour un examen de votre architecture actuelle, écrivez-nous.