Intégration et configuration du routage SBC sur ARM

Bonjour !

Dans la leçon précédente, nous avons exploré l'architecture et les puissantes fonctionnalités de l'AudioCodes Routing Manager (ARM). Vous avez compris son rôle de "cerveau" central qui orchestre le routage des appels sur l'ensemble de vos SBCs.

Aujourd'hui, nous passons de la théorie à la pratique. L'objectif de cette leçon est de vous montrer, étape par étape, comment intégrer un SBC AudioCodes à l'ARM. Nous allons effectuer les configurations nécessaires sur le SBC pour qu'il établisse la communication avec le serveur ARM et lui délègue les décisions de routage. Cette leçon est le pont indispensable entre la configuration locale du SBC que vous connaissez et la gestion centralisée offerte par l'ARM.

Le Plan d'Action : Les 3 Piliers de l'Intégration

Pour qu'un SBC puisse recevoir sa configuration de routage de l'ARM, trois grandes étapes de configuration sont nécessaires sur le SBC lui-même :

1. Établir la Connexion : Le SBC doit savoir où se trouve le serveur ARM sur le réseau et comment communiquer avec lui. C'est le lien de communication fondamental.
2. Déclarer les Ressources : Le SBC doit explicitement indiquer à l'ARM quels "morceaux" de sa configuration (comme les trunks opérateurs ou les liens vers Teams) sont disponibles pour être gérés de manière centralisée. C'est un mécanisme d' "opt-in".
3. Déléguer la Décision de Routage : Enfin, nous devons créer une règle de routage spécifique dans le SBC qui lui ordonne, pour certains appels, de ne plus utiliser sa logique locale mais de demander son chemin à l'ARM.

Nous allons parcourir chacune de ces étapes en nous appuyant sur la documentation technique.

Étape 1 : Connecter le SBC au Serveur ARM

La toute première chose à faire est d'établir la connexion entre le SBC et le "Configurator" de l'ARM, qui, comme nous l'avons vu, est le composant central de gestion. Cette connexion se fait via le protocole HTTP/HTTPS et se configure dans le menu Remote Web Services du SBC.

Pour résumer le processus que vous venez de lire :

1. On se rend dans IP Network > Web Services > Remote Web Services.
2. On crée un nouveau service de type Routing.
3. On définit ensuite un "Host" pour ce service, qui n'est autre que l'adresse IP du serveur ARM Configurator.
4. Le SBC tente alors d'établir une connexion. Le statut passe à Connected si la communication est réussie.

À ce stade, le SBC sait "parler" à l'ARM, mais il ne sait pas encore "quoi lui dire" ni quand le faire.

Étape 2 : Exposer les Ressources du SBC à l'ARM

Maintenant que la connexion est établie, le SBC va automatiquement commencer à synchroniser sa topologie avec l'ARM. Cependant, par défaut, la plupart des éléments de configuration ne sont pas partagés. Vous devez explicitement autoriser l'ARM à "voir" et à contrôler les entités de routage pertinentes. Cela se fait via un simple paramètre : Used by Routing Server.

Cette étape est cruciale car elle permet de faire le lien entre les concepts du SBC (IP Group, SIP Interface) et ceux de l'ARM (Peer Connection, Routing Interface) vus dans la leçon précédente.

Ce que vous devez retenir :

• SIP Interfaces : En passant le paramètre Used by Routing Server à Used sur une interface SIP, vous autorisez l'ARM à l'utiliser comme une Routing Interface pour construire des liens (Connections) entre vos SBCs (Nodes).
• IP Groups : C'est le point le plus important. En activant ce paramètre sur un IP Group (par exemple, celui de votre opérateur ITSP ou de votre trunk Teams), vous le faites apparaître dans l'interface de l'ARM en tant que Peer Connection. L'ARM peut alors l'utiliser comme source ou destination dans ses règles de routage.

Une fois ces étapes réalisées, si vous vous connectez à l'interface de l'ARM, vous verrez votre SBC apparaître en tant que Node, et vos IP Groups sélectionnés en tant que Peer Connections. La topologie est maintenant visible par le serveur central.

Étape 3 : Déléguer la Décision de Routage

