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.
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.
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.
Configurez un nom du Template et un Display Name, par exemple Cisco Meeting Server et CMS respectivement.
Dans la console certificate, on émet le certificat template dénommé CMS.
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.
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.
On sélectionne Base 64 Encoded on clique Download certificate, on sauvegarde le certificate avec le nom cmscert.
Ci-dessous les détails du certificat dénommé cmscert généré auparavant.
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.
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.
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.
On selectionne Base 64 Encoded et on clique sur Download certificate.
Finalement on obtient un certificat d’un CA intermédiaire nomme adcert qui ressemblera à ça.
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.
On utilise Base 64 et on clique sur Download CA certificate, ici j’l’ai nommé Root-CA.
Le certificat de l’autorité de certification ressemblera à ça.
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.
On édite le certificat du CA Root-CA avec nodepad également.
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.
Notre chaine de certificat CA-Chain ressemblera à ça.
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.
Ensuite on édite la chaine de certificat CA-Chain avec nodepad également.
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.
Ci-dessous la chaine de certificat CMS-Chain qui sera utilisé pour le webbridge3.
La dernière étape consister à copier les trois certificats cmscert, CA-Chain et CMS-Chain dans hq-cms avec WinSCP.
On peut vérifier avec la commande pki list que les trois certificats sont bel et bien copiés.
L’activation des services se fera selon le procédé suivant :
- WebAdmin
- CallBridge
- 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.
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:
- Incoming Call Table
- Call Forwarding Table
- Outbound Call Table
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 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.
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.
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.
hq-cms>webadmin certs cmscert.key cmscert.cer CA-Chain.cer
On configure la redirection du http vers https.
hq-cms>webadmin http-redirect enable
Finalement on active le service WebAdmin.
hq-cms>webadmin enable
La commande webadmin est très utile pour vérifier que tout est bon.
Activation de la licence d’eval avec Cisco Meeting Management
A partir de l’interface graphique de Cisco Meeting Management hq-cmm.
Dans Settings, aller dans License, clique sur Change et selectionner Smart Licensing.
Clique Save.
Ajouter le CallBridge au CMM
Clique sur Servers pour ajouter le Callbridge au CMM. Clique Add Call Bridge.
Entrer les informations suivantes :
- Server Address: 10.1.5.20
- Port: 445
- Username: admin
- Password: (password of CMS)
- Display name: hq-cms
Cocher l’option Use Trusted Certificate Chain boxes. Sélectionner la chaine de certificat CA-Chain créé précédemment.
Aller ensuite dans License, et clique sur Start Trial. Le CMM doit avoir une connectivité internet pour activer le mode trial.
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
Verifier le service callbridge.
Configuration du WebBridge3
Toujours en ligne de commande, entrez les commandes suivantes.
Vérifier la configuration du WebBridge3.
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.
