Serveur de réunion Cisco 2.5.2. Cluster en mode évolutif et résilient avec enregistrement de visioconférence

Dans ce numéro, je montrerai et expliquerai certaines des subtilités de la configuration d'un serveur CMS en mode cluster de basculement.


ТеорияEn général, il existe trois types de déploiement de serveur CMS :

• Simple combiné(Simple combiné), c'est-à-dire il s'agit d'un serveur sur lequel tous les services nécessaires sont exécutés. Dans la plupart des cas, ce type de déploiement ne convient que pour l'accès client interne et dans des environnements plus petits où les limitations d'évolutivité et de redondance d'un seul serveur ne constituent pas un problème critique, ou dans les situations où le CMS n'exécute que certaines fonctions, telles que des fonctions ad hoc. conférences sur Cisco UCM.

  Schéma approximatif de travail :
  

• Division simple(Single Split) étend le type de déploiement précédent en ajoutant un serveur distinct pour l'accès externe. Dans les déploiements existants, cela signifiait déployer un serveur CMS dans un segment de réseau démilitarisé (DMZ) où les clients externes pouvaient y accéder, et un serveur CMS dans le cœur du réseau où les clients internes pouvaient accéder au CMS. Ce modèle de déploiement particulier est désormais remplacé par ce qu'on appelle le modèle de déploiement Bord unique, qui se compose de serveurs Voie express Cisco, qui ont ou auront bon nombre des mêmes capacités de contournement du pare-feu afin que les clients n'aient pas besoin d'ajouter un serveur CMS Edge dédié.

  Schéma approximatif de travail :
  

• Évolutif et résilient(Évolutif et tolérant aux pannes) Ce type inclut une redondance pour chaque composant, permettant au système d'évoluer avec vos besoins jusqu'à sa capacité maximale tout en fournissant une redondance en cas de panne. Il utilise également le concept Single Edge pour fournir un accès externe sécurisé. C'est le type que nous examinerons dans cet épisode. Si nous comprenons comment déployer ce type de cluster, nous comprendrons non seulement d'autres types de déploiements, mais nous pourrons également comprendre comment créer des clusters de serveurs CMS pour répondre à la croissance potentielle de la demande.

Avant de passer au déploiement, vous devez comprendre certaines choses de base, à savoir

Principaux composants du logiciel CMS :

• Base de données: Permet de combiner certaines configurations, telles que le plan de numérotation, les espaces utilisateur et les utilisateurs eux-mêmes. Prend en charge le clustering pour la haute disponibilité (maître unique) uniquement.
• Pont d'appel: un service d'audio et de vidéoconférence qui offre un contrôle total sur la gestion et le traitement des appels et des processus multimédia. Prend en charge le clustering pour une haute disponibilité et une évolutivité.
• Serveur XMPP: responsable de l'enregistrement et de l'authentification des clients utilisant l'application Cisco Meeting et/ou WebRTC(communication en temps réel, ou simplement dans le navigateur), ainsi que la signalisation intercomposants. Peut être mis en cluster pour la haute disponibilité uniquement.
• Pont Web: Fournit un accès client à WebRTC.
• Équilibreur de charge: Fournit un point de connexion unique pour les applications Cisco Meeting en mode Single Split. Écoute l'interface externe et le port pour les connexions entrantes. De même, l'équilibreur de charge accepte les connexions TLS entrantes du serveur XMPP, via lesquelles il peut basculer les connexions TCP des clients externes.
  Dans notre scénario, cela ne sera pas nécessaire.
• Serveur TOUR: Fournit une technologie de contournement du pare-feu qui permet
  placez notre CMS derrière un pare-feu ou un NAT pour connecter des clients externes à l'aide de l'application Cisco Meeting ou d'appareils SIP. Dans notre scénario, cela ne sera pas nécessaire.
• Administrateur Web: Interface d'administration et accès API, y compris pour les conférences spéciales Unified CM.

Modes de configuration

Contrairement à la plupart des autres produits Cisco, Cisco Meeting Server prend en charge trois méthodes de configuration pour s'adapter à tout type de déploiement.

• Ligne de commande (CLI): Interface de ligne de commande connue sous le nom de MMP pour les tâches de configuration initiale et de certificat.
• Administrateur Web: Principalement pour les configurations liées à CallBridge, en particulier lors de la configuration d'un seul serveur non clusterisé.
• API REST: Utilisé pour les tâches de configuration les plus complexes et les tâches liées aux bases de données en cluster.

En plus de ce qui précède, le protocole est utilisé SFTP pour transférer des fichiers (généralement des licences, des certificats ou des journaux) vers et depuis le serveur CMS.

Dans les guides de déploiement de Cisco, il est écrit en blanc et en anglais que le cluster doit être déployé au moins trois serveurs (nœuds) dans le contexte de bases de données. Parce que Ce n'est qu'avec un nombre impair de nœuds que le mécanisme de sélection d'un nouveau maître de base de données fonctionnera, et en général, le maître de base de données a une connexion avec la plupart des bases de données du serveur CMS.

