Cisco Meeting Server 2.5.2. Cluster im skalierbaren und robusten Modus mit Videokonferenzaufzeichnung

In dieser Ausgabe werde ich einige Feinheiten der Einrichtung eines CMS-Servers im Failover-Cluster-Modus zeigen und erklären.


ТеорияIm Allgemeinen gibt es drei Arten der CMS-Serverbereitstellung:

• Einzeln kombiniert(Einfach kombiniert), d.h. Dabei handelt es sich um einen Server, auf dem alle notwendigen Dienste laufen. In den meisten Fällen eignet sich diese Art der Bereitstellung nur für den internen Clientzugriff und in kleineren Umgebungen, in denen die Skalierbarkeits- und Redundanzbeschränkungen eines einzelnen Servers kein kritisches Problem darstellen, oder in Situationen, in denen das CMS nur bestimmte Funktionen ausführt, z. B. Ad-hoc Konferenzen zu Cisco UCM.

  Ungefähres Arbeitsschema:
  

• Einzelaufteilung(Single Split) erweitert den bisherigen Bereitstellungstyp um einen separaten Server für den externen Zugriff. Bei älteren Bereitstellungen bedeutete dies die Bereitstellung eines CMS-Servers in einem demilitarisierten Netzwerksegment (DMZ), auf den externe Clients zugreifen konnten, und eines CMS-Servers im Netzwerkkern, auf dem interne Clients auf das CMS zugreifen konnten. Dieses spezielle Bereitstellungsmodell wird nun durch den sogenannten Typ ersetzt Einzelne Kante, das aus Servern besteht Cisco Expressway, die entweder über viele der gleichen Firewall-Umgehungsfunktionen verfügen oder verfügen werden, sodass Clients keinen dedizierten Edge-CMS-Server hinzufügen müssen.

  Ungefähres Arbeitsschema:
  

• Skalierbar und belastbar(Skalierbar und fehlertolerant) Dieser Typ umfasst Redundanz für jede Komponente, sodass das System mit Ihren Anforderungen bis zur maximalen Kapazität wachsen kann und gleichzeitig Redundanz im Fehlerfall bietet. Es nutzt außerdem das Single-Edge-Konzept, um einen sicheren externen Zugriff zu ermöglichen. Dies ist der Typ, den wir uns in dieser Episode ansehen werden. Wenn wir verstehen, wie diese Art von Cluster bereitgestellt wird, werden wir nicht nur andere Arten von Bereitstellungen verstehen, sondern auch in der Lage sein, Cluster von CMS-Servern zu erstellen, um potenziellem Nachfragewachstum gerecht zu werden.

Bevor Sie mit der Bereitstellung fortfahren, müssen Sie einige grundlegende Dinge verstehen, nämlich

Hauptkomponenten der CMS-Software:

• Datenbase: Ermöglicht Ihnen, einige Konfigurationen zu kombinieren, z. B. Wählplan, Benutzerbereiche und Benutzer selbst. Unterstützt nur Clustering für Hochverfügbarkeit (einzelner Master).
• Rufen Sie Bridge an: ein Dienst für Audio- und Videokonferenzen, der die volle Kontrolle über die Verwaltung und Verarbeitung von Anrufen und Multimedia-Prozessen bietet. Unterstützt Clustering für hohe Verfügbarkeit und Skalierbarkeit.
• XMPP-Server: verantwortlich für die Registrierung und Authentifizierung von Kunden, die die Cisco Meeting Application und/oder WebRTC verwenden(Echtzeitkommunikation oder einfach im Browser), sowie Interkomponenten-Signalisierung. Kann nur für hohe Verfügbarkeit geclustert werden.
• Web-Bridge: Bietet Clientzugriff auf WebRTC.
• Lastenausgleicher: Bietet einen einzigen Verbindungspunkt für Cisco Meeting Apps im Single Split-Modus. Hört auf die externe Schnittstelle und den Port auf eingehende Verbindungen. Ebenso akzeptiert der Load Balancer eingehende TLS-Verbindungen vom XMPP-Server, über die er TCP-Verbindungen von externen Clients vermitteln kann.
  In unserem Szenario wird es nicht benötigt.
• TURN-Server: Bietet Firewall-Bypass-Technologie, die dies ermöglicht
  Platzieren Sie unser CMS hinter einer Firewall oder einem NAT, um externe Clients über die Cisco Meeting App oder SIP-Geräte zu verbinden. In unserem Szenario wird es nicht benötigt.
• Web-Admin: Verwaltungsschnittstelle und API-Zugriff, auch für spezielle Unified CM-Konferenzen.

Konfigurationsmodi

Im Gegensatz zu den meisten anderen Cisco-Produkten unterstützt Cisco Meeting Server drei Konfigurationsmethoden, um jede Art von Bereitstellung zu ermöglichen.

• Befehlszeile (CLI): Befehlszeilenschnittstelle namens MMP für Erstkonfigurations- und Zertifikatsaufgaben.
• Webadministrator: Hauptsächlich für CallBridge-bezogene Konfigurationen, insbesondere beim Einrichten eines einzelnen, nicht geclusterten Servers.
• REST API: Wird für die komplexesten Konfigurationsaufgaben und Cluster-Datenbank-bezogenen Aufgaben verwendet.

Darüber hinaus wird das Protokoll verwendet SFTP um Dateien – normalerweise Lizenzen, Zertifikate oder Protokolle – zum und vom CMS-Server zu übertragen.

In Bereitstellungshandbüchern von Cisco steht in Weiß und Englisch, dass der Cluster bereitgestellt werden muss mindestens drei Server (Knoten) im Kontext von Datenbanken. Weil Nur bei einer ungeraden Anzahl von Knoten funktioniert der Mechanismus zur Auswahl eines neuen Datenbankmasters, und im Allgemeinen hat der Datenbankmaster eine Verbindung mit den meisten CMS-Serverdatenbanken.

