Cisco Meeting Server combine les conférences audio, vidéo et Web dans une seule solution pour répondre aux besoins de collaboration. La solution permet de garantir aux participants une expérience de réunion cohérente et familière, qu’ils rejoignent une réunion à l’aide d’une solution Cisco ou de terminaux tiers.

L’objectif dans un déploiement avec plus d’un nœud CMS est:

  • Haute Disponibilité, voir le même service dans plusieurs nœuds, par exemple si les CallBridges sont en cluster, si un call bridge est hors service, un autre CallBridge peut héberger les meetings.
  • Evolutivité, en d’autre termes, un meeting peut être hébergé par plusieurs CallBridge si l’un deux n’a pas assez de capacité pour héberger tous les participants. (En règle générale, il est recommandé d’avoir le meeting et ses participants hébergés par un seul CallBridge avec la notion de distribution ou bien d’une manière encore plus optimale en utilisant la fonctionnalité CallBridge Group).
  • Efficacité, un Meeting Server peut décider quels sont les nœuds du cluster offrant une meilleur expérience utilisateur pour des participants se connectant de différents emplacements géographiques.

L’Intégration avec Cisco Expressway comme EDGE à la place de l’ancienne solution Cisco CMS Edge afin de permettre aux participants de se connecter à un meeting en utilisant un navigateur supportant le WebRTC. Cisco Expressway version X8.11 et plus supporte le CallBridge Group pour un équilibrage de charge efficace dans un environnement Cluster CallBridges, cela permet en effet de réduire le nombre de distribution entre les CallBridge réduire ainsi le nombre de ports HD.

C:\Users\acer\Desktop\Blog\topo.PNG

Dans cet article vous verrez la configuration initiale de Cisco Meeting Server et principalement la préparation des certificats SSL pour les différents services que composent le CMS, cette étape est vitale pour déployer la solution on-premise de conferencing Cisco Meeting Server ainsi que la configuration des services WebAdmin, CallBridge et WebBridge.

Configuration de base

La première étape d’implémentation concerne les paramètres réseaux nécessaires pour la connectivité: Adresse IP, Gateway, Serveur DNS, nom de domaine et le serveur NTP.

acano>hostname hq-cms

acano>reboot

hq-cms>

hq-cms>ipv4 a add 10.1.5.20/24 10.1.5.29

hq-cms>ntp server add 10.1.5.29

hq-cms>dns add forwardzone collab.com 10.1.5.27

Préparation des certificats

La deuxième étape consiste en la préparation des certificats pour les services.

Un serveur Cisco Meeting Server est composé des modules suivants:

  • WebAdmin: Pour l’administration à travers l’interface graphique.
  • WebBridge3: Pour assurer la fonctionnalité WebRTC.
  • CallBridge: C’est le pont de conférence qui héberge les meetings.

L’activation et l’implémentation des services nécessitent des certificats, un certificat avec comme Common Name CN:non de domaine et dont le SAN inclue par exemple les FQDNs webbridge.domain.com, callbridge.domain.com, les FQDNs des nœuds ainsi que l’URL Guest pour l’accès en WebRTC, le deuxième certificat est une chaine de certification composé du certificat racine du CA et un certificat de subordination avec le Common Name = nom de domaine. Les certificats doivent être signés par un CA interne ou externe.

Pour générer un CSR Certificate Signing Request et une clé privée, on utilise la commande suivante, ici on donne un nom cmscert.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS\8.PNG

hq-cms>pki csr cmscert CN:collab.com OU:CCNP O:Collaboration L:Hydra ST:Algiers C:AL subjectAltName:webbridge.collab.com,xmpp.collab.com,callbridge.collab.com,join.collab.com,webadmin.collab.com,hq-cms.collab.com,*.lab.local,10.1.5.20

Pour récupérer le CSR, il suffit de se connecter au CMS en utilisant l’outil WinSCP et on copy le CSR crée précédemment dans votre PC.

Au niveau du serveur CA 10.1.5.27.

Lancez la console Certification Authority, sélectionner Certificate Template. Double clic sur le Certificate Template et sélectionner Manage.

Faites un duplicate du template Web Server et configurer le nouveau template pour fournir l’authentification client et serveur.