Et comme le montre la pratique, deux serveurs (nœuds) ne suffisent vraiment pas. Le mécanisme de sélection fonctionne au redémarrage du maître, le serveur esclave ne devient maître qu'après le démarrage du serveur redémarré. Cependant, si dans un cluster de deux serveurs le serveur maître s'éteint soudainement, alors le serveur esclave ne deviendra pas le maître, et si l'esclave s'éteint, alors le serveur maître restant deviendra l'esclave.

Mais dans le cadre de XMPP, il faudrait bien assembler un cluster de trois serveurs, car si, par exemple, vous désactivez le service XMPP sur l'un des serveurs sur lequel XMMP est dans le statut Leader, alors sur le serveur restant, XMPP restera dans le statut Follower et les connexions CallBridge à XMPP seront interrompues, car CallBridge se connecte exclusivement à XMPP avec le statut Leader. Et c'est crucial, parce que... pas un seul appel ne passera.

Dans les mêmes guides de déploiement, un cluster avec un serveur XMPP est également présenté.

Et compte tenu de ce qui précède, il devient clair pourquoi : cela fonctionne parce qu'il est en mode basculement.

Dans notre cas, le serveur XMPP sera présent sur les trois nœuds.

On suppose que nos trois serveurs sont opérationnels.

Enregistrements DNS

Avant de commencer à configurer des serveurs, vous devez créer des enregistrements DNS А и SRV types:

Veuillez noter que dans nos enregistrements DNS, il y a deux domaines example.com et conf.exemple.com. Exemple.com est un domaine que tous les abonnés Cisco Unified Communication Manager peuvent utiliser pour leurs URI, qui sont très probablement présents dans votre infrastructure ou sont susceptibles d'être présents. Ou exemple.com est le même domaine que celui que les utilisateurs utilisent pour leurs adresses e-mail. Ou le client Jabber sur votre ordinateur portable peut avoir un URI [email protected]. Domaine conf.example.com est le domaine qui sera configuré pour les utilisateurs de Cisco Meeting Server. Le domaine du Cisco Meeting Server sera conf.example.com, donc pour le même utilisateur Jabber, l'URI user@ devra être utilisé pour se connecter à Cisco Meeting Serverconf.exemple.com.

Configuration de base

Tous les paramètres décrits ci-dessous sont affichés sur un serveur, mais ils doivent être effectués sur chaque serveur du cluster.

QoS

Puisque le CMS génère en temps réel trafic sensible aux délais et aux pertes de paquets, dans la plupart des cas il est recommandé de configurer la qualité de service (QoS). Pour y parvenir, le CMS prend en charge le marquage des paquets avec les codes de services différenciés (DSCP) qu'il génère. Bien que la priorisation du trafic basée sur DSCP dépend de la manière dont le trafic est traité par les composants réseau de votre infrastructure, dans notre cas, nous configurerons notre CMS avec une priorisation DSCP typique basée sur les meilleures pratiques de QoS.

Sur chaque serveur nous entrerons ces commandes

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Ainsi, tout le trafic vidéo était marqué AF41 (DSCP 0x22), tout le trafic vocal était marqué EF (DSCP 0x2E), d'autres types de trafic à faible latence tels que SIP et XMPP utilisaient AF31 (DSCP 0x1A).

vérifier:

NTP

Le protocole NTP (Network Time Protocol) est important non seulement pour fournir des horodatages précis des appels et des conférences, mais également pour vérifier les certificats.

Ajoutez des serveurs NTP à votre infrastructure avec une commande comme

ntp server add <server>

Dans notre cas, il existe deux de ces serveurs, il y aura donc deux équipes.
vérifier:

Et définissez le fuseau horaire de notre serveur

DNS

Nous ajoutons des serveurs DNS au CMS avec une commande comme :

dns add forwardzone <domain-name> <server ip>

Dans notre cas, il existe deux de ces serveurs, il y aura donc deux équipes.
vérifier:

Configuration de l'interface réseau

Nous configurons l'interface avec une commande comme :

ipv4 <interface> add <address>/<prefix length> <gateway>

vérifier:

Nom du serveur (nom d'hôte)

Nous définissons le nom du serveur avec une commande comme :

hostname <name>

Et on redémarre.


Ceci termine la configuration de base.

Certificats

ТеорияCisco Meeting Server nécessite une communication cryptée entre différents composants et, par conséquent, des certificats X.509 sont requis pour tous les déploiements CMS. Ils permettent de garantir que les services/serveurs sont approuvés par d'autres serveurs/services.

Chaque service nécessite un certificat, mais la création de certificats distincts pour chaque service peut entraîner une confusion et une complexité inutile. Heureusement, nous pouvons générer la paire de clés publique-privée d'un certificat, puis les réutiliser sur plusieurs services. Dans notre cas, le même certificat sera utilisé pour Call Bridge, XMPP Server, Web Bridge et Web Admin. Ainsi, vous devez créer une paire de clés de certificat publiques et privées pour chaque serveur du cluster.

Le clustering de bases de données comporte toutefois des exigences particulières en matière de certificats et nécessite donc ses propres certificats, différents de ceux des autres services. CMS utilise un certificat de serveur, similaire aux certificats utilisés par d'autres serveurs, mais il existe également un certificat client utilisé pour les connexions à la base de données. Les certificats de base de données sont utilisés à la fois pour l'authentification et le chiffrement. Au lieu de fournir un nom d'utilisateur et un mot de passe permettant au client de se connecter à la base de données, il présente un certificat client approuvé par le serveur. Chaque serveur du cluster de bases de données utilisera la même paire de clés publique et privée. Cela permet à tous les serveurs du cluster de chiffrer les données de telle manière qu'elles ne puissent être déchiffrées que par d'autres serveurs partageant également la même paire de clés.

Pour que la redondance fonctionne, les clusters de bases de données doivent être constitués d'un minimum de 3 serveurs, mais pas de plus de 5, avec un temps d'aller-retour maximum de 200 ms entre tous les membres du cluster. Cette limite est plus restrictive que pour le clustering Call Bridge, elle constitue donc souvent le facteur limitant dans les déploiements géographiquement distribués.

Le rôle de base de données pour un CMS présente un certain nombre d'exigences uniques. Contrairement à d'autres rôles, il nécessite un certificat client et serveur, le certificat client comportant un champ CN spécifique qui est présenté au serveur.

Le CMS utilise une base de données Postgres avec un maître et plusieurs répliques complètement identiques. Il n’existe qu’une seule base de données principale à la fois (le « serveur de base de données »). Les membres restants du cluster sont des réplicas ou des « clients de base de données ».

Un cluster de bases de données nécessite un certificat de serveur dédié et un certificat client. Ils doivent être signés par des certificats, généralement une autorité de certification privée interne. Étant donné que n'importe quel membre du cluster de bases de données peut devenir le maître, les paires de certificats serveur de base de données et client (contenant les clés publique et privée) doivent être copiées sur tous les serveurs afin qu'ils puissent prendre l'identité du client ou du serveur de base de données. De plus, le certificat racine de l'autorité de certification doit être chargé pour garantir que les certificats client et serveur peuvent être vérifiés.

Nous créons donc une demande de certificat qui sera utilisée par tous les services du serveur à l'exception de la base de données (il y aura une demande distincte pour cela) avec une commande telle que :

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

En CN, nous écrivons le nom général de nos serveurs. Par exemple, si les noms d'hôtes de nos serveurs server01, server02, server03, alors le CN sera serveur.exemple.com

On fait de même sur les deux serveurs restants à la différence que les commandes contiendront les « noms d'hôtes » correspondants

Nous générons deux requêtes de certificats qui seront utilisées par le service de base de données avec des commandes telles que :

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

où serveur de cluster de base de données и client dbcluster les noms de nos demandes et futurs certificats, nom d'hôte1(2)(3) noms des serveurs correspondants.

Nous effectuons cette procédure uniquement sur un serveur (!), et nous téléchargerons les certificats et les fichiers .key correspondants sur d'autres serveurs.

Activer le mode certificat client dans AD CS

Vous devez également fusionner les certificats de chaque serveur en un seul fichier.Sur *NIX :

cat server01.cer server02.cer server03.cer > server.cer

Sous Windows/DOS :

copy server01.cer + server02.cer + server03.cer  server.cer

Et téléchargez sur chaque serveur :
1. Certificat de serveur « Individuel ».
2. Certificat racine (ainsi que les certificats intermédiaires, le cas échéant).
3. Certificats pour la base de données (« serveur » et « client ») et fichiers avec l'extension .key, qui ont été générés lors de la création d'une demande de certificats de base de données « serveur » et « client ». Ces fichiers doivent être les mêmes sur tous les serveurs.
4. Dossier des trois certificats « individuels ».

En conséquence, vous devriez obtenir quelque chose comme cette image de fichier sur chaque serveur.

Cluster de base de données

Maintenant que tous les certificats sont téléchargés sur les serveurs CMS, vous pouvez configurer et activer le clustering de bases de données entre les trois nœuds. La première étape consiste à sélectionner un serveur comme nœud maître du cluster de bases de données et à le configurer entièrement.

Base de données principale

La première étape de la configuration de la réplication de base de données consiste à spécifier les certificats qui seront utilisés pour la base de données. Cela se fait à l'aide d'une commande telle que :

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Indiquons maintenant au CMS quelle interface utiliser pour le clustering de bases de données avec la commande :

database cluster localnode a

Ensuite, nous initialisons la base de données du cluster sur le serveur principal avec la commande :

database cluster initialize

Nœuds de base de données client

Nous faisons la même procédure, seulement à la place de la commande initialisation du cluster de base de données entrez une commande comme :

database cluster join <ip address existing master>

où adresse IP adresse IP principale existante du serveur CMS sur lequel le cluster a été initialisé, simplement Maître.

Nous vérifions le fonctionnement de notre cluster de bases de données sur tous les serveurs avec la commande :

database cluster status

Nous faisons de même sur le troisième serveur restant.

En conséquence, il s'avère que notre premier serveur est le maître, les autres sont des esclaves.

Service d'administration Web

Activez le service d'administrateur Web :

webadmin listen a 445

Le port 445 a été choisi car le port 443 est utilisé pour l'accès des utilisateurs au client Web.

Nous configurons le service Web Admin avec des fichiers de certificat avec une commande comme :

webadmin certs <keyfile> <certificatefile> <ca bundle>

Et activez Web Admin avec la commande :

webadmin enable

Si tout va bien, nous recevrons des lignes SUCCÈS indiquant que Web Admin est correctement configuré pour le réseau et le certificat. Nous vérifions la fonctionnalité du service à l'aide d'un navigateur Web et saisissons l'adresse de l'administrateur Web, par exemple : cms.exemple.com: 445

Cluster de pont d'appel

Call Bridge est le seul service présent dans chaque déploiement CMS. Call Bridge est le principal mécanisme de conférence. Il fournit également une interface SIP afin que les appels puissent être acheminés vers ou depuis, par exemple, un Cisco Unified CM.

Les commandes décrites ci-dessous doivent être exécutées sur chaque serveur avec les certificats appropriés.
Donc:

Nous associons les certificats au service Call Bridge avec une commande telle que :

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Nous lions les services CallBridge à l'interface dont nous avons besoin avec la commande :

callbridge listen a

Et redémarrez le service avec la commande :

callbridge restart

Maintenant que nos Call Bridges sont configurés, nous pouvons configurer le clustering Call Bridge. Le clustering Call Bridge est différent du clustering de base de données ou XMPP. Call Bridge Cluster peut prendre en charge de 2 à 8 nœuds sans aucune restriction. Il fournit non seulement une redondance, mais également un équilibrage de charge afin que les conférences puissent être activement distribuées sur les serveurs Call Bridge à l'aide d'une distribution intelligente des appels. Le CMS dispose de fonctionnalités supplémentaires, de groupes Call Bridge et de fonctionnalités associées qui peuvent être utilisées pour une gestion ultérieure.

Le clustering du pont d'appels est configuré principalement via l'interface d'administration Web.
La procédure décrite ci-dessous doit être effectuée sur chaque serveur du cluster.
ainsi,

1. Parcourez le Web jusqu'à Configuration > Cluster.
2. En Identité du pont d'appel Comme nom unique, saisissez callbridge[01,02,03] correspondant au nom du serveur. Ces noms sont arbitraires, mais doivent être uniques pour ce cluster. Ils sont de nature descriptive car ils indiquent qu'il s'agit d'identifiants de serveur [01,02,03].
3.B Ponts d'appels groupés saisir les URL des administrateurs web de nos serveurs dans le cluster, cms[01,02,03].example.com:445, dans le champ Adresse. Assurez-vous de spécifier le port. Vous pouvez laisser le domaine SIP Peer Link vide.
4. Ajoutez un certificat au trust CallBridge de chaque serveur, dont le fichier contient tous les certificats de nos serveurs, que nous avons fusionnés dans ce fichier au tout début, avec une commande du type :

callbridge trust cluster <trusted cluster certificate bundle>

Et redémarrez le service avec la commande :

callbridge restart

En conséquence, sur chaque serveur, vous devriez obtenir cette image :

Cluster XMPP

Le service XMPP du CMS est utilisé pour gérer toutes les inscriptions et authentifications pour Cisco Meeting Apps (CMA), y compris le client Web CMA WebRTC. Le Call Bridge lui-même agit également comme client XMPP à des fins d'authentification et doit donc être configuré comme les autres clients. La tolérance aux pannes XMPP est une fonctionnalité prise en charge dans les environnements de production depuis la version 2.1.

Les commandes décrites ci-dessous doivent être exécutées sur chaque serveur avec les certificats appropriés.
Donc:

Nous associons les certificats au service XMPP avec une commande comme :

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Définissez ensuite l'interface d'écoute avec la commande :

xmpp listen a

Le service XMPP nécessite un domaine unique. Il s'agit de la connexion pour les utilisateurs. En d'autres termes, lorsqu'un utilisateur tente de se connecter à l'aide de l'application CMA (ou via le client WebRTC), il saisit userID@logindomain. Dans notre cas, ce sera userid@conf.exemple.com. Pourquoi n'est-ce pas simplement example.com ? Dans notre déploiement particulier, nous avons sélectionné notre domaine Unified CM que les utilisateurs de Jabber utiliseront dans Unified CM comme example.com. Nous avions donc besoin d'un domaine différent pour que les utilisateurs du CMS puissent acheminer les appels vers et depuis le CMS via les domaines SIP.

Configurez un domaine XMPP à l'aide d'une commande telle que :

xmpp domain <domain>

Et activez le service XMPP avec la commande :

xmpp enable

Dans le service XMPP, vous devez créer des informations d'identification pour chaque Call Bridge qui seront utilisées lors de l'inscription au service XMPP. Ces noms sont arbitraires (et ne sont pas liés aux noms uniques que vous avez configurés pour le clustering de pont d'appels). Vous devez ajouter trois ponts d'appel sur un serveur XMPP, puis saisir ces informations d'identification sur d'autres serveurs XMPP du cluster, car cette configuration ne rentre pas dans la base de données du cluster. Plus tard, nous configurerons chaque Call Bridge pour utiliser ce nom et ce secret pour s'inscrire auprès du service XMPP.

Nous devons maintenant configurer le service XMPP sur le premier serveur avec trois Call Bridges callbridge01, callbridge02 et callbridge03. Chaque compte se verra attribuer des mots de passe aléatoires. Ils seront ensuite saisis sur d'autres serveurs Call Bridge pour se connecter à ce serveur XMPP. Entrez les commandes suivantes :

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

En conséquence, nous vérifions ce qui s'est passé avec la commande :

xmpp callbridge list

Exactement la même image devrait apparaître sur les serveurs restants après les étapes décrites ci-dessous.

Ensuite, nous ajoutons exactement les mêmes paramètres sur les deux serveurs restants, uniquement avec les commandes

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Nous ajoutons Secret très soigneusement afin que, par exemple, il n'y ait pas d'espace supplémentaire.


En conséquence, chaque serveur devrait avoir la même image :

Ensuite, sur tous les serveurs du cluster, nous spécifions en confiance le fichier contenant les trois certificats, créé précédemment avec une commande comme celle-ci :

xmpp cluster trust <trust bundle>

Nous activons le mode cluster xmpp sur tous les serveurs du cluster avec la commande :

xmpp cluster enable

Sur le premier serveur du cluster, on lance la création d'un cluster xmpp avec la commande :

xmpp cluster initialize

Sur d'autres serveurs, ajoutez un cluster à xmpp avec une commande telle que :

xmpp cluster join <ip address head xmpp server>

On vérifie sur chaque serveur la réussite de la création d'un cluster XMPP sur chaque serveur avec les commandes :

xmpp status
xmpp cluster status

Premier serveur :

Deuxième serveur :

Troisième serveur :

Connexion du pont d'appel à XMPP

Maintenant que le cluster XMPP est en cours d'exécution, vous devez configurer les services Call Bridge pour vous connecter au cluster XMPP. Cette configuration se fait via l'administrateur Web.

Sur chaque serveur, allez dans Configuration > Général et dans le champ Nom unique du pont d'appel écrire des noms uniques correspondant au serveur Call Bridge pont d'appel[01,02,03]. оле Domaine conf.exemple.ru et les mots de passe correspondants, vous pouvez les espionner
sur n'importe quel serveur du cluster avec la commande :

xmpp callbridge list

Laissez le champ « Serveur » vide Pont d'appel effectuera une recherche DNS SRV pour _xmpp-component._tcp.conf.example.compour trouver un serveur XMPP disponible. Les adresses IP pour connecter les callbridges à XMPP peuvent différer sur chaque serveur, cela dépend des valeurs renvoyées à la demande d'enregistrement _xmpp-component._tcp.conf.example.com callbridge, qui à son tour dépend des paramètres de priorité pour un enregistrement DNS donné.

Ensuite, accédez à Statut > Général pour vérifier si le service Call Bride est connecté avec succès au service XMPP.

Pont Web

Sur chaque serveur du cluster, activez le service Web Bridge avec la commande :

webbridge listen a:443

Nous configurons le service Web Bridge avec des fichiers de certificat avec une commande telle que :

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge prend en charge HTTPS. Il redirigera HTTP vers HTTPS s'il est configuré pour utiliser "http-redirect".
Pour activer la redirection HTTP, utilisez la commande suivante :

webbridge http-redirect enable

Pour faire savoir à Call Bridge que Web Bridge peut faire confiance aux connexions de Call Bridge, utilisez la commande :

webbridge trust <certfile>

où il s'agit d'un fichier contenant les trois certificats de chaque serveur du cluster.

Cette image doit figurer sur chaque serveur du cluster.


Nous devons maintenant créer un utilisateur avec le rôle « appadmin », nous en avons besoin pour pouvoir configurer notre cluster (!), et non chaque serveur du cluster séparément, de cette façon les paramètres seront appliqués de manière égale à chaque serveur malgré le fait qu'ils seront faits une fois.


Pour une configuration ultérieure, nous utiliserons Facteur.

Pour l'autorisation, sélectionnez Basique dans la section Autorisation

Pour envoyer correctement les commandes au serveur CMS, vous devez définir l'encodage requis

On précise Webbridge avec la commande POSTEZ avec paramètre url et sens cms.exemple.com



Dans le webbridge lui-même, nous indiquons les paramètres requis : accès invité, accès protégé, etc.

Groupes de passerelle d'appel

Par défaut, le CMS n'utilise pas toujours de la manière la plus efficace possible les ressources de conférence dont il dispose.

Par exemple, pour une réunion avec trois participants, chaque participant peut se retrouver sur trois ponts d'appel différents. Pour que ces trois participants communiquent entre eux, Call Bridges établira automatiquement des connexions entre tous les serveurs et clients du même espace, de sorte que tout semble comme si tous les clients étaient sur le même serveur. Malheureusement, l'inconvénient est qu'une seule conférence de 3 personnes consommera désormais 9 ports multimédia. Il s’agit évidemment d’une utilisation inefficace des ressources. De plus, lorsqu'un Call Bridge est réellement surchargé, le mécanisme par défaut consiste à continuer à accepter des appels et à fournir un service de qualité réduite à tous les abonnés de ce Call Bridge.

Ces problèmes sont résolus à l’aide de la fonctionnalité Call Bridge Group. Cette fonctionnalité a été introduite dans la version 2.1 du logiciel Cisco Meeting Server et a été étendue pour prendre en charge l'équilibrage de charge pour les appels entrants et sortants de l'application Cisco Meeting App (CMA), y compris les participants WebRTC.

Pour résoudre le problème de reconnexion, trois limites de charge configurables ont été introduites pour chaque pont d'appel :

Limite de charge — c'est la charge numérique maximale pour un Call Bridge particulier. Chaque plate-forme a une limite de charge recommandée, telle que 96000 1000 pour le CMS1.25 et XNUMX GHz par vCPU pour la machine virtuelle. Différents appels consomment une certaine quantité de ressources en fonction de la résolution et de la fréquence d'images du participant.
NewConferenceLoadLimitBasisPoints (loadLimit 50% par défaut) - définit la limite de charge du serveur, après laquelle les nouvelles conférences sont rejetées.
ExistingConferenceLoadLimitBasisPoints (par défaut 80 % de loadLimit) - la valeur de charge du serveur après laquelle les participants rejoignant une conférence existante seront rejetés.

Bien que cette fonctionnalité ait été conçue pour la distribution des appels et l'équilibrage de charge, d'autres groupes tels que les serveurs TURN, les serveurs Web Bridge et les enregistreurs peuvent également être attribués aux groupes Call Bridge afin qu'ils puissent également être correctement regroupés pour une utilisation optimale. Si l'un de ces objets n'est pas affecté à un groupe d'appels, il est supposé être disponible pour tous les serveurs sans priorité particulière.

Ces paramètres sont configurés ici : cms.exemple.com:445/api/v1/system/configuration/cluster

Ensuite, nous indiquons à chaque callbridge à quel groupe de callbridge il appartient :

Premier pont d'appel

Deuxième pont d'appel

Troisième pont d'appel


Ainsi, nous avons configuré le groupe Call Brdige pour utiliser plus efficacement les ressources du cluster Cisco Meeting Server.

Importer des utilisateurs depuis Active Directory

Le service Web Admin dispose d'une section de configuration LDAP, mais il ne fournit pas d'options de configuration complexes et les informations ne sont pas stockées dans la base de données du cluster, la configuration devra donc être effectuée, soit manuellement sur chaque serveur via l'interface Web, soit via l'API, et pour que nous « ne nous levions pas trois fois », nous définirons toujours les données via l'API.

Utiliser l'URL pour accéder cms01.exemple.com:445/api/v1/ldapServers crée un objet serveur LDAP, en spécifiant des paramètres tels que :

• Adresse IP du serveur
• numéro de port
• имя пользователя
• mot de passe
• sécurisé

Sécurisé - sélectionnez vrai ou faux en fonction du port, 389 - non sécurisé, 636 - protégé.


Mappage des paramètres source LDAP aux attributs dans Cisco Meeting Server.
Le mappage LDAP mappe les attributs de l'annuaire LDAP aux attributs du CMS. Les attributs réels :

• jidMapping
• mappage de noms
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Description des attributsJ ID représente l'ID de connexion de l'utilisateur dans le CMS. Puisqu'il s'agit d'un serveur LDAP Microsoft Active Directory, le JID du CMS correspond au sAMAccountName dans LDAP, qui est essentiellement l'ID de connexion Active Directory de l'utilisateur. Notez également que vous prenez sAMAccountName et ajoutez le domaine conf.pod6.cms.lab à la fin car c'est le login que vos utilisateurs utiliseront pour se connecter au CMS.

mappage de noms fait correspondre le contenu du champ displayName d'Active Directory au champ de nom CMS de l'utilisateur.

coSpaceNameMapping crée un nom d'espace CMS basé sur le champ displayName. Cet attribut, ainsi que l'attribut coSpaceUriMapping, est nécessaire pour créer un espace pour chaque utilisateur.

coSpaceUriMapping définit la partie utilisateur de l'URI associée à l'espace personnel de l'utilisateur. Certains domaines peuvent être configurés pour être connectés à l'espace. Si la partie utilisateur correspond à ce champ pour l'un de ces domaines, l'appel sera dirigé vers l'espace de cet utilisateur.

coSpaceSecondaryUriMapping définit un deuxième URI pour atteindre l'espace. Cela peut être utilisé pour ajouter un alias numérique pour acheminer les appels vers l'espace de l'utilisateur importé comme alternative à l'URI alphanumérique défini dans le paramètre coSpaceUriMapping.

Le serveur LDAP et le mappage LDAP sont configurés. Vous devez maintenant les relier entre eux en créant une source LDAP.

Utiliser l'URL pour accéder cms01.exemple.com:445/api/v1/ldapSource crée un objet source LDAP, en spécifiant des paramètres tels que :

• serveur
• cartographie
• baseDn
• une fonction filtre

Maintenant que la configuration LDAP est terminée, vous pouvez effectuer l'opération de synchronisation manuelle.

On fait cela soit dans l'interface Web de chaque serveur en cliquant sur Synchroniser maintenant section active Directory


ou via l'API avec la commande POSTEZ utiliser l'URL pour accéder cms01.exemple.com:445/api/v1/ldapSyncs

Conférences ponctuelles

Qu'est-ce que c'est?Dans le concept traditionnel, une conférence se produit lorsque deux participants se parlent et que l'un des participants (à l'aide d'un appareil enregistré auprès d'Unified CM) appuie sur le bouton « Conférence », appelle l'autre personne et, après avoir parlé à ce tiers. , appuie à nouveau sur le bouton « Conférence » pour rejoindre tous les participants à la conférence tripartite.

Ce qui distingue une conférence Ad-Hoc d'une conférence planifiée dans un CMS, c'est qu'une conférence Ad-Hoc n'est pas simplement un appel SIP vers le CMS. Lorsque l'initiateur de la conférence clique une deuxième fois sur le bouton Conférence pour inviter tout le monde à la même réunion, Unified CM doit effectuer un appel API au CMS pour créer une conférence à la volée vers laquelle tous les appels sont ensuite transférés. Tout cela se passe inaperçu des participants.

Cela signifie qu'Unified CM doit configurer les informations d'identification API et l'adresse/port WebAdmin du service ainsi que le tronc SIP directement sur le serveur CMS pour poursuivre l'appel.

Si nécessaire, CUCM peut créer dynamiquement un espace dans le CMS afin que chaque appel puisse atteindre le CMS et correspondre à la règle d'appel entrant destinée aux espaces.

Intégration avec CUCM configuré de la même manière que décrit dans l'article plus tôt sauf que sur Cisco UCM, vous devez créer trois lignes réseau pour le CMS, trois ponts de conférence, dans le profil de sécurité SIP, spécifier trois noms de sujet, groupes de routage, listes de routage, groupes de ressources média et listes de groupes de ressources média, et ajouter quelques règles de routage au serveur de réunion Cisco.

Profil de sécurité SIP:


Les troncs:


Chaque coffre se ressemble :




Pont de conférence


Chaque pont de conférence se ressemble :


Groupe d'itinéraires


Liste des itinéraires


Groupe de ressources médiatiques


Liste des groupes de ressources multimédias

Règles d'appel

Contrairement aux systèmes de gestion des appels plus avancés tels que Unified CM ou Expressway, CMS recherche uniquement le domaine dans le champ SIP Request-URI pour les nouveaux appels. Donc si SIP INVITE est pour siroter : [email protected]Le CMS ne se soucie que de domain.com. CMS suit ces règles pour déterminer où acheminer un appel :

1. Le CMS essaie d'abord de faire correspondre le domaine SIP avec les domaines configurés dans les règles d'appel entrant. Ces appels peuvent ensuite être acheminés vers des espaces (« ciblés ») ou des utilisateurs spécifiques, des SVI internes ou des destinations Microsoft Lync/Skype for Business (S4B) directement intégrées.
2. S'il n'y a aucune correspondance dans les règles d'appel entrant, CMS tentera de faire correspondre le domaine configuré dans le tableau de transfert d'appel. Si une correspondance est établie, la règle peut explicitement rejeter l'appel ou transférer l'appel. À ce stade, le CMS peut réécrire le domaine, ce qui est parfois utile pour appeler des domaines Lync. Vous pouvez également choisir de passer le lancer, ce qui signifie qu'aucun des champs ne sera modifié davantage, ou d'utiliser un plan de numérotation CMS interne. S'il n'y a aucune correspondance dans les règles de transfert d'appel, la valeur par défaut est de rejeter l'appel. Gardez à l’esprit que dans le CMS, même si l’appel est « transféré », le média est toujours lié au CMS, ce qui signifie qu’il se trouvera dans le chemin de signalisation et de trafic multimédia.
Seuls les appels renvoyés sont alors soumis aux règles des appels sortants. Ces paramètres déterminent les destinations vers lesquelles les appels sont envoyés, le type de ligne réseau (qu'il s'agisse d'un nouvel appel Lync ou d'un appel SIP standard) et toutes les conversions pouvant être effectuées si le transfert n'est pas sélectionné dans la règle de transfert d'appel.

Voici le journal réel de ce qui se passe lors d'une conférence Ad-Hoc

La capture d'écran le montre mal (je ne sais pas comment l'améliorer), je vais donc écrire le journal comme ceci :

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

