Routage alternatif pour le basculement (Failover)

Bonjour !

Dans la leçon précédente, nous avons vu comment utiliser le Destination Phone Prefix pour diriger les appels vers différentes destinations en fonction du numéro composé. Nous avons établi que l'ordre des règles est crucial : les plus spécifiques avant les plus générales.

Introduction

Aujourd'hui, nous allons répondre à une question essentielle pour la robustesse de toute solution de téléphonie : que se passe-t-il si la destination principale que nous avons choisie est indisponible ? Si un opérateur SIP tombe en panne ou si, comme dans un environnement hybride, un utilisateur n'existe pas dans le premier système interrogé (par exemple, Microsoft Teams), l'appel échoue.

L'objectif de cette leçon est de vous apprendre à implémenter une règle de routage alternative ('Alternative Routing') pour le basculement (failover). Vous apprendrez à configurer le SBC AudioCodes pour qu'il tente automatiquement une seconde destination en cas d'échec de la première, garantissant ainsi la continuité du service et évitant les appels perdus. Cette compétence est fondamentale pour construire des architectures de communication résilientes.

1. Le principe du routage alternatif

Le concept est simple : vous définissez une route principale, puis une ou plusieurs routes de secours. Le SBC tente d'abord la route principale. Si cette tentative échoue pour une raison prédéfinie, au lieu de rejeter l'appel, il le ré-achemine vers la route de secours suivante.

Qu'est-ce qui peut déclencher ce basculement ? La documentation d'AudioCodes nous l'explique.

En résumé, le basculement est initié lorsque la destination principale renvoie un code d'erreur SIP que nous avons explicitement défini comme un déclencheur, ou lorsqu'elle ne répond tout simplement pas.

2. Mise en œuvre du Failover : un scénario pratique

Pour illustrer la configuration, nous allons suivre un cas d'usage très courant que vous rencontrerez certainement : un environnement hybride avec Microsoft Teams et un PABX existant (par exemple, un Cisco CUCM).

Le problème : Un appel arrive pour une extension. Le SBC l'envoie d'abord à Teams. Si l'utilisateur n'est pas (ou pas encore) sur Teams, Teams renverra une erreur 404 Not Found. Nous ne voulons pas que l'appel soit perdu ; nous voulons que le SBC le tente alors vers le PABX.

Ce scénario est parfaitement détaillé dans le guide pratique suivant, que nous allons utiliser comme fil conducteur.

Ce guide décompose la configuration en trois étapes claires que nous allons maintenant analyser.

Étape 1 : Définir le déclencheur avec Alternative Reasons Set

D'abord, il faut dire au SBC quels codes d'erreur SIP doivent lancer le routage alternatif. On ne veut pas, par exemple, basculer sur une erreur 486 Busy Here. En revanche, 404 Not Found ou 503 Service Unavailable sont des candidats parfaits.

Comme indiqué dans l'Étape 2 du guide, la configuration se fait dans Setup > Signaling & Media > SBC > Alternative Reasons Set.

1. Vous créez un nouvel ensemble (Set).
2. Vous y ajoutez les codes de réponse qui serviront de déclencheurs. Pour notre exemple, on ajoute 404. On pourrait aussi y ajouter 503, 408, etc.

Étape 2 : Appliquer le déclencheur à l'IP Group principal

Maintenant que le "déclencheur" est défini, il faut l'associer à la destination qui est susceptible de le générer. C'est le IP Group de notre destination principale (Teams dans notre scénario).

Comme montré dans l'Étape 3 du guide :

1. Allez dans Setup > Signaling & Media > Core Entities > IP Groups.
2. Modifiez l'IP Group de la destination principale (ex: IG_Teams).
3. Dans le paramètre SBC Alternative Routing Reasons Set, sélectionnez l'ensemble que vous venez de créer.

Désormais, si un appel routé vers cet IP Group reçoit une réponse 404, le SBC saura qu'il doit chercher une route alternative.

Étape 3 : Créer la règle de routage alternative

C'est ici que la magie opère, dans la table de routage IP-to-IP. La logique repose sur deux règles placées l'une à la suite de l'autre :

• Règle N (principale) : Route l'appel vers la destination prioritaire (ex: Teams).
• Règle N+1 (alternative) : Route l'appel vers la destination de secours (ex: PABX).

La distinction se fait grâce à un paramètre crucial : Alternative Route Options.

Comme indiqué dans l'Étape 4 du guide LINK, la mise en place est la suivante :

1. Assurez-vous d'avoir votre règle principale (par exemple, Index 10: from_PBX_to_Teams). Son Alternative Route Options est à Route Row.
2. Créez une nouvelle règle juste en dessous (par exemple, à l'Index 11).
3. Configurez cette nouvelle règle pour qu'elle route vers votre destination de secours (ex: Destination IP Group: IG_CUCM).
4. Pour cette règle Index 11, réglez le paramètre Alternative Route Options sur Alternative Route Consider Inputs.

Le SBC suivra alors cette logique :

1. Tenter l'appel via la règle 10 vers Teams.
2. Si Teams renvoie une erreur 404 (parce que le SBC Alternative Routing Reasons Set est configuré sur l'IP Group de Teams)...
3. ...le SBC passera automatiquement à la règle 11 et ré-acheminera l'appel vers le CUCM.

3. Analyse du résultat dans les traces

Votre objectif étant le troubleshooting, il est vital de savoir comment ce comportement se traduit dans les traces SIP. La section Call analysis du guide LINK le décrit parfaitement : vous verriez dans un Syslog ou une capture Wireshark :

1. Un INVITE du SBC vers le proxy Teams.
2. Une réponse 404 Not Found de Teams vers le SBC.
3. Immédiatement après, un nouvel INVITE (avec le même Call-ID) du SBC vers le proxy du PABX.
4. Une réponse 200 OK du PABX, et l'appel est établi.

C'est la preuve que votre routage alternatif fonctionne comme prévu.

Conclusion

Vous venez d'ajouter une brique essentielle à vos compétences en matière de routage sur AudioCodes : la résilience. En maîtrisant le routage alternatif, vous pouvez concevoir des solutions robustes qui garantissent une disponibilité maximale du service de téléphonie.

Points Clés à Retenir

• 1. Le basculement est déclenché par des erreurs SIP : Le routage alternatif s'active en réponse à des codes d'erreur spécifiques (ex: 404, 503) ou à des timeouts (408).
• 2. La configuration se fait en trois étapes :
  • Définir les déclencheurs dans un Alternative Reasons Set.
  • Appliquer ce Set à l'IP Group de la destination principale.
  • Créer une règle alternative dans la table de routage juste en dessous de la règle principale, en utilisant l'option Alternative Route ... Inputs.
• 3. L'ordre et la proximité sont cruciaux : La règle alternative doit impérativement se trouver juste après la règle principale dans la table de routage pour que le mécanisme fonctionne.
• 4. La validation passe par l'analyse des traces : Le meilleur moyen de confirmer que le failover fonctionne est d'observer la séquence INVITE -> ERREUR -> nouvel INVITE dans les traces SIP.

Prochaine Étape

Nous avons maintenant construit une logique de routage complète et résiliente, en combinant les conditions de Match (préfixes) et le basculement. Dans la prochaine leçon, nous allons nous concentrer sur la validation pratique. Vous apprendrez à passer un appel de test et à vérifier les traces directement sur le SBC pour valider le fonctionnement d'une règle de routage, une compétence au cœur du dépannage quotidien.