C:\Users\acer\Desktop\Lab TMS Clustering\AD CERT Template\2.PNG

Configurez un nom du Template et un Display Name, par exemple Cisco Meeting Server et CMS respectivement.

C:\Users\acer\Desktop\Lab TMS Clustering\AD CERT Template\1.PNG

C:\Users\acer\Desktop\Lab TMS Clustering\AD CERT Template\3.PNG

Dans la console certificate, on émet le certificat template dénommé CMS.

C:\Users\acer\Desktop\Lab TMS Clustering\AD CERT Template\4.PNG

Au niveau d’un pc, on accede au server CA en utilisant l’URL suivante http://10.1.5.27/certsrv.

Clique sur Request a certificate ensuite sur advanced request certificate.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\1.PNG

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\2.PNG

On édite le CSR crée précédemment avec bloc-notes et on copie le contenu. On colle ensuite le CSR dans la partie Base-64 encoded et on sélectionne le certificate template Cisco Meeting Server.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\6.PNG

On sélectionne Base 64 Encoded on clique Download certificate, on sauvegarde le certificate avec le nom cmscert.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\CERT\2.PNG

Ci-dessous les détails du certificat dénommé cmscert généré auparavant.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\Nouveau dossier\1.PNG

Une chaine de certificat est requise pour truster le certificat cmscert lorsqu’on activera les services webadmin, callbridge et webbridge3.

Une chaine de certificat est un fichier unique avec l’extension .pem, .cer ou bien .crt qui englobe le certificat du CA c’est-à-dire le root CA ainsi que les certificats intermédiaires dans la chaine

Pour créer une chaine de certificat, il nous faut le certificat du CA et un certificat de subordination avec comme Common Name : collab.com.

Pour générer un certificat de subordination, il nous faut un CSR.

On peut utiliser plusieurs outils dont openssl pour générer un CSR avec un Common Name : collab.com.

Si vous n’avez pas openssl, on peut intuitivement utiliser le CMS pour générer le CSR.

A partir de la ligne command du CMS, on génère un CSR avec comme Common Name : collab.com. On lui octroie un nom, par exemple adcert.

hq-cms>pki csr adcert CN:collab.com OU:CCNP O:Collaboration L:Hydra ST:Algiers C:AL

Ensuite on utilisera le WinSCP pour copier le CSR afin de le soumettre à notre autorité de certification.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\winscp1.PNG

Au niveau du serveur CA, on procède de la même manière qu’auparavant afin de générer un certificat dont le common name est collab.com à partir du CSR adcert.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\1.PNG

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\2.PNG

On édite le CSR adcert avec notepade et on colle le contenu. Il est très important de sélectionner dans Certificate Template, Subordinate Certification Authority. Cela nous permettra par la suite de créer un Certificat Bundle afin de l’utiliser comme une chaine de certificat pour truster le certificat des services.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\5.PNG

On selectionne Base 64 Encoded et on clique sur Download certificate.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\4.PNG

Finalement on obtient un certificat d’un CA intermédiaire nomme adcert qui ressemblera à ça.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\ADCERT1.PNG

Il nous reste maintenant de télécharger le Certificat de l’autorité de certification ou bien communément connu Root CA en cliquant simplement sur Download a CA certificate, certificate chain, or CRL.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\1.PNG

On utilise Base 64 et on clique sur Download CA certificate, ici j’l’ai nommé Root-CA.

C:\Users\acer\Desktop\Collaboration\Lab TMS Clustering\AD CERT\3.PNG

Le certificat de l’autorité de certification ressemblera à ça.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\root ca 1.PNG

Maintenant le certificat du CA Root-CA et le certificat intermédiaire ou subordonné adcet sont prêts, on peut procéder à la création d’une chaine de certificat.

Pour créer une chaine de certificat, on utilise le notepad. Tous les caractères qui incluent

—–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– doivent être inserés dans le document txt.

On edite le certificat intermédiaire adcert créé précédemment avec notepad.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\ADCERT.PNG

On édite le certificat du CA Root-CA avec nodepad également.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\Root CA.PNG

On colle le certificate adcert en premier et ensuite le certificat Root-CA en deuxième.

