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 wird beschrieben, wie der Cisco TelePresence Video Communication Server (VCS) für den mobilen Remote-Zugriff (MRA) konfiguriert wird, wenn mehrere Domänen verwendet werden.
Die MRA-Einrichtung, wenn nur eine Domäne vorhanden ist, ist relativ einfach. Sie können die im Bereitstellungsleitfaden dokumentierten Schritte befolgen. Wenn die Bereitstellung mehrere Domänen umfasst, wird sie komplexer. Dieses Dokument ist kein Konfigurationsleitfaden, aber es beschreibt die wichtigen Aspekte, wenn mehrere Domänen beteiligt sind. Die Hauptkonfiguration ist im Cisco TelePresence Video Communication Server (VCS) Deployment Guide dokumentiert.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Verwenden Sie die in diesem Abschnitt beschriebenen Informationen, um den VCS zu konfigurieren.
Im Folgenden finden Sie eine kurze Übersicht über die verschiedenen Domänen:
Die Traversal Zone besteht aus dem Traversal Server (ExpresswayE) in der De-Militarized Zone (DMZ) und dem Traversal Client (ExpresswayC) im Netzwerk:
Der Traversal-Server befindet sich in der Zonenkonfiguration auf der Expressway E:
Der Traversal Client befindet sich in der Zonenkonfiguration auf der Expressway C:
Der Benutzer meldet sich immer bei userid@domain4 an, da es innerhalb und außerhalb des Netzwerks keine Unterschiede beim Anwendererlebnis geben sollte. Dies bedeutet, dass Sie die Sprachdienstdomäne im Jabber-Client konfigurieren müssen, wenn domain1 sich von domain4 unterscheidet. Der Grund hierfür ist, dass der Domänenteil der Anmeldung verwendet wird, um die Collaboration Edge-Services mithilfe der SRV-Datensatzsuche zu ermitteln.
Der Client führt eine DNS-Abfrage (Domain Name System) der SRV-Datensätze für _collab-edge._tls.<domain> durch. Dies bedeutet, dass Sie die Domänenkonfiguration für Sprachdienste verwenden müssen, wenn die Domäne aus der Anmelde-Benutzer-ID von der Domäne des Expressway E abweicht. Jabber verwendet diese Konfiguration, um den Collaboration Edge und den UDS zu ermitteln.
Sie können mehrere Optionen verwenden, um diese Aufgabe durchzuführen:
msiexec /i CiscoJabberSetup.msi VOICE_SERVICES_DOMAIN=domain1 CLEAR=1
<?xml version="1.0" encoding="utf-8"?>
<config version ="1.0">
<Policies> <VoiceServicesDomain>domain1</VoiceServicesDomain>
</Policies>
</config>
Hinweis: Diese Methode ist nur experimentell und wird nicht offiziell von Cisco unterstützt.
<Policies>
<VoiceServicesDomain>domain1</VoiceServicesDomain>
</Policies>
ciscojabber://provision?ServicesDomain=domain4&VoiceServicesDomain=domain1
Hinweis: Es ist erforderlich, die Voice-Services-Domäne zu verwenden, da Sie sicherstellen müssen, dass Sie die Suche nach den Collaboration Edge SRV-Datensätzen für die externe Domäne (Domäne1) durchführen.
In diesem Abschnitt werden die Konfigurationseinstellungen für die externen und internen DNS-Datensätze beschrieben.
Extern
Typ | Eintrag | Auflöst auf |
SRV-Datensatz | _collab-edge._tls.domain1 | ExpresswayE.Domain1 |
Ein Datensatz | ExpresswayE.Domain1 | IP-Adresse ExpresswayE |
Folgendes ist wichtig:
Dies ist erforderlich, da das Expressway-E ein Cookie auf dem Client mit seiner eigenen Domäne (domain1) setzt, und wenn dies nicht mit der vom FQDN zurückgegebenen Domäne übereinstimmt, akzeptiert der Client dies nicht. Die Cisco Bug-ID CSCuo83458 wird als Erweiterung für dieses Szenario geöffnet.
Intern
Typ | Eintrag | Auflöst auf |
SRV-Datensatz | _cisco-uds_tcp.domain1 | cucm.domain3 |
Ein Datensatz | cucm.domain3 | IP-Adresse CUCM |
Da die Voice-Services-Domäne auf domain1 festgelegt ist, fügt Jabber domain1 zur Konfigurationserkennung des Collaboration Edge in die umgewandelte URL ein (get edge_config). Nach dem Empfang führt der Expressway-C eine SRV UDS-Datensatzabfrage für domain1 durch und gibt die Datensätze in der 200 OK-Nachricht zurück.
Typ | Eintrag | Auflöst auf |
SRV | _cisco-uds_tcp.domain4 | cucm.domain3 |
Ein Datensatz | cucm.domain3 | IP-Adresse CUCM |
Wenn der Client im Netzwerk ist, ist die SRV UDS-Datensatzerkennung für Domäne4 erforderlich.
Sie müssen diese SIP-Domänen (Session Initiation Protocol) auf dem Expressway-C hinzufügen und für MRA aktivieren:
Wenn Sie die Cisco Unified Communications Manager-Server (CUCM) konfigurieren, gibt es zwei Szenarien:
Dies ist erforderlich, da Expressway-C, wenn er die CUCM-Server erkennt und den Hostnamen zurückgibt, eine DNS-Suche nach hostname.domain2 durchführt, die nicht funktioniert, wenn sich domain2 und domain3 unterscheiden.
Neben den allgemeinen Zertifikatsanforderungen müssen den Subject Alternate Names (SAN) der Zertifikate einige Dinge hinzugefügt werden:
Hinweis: Das FQDN-Format ist nur erforderlich, wenn Ihre Zertifizierungsstelle (Certificate Authority, CA) die Hostnamensyntax im SAN nicht zulässt.
In diesem Abschnitt werden die Konfigurationseinstellungen beschrieben, wenn zwei Netzwerkschnittstellenkarten (NICs) verwendet werden.
Wenn Sie Expressway-E für die Verwendung von dualen Netzwerkschnittstellen konfigurieren, ist es wichtig, sicherzustellen, dass beide Schnittstellen konfiguriert und verwendet werden.
Wenn die Doppelnetzwerkschnittstellen verwenden mit dem Wert Ja konfiguriert ist, überwacht der Expressway-E nur die interne Schnittstelle für die XMPP-Kommunikation mit dem Expressway-C. Daher müssen Sie sicherstellen, dass diese Schnittstelle konfiguriert ist und ordnungsgemäß funktioniert.
Wenn nur eine Schnittstelle verwendet wird und Sie das Expressway-E mit einer öffentlichen IP-Adresse konfigurieren, müssen keine besonderen Überlegungen angestellt werden.
Wenn nur eine Schnittstelle verwendet wird und Sie das Expressway-E mit einer privaten IP-Adresse konfigurieren, müssen Sie auch die statische Network Address Translation (NAT)-Adresse konfigurieren:
In dieser Situation ist es wichtig sicherzustellen, dass
Tipp: Weitere Informationen zu erweiterten Netzwerkbereitstellungen finden Sie in Anhang 4 des Cisco TelePresence Video Communication Server Basic Configuration (Control with Expressway) Deployment Guide.
Für diese Konfiguration ist derzeit kein Überprüfungsverfahren verfügbar.
Dieser Abschnitt enthält Informationen, die Sie zur Fehlerbehebung bei Ihrer Konfiguration verwenden können.
Einige spezifische Szenarien werden in diesem Abschnitt behandelt, Sie können jedoch auch den Collaboration Solutions Analyzer verwenden, der eine detaillierte Ansicht aller Kommunikationsvorgänge für MRA-Anmeldeversuche und Informationen zur Fehlerbehebung auf der Grundlage Ihrer Diagnoseprotokolle bereitstellt.
Wenn die Peer-Adresse als IP-Adresse konfiguriert ist oder die Peer-Adresse nicht mit dem Common Name (CN) übereinstimmt, wird dies in den Protokollen angezeigt:
Event="Outbound TLS Negotiation Error" Service="SIP" Src-ip="10.48.80.161"
Src-port="25697" Dst-ip="10.48.36.171" Dst-port="7001" Detail="Peer's TLS
certificate identity was unacceptable" Protocol="TLS" Common-name="10.48.36.171"
Wenn das Kennwort falsch ist, sehen Sie dies in den Expressway-E-Protokollen:
Module="network.ldap" Level="INFO": Detail="Authentication credential found in
directory for identity: traversal"
Module="developer.nomodule" Level="WARN" CodeLocation="ppcmains/sip/sipproxy/
SipProxyAuthentication.cpp(686)" Method="SipProxyAuthentication::
checkDigestSAResponse" Thread="0x7f2485cb0700": calculated response does not
match supplied response, calculatedResponse=769c8f488f71eebdf28b61ab1dc9f5e9,
response=319a0bb365decf98c1bb7b3ce350f6ec
Event="Authentication Failed" Service="SIP" Src-ip="10.48.80.161"
Src-port="25723" Detail="Incorrect authentication credential for user"
Protocol="TLS" Method="OPTIONS" Level="1"
Wenn Dual-NIC aktiviert ist, aber die zweite Schnittstelle nicht verwendet oder verbunden wird, kann Expressway-C keine Verbindung zum Expressway-E für die XMPP-Kommunikation auf Port 7400 herstellen. Die Expressway-C-Protokolle zeigen Folgendes:
xwayc XCP_JABBERD[23843]: UTCTime="2014-03-25 17:19:45,843" ThreadID=
"139747212576512" Module="Jabber" Level="INFO " CodeLocation="mio.c:1109"
Detail="Connecting on fd 28 to host '10.48.36.171', port 7400"xwayc
XCP_JABBERD[23843]: UTCTime="2014-03-25 17:19:45,847" ThreadID="139747212576512"
Module="Jabber" Level="ERROR" CodeLocation="mio.c:1121" Detail="Unable to
connect to host '10.48.36.171', port 7400:(111) Connection refused"
xwayc XCP_JABBERD[23843]: UTCTime="2014-03-25 17:19:45,847" ThreadID=
"139747406935808" Module="Jabber" Level="ERROR" CodeLocation=
"base_connection.cpp:104" Detail="Failed to connect to component
jabberd-port-1.expresswayc-vngtp-lab"
Wenn der FQDN, der von der SRV-Datensatzsuche für den Collaboration Edge zurückgegeben wird, nicht mit dem FQDN übereinstimmt, der auf dem Expressway-E konfiguriert wurde, zeigen die Jabber-Protokolle den folgenden Fehler an:
WARNING [9134000] - [csf.edge][executeEdgeConfigRequest] XAuth Cookie expiration
time is invalid or not available. Attempting to Failover.
DEBUG [9134000] - [csf.edge][executeEdgeConfigRequest]Failed to retrieve
EdgeConfig with error:INTERNAL_ERROR
In den Diagnoseprotokollen für Expressway-E können Sie sehen, für welche Domäne das Cookie in der HTTPS-Nachricht festgelegt ist:
Set-Cookie: X-Auth=1e1111e1-dddb-49e9-ad0d-ab34526e2b00; Expires=Fri,
09 May 2014 20:21:31 GMT; Domain=.vngtp.lab; Path=/; Secure
Wenn die erforderlichen SIP-Domänen nicht zum Expressway-C hinzugefügt werden, akzeptiert der Expressway-E keine Nachrichten für diese Domäne. In den Diagnoseprotokollen wird eine 403 Forbidden-Meldung angezeigt, die an den Client gesendet wird:
ExpresswayE traffic_server[15550]:
Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Response"
Txn-id="2" Dst-ip="10.48.79.80" Dst-port="50314"
HTTPMSG:
|HTTP/1.1 403 Forbidden
Date: Wed, 21 May 2014 14:31:18 GMT
Connection: close
Server: CE_E
Content-Length: 0
ExpresswayE traffic_server[15550]: Event="Sending HTTP error response"
Status="403" Reason="Forbidden" Dst-ip="10.48.79.80" Dst-port="50314"