Cisco Meeting Server 2.5.2. Cluster im Scalable and Resilient-Modus mit der Funktion zur Aufnahme von Videokonferenzen.

In dieser Ausgabe werde ich einige Feinheiten bei der Konfiguration eines CMS-Servers im Fault-Tolerant-Cluster-Modus zeigen und erklären.


TheorieEs gibt insgesamt drei Arten der Bereitstellung eines CMS-Servers:

• Single Combined(Einzelner Kombinierter), d.h. es handelt sich um einen Server, auf dem alle erforderlichen Dienste ausgeführt werden. In den meisten Fällen wird dieser Typ der Bereitstellung nur für den Zugang interner Clients und in kleinen Umgebungen verwendet, in denen die Einschränkungen hinsichtlich Skalierbarkeit und Redundanz eines einzelnen Servers kein kritisches Problem darstellen, oder in Situationen, in denen das CMS nur bestimmte Funktionen ausführt, wie z.B. spezielle Konferenzen auf Cisco UCM.

  Ungefähres Funktionsschema:
  

• Single Split(Einzelner Geteilte) erweitert den vorherigen Bereitstellungstyp, indem er einen separaten Server für den externen Zugriff hinzufügt. In veralteten Bereitstellungen bedeutete dies, einen CMS-Server in einem demilitarisierten Segment des Netzwerks (DMZ) bereitzustellen, auf den externe Clients zugreifen konnten, sowie einen CMS-Server im Kern des Netzwerks, auf den interne Clients zugreifen. Dieses spezielle Bereitstellungsmodell wird nun durch den sogenannten Typ Single Edge, der aus Servern Cisco Expressway, die entweder viele der Firewall-Umgehungsmöglichkeiten haben oder haben werden, sodass die Kunden keinen dedizierten Grenzserver für das CMS hinzufügen müssen.

  Ungefähres Funktionsschema:
  