Und wie die Praxis zeigt, reichen zwei Server (Knoten) wirklich nicht aus. Der Auswahlmechanismus funktioniert, wenn der Master neu gestartet wird. Der Slave-Server wird erst zum Master, nachdem der neu gestartete Server hochgefahren wurde. Wenn jedoch in einem Cluster aus zwei Servern plötzlich der Master-Server ausfällt, wird der Slave-Server nicht zum Master, und wenn der Slave ausfällt, wird der verbleibende Master-Server zum Slave.

Aber im Kontext von XMPP wäre es wirklich notwendig, einen Cluster aus drei Servern zusammenzustellen, denn Wenn Sie beispielsweise den XMPP-Dienst auf einem der Server deaktivieren, auf denen sich XMMP im Leader-Status befindet, bleibt XMPP auf dem verbleibenden Server im Follower-Status und CallBridge-Verbindungen zu XMPP fallen ab, weil CallBridge verbindet sich ausschließlich mit XMPP mit Leader-Status. Und das ist entscheidend, denn... Es kommt kein einziger Anruf durch.

In denselben Bereitstellungshandbüchern wird auch ein Cluster mit einem XMPP-Server demonstriert.

Und unter Berücksichtigung des oben Gesagten wird klar, warum: Es funktioniert, weil es sich im Failover-Modus befindet.

In unserem Fall wird der XMPP-Server auf allen drei Knoten vorhanden sein.

Es wird davon ausgegangen, dass alle drei unserer Server aktiv sind.

DNS-Einträge

Bevor Sie mit der Einrichtung von Servern beginnen, müssen Sie DNS-Einträge erstellen А и SRV Typen:

Bitte beachten Sie, dass es in unseren DNS-Einträgen zwei Domains gibt: example.com und conf.example.com. Beispiel.com ist eine Domäne, die alle Cisco Unified Communication Manager-Abonnenten für ihre URIs verwenden können und die höchstwahrscheinlich in Ihrer Infrastruktur vorhanden ist oder wahrscheinlich vorhanden sein wird. Oder example.com stimmt mit derselben Domäne überein, die Benutzer für ihre E-Mail-Adressen verwenden. Oder der Jabber-Client auf Ihrem Laptop verfügt möglicherweise über einen URI [E-Mail geschützt] . Domain conf.example.com ist die Domäne, die für Cisco Meeting Server-Benutzer konfiguriert wird. Die Domäne des Cisco Meeting Servers wird sein conf.example.com, daher müsste für denselben Jabber-Benutzer der user@-URI verwendet werden, um sich beim Cisco Meeting Server anzumeldenconf.example.com.

Grundlegende Konfiguration

Alle im Folgenden beschriebenen Einstellungen werden auf einem Server angezeigt, müssen jedoch auf jedem Server im Cluster vorgenommen werden.

QoS

Da das CMS generiert Echtzeit Da der Datenverkehr empfindlich auf Verzögerungen und Paketverluste reagiert, wird in den meisten Fällen empfohlen, die Dienstgüte (Quality of Service, QoS) zu konfigurieren. Um dies zu erreichen, unterstützt das CMS das Markieren von Paketen mit den von ihm generierten Differentiated Services Codes (DSCPs). Obwohl die DSCP-basierte Datenverkehrspriorisierung davon abhängt, wie der Datenverkehr von den Netzwerkkomponenten Ihrer Infrastruktur verarbeitet wird, konfigurieren wir in unserem Fall unser CMS mit typischer DSCP-Priorisierung basierend auf QoS-Best Practices.

Auf jedem Server werden wir diese Befehle eingeben

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

Daher wurde der gesamte Videoverkehr mit AF41 (DSCP 0x22) gekennzeichnet, der gesamte Sprachverkehr mit EF (DSCP 0x2E), andere Arten von Verkehr mit geringer Latenz wie SIP und XMPP verwenden AF31 (DSCP 0x1A).

Wir prüfen:

NTP

Das Network Time Protocol (NTP) ist nicht nur für die Bereitstellung genauer Zeitstempel von Anrufen und Konferenzen wichtig, sondern auch für die Überprüfung von Zertifikaten.

Fügen Sie Ihrer Infrastruktur NTP-Server mit einem Befehl wie hinzu

ntp server add <server>

In unserem Fall gibt es zwei solcher Server, also wird es zwei Teams geben.
Wir prüfen:

Und stellen Sie die Zeitzone für unseren Server ein

DNS

Wir fügen dem CMS DNS-Server mit einem Befehl wie dem folgenden hinzu:

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

In unserem Fall gibt es zwei solcher Server, also wird es zwei Teams geben.
Wir prüfen:

Konfiguration der Netzwerkschnittstelle

Wir konfigurieren die Schnittstelle mit einem Befehl wie:

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

Wir prüfen:

Servername (Hostname)

Wir legen den Servernamen mit einem Befehl fest wie:

hostname <name>

Und wir starten neu.


Damit ist die Grundkonfiguration abgeschlossen.

Zertifikate

ТеорияDer Cisco Meeting Server erfordert eine verschlüsselte Kommunikation zwischen verschiedenen Komponenten. Daher sind für alle CMS-Bereitstellungen X.509-Zertifikate erforderlich. Sie tragen dazu bei, dass andere Server/Dienste dem Dienst/Server vertrauen.

Für jeden Dienst ist ein Zertifikat erforderlich. Das Erstellen separater Zertifikate für jeden Dienst kann jedoch zu Verwirrung und unnötiger Komplexität führen. Glücklicherweise können wir das öffentlich-private Schlüsselpaar eines Zertifikats generieren und es dann für mehrere Dienste wiederverwenden. In unserem Fall wird dasselbe Zertifikat für Call Bridge, XMPP Server, Web Bridge und Web Admin verwendet. Daher müssen Sie für jeden Server im Cluster ein Paar öffentlicher und privater Zertifikatsschlüssel erstellen.