Le SBC et l'ARM communiquent, la topologie est synchronisée... mais le SBC continue de router les appels en utilisant sa propre table de routage locale ! La dernière étape consiste à créer la règle qui va tout changer. Nous allons ajouter une règle dans la table IP-to-IP Routing qui, au lieu de pointer vers une destination SIP, pointera vers une destination spéciale : le Routing Server.

Le mécanisme est le suivant :

1. Un appel (SIP INVITE) arrive sur le SBC.
2. Le SBC analyse sa table IP-to-IP Routing.
3. Il trouve une correspondance avec notre nouvelle règle (qui peut être très large, par exemple, pour tous les INVITE).
4. La destination étant Routing Server, le SBC cesse le traitement local. Il envoie une requête HTTP Get Route à l'ARM en lui fournissant les détails de l'appel.
5. Il attend la réponse de l'ARM pour savoir où acheminer l'appel.

La documentation décrit une stratégie de migration en douceur :

1. Gardez vos règles de routage locales actives sur le SBC.
2. Configurez la règle équivalente dans l'interface de l'ARM.
3. Activez la règle de délégation Routing Server sur le SBC.
4. Testez que les appels sont bien routés par l'ARM.
5. Une fois validé, vous pouvez supprimer l'ancienne règle locale du SBC.

Mémo Pratique : Les Étapes Clés de l'Intégration ARM

Conformément à votre demande, voici un résumé des étapes clés à mémoriser pour intégrer un SBC à l'ARM. C'est votre checklist pratique.

1. Connexion au Serveur ARM

   • Naviguer vers Setup > IP Network > Web Services > Remote Web Services.
   • Créer un service de type Routing.
   • Dans HTTP Remote Hosts, ajouter l'adresse IP et les identifiants du serveur ARM Configurator.
   • Validation : Vérifier que le statut du Host est Connected.

2. Déclaration des Ressources SIP

   • Naviguer vers Setup > Signaling & Media > Core Entities > SIP Interfaces.
   • Pour chaque interface réseau que l'ARM doit pouvoir utiliser, régler Used By Routing Server sur Used.
   • Naviguer vers Setup > Signaling & Media > Core Entities > IP Groups.
   • Pour chaque IP Group (trunk) que l'ARM doit gérer, régler Used By Routing Server sur Used et s'assurer qu'il a un nom unique.
   • Validation : Dans l'interface ARM, vérifier que le SBC apparaît comme un Node et que les IP Groups apparaissent comme des Peer Connections.

3. Délégation du Routage

   • Naviguer vers Setup > Signaling & Media > SBC > IP-to-IP Routing.
   • Créer une nouvelle règle de routage. Il est courant d'en créer une qui s'applique à tous les appels entrants (Source IP Group = Any).
   • Régler le Destination Type sur Routing Server.
   • Validation : Passer un appel de test et vérifier dans les traces du SBC (et de l'ARM) que la requête de routage est bien envoyée à l'ARM et que la réponse est correctement traitée.

Conclusion

Félicitations ! Vous avez franchi une étape majeure. Vous savez maintenant configurer un SBC pour qu'il soit entièrement géré par l'ARM. Le lien est créé, les ressources sont visibles, et le mécanisme de délégation est en place. Le SBC n'est plus une île isolée mais un membre à part entière d'un réseau de routage intelligent et centralisé.

Points Clés à Retenir :

• L'intégration repose sur 3 actions sur le SBC : Connecter (Remote Web Services), Déclarer (Used by Routing Server), et Déléguer (règle de routage vers 'Routing Server').
• Le paramètre Used by Routing Server est la clé qui rend les entités du SBC visibles et contrôlables par l'ARM.
• La règle IP-to-IP Routing avec la destination Routing Server est le déclencheur qui active la consultation de l'ARM pour un appel donné.

Aperçu de la prochaine leçon :

Maintenant que notre SBC est prêt à écouter les ordres de l'ARM, il est temps de passer de l'autre côté du miroir. Dans la prochaine leçon, nous nous connecterons à l'interface de l'ARM et nous configurerons notre première politique de routage centralisée, par exemple, une règle de routage au moindre coût (Least Cost Routing). Vous verrez comment l'ARM utilise la topologie que nous venons de lui fournir pour prendre des décisions intelligentes.