• Skalierbar und Resilient(Dieser Typ umfasst Redundanz für jede Komponente, wodurch das System mit Ihren Bedürfnissen bis zur maximalen Kapazität wachsen kann und gleichzeitig Redundanz im Falle eines Ausfalls gewährleistet wird. Er nutzt auch das Konzept der Single Edge, um einen sicheren externen Zugriff zu ermöglichen. Dies ist der Typ, den wir in dieser Ausgabe behandeln werden. Wenn wir verstehen, wie man einen Cluster dieses Typs bereitstellt, werden wir nicht nur die anderen Bereitstellungstypen verstehen, sondern auch lernen, wie man CMS-Server-Cluster mit Blick auf das potenzielle Wachstum der Bedürfnisse erstellt.

Bevor wir zur Bereitstellung übergehen, müssen einige grundlegende Dinge verstanden werden, nämlich

Wesentliche Softwarekomponenten des CMS:

• Datenbank: ermöglicht das Zusammenführen bestimmter Konfigurationen, wie Abonnentengruppen, Benutzerspeicher und die Benutzer selbst. Unterstützt Clusterbildung nur für hohe Verfügbarkeit (ein Master).
• Call Bridge: Ein Dienst für Audio- und Videokonferenzen, der vollständige Kontrolle über das Management und die Verarbeitung von Anrufen sowie Multimedia-Prozessen bietet. Unterstützt Clusterbildung 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 für die interkomponentale Signalisierung. Kann nur für hohe Verfügbarkeit geclustert werden.
• Web Bridge: Gewährt den Kunden Zugang zu WebRTC.
• Lastenausgleich: Bietet einen einheitlichen Verbindungspunkt für die Cisco Meeting App im Single Split-Modus. Überwacht die externe Schnittstelle und den Port für eingehende Verbindungen. Der Lastenausgleich akzeptiert eingehende TLS-Verbindungen vom XMPP-Server, über die er TCP-Verbindungen von externen Kunden umschalten kann.
  In unserem Szenario wird er nicht benötigt.
• TURN-Server: Bietet Technologien zum Umgehen von Firewalls und erlaubt es,
  unser CMS hinter einer Firewall oder NAT zu platzieren, um externe Kunden, die die Cisco Meeting App oder SIP-Geräte verwenden, zu verbinden. In unserem Szenario wird er nicht benötigt.
• Web Admin: Verwaltungsoberfläche und API-Zugang, einschließlich für spezielle Unified CM-Konferenzen.

Konfigurationsmodi

Im Gegensatz zu den meisten anderen Cisco-Produkten unterstützt der Cisco Meeting Server drei Konfigurationsmethoden, die eine Bereitstellung jeder Art von Deployment ermöglichen.

• Befehlszeilenschnittstelle (CLI): Befehlszeilenschnittstelle, bekannt als MMP, für Aufgaben der Ersteinrichtung und Zertifikate.
• Web-Administrator: in erster Linie für CallBridge-bezogene Konfigurationen, insbesondere bei der Einrichtung eines einzelnen nicht-clusterierten Servers.
• REST API: wird für die komplexesten Konfigurationsaufgaben und clusterbezogene Datenbankaufgaben verwendet.

Zusätzlich zu den oben genannten wird das Protokoll SFTP verwendet, um Dateien – typischerweise Lizenzen, Zertifikate oder Protokolle – an den CMS-Server zu übertragen und von ihm.

In den Deployment-Anleitungen von Cisco steht ausdrücklich, dass ein Cluster mindestens aus drei Servern (Nodes) im Kontext von Datenbanken bestehen muss. Nur mit einer ungeraden Anzahl von Knoten funktioniert der Mechanismus zur Auswahl eines neuen Master-Datenbankservers, und der Master-Datenbankserver hat eine Verbindung zum Großteil der Datenbank des CMS-Servers.

Und wie die Praxis zeigt, reichen zwei Server (Nodes) tatsächlich nicht aus. Der Auswahlmechanismus funktioniert bei einem Neustart des Masters, der Slave-Server wird nur dann zum Master, wenn der neu gestartete Server aktiviert wird. Wenn jedoch im Cluster mit zwei Servern der Master-Server plötzlich ausfällt, wird der Slave-Server nicht zum Master, und wenn der Slave ausfällt, wird der verbleibende Master-Server ebenfalls zum Slave.

Im Kontext von XMPP hingegen ist es wirklich notwendig, einen Cluster aus drei Servern zu bilden, da, wenn beispielsweise der XMPP-Dienst auf einem der Server, dessen XMPP den Status 'Leader' hat, deaktiviert wird, der verbleibende Server weiterhin den Status 'Follower' behält. Die Verbindungen von CallBridge zu XMPP brechen ab, da CallBridge sich ausschließlich mit einem XMPP-Server im Status 'Leader' verbindet. Das ist kritisch, denn kein Anruf wird durchgeführt werden.

In denselben Deployment-Guides wird auch ein Cluster mit einem einzelnen XMPP-Server demonstriert.

In Anbetracht des Vorstehenden wird klar, warum: Es funktioniert, weil es im Failover-Modus läuft.

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

Es wird angenommen, dass alle drei unsere Server hochgefahren sind.

DNS-Einträge

Bevor Sie mit der Konfiguration der Server beginnen, müssen Sie DNS-Einträge erstellen. A und SRV Typen:

Bitte beachten Sie, dass in unseren DNS-Einträgen zwei Domains vorhanden sind: example.com und conf.example.com. Example.com ist die Domain, die alle Abonnenten des Cisco Unified Communication Managers für ihre URIs verwenden können, die wahrscheinlich in Ihrer Infrastruktur vorhanden sind oder mit hoher Wahrscheinlichkeit vorhanden sein werden. Oder die Domain example.com entspricht der Domain, die die Benutzer für ihre E-Mail-Adressen verwenden. Alternativ kann der Jabber-Client auf Ihrem Laptop die URI user@example.com haben. Die Domain conf.example.com ist die Domain, die für die Benutzer des Cisco Meeting Servers eingerichtet wird. Die Domain des Cisco Meeting Servers wird conf.example.com sein, weshalb der gleiche Jabber-Benutzer zur Anmeldung am Cisco Meeting Server die URI user@conf.example.com verwenden muss.

Grundkonfiguration

Alle unten beschriebenen Einstellungen sind auf einem Server dargestellt, müssen jedoch auf jedem Server des Clusters durchgeführt werden.

QoS

Da CMS generiert Echtzeit Für latenz- und paketverlustsensiblen Datenverkehr wird in den meisten Fällen empfohlen, Quality of Service (QoS) einzurichten. Dazu unterstützt unser CMS die Kennzeichnung von Paketen mit Differentiated Services Code Point (DSCP), die es generiert. Obwohl die Priorisierung von Datenverkehr basierend auf DSCP davon abhängt, wie der Datenverkehr von den Netzwerkkomponenten Ihrer Infrastruktur behandelt wird, werden wir in diesem Fall unser CMS mit einer typischen Priorisierungsverteilung für DSCP gemäß den besten QoS-Praktiken konfigurieren.

Wir geben folgende Befehle auf jedem Server ein:

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

Somit wird der gesamte Video-Datenverkehr mit AF41 (DSCP 0x22) gekennzeichnet, der gesamte Sprachverkehr mit EF (DSCP 0x2E) und andere Arten von latenzsensibler Datenübertragung, wie SIP und XMPP, nutzen AF31 (DSCP 0x1A).

Überprüfen wir:

NTP

Das Network Time Protocol (NTP) ist nicht nur wichtig, um genaue Zeitstempel für Anrufe und Konferenzen zu gewährleisten, sondern auch zur Überprüfung von Zertifikaten.

Fügen Sie NTP-Server zu Ihrer Infrastruktur mit einem Befehl vom Typ hinzu:

ntp server add

In unserem Fall gibt es zwei solcher Server, daher werden auch zwei Befehle erforderlich sein.
Überprüfen wir:

Und wir stellen die Zeitzone für unseren Server ein.

DNS

DNS-Server in CMS werden mit dem Befehl hinzugefügt:

dns add forwardzone

In unserem Fall gibt es zwei solcher Server, daher werden auch zwei Befehle erforderlich sein.
Überprüfen wir:

Konfiguration des Netzwerkinterfaces

Wir konfigurieren ein Interface mit dem folgenden Befehl:

ipv4  add 
/

Überprüfen wir:

Servername (Hostname)

Den Servernamen setzen wir mit dem folgenden Befehl:

hostname

Und starten neu.


Damit ist die grundlegende Konfiguration abgeschlossen.

Zertifikate

TheorieCisco Meeting Server erfordert eine verschlüsselte Kommunikation zwischen verschiedenen Komponenten, weshalb X.509-Zertifikate für alle CMS-Deployments notwendig sind. Diese garantieren das Vertrauen der Dienste/Server gegenüber anderen Servern/Diensten.

Für jeden Dienst wird ein Zertifikat benötigt, aber die Erstellung separater Zertifikate für jeden Dienst kann zu Verwirrung und zusätzlicher Komplexität führen. Glücklicherweise können wir ein Paar von öffentlichem und privatem Schlüssel für das Zertifikat 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 für jeden Server im Cluster ein Paar von öffentlichem und privatem Schlüssel für das Zertifikat erstellt werden.

Die Clusterbildung einer Datenbank hat jedoch spezielle Anforderungen an Zertifikate und erfordert daher eigene Zertifikate, die sich von denen anderer Dienste unterscheiden. Das CMS verwendet ein Serverzertifikat, das den von anderen Servern verwendeten Zertifikaten ähnelt, jedoch gibt es auch ein Client-Zertifikat, das für Verbindungen zur Datenbank eingesetzt wird. Die Datenbankzertifikate dienen sowohl der Authentifizierung als auch der Verschlüsselung. Anstatt einen Benutzernamen und ein Passwort zur Verbindung des Clients mit der Datenbank bereitzustellen, präsentiert der Client ein Zertifikat, dem der Server vertraut. Jeder Server im Datenbankcluster nutzt dasselbe Paar aus öffentlichem und privatem Schlüssel. Dies ermöglicht allen Servern im Cluster, Daten so zu verschlüsseln, dass sie nur von anderen Servern, die ebenfalls dasselbe Schlüsselpaar verwenden, entschlüsselt werden können.

Um die Reservierung zu ermöglichen, müssen die Datenbankcluster aus mindestens 3 Servern, jedoch maximal 5 bestehen, wobei die maximale Signallaufzeit in beiden Richtungen 200 ms zwischen allen Clustermitgliedern beträgt. Diese Grenze ist restriktiver als bei der Clusterbildung von Call Bridge, weshalb sie häufig ein limitierender Faktor bei geografisch verteilten Bereitstellungen ist.

Die Rolle der Datenbank für das CMS hat eine Reihe von einzigartigen Anforderungen. Im Gegensatz zu anderen Rollen benötigt sie ein Client- und Server-Zertifikat, wobei das Client-Zertifikat ein bestimmtes CN-Feld aufweisen muss, das dem Server präsentiert wird.

Das CMS verwendet eine Postgres-Datenbank mit einem Hauptserver und mehreren vollständig identischen Replikaten. Zu jedem Zeitpunkt gibt es nur eine Hauptdatenbank („Datenbankserver“). Die übrigen Mitglieder des Clusters sind Replikate oder „Datenbankclients“.

Für das Datenbankcluster sind das Zertifikat des dedizierten Servers und das Client-Zertifikat erforderlich. Diese müssen von Zertifizierungsstellen signiert sein, normalerweise von einer internen privaten Zertifizierungsstelle. Da jedes Mitglied des Datenbankclusters der Hauptserver werden kann, müssen die Zertifikatpaare des Datenbankservers und des Clients (die den öffentlichen und privaten Schlüssel enthalten) auf alle Server kopiert werden, damit sie die Identität des Clients oder des Datenbankservers annehmen können. Darüber hinaus muss das Root-Zertifikat der CA hochgeladen werden, um sicherzustellen, dass die Client- und Serverzertifikate überprüft werden können.

Nun erstellen wir die Anfrage für das Zertifikat, das von allen Serverdiensten außer der Datenbank verwendet wird (für die wird es eine separate Anfrage geben) mit einem Befehl dieser Art:

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

Im CN geben wir den allgemeinen Namen unserer Server an. Zum Beispiel, wenn die Hostnamen unserer Server server01, server02, server03, dann wäre der CN server.example.com

Das gleiche machen wir mit den verbleibenden zwei Servern, wobei die Befehle die entsprechenden "Hostnamen" beinhalten.

Wir erstellen zwei Anfragen für die Zertifikate, die von der Datenbankdienstleistung verwendet werden:

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

pki csr dbclusterclient CN:postgres

wobei dbclusterserver und dbclusterclient die Namen unserer Anfragen und zukünftigen Zertifikate, hostname1(2)(3) die entsprechenden Servernamen.

Dieses Verfahren führen wir nur auf einem Server durch(!), und die Zertifikate sowie die entsprechenden .key-Dateien laden wir auf andere Server hoch.

Aktivierung des Client-Zertifikatsmodus in AD CS

Außerdem müssen die Zertifikate für jeden Server in einer Datei zusammengeführt werdenIn *NIX:

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

In Windows/DOS:

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

Und auf jeden Server hochladen:
1. „Individuelles“ Serverzertifikat.
2. Wurzelzertifikat (einschließlich Zwischenzertifikate, sofern vorhanden).
3. Datenbankzertifikate („Server“ und „Client“) und die .key-Dateien, die bei der Erstellung der Anfrage für das „Server“- und „Client“-Zertifikat der Datenbank entstanden sind. Diese Dateien müssen auf allen Servern identisch sein.
4. Datei mit allen drei „individuellen“ Zertifikaten.

Am Ende sollte eine solche Dateianordnung auf jedem Server entstehen.

Datenbank-Cluster

Jetzt, da alle Zertifikate auf die CMS-Server hochgeladen sind, können Sie die Datenbank-Klusterung zwischen den drei Knoten einrichten und aktivieren. Der erste Schritt besteht darin, einen Server als Hauptknoten des Datenbank-Clusters auszuwählen und ihn vollständig zu konfigurieren.

Haupthost-Datenbank

Der erste Schritt zur Einrichtung der Datenbank-Replikation besteht darin, die Zertifikate anzugeben, die für die Datenbank verwendet werden sollen. Dies erfolgt mit einem Befehl der folgenden Art:

database cluster certs

Jetzt geben wir der CMS an, welches Interface für die Datenbank-Klusterung verwendet werden soll mit dem Befehl:

database cluster localnode a

Dann initialisieren wir die Datenbank des Clusters auf dem Hauptserver mit dem Befehl:

database cluster initialize

Client-Datenbank-Knoten

Wir führen dasselbe Verfahren durch, nur dass wir anstelle des Befehls database cluster initialize den Befehl der folgenden Art eingeben:

database cluster join

wo die IP-Adresse des CMS-Servers ist, auf dem das Cluster initialisiert wurde, einfach gesagt das Master.

Wir überprüfen, wie unser Datenbank-Cluster auf allen Servern funktioniert mit dem Befehl:

database cluster status

Das Gleiche machen wir mit dem verbleibenden dritten Server.

Somit ist unser erster Server der Master, während die anderen Slaves sind.

Web-Admin-Dienst

Aktivieren Sie den Web-Admin-Dienst:

webadmin listen a 445

Der Port 445 wurde gewählt, da der Port 443 für den Zugriff der Benutzer auf den Web-Client verwendet wird.

Konfigurieren Sie den Web-Admin-Dienst mit den Zertifikatdateien über den Befehl:

webadmin certs

Und aktivieren Sie den Web-Admin mit dem Befehl:

webadmin enable

Wenn alles gut läuft, erhalten wir die Erfolgsmeldungen, die anzeigen, dass der Web-Admin richtig für Netzwerk und Zertifikat konfiguriert ist. Überprüfen Sie die Funktionsfähigkeit des Dienstes über den Webbrowser, indem Sie die Adresse des Web-Administrators eingeben, zum Beispiel: cms.example.com:445

Call Bridge Cluster

Call Bridge ist der einzige Dienst, der in jeder CMS-Installation vorhanden ist. Call Bridge ist der Hauptmechanismus für die Konferenzkommunikation und bietet auch eine SIP-Schnittstelle, sodass Anrufe zu ihm oder von ihm geroutet werden können, beispielsweise mit Cisco Unified CM.

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

Binden Sie die Zertifikate an den Call Bridge-Dienst mit dem Befehl:

callbridge certs  []

Wir binden die CallBridge-Dienste mit folgendem Befehl an die benötigte Schnittstelle:

callbridge listen a

Und wir starten den Dienst mit dem Befehl:

callbridge restart

Jetzt, wo wir die Call Bridges konfiguriert haben, können wir die Call Bridge-Klusterung einrichten. Die Klusterung von Call Bridges unterscheidet sich von der Klusterung von Datenbanken oder XMPP. Ein Call Bridge Cluster kann zwischen 2 und 8 Knoten ohne Einschränkungen unterstützen. Es bietet nicht nur Redundanz, sondern auch Lastverteilung, sodass Konferenzen aktiv zwischen den Call Bridge-Servern mithilfe intelligenter Anrufverteilung verteilt werden können. Das CMS verfügt über zusätzliche Funktionen, Call Bridge-Gruppen und zugehörige Funktionen, die für eine weitere Verwaltung verwendet werden können.

Die Klusterung der Call Bridges wird hauptsächlich über die Web-Adminoberfläche konfiguriert.
Das folgende Verfahren muss auf jedem Cluster-Server durchgeführt werden.
Also,

1. Melden Sie sich über das Web an unter Configuration > Cluster.
2. In Call Bridge identity Geben Sie als einzigartigen Namen callbridge[01,02,03] ein, der dem Servernamen entspricht. Diese Namen sind beliebig, müssen aber innerhalb dieses Clusters einzigartig sein. Sie sind beschreibend, da sie anzeigen, dass es sich um die Identifikatoren der Server [01,02,03] handelt.
3. B Clustered Call Bridges Geben Sie die URL-Adressen der Webadministratoren unserer Server im Cluster ein, cms[01,02,03].example.com:445 in das Feld Adresse ein. Stellen Sie sicher, dass der Port angegeben ist. Sie können das Feld für die Peer link SIP-Domain leer lassen.
4. Fügen Sie das Vertrauen zu CallBridge für jeden Server mit einem Zertifikat hinzu, dessen Datei alle Zertifikate unserer Server enthält, die wir zu Beginn in diese Datei zusammengeführt haben, mit einem Befehl wie:

callbridge trust cluster

Und wir starten den Dienst mit dem Befehl:

callbridge restart

Am Ende sollte auf jedem Server folgendes Bild entstehen:

XMPP Cluster

Der XMPP-Dienst in CMS wird zur Verarbeitung aller Registrierungen und Authentifizierungen für Cisco Meeting Apps (CMA) verwendet, einschließlich des Webclients CMA WebRTC. Der Call Bridge selbst fungiert ebenfalls als XMPP-Client für Authentifizierungszwecke und muss daher wie andere Clients konfiguriert werden. Die Fehlertoleranz von XMPP ist eine Funktion, die in Produktionsumgebungen ab Version 2.1 unterstützt wird.

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

Verknüpfen Sie die Zertifikate mit dem XMPP-Dienst über den Befehl:

xmpp certs  []

Definieren Sie dann die Schnittstelle zum Lauschen mit dem Befehl:

xmpp listen a

Für den XMPP-Dienst ist eine eindeutige Domain erforderlich. Dies ist der Login für Benutzer. Mit anderen Worten, wenn ein Benutzer sich über die CMA-App (oder einen WebRTC-Client) anmeldet, gibt er userID@logindomain ein. In unserem Fall ist das userid@conf.example.com. Warum nicht einfach example.com? In unserer speziellen Bereitstellung haben wir unsere Unified CM-Domain gewählt, die Jabber-Benutzer in Unified CM verwenden werden, wie example.com. Daher benötigen wir eine andere Domain für CMS-Benutzer, um Anrufe über SIP-Domains in und aus dem CMS zu leiten.

Konfigurieren Sie die XMPP-Domain mit dem Befehl:

xmpp domain

Aktivieren Sie den XMPP-Dienst mit dem Befehl:

xmpp enable

Im XMPP-Dienst müssen für jede Call Bridge Anmeldedaten erstellt werden, die bei der Registrierung im XMPP-Dienst verwendet werden. Diese Namen sind willkürlich (und sind nicht mit den eindeutigen Namen verknüpft, die Sie für die Clusterung der Call Bridges konfiguriert haben). Auf einem XMPP-Server müssen drei Call Bridges hinzugefügt werden, und anschließend müssen diese Anmeldedaten auf anderen XMPP-Servern im Cluster eingegeben werden, da diese Konfiguration nicht in der clustered Datenbank gespeichert wird. Später werden wir jede Call Bridge so einrichten, dass sie diesen Namen und das Passwort zur Registrierung im XMPP-Dienst verwendet.

Jetzt müssen wir den XMPP-Dienst auf dem ersten Server mit den drei Call Bridges callbridge01, callbridge02 und callbridge03 einrichten. Jeder dieser Konten wird ein zufälliges Passwort zugewiesen. Später werden diese auf anderen Call Bridges eingegeben, um sich bei diesem XMPP-Server anzumelden. Wir geben die folgenden Befehle ein:

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

Wir überprüfen das Ergebnis mit dem Befehl:

xmpp callbridge list

Das gleiche Bild sollte auch auf den anderen Servern nach den unten beschriebenen Schritten vorhanden sein.

Fügen Sie dann auf den verbleibenden zwei 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

Das Hinzufügen des Secrets erfolgt äußerst sorgfältig, um beispielsweise versehentliche Leerzeichen zu vermeiden.


Am Ende sollten alle Server das gleiche Bild zeigen:

Anschließend geben wir auf allen Servern des Clusters die vertrauenswürdige Datei an, die alle drei zuvor vom Team erstellten Zertifikate enthält:

xmpp cluster trust

Wir aktivieren den XMPP-Cluster-Modus auf allen Servern des Clusters mit dem Befehl:

xmpp cluster enable

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

xmpp cluster initialize

Auf den anderen Servern fügen wir dem XMPP-Cluster mit einem Befehl wie folgt hinzu:

xmpp cluster join

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

xmpp status
xmpp cluster status

Erster Server:

Zweiter Server:

Dritter Server:

Verbindung der Call Bridge zu XMPP

Jetzt, da der XMPP-Cluster läuft, müssen die Call Bridge-Dienste so konfiguriert werden, dass sie mit dem XMPP-Cluster verbunden sind. Diese Konfiguration erfolgt über den Web-Administrator.

Wir gehen auf jedem Server zu Konfiguration > Allgemein und im Feld Eindeutiger Call Bridge-Name tragen wir die entsprechenden eindeutigen Call Bridge-Namen des Servers ein callbridge[01,02,03]. Im Feld Domain conf.example.ru und die entsprechenden Passwörter, die man einsehen kann
auf jedem Cluster-Server mit dem Befehl:

xmpp callbridge list

Das Feld „Server“ lassen wir leer, Callbridge führt eine DNS-SRV-Suche für _xmpp-component._tcp.conf.example.com, um einen verfügbaren XMPP-Server zu finden. Die IP-Adressen, über die sich die Callbridges mit XMPP verbinden, können auf jedem Server unterschiedlich sein, das hängt von den Rückgabewerten der Anfrage für den Datensatz ab. _xmpp-component._tcp.conf.example.com Das hängt wiederum von den Prioritätseinstellungen für diesen DNS-Datensatz ab.

Gehen Sie dann zu Status > Allgemein, um sicherzustellen, dass der Dienst Call Bride erfolgreich mit dem XMPP-Dienst verbunden ist.

Web Bridge

Aktivieren Sie auf jedem Cluster-Server den Web Bridge-Dienst mit folgendem Befehl:

webbridge listen a:443

Konfigurieren Sie den Web Bridge-Dienst mit den Zertifikatdateien über den Befehl:

webbridge certs

Web Bridge unterstützt HTTPS. Er wird HTTP auf HTTPS umleiten, wenn er 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 zu verständigen, dass Verbindungen von Call Bridge dem Web Bridge vertraut werden können, verwenden Sie den Befehl:

webbridge trust

wo dies die Datei ist, die alle drei Zertifikate von jedem Server im Cluster enthält.

Ein solches Bild sollte auf jedem Server des Clusters vorhanden sein.


Jetzt müssen wir einen Benutzer mit der Rolle „appadmin“ erstellen, da wir ihn benötigen, um unseren Cluster zu konfigurieren, und nicht jeden Server des Clusters einzeln. Auf diese Weise werden die Einstellungen einmalig vorgenommen und auf jeden Server gleichmäßig angewendet.


Für die weitere Konfiguration verwenden wir Postman.

Für die Authentifizierung wählen wir Basic im Abschnitt Autorisierung.

Um die Befehle korrekt an die CMS-Server zu senden, muss die richtige Kodierung eingestellt werden.

Wir geben die Webbridges mit dem Befehl an. POST mit dem Parameter url und dem Wert cms.example.com



Im Webbridge geben wir die benötigten Parameter an: Gastzugang, geschützter Zugang und weitere.

Call Bridge Groups

Standardmäßig nutzt CMS nicht immer die verfügbaren Ressourcen für die Konferenzverbindung optimal.

Wenn beispielsweise drei Teilnehmer an einem Treffen teilnehmen, kann jeder dieser Teilnehmer in drei verschiedenen Call Bridges sein. Um sicherzustellen, dass diese drei Teilnehmer miteinander kommunizieren können, richten die Call Bridges automatisch Verbindungen zwischen allen Servern und Clients im gleichen Space ein, sodass es so aussieht, als wären alle Clients auf demselben Server. Leider hat dies den Nachteil, dass eine Konferenz mit drei Personen nun 9 Media-Ports benötigt. Dies ist offensichtlich eine ineffiziente Nutzung von Ressourcen. Zudem, wenn ein Call Bridge tatsächlich überlastet ist, besteht der Standardmechanismus darin, weiterhin Anrufe entgegenzunehmen und Dienstleistungen mit reduzierter Qualität für alle Teilnehmer dieses Call Bridges bereitzustellen.

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 erweitert, um die Lastenverteilung sowohl für eingehende als auch für ausgehende Anrufe, Cisco Meeting App (CMA) und WebRTC-Teilnehmer zu unterstützen.

Zur Lösung des Reconnect-Problems wurden drei anpassbare Lastbeschränkungen für jede Call Bridge eingeführt:

LoadLimit — ist die maximale numerische Last für eine bestimmte Call Bridge. Jede Plattform hat einen empfohlenen Grenzwert für die Last, zum Beispiel 96000 für CMS1000 und 1,25 GHz pro virtuellen Prozessor für eine virtuelle Maschine. Verschiedene Anrufe verbrauchen je nach Auflösung und Bildrate der Teilnehmer eine bestimmte Menge an Ressourcen.
NewConferenceLoadLimitBasisPoints (standardmäßig 50% loadLimit) — legt die Serverlastgrenze fest, ab der neue Konferenzen abgelehnt werden.
ExistingConferenceLoadLimitBasisPoints (standardmäßig 80% von loadLimit) — der Wert der Serverlast, ab der Teilnehmer, die einer bestehenden Konferenz beitreten, abgelehnt werden.

Während diese Funktion entwickelt wurde, um Anrufe zu verteilen und die Last zu verteilen, können auch andere Gruppen wie TURN-Server, Web Bridge-Server und Aufnahmegeräte für Call Bridge-Gruppen zugewiesen werden, damit sie ebenfalls richtig gruppiert werden können, um eine optimale Nutzung zu gewährleisten. Wenn eines dieser Objekte nicht der Call Bridge-Gruppe zugewiesen ist, wird angenommen, dass sie für alle Server ohne spezifische Priorität verfügbar sind.

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

Anschließend geben wir für jede Callbridge an, zu welcher Callbridge-Gruppe sie gehört:

Erste Callbridge

Zweite Callbridge

Dritte Callbridge


Somit haben wir die Callbridge-Gruppe für eine effizientere Ressourcennutzung des Cisco Meeting Servers konfiguriert.

Benutzer aus Active Directory importieren

Der Web-Admin-Dienst hat einen Abschnitt zur LDAP-Konfiguration, bietet jedoch keine komplexen Konfigurationsparameter, und die Informationen werden nicht in der Cluster-Datenbank gespeichert. Daher müssen die Einstellungen entweder manuell auf jedem Server über die Web-Oberfläche oder über die API vorgenommen werden. Um „dreimal nicht aufstehen zu müssen“, werden wir die Daten jedoch über die API angeben.

Zugriff über die URL verwenden cms01.example.com:445/api/v1/ldapServers erstellen wir das LDAP-Serverobjekt und geben dabei Parameter wie an:

• Server-IP-Adresse
• Portnummer
• Benutzername
• Passwort
• sicher

Sicher — true oder false wählen wir abhängig vom Port, 389 — ungesichert, 636 — gesichert.


LDAP-Parameter der Quelle den Attributen im Cisco Meeting Server zuordnen.
Die Zuordnung von LDAP verknüpft Attribute im LDAP-Katalog mit Attributen in CMS. Die spezifischen Attribute sind:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Beschreibung der AttributeJID ist die Benutzeranmeldekennung im CMS. Da dies ein LDAP-Server von Microsoft Active Directory ist, wird die JID im CMS mit sAMAccountName im LDAP verknüpft, was im Wesentlichen die Anmeldekennung des Benutzers im Active Directory darstellt. Beachten Sie außerdem, dass Sie sAMAccountName nehmen und die Domain conf.pod6.cms.lab anhängen, da dies der Anmeldekennung ist, die Ihre Benutzer zum Zugriff auf das CMS verwenden werden.

nameMapping verknüpft den Inhalt des Active Directory-Feldes displayName mit dem Namensfeld des CMS-Benutzers.

coSpaceNameMapping generiert den Namen des CMS-Space basierend auf dem Feld displayName. Dieses Attribut zusammen mit dem Attribut coSpaceUriMapping ist erforderlich, um einen Space für jeden Benutzer zu erstellen.

coSpaceUriMapping definiert den benutzerdefinierten Teil der URI, der mit dem persönlichen Space des Benutzers verknüpft ist. Einige Domains können für die Eingabe in den Space konfiguriert sein. Wenn der benutzerdefinierte Teil mit diesem Feld für eine dieser Domains übereinstimmt, wird der Aufruf an den Space dieses Benutzers weitergeleitet.

coSpaceSecondaryUriMapping definiert die zweite URI, um den Raum zu erreichen. Dies kann verwendet werden, um einen numerischen Alias für die Anrufweiterleitung in den Raum eines importierten Benutzers hinzuzufügen, alternativ zur alphanumerischen URI, die im Parameter coSpaceUriMapping definiert ist.

Der LDAP-Server und die LDAP-Zuordnung sind eingerichtet. Jetzt müssen sie miteinander verknüpft werden, indem eine LDAP-Quelle erstellt wird.

Zugriff über die URL verwenden cms01.example.com:445/api/v1/ldapSource erstellen wir ein LDAP-Source-Objekt und geben dabei Parameter wie an:

• server
• Mapping
• baseDn
• filter

Jetzt, da die LDAP-Konfiguration abgeschlossen ist, kann der manuelle Synchronisierungsprozess durchgeführt werden.

Dies erfolgt entweder über die Web-Oberfläche jedes Servers, indem Sie auf Jetzt synchronisieren im Bereich Active Directory


klicken oder über die API mit dem Befehl POST unter Verwendung der URL für den Zugriff cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc-Konferenzen

Was ist das?Im traditionellen Sinne ist eine Konferenz, wenn zwei Teilnehmer miteinander sprechen und einer der Teilnehmer (mithilfe eines Geräts, das bei Unified CM registriert ist) die Schaltfläche „Konferenz“ drückt, eine andere Person anruft und nach dem Gespräch mit dieser dritten Partei erneut die Schaltfläche „Konferenz“ drückt, um alle Teilnehmer der Dreierkonferenz zu verbinden.

Eine Ad-Hoc-Konferenz unterscheidet sich von einer geplanten Konferenz im CMS dadurch, dass eine Ad-Hoc-Konferenz nicht einfach ein SIP-Anruf für das CMS ist. Wenn der Initiator der Konferenz die Taste „Konferenz“ ein zweites Mal drückt, um alle zu demselben Treffen einzuladen, muss Unified CM einen API-Aufruf für das CMS ausführen, um die Konferenz „on the fly“ zu erstellen, auf die dann alle Anrufe weitergeleitet werden. All dies geschieht für die Teilnehmer unbemerkt.

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

Falls erforderlich, kann CUCM dynamisch einen Raum im CMS erstellen, damit jeder Anruf das CMS erreichen und der Regel für eingehende Anrufe entsprechen kann, die für den jeweiligen Raum vorgesehen ist.

Integration mit CUCM wird ebenso konfiguriert, wie im Artikel beschrieben zuvor außer dass auf Cisco UCM drei Trunks für das CMS, drei Conference Bridges erstellt werden müssen, im SIP Security Profile drei Subject Names angegeben werden, Route Group, Route List, Media Resource Group und Media Resource Group List konfiguriert werden, sowie einige Routing-Regeln im Cisco Meeting Server hinzugefügt werden müssen.

SIP Security Profile:


Trunks:


Jeder Trunk sieht gleich aus:




Conference Bridge


Jede Conference Bridge sieht gleich aus:


Routengruppe


Routenliste


Medienressourcengruppe


Liste der Medienressourcengruppen

Anrufregeln

Im Gegensatz zu fortschrittlicheren Anrufverwaltungssystemen wie Unified CM oder Expressway, überprüft CMS für neue Anrufe die Domain nur im SIP Request-URI-Feld. Wenn also SIP INVITE für sip:user@domain.com bestimmt ist, kümmert sich CMS nur um domain.com. CMS folgt diesen Regeln, um zu bestimmen, wohin der Anruf geleitet werden soll:

1. Zuerst versucht CMS, die SIP-Domain mit den in den Regeln für die Bearbeitung eingehender Anrufe konfigurierten Domains abzugleichen. Anschließend können diese Anrufe in ('Ziel-') Plätze oder spezifische Benutzer, interne IVRs oder direkt integrierte Empfänger von Microsoft Lync/Skype für Unternehmen (S4B) geleitet werden.
2. Wenn die Regeln für die Verarbeitung eingehender Anrufe nicht übereinstimmen, versucht das CMS, die in der Anrufumleitungstabelle konfigurierte Domain zuzuordnen. Wenn eine Zuordnung hergestellt wird, kann die Regel den Anruf ausdrücklich ablehnen oder umleiten. Zu diesem Zeitpunkt kann das CMS die Domain umschreiben, was manchmal für Anrufe zu Lync-Domains hilfreich ist. Sie können auch 'Pass Throw' wählen, was bedeutet, dass keines der Felder weiter verändert wird, oder die interne Teilnehmergruppe des CMS verwenden. Wenn es keine Übereinstimmungen in den Anrufumleitungsregeln gibt, wird standardmäßig der Anruf abgelehnt. Bitte beachten Sie, dass auch wenn der Anruf im CMS 'umgeleitet' wird, das Multimedia weiterhin mit dem CMS verbunden bleibt, was bedeutet, dass es weiterhin Teil des Signalisierungs- und Multimedia-Traffics sein wird.
Nur umgeleitete Anrufe unterliegen dann den Regeln für ausgehende Anrufe. Diese Einstellungen bestimmen die Empfänger, an die Anrufe gesendet werden, die Art der Verbindungsleitung (ob es sich um einen neuen Lync-Anruf oder einen Standard-SIP handelt) und alle Umwandlungen, die möglicherweise durchgeführt werden, wenn in der Anrufumleitungsregel keine Übertragung ausgewählt wurde.

Hier ist das Protokoll dessen, was während der Ad-Hoc-Konferenz passiert.

Auf dem Screenshot ist es schlecht zu erkennen (ich weiß nicht, wie ich es besser machen kann), daher schreibe ich das Protokoll so:

Info	127.0.0.1:35870: API-Benutzer "api" hat neuen Raum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012) erstellt.