Datenbank-Clustering hat jedoch einige besondere Zertifikatsanforderungen und erfordert daher eigene Zertifikate, die sich von denen der anderen Dienste unterscheiden. CMS verwendet ein Serverzertifikat, das den von anderen Servern verwendeten Zertifikaten ähnelt, es gibt jedoch auch ein Client-Zertifikat, das für Datenbankverbindungen verwendet wird. Datenbankzertifikate werden sowohl zur Authentifizierung als auch zur Verschlüsselung verwendet. Anstatt einen Benutzernamen und ein Kennwort anzugeben, damit der Client eine Verbindung zur Datenbank herstellen kann, wird ein Client-Zertifikat angezeigt, dem der Server vertraut. Jeder Server im Datenbankcluster verwendet dasselbe öffentliche und private Schlüsselpaar. Dadurch können alle Server im Cluster Daten so verschlüsseln, dass sie nur von anderen Servern entschlüsselt werden können, die ebenfalls dasselbe Schlüsselpaar verwenden.

Damit die Redundanz funktioniert, müssen Datenbankcluster aus mindestens 3, jedoch nicht mehr als 5 Servern bestehen, mit einer maximalen Umlaufzeit von 200 ms zwischen allen Clustermitgliedern. Dieser Grenzwert ist restriktiver als beim Call Bridge-Clustering und stellt daher häufig den begrenzenden Faktor bei geografisch verteilten Bereitstellungen dar.

Die Datenbankrolle für ein CMS stellt eine Reihe einzigartiger Anforderungen. Im Gegensatz zu anderen Rollen ist ein Client- und ein Serverzertifikat erforderlich, wobei das Clientzertifikat über ein bestimmtes CN-Feld verfügt, das dem Server angezeigt wird.

Das CMS nutzt eine Postgres-Datenbank mit einem Master und mehreren völlig identischen Replikaten. Es gibt jeweils nur eine Primärdatenbank (den „Datenbankserver“). Die übrigen Mitglieder des Clusters sind Replikate oder „Datenbank-Clients“.

Ein Datenbankcluster erfordert ein dediziertes Serverzertifikat und ein Clientzertifikat. Sie müssen durch Zertifikate signiert sein, in der Regel eine interne private Zertifizierungsstelle. Da jedes Mitglied des Datenbankclusters zum Master werden kann, müssen die Datenbankserver- und Client-Zertifikatpaare (mit den öffentlichen und privaten Schlüsseln) auf alle Server kopiert werden, damit diese die Identität des Clients oder Datenbankservers annehmen können. Darüber hinaus muss das CA-Stammzertifikat geladen werden, um sicherzustellen, dass die Client- und Serverzertifikate überprüft werden können.

Also erstellen wir eine Anfrage für ein Zertifikat, das von allen Serverdiensten außer der Datenbank verwendet wird (hierfür wird es eine separate Anfrage geben), mit einem Befehl wie:

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

In CN schreiben wir den allgemeinen Namen unserer Server. Zum Beispiel, wenn die Hostnamen unserer Server server01, server02, server03, dann wird CN sein server.beispiel.com

Auf den verbleibenden beiden Servern machen wir dasselbe, mit dem Unterschied, dass die Befehle die entsprechenden „Hostnamen“ enthalten.

Wir generieren zwei Anfragen für Zertifikate, die vom Datenbankdienst verwendet werden, mit Befehlen wie:

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

pki csr dbclusterclient CN:postgres

wo dbclusterserver и dbclusterclient Namen unserer Anfragen und zukünftiger Zertifikate, Hostname1(2)(3) Namen der entsprechenden Server.

Wir führen diesen Vorgang nur auf einem Server (!) durch und laden die Zertifikate und entsprechenden .key-Dateien auf andere Server hoch.

Aktivieren Sie den Clientzertifikatmodus in AD CS

Sie müssen außerdem die Zertifikate für jeden Server in einer Datei zusammenführen.Auf *NIX:

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

Unter Windows/DOS:

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

Und auf jeden Server hochladen:
1. „Individuelles“ Serverzertifikat.
2. Stammzertifikat (zusammen mit Zwischenzertifikaten, falls vorhanden).
3. Zertifikate für die Datenbank („Server“ und „Client“) und Dateien mit der Erweiterung .key, die beim Erstellen einer Anfrage für die Datenbankzertifikate „Server“ und „Client“ generiert wurden. Diese Dateien müssen auf allen Servern gleich sein.
4. Datei aller drei „Einzel“-Zertifikate.

Als Ergebnis sollten Sie auf jedem Server so etwas wie dieses Dateibild erhalten.

Datenbankcluster

Nachdem Sie nun alle Zertifikate auf die CMS-Server hochgeladen haben, können Sie das Datenbank-Clustering über die drei Knoten hinweg konfigurieren und aktivieren. Der erste Schritt besteht darin, einen Server als Masterknoten des Datenbankclusters auszuwählen und ihn vollständig zu konfigurieren.

Master-Datenbank

Der erste Schritt beim Einrichten der Datenbankreplikation besteht darin, die Zertifikate anzugeben, die für die Datenbank verwendet werden. Dies geschieht mit einem Befehl wie:

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

Nun teilen wir dem CMS mit dem folgenden Befehl mit, welche Schnittstelle für das Datenbank-Clustering verwendet werden soll:

database cluster localnode a

Anschließend initialisieren wir die Cluster-Datenbank auf dem Hauptserver mit dem Befehl:

database cluster initialize

Client-Datenbankknoten

Wir führen das gleiche Verfahren durch, nur anstelle des Befehls Datenbankcluster initialisieren Geben Sie einen Befehl ein wie:

database cluster join <ip address existing master>

Dabei ist die IP-Adresse die vorhandene Master-IP-Adresse des CMS-Servers, auf dem der Cluster initialisiert wurde, einfach Master.

Wie unser Datenbankcluster auf allen Servern funktioniert, überprüfen wir mit dem Befehl:

database cluster status

Dasselbe machen wir auch auf dem verbleibenden dritten Server.