La conférence Ad-Hoc elle-même :


Règles d'appel entrant
La configuration des paramètres des appels entrants est nécessaire pour pouvoir recevoir un appel dans le CMS. Comme vous l'avez vu dans la configuration LDAP, tous les utilisateurs ont été importés avec le domaine conf.pod6.cms.lab. Donc, au minimum, vous souhaitez que les appels vers ce domaine ciblent des espaces. Vous devrez également mettre en place des règles pour tout ce qui est destiné au nom de domaine complet (et peut-être même à l'adresse IP) de chacun des serveurs CMS. Notre contrôle d'appel externe, Unified CM, configurera individuellement les trunks SIP dédiés à chacun des serveurs CMS. Selon que la destination de ces lignes réseau SIP est une adresse IP ou le FQDN du serveur déterminera si le CMS doit être configuré pour accepter les appels dirigés vers son adresse IP ou son FQDN.

Le domaine doté de la règle entrante la plus prioritaire est utilisé comme domaine pour tous les espaces utilisateur. Lorsque les utilisateurs se synchronisent via LDAP, le CMS crée automatiquement des espaces, mais uniquement la partie utilisateur de l'URI (coSpaceUriMapping), par exemple user.space. Partie domaine L'URI complet est généré sur la base de cette règle. En fait, si vous vous connectiez à Web Bridge à ce stade, vous verriez que l'URI de l'espace n'a pas de domaine. En définissant cette règle comme priorité la plus élevée, vous définissez le domaine des espaces générés comme étant conf.exemple.com.