Il ne faut pas qu’il y’ait d’espace entre la ligne —–END CERTIFICATE—– du premier certificate et la ligne —–BEGIN CERTIFICATE—– du deuxième certificat. Finalement on sauvegard le fichier avec l’extension .cer et on le renomme CA-Chain.cer.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CA-Chain2.PNG C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CA-Chain3.PNG

Notre chaine de certificat CA-Chain ressemblera à ça.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CA-Chain1.PNG

Une chaine de certificat est aussi requise pour le Webbridge3 dans version 3.

Pour le créer, il nous faut le certificat cmscert et la chaine de certificat CA-Chain crées auparavant.

Dans le premier temps on édite le certificat cmscert avec nodepad.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CMS-CERT2.PNG

Ensuite on édite la chaine de certificat CA-Chain avec nodepad également.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CA-Chain2.PNG C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CA-Chain3.PNG

On colle le certificat cmscert en premier ensuite on colle le certificat CA-Chain certificate en deuxième lieu. Finalement on sauvegarde le fichier avec l’extension .cer extension. On le nomme par exemple CMS-Chain.cer.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CMS-Chain1.PNG C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CMS-Chain2.PNG

Ci-dessous la chaine de certificat CMS-Chain qui sera utilisé pour le webbridge3.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\CMS-Chain.PNG

La dernière étape consister à copier les trois certificats cmscert, CA-Chain et CMS-Chain dans hq-cms avec WinSCP.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\winscp.PNG

On peut vérifier avec la commande pki list que les trois certificats sont bel et bien copiés.

C:\Users\acer\Desktop\Lab TMS Clustering\Cert preparation\PKI List.PNG

L’activation des services se fera selon le procédé suivant :

  1. WebAdmin
  2. CallBridge
  3. WebBridge3

Note: Il recommandé d’utiliser le port 445 au lieu de 443 pour l’accès à l’interface graphique des serveurs Cisco Meeting Server. Le port traditionnel 443 sera utilisé pour le WebRTC lorsque les utilisateurs accèdent au meeting en utilisant le navigateur avec une URL Guest du portal Cisco Meeting App, par exemple https://join.domain.com, cela leur évitera d’être redirigés vers l’interface graphique d’un serveur Cisco Meeting Server.

Cisco Meeting Server Spaces

Un « Space » est une salle virtuelle qui permet à des utilisateurs de joindre une conférence ou un meeting. Spaces est la terminologie qu’on trouve dans le fonctionnement de Cisco Meeting Server et dans l’interface graphique d’administration, Cisco Meeting Server contient une Space table, un administrateur peut ajouter des Spaces ou bien s’appuyer sur Active Directory lors de l’import des AD users pour une création d’un space personnel pour chaque AD user. Cette space table contient trois informations importantes lors de la création des spaces:

  • Le nom du space
  • User Portion URI
  • Meeting ID ou bien Call ID

Pour pouvoir router un utilisateur vers un space, Cisco Meeting Server utilise la partie host de l’URI pour trouver un match dans la table Incoming Rules.

Un space ou un meeting (Conférence) peut être joint en utilisant une URI ou bien un Numéro (Meeting ID), à partir d’un système Télépresence, un navigateur web supportant le WebRTC pour les utilisateurs Nomades avec une URL Guest, ou bien un Téléphone en composant le numéro correspondant au Meeting ID.

C:\Users\acer\Desktop\LLD HLD\Topo and image\21.PNG

Cisco Meeting Server Dial Plan

Le routage des appels dans Cisco Meeting Server sollicite peu de tables de routage et elles sont analysées dans l’ordre suivant:

  1. Incoming Call Table
  2. Call Forwarding Table
  3. Outbound Call Table

C:\Users\acer\Desktop\LLD HLD\Topo and image\12.PNG

Ci-dessous, un schéma qui résume comme un endpoint enregistré dans le call control Unified CM accède à un meeting, ou une conférence, ou bien un space (les trois mots signifient la meme chose) en composant l’URI du meeting.

Pour rappel une URI est composé de la partie user et la partie host.

Exemple :

ccnp@collab.lab.local.

