Dans un projet de déploiement d’une solution Visio Conference Cisco, intégration d’un Cluster Cisco Meeting Server avec un cluster Cisco Unified CM (CUCM) via un Trunk SIP. J’ai été interrogé sur le but et le pourquoi de l’activation de l’option “Run On All Active Unified CM Nodes” dans la Route List et le Trunk SIP. A travers cette article, nous allons voir tous les scenarios possibles et nous analyserons les messages SIP INVITE à la sortie du Trunk SIP.
Mais d’abord pour comprendre cette option, vous devez comprendre d’abord que cette dernière a un effet sur les appels sortants, plus précisément lorsqu’un endpoint, par exemple HQ-Phone-1 enregistré au niveau de HQ-PUB compose le numéro d’un space, le SIP INVITE est envoyé au call control où le endpoint est enregistré et principalement l’analyse du champ de l’entête SIP INVITE « From » et la partie Host de l’URI. La question qui surgit est : une fois l’appel est reçu par le call control dans un CUCM, quel nœud ou serveur dans le cluster va-t-il initié l’appel en sortie sur le Trunk SIP vers Cisco Meeting Server ?
La réponse est : Tout dépend, ci-dessous, nous allons voir que dans certains scenarios, le calling est la Route List, Non pas le endpoint.
Essayons de décortiquer les différents scenarios.
Lorsqu’un appel sortant est initié par un endpoint et arrive au niveau du cluster CUCM, un nœud parmi les nœuds du cluster va faire l’analyse des digits et cherchent la route pattern qui routera l’appel à travers le Trunk SIP.
Il faut d’abord faire la part des choses, il y’a deux scenarios possibles pour router l’appel à travers le Trunk SIP :
1-La Route Pattern pointe directement vers le Trunk SIP. Dans ce cas le calling est le endpoint.
- Si le endpoint est enregistré dans un serveur CUCM qui est membre du Groupe CUCM assigné au Trunk SIP, alors le server où le endpoint est enregistré sera celui qui initiera l’appel sortant.
- Si le endpoint est enregistré dans un serveur CUCM et ce dernier n’est pas un membre du Group CUCM assigné au Trunk SIP, dans ce cas, les appels seront distribués aléatoirement à tous les serveurs membres du Group CUCM du SIP Trunk pour initier les appels.
2-La Route Pattern pointe vers une Route List. Dans ce cas le Calling est la Route List.
- Si la route list est enregistrée dans un serveur CUCM qui est membre du Groupe CUCM assigné au Trunk SIP, alors le server où la route list est enregistrée sera celui qui initiera l’appel sortant.
- Si la route list est enregistrée dans un serveur CUCM et cette derniere n’est pas un membre du Group CUCM assigné au Trunk SIP, dans ce cas, les appels seront distribués aléatoirement à tous les serveurs membres du Group CUCM du SIP Trunk pour initier les appels.
En fait Se référant à cette logique, nous avons deux problématiques lorsque nous avons 8 call manager ou 16 dans un mega cluster:
- La Route List est active seulement dans un seul serveur, ce qui n’est pas recommandé car tous les appels sortants seront toujours initiés par le même serveur où la Route List est enregistrée. C’est le cas lorsque ce serveur fait partie du Group CUCM assigné au Trunk SIP. Ce n’est pas recommandé d’associer la Route List et le Trunk SIP au même Groupe CUCM.
- Si Le Group CUCM assigné au Trunk SIP est utilisé, on ne peut avoir que 3 serveurs maximum pour traiter les appels sortants. C’est le cas lorsque le serveur dans lequel la Route List est enregistrée n’est pas membre du Group CUCM associé au Trunk SIP. C’est le cas lorsque le Groupe CUCM associé à la Route List n’est pas le même que celui associé au Trunk SIP. C’est plus optimal mais pas suffisant puisque on ne peut avoir que 3 serveurs maximum dans le Groupe CUCM pour traiter les appels sortants
Introduite à partir de la version 8.5, l’option “Run On All Active Unified CM Nodes” dans la Route List et le Trunk SIP, on peut aller jusqu’à 8 serveurs ou 16 dans un mega cluster comme candidats afin d’initier les appels sortants.
Pour résumer, les considerations suivantes doivent être prises en compte avant toute creation de la Route List et du Trunk SIP:
- L’option “Run On All Active Unified CM Nodes” est désactivée dans la Route List et le Trunk SIP. Le calling est la Route List.
- L’option “Run On All Active Unified CM Nodes” est activée dans la Route List et désactivée dans le Trunk SIP. Le calling est le endpoint.
- L’option “Run On All Active Unified CM Nodes” est désactivée dans la Route List et activée dans le Trunk SIP. Le calling est la Route List.
- L’option “Run On All Active Unified CM Nodes” est activée dans la Route List et le Trunk SIP. Le calling est le endpoint.
Comme vous le remarquez, la Route List est active et s’enregistre seulement dans un seul serveur CUCM. Si l’option “Run On All Active Unified CM Nodes” est désactivée dans la Route List et le Trunk SIP, tous les appels sortants peuvent être initiés par le même serveur dans lequel la Route List est enregistrée ou active (dans le cas où la Route List est active dans un serveur qui fait partie du Group CUCM assigné au Trunk SIP, comme mentioné précédemment). Ce qui n’est pas recommandé.
Solution: Activer l’option “Run On All Active Unified CM Nodes” dans la Route List et le Trunk SIP. Cette option va permettre une optimisation des appels sortants en les distribuant à tous les serveurs du cluster pour les router. En activant cette option dans la Route List et le Trunk SIP, la notion de Group CUCM dans la Route List et le Trunk SIP devient IMPERTINENTE.
Dans ce scenario, nous avons deux Group CUCM PUB et SUB qui contiennent les Call Control HQ-PUB et HQ-SUB respectivement.
Nous avons aussi deux device pool DP-PUB et DP-SUB qui contiennent les Group CUCM PUB and SUB respectivement.
Also there are two Device Pool DP-PUB and DP-SUB that contains the UCM groups PUB and SUB respectively.
L’option “Run On All Active Unified CM Nodes” est désactivée dans la Route List et le Trunk SIP.
Dans ce cas, en utilisant le concept de Route List et Route Group, le calling est la Route List. Les endpoints HQ-Phone-1 avec le DN 5001 et HQ-Phone-2 avec le DN 5002 sont enregistrés dans HQ-PUB et HQ-SUB respectivement.
Cas 1 :
- La Route List est enregistrée dans HQ-PUB 10.1.5.15.
- Le Trunk SIP est associé Group CUCM SUB qui contient le Call Control HQ-SUB 10.1.5.14.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 et contient le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.14> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 et contient le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 et contient le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Conclusion : Comme le calling la Route List est enregistrée dans HQ-PUB qui n’est pas membre du Group CUCM assigné au Trunk SIP, tous les appels sortants sont envoyés avec le champ From header: « HQ-Phone-x » <sip:500X@10.1.5.14>, the Server 10.1.5.14 du Group CUCM associé au Trunk SIP est toujours utilisé pour initier les appels sortants.
Cas 2 :
- La Route List est enregistrée dans HQ-PUB 10.1.5.15.
- Le Trunk SIP est associé Group CUCM PUB qui contient le Call Control HQ-PUB 10.1.5.15.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 et contient le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 et contient le champ From header « HQ-Phone-1 » <sip:5001@10.1.5.15> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 et contient le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 et contient le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.15> ».
Conclusion : Comme le calling est la Route List et elle est enregistrée dans HQ-PUB qui est aussi membre du Group CUCM associé au Trunk SIP. Dès lors les appels sortants sont envoyés avec le champ From header : « HQ-Phone-x » <sip:500X@10.1.5.15>, le serveur 10.1.5.15 dans lequel la Route List est enregistrée est toujours utilisé pour initier les appels sortants.
Cas 3 :
- La Route List est enregistrée dans HQ-SUB 10.1.5.14.
- Le Trunk SIP est associé Group CUCM PUB qui contient le Call Control HQ-PUB 10.1.5.15.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 et contient le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 et contient le champ From header « HQ-Phone-1 » <sip:5001@10.1.5.15> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 et contient le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 et contient le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.15> ».
Conclusion : Comme le calling est la Route List et elle est enregistrée dans HQ-SUB qui n’est pas membre du Group CUCM assigné au Trunk SIP. Les appels sortants sont envoyé avec le champ From header : « HQ-Phone-x » <sip:500X@10.1.5.15>, le serveur 10.1.5.15 membre du Group CUCM associé au Trunk SIP est toujours utilisé pour initier les appels sortants.
Cas 4 :
- La Route List est enregistrée dans HQ-SUB 10.1.5.14.
- Le Trunk SIP est associé Group CUCM SUB qui contient le Call Control HQ-SUB 10.1.5.14.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 et contient le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 et contient le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.14> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Conclusion : Comme le calling est la Route List et elle est enregistrée dans HQ-SUB qui est aussi membre du Group CUCM assigné au Trunk SIP. Les appels sortants sont envoyé avec le champ From header : « HQ-Phone-x » <sip:500X@10.1.5.14>, le serveur 10.1.5.14 dans lequel la Route List est enregistrée est toujours utilisé pour initier les appels sortants.
L’option “Run On All Active Unified CM Nodes” est activée dans la Route List et désactivée dans le Trunk SIP. Le calling est le endpoint.
Cas 1 :
- La Route List avec l’option “Run On All Active Unified CM Nodes” activée. Note : le Group CUCM associé à la Route List devient impertinent.
- Le Trunk SIP est associé Group CUCM PUB qui contient le Call Control HQ-PUB 10.1.5.15.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-1 » <sip:5001@10.1.5.15> ».
Conclusion : Le endpoint HQ-Phone-1 est enregistré dans HQ-PUB et il est aussi membre du Groupe CUCM associé au Trunk SIP. Dès lors Les appels sortants sont envoyés avec le champ From header: « HQ-Phone-1 » <sip:5001@10.1.5.15>, le serveur 10.1.5.15 dans lequel le endpoint est enregistré est toujours utilisé pour initier les appels sortants.
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.15> ».
Conclusion : Le endpoint HQ-Phone-2 est enregistré dans HQ-SUB et le serveur n’est pas membre du Groupe CUCM associé au Trunk SIP. Dès lors Les appels sortants sont envoyés avec le champ From header : « HQ-Phone-2 » <sip:5002@10.1.5.15>, le serveur 10.1.5.15 membre du Group CUCM associé au Trunk SIP est toujours utilisé pour initier les appels sortants.
Cas 2 :
- La Route List avec l’option “Run On All Active Unified CM Nodes” activée. Note : le Group CUCM associé à la Route List devient impertinent.
- Le Trunk SIP est associé Group CUCM SUB qui contient le Call Control HQ-SUB 10.1.5.14.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.14> ».
Conclusion : Le endpoint HQ-Phone-1 est enregistré dans HQ-PUB et le serveur n’est pas membre du Groupe CUCM associé au Trunk SIP. Dès lors Les appels sortants sont envoyés avec le champ From header : « HQ-Phone-1 » <sip:5001@10.1.5.14>, le serveur 10.1.5.14 membre du Groupe CUCM associé au Trunk SIP est toujours utilisé pour initier les appels sortants.
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Conclusion : Le endpoint HQ-Phone-2 est enregistré dans HQ-SUB et il est aussi membre du Groupe CUCM associé au Trunk SIP. Dès lors Les appels sortants sont envoyés avec le champ From header: « HQ-Phone-2 » <sip:5002@10.1.5.14>, le serveur 10.1.5.14 dans lequel le endpoint est enregistré est toujours utilisé pour initier les appels sortants.
L’option “Run On All Active Unified CM Nodes” est désactivée dans la Route List et activée dans le Trunk SIP. Le calling est la Route List.
Cas 1 :
- Trunk SIP avec l’option “Run On All Active Unified CM Nodes” activée. Note : le Groupe CUCM associé au Trunk SIP devient impertinent.
- La Route List est associée au Groupe CUCM PUB qui contient le serveur HQ-PUB 10.1.5.15.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-1 » <sip:5001@10.1.5.15> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.15> ».
Conclusion : Pour les deux appels initiés par les endpoints HQ-Phone-1 et HQ-Phone-2, à la sortie du Trunk SIP ils seront routé avec le champ From header: « HQ-Phone-x » <sip:500x@10.1.5.15>, le serveur 10.1.5.15 dans lequel la Route List est enregistrée sera toujours utilisé pour initier les appels sortants.
Cas 2 :
- Trunk SIP avec l’option “Run On All Active Unified CM Nodes” activée. Note : le Groupe CUCM associé au Trunk SIP devient impertinent.
- La Route List est associée au Groupe CUCM SUB qui contient le serveur HQ-SUB 10.1.5.14.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.14> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Conclusion : Pour les deux appels initiés par les endpoints HQ-Phone-1 et HQ-Phone-2, à la sortie du Trunk SIP ils seront routé avec le champ From header : « HQ-Phone-x » <sip:500x@10.1.5.14>, le serveur 10.1.5.14 dans lequel la Route List est enregistrée sera toujours utilisé pour initier les appels sortants.
Comme on le constate, la Route List est active seulement dans un seul serveur, par conséquent, tous les appels sortants sont initiés par le serveur dans lequel la Route List est enregistrée. Ce n’est pas recommandé.
L’option “Run On All Active Unified CM Nodes” est activée dans la Route List et le Trunk SIP. Le calling est le endpoint.
Un message SIP INVITE est envoyé par le HQ-Phone-1 10.1.5.102 au HQ-PUB 10.1.5.15 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un SIP INVITE sortant est envoyé par HQ-PUB 10.1.5.15 au HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-1″ <sip:5001@10.1.5.15> ».
Un message SIP INVITE est envoyé par le HQ-Phone-2 10.1.5.111 au HQ-SUB 10.1.5.14 avec le champ From header « HQ-Phone-2″ <sip:5002@10.1.5.14> ».
Un SIP INVITE sortant est envoyé par HQ-SUB 10.1.5.14 to HQ-CMS 10.1.5.42 avec le champ From header « HQ-Phone-2 » <sip:5002@10.1.5.14> ».
Dans ce cas avec l’option “Run On All Active Unified CM Nodes” activée, les groupes CUCM au niveau de la Route List et du Trunk SIP sont impertinents et le calling est toujours le endpoint, non pas la Route List.
Le processus de routage des appels sortant est le suivant :
- Si le endpoint HQ-Phone-1 est enregistré dans HQ-PUB 10.1.5.15. Les appels sortants à la sortie du Trunk SIP seront envoyés avec le champ From header: « HQ-Phone-1 » <sip:5001@10.1.5.15>, le serveur 10.1.5.15 dans lequel le endpoint est enregistré sera utilisé pour initier l’appel sortant.
- Si le endpoint HQ-Phone-2 est enregistré dans HQ-SUB 10.1.5.14. Les appels sortants à la sortie du Trunk SIP seront envoyés avec le champ From header: « HQ-Phone-2 » <sip:5002@10.1.5.14>, le serveur 10.1.5.14 dans lequel le endpoint est enregistré sera utilisé pour initier l’appel sortant.
Conclusion : En activant l’option “Run On All Active Unified CM Nodes” dans la Route List et le Trunk SIP permet de distribuer les appels sortants à la sortie du Trunk SIP vers Cisco Meeting Server, ainsi l’ensemble des call control du Cluster CUCM vont partager la charge des appels sortants tout en réduisant le traffic Intra Cluster ICCS.
Mais ce n’est pas fini, l’activation de l’option “Run On All Active Unified CM Nodes” peut provoquer l’echec des appels dans certains déploiements, alors il est recommandé de la désactiver. C’est le cas lors de l’intégration du CUBE pour le routage des appels vers un fournisseur SIP. Ce sera l’objet du prochain article.