Info	Aufruf von create gescheitert, CoSpace nicht gefunden – versuche auf Datenbank zuzugreifen.

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  Intern.

Info	127.0.0.1:35872: API-Benutzer "api" hat neuen Anruf 93bfb890-646c-4364-8795-9587bfdc55ba erstellt.

Info	Anruf 7: Eingehender SIP-Anruf von "sip:672@172.x.x.x" zu lokaler URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com".

Info	API-Anrufbeine bc0be45e-ce8f-411c-be04-594e0220c38e im Anruf 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-Anruf 93bfb890-646c-4364-8795-9587bfdc55ba).

Info	Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 hat Kontroll-/Medien-GUID: fb587c12-23d2-4351-af61-d6365cbd648d.

Info	Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 mit dem Namen "001036270012".

Info	Anruf 7: konfiguriert - API-Anrufbein bc0be45e-ce8f-411c-be04-594e0220c38e mit SIP-Anruf-ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x".

Info	Anruf 7: UDT RTP-Sitzung für DTLS (kombinierte Medien- und Steuerungssitzung) wird eingerichtet.
Info	Konferenz "001036270012": unverschlüsselte Anrufbeine sind jetzt vorhanden.

Info	Teilnehmer "672@172.x.x.x" hat Raum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012) betreten.

Info	Teilnehmer "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) hat an Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 über SIP teilgenommen.

