Integration de Cisco Meeting Server avec Unified CM pour un Load Balancing Intelligent, merci à la fonction CallBridge Group

L’intégration du Call Control Cisco Unified Communication Manager avec un cluster Cisco Meeting Server permettra le routage des appels des utilisateurs lorsqu’ils souhaitent joindre un meeting en utilisant leurs terminaux. Le design du Dial Plan recommandé pour un routage des appels optimal et évolutif est composé de 4 parties :

• Route Pattern/SIP Route Pattern
• Route List
• Route Group
• Trunk SIP

La Route Pattern correspond aux numéros que l’on veut joindre, exemple: 900X. L’utilisateur peut composer 9001, 9002….9009.

La SIP Route Pattern correspond à la partie host d’une URI, exemple: domain.com. L’utilisateur peut composer meet@domain.com.

La Route List est une liste de Route Group disponibles.

Les Route Groups sont des listes de gateway ou de trunk sip disponibles. Dans cette partie de Route Group, l’algorithme de distribution des appels recommandé vers les CallBridges est « Circular ».

Les gateways ou les trunks SIP/ICT sont les routeurs voix ou un autre cluster de CUCM/CMS, Unity Connection etc…Utilisés pour joindre la destination (le numéro ou l’URI composé par l’utilisateur).

Ce procédé permettra en effet d’apporter des modifications lorsqu’on ajoute de nouveaux sites avec un nouveau plan de numérotation sans affecter le dial plan existant. On assure ainsi l’évolutivité.

L’intégration du cluster Cisco Unified Communication Manager avec le cluster Cisco Meeting Server avec un dial plan sera basé sur ces composants ainsi il sera adapté au load balancing intelligent offert par la fonctionnalité CallBridge Group dans Cisco Meeting Server.

4 trunk sip seront créés vers les 4 CallBridges, ses trunk sip seront groupés dans une route groupe dont l’algorithme de distribution des appels est « Circular », la route groupe sera ensuite intégrée dans une route liste et enfin des routes patterns et des sip routes patterns pointeront vers la route liste.

Recommandations de l’intégration du Call Control CUCM avec Cisco Meeting Server.

Le but principal de la fonctionnalité CallBridge Group est de s’assurer que tous les participants au même meeting soient connectés au même CallBridge, éliminant ainsi un nombre excessif d’appels de distribution entre les CallBridges dont le résultat indésirable : un nombre élevé de ports consommés d’une manière non-optimale et une multitude de flux RTP. Pour illustrer ces problematiques, voyons un scenario sans CallBridge Group et un autre avec CallBridge Group.

Sans le CallBridge Group, le call flow est comme suit:

1. Un premier participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM cherche une SIP Route Pattern collab.lab.local
3. Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
4. Le Cluster CUCM vérifie la Route Group associée à la route list
5. La Route Group est configurée avec 4 Trunks SIP vers CMS-1, CMS-2, CMS-3 et CMS-4 avec l’algorithme de distribution Circular
6. Le Cluster CUCM route l’appel au CMS-1
7. La conférence nommée ccnp est active sur CMS-1

1. Un deuxième participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM cherche une SIP Route Pattern collab.lab.local
3. Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
4. Le Cluster CUCM vérifie la Route Group associée à la route list
5. La Route Group est configurée avec 4 Trunks SIP vers CMS-1, CMS-2, CMS-3 et CMS-4 avec l’algorithme de distribution Circular
6. Le Cluster CUCM route l’appel au CMS-2
7. CMS-2 distribue l’appel au CMS-1

1. Un troisième participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM cherche une SIP Route Pattern collab.lab.local
3. Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
4. Le Cluster CUCM vérifie la Route Group associée à la route list
5. La Route Group est configurée avec 4 Trunks SIP vers CMS-1, CMS-2, CMS-3 et CMS-4 avec l’algorithme de distribution Circular
6. Le Cluster CUCM route l’appel au CMS-3
7. CMS-3 distribue l’appel au CMS-1

1. Un quatrième participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM cherche une SIP Route Pattern collab.lab.local
3. Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
4. Le Cluster CUCM vérifie la Route Group associée à la route list
5. La Route Group est configurée avec 4 Trunks SIP vers CMS-1, CMS-2, CMS-3 et CMS-4 avec l’algorithme de distrbution Circular
6. Le Cluster CUCM route l’appel au CMS-4
7. CMS-4 distribue l’appel au CMS-1

Le résultat est:

