Cisco Meeting Server
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.
- Évolutivité, 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. Dans une architecture distribuée, cela implique que l'utilisation du concept CallBridge Group nécessite un RTT inférieur à 100 ms.
Configuration du cluster Cisco Meeting Server
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.
Préparation des certificats
La deuxième étape consiste en la préparation des certificats pour le clustering. Deux types de certificats sont nécessaires, un certificat server avec comme Common Name CN:FQDN du Master et dont le SAN inclue le FQDN des slaves, et un certificat client avec comme Common Name CN:postgres.
Configuration du cluster Database
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'implémentation du cluster débutera avec le clustering de la database au niveau du Master, ensuite les autres nœuds slaves vont joindre le cluster database à travers le master.
Il est recommandé d’avoir un nombre impair (max 5) de serveurs database Cisco Meeting Server pour implémenter un cluster database.
Le master de la base de données écoute sur le port 5432 pour les connections provenant des slaves, si un firewall est présent entre les nœuds, ce port doit être autorisé.
Les services We CallBridge et WebBridges seront mis en cluster une fois le cluster database est opérationnelle.
La redondance dans un cluster CMS fonctionnement comme suit :
- CallBridge: Active/Active
- WebBridge3: Active/Active
- Database: Active/Standby
Configuration des services
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.
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
Cisco Meeting Management
Cisco Meeting Management est un serveur de gestion des meetings hébergés au niveau des CallBridges, il permet :
- Un management centralisé des meetings planifié
- Affichage les meetings actifs
- Visualiser les participants connectés
- Inviter une personne au meeting ou le retirer, mettre fin à un meeting
- Contrôler le recording et le streaming
- Changer les dispositions (layouts) et Observer les statistiques des appels
Cisco Meeting Management peut être intégré avec Cisco Telepresence Management Suite pour la planification des meetings. Il faut noter qu’à partir de la version 3.0 de Cisco Meeting Server, les licences sont gérées par Cisco Meeting Management via le smart licensing.
Configuration de Cisco Meeting Management
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.
Ajout des CallBridges
Les CallBridges des sites Hassi Messaoud et Alger seront ajoutés avec l’IP ou bien le FQDN et les logins du WebAdmin sur le port 445, et la chaine de certification créée lors de la préparation des certificats.
Activation des licences
Activation des licences une fois les CallBridges sont ajoutés via le smart licensing.
Cisco Unified Communication Manager
Cisco Unified Communication Manager est le call control de la solution collaboration de Cisco, il est responsable du traitement des appels, de l’étape setup de l’appel jusqu’à la fin de ce dernier. Il est responsable de l’acheminement et du routage des appels en se basant sur une table de routage des appels appelée « Route Plan Report ». Il peut être déployé en standalone ou en cluster.
L’objectif d’un déploiement en cluster est :
- La haute disponibilité du call control offrant la redondance pour la signalisation et le media.
- L’évolutivité pour prendre en charge les endpoints si le nombre de ses derniers augmente dans le futur.
La décision du nombre de subscriber dans un cluster Cisco Unified Communication Manager dépend des facteurs suivants:
- Redondance
- Partage de charge
- Evolutivité
Dans un cluster CUCM, il y’a 2 types de serveurs :
Publisher : Le Publisher contient une copie en lecture et écriture de la base de données IBM Informix. Dans un cluster CUCM on ne peut avoir qu’un seul serveur Publisher.
Subscriber : Le Subscriber contient une copie en lecture seulement, à partir de la version 6.0, le Subsbriber à le privilège d'écriture sur la base de données pour les UFFs (User-Facing Features) comme le CFA (Call Forward All), Device Mobility, MWI (Message Waiting Indicator).
Le maximum de noeuds Cisco Unified Communication Manager dans un cluster est 20 réparti comme suit:
- Un seul publisher
- Max 8 Subscriber responsable du traitement des appels avec le service Call Manager activé.
- Les 11 subscribers se verront activés les différents services restants comme TFTP, Music On Hold (MOH), Annunciator, etc.
Cette répartition des services assure une haute disponibilité pour le traitement des appels et une répartition des ressources des nœuds, Par exemple sur un même subscriber TFTP, en plus du service TFTP, il est possible d'activer un ou plusieurs services. Dans un déploiement avec plus de 1250 utilisateurs, il est recommandé d'avoir un subscriber TFTP dédié, autrement les autres services peuvent être impactés.
Note : Dans un déploiement avec plus de 1250 utilisateurs, il est recommandé d’utiliser un nœud comme publisher dédié sans activation de services.
Prenons une architecture multi-site distribuée à travers le WAN, deux serveurs sis au site central HQ et deux serveurs dans un site distant.
Du moment le cluster est distribué sur deux sites, il est recommandé d’avoir un RTT inférieur à 80 millisecondes.
Cisco Unified Communication Manager sera intégré avec le cluster CMS via un trunk sip pour permettre à des utilisateurs internes d’utiliser leurs terminaux ou bien l’application Jabber pour joindre un meeting hébergé dans le CallBridge, le routage des appels sera basé sur une SIP Route Pattern et une Route Pattern, une Route List, une Route Group et un trunk sip. La SIP Route Pattern permettra aux utilisateurs d’utiliser des URI sous le format meet@domain.com tant dis qu’une route pattern leurs permettra d’utiliser une extension pour joindre un meeting.
Cisco Unified Communication Manager sera intégré avec Cisco Expressway Core et Edge pour le MRA (Mobile Remote Access), le MRA est fonctionnalité qui permet à un utilisateur nomade d’enregistrer son application Jabber au niveau du Call Control via Cisco Expressway et par conséquent placer des appels sécurisés.
Le MRA se base sur une zone traversal entre l’Expressway C et l’Expressway E, celle-ci sera utilisée pour WebRTC Cisco Meeting App par les utilisateurs nomades dans le but de joindre un meeting derrière la toile internet tout en assurant la sécurité.
Configuration du cluster Cisco Unified Communication Manager
Configuration du Publisher et des subscribers
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.
Note : le publisher doit être installé en premier avec au préalable un serveur NTP opérationnel.
Activation des services
Activation des services suivant :
- Le service Call Manager pour le call processing.
- Le service TFTP pour les fichiers de configuration lors de l’enregistrement des endpoints.
- Le service DireSync pour l’integration avec Active Directory.
- Le service Dialed Number Analyzer pour les tests et les dépannages.
Note : d’autres services seront installés lors de l’intégration d’autres applications.
Intégration avec Le cluster CMS
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 sont les routeurs ou un autre cluster de CUCM/CMS 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.
Pour l’intégration du cluster Cisco Unified Communication Manager avec le cluster Cisco Meeting Server avec un dial plan basé sur ces composants ainsi il sera adapté au load balancing intelligent offert par la fonctionnalité CallBridge Group.
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.
Sans le CallBridge Group, le call flow est comme suit:
- Un premier participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM cherche une SIP Route Pattern meet.demystify.com
- Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
- Le Cluster CUCM vérifie la Route Group associée à la route list
- 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
- Le Cluster CUCM route l'appel au CMS-1
- La conférence nommée ccnp est active sur CMS-1
- Un deuxième participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM cherche une SIP Route Pattern meet.demystify.com
- Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
- Le Cluster CUCM vérifie la Route Group associée à la route list
- 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
- Le Cluster CUCM route l'appel au CMS-2
- CMS-2 distribue l'appel au CMS-1
- Un troisième participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM cherche une SIP Route Pattern meet.demystify.com
- Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
- Le Cluster CUCM vérifie la Route Group associée à la route list
- 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
- Le Cluster CUCM route l'appel au CMS-3
- CMS-3 distribue l'appel au CMS-1
- Un quatrième participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM cherche une SIP Route Pattern meet.demystify.com
- Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
- Le Cluster CUCM vérifie la Route Group associée à la route list
- 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
- Le Cluster CUCM route l'appel au CMS-4
- 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.
Figure Call Flow sans le Call Bridge Group
Au total 16 ports utilisés pour une conférence de 4 participants.
Figure Call Flow Simplifié sans le CallBridge Group
Avec le CallBridge Group, le call flow est comme suit:
- Un premier participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM cherche une SIP Route Pattern meet.demystify.com
- Le Cluster CUCM vérifie la Route List associée à la SIP Route Pattern
- Le Cluster CUCM vérifie la Route Group associée à la route list
- 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
- Le Cluster CUCM route l'appel au CMS-1
- La conférence nommée join est active sur CMS-1
- Un deuxième participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM Route l'appel au CMS-2
- CMS-1 envoie un SIP Invite avec Replace Header indiquant au CUCM de rerouter l'appel précèdent au CMS-1
- Le Cluster CUCM route l'appel au CMS-1
- Un troisième participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM Route l'appel au CMS-3
- CMS-1 envoie un SIP Invite avec Replace Header indiquant au CUCM de rerouter l'appel précèdent au CMS-1
- Le Cluster CUCM route l'appel au CMS-1
- Un quatrième participant compose l'URI ccnp@meet.demystify.com
- Le Cluster CUCM Route l'appel au CMS-4
- CMS-1 envoie un SIP Invite avec Replace Header indiquant au CUCM de rerouter l'appel précèdent au CMS-1
- Le Cluster CUCM route l'appel au CMS-1
Figure Call Flow avec le Call Bridge Group
Figure Call Flow Simplifié sans le CallBridge Group
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.
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.
Cisco Expressway Series
La solution Cisco Expressway Series offre les fonctionnalités des appels inter-entreprises (B2B) et Cisco Mobile MRA pour les utilisateurs nomades et mobiles sur INTERNET tout en garantissant des appels sécurisés pour ses utilisateurs, Il permet également d’outrepasser :
- Le problème causé par la présence d’un équipement NAT entre deux endpoints pour l’établissement du flux RTP après la négociation des adresses IP et des numéros de port via le protocole de signalisation SIP avec la fonctionnalité NAT Traversal.
- Le problème du firewall qui bloque tous les appels initiés de l’INTERNET c’est à dire d’une zone untrust vers le réseau de l’entreprise qui est la zone trust avec la fonctionnalité Firewall Traversal.
Cisco Expressway Series se base deux serveurs dénommés Expressway-Core et Expressway-Edge pour fournir les fonctionnalités B2B et MRA, NAT Traversal et Firewall Traversal.
Un cluster Cisco Expressway permet d'assurer la résilience pour les différentes fonctionnalités énumérées ci-dessus, par exemple avec deux Expressway Edges, un client jabber peut s'enregistrer au niveau du call control CUCM de l'entreprise via un deuxième Expressway Edge dans le cas où le premier Expressway Edge n'est plus disponible.
Chaque membre du cluster doit avoir le même dial plan, si un Expressway possède une "search rule" pour router un appel vers une destination, les autres membres doivent bien évidemment avoir la même "search rule" pour pouvoir router le même appel vers cette destination. Si le dial plan est diffèrent entre les serveurs Expressway, alors des clusters séparés doivent être utilisés.
Cisco Expressway Edge et Cisco Expressway Core ne peuvent pas coexister dans le même cluster.
Lorsque ces deux clusters sont distribués sur le WAN avec un cluster Expressway Edge et un Expressway Core sur chaque site. Il est recommandé d'avoir un RTT qui n'excède pas les 30 Millisecondes.
Pour former un cluster:
- Un maximum de 6 membres dans un cluster
- Les membres doivent être ajoutés un par un
- La modification doivent être faites au niveau de l'Expressway Primaire et automatiquement synchronisées avec les autres membres
- Déployer un nombre identique de membres dans un cluster Expressway Edge et un cluster Expressway Core
- Le protocole H.323 doit etre activé.
- Les fonctionnalités MRA et B2B sont implémentées dans le même cluster Expressway Edge et Expressway Core, le numéro de port SIP utilisé dans le Trunk SIP entre Cisco CUCM et Cisco Expressway-C doit être modifié pour utiliser le port 5061 à place du port par défaut 5060.
- Le record SRV DNS doit être disponible pour le cluster and doit contenir les A records des membres du cluster.
- Chaque cluster doit avoir un Cluster Name sous le format d'un FQDN où la partie du domaine est utilisé pour les records SRV.
- Lors de la création de la zone traversal serveur, le Cluster Name des nœuds Expressway Core doit correspondre à l'attribut SAN du certificat de ses Expressway Core.
- Lors de la création de la zone traversal client, le FQDN de chaque Expressway Edge doit correspondre à l'attribut SAN du certificat de l'Expressway Edge.
Intégration de Cisco Expressway avec Cisco Meeting Server
L’intégration de Cisco Expressway Edge et Core comme solution Unified Edge avec Cisco Meeting Server permet aux utilisateurs nomades se trouvant sur INTERNET de joindre une conférence hébergée au niveau de Cisco Meeting Server localisé dans le réseau interne de l’entreprise en utilisant un navigateur supportant le WebRTC d’une manière sécurisée.
Etapes de configuration de Web Proxy
- Mise en place de la zone Unified Communication traversal MRA entre le cluster Expressway-C et le cluster Expressway-E pour MRA (Mobile Remote Access) et Web Proxy
- Intégration du cluster Cisco Unified Communication Manager avec Cisco Expressway-C pour permettre aux utilisateurs nomades d’enregistrer leurs clients Jabber dans le cluster CUCM
- Activation de l’option Cisco Meeting Server Web Proxy et configuration de Guest account client URI exemple : meet.collab.com
- Un A record DNS interne doit exister pour meet.collab.com pour la résolution des adresses IP privées des WebBridges Cisco Meeting Servers par les serveurs Expressway-C, meet.collab.com doit apparaitre dans le SAN du certificat des WebBridges. Pour un meilleur partage de charge selon la capacité des WebBridges, il est recommandé d'utiliser le SRV record _cms-web._tls.meet.collab.com, cela permet d'octroyer des priorités et des poids pour les WebBridges au niveau des DNS de telle sorte les connections WebRTC émanant des Expressway-C seront dirigés selon les capacités des WebBridges.
- Un A record DNS externe doit exister pour la résolution des adresses IP publiques des serveurs Expressway-E par les utilisateurs nomades, meet.collab.com doit apparaitre dans le SAN du certificat des serveurs Expressway-E. Le load Balancing DNS est basé sur le Round Robin.
- Activation de TurnServer dans le cluster Cisco Expressway-E
Note: Il est recommandé d’utiliser le port 445 au lieu de 443 pour l’accès à l’interface graphique des serveurs Cisco Expressway Edge.