Als Ergebnis stellt sich heraus, dass unser erster Server der Master ist, der Rest sind Slaves.

Webadministrationsdienst

Aktivieren Sie den Webadministratordienst:

webadmin listen a 445

Port 445 wurde ausgewählt, da Port 443 für den Benutzerzugriff auf den Webclient verwendet wird

Wir konfigurieren den Web Admin-Dienst mit Zertifikatsdateien mit einem Befehl wie:

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

Und aktivieren Sie Web Admin mit dem folgenden Befehl:

webadmin enable

Wenn alles in Ordnung ist, erhalten wir SUCCESS-Zeilen, die anzeigen, dass Web Admin für das Netzwerk und das Zertifikat korrekt konfiguriert ist. Wir überprüfen die Funktionalität des Dienstes mithilfe eines Webbrowsers und geben die Adresse des Webadministrators ein, zum Beispiel: cms.example.com: 445

Rufen Sie den Bridge-Cluster auf

Call Bridge ist der einzige Dienst, der in jeder CMS-Bereitstellung vorhanden ist. Call Bridge ist der wichtigste Konferenzmechanismus. Es bietet außerdem eine SIP-Schnittstelle, sodass Anrufe beispielsweise über einen Cisco Unified CM dorthin oder von dieser weitergeleitet werden können.

Die nachfolgend beschriebenen Befehle müssen auf jedem Server mit den entsprechenden Zertifikaten ausgeführt werden.
Also:

Wir verknüpfen Zertifikate mit dem Call Bridge-Dienst mit einem Befehl wie:

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

Wir binden CallBridge-Dienste mit dem Befehl an die Schnittstelle, die wir benötigen:

callbridge listen a

Und starten Sie den Dienst mit dem Befehl neu:

callbridge restart

Nachdem wir nun unsere Call Bridges konfiguriert haben, können wir das Call Bridge-Clustering konfigurieren. Call Bridge-Clustering unterscheidet sich vom Datenbank- oder XMPP-Clustering. Call Bridge Cluster kann ohne Einschränkungen 2 bis 8 Knoten unterstützen. Es bietet nicht nur Redundanz, sondern auch Lastausgleich, sodass Konferenzen mithilfe einer intelligenten Anrufverteilung aktiv auf Call Bridge-Server verteilt werden können. Das CMS verfügt über zusätzliche Funktionen, Call Bridge-Gruppen und verwandte Funktionen, die für die weitere Verwaltung verwendet werden können.

Das Anrufbrücken-Clustering wird hauptsächlich über die Webadministrationsoberfläche konfiguriert
Der nachfolgend beschriebene Vorgang muss auf jedem Server im Cluster durchgeführt werden.
somit

1. Gehen Sie im Internet zu Konfiguration > Cluster.
2. In Call Bridge-Identität Geben Sie als eindeutigen Namen callbridge[01,02,03] entsprechend dem Servernamen ein. Diese Namen sind willkürlich, müssen aber für diesen Cluster eindeutig sein. Sie sind beschreibender Natur, da sie darauf hinweisen, dass es sich um Serverkennungen handelt [01,02,03].
3.B Geclusterte Anrufbrücken Geben Sie die Webadministrator-URLs unserer Server im Cluster ein. cms[01,02,03].example.com:445 im Feld Adresse. Geben Sie unbedingt den Port an. Sie können die Peer-Link-SIP-Domäne leer lassen.
4. Fügen Sie dem CallBridge-Trust jedes Servers ein Zertifikat hinzu, dessen Datei alle Zertifikate unserer Server enthält, die wir ganz am Anfang in dieser Datei zusammengeführt haben, mit einem Befehl wie:

callbridge trust cluster <trusted cluster certificate bundle>

Und starten Sie den Dienst mit dem Befehl neu:

callbridge restart

Als Ergebnis sollten Sie auf jedem Server dieses Bild erhalten:

XMPP-Cluster

Der XMPP-Dienst im CMS wird für die gesamte Registrierung und Authentifizierung für Cisco Meeting Apps (CMA) verwendet, einschließlich des CMA WebRTC-Webclients. Die Call Bridge selbst fungiert zu Authentifizierungszwecken auch als XMPP-Client und muss daher wie andere Clients konfiguriert werden. XMPP-Fehlertoleranz ist eine Funktion, die in Produktionsumgebungen seit Version 2.1 unterstützt wird

Die nachfolgend beschriebenen Befehle müssen auf jedem Server mit den entsprechenden Zertifikaten ausgeführt werden.
Also:

Wir verknüpfen Zertifikate mit dem XMPP-Dienst mit einem Befehl wie:

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

Definieren Sie dann die Abhörschnittstelle mit dem Befehl:

xmpp listen a

Der XMPP-Dienst erfordert eine eindeutige Domäne. Dies ist der Login für Benutzer. Mit anderen Worten: Wenn ein Benutzer versucht, sich über die CMA-App (oder über den WebRTC-Client) anzumelden, gibt er userID@logindomain ein. In unserem Fall ist es userid@conf.example.com. Warum heißt es nicht nur example.com? In unserer speziellen Bereitstellung haben wir unsere Unified CM-Domäne als example.com ausgewählt, die Jabber-Benutzer in Unified CM verwenden werden. Daher benötigten wir eine andere Domäne für CMS-Benutzer, um Anrufe zum und vom CMS über SIP-Domänen weiterzuleiten.

Richten Sie eine XMPP-Domäne mit einem Befehl wie dem folgenden ein:

xmpp domain <domain>

Und aktivieren Sie den XMPP-Dienst mit dem Befehl:

xmpp enable

