Mécanisme de distribution d'appels CUCM dans la liaison SIP/H323

Introduction

Ce document décrit le mode de fonctionnement utilisé par Cisco Unified Communications Manager pour décider quels noeuds CUCM sont utilisés pour envoyer des appels via le protocole SIP (Session Initiation Protocol) ou les liaisons basées sur H.323.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître au préalable les sujets suivants :

• Concepts de base de Cisco Unified Communications Managers (CUCM) sur le routage des appels

Components Used

 Les informations de ce document sont basées sur Cisco Unified Communications Managers (CUCM) 8.x et versions ultérieures.

 The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les liaisons SIP et les passerelles H.323 ne s'inscrivent pas avec CUCM (contrairement aux passerelles MGCP). Au lieu de cela, le groupe CUCM associé au pool de périphériques connecté à la liaison ou à la passerelle détermine où ils seront actifs. Par exemple, s'ils sont actifs sur 2 ou 3 noeuds, quel mécanisme CUCM utilise-t-il pour décider sur quel serveur envoyer l'appel.

L'objectif de ce document est d'expliquer comment les décisions de routage d'appels sont prises et comment l'équilibrage de charge peut être réalisé pour les appels sortants via des liaisons SIP ou H.323.

Mécanisme de routage d'appel pré-CUCM 8.5 (non exécuté sur tous les noeuds Active Unified CM)

Logique générale : Pour un appel sortant, une fois que CUCM a passé par l'analyse de chiffres, il étend l'appel à RouteList ou au périphérique final.  (RouteList est enregistré sur un noeud particulier, qui dépend du groupe CUCM)

Le contrôle RouteList identifie la liste des périphériques et interroge le gestionnaire de périphériques.
Le gestionnaire de périphériques donne l'ID de processus (PID) du périphérique (exemple : (2 100 25 45), dans cet exemple, le périphérique est actif sur le noeud 2)

Le contrôle RouteList vérifie l'état du périphérique (périphérique cible actif, inactif ou occupé) et étend l'appel à la liaison ou à la passerelle.

Étant donné que les liaisons SIP / les passerelles H.323 peuvent être actives sur plusieurs noeuds, la question demande maintenant quel noeud est sélectionné comme PID actif par le gestionnaire de périphériques ?

Ces scénarios de cas d'utilisation fournissent des informations supplémentaires sur ce point :

Cas d'utilisation 1 : Téléphones IP enregistrés au noeud 1. Aucune RouteList configurée.

Dans cette ligne principale SIP, elle est active sur les noeuds 1 et 4.

• La logique générale reste la même, CUCM effectue l'analyse des chiffres sur le noeud 1 où le téléphone est enregistré. Comme aucune RouteList n'est configurée, le modèle de route est directement associé à la ligne principale SIP.
  
  
• CUCM sur le noeud 1 interroge le gestionnaire de périphériques sur le noeud 1.
  
  
• Le Gestionnaire de périphériques (DM) vérifie toujours d'abord la table locale et retourne le périphérique local s'il en existe un, afin d'éviter toute communication/trafic entre clusters inutile.

Dans ce cas, la liaison SIP est active sur le noeud 1 où le téléphone est enregistré, de sorte que CUCM prolonge l'appel à partir du noeud 1 (à chaque fois). La logique aléatoire n'est pas appliquée ici et il n'y a pas d'équilibrage de charge puisque l'appel est étendu à partir du noeud 1 dans tous les cas.

Cas d'utilisation 2 : Téléphones IP enregistrés au noeud 1. RouteList inscrit au noeud 2.

Dans cette ligne principale SIP, elle est active sur les noeuds 2 et 4.

• Après les résultats de l'analyse des chiffres (DA), le noeud CUCM 1 étend l'appel au contrôle RouteList du noeud 2.
  
  
• Le contrôle RouteList sur le noeud 2 interroge le gestionnaire de périphériques sur le noeud 2.
  
  
• DM vérifie toujours la table locale en premier et retourne un périphérique local s'il en existe un, dans ce cas la ligne principale SIP est locale au noeud 2.