• 4 ports utilisés par les participants.
• 2 ports utilisés entre CMS-1 et CMS-2.
• 2 ports utilisés entre CMS-1 et CMS-3.
• 2 ports utilisés entre CMS-1 et CMS-4.
• 2 ports utilisés entre CMS-2 et CMS-3.
• 2 ports utilisés entre CMS-2 et CMS-4.
• 2 ports utilisés entre CMS-3 et CMS-4.

Au total 16 ports utilisés pour une conférence de 4 participants.

Aussi 4 flux RTP entre les 4 utilisateurs et les 4 CMS + 3 flux RTP (CMS-2 et CMS-1, CMS-3 et CMS-1, CMS-4 et CMS-1), c’est ce qu’on appelle Distributed Calls entre CMS. Au total 8 Flux RTP.

Figure Call Flow sans le Call Bridge Group

Figure Call Flow Simplifié sans le CallBridge Group avec trois flux RTP en vert.

Avec le CallBridge Group, le call flow est comme suit:

1. Un premier participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM cherche une SIP Route Pattern collab.lab.local
3. Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
4. Le Cluster CUCM vérifie la Route Group associée à la route list
5. La Route Group est configurée avec 4 Trunks SIP vers CMS-1, CMS-2, CMS-3 et CMS-4 avec l’algorithme de distribution Circular
6. Le Cluster CUCM route l’appel au CMS-1
7. La conférence nommée ccnp est active sur CMS-1

1. Un deuxième participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM Route l’appel au CMS-2
3. CMS-1 envoie un SIP Invite avec Replace Header indiquant au CUCM de rerouter l’appel précèdent au CMS-1
4. Le Cluster CUCM route l’appel au CMS-1

1. Un troisième participant compose l’URI ccnp@collab.lab.local
   
2. Le Cluster CUCM Route l’appel au CMS-3
3. CMS-1 envoie un SIP Invite avec Replace Header indiquant au CUCM de rerouter l’appel précèdent au CMS-1
4. Le Cluster CUCM route l’appel au CMS-1

1. Un quatrième participant compose l’URI ccnp@collab.lab.local
2. Le Cluster CUCM Route l’appel au CMS-4
3. CMS-1 envoie un SIP Invite avec Replace Header indiquant au CUCM de rerouter l’appel précèdent au CMS-1
4. Le Cluster CUCM route l’appel au CMS-1

Le résultat est:

4 ports utilisés entre les participants et CMS-1.

Avec le CallBridge Group, le nombre de ports économisés est: 16-4=12.

Aussi le nombre de flux RTP sera de 4, les 4 utilisateurs établiront directement le media RTP avec le CMS-1. On élimine ainsi les Distributed Calls.

Pour implémenter le CallBridge il est recommandé:

• D’utiliser le dial plan basé sur la SIP Route Pattern, Roule Liste, Route Group et Trunk SIP.
• De sélectionner l’algorithme de distribution « Circular » dans la Route Groupe.
• De configurer l’option « Accept Replaces Header » dans le SIP Trunk Security Profile associé au Trunk SIP et de selectionner le Rerouting CSS approprié dans le Trunk SIP.

Figure Call Flow avec le Call Bridge Group

Figure Call Flow Simplifié avec le CallBridge Group avec deux flux RTP entre les deux utilisateurs et le CMS-2 en vert. Y’a plus de flux RTP entre CMS-1 et CMS-2

La fonctionnalité du CallBridge Group doit etre activé dans les CallBridges, elle consiste à grouper un Cluster de CallBridges.

Mais il est trés important de noter que cette fonctionnalité ne sera pas effective et n’marchera pas sans les deux options suivantes:

1. Accept Replaces Header dans le SIP Trunk Security Profile appliqué sur les trunks SIP vers les CallBridges.
2. Une Rerouting CSS approprié dans ces mêmes trunks SIP.

Dans la forme ces deux options paraissent simple puisqu’ils s’agit d’un clique dans l’implémentation mais dans le fond c’est tout un processus qui se met en place lors des échanges SIP entre les CallBridges et le CUCM.

De par ma petite expérience dans le domaine Visio Conférence que ce soit dans la partie training ou bien intégration, les cours officiel comme CLCNF ou bien les deployments Guides de Cisco mentionne à la volée comment les activer seulement.

Mais j’ai jugé judicieux de décortiquer ce processus en un schéma concocté grâce au logiciel Wireshark et une bonne compréhension du protocole SIP afin de savoir exactement ce que l’on implémente, car c’est le moyen le plus efficace pour un troubleshooting efficace. Ça a abouti au schéma suivant que j’décortiquerai étape par étape dans un autre article.