Info	Anruf 8: Eingehender SIP-Anruf von "sip:690@172.x.x.x" zu lokaler URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com".

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

Info	Anruf 8: konfiguriert - API-Anrufbein db61b242-1c6f-49bd-8339-091f62f5777a mit SIP-Anruf-ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x".

Info	Anruf 8: UDT RTP-Sitzung für DTLS (kombinierte Medien- und Steuerungssitzung) wird eingerichtet.

Info	Anruf 9: Eingehender SIP-Anruf von "sip:673@172.x.x.x" zu lokaler URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com".

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

Info	Anruf 9: konfiguriert - API-Anrufbein 37a6e86d-d457-47cf-be24-1dbe20ccf98a mit SIP-Anruf-ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x".

Info	Anruf 9: UDT RTP-Sitzung für DTLS (kombinierte Medien- und Steuerungssitzung) wird eingerichtet.
Info	Anruf 8: Kompensation für nicht passende Payload-Typen auf der anderen Seite.

Info	Teilnehmer "690@172.x.x.x" hat Raum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012) betreten.

Info	Teilnehmer "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) hat an Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 über SIP teilgenommen.

Info	Anruf 7: Kompensation für nicht passende Payload-Typen auf der anderen Seite.
Info	Anruf 8: nicht passende Payload-Typen-Modus 1/0.
Info	Anruf 8: Angebot im nicht passenden Payload-Typenmodus wird angenommen.
Info	Anruf 8: Folgeangebot für einen einzelnen Codec erhalten.
Info	Anruf 8: nicht passende Payload-Typen-Modus 1/0.
Info	Anruf 8: Angebot im nicht passenden Payload-Typenmodus wird angenommen.
Info	Anruf 8: Antwort auf zusätzliches Angebot für einen einzelnen Codec wird gesendet.
Info	Anruf 9: Kompensation für nicht passende Payload-Typen auf der anderen Seite.

