In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die Schritte zur Konfiguration und Fehlerbehebung von Cisco Meeting Server (CMS) WebRTC über Expressway beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Konfigurationsvoraussetzungen:
Achtung: Wenn TCP-Port 443 aktiviert ist, kann der Expressway nicht mehr auf TCP-Port 3478 reagieren.
Hinweis: Expressway-Paare für Jabber Guest-Services können nicht für CMS WebRTC Proxy-Services verwendet werden.
Hinweis: Informationen zum Upgrade von früheren Versionen auf Version 3.0 oder höher finden Sie unter Anleitung für ein reibungsloses Upgrade von Cisco Meeting Server 2.9 auf 3.0 (und höher).
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt. Die Mindestanforderungen für Softwareversionen müssen jedoch erfüllt werden.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Seit Version X8.9.2 wurde Expressway um die WebRTC Proxy-Unterstützung erweitert. So können externe Benutzer auf eine Cisco Meeting Server Web Bridge zugreifen.
Externe Clients und Gäste können Bereiche verwalten oder beitreten, ohne dass eine andere Software als ein unterstützter Browser erforderlich ist. Klicken Sie hier, um eine Liste der unterstützten Browser anzuzeigen.
Ab dem 5. Februar 2021 werden die folgenden Browser für CMS 3.1.1 unterstützt:
Dieses Bild zeigt ein Beispiel für den Verbindungsfluss des Webproxys für CMS WebRTC: (aus dem Konfigurationsleitfaden für die Verwendung des Exp-IP-Ports).
Hinweis: Wenn Sie X12.5.2 oder früher ausführen, müssen Sie Ihre externe Firewall so konfigurieren, dass NAT-Reflektion für die öffentliche Expressway-E& IP-Adresse möglich ist (Firewalls misstrauen in der Regel Paketen, die dieselbe Quell- und Ziel-IP-Adresse haben). Ab X12.5.3 ist dies für einen Standalone-Expressway nicht mehr erforderlich.
a. Navigieren Sie zu Configuration > Unified Communication > Cisco Meeting Server.
b. Webproxy des Meeting-Servers aktivieren.
c. Geben Sie die Join-URL in das Feld Guest Account Client URI ein.
d. Klicken Sie auf Speichern.
e. Fügen Sie die CMS-Join-URL dem Expressway-E-Serverzertifikat als Subject Alternative Name (SAN) hinzu. Siehe Cisco VCS Certificate Creation and Use Deployment Guide.
a. Navigieren Sie zu Konfiguration > Traversal > TURN.
b. Aktivieren Sie die TURN-Dienste, von Aus bis Ein.
c. Wählen Sie Anmeldeinformationen für den TURN-Client in der lokalen Datenbank konfigurieren, und fügen Sie die Anmeldeinformationen (Benutzername und Kennwort) hinzu.
Hinweis: Wenn Sie einen Cluster von Expressway-Es haben und diese alle als TURN-Server verwendet werden sollen, dann stellen Sie sicher, dass Sie ihn auf allen Knoten aktivieren. Sie müssen zwei separate turnServer-Instanzen über API konfigurieren und sie auf jeden der Expressway-E-Server im Cluster verweisen (gemäß dem in Schritt 4 gezeigten Konfigurationsprozess, der den Prozess für einen Expressway-E-Server zeigt; die Konfiguration des zweiten turnServers wäre ähnlich, nur unter Verwendung der jeweiligen IP-Adressen und Anmeldeinformationen für den anderen Expressway-E-Server).
Hinweis: Sie können einen Netzwerk-Load Balancer vor Ihren Schnellstraßen für TCP/HTTPS-Datenverkehr verwenden, aber TURN-Medien müssen weiterhin von Client zu TURN-Servern für die öffentliche IP übertragen werden. TURN-Medien dürfen den Netzwerk-Load Balancer nicht passieren.
Dieser Schritt ist erforderlich, da WebRTC-Verbindungen über TCP 443 bereitgestellt werden. Mit Exp 12.7 wurde jedoch eine neue dedizierte Verwaltungsschnittstelle (Dedicated Management Interface, DMI) eingeführt, die für 443 verwendet werden kann.
a. Navigieren Sie zu System > Administration.
b. Ändern Sie unter Webserverkonfiguration den Webadministratorport aus den Dropdown-Optionen auf 445, und klicken Sie dann auf Speichern.
c. Wiederholen Sie die Schritte 3a bis 3b auf allen Expressway-ES, die für WebRTC-Proxydienste verwendet werden.
Hinweis: Cisco empfiehlt, den Administrations-Port zu ändern, da WebRTC-Clients 443 verwenden. Wenn der WebRTC-Browser versucht, auf Port 80 zuzugreifen, leitet der Expressway-E die Verbindung zu 443 um.
In CMS 2.9.x können Sie über das Menü Konfiguration —> API Server hinzufügen:
d. Wiederholen Sie Schritt 4c für jeden Expressway-E-Server, der für TURN verwendet werden soll.
Dieses Bild zeigt ein Beispiel der Konfigurationsschritte:
Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.
a. Navigieren Sie zu Configuration > Unified Communication > Cisco Meeting Server. Sie müssen die IP-Adresse des WB sehen:
b. Navigieren Sie zu Konfiguration > Unified Communication > HTTP-Zulassungsliste > Automatisch hinzugefügte Regeln. Überprüfen Sie, ob dies den Regeln hinzugefügt wurde:
Meeting Server web bridges https 443 Prefix / GET, POST, PUT, HEAD, DELETE Meeting Server web bridges wss 443 Prefix / GET, POST, PUT, HEAD, DELETE
Hinweis: Es wird nicht erwartet, dass der WB in den erkannten Knoten zu finden, da die Regeln lediglich den Proxy für HTTPS-Verkehr zum WB und nicht unbedingt für Unified Communications zulassen.
c. Überprüfen Sie, ob der Secure Shell (SSH)-Tunnel für den WB FQDN auf dem Expressway-C zum Expressway-E gebaut wurde und aktiv ist. Navigieren Sie zu Status > Unified Communications > Unified Communications SSH tunnels status. Sie müssen den FQDN der WB sehen und das Ziel muss der Expressway-E sein.
Suchen Sie im CMS API-Menü die Turn-Server, und klicken Sie auf die einzelnen Server. In jedem Objekt gibt es einen Link, um den Status zu überprüfen:
Die Ausgabe zeigt Informationen an, die die Round-Trip Time (RTT) in Millisekunden (Ms) enthalten, die dem TURN-Server zugeordnet sind. Diese Informationen sind wichtig für die CB-Auswahl des besten zu verwendenden TURN-Servers.
Bei einem Live-Anruf, der über den WebRTC-Client geführt wird, können Sie den Status des TURN-Medien-Relays auf dem Expressway anzeigen. Navigieren Sie zu Status > TURN relay usage, und wählen Sie view (Ansicht).
Nützliche Tools:
In diesem Szenario ist der RTC-Client in der Lage, die Anruf-ID in jalero.space aufzulösen. Wenn Sie jedoch Ihren Namen eingeben und Anruf beitreten auswählen, zeigt der Client Verbindung an, wie in der folgenden Abbildung dargestellt:
Nach ca. 30 Sekunden wird sie auf die erste WB-Seite umgeleitet.
Führen Sie zur Fehlerbehebung die folgenden Schritte aus:
Navigieren Sie im CMS-Webadministrator zu Protokolle > Ereignisprotokolle.
In den Wireshark-Ablaufverfolgungen sehen Sie, dass der Client eine Zuweisungsanforderung mit konfigurierten Anmeldeinformationen an den Expressway-E TURN-Server an Port 3478 sendet:
1329 2017-04-15 10:26:42.108282 10.55.157.229 10.48.36.248 STUN 186
Allocate Request UDP user: expturncreds realm: TANDBERG with nonce
Der Server antwortet mit dem Fehler "Zuordnen":
1363 2017-04-15 10:26:42.214119 10.48.36.248 10.55.157.229 STUN 254
Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 431
(*Unknown error code*) Integrity Check Failure
Oder
3965 2017-04-15 10:34:54.277477 10.48.36.248 10.55.157.229 STUN 218
Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 401
(Unauthorized) Unauthorized
In den CMS-Protokollen wird diese Protokollmeldung angezeigt:
2017-04-15 10:34:56.536 Warning call 7: ICE failure 4 (unauthorized - check credentials)
Lösung:
Überprüfen Sie die im CMS konfigurierten TURN-Anmeldeinformationen, und stellen Sie sicher, dass sie mit den in der lokalen Expressway-E-Authentifizierungsdatenbank konfigurierten Anmeldeinformationen übereinstimmen.
Auf der Seite "Callbridge Status > General" (Rufbrückenstatus > Allgemein) wird Folgendes angezeigt:
2017-04-15 12:09:06.647 Web bridge connection to "webbridge.alero.aca" failed (DNS failure) 2017-04-15 12:10:11.634 Warning web bridge link 2: name resolution for "webbridge.alero.aca" failed 2017-04-15 11:55:50.835 Info failed to establish connection to web bridge link 2 (unknown error)
Lösung:
Lösung:
Navigieren Sie zu Maintenance > Diagnostics > Diagnostic logging, und stellen Sie sicher, dass Take tcpdump while logging markiert ist (wie in diesem Bild gezeigt), bevor Sie Start new log auswählen:
Hinweis: Stellen Sie sicher, dass die Wireshark-Erfassung auf dem Client-Gerät und die Protokollierung auf dem Expressway-E gestartet werden, bevor Sie den fehlerhaften Anruf reproduzieren. Wenn der fehlerhafte Anruf reproduziert wurde, stoppen Sie die Protokollierung auf dem Expressway-E und laden Sie die Aufzeichnung auf den Client herunter.
In diesem Szenario ist der RTC-Client in der Lage, die Anruf-ID in jalero.space aufzulösen. Wenn Sie jedoch Ihren Namen eingeben und Anruf beitreten auswählen, wird sofort die Warnung Verbindung nicht möglich - später erneut versuchen angezeigt:
Lösung:
Überprüfen Sie, ob CMS im internen Netzwerk in der Lage ist, den SRV-Datensatz _xmpp-client für die CB-Domäne immer aufzulösen.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
21-Jun-2023 |
Aktualisiert PII, SEO, Alt-Text, maschinelle Übersetzung, Stilanforderungen, Rechtschreibung und Formatierung. |
1.0 |
20-Oct-2017 |
Erstveröffentlichung |