Ccnp est la partie user. (Ça peut être aussi des chiffres 1111).

Collab.lab.local est la partie host ou bien domaine SIP.

Le routage des appels URIs se base bien évidemment sur la partie host ou domaine SIP, par conséquent, il est nécessaire d’avoir une SIP route pattern pour router les URIs.

C:\Users\acer\Desktop\Blog\Capture.PNG

Activation du service WebAdmin

Le service WebAdmin est responsable de l’interface graphique du CMS. Pour pouvoir configurer notre CMS via GUI, il est impératif d’activer ce service.

Par défaut le WebAdmin écoute sur le port 443. Mais dans un déploiement avec le WebRTC, il est recommandé de modifier ce port afin de laisser le port 443 pour les utilisateurs guest qui utiliseront le WebRTC du navigateur pour accéder à un meeting.

Généralement le port 445 est utilisé pour le WebAdmin, ainsi pour accéder à l’interface graphique, on utilisera l’URL https://10.1.5.20:445.

La commande suivante nous permettra de spécifier l’interface sur laquelle le CMS écoutera et le port.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS\3.PNG

hq-cms>webadmin listen a 445

Les certificates sont primordiaux pour activer tous les services WebAdmin, CallBridge et WebBridge3.

Il est à noter qu’on peut utiliser un certificat par service ou bien un seul certificat pour tous les services, dans cet exemple, le meme certificat sera utilisé pour tous les services.

Pour spécifier le certificat qui sera utilisé par le service WebAdmin, on utilise la commande suivant, il est très important de spécifier la clé privée du certificat ainsi que la chaine des autorités qui va valider ce certificat.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS\4.PNG

hq-cms>webadmin certs cmscert.key cmscert.cer CA-Chain.cer

On configure la redirection du http vers https.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS\5.PNG

hq-cms>webadmin http-redirect enable

Finalement on active le service WebAdmin.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS\6.PNG

hq-cms>webadmin enable

La commande webadmin est très utile pour vérifier que tout est bon.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS\7.PNG

Activation de la licence d’eval avec Cisco Meeting Management

A partir de l’interface graphique de Cisco Meeting Management hq-cmm.

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\1.PNG

Dans Settings, aller dans License, clique sur Change et selectionner Smart Licensing.

Clique Save.

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\3.PNG

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\4.PNG

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\7.PNG

Ajouter le CallBridge au CMM

Clique sur Servers pour ajouter le Callbridge au CMM. Clique Add Call Bridge.

Entrer les informations suivantes :

  1. Server Address: 10.1.5.20
  2. Port: 445
  3. Username: admin
  4. Password: (password of CMS)
  5. Display name: hq-cms

Cocher l’option Use Trusted Certificate Chain boxes. Sélectionner la chaine de certificat CA-Chain créé précédemment.

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\8.PNG

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\9.PNG

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\10.PNG

Aller ensuite dans License, et clique sur Start Trial. Le CMM doit avoir une connectivité internet pour activer le mode trial.

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\11.PNG

C:\Users\acer\Desktop\Lab TMS Clustering\CMM\12.PNG

Configuration du CallBridge

Configurer le service callbridge pour écouter sur l’interface a.

hq-cms>callbridge listen a

Specifier le certificat cmscert créé précédemment, la clé privée ainsi que la chaine d’autorité.

hq-cms>callbridge certs cmscert.key cmscert.cer CA-Chain.cer

Redémarrer le service callbridge

hq-cms>callbridge restart

C:\Users\acer\Desktop\Lab TMS Clustering\CMS1\1.PNG

Verifier le service callbridge.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS1\2.PNG

Configuration du WebBridge3

Toujours en ligne de commande, entrez les commandes suivantes.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS1\3.PNG

Vérifier la configuration du WebBridge3.

C:\Users\acer\Desktop\Lab TMS Clustering\CMS1\4.PNG

Dans le prochain article nous allons voir la logique du routage des appels avec Cisco Meeting Server, la création des spaces ainsi que l’integration avec Unified CM via un trunk SIP pour permettre à des utilisateurs de joindre un space ou un meeting via l’application jabber ainsi que l’utilisation de Cisco Web App via le navigateur.

Write A Comment