Im XMPP-Dienst müssen Sie Anmeldeinformationen für jede Call Bridge erstellen, die bei der Registrierung beim XMPP-Dienst verwendet werden. Diese Namen sind willkürlich (und haben nichts mit den eindeutigen Namen zu tun, die Sie für das Call-Bridge-Clustering konfiguriert haben). Sie müssen drei Anrufbrücken auf einem XMPP-Server hinzufügen und diese Anmeldeinformationen dann auf anderen XMPP-Servern im Cluster eingeben, da diese Konfiguration nicht in die Cluster-Datenbank passt. Später werden wir jede Call Bridge so konfigurieren, dass sie diesen Namen und dieses Geheimnis für die Registrierung beim XMPP-Dienst verwendet.

Jetzt müssen wir den XMPP-Dienst auf dem ersten Server mit den drei Call Bridges callbridge01, callbridge02 und callbridge03 konfigurieren. Jedem Konto werden zufällige Passwörter zugewiesen. Sie werden später auf anderen Call Bridge-Servern eingetragen, um sich bei diesem XMPP-Server anzumelden. Geben Sie die folgenden Befehle ein:

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

Als Ergebnis überprüfen wir, was mit dem Befehl passiert ist:

xmpp callbridge list

Nach den unten beschriebenen Schritten sollte auf den übrigen Servern genau das gleiche Bild erscheinen.

Als nächstes fügen wir auf den verbleibenden beiden Servern genau die gleichen Einstellungen hinzu, nur mit den Befehlen

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

Wir fügen Secret sehr sorgfältig hinzu, damit es beispielsweise keine zusätzlichen Leerzeichen enthält.


Als Ergebnis sollte jeder Server das gleiche Bild haben:

Als Nächstes geben wir auf allen Servern im Cluster die Datei mit allen drei Zertifikaten an, die zuvor mit einem Befehl wie dem folgenden erstellt wurde:

xmpp cluster trust <trust bundle>

Wir aktivieren den xmpp-Cluster-Modus auf allen Cluster-Servern mit dem Befehl:

xmpp cluster enable

Auf dem ersten Server des Clusters initiieren wir die Erstellung eines xmpp-Clusters mit dem Befehl:

xmpp cluster initialize

Fügen Sie auf anderen Servern einen Cluster zu xmpp mit einem Befehl wie dem folgenden hinzu:

xmpp cluster join <ip address head xmpp server>

Wir überprüfen auf jedem Server den Erfolg der Erstellung eines XMPP-Clusters auf jedem Server mit den Befehlen:

xmpp status
xmpp cluster status

Erster Server:

Zweiter Server:

Dritter Server:

Call Bridge mit XMPP verbinden

Da der XMPP-Cluster nun ausgeführt wird, müssen Sie die Call Bridge-Dienste für die Verbindung mit dem XMPP-Cluster konfigurieren. Diese Konfiguration erfolgt über den Webadministrator.

Gehen Sie auf jedem Server zu Konfiguration > Allgemein und in das Feld Eindeutiger Anrufbrückenname Schreiben Sie eindeutige Namen, die der Server-Call Bridge entsprechen Callbridge[01,02,03]. оле Domain conf.example.ru und entsprechende Passwörter können Sie ausspionieren
auf einem beliebigen Server im Cluster mit dem Befehl:

xmpp callbridge list

Lassen Sie das Feld „Server“ leer Anrufbrücke führt eine DNS-SRV-Suche durch _xmpp-component._tcp.conf.example.comum einen verfügbaren XMPP-Server zu finden. Die IP-Adressen zum Verbinden von Callbridges mit XMPP können auf jedem Server unterschiedlich sein, es hängt davon ab, welche Werte an die Datensatzanforderung zurückgegeben werden _xmpp-component._tcp.conf.example.com Callbridge, die wiederum von den Prioritätseinstellungen für einen bestimmten DNS-Eintrag abhängt.

Gehen Sie als Nächstes zu Status > Allgemein, um zu überprüfen, ob der Call Bride-Dienst erfolgreich mit dem XMPP-Dienst verbunden wurde.

Web-Bridge

Aktivieren Sie auf jedem Server im Cluster den Web Bridge-Dienst mit dem folgenden Befehl:

webbridge listen a:443

Wir konfigurieren den Web Bridge-Dienst mit Zertifikatsdateien mit einem Befehl wie:

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

Web Bridge unterstützt HTTPS. Es wird HTTP zu HTTPS umleiten, wenn es für die Verwendung von „http-redirect“ konfiguriert ist.
Um die HTTP-Umleitung zu aktivieren, verwenden Sie den folgenden Befehl:

webbridge http-redirect enable

Um Call Bridge darüber zu informieren, dass Web Bridge Verbindungen von Call Bridge vertrauen kann, verwenden Sie den folgenden Befehl:

webbridge trust <certfile>

Dabei handelt es sich um eine Datei, die alle drei Zertifikate von jedem Server im Cluster enthält.

Dieses Bild sollte auf jedem Server im Cluster vorhanden sein.


Теперь нам нужно создать пользователя с ролью «appadmin», он нам нужен для того чтобы мы могли настраивать наш кластер(!), а не каждый сервер кластера по отдельности, таким образом настройки будут применяться одинаково на каждый сервер при том, что производиться они будут einmal.


Für die weitere Einrichtung verwenden wir Postman.

Wählen Sie für die Autorisierung im Abschnitt „Autorisierung“ die Option „Basis“ aus

Um Befehle korrekt an den CMS-Server zu senden, müssen Sie die erforderliche Kodierung festlegen

Wir geben Webbridge mit dem Befehl an jetzt lesen mit Parameter URL und Bedeutung cms.example.com



In der Webbridge selbst geben wir die erforderlichen Parameter an: Gastzugang, geschützter Zugang usw.

Rufen Sie Bridge-Gruppen an

Standardmäßig nutzt das CMS die ihm zur Verfügung stehenden Konferenzressourcen nicht immer optimal.

