Aperçu

Dernière mise à jour : Mar 19, 2025 |
Informations sur le prologue
La fonction d'optimisation des trunks SIP élimine le besoin d'attribuer des trunks pour la redondance. Cette fonction libère des trunks afin que les trunks disponibles puissent être utilisés par les agents SIP, les stations SIP ou les appels de trunks SIP liés au RTPC. L'illustration suivante explique le problème de la consommation de trunks en raison de la redondance.
Illustration Scénario 1 de consommation de trunks en raison de la redondance
La figure ci-dessus présente les deux scénarios suivants :
  • Premier scénario : Lorsque la connexion entre Communication Manager et Session Manager fonctionne correctement.
  • Deuxième scénario : Lorsque la connexion entre Communication Manager et Session Manager échoue.
Dans le premier scénario, si Communication Manager veut atteindre les agents rouges (piscine d'agents 1), il peut le faire en utilisant la ligne rouge entre Communication Manager et Session Manager-1. De même, si Communication Manager veut atteindre les agents bleus (piscine d'agents 2), il peut le faire en utilisant la ligne bleue entre Communication Manager et Session Manager-2.
Dans le deuxième scénario, si la connexion entre Session Manager-1 et Communication Manager est interrompue, ou si Session Manager-1 échoue, Communication Manager dispose d'un chemin alternatif pour joindre les agents rouges par Session Manager-2 en utilisant le circuit bleu. Avec 2500 membres de troncs entre Communication Manager et Session Manager-2, 5000 agents des deux pools d'agents ne peuvent pas être pris en charge. Il en est de même si les agents bleus échouent et passent à Session Manager-1.
Pour résoudre le problème dans le deuxième scénario, des trunks supplémentaires doivent être administrés entre Communication Manager et Session Manager-1 et également entre Communication Manager et Session Manager-2. Pour prendre en charge le basculement de 2 500 agents rouges vers Session Manager-2, 2 500 membres de trunks supplémentaires doivent être administrés entre Communication Manager et Session Manager-2. De même, pour prendre en charge le basculement des agents bleus vers Session Manager-1, 2 500 membres de troncs supplémentaires doivent être administrés entre Communication Manager et Session Manager-1. Pour prendre en charge le deuxième scénario, des trunks supplémentaires sont indiqués par les lignes pointillées dans la figure suivante.
Illustration Scénario 2 de la consommation de trunks en raison de la redondance
Dans le deuxième scénario, l'administration de trunks supplémentaires fournit une solution pour offrir un service aux agents rouges et bleus, mais introduit peu d'autres problèmes.
  • Les membres de troncs supplémentaires administrés pour la redondance demeurent inutilisés dans le premier scénario lorsque les liaisons d'entité à Session Manager-1 et Session Manager-2 sont en service.
    Remarque :
    Lorsque l'attribution basée sur une stratégie est activée dans System Manager, vous pouvez administrer jusqu'à quatre Session Managers pour un poste SIP.
  • Le double du nombre de trunks doit être attribué pour couvrir un deuxième scénario rare. Compte tenu du nombre limité de membres de trunk sur Communication Manager, l'utilisation de trunks pour la redondance réduit les trunks requis pour le trafic réel.
  • L'acheminement et l'administration des modèles de routage deviennent complexes.
Pour attribuer la connectivité à Session Manager-1 et Session Manager-2, Communication Manager doit créer deux groupes de signalisation :
  • Groupe de signalisation vers Session Manager-1 : Proche-extrémité comme procr et Loin-extrémité comme Session Manager-1
  • Groupe de signalisation vers Session Manager-2 : Proche extrémité comme procr et Loin extrémité comme Session Manager-2
Chaque signalisation doit avoir 5 000 trunks approvisionnés avec Session Manager-1 et 5 000 trunks à approvisionner avec Session Manager-2, comme décrit précédemment.
La fonction d'optimisation des circuits SIP permet à chaque groupe de signalisation de pointer vers plusieurs Session Manager. Dans ce cas particulier, un groupe de signalisation pointera vers Session Manager-1 et Session Manager-2. Pour ce faire, pointez le groupe de signalisation vers un groupe de Session Managers. Un cluster SM peut comporter 28 Session Manager. Dans le cas d’un cluster Session Manager, on suppose que tous les Session Manager partagent une configuration similaire et que tout Session Manager peut acheminer un appel vers la station distante ou le circuit distant.
La capacité du groupe de signalisation à pointer vers les deux Session Managers réduit de moitié les trunks à administrer sur Communication Manager tout en assurant une redondance complète. Si le lien vers Session Manager-1 échoue, le groupe de signalisation utilise le lien vers Session Manager-2 pour acheminer tout le trafic sortant. L'effet d'un groupe de signalisation pointant vers plusieurs Session Manager est le suivant :
  • Le groupe de signalisation reste en service si au moins un Session Manager administré dans le cluster est accessible.
  • Le groupe de troncs reste en service et tous les membres administrés dans le groupe de troncs peuvent fournir du trafic.
  • Par exemple, un groupe de trunks comptant 5 000 membres dans le premier scénario peut servir 2 500 agents sur Session Manager-1 et 2 500 agents sur Session Manager-2. Si la connectivité entre Communication Manager et Session Manager-1 tombe en panne, le même groupe de lignes de tronc avec 5 000 membres peut servir 2 500 agents sur Session Manager-1 et 2 500 agents sur Session Manager-1 et 2 500 agents sur Session Manager-2 par le biais de la liaison entre Communication Manager et Session Manager-2. Même si Session Manager-1 tombe en panne et que tous les agents passent à Session Manager-2, les mêmes 5 000 membres peuvent atteindre tous les 5 000 agents.
La fonction d'optimisation des circuits SIP est la suivante :
  • Le nombre de membres de troncs est de 9 999 pour les groupes de troncs SIP.
  • Le nombre d'agents SIP est de 10 000.
  • Le nombre de membres de trunks à l'échelle du système est de 30 000.
  • Les trunks mesurés sont de 30 000.
  • Les connexions TLS pour SIP sont de 56 à 32 pour prendre en charge 28 Session Manager parce que deux liens sont nécessaires pour prendre en charge chaque Session Manager.
  • Le formulaire de station SIP pointe directement vers ses Session Manager principale et secondaire pour prendre en charge 28 Session Managers, car deux liaisons sont nécessaires pour prendre en charge chaque Session Manager. Pour obtenir de plus amples renseignements sur les capacités, consultez Tableau des capacités système de Avaya Aura® Communication Manager.
    Remarque :
    Lorsque l'attribution basée sur une stratégie est activée dans System Manager, vous pouvez administrer jusqu'à quatre Session Managers pour un poste SIP.
  • La fonction d'acheminement anticipé est obsolète pour les appels de postes SIP s'ils sont acheminés sur un groupe de signalisation en cluster.
  • Le modèle de routage peut maintenant spécifier une région de réseau.