In dieser Ausgabe werde ich einige Feinheiten bei der Konfiguration des CMS-Servers im Modus eines ausfallsicheren Clusters zeigen und erklären.
TheorieEs gibt insgesamt drei Typen der Bereitstellung eines CMS-Servers:
- Single Combined(Einzelnes Kombiniertes) bedeutet, dass es sich um einen Server handelt, auf dem alle erforderlichen Dienste ausgeführt werden. In den meisten Fällen ist dieser Bereitstellungstyp nur für den Zugriff interner Kunden und in kleinen Umgebungen anwendbar, bei denen die Skalierbarkeit und Redundanz eines einzelnen Servers kein kritisches Problem darstellt oder in Situationen, in denen das CMS nur bestimmte Funktionen erfüllt, wie spezielle Konferenzen auf Cisco UCM.
Ein schematisches Beispiel zur Funktionsweise:
- Single Split(Einzelnes Geteiltes) erweitert den vorherigen Bereitstellungstyp, indem ein separater Server für den externen Zugang hinzugefügt wird. In veralteten Bereitstellungen bedeutete dies, einen CMS-Server im demilitarisierten Segment des Netzwerks (DMZ) bereitzustellen, auf den externe Kunden zugreifen konnten, und einen CMS-Server im Kern des Netzwerks, auf den interne Kunden Zugriff haben. Dieses spezifische Bereitstellungsmodell wird nun von dem so genannten Typ Single Edge, der aus Servern besteht, Cisco Expressway, die entweder über viele der Firewall-Umgehungsfunktionen verfügen oder diese bald erhalten werden, sodass den Kunden kein spezieller CMS-Grenzserver hinzugefügt werden muss.
Ein schematisches Beispiel zur Funktionsweise:
- Scalable and Resilient(Skalierbar und Ausfallsicher) umfasst diese Art Redundanz für jede Komponente, die es dem System ermöglicht, mit Ihren Bedürfnissen bis zur maximalen Kapazität zu wachsen und dabei eine Redundanz im Falle eines Fehlers zu gewährleisten. Es verwendet auch das Konzept des Single Edge, um einen sicheren externen Zugriff zu gewährleisten. Dies ist der Typ, den wir in dieser Ausgabe betrachten werden. Wenn wir verstehen, wie wir einen Cluster dieses Typs bereitstellen können, verstehen wir nicht nur andere Bereitstellungstypen, sondern können auch Cluster von CMS-Servern mit Blick auf das potenzielle Wachstum der Anforderungen erstellen.
Bevor wir zur Bereitstellung übergehen, müssen wir einige grundlegende Dinge verstehen, nämlich
Die Hauptsoftwarekomponenten des CMS:
- Datenbank: ermöglicht das Zusammenfassen bestimmter Konfigurationen wie Abonnentengruppen, Benutzerbereiche und selbst die Benutzer. Unterstützt Clusterbildung nur für hohe Verfügbarkeit (ein Master).
- Call Bridge: Dienst für Audio- und Videokonferenzen, der die vollständige Kontrolle über das Management und die Verarbeitung von Anrufen und Multimedia-Prozessen ermöglicht. Unterstützt die Clusterbildung für hohe Verfügbarkeit und Skalierbarkeit.
- XMPP-Server: Verantwortlich für die Registrierung und Authentifizierung von Clients, die die Cisco Meeting Application und/oder WebRTC verwenden (Echtzeitkommunikation, oder einfach im Browser), sowie für die interkomponentale Signalgebung. Kann nur für hohe Verfügbarkeit geclustert werden.
- Web Bridge: Bietet Clients Zugang zu WebRTC.
- Loadbalancer: Stellt einen einzigen Verbindungspunkt für Anwendungen der Cisco Meeting App im Single Split-Modus bereit. Überwacht das externe Interface und den Port für eingehende Verbindungen. Der Load Balancer akzeptiert gleichsam eingehende TLS-Verbindungen vom XMPP-Server, über die er TCP-Verbindungen von externen Clients umschalten kann.
In unserem Szenario wird er nicht benötigt. - TURN-Server: Bietet eine Technologie zum Umgehen von Firewalls, die es ermöglicht,
unser CMS hinter der Firewall oder NAT sichtbar zu machen, um externe Clients, die die Cisco Meeting App oder SIP-Geräte verwenden, zu verbinden. In unserem Szenario wird er nicht benötigt. - Web Admin: Administrationsoberfläche und Zugriff auf die API, einschließlich für spezielle Konferenzen mit Unified CM.
Konfigurationsmodi
Im Gegensatz zu den meisten anderen Cisco-Produkten unterstützt Cisco Meeting Server drei Methoden zur Konfiguration, die eine Bereitstellung jeder Art ermöglichen.
- Befehlszeile (CLI): Befehlszeileninterface, bekannt als MMP, für Aufgaben der اولیهinstellung und Zertifikate.
- Web-Administrator: Vor allem für die Konfiguration im Zusammenhang mit CallBridge, insbesondere bei der Einrichtung eines nicht geclusterten Servers.
- REST API: Wird für die komplexesten Konfigurationsaufgaben und solche, die mit der Cluster-Datenbank verbunden sind, verwendet.
Zusätzlich zu den oben genannten wird das Protokoll SFTP zum Übertragen von Dateien verwendet – normalerweise Lizenzen, Zertifikate oder Protokolle – auf den CMS-Server und von diesem.
In den Deployment-Leitfäden von Cisco steht deutlich geschrieben, dass ein Cluster mindestens aus drei Servern (Nodes) im Kontext von Datenbanken bestehen muss. Da nur mit einer ungeraden Anzahl von Knoten der Mechanismus zur Auswahl eines neuen Datenbankmasters funktioniert, und der Master-Datenbank auch mit dem Großteil der Datenbank des CMS-Servers verbunden ist.
Wie die Praxis zeigt, sind zwei Server (Nodes) tatsächlich nicht ausreichend. Der Auswahlmechanismus funktioniert bei einem Neustart des Masters, der Slave-Server wird nur dann zum Master, wenn der neu gestartete Server hochgefahren ist. Wenn jedoch der Master-Server im Cluster aus zwei Servern plötzlich „ausfällt“, wird der Slave-Server nicht zum Master, und wenn der Slave ausfällt, wird der verbliebene Master-Server zum Slave.
Im Kontext von XMPP sollte man in der Tat einen Cluster aus drei Servern aufbauen, denn wenn beispielsweise der XMPP-Dienst auf einem der Server, der im Status Leader ist, abgeschaltet wird, bleibt der verbleibende Server im Status Follower, und die Verbindungen von CallBridge zu XMPP fallen aus, da CallBridge sich ausschließlich zu XMPP im Status Leader verbindet. Das ist kritisch, denn kein Anruf wird durchkommen.
Auch in diesen Deployment-Guides wird ein Cluster mit einem XMPP-Server demonstriert.
In Anbetracht dessen 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, der wahrscheinlich in Ihrer Infrastruktur vorhanden ist oder mit hoher Wahrscheinlichkeit vorhanden sein wird. Alternativ könnte die Domain example.com derselbe Domain entsprechen, den die Benutzer für ihre E-Mail-Adressen verwenden. Oder der Jabber-Client auf Ihrem Laptop könnte die URI user@example.com haben. Die Domain conf.example.com ist die Domain, die für die Benutzer des Cisco Meeting Servers konfiguriert wird. Die Domain des Cisco Meeting Servers wird conf.example.com sein, daher muss der Benutzer Jabber für den Zugang zum Cisco Meeting Server die URI user@conf.example.com verwenden.
Basis-Konfiguration
Alle nachfolgend beschriebenen Einstellungen werden auf einem Server angezeigt, müssen jedoch auf jedem Server im Cluster durchgeführt werden.
QoS
Da CMS generiert Echtzeit Verkehr, der empfindlich auf Verzögerungen und Paketverluste reagiert, sollte in den meisten Fällen durch Quality of Service (QoS) konfiguriert werden. Dazu unterstützt das CMS die Kennzeichnung von Paketen mit Differentiated Services Codes (DSCP), die es generiert. Obwohl die Priorisierung des Verkehrs basierend auf DSCP davon abhängt, wie der Verkehr von den Netzwerkkomponenten Ihrer Infrastruktur verarbeitet wird, konfigurieren wir in unserem Fall unser CMS mit einer typischen Verteilung der DSCP-Prioritäten basierend auf den besten QoS-Praktiken.
Auf jedem Server geben wir die folgenden Befehle ein
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ASomit wurde der gesamte Videoverkehr mit AF41 (DSCP 0x22) markiert, der gesamte Sprachverkehr mit EF (DSCP 0x2E) und andere Arten von latenzarmen Verkehr, wie SIP und XMPP, verwenden AF31 (DSCP 0x1A).
Überprüfen:
NTP
Das Network Time Protocol (NTP) ist nicht nur wichtig für die Bereitstellung genauer Zeitstempel für Anrufe und Konferenzen, sondern auch für die Überprüfung von Zertifikaten.
Wir fügen die NTP-Server Ihrer Infrastruktur mit einem Befehl der Art hinzu
ntp server add In unserem Fall gibt es zwei solcher Server, daher wird es zwei Befehle geben.
Überprüfen:
Und wir setzen die Zeitzone für unseren Server.
DNS
DNS-Server fügen wir im CMS mit einem Befehl der Art hinzu:
dns add forwardzone In unserem Fall gibt es zwei solcher Server, daher wird es zwei Befehle geben.
Überprüfen:
Konfiguration des Netzwerkinterfaces
Wir konfigurieren das Interface mit einem Befehl der Art:
ipv4 add / Überprüfen:
Servername (Hostname)
Den Servernamen setzen wir mit einem Befehl der Art:
hostname Und wir starten neu.
Damit ist die grundlegende Konfiguration abgeschlossen.
Zertifikate
TheorieCisco Meeting Server erfordert eine verschlüsselte Kommunikation zwischen verschiedenen Komponenten, und daher sind X.509-Zertifikate für alle CMS-Bereitstellungen erforderlich. Sie helfen, Vertrauen zwischen den Diensten/Servern und anderen Servern/Diensten herzustellen.
Für jeden Dienst ist ein Zertifikat erforderlich, jedoch kann die Erstellung separater Zertifikate für jeden Dienst zu Verwirrung und unnötiger Komplexität führen. Glücklicherweise können wir ein Paar von privaten und öffentlichen Schlüsseln eines Zertifikats generieren und diese 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 wir für jeden Server im Cluster ein Paar von öffentlichen und privaten Schlüsseln eines Zertifikats erstellen.
Die Clusterbildung einer Datenbank hat jedoch einige spezielle Anforderungen an die Zertifikate und erfordert daher eigene Zertifikate, die sich von denen anderer Dienste unterscheiden. Das CMS verwendet ein Serverzertifikat, das ähnlich ist wie die Zertifikate, die von anderen Servern verwendet werden, jedoch gibt es auch ein Clientzertifikat, das für Verbindungen zur Datenbank verwendet wird. Die Zertifikate der Datenbank werden sowohl für die Authentifizierung als auch für die Verschlüsselung verwendet. Anstatt einen Benutzernamen und ein Passwort zur Verbindung des Clients mit der Datenbank bereitzustellen, repräsentiert der Client ein Clientzertifikat, dem der Server vertraut. Jeder Server im Datenbankcluster wird dasselbe Paar aus öffentlichem und privatem Schlüssel verwenden. Dies ermöglicht es allen Servern im Cluster, Daten so zu verschlüsseln, dass sie nur von anderen Servern entschlüsselt werden können, die ebenfalls dasselbe Schlüsselpaar verwenden.
Damit die Sicherung funktioniert, müssen Datenbankcluster aus mindestens 3 Servern bestehen, jedoch nicht mehr als 5, mit einer maximalen Signalverzögerung in beide Richtungen von 200 ms zwischen beliebigen Mitgliedern des Clusters. Diese Grenze ist restriktiver als bei der Clusterbildung von Call Bridge, weshalb sie oft ein begrenzender Faktor bei geografisch verteilten Implementierungen ist.
Die Rolle der Datenbank für das CMS bringt eine Reihe einzigartiger Anforderungen mit sich. Im Gegensatz zu anderen Rollen benötigt es sowohl ein Client- als auch ein Serverzertifikat, wobei das Clientzertifikat ein bestimmtes CN-Feld hat, das dem Server präsentiert wird.
Das CMS verwendet eine PostgreSQL-Datenbank mit einem Hauptserver und mehreren vollständig identischen Replikaten. Zu jedem Zeitpunkt gibt es nur eine Hauptdatenbank („Datenbank-Server“). Die anderen Mitglieder des Clusters sind Replikate oder „Datenbank-Clients“.
Für den Datenbankcluster werden ein dedizierter Serverzertifikat und ein Clientzertifikat benötigt. Diese müssen von Zertifikaten, üblicherweise von einer internen privaten Zertifizierungsstelle, signiert sein. Da jeder der Cluster-Mitglieder der Datenbank Haupt werden kann, müssen die Paare von Serverzertifikaten und Clientzertifikaten (die öffentliche und private Schlüssel enthalten) auf alle Server kopiert werden, damit sie die Identität des Clients oder Servers der Datenbank annehmen können. Außerdem muss das Root-Zertifikat der CA hochgeladen werden, um sicherzustellen, dass die Client- und Serverzertifikate überprüft werden können.
Lass uns also einen Antrag auf Zertifikat erstellen, der von allen Serverdiensten bis auf die Datenbank verwendet wird (für diesen wird es eine gesonderte Anfrage geben) mit folgendem Befehl:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Im CN schreiben wir den generischen Namen unserer Server. Zum Beispiel, wenn die Hostnamen unserer Server server01, server02, server03, dann wird der CN server.example.com
Das Gleiche machen wir auf den verbleibenden zwei Servern, mit dem Unterschied, dass in den Befehlen die entsprechenden «Hostnamen» enthalten sein werden.
Wir erstellen zwei Anträge für Zertifikate, die vom Dienst der Datenbank verwendet werden, mit folgenden Befehlen:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreswo dbclusterserver und dbclusterclient Namen unserer Anträge und zukünftigen Zertifikate, hostname1(2)(3) Namen der entsprechenden Server.
Dieses Verfahren führen wir nur auf einem Server aus(!), und die Zertifikate sowie die entsprechenden .key-Dateien laden wir auf die anderen Server hoch.
Aktivierung des Client-Zertifikatsmodus in AD CS
Wir müssen außerdem die Zertifikate für jeden Server in eine Datei zusammenführen.In *NIX:
cat server01.cer server02.cer server03.cer > server.cerIn Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer Und hochladen auf jeden Server:
1. „Individuelles“ Serverzertifikat.
2. Root-Zertifikat (einschließlich der Zwischenzertifikate, falls vorhanden).
3. Zertifikate für die Datenbank („Server“- und „Client“-Zertifikat) sowie die .key-Dateien, die beim Erstellen der Anfrage für das „Server“- und „Client“-Zertifikat für die Datenbank entstanden sind. Diese Dateien müssen auf allen Servern identisch sein.
4. Datei mit allen drei „individuellen“ Zertifikaten.
Am Ende sollte sich auf jedem Server ein ähnliches Dateibild ergeben.
Datenbankcluster
Jetzt, da Sie alle Zertifikate auf die CMS-Server hochgeladen haben, können Sie die Datenbank-Clustering zwischen drei Knoten einrichten und aktivieren. Der erste Schritt besteht darin, einen Server als Hauptknoten des Datenbankclusters auszuwählen und ihn vollständig einzurichten.
Master-Datenbank
Der erste Schritt bei der Einrichtung der Datenbankreplikation besteht darin, die Zertifikate anzugeben, die für die Datenbank verwendet werden sollen. Dies erfolgt mit einem Befehl in der Form:
datenbank cluster certsJetzt geben wir dem CMS an, welches Interface für das Datenbankclustering verwendet werden soll, mit dem Befehl:
datenbank cluster localnode aDann initialisieren wir die Cluster-Datenbank auf dem Hauptserver mit dem Befehl:
datenbank cluster initialize
Client-Datenbankknoten
Wir führen das gleiche Verfahren durch, nur dass wir anstelle des Befehls datenbank cluster initialize einen Befehl in der Form eingeben:
datenbank cluster joinwobei die ip address existing master die IP-Adresse des CMS-Servers ist, auf dem die Clusterinitialisierung durchgeführt wurde, einfach Master.
Wir überprüfen, wie unser Datenbankcluster auf allen Servern funktioniert, mit dem Befehl:
datenbank cluster status
Das gleiche machen wir auch auf dem verbleibenden dritten Server.
Am Ende ist unser erster Server der Master, die anderen sind Slaves.
Web-Admin-Dienst
Wir aktivieren den Web-Administrationsdienst:
webadmin listen a 445Port 445 wurde gewählt, da Port 443 für den Benutzerzugriff auf den Web-Client verwendet wird.
Wir konfigurieren den Web-Admin-Dienst mit den Zertifikatdateien, mit einem Befehl in der Form:
webadmin certsUnd aktivieren den Web-Admin mit dem Befehl:
webadmin enable 
Wenn alles gut läuft, erhalten wir die SUCCESS-Zeilen, die angeben, dass der Web-Admin korrekt für das Netzwerk und das Zertifikat konfiguriert ist. Wir überprüfen die Funktionsfähigkeit des Dienstes mit einem Webbrowser und geben die Adresse des Web-Administrators ein, zum Beispiel: :445
Call Bridge Cluster
Call Bridge ist der einzige Dienst, der in jedem CMS-Deployment vorhanden ist. Call Bridge ist der Hauptmechanismus für Konferenzverbindungen. Es bietet auch eine SIP-Schnittstelle, sodass Anrufe an ihn oder von ihm geleitet werden können, beispielsweise mit Cisco Unified CM.
Die nachfolgend beschriebenen Befehle müssen auf jedem Server mit den entsprechenden Zertifikaten ausgeführt werden.
Also:
Wir verknüpfen die Zertifikate mit dem Call Bridge-Dienst mit einem Befehl in der Form:
callbridge certs []Wir binden die CallBridge-Dienste an die gewünschte Schnittstelle mit dem Befehl:
callbridge listen aUnd wir starten den Dienst mit dem Befehl:
callbridge restart 
Jetzt, da wir die Call Bridges eingerichtet haben, können wir die Call Bridge-Klusterung konfigurieren. Die Call Bridge-Klusterung 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, wodurch Konferenzen aktiv auf die Call Bridge-Server mit einer intelligenten Anrufverteilung verteilt werden können. CMS hat zusätzliche Funktionen, Call Bridge-Gruppen und damit verbundene Funktionen, die zur weiteren Verwaltung genutzt werden können.
Die Konfiguration der Call Bridge-Klusterung erfolgt hauptsächlich über die Web-Administrator-Schnittstelle
Die im Folgenden beschriebene Prozedur ist auf jedem Server des Clusters durchzuführen.
Also,
1. Melden Sie sich über das Web bei Configuration > Cluster an.
2. Bei Call Bridge identity geben Sie als eindeutige Bezeichnung callbridge[01,02,03] entsprechend dem Namen des Servers ein. Diese Namen sind willkürlich, müssen jedoch für dieses Cluster eindeutig sein. Sie sind beschreibend, da sie darauf hinweisen, dass es sich um die Identifizierer der Server [01,02,03] handelt.
3. Bei Clustered Call Bridges geben Sie die URLs der Web-Administratoren unserer Server im Cluster ein, [01,02,03].example.com:445, im Feld Adresse. Stellen Sie sicher, dass Sie den Port angeben. Sie können das Feld Peer link SIP domain leer lassen.
4. Fügen Sie dem CallBridge jedes Serverzertifikat 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 clusterUnd wir starten den Dienst mit dem Befehl:
callbridge restart 
Am Ende sollte jeder Server folgendes Bild aufweisen:
XMPP-Cluster
Der XMPP-Dienst in CMS wird verwendet, um alle Registrierungen und Authentifizierungen für Cisco Meeting Apps (CMA) zu verarbeiten, 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 Ausfallsicherheit von XMPP ist eine Funktion, die in Produktionsumgebungen ab 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 die Zertifikate mit dem XMPP-Dienst mit einem Befehl wie:
xmpp certs []Definieren Sie dann die Listening-Schnittstelle mit dem Befehl:
xmpp listen aFür den XMPP-Dienst wird eine einzigartige Domain benötigt. Dies ist der Login für die Benutzer. Anders ausgedrückt, wenn ein Benutzer sich über die CMA-App (oder über einen WebRTC-Client) anmelden möchte, gibt er userID@logindomain ein. In unserem Fall wird das userid@conf.example.com sein. Warum nicht einfach example.com? In unserer speziellen Bereitstellung haben wir unsere Unified CM-Domain gewählt, die Jabber-Benutzer in Unified CM verwenden, wie example.com, daher benötigen wir eine andere Domain für die CMS-Benutzer, um Anrufe zu CMS zu routen und von CMS über SIP-Domains.
Konfigurieren Sie die XMPP-Domain mit dem Befehl:
xmpp domainUnd aktivieren Sie den XMPP-Dienst mit dem Befehl:
xmpp enableIm XMPP-Dienst müssen Anmeldeinformationen für jede Call Bridge erstellt werden, die bei der Registrierung im XMPP-Dienst verwendet werden. Diese Namen sind beliebig (und nicht mit den einzigartigen Namen verbunden, die Sie für das Clustering der Call Bridges konfiguriert haben). Auf einem XMPP-Server müssen drei Call Bridges hinzugefügt werden, und dann müssen diese Anmeldeinformationen auf anderen XMPP-Servern im Cluster eingegeben werden, da diese Konfiguration nicht in die Cluster-Datenbank eingegeben wird. Später werden wir jede Call Bridge so konfigurieren, dass sie diesen Namen und das Geheimnis für die 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 konfigurieren. Jeder Registrierung wird ein zufälliges Passwort zugewiesen. Später werden diese auf anderen Call Bridge-Servern eingegeben, 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Überprüfen Sie schließlich, was herausgekommen ist, mit dem Befehl:
xmpp callbridge list 
Das gleiche Bild sollte nach den unten beschriebenen Aktionen auf den anderen Servern zu sehen 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 callbridge03Das Geheimnis wird sehr sorgfältig hinzugefügt, damit nicht versehentlich zusätzliche Leerzeichen enthalten sind.
Am Ende sollten auf jedem Server die gleichen Einstellungen vorhanden sein:
Als nächstes geben wir auf allen Servern im Cluster die Vertrauensdatei an, die alle drei zuvor erstellten Zertifikate enthält, mit dem Befehl:
xmpp cluster trustAktivieren Sie den XMPP-Cluster-Modus auf allen Cluster-Servern mit dem Befehl:
xmpp cluster enableAuf dem ersten Server des Clusters initiieren wir die Erstellung des XMPP-Clusters mit dem Befehl:
xmpp cluster initializeAuf den anderen Servern fügen wir den XMPP-Cluster mit dem Befehl hinzu:
xmpp cluster joinWir überprüfen auf jedem Server, ob die Erstellung des XMPP-Clusters erfolgreich war, mit den folgenden Befehlen:
xmpp status
xmpp cluster statusErster Server:
Zweiter Server:
Dritter Server:
Verbindung des Call Bridge mit XMPP
Jetzt, wo der XMPP-Cluster gestartet ist, müssen die Call Bridge-Dienste für die Verbindung zum XMPP-Cluster konfiguriert werden. Diese Konfiguration erfolgt über den Web-Administrator.
Wir gehen auf jedem Server zu Configuration > General und in das Feld Eindeutiger Call Bridge-Name geben die entsprechenden eindeutigen Call Bridge-Namen für den jeweiligen Server ein callbridge[01,02,03]. Im Feld Domain conf.example.ru und die entsprechenden Passwörter, die man abrufen kann
auf jedem Server des Clusters 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 Callbridge mit XMPP verbindet, können auf jedem Server unterschiedlich sein, da sie von den zurückgegebenen Werten bei der Abfrage des Datensatzes abhängen. _xmpp-component._tcp.conf.example.com Das hängt von den Prioritätseinstellungen für diesen DNS-Eintrag ab.
Dann gehen wir zu Status > General, um sicherzustellen, dass der Call Bridge-Dienst erfolgreich mit dem XMPP-Dienst verbunden ist.
Web Bridge
Auf jedem Server des Clusters aktivieren wir den Web Bridge-Dienst mit dem Befehl:
webbridge listen a:443Wir konfigurieren den Web Bridge-Dienst mit den Zertifikatdateien mit einem Befehl der Form:
webbridge certsWeb 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 enableDamit Call Bridge dem Web Bridge signalisiert, dass Verbindungen von Call Bridge vertrauenswürdig sind, verwenden Sie den Befehl:
webbridge trustwo dies eine Datei ist, die alle drei Zertifikate von jedem Server im Cluster enthält.
So sollte es auf jedem Server des Clusters aussehen.
Jetzt müssen wir einen Benutzer mit der Rolle „appadmin“ erstellen, den wir benötigen, damit wir unseren Cluster konfigurieren können (!), und nicht jeden Server des Clusters einzeln. Auf diese Weise werden die Einstellungen einmalig angewendet und gleichmäßig auf jeden Server übertragen.
Für die weitere Konfiguration verwenden wir .
Für die Authentifizierung wählen wir Basic im Abschnitt Autorisierung
Für das korrekte Senden von Befehlen an die CMS-Server muss die richtige Kodierung eingestellt werden.
Wir geben die Webbridge mit dem Befehl an. POST und dem Parameter url und mit dem Wert.
Im Webbridge selbst geben wir die erforderlichen Parameter an: Gastzugang, geschützter Zugang und weiteres.
Call Bridge Gruppen
Standardmäßig nutzt das CMS nicht immer die verfügbaren Ressourcen für die Konferenzkommunikation maximal effizient.
Bei einem Treffen mit drei Teilnehmern kann jeder Teilnehmer auf drei unterschiedlichen Call Bridge's sein. Damit diese drei Teilnehmer miteinander kommunizieren können, stellen die Call Bridge's automatisch Verbindungen zwischen allen Servern und Clients im gleichen Space her, sodass es aussieht, als wären alle Clients auf einem Server. Ein Nachteil davon ist, dass eine Konferenz mit 3 Personen jetzt 9 Medienports verbrauchen wird. Das ist offensichtlich eine ineffiziente Ressourcennutzung. Außerdem besteht der Standardmechanismus, wenn der Call Bridge tatsächlich überlastet ist, darin, weiterhin Anrufe entgegenzunehmen und den Teilnehmern dieses Call Bridge's Dienste mit geringerem Qualitätsniveau anzubieten.
Diese Probleme werden durch die Funktion Call Bridge Gruppe gelöst. Diese Funktion wurde in der Version 2.1 der Software Cisco Meeting Server eingeführt und erweitert, um die Lastverteilung sowohl für eingehende als auch für ausgehende Anrufe, Cisco Meeting App (CMA) einschließlich WebRTC-Teilnehmern, zu unterstützen.
Zur Lösung des Problems der Wiederverbindung wurden drei anpassbare Lastgrenzen für jeden Call Bridge eingeführt:
LoadLimit ist die maximale numerische Last für einen bestimmten Call Bridge. Jede Plattform hat einen empfohlenen Grenzwert für die Last, z.B. 96000 für CMS1000 und 1,25 GHz pro virtuellen Prozessor für die virtuelle Maschine. Verschiedene Anrufe verbrauchen je nach Auflösung und Bildrate des Teilnehmers eine bestimmte Menge an Ressourcen.
NewConferenceLoadLimitBasisPoints (Standardwert 50% loadLimit) – legt die Serverlastgrenze fest, ab der neue Konferenzen abgelehnt werden.
ExistingConferenceLoadLimitBasisPoints (Standardwert 80% des loadLimit) – der Wert der Serverlast, ab der Teilnehmer, die einer bestehenden Konferenz beitreten, abgelehnt werden.
Während diese Funktion zur Verteilung von Anrufen und Lastverteilung entwickelt wurde, können auch andere Gruppen wie TURN-Server, Web Bridge-Server und Aufzeichnungsgeräte für Call Bridge-Gruppen zugewiesen werden, sodass sie ebenfalls richtig gruppiert werden können, um eine optimale Nutzung zu gewährleisten. Wenn eines dieser Objekte nicht der Anrufgruppe zugewiesen ist, wird angenommen, dass sie allen Servern ohne besondere Priorität zur Verfügung stehen.
Diese Einstellungen werden hier konfiguriert: :445/api/v1/system/configuration/cluster
Als nächstes geben wir jedem Callbridge an, zu welcher Callbridge-Gruppe er gehört:
Erster Callbridge
Zweiter Callbridge
Dritter Callbridge
Auf diese Weise haben wir die Call Bridge-Gruppe für eine effektivere Nutzung der Ressourcen des Cisco Meeting Servers konfiguriert.
Benutzer aus Active Directory importieren
Der Web Admin-Dienst hat einen LDAP-Konfigurationsbereich, bietet jedoch keine komplexen Konfigurationsmöglichkeiten, und die Informationen werden nicht in der Cluster-Datenbank gespeichert. Daher muss die Konfiguration entweder manuell auf jedem Server über die Web-Oberfläche oder über die API durchgeführt werden, und um es uns "dreimal nicht schwer zu machen", werden wir die Daten über die API eingeben.
Mit der URL-Zugriffsadresse :445/api/v1/ldapServers erstellen wir ein LDAP-Server-Objekt, indem wir Parameter wie folgende angeben:
- IP-Adresse des Servers
- Portnummer
- Benutzername
- Passwort
- sicher
Ob Secure true oder false ausgewählt wird, hängt vom Port ab: 389 ist ungesichert, 636 gesichert.
Wir ordnen die LDAP-Quellparameter den Attributen im Cisco Meeting Server zu.
Die LDAP-Zuordnung verknüpft die Attribute im LDAP-Verzeichnis mit den Attributen im CMS. Die entsprechenden Attribute sind:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beschreibung der AttributeJID stellt die Anmeldekennung des Benutzers im CMS dar. Da es sich um einen Microsoft Active Directory LDAP-Server handelt, wird die JID im CMS mit dem sAMAccountName im LDAP verknüpft, der im Wesentlichen die Anmeldekennung für Active Directory des Benutzers ist. Bitte beachten Sie auch, dass Sie den sAMAccountName nehmen und die Domain conf.pod6.cms.lab an das Ende anhängen, da dies der Login ist, den Ihre Benutzer verwenden werden, um sich im CMS anzumelden.
nameMapping verknüpft, was im Feld displayName des Active Directory enthalten ist, mit dem Namensfeld des CMS-Benutzers.
coSpaceNameMapping erstellt den Namen des CMS-Raums basierend auf dem Feld displayName. Dieses Attribut zusammen mit dem Attribut coSpaceUriMapping ist erforderlich, um einen Raum für jeden Benutzer zu erstellen.
coSpaceUriMapping definiert den benutzerdefinierten Teil der URI, der mit dem persönlichen Space des Benutzers verbunden ist. Einige Domänen können eingerichtet werden, um einen Space zu setzen. Wenn der benutzerdefinierte Teil mit diesem Feld für eine dieser Domänen übereinstimmt, wird der Anruf an den Space dieses Benutzers weitergeleitet.
coSpaceSecondaryUriMapping definiert die zweite URI, um auf den Space zuzugreifen. Dies kann verwendet werden, um ein numerisches Pseudonym hinzuzufügen, um Anrufe in den Space eines importierten Benutzers alternativ zur alphanumerischen URI, die im Parameter coSpaceUriMapping festgelegt ist, zu routen.
LDAP-Server und LDAP-Mapping sind eingerichtet. Jetzt müssen sie miteinander verbunden werden, indem eine LDAP-Quelle erstellt wird.
Mit der URL-Zugriffsadresse :445/api/v1/ldapSource erstellen wir das LDAP-Source-Objekt und geben Parameter wie an:
- server
- Mapping
- baseDn
- filter
Jetzt, da die LDAP-Konfiguration abgeschlossen ist, kann der manuelle Synchronisierungsprozess ausgeführt werden.
Wir tun dies entweder über die Weboberfläche jedes Servers, indem wir auf Jetzt synchronisieren im Abschnitt Active Directory
oder über die API mit dem Befehl POST unter Verwendung der URL zur Zugriffs :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 (unter Verwendung eines bei Unified CM registrierten Geräts) die Schaltfläche 'Konferenz' drückt, einen anderen anruft und nach dem Gespräch mit diesem dritten Teilnehmer 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 die Ad-Hoc-Konferenz nicht einfach ein SIP-Anruf für das CMS ist. Wenn der Initiator der Konferenz die Schaltfläche 'Konferenz' ein zweites Mal drückt, um alle zu derselben Sitzung einzuladen, muss Unified CM einen API-Aufruf an das CMS durchführen, um die Konferenz 'on-the-fly' zu erstellen, in die dann alle Anrufe geleitet werden. All dies geschieht nahtlos für die Teilnehmer.
Das bedeutet, dass Unified CM die API-Anmeldeinformationen und die Adresse / den Port des WebAdmin-Dienstes sowie den SIP-Trunk direkt auf dem CMS-Server konfigurieren muss, um den Anruf fortzusetzen.
Bei Bedarf kann CUCM dynamisch Räume im CMS erstellen, damit jeder Anruf zum CMS gelangen und den eingehenden Anrufrichtlinien entsprechen kann, die für Räume vorgesehen sind.
Integration mit CUCM wird genauso konfiguriert, wie im Artikel beschrieben. Außer dass auf Cisco UCM drei Trunks für CMS, drei Conference Bridges erstellt werden müssen, im SIP Security Profile drei Subject Names angegeben werden müssen, Route Group, Route List, Media Resource Group und Media Resource Group List festgelegt werden müssen, und etwas Routing-Regeln im Cisco Meeting Server hinzugefügt werden müssen.
SIP-Sicherheitsprofil:
Trunks:
Jeder Trunk sieht gleich aus:
Conference Bridge
Jede Conference Bridge sieht gleich aus:
Route Group
Route List
Media Resource Group
Media Resource Group List
Anrufregeln
Im Gegensatz zu fortschrittlicheren Anrufmanagementsystemen wie Unified CM oder Expressway durchsucht CMS für neue Anrufe den Domain nur im Feld SIP Request-URI. Wenn SIP INVITE also für sip: user@domain.com bestimmt ist, kümmert sich CMS nur um domain.com. CMS folgt diesen Regeln zur Bestimmung, wohin der Anruf geleitet werden soll:
1. Zuerst versucht CMS, die SIP-Domain mit den in den Regeln für eingehende Anrufe konfigurierten Domains abzugleichen. Dann können diese Anrufe an ("Ziel-") Bereiche oder spezifische Benutzer, interne IVR oder direkt integrierte Empfänger von Microsoft Lync/Skype für Unternehmen (S4B) weitergeleitet werden.
2. Wenn in den Regeln für eingehende Anrufe keine Übereinstimmungen gefunden werden, versucht CMS, die in der Rufumleitungs-Tabelle konfigurierten Domains abzugleichen. Wenn eine Übereinstimmung gefunden wird, kann die Regel den Anruf explizit ablehnen oder weiterleiten. Zu diesem Zeitpunkt kann CMS die Domain umschreiben, was manchmal nützlich für Anrufe an Lync-Domains ist. Sie können auch die Option pass throw auswählen, was bedeutet, dass keines der Felder weiter verändert wird, oder die interne Teilnehmergruppe von CMS verwenden. Wenn es in den Rufumleitungsregeln keine Übereinstimmungen gibt, wird standardmäßig der Anruf abgelehnt. Beachten Sie, dass in CMS, obwohl der Anruf „weitergeleitet“ wird, die Multimedia weiterhin an CMS gebunden ist, was bedeutet, dass sie im Signal- und Multimedia-Verkehr bleibt.
Nur weitergeleitete Anrufe unterliegen dann den Regeln für ausgehende Anrufe. Diese Optionen bestimmen die Empfänger, an die Anrufe gesendet werden sollen, den Typ der Verbindungsleitung (ob es sich um einen neuen Lync-Anruf oder um Standard-SIP handelt) und alle Umwandlungen, die durchgeführt werden können, wenn im Rufumleitungsregel kein Durchgang ausgewählt wird.
Hier ist das tatsächliche Protokoll davon, was bei einer Ad-Hoc-Konferenz geschieht.
Auf dem Screenshot ist es schlecht zu sehen (ich weiß nicht, wie ich es besser machen kann), deshalb 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 Anruf Erstellung fehlgeschlagen, da coSpace nicht gefunden wurde -- versuche, es aus der Datenbank abzurufen.
Info API "001036270012" Raum GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 Anruf GUID: 93bfb890-646c-4364-8795-9587bfdc55ba Anruf Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 Intern G
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" zur lokalen URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-Anrufbeinhalt 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 mit Steuerung/Medien GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 mit dem Namen "001036270012"
Info Anruf 7: konfiguriert - API-Anrufbeinhalt 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 Steuerung) wird eingerichtet.
Info Konferenz "001036270012": unverschlüsselte Anrufbeinhälter 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 die Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 über SIP betreten.
Info Anruf 8: eingehender SIP-Anruf von "sip:690@172.x.x.x" zur lokalen URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-Anrufbeinhalt db61b242-1c6f-49bd-8339-091f62f5777a im Anruf 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-Anruf 93bfb890-646c-4364-8795-9587bfdc55ba)
Info Anruf 8: konfiguriert - API-Anrufbeinhalt 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 Steuerung) wird eingerichtet.
Info Anruf 9: eingehender SIP-Anruf von "sip:673@172.x.x.x" zur lokalen URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-Anrufbeinhalt 37a6e86d-d457-47cf-be24-1dbe20ccf98a im Anruf 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-Anruf 93bfb890-646c-4364-8795-9587bfdc55ba)
Info Anruf 9: konfiguriert - API-Anrufbeinhalt 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 Steuerung) wird eingerichtet.
Info Anruf 8: kompensiert für nicht übereinstimmende Payload-Typen.
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 die Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 über SIP betreten.
Info Anruf 7: kompensiert für nicht übereinstimmende Payload-Typen.
Info Anruf 8: nicht übereinstimmende Payload-Typen-Modus 1/0.
Info Anruf 8: Angebot in nicht übereinstimmendem Payload-Typen-Modus beantworten.
Info Anruf 8: nachfolgend ein Angebot für einen einzelnen Codec erhalten.
Info Anruf 8: nicht übereinstimmende Payload-Typen-Modus 1/0.
Info Anruf 8: Angebot in nicht übereinstimmendem Payload-Typen-Modus beantworten.
Info Anruf 8: Antwort auf das zusätzliche Angebot für einen einzelnen Codec senden.
Info Anruf 9: kompensiert für nicht übereinstimmende Payload-Typen.
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 die Konferenz 434f88d0-8441-41e1-b6ee-6d1c63b5b098 über SIP betreten.
Info Anruf 9: BFCP (Client-Rolle) jetzt aktiv.
Info Anruf 9: BFCP-Hallo als Client senden nach Erhalt des Hallos, als BFCP nicht aktiv war.
Info Anruf 9: BFCP (Client-Rolle) jetzt aktiv.
Info Anruf 7: wird beendet; Fern-SIP-Abbruch - verbunden für 0:13.
Info Anruf 7: API-Anrufbeinhalt 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: wird gehalten.
Info Anruf 9: nicht übereinstimmende Payload-Typen-Modus 1/0.
Info Anruf 9: Angebot in nicht übereinstimmendem Payload-Typen-Modus beantworten.
Info Anruf 8: wird gehalten.
Info Anruf 8: nachfolgend ein Angebot für einen einzelnen Codec erhalten.
Info Anruf 8: nicht übereinstimmende Payload-Typen-Modus 1/0.
Info Anruf 8: Angebot in nicht übereinstimmendem Payload-Typen-Modus beantworten.
Info Anruf 8: Antwort auf das zusätzliche Angebot für einen einzelnen Codec senden.
Info Anruf 9: wird beendet; Fern-SIP-Abbruch - verbunden für 0:12.Die Ad-Hoc-Konferenz selbst:
Regeln für eingehende Anrufe
Die Konfiguration der Parameter für eingehende Anrufe ist notwendig, um Anrufe im CMS empfangen zu können. Wie Sie in der LDAP-Einstellung gesehen haben, wurden alle Benutzer mit der Domäne conf.pod6.cms.lab importiert. Daher möchten Sie zumindest, dass Anrufe an diese Domäne für die Spaces bestimmt sind. Sie müssen auch Regeln für alles festlegen, was für den vollqualifizierten Domänennamen (und möglicherweise sogar für die IP-Adresse) jedes der CMS-Server bestimmt ist. In unserer externen Anrufsteuerung wird Unified CM SIP-Trunks für jeden der CMS-Server individuell eingerichtet. Abhängig davon, ob das Ziel dieser SIP-Trunks eine IP-Adresse oder der vollqualifizierte Domänenname des Servers ist, wird festgelegt, ob CMS so konfiguriert werden muss, dass es Anrufe an seine IP-Adresse oder seinen vollqualifizierten Domänennamen empfängt.
Die Domäne mit der Regel für den eingehenden Datenverkehr mit der höchsten Priorität wird als Domäne für alle Benutzer-Space verwendet. Wenn Benutzer über LDAP synchronisiert werden, erstellt CMS automatisch Spaces, aber nur den benutzerdefinierten Teil der URI (coSpaceUriMapping), z. B. user.space. Der Teil der vollständigen URI wird basierend auf dieser Regel erstellt. Tatsächlich würden Sie, wenn Sie zu diesem Zeitpunkt in die Web Bridge eingestiegen wären, sehen, dass der Space-URI keinen Domänennamen hat. Indem Sie diese Regel als höchste Priorität festlegen, geben Sie die Domäne für die generierten Spaces als conf.example.com beeinflussen.
Regeln für ausgehende Anrufe
Um Benutzern das Tätigen von ausgehenden Anrufen im Unified CM-Cluster zu ermöglichen, müssen die Regeln für ausgehende Verbindungen konfiguriert werden. Die Domäne der Endpunkte, die im Unified CM registriert sind, wie Jabber, ist example.com. Anrufe in diese Domäne sollten als Standard-SIP-Anrufe an die Call-Processing-Knoten des Unified CM geleitet werden. Hauptsächlich fungiert der Server cucm-01.example.com, als zusätzlicher Server cucm-02.example.com.
Die erste Regel beschreibt die einfachste Anrufweiterleitung zwischen den Servern des Clusters.
Feld Local from domain verantwortlich dafür, was in der SIP-URI des Anrufers angezeigt wird, bei dem, den man anruft, nach dem Zeichen „@“. Wenn wir es leer lassen, wird nach dem Zeichen „@“ die IP-Adresse des CUCM angezeigt, über die dieser Anruf getätigt wird. Wenn wir jedoch eine Domain angeben, wird nach dem Zeichen „@“ genau diese Domain angezeigt. Das ist notwendig, um die Möglichkeit zu haben, zurückzurufen; andernfalls ist es unmöglich, über SIP-URI name@ip-Adresse zurück anzurufen.
Anruf, wenn angegeben Local from domain
Anruf, wenn NEIN angegeben ist Local from domain
Bitte geben Sie ausdrücklich Encrypted oder Unencrypted an, da dies die ausgehenden Anrufe betrifft, da beim Parameter Auto nichts funktioniert.
Aufzeichnung
Die Aufzeichnung von Videokonferenzen erfolgt durch den Record-Server. Der Recorder stellt einen identischen Cisco Meeting Server dar. Der Recorder benötigt keine Installation von Lizenzen auf sich. Lizenzen für die Aufzeichnung sind für die Server erforderlich, auf denen die CallBridge-Dienste ausgeführt werden, d.h. die Recording-Lizenz ist erforderlich und muss auf die Komponente CallBridge angewendet werden, nicht auf den Server, auf dem der Recorder läuft. Der Recorder verhält sich wie ein Client eines erweiterbaren Protokolls für den Nachrichtenaustausch und die Anwesenheit (XMPP), daher muss der XMPP-Server auf dem Server aktiviert sein, auf dem die CallBridge gehostet wird.
Da wir ein Cluster haben und die Lizenz auf alle drei Server des Clusters „ausgedehnt“ werden muss, assoziieren wir einfach in unserem persönlichen Bereich in den 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 verschiedene Szenarien für die Platzierung des Recorders, aber wir werden uns an folgendes halten:
Bevor Sie den Recorder konfigurieren, müssen Sie einen Ort vorbereiten, an dem die Videokonferenzen tatsächlich aufgezeichnet werden sollen. Das ist , wie man die gesamte Aufzeichnung konfiguriert. Ich werde auf wichtige Punkte und Details hinweisen:
1. Es ist besser, das Zertifikat vom ersten Server im Cluster zu verwenden.
2. Der Fehler „Recorder unavailable“ kann auftreten, weil im Recorder Trust nicht das richtige Zertifikat angegeben wurde.
3. Die Aufzeichnung kann nicht stattfinden, wenn für die Aufzeichnung kein Root-Verzeichnis in NFS angegeben ist.
Manchmal besteht die Notwendigkeit, eine Konferenz eines bestimmten Benutzers oder Space automatisch aufzuzeichnen.
Dafür werden zwei CallProfile erstellt:
Mit deaktivierter Aufzeichnungsfunktion
Und mit automatischer Aufzeichnungsfunktion
Danach „verbinden“ wir das CallProfile mit automatischer Aufzeichnungsfunktion mit dem gewünschten Space.
In CMS ist es so, dass, wenn ein CallProfile eindeutig an bestimmte Spaces gebunden ist, dieses CallProfile nur auf diese spezifischen Spaces angewendet wird. Wenn das CallProfile jedoch an keinen Space gebunden ist, wird es standardmäßig auf die Spaces angewendet, an die kein CallProfile explizit gebunden ist.
Beim nächsten Mal werde ich versuchen zu beschreiben, auf welche Arten der Zugriff auf die CMS außerhalb des internen Netzwerks der Organisation erfolgt.
Quellen:
Quelle: habr.com