Info	Teilnehmer "673@172.x.x.x" hat Raum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012) betreten.

Info	Teilnehmer "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) hat an Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 über SIP teilgenommen.

Info	Anruf 9: BFCP (Client-Rolle) jetzt aktiv.
Info	Anruf 9: BFCP-Hello wird als Client gesendet, nachdem das Hello empfangen wurde, als BFCP nicht aktiv war.
Info	Anruf 9: BFCP (Client-Rolle) jetzt aktiv.
Info	Anruf 7: beendet; remote SIP-Abbau - verbunden für 0:13.
Info	Anruf 7: API-Anrufbein bc0be45e-ce8f-411c-be04-594e0220c38e wird zerstört.

Info	Teilnehmer "672@x.x.x" hat Raum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012) verlassen.

Info	Anruf 9: in Wartestellung.
Info	Anruf 9: nicht passende Payload-Typen-Modus 1/0.
Info	Anruf 9: Antwort im nicht passenden Payload-Typenmodus.
Info	Anruf 8: in Wartestellung.
Info	Anruf 8: Folgeangebot für einen einzelnen Codec erhalten.
Info	Anruf 8: nicht passende Payload-Typen-Modus 1/0.
Info	Anruf 8: Angebot im nicht passenden Payload-Typenmodus wird angenommen.
Info	Anruf 8: Antwort auf zusätzliches Angebot für einen einzelnen Codec wird gesendet.
Info	Anruf 9: beendet; remote SIP-Abbau - verbunden für 0:12.

