Nous avons abordé la notion Call Bridge Group dans le dernier article sur Cisco Meeting Server intitulé « Intégration de Cisco Meeting Server avec Unified CM pour un Load Balancing Intelligent, merci à la fonction CallBridge Group » dont l’objectif utlime 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 ce résultat indésirable : un nombre élevé de ports consommés d’une manière non-optimale et une multitude de flux RTP.
Pour rappel. 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.
La fonctionnalité du CallBridge Group doit etre activée 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:
- Accept Replaces Header dans le SIP Trunk Security Profile appliqué sur les trunks SIP vers les CallBridges.
- 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. Comme promis dans le précèdent article voici l’explication et le secret de ses deux options. Après tout « la meilleure façon de tenir une promesse c’est de ne jamais la donner » dixit Napoleon Bonaparte.
La question qui m’a taraudé longtemps et dont j’n’ai pas trouvé de réponse est : si on n’active pas l’option Accept Replaces Header et si on n’associe pas la bonne Rerouting CSS. Quelles sont les types de messages SIP bloqués par le CUCM ? Comment les informations SDP (adresse IP et numéro de ports RTP) sont modifiées à la volée afin de fournir cet équilibrage de charge intelligent ? car l’idée est la. Y’a quelque chose qui se passe dans la payload SDP.
La topologie dont je me suis basée est la suivante :
Faisons une analyse approfondie et voyons avec le logiciel wireshark et les traces SIP de Cisco Meeting Server, ce qui va se passer sans ces deux fameuses options.
Le client Jabber pperez@lab.local compose l’URI ccnp@collab.lab.local pour joindre la conférence. L’utilisateur pperez est connecté avec succès à l’espace appelé Demystify From Scratch Meeting hébergé au niveau du call bridge CMS-A 10.1.5.50 selon la décision de l’algorithme circulaire (round robin) définie dans la route groupe du Call Manager BR-CUCM.
Le flux RTP est établi entre le call bridge CMS-A 10.1.5.50 et l’utilisateur pperez 10.1.5.100. La conférence Demystify From Scratch Meeting est actuellement active au niveau du CMS-A.
Un second client jabber jsmith@lab.local compose ccnp@collab.lab.local dans le but de joindre la conférence et l’utilisateur pperez pour parler de l’actualité du foot !!
En utilisant l’algorithme round robin. Le Call Manager BR-CUCM route l’appel et plus exactement le message SIP INVITE au deuxième call bridge CMS-B 10.1.5.51.
Le CMS-B en cluster avec le CMS-A, sait déjà que la conférence est déjà active dans le CMS-A. Il l’informe qu’un utilisateur veut joindre cet espace.
Dans les logs SIP Trace de Cisco Meeting Server CMS-B, on voit ce dernier sollicitant le CMS-A pour remplacer et prendre en charge l’appel émanant du call manager 10.1.5.16 BR-CUCM avec le Call ID 65c73500-10001-3a2-93f492a@10.1.5.16.
Le CMS-A envoie à son tour un message SIP INVITE au Call Manager BR-CUCM avec l’option Replaces Header dans l’entête SIP. Il lui indique que le message SIP provient de (From) ccnp@collab.lab.local qui est l’adresse URI de la conférence et destiné à (TO) jsmith@lab.local.
Qu’y a-t-il dans ce fameux Replace Header ?
Naturellement quelque chose qui identifie d’une manière unique l’appel reçu par le CMS-B.
Cette identification est basée sur le Call-ID (qui est unique dans chaque conversation SIP) du dialogue SIP précèdent entre le CMS-B et BR-CUCM et qui contient les champ “To Tag” et “From Tag”.
Le champ To TAG identifie l’utilisateur jsmith@lab.local l’initiateur de l’appel, tant dis que le champ From TAG identifie la conférence avec son URI ccnp@collab.lab.local.
Les champs “Call ID”, “To Tag” et “From Tag” du dialogue SIP entre le CMS-B et BR-CUCM, et les champs “Call ID”, “To Tag” et “From Tag” dans le SIP INVITE envoyé par le CMS-A au BR-CUCM sont identiques.
La section Replaces Header dans le SIP INVITE envoyé par le CMS-A contient les « Call ID », « To Tag » et « From Tag » suivants :
- Call ID= 65c73500-10001-3a2-93f492a@10.1.5.16.
- SIP to tag: 529a83981e4deb40.
- SIP from tag: 1298~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851046
Le dialogue SIP entre le CMS-B et BR-CUCM possède des informations identiques du
« Call ID », « To Tag » et « From Tag ».
- Call ID= 65c73500-10001-3a2-93f492a@10.1.5.16.
- SIP to tag: 529a83981e4deb40.
- SIP from tag: 1298~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851046
C’est comme si le CMS-A est en train d’usurper la conversation SIP entre le CMS-B et BR-CUCM, dont l’objectif ultime est d’établir le flux RTP entre le CMS-A et le client jabber.
L’option Replaces Header va instruire le Call Manager de rerouter l’appel précèdent de jsmith au CMS-A où la conférence est déjà active.
Si on regarde encore dans la payload, à l’intérieur du champ SDP du SIP INVITE envoyé par le CMS-A au BR-CUCM, on constate que le SDP véhicule l’adresse IP 10.1.5.50 du CMS-A et le port RTP 37608 pour l’audio que le CMS-A offre et propose à jsmith@lab.local pour l’établissement du flux RTP.
Le BR-CUCM reçoit un SIP INVITE avec Replaces Header,
La capture montre intuitivement que le BR-CUCM renvoie un message SIP 404 Not Found.
La capture wireshark confirme clairement le problème.
La cause de cette erreur 404 Not Found est l’absence d’une rerouting CSS appropriée afin d’informer le client jabber de jsmith qu’un changement est opéré dans le dialogue SIP qu’il a initié au départ, ce changement est véhiculé par le message SIP Update.
Ce message SIP Update doit etre rerouté et non routé, la différence est de mise dans le monde du call routing, par conséquent lorsque le call manager BR-CUCM reroute le SIP Update à jsmith, il faut une rerouting CSS qui inclue la partition Directory URI du client jabber jsmith. Faut noter que par défaut, lorsqu’on associé une URI à un Endpoint à partir de la page de configuration end user dans le Call Manager, l’URI de l’utilisateur sera associé au endpoint et mis dans la partition par défaut appelée Directory URI. Cette rerouting CSS qui inclut cette partition doit être définie dans le Trunk SIP où le call manager BR-CUCM a reçu le SIP INVITE du CMS-A.
Du moment il n’y’a aucune Rerouting CSS définie dans le Trunk SIP et en même temps l’URI jsmith@lab.local est dans la partition Directory URI. Le BR-CUM va agir en refusant d’envoyer le SIP Update à jsmith, il informe le CMS-A en lui envoyant un message SIP avec le code d’erreur 404 Not Found.
Je vais créer la CSS Calling Search Space et j’la nomme br-css, dans la CSS, j’ajoute la partition Directory URI. Enfin j’associe la CSS br-css dans le champ Rerouting Calling Search Space du Trunk SIP qui pointe vers le CMS-A et le CMS-B.
On fait une deuxième tentative à partir du client jabber jsmith pour rejoinder le space Demystify From Scratch Meeting en composant l’ URI ccnp@collab.lab.local.
Dans les logs SIP Trace de Cisco Meeting Server CMS-B, on voit ce dernier sollicitant le CMS-A pour remplacer et prendre en charge l’appel émanant du call manager 10.1.5.16 BR-CUCM.
Le call manager BR-CUCM envoie un message SIP avec le code d’erreur 403 Forbiden au CMS-A comme le montre la capture wireshark ci-dessous.
Le SIP Trace dans le CMS-A montre et confirme qu’il a bel et bien reçu le message SIP avec le code d’erreur 403 Forbiden du BR-CUCM 10.1.5.16.
La raison pour laquelle le BR-CUCM a envoyé ce code d’erreur est : sans cette option (Accept Replaces Header) dans SIP Trunk Security Profile qu’on a appliqué dans le Trunk SIP vers le CMS-A, le BR-CUCM va rejeter le SIP INVITE avec le champ Replaces Header.
Cette option va instruire le call manager d’accepter tout message SIP INVITE avec le champ Replaces Header.
En d’autres termes, cette option autorisera le BR-CUCM de transférer l’appel initié précédemment par jsmith@lab.local vers le CMS-B et usurpé par le CMS-A.
Editer le SIP Trunk Security Profile déja appliqué lors de la creation du Trunk SIP vers CMS-A and CMS-B, et on active l’option Accept Replaces Header. N’oubliez pas de réinitialiser le trunk sip avec le bouton Reset.
Une autre tentative de rejoindre le meeting en composant l’URI ccnp@collab.lab.local.
Maintenant le client jabber jsmith est connecté au space “Demystify From Scratch Meeting”.
Essayons de construire le call flow après avoir mis la bonne Rerouting CSS et activé l’option Accept Replaces Header.
Step 1:
Le jabber client jsmith@lab.local envoie un SIP INVITE avec le SDP inclus au call manager BR-CUCM, le Call ID est 000c2972-b1cc00ae-00006003-000060e0@10.1.5.114.
A l’intérieur du SDP, jsmith inclue son adresse IP 10.1.5.114 et le port Audio RTP par exemple 23086 / le port Vidéo RTP 29970 qui seront utilisés plus tard pour le media audio et vidéo respectivement.
Step 2:
BR-CUCM répond avec un message SIP 100 Trying.
Step 3:
En se basant sur l’algorithme circular défini dans la Route Group, le BR-CUCM envoie un SIP INVITE sans SDP au CMS-B.
Step 4:
CMS-B répond avec un message SIP 100 Trying, cet appel est identifié avec les informations Call ID, To TAG et From TAG suivantes :
Call ID 8b097280-10001-44d-93f492a@10.1.5.16, From TAG = 1623~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851074 and To TAG = 0bb81861725b6a46.
Step 5:
CMS-B envoie un message SIP 180 Ringing au call manager BR-CUCM.
Step 6:
BR-CUCM envoie un messge SIP 180 Ringing à jsmith@lab.local.
Step 7:
Comme le space est actif dans le call bridge CMS-A, l’appel sera remplacé. Le CMS-B va solliciter le call bridge CMS-A et lui demande tout bêtement de remplacer et de prendre en charge l’appel provenant du call manager BR-CUCM 10.1.5.16 dont le Call ID est 8b097280-10001-44d-93f492a@10.1.5.16. Comme le montre le SIP Trace du CMS-A.
Le CMS-A envoie a SIP INVITE avec le champ Replaces Header dans l’entête du message SIP (Message Header), ce SIP INVITE provient de la conférence (From « Demystify From Scratch Meeting » ccnp@collab.lab.local), à (TO jsmith@lab.local).
A l’interieur de l’entête du message (Message Header), le champ Replaces Header contient les informations suivantes : Call ID = 8b097280-10001-44d-93f492a@10.1.5.16;to-tag=1623~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851074;from-tag=0bb81861725b6a46.
Les mêmes valeurs que le Call ID, To Tag et From Tag de l’étape 4.
Ce SIP INVITE provient de la conférence (From « Demystify From Scratch Meeting » ccnp@collab.lab.local), destiné à jsmith (TO jsmith@lab.local).
Le CMS-A est en train d’usurper le dialogue ou la conversation SIP entre le BR-CUCM et CMS-B, il demande au call manager qu’il prend en charge la conversation SIP et de lui transférer l’appel
Step 8:
Ce SIP INVITE avec le champ Replaces Header envoyé par le CMS-A inclue la payload SDP, à l’interieur du SDP, le CMS-A propose l’adresse IP 10.1.5.50 et le port Audio RTP 37700 / port Video RTP 37702 à jsmith@lab.local pour l’établissement du media (flux RTP avec lui).
Puisque le BR-CUCM est configuré avec l’option activée Accept Replaces Header dans le SIP Trunk Security Profile et ce profile est appliqué dans le trunk SIP vers le CMS-A.
Le call control BR-CUCM envoie un message SIP Cancel au CMS-B afin de mettre fin à la conversation SIP, le CMS-B répond à son tour par un message SIP avec le code 487 Request Terminated. Enfin le BR-CUCM répond quant à lui par message ACK afin d’acquitter la réception du message 487 Request Terminated.
Maintenant le CMS-A remplace the CMS-B dans la conversation SIP initiée par jsmith.
BR-CUCM a besoin d’informer le client jabber jsmith sur le changement opéré dans sa conversation SIP initiale, il envoie pour cela un SIP Update à jsmith pour l’informer du changement et de la mise à jour de son appel initié auparavant.
Dans le message SIP Update, l’identifiant de l’appel Call ID 000c2972-b1cc00ae-00006003-000060e0@10.1.5.114 est le même que l’identifiant Call ID du message SIP INVITE envoyé par jsmith@lab.local dans l’étape 2.
Ce message SIP Update a été routé avec succès à jsmith par le BR-CUCM grâce à la rerouting CSS appliquée dans le Trunk SIP pointant vers le CMS-A et qui contient la partition Directory URI de l’utilisateur jsmith.
Le client jabber jsmith répond par un message SIP 200 OK.
Au final, le BR-CUCM envoie un message SIP 200 OK avec la payload SDP à jsmith@lab.local, à l’intérieur du SDP, l’adresse IP 10.1.5.50 du CMS-A et le port Audio RTP port 37700 / port Vidéo RTP port 37702 du CMS-A proposés dans l’étape 8.
Le BR-CUCM envoie aussi un message SIP 200 OK avec SDP au CMS-A, à l’intérieur du SDP, l’adresse IP 10.1.5.114 de jsmith et le port Audio RTP port 23086 / Vidéo RTP port 29970 de jsmith proposés dans l’étape 1.
Le CMS-A envoie un message SIP ACK pour acquitter la réception du message SIP 200 OK.
Jsmith envoie un message SIP ACK pour acquitter la réception du message SIP 200 OK.
Finalement, le media est établi directement entre jsmith@lab.local avec l’adresse IP 10.1.5.114 et le port UDP 23086, et le CMS-A avec l’adresse IP 10.1.5.50 et le port UDP port 37700.
Ci-dessous l’utilisateur pperez@lab.local 10.1.5.100 qui a créé la conference avec le flux RTP établi avec le CMS-A 10.1.5.50.
Dans l’interface graphique du CMS-A, aller dans Status > Call, on peut vérifier que deux appels sont actifs et qui émanent de pperez@lab.local et jsmith@lab.local. Il n’y’a plus d’appels distribués entre le CMS-A et le CMS-B.
Ainsi on a démystifié pourquoi il faut une Rerouting CSS et l’option Accept Replcaces Header pour la fonctionnalité Call Bridge Group.
Pour finir en beauté comme dans un match de foot je vous offre ce schéma concocté spécialement afin de résumer ce call flow et les étapes énumérées précédemment et qui montre la tactique utilisée pour gagner ce match.