Par conséquent, quel que soit l'endroit où le téléphone est enregistré, puisque la RouteList est enregistrée sur le noeud 2 et que la ligne principale Sip est active sur le même noeud, tous les appels proviennent du noeud 2. Là encore, la logique aléatoire n'est pas appliquée.

Cas d'utilisation 3 : Téléphones IP enregistrés au noeud 1. RouteList inscrit au noeud 2.

Dans cette passerelle H323 est active sur les noeuds 1 et 4.

• Après les résultats DA, CUCM sur le noeud 1 étend l'appel au contrôle RouteList sur le noeud 2.
  
  
• Le contrôle RouteList sur le noeud 2 interroge le gestionnaire de périphériques sur le noeud 2.
  
  
• Le Gestionnaire de périphériques (DM) vérifie toujours d'abord la table locale, puis renvoie la valeur local device none.
  
  
• Device Manager recherche RemoteTable et voit la passerelle H.323 active sur les noeuds 1 et 4.

Il applique la logique aléatoire et donne un PID actif de manière aléatoire au contrôle RouteList. Comme il est envoyé de manière aléatoire entre les noeuds 1 et 4, les appels sont équilibrés de charge dans CUCM.

Conclusion

CUCM vérifie si la liaison SIP/passerelle H.323 est active sur le même noeud que le périphérique appelant. Si c'est le cas, il utilise toujours le noeud local pour envoyer l'appel.
Si la liaison SIP/passerelle H.323 n'est pas active sur le même noeud que le périphérique appelant, elle provient de manière aléatoire des noeuds où la liaison/le périphérique est active.

Note: Le périphérique appelant peut être un téléphone ou une RouteList.  Si le modèle de route correspond à une RouteList, l'appelant est la RouteList. Si le modèle de route est directement associé au périphérique SIP/H.323, l'appelant est le téléphone.

Équilibrage de charge

Si l'équilibrage de charge veut être réalisé, il n'est pas conseillé de colocaliser la RouteList ou le téléphone avec les noeuds CUCM auxquels les passerelles SIP/H.323 sont associées, c'est-à-dire si elles sont toutes deux actives sur le même noeud, les appels seront envoyés à partir du noeud local (toujours).

En d'autres termes, la liaison SIP/passerelle H.323 doit être configurée de sorte qu'elle ne soit pas active sur les noeuds où RouteList ou les téléphones sont enregistrés.

À partir de CUCM version 8.6, CUCM a introduit une nouvelle fonctionnalité appelée Exécuter sur tous les noeuds Unified CM actifs pour les deux liaisons RouteList/SIP.     

Il s'agit d'une autre façon d'équilibrer efficacement la charge des appels sortants et de réduire le nombre de signaux échangés au sein du cluster.

Mécanisme de routage d'appel après CUCM 8.5 (exécution sur tous les noeuds Unified CM actifs utilisés)

Dans CUCM 8.5 et versions ultérieures, Cisco a introduit une nouvelle fonctionnalité sur les liaisons SIP et la liste de routage appelée Exécuter sur tous les noeuds Unified CM actifs. Cela a pour l'essentiel supprimé la dépendance de la ligne principale SIP et de la liste de routage sur le groupe CUCM qui leur est affecté. Cela signifie que vous pouvez avoir plus de trois serveurs CUCM qui lancent et terminent des appels depuis et vers une liaison SIP.

Trunks SIP : exécution sur tous les noeuds et la règle locale de route

Lorsque l'option Exécuter sur tous les noeuds Active Unified CM est cochée sur une ligne principale SIP, Unified CM crée une instance du démon de ligne principale SIP sur chaque abonné de traitement des appels du cluster, permettant ainsi d'effectuer ou de recevoir un appel de ligne principale SIP sur n'importe quel abonné de traitement des appels. (Avant cette fonction, jusqu'à trois noeuds pouvaient être sélectionnés par liaison à l'aide de groupes Unified CM.)