Règles d'appel sortant

Pour permettre aux utilisateurs d'effectuer des appels sortants vers le cluster Unified CM, vous devez configurer des règles sortantes. Le domaine des points de terminaison enregistrés auprès d'Unified CM, tels que Jabber, est example.com. Les appels vers ce domaine doivent être acheminés sous forme d’appels SIP standard vers les nœuds de traitement des appels Unified CM. Le serveur principal est cucm-01.example.com et le serveur supplémentaire est cucm-02.example.com.

La première règle décrit le routage le plus simple des appels entre les serveurs du cluster.

Champ Local du domaine est responsable de ce qui sera affiché dans le SIP-URI de l’appelant pour la personne appelée après le symbole « @ ». Si nous le laissons vide, après le symbole « @ », il y aura l'adresse IP du CUCM par laquelle passe cet appel. Si nous spécifions un domaine, alors après le symbole « @ », il y aura effectivement un domaine. Ceci est nécessaire pour pouvoir rappeler, sinon il ne sera pas possible de rappeler via SIP-URI nom@adresse-ip.

Appeler lorsque spécifié Local du domaine


Appeler quand PAS indiqué Local du domaine


Assurez-vous de spécifier explicitement Chiffré ou Non chiffré pour les appels sortants, car rien ne fonctionne avec le paramètre Auto.