Beispielsweise kann bei einem Meeting mit drei Teilnehmern jeder Teilnehmer auf drei verschiedenen Anrufbrücken landen. Damit diese drei Teilnehmer miteinander kommunizieren können, stellt Call Bridges automatisch Verbindungen zwischen allen Servern und Clients im selben Space her, sodass alles so aussieht, als ob alle Clients auf demselben Server wären. Leider besteht der Nachteil darin, dass eine einzelne 3-Personen-Konferenz nun 9 Medienanschlüsse belegt. Dies ist offensichtlich eine ineffiziente Nutzung der Ressourcen. Wenn eine Call Bridge außerdem wirklich überlastet ist, besteht der Standardmechanismus darin, weiterhin Anrufe anzunehmen und allen Teilnehmern dieser Call Bridge einen Dienst mit reduzierter Qualität anzubieten.

Diese Probleme werden mit der Funktion „Call Bridge Group“ gelöst. Diese Funktion wurde in Version 2.1 der Cisco Meeting Server-Software eingeführt und wurde erweitert, um den Lastausgleich für eingehende und ausgehende Cisco Meeting App (CMA)-Anrufe, einschließlich WebRTC-Teilnehmer, zu unterstützen.

Um das Wiederverbindungsproblem zu lösen, wurden für jede Call Bridge drei konfigurierbare Lastgrenzen eingeführt:

Lastgrenze – Dies ist die maximale numerische Belastung für eine bestimmte Anrufbrücke. Für jede Plattform gilt ein empfohlenes Lastlimit, beispielsweise 96000 für das CMS1000 und 1.25 GHz pro vCPU für die virtuelle Maschine. Verschiedene Anrufe verbrauchen je nach Auflösung und Bildrate des Teilnehmers eine bestimmte Menge an Ressourcen.
NewConferenceLoadLimitBasisPoints (Standard 50 % LoadLimit) – legt die Serverlastgrenze fest, nach der neue Konferenzen abgelehnt werden.
VorhandeneConferenceLoadLimitBasisPoints (Standard 80 % von LoadLimit) – der Serverlastwert, nach dem Teilnehmer, die einer bestehenden Konferenz beitreten, abgelehnt werden.

Während diese Funktion für die Anrufverteilung und den Lastausgleich konzipiert wurde, können auch andere Gruppen wie TURN-Server, Web Bridge-Server und Rekorder Call Bridge-Gruppen zugewiesen werden, sodass sie für eine optimale Nutzung ebenfalls ordnungsgemäß gruppiert werden können. Wenn eines dieser Objekte keiner Anrufgruppe zugeordnet ist, wird davon ausgegangen, dass es allen Servern ohne besondere Priorität zur Verfügung steht.

Diese Parameter werden hier konfiguriert: cms.example.com:445/api/v1/system/configuration/cluster

Als nächstes geben wir jeder Callbridge an, zu welcher Callbridge-Gruppe sie gehört:

Erste Callbridge

Zweite Rufbrücke

Dritte Rufbrücke


Daher haben wir die Call Brdige-Gruppe so konfiguriert, dass sie die Ressourcen des Cisco Meeting Server-Clusters effizienter nutzt.

Benutzer aus Active Directory importieren

Der Web-Admin-Dienst verfügt über einen LDAP-Konfigurationsabschnitt, bietet jedoch keine komplexen Konfigurationsoptionen und die Informationen werden nicht in der Cluster-Datenbank gespeichert, sodass die Konfiguration entweder manuell auf jedem Server über die Webschnittstelle oder über durchgeführt werden muss die API, und damit wir „dreimal nicht aufstehen“, werden wir die Daten trotzdem über die API einstellen.

Für den Zugriff wird eine URL verwendet cms01.example.com:445/api/v1/ldapServers erstellt ein LDAP-Serverobjekt und gibt Parameter an wie:

• Server-IP
• Port-Nummer
• Benutzername
• Kennwort
• Verbindung

Sicher – wählen Sie je nach Port „true“ oder „false“, 389 – nicht sicher, 636 – geschützt.


Zuordnen von LDAP-Quellparametern zu Attributen im Cisco Meeting Server.
Die LDAP-Zuordnung ordnet die Attribute im LDAP-Verzeichnis den Attributen im CMS zu. Die tatsächlichen Attribute:

• jidMapping
• Namenszuordnung
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Beschreibung der AttributeJID stellt die Anmelde-ID des Benutzers im CMS dar. Da es sich um einen Microsoft Active Directory LDAP-Server handelt, wird die CMS-JID dem sAMAccountName in LDAP zugeordnet, bei dem es sich im Wesentlichen um die Active Directory-Anmelde-ID des Benutzers handelt. Beachten Sie außerdem, dass Sie sAMAccountName nehmen und am Ende die Domäne conf.pod6.cms.lab hinzufügen, da dies der Login ist, mit dem sich Ihre Benutzer beim CMS anmelden.

Namenszuordnung Gleicht den Inhalt des DisplayName-Felds von Active Directory mit dem CMS-Namensfeld des Benutzers ab.

coSpaceNameMapping erstellt einen CMS-Bereichsnamen basierend auf dem Feld displayName. Dieses Attribut ist zusammen mit dem coSpaceUriMapping-Attribut erforderlich, um für jeden Benutzer einen Bereich zu erstellen.

coSpaceUriMapping Definiert den Benutzerteil des URI, der dem persönlichen Bereich des Benutzers zugeordnet ist. Einige Domänen können so konfiguriert werden, dass sie in den Weltraum eingewählt werden. Wenn der Benutzerteil mit diesem Feld für eine dieser Domänen übereinstimmt, wird der Anruf an den Bereich dieses Benutzers weitergeleitet.

coSpaceSecondaryUriMapping Definiert einen zweiten URI, um den Speicherplatz zu erreichen. Dies kann verwendet werden, um als Alternative zum alphanumerischen URI, der im Parameter coSpaceUriMapping definiert ist, einen numerischen Alias ​​für die Weiterleitung von Anrufen an den Bereich des importierten Benutzers hinzuzufügen.

Der LDAP-Server und die LDAP-Zuordnung sind konfiguriert. Jetzt müssen Sie sie miteinander verknüpfen, indem Sie eine LDAP-Quelle erstellen.