Lorsque Exécuter sur tous les noeuds Active Unified CM est activé, les appels de liaison SIP sortants proviennent du même noeud sur lequel l'appel entrant (par exemple, depuis un téléphone ou une liaison) est reçu (en fonction de la règle locale de route). La fonctionnalité Exécuter sur tous les noeuds Active Unified CM remplace la configuration du groupe Unified CM de la liaison.

Pour les liaisons SIP, voici comment fonctionne la règle locale de route :

Pour les appels de liaison SIP sortants, lorsqu'un appel d'un téléphone enregistré ou d'une liaison entrante arrive sur un noeud Unified CM, Unified CM vérifie si une instance de la liaison sortante sélectionnée existe sur le même noeud où l'appel entrant est arrivé. Si c'est le cas, Unified CM utilise ce noeud pour établir l'appel de liaison sortante.

Pour activer l'exécution sur tous les noeuds Active Unified CM sur les liaisons SIP, il est fortement recommandé car cette fonctionnalité permet aux appels sortants d'être reçus à partir de n'importe quel noeud de traitement des appels du cluster. Exécuté sur tous les noeuds Active Unified CM peut également éliminer les appels configurés entre les noeuds de traitement des appels dans le même cluster avant d'être établi sur la liaison SIP sortante.

Comme pour toutes les liaisons SIP Unified CM, les démons SIP associés à la liaison n'acceptent les appels entrants que depuis les systèmes d'extrémité dont les adresses IP sont définies dans les champs d'adresse de destination de la liaison.

Lorsque plusieurs liaisons SIP vers les mêmes destinations utilisent les mêmes noeuds de traitement des appels, un numéro de port entrant et de destination unique doit être défini par liaison pour permettre l'identification unique de chaque liaison.

Listes de routage - Exécuter sur tous les noeuds et la règle locale de routage

Bien qu'il ne s'agisse pas spécifiquement d'une fonction de liaison SIP, l'exécution de listes de routes sur tous les noeuds offre des avantages pour les liaisons dans les listes de routes et les groupes de routes. L'exécution de listes de routage sur tous les noeuds améliore la distribution des appels sortants en utilisant la règle locale de routage pour éviter le trafic inutile de configuration des appels intra-cluster.

Pour les listes de routage, voici comment la règle locale de routage fonctionne :

Pour les appels sortants qui utilisent des listes de routage (et les groupes et agrégations de routage associés), lorsqu'un appel d'un téléphone enregistré ou d'une liaison entrante arrive au noeud avec l'instance de liste de routage, Unified CM vérifie si une instance de la liaison sortante sélectionnée existe sur le même noeud que la liste de routage. Si c'est le cas, Unified CM utilise ce noeud pour établir l'appel de liaison sortante.

• Si la liste de routage et le trunk ont Exécuté sur tous les noeuds Active Unified CM activés, la distribution des appels sortants est déterminée par le noeud sur lequel l'appel entrant arrive.
  
  
• Si la liaison sortante sélectionnée utilise des groupes Unified CM au lieu de s'exécuter sur tous les noeuds, Unified CM applique la règle locale de routage si une instance de la liaison sortante sélectionnée existe sur le même noeud sur lequel l'appel entrant arrive.
  
  
• Si une instance de l'agrégation n'existe pas sur ce noeud, Unified CM transfère l'appel (au sein du cluster) vers un noeud où l'agrégation est active.
  
  
• Si la liste de routage n'est pas exécutée sur tous les noeuds Active Unified CM activés, une instance de la liste de routage est active sur un noeud du cluster (noeud principal du groupe Unified CM de la liste de routage).
  
  
• Si la liaison sortante sélectionnée est également active sur le noeud principal du groupe Unified CM de la liste de routage, la règle locale de routage est appliquée, ce qui entraîne une distribution d'appels sortants sous-optimale car tous les appels de liaison sortante proviennent de ce noeud.

Cisco recommande fortement d'activer Exécuter sur tous les noeuds Active Unified CM sur toutes les listes de routage et les liaisons SIP.