enregistrement

Les vidéoconférences sont enregistrées par le serveur Record. Recorder est exactement le même que Cisco Meeting Server. Recorder ne nécessite l’installation d’aucune licence. Des licences d'enregistrement sont requises pour les serveurs exécutant les services CallBridge, c'est-à-dire une licence d'enregistrement est requise et doit être appliquée au composant CallBridge, et non au serveur exécutant Recorder. Recorder se comporte comme un client XMPP (Extensible Messaging and Presence Protocol), le serveur XMPP doit donc être activé sur le serveur hébergeant CallBridge.

Parce que Nous avons un cluster et la licence doit être « étendue » sur les trois serveurs du cluster. Ensuite simplement dans votre compte personnel dans les licences nous associons (ajoutons) les adresses MAC des a-interfaces de tous les serveurs CMS inclus dans le cluster.

Et c'est l'image qui devrait être sur chaque serveur du cluster

En général, il existe plusieurs scénarios pour placer Recorder, mais nous nous en tiendrons à celui-ci :


Avant de configurer Recorder, vous devez préparer un endroit où les vidéoconférences seront réellement enregistrées. En fait ici lien, comment configurer tous les enregistrements. Je me concentre sur les points et détails importants :

1. Il est préférable de retirer le certificat du premier serveur du cluster.
2. L'erreur « Enregistreur indisponible » peut se produire car un mauvais certificat est spécifié dans Recorder Trust.
3. L'écriture peut ne pas fonctionner si le répertoire NFS spécifié pour l'enregistrement n'est pas le répertoire racine.

Il est parfois nécessaire d'enregistrer automatiquement une conférence d'un utilisateur ou d'un espace spécifique.

Pour cela, deux CallProfiles sont créés :
Avec enregistrement désactivé


Et avec fonction d'enregistrement automatique


Ensuite, nous « attachons » un CallProfile avec une fonction d'enregistrement automatique à l'espace requis.


Dans CMS, il est établi que si un CallProfile est explicitement lié à un espace ou un espace, alors ce CallProfile ne fonctionne qu'en relation avec ces espaces spécifiques. Et si le CallProfile n'est lié à aucun espace, alors par défaut il est appliqué aux espaces auxquels aucun CallProfile n'est explicitement lié.

La prochaine fois, j'essaierai de décrire comment on accède au CMS en dehors du réseau interne de l'organisation.

Sources:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

Source: habr.com