Für den Zugriff wird eine URL verwendet cms01.example.com:445/api/v1/ldapSource erstellt ein LDAP-Quellobjekt und gibt Parameter an wie:

• Server
• Mapping
• baseDn
• Filter

Nachdem die LDAP-Konfiguration nun abgeschlossen ist, können Sie den manuellen Synchronisierungsvorgang durchführen.

Dies machen wir entweder im Webinterface des jeweiligen Servers per Klick Jetzt synchronisieren in Abschnitt Active Directory


oder über die API mit dem Befehl jetzt lesen Verwenden der URL für den Zugriff cms01.example.com:445/api/v1/ldapSyncs

Ad-hoc-Konferenzen

Was ist das?Im traditionellen Konzept liegt eine Konferenz vor, wenn zwei Teilnehmer miteinander sprechen und einer der Teilnehmer (unter Verwendung eines bei Unified CM registrierten Geräts) die Schaltfläche „Konferenz“ drückt, die andere Person anruft und anschließend mit diesem Dritten spricht , drückt erneut die Schaltfläche „Konferenz“, um allen Teilnehmern der Dreierkonferenz beizutreten.

Was eine Ad-hoc-Konferenz von einer geplanten Konferenz in einem CMS unterscheidet, ist, dass eine Ad-hoc-Konferenz nicht nur ein SIP-Anruf an ein CMS ist. Wenn der Konferenzinitiator ein zweites Mal auf die Schaltfläche „Konferenz“ klickt, um alle zu derselben Besprechung einzuladen, muss Unified CM einen API-Aufruf an das CMS tätigen, um eine spontane Konferenz zu erstellen, an die dann alle Anrufe weitergeleitet werden. All dies geschieht unbemerkt für die Teilnehmer.

Das bedeutet, dass Unified CM die API-Anmeldeinformationen und die WebAdmin-Adresse/den WebAdmin-Port des Dienstes sowie den SIP-Trunk direkt zum CMS-Server konfigurieren muss, um den Anruf fortzusetzen.

Bei Bedarf kann CUCM dynamisch einen Bereich im CMS erstellen, sodass jeder Anruf den CMS erreichen und der Regel für eingehende Anrufe entsprechen kann, die für Bereiche vorgesehen ist.

Integration mit CUCM Die Konfiguration erfolgt auf die gleiche Weise wie im Artikel beschrieben früher Mit der Ausnahme, dass Sie auf Cisco UCM drei Trunks für das CMS und drei Konferenzbrücken erstellen, im SIP-Sicherheitsprofil drei Betreffnamen, Routengruppen, Routenlisten, Medienressourcengruppen und Medienressourcengruppenlisten angeben und einige Routing-Regeln hinzufügen müssen zum Cisco Meeting Server.

SIP-Sicherheitsprofil:


Badehosen:


Jeder Stamm sieht gleich aus:




Konferenzbrücke


Jede Konferenzbrücke sieht gleich aus:


Routengruppe


Routenliste


Medienressourcengruppe


Liste der Medienressourcengruppen

Anrufregeln

Im Gegensatz zu fortschrittlicheren Anrufverwaltungssystemen wie Unified CM oder Expressway sucht CMS bei neuen Anrufen nur nach der Domäne im SIP-Request-URI-Feld. Wenn SIP INVITE also für SIP ist: [E-Mail geschützt] Das CMS kümmert sich nur um domain.com. CMS befolgt diese Regeln, um zu bestimmen, wohin ein Anruf weitergeleitet werden soll:

1. Das CMS versucht zunächst, die SIP-Domäne mit den in den Regeln für eingehende Anrufe konfigurierten Domänen abzugleichen. Diese Anrufe können dann an („gezielte“) Bereiche oder bestimmte Benutzer, interne IVRs oder direkt integrierte Microsoft Lync/Skype for Business (S4B)-Ziele weitergeleitet werden.
2. Wenn es keine Übereinstimmung in den Regeln für eingehende Anrufe gibt, versucht CMS, eine Übereinstimmung mit der in der Anrufweiterleitungstabelle konfigurierten Domäne herzustellen. Bei einer Übereinstimmung kann die Regel den Anruf explizit ablehnen oder weiterleiten. Zu diesem Zeitpunkt schreibt das CMS möglicherweise die Domäne neu, was manchmal beim Aufrufen von Lync-Domänen nützlich ist. Sie können sich auch für „Pass Throw“ entscheiden, was bedeutet, dass keines der Felder weiter geändert wird, oder einen internen CMS-Wählplan verwenden. Wenn es keine Übereinstimmung in den Anrufweiterleitungsregeln gibt, wird der Anruf standardmäßig abgelehnt. Beachten Sie, dass im CMS der Anruf zwar „weitergeleitet“ wird, die Medien jedoch weiterhin an das CMS gebunden sind, was bedeutet, dass sie sich im Signalisierungs- und Medienverkehrspfad befinden.
Dann unterliegen nur weitergeleitete Anrufe den Regeln für ausgehende Anrufe. Diese Einstellungen bestimmen die Ziele, an die Anrufe gesendet werden, den Trunk-Typ (ob es sich um einen neuen Lync-Anruf oder einen Standard-SIP-Anruf handelt) und alle Konvertierungen, die durchgeführt werden können, wenn die Weiterleitung in der Anrufweiterleitungsregel nicht ausgewählt ist.

Hier ist das eigentliche Protokoll dessen, was während einer Ad-hoc-Konferenz passiert

Der Screenshot zeigt es schlecht (ich weiß nicht, wie ich es besser machen kann), also schreibe ich das Protokoll so:

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

Die Ad-hoc-Konferenz selbst:


Regeln für eingehende Anrufe
Um einen Anruf im CMS entgegennehmen zu können, müssen die Parameter eingehender Anrufe konfiguriert werden. Wie Sie im LDAP-Setup gesehen haben, wurden alle Benutzer mit der Domäne conf.pod6.cms.lab importiert. Sie möchten also zumindest, dass Aufrufe dieser Domäne auf Leerzeichen abzielen. Sie müssen außerdem Regeln für alles einrichten, was für den vollqualifizierten Domänennamen (und möglicherweise sogar die IP-Adresse) jedes CMS-Servers bestimmt ist. Unsere externe Anrufsteuerung Unified CM konfiguriert SIP-Trunks für jeden CMS-Server einzeln. Abhängig davon, ob das Ziel dieser SIP-Trunks eine IP-Adresse oder der FQDN des Servers ist, wird bestimmt, ob das CMS so konfiguriert werden muss, dass es Anrufe akzeptiert, die an seine IP-Adresse oder seinen FQDN gerichtet sind.

Die Domäne mit der Eingangsregel mit der höchsten Priorität wird als Domäne für alle Benutzerbereiche verwendet. Wenn Benutzer über LDAP synchronisieren, erstellt das CMS automatisch Leerzeichen, jedoch nur den Benutzerteil des URI (coSpaceUriMapping), zum Beispiel user.space. Teil Domain Der vollständige URI wird basierend auf dieser Regel generiert. Wenn Sie sich zu diesem Zeitpunkt bei Web Bridge anmelden würden, würden Sie tatsächlich feststellen, dass der Space-URI keine Domäne hat. Indem Sie diese Regel als höchste Priorität festlegen, legen Sie die Domäne für die generierten Räume fest Konf.beispiel.com.


Regeln für ausgehende Anrufe

Damit Benutzer ausgehende Anrufe an den Unified CM-Cluster tätigen können, müssen Sie Ausgangsregeln konfigurieren. Die Domäne der bei Unified CM registrierten Endpunkte, wie z. B. Jabber, ist example.com. Anrufe an diese Domäne sollten als Standard-SIP-Anrufe an Unified CM-Anrufverarbeitungsknoten weitergeleitet werden. Der Hauptserver ist cucm-01.example.com und der zusätzliche Server ist cucm-02.example.com.

Die erste Regel beschreibt die einfachste Weiterleitung von Anrufen zwischen Clusterservern.

Feld Lokal von der Domäne ist dafür verantwortlich, was im SIP-URI des Anrufers nach dem „@“-Symbol für den Angerufenen angezeigt wird. Wenn wir es leer lassen, steht nach dem „@“-Symbol die IP-Adresse des CUCM, über die dieser Anruf geleitet wird. Wenn wir eine Domäne angeben, steht hinter dem „@“-Symbol tatsächlich eine Domäne. Dies ist notwendig, um einen Rückruf durchführen zu können, andernfalls ist ein Rückruf über SIP-URI Name@IP-Adresse nicht möglich.

Rufen Sie an, wenn Sie dazu aufgefordert werden Lokal von der Domäne


Rufen Sie an, wann NICHT angezeigt Lokal von der Domäne


Stellen Sie sicher, dass Sie für ausgehende Anrufe explizit „Verschlüsselt“ oder „Unverschlüsselt“ angeben, da mit dem Parameter „Auto“ nichts funktioniert.

Aufnahme

Videokonferenzen werden vom Record-Server aufgezeichnet. Recorder ist genau das gleiche wie Cisco Meeting Server. Für den Recorder sind keine Lizenzen erforderlich. Aufnahmelizenzen sind für Server erforderlich, auf denen CallBridge-Dienste ausgeführt werden, d. h. Eine Aufnahmelizenz ist erforderlich und muss auf die CallBridge-Komponente angewendet werden, nicht auf den Server, auf dem Recorder ausgeführt wird. Der Recorder verhält sich wie ein XMPP-Client (Extensible Messaging and Presence Protocol). Daher muss der XMPP-Server auf dem Server aktiviert sein, der CallBridge hostet.

Weil Wir haben einen Cluster und die Lizenz muss auf alle drei Server im Cluster „ausgedehnt“ werden. Dann verknüpfen (fügen) wir einfach in Ihrem persönlichen Konto in den Lizenzen die MAC-Adressen der A-Schnittstellen aller im Cluster enthaltenen CMS-Server ein.

Und dieses Bild sollte auf jedem Server im Cluster vorhanden sein

Im Allgemeinen gibt es mehrere Szenarien für die Platzierung des Recorders, wir bleiben jedoch dabei:


Bevor Sie den Recorder einrichten, müssen Sie einen Ort vorbereiten, an dem die Videokonferenzen tatsächlich aufgezeichnet werden. Eigentlich hier Link, wie man alle Aufnahmen einrichtet. Ich konzentriere mich auf wichtige Punkte und Details:

1. Es ist besser, das Zertifikat vom ersten Server im Cluster zu übertragen.
2. Der Fehler „Recorder nicht verfügbar“ kann auftreten, weil im Recorder Trust das falsche Zertifikat angegeben ist.
3. Das Schreiben funktioniert möglicherweise nicht, wenn das für die Aufzeichnung angegebene NFS-Verzeichnis nicht das Stammverzeichnis ist.

Manchmal besteht die Notwendigkeit, eine Konferenz eines bestimmten Benutzers oder Bereichs automatisch aufzuzeichnen.

Hierzu werden zwei CallProfiles erstellt:
Mit deaktivierter Aufnahme


Und mit automatischer Aufnahmefunktion


Als nächstes „hängen“ wir ein CallProfile mit automatischer Aufnahmefunktion an den benötigten Platz an.


Im CMS ist es so festgelegt, dass, wenn ein CallProfile explizit an einen beliebigen Raum oder Raum gebunden ist, dieses CallProfile nur in Bezug auf diese bestimmten Räume funktioniert. Und wenn das CallProfile an keinen Raum gebunden ist, wird es standardmäßig auf die Räume angewendet, an die kein CallProfile explizit gebunden ist.

Das nächste Mal werde ich versuchen zu beschreiben, wie auf das CMS außerhalb des internen Netzwerks der Organisation zugegriffen wird.

Quellen:

• 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