Die Ad-Hoc-Konferenz:


Regeln für eingehende Anrufe
Die Konfiguration der Parameter für eingehende Anrufe ist notwendig, um Anrufe in der CMS zu empfangen. Wie Sie in der LDAP-Konfiguration gesehen haben, wurden alle Benutzer mit der Domain conf.pod6.cms.lab importiert. Daher sollten Anrufe für diese Domain mindestens für die Spaces bestimmt sein. Außerdem müssen Sie Regeln für alles festlegen, was für den vollständigen Domänennamen (und möglicherweise sogar für die IP-Adresse) jedes der CMS-Server bestimmt ist. In unserer externen Anrufsteuerung, Unified CM, werden die SIP-Trunks für jeden CMS-Server einzeln konfiguriert. Je nachdem, ob die Zuordnung dieser SIP-Trunks eine IP-Adresse oder den vollständigen Domänennamen des Servers betrifft, wird entschieden, ob das CMS für den Empfang von Anrufen, die an seine IP-Adresse oder den vollständigen Domänennamen gerichtet sind, eingerichtet werden muss.

Die Domain mit der Regel für eingehenden Traffic mit der höchsten Priorität wird als Domain für alle benutzerdefinierten Spaces verwendet. Wenn Benutzer über LDAP synchronisiert werden, erstellt das CMS automatisch Spaces, jedoch nur den benutzerdefinierten Teil der URI (coSpaceUriMapping), z.B. user.space. Der Teil domain Die vollständige URI wird auf der Grundlage dieser Regel erstellt. Wenn Sie zu diesem Zeitpunkt auf Web Bridge zugreifen würden, würden Sie sehen, dass der Space URI keine Domäne hat. Indem Sie diese Regel zur höchsten Priorität erheben, legen Sie die Domäne für die generierten Spaces fest als conf.example.com.


Regeln für ausgehende Anrufe

Um Benutzern zu ermöglichen, ausgehende Anrufe im Unified CM Cluster zu tätigen, müssen die Regeln für ausgehende Verbindungen konfiguriert werden. Die Domäne der Endpunkte, die im Unified CM registriert sind, wie Jabber, lautet example.com. Anrufe in diese Domäne sollten als Standard-SIP-Anrufe an die Verarbeitungsserver des Unified CM geleitet werden. Der Hauptserver ist cucm-01.example.com, der sekundäre cucm-02.example.com.

Die erste Regel beschreibt die einfachste Anrufweiterleitung zwischen den Servern des Clusters.

Feld Local von Domain verantwortet, was im SIP-URI des Anrufers bei dem Angerufenen nach dem Zeichen „@“ angezeigt wird. Wenn wir dieses Feld leer lassen, wird nach dem Zeichen „@“ die IP-Adresse des CUCM angezeigt, über die dieser Anruf geleitet wird. Wenn wir jedoch eine Domain angeben, wird nach dem Zeichen „@“ tatsächlich die Domain erscheinen. Dies ist erforderlich, um die Möglichkeit zu haben, zurückzurufen; andernfalls wird es nicht möglich sein, über den SIP-URI name@ip-Adresse zurückzutelefonieren.

Anruf, wenn angegeben Local von Domain


Anruf, wenn sind als Local von Domain


Bitte geben Sie unbedingt an, ob es sich um Encrypted oder Unencrypted Anrufe handelt, denn bei der Option Auto funktioniert nichts.

Aufzeichnung

Die Aufnahme von Videokonferenzen erfolgt durch den Record-Server. Der Recorder ist im Grunde genau derselbe wie der Cisco Meeting Server. Der Recorder benötigt keine Lizenzen auf seinem System. Lizenzen für die Aufnahme sind für die Server erforderlich, auf denen die CallBridge-Dienste ausgeführt werden, d.h. die Recording-Lizenz ist notwendig und sollte auf die CallBridge-Komponente und nicht auf den Server, auf dem der Recorder läuft, angewendet werden. Der Recorder verhält sich wie ein Client des extensiblen Protokolls für Messaging und Präsenz (XMPP), daher muss der XMPP-Server auf dem Server aktiviert sein, auf dem die CallBridge gehostet wird.

Da wir ein Cluster haben, muss die Lizenz auf alle drei Server des Clusters "aufgeteilt" werden. Daher verknüpfen wir einfach im persönlichen Bereich unter Lizenzen die MAC-Adressen der a-Schnittstellen aller CMS-Server, die zum Cluster gehören.

Und so sollte das Bild auf jedem Server des Clusters aussehen.

Es gibt mehrere Szenarien für die Platzierung des Recorders, aber wir werden uns an folgendes halten:


Bevor Sie den Recorder konfigurieren, muss ein Platz vorbereitet werden, wo die Videozeitzahlen aufgezeichnet werden. Hier ist er: Link, wie Sie die gesamte Aufnahme einrichten. Ich werde auf wichtige Punkte und Details eingehen:

1. Es ist besser, das Zertifikat vom ersten Server im Cluster zu verwenden.
2. Der Fehler "Recorder unavailable" kann auftreten, weil das falsche Zertifikat im Recorder-Vertrauensbereich angegeben wurde.
3. Die Aufnahme kann nicht erfolgen, wenn das Wurzelverzeichnis im NFS nicht angegeben ist.

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

Dazu werden zwei CallProfile erstellt:
Mit deaktivierter Aufnahmefunktion.


Und mit automatischer Aufnahmefunktion.


Anschließend "verbinden" wir das benötigte CallProfile mit automatischer Aufnahmefunktion mit dem gewünschten Raum.


Im CMS ist es so geregelt, dass ein CallProfile, wenn es eindeutig an bestimmte Spaces gebunden ist, nur für diese spezifischen Spaces funktioniert. Ist das CallProfile jedoch nicht mit einem Space verbunden, so wird es standardmäßig für die Spaces angewendet, mit denen kein CallProfile eindeutig verbunden ist.

Beim nächsten Mal werde ich beschreiben, auf welchen Wegen der Zugriff auf das CMS außerhalb des internen Netzwerks der Organisation erfolgt.

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

Quelle: habr.com