Umgebung vorbereiten
Entscheidungspunkte
Berücksichtigung | Fragen zur Beantwortung | Ressourcen |
Architektur und Infrastruktur |
Wie viele XSPs? Wie nehmen sie mTLS ein? |
Cisco BroadWorks-Systemkapazitätsplaner Cisco BroadWorks-Systementwicklungsleitfaden XSP CLI-Referenz Dieses Dokument |
Kunden- und Benutzerbereitstellung | Können Sie behaupten, dass Sie E-Mails in BroadWorks vertrauen? Möchten Sie, dass Benutzer E-Mail-Adressen angeben, um ihre eigenen Konten zu aktivieren? Können Sie Tools zur Verwendung unserer API erstellen? |
Öffentliche API-Dokumente unter https://developer.webex.com Dieses Dokument |
Markenbildung | Welche Farbe und welches Logo möchten Sie verwenden? | Branding-Artikel zur Webex-App |
Vorlagen | Welche unterschiedlichen Anwendungsfälle haben Sie für Kunden? | Dieses Dokument |
Abonnentenfunktionen pro Kunde/Unternehmen/Gruppe | Wählen Sie ein Paket aus, um den Servicelevel pro Vorlage zu definieren. Basic, Standard, Premium oder Softphone. | Dieses Dokument Funktions-/Paketmatrix |
Benutzerauthentifizierung | BroadWorks oder Webex | Dieses Dokument |
Bereitstellungsadapter (für Durchlaufbereitstellungsoptionen) | Verwenden Sie bereits integriertes IM&P, z. B. für UC-One SaaS? Beabsichtigen Sie, mehrere Vorlagen zu verwenden? Wird ein häufigerer Anwendungsfall erwartet? |
Dieses Dokument CLI-Referenz für Anwendungsserver |
Architektur und Infrastruktur
Mit welcher Größenordnung wollen Sie beginnen? Es ist möglich, in Zukunft zu skalieren, aber Ihre aktuelle Nutzungsschätzung sollte die Infrastrukturplanung vorantreiben.
Arbeiten Sie mit Ihrem Cisco-Account-Manager/Vertriebsmitarbeiter zusammen, um Ihre XSP-Infrastruktur gemäß dem Cisco BroadWorks System Capacity Planner und dem Cisco BroadWorks System Engineering Guide zu vergrößern.
Wie stellt Webex Mutual TLS-Verbindungen zu Ihren XSPs her? Direkt zum XSP in einer DMZ oder über TLS-Proxy? Dies wirkt sich auf Ihre Zertifikatverwaltung und die URLs aus, die Sie für die Schnittstellen verwenden. ( Wir unterstützen keine unverschlüsselten TCP-Verbindungen zum Rand Ihres Netzwerks ).
Kunden- und Benutzerbereitstellung
Welche Bereitstellungsmethode für Benutzer passt am besten zu Ihnen?
Durchlaufbereitstellung mit vertrauenswürdigen E-Mails : Durch Zuweisen des „integrierten IM&P“-Dienstes auf BroadWorks wird der Subscriber automatisch in Webex bereitgestellt.
Wenn Sie auch bestätigen können, dass die E-Mail-Adressen der Subscriber in BroadWorks gültig und für Webex eindeutig sind, können Sie die „vertrauenswürdige E-Mail“-Variante der Durchlaufbereitstellung verwenden. Webex-Abonnentenkonten werden ohne ihr Eingreifen erstellt und aktiviert. Sie laden einfach den Client herunter und melden sich an.
Die E-Mail-Adresse ist ein wichtiges Benutzerattribut in Webex. Daher muss der Serviceanbieter eine gültige E-Mail-Adresse für den Benutzer angeben, um diese für Webex-Dienste bereitstellen zu können. Dies muss im E-Mail-ID-Attribut des Benutzers in BroadWorks enthalten sein. Wir empfehlen, dass Sie es auch in das Attribut „Alternative ID“ kopieren.
Durchlaufbereitstellung ohne vertrauenswürdige E-Mails : Wenn Sie den E-Mail-Adressen der Subscriber-Benutzer nicht vertrauen können, können Sie weiterhin den integrierten IM&P-Dienst in BroadWorks zuweisen, um Benutzer in Webex bereitzustellen.
Mit dieser Option werden die Konten erstellt, wenn Sie den Dienst zuweisen, aber die Subscriber müssen ihre E-Mail-Adressen angeben und validieren, um die Webex-Konten zu aktivieren.
Benutzer-Self-Provisioning: Für diese Option ist keine IM&P-Dienstzuweisung in BroadWorks erforderlich. Sie (oder Ihre Kunden) verteilen stattdessen einen Bereitstellungslink und die Links zum Herunterladen der verschiedenen Clients mit Ihrem Branding und Anweisungen.
Subscriber folgen dem Link, geben dann ihre E-Mail-Adressen ein und validieren sie, um ihre Webex-Konten zu erstellen und zu aktivieren. Anschließend laden sie den Client herunter und melden sich an. Webex ruft einige zusätzliche Konfigurationen über BroadWorks ab (einschließlich der primären Nummern).
SP-kontrollierte Bereitstellung über APIs : Webex stellt eine Reihe von Öffentlichen APIs bereit, die Dienstanbietern die Erstellung von Benutzer-/Subscriber-Bereitstellungen in ihren vorhandenen Workflows ermöglichen.
Bereitstellungsanforderungen
In der folgenden Tabelle sind die Anforderungen für die einzelnen Bereitstellungsmethoden zusammengefasst. Zusätzlich zu diesen Anforderungen muss Ihre Bereitstellung die allgemeinen Systemanforderungen erfüllen, die in diesem Handbuch beschrieben werden.
Bereitstellungsmethode |
Anforderungen |
---|---|
Flowthrough-Bereitstellung (Vertrauenswürdige oder nicht vertrauenswürdige E-Mails) |
Die Webex-Bereitstellungs-API fügt vorhandene BroadWorks-Benutzer automatisch zu Webex hinzu, sobald der Benutzer die Anforderungen erfüllt und Sie den integrierten IM+P -Dienst aktivieren. Es gibt zwei Flüsse (vertrauenswürdige E-Mails oder nicht vertrauenswürdige E-Mails), die Sie über die Kundenvorlage in Webex zuweisen. BroadWorks-Anforderungen:
Webex-Anforderungen: Die Kundenvorlage umfasst die folgenden Einstellungen:
|
Selbstbereitstellung für Benutzer |
Admin stellt einem vorhandenen BroadWorks-Benutzer einen Link zum Benutzeraktivierungsportal bereit. Der Benutzer muss sich mit BroadWorks-Anmeldeinformationen beim Portal anmelden und eine gültige E-Mail-Adresse angeben. Nachdem die E-Mail validiert wurde, ruft Webex zusätzliche Benutzerinformationen ab, um die Bereitstellung abzuschließen. BroadWorks-Anforderungen:
Webex-Anforderungen: Die Kundenvorlage umfasst die folgenden Einstellungen:
|
SP-gesteuerte Bereitstellung über API (Vertrauenswürdige oder nicht vertrauenswürdige E-Mails) |
Webex stellt eine Reihe öffentlicher APIs bereit, mit denen Sie die Benutzerbereitstellung in Ihre vorhandenen Workflows und Tools integrieren können. Es gibt zwei Flüsse:
BroadWorks-Anforderungen:
Webex-Anforderungen:
Um die APIs zu verwenden, gehen Sie zu BroadWorks Subscribers . |
Erforderliche Patches mit Flow-through-Bereitstellung
Wenn Sie die Flow-Through-Bereitstellung verwenden, müssen Sie ein System-Patch installieren und eine CLI-Eigenschaft anwenden. Anweisungen für Ihre BroadWorks-Version finden Sie in der folgenden Liste:
Für R22:
Installieren Sie AP.as.22.0.1123.ap376508 .
Nach der Installation die Eigenschaft festlegen
bw.msg.includeIsEnterpriseInOSSschema
bistrue
über die CLI in Maintenance/ContainerOptions .Weitere Informationen finden Sie in den Patch Notes https://www.cisco.com/web/software/286326332/154309/AP.as.22.0.1123.ap376508.txt.
Für R23:
Installieren AP.as.23.0.1075.ap376509
Nach der Installation die Eigenschaft festlegen
bw.msg.includeIsEnterpriseInOSSschema
bistrue
über die CLI in Maintenance/ContainerOptions .Weitere Informationen finden Sie in den Patch Notes https://www.cisco.com/web/software/286326332/154325/AP.as.23.0.1075.ap376509.txt.
Für R24:
Installieren AP.as.24.0.944.ap375100
Nach der Installation die Eigenschaft festlegen
bw.msg.includeIsEnterpriseInOSSschema
bistrue
über die CLI in Maintenance/ContainerOptions .Weitere Informationen finden Sie in den Patch Notes https://www.cisco.com/web/software/286326332/154326/AP.as.24.0.944.ap375100.txt.
Nachdem Sie diese Schritte abgeschlossen haben, können Sie keine neuen Benutzer mehr mit UC-One Collaborate-Diensten bereitstellen. Neu bereitgestellte Benutzer müssen Webex für Cisco BroadWorks-Benutzer sein.
|
Unterstützte Spracheinstellungen
Während der Bereitstellung wird die Sprache, die dem ersten bereitgestellten Benutzer mit Administratorrechten in BroadWorks zugewiesen wurde, automatisch als Standardgebietsschema für diese Kundenorganisation zugewiesen. Diese Einstellung legt die Standardsprache fest, die für Aktivierungs-E-Mails, Meetings und Meeting-Einladungen unter dieser Kundenorganisation verwendet wird.
Es werden fünf Zeichensprachen im Format (ISO-639-1)_(ISO-3166) unterstützt. Beispiel: en_ US entspricht E nglish_ UnitedStates. Wenn nur eine Sprache mit zwei Buchstaben angefordert wird (im ISO-639-1-Format), generiert der Dienst eine Sprachsprache mit fünf Zeichen, indem er die angeforderte Sprache mit einem Ländercode aus der Vorlage kombiniert, d. h. "requestedL anguage_ CountryCode", wenn keine gültige Spracheinstellung abgerufen werden kann, dann wird die standardmäßige sinnvolle Spracheinstellung basierend auf dem erforderlichen Sprachcode verwendet.
In der folgenden Tabelle werden die unterstützten Gebietsschemata und die Zuordnung, die einen Sprachcode mit zwei Buchstaben in ein Gebietsschema mit fünf Zeichen konvertiert, für Situationen aufgeführt, in denen ein Gebietsschema mit fünf Zeichen nicht verfügbar ist.
Unterstützte Spracheinstellungen (ISO-639-1)_(ISO-3166) |
Wenn nur ein Sprachcode mit zwei Buchstaben verfügbar ist... |
|
---|---|---|
Sprachcode (ISO-639-1) ** |
Verwenden Sie stattdessen das standardmäßige sensible Gebietsschema (ISO-639-1)_(ISO-3166) |
|
en_USA en_AU en_GB en_CA |
en |
en_USA |
fr_Fr fr_CA |
Fr |
fr_Fr |
cs_TSCHECHISCH |
c) |
cs_TSCHECHISCH |
da_Weiß nicht |
da |
da_Weiß nicht |
de_DE |
DE |
de_DE |
hu_HU |
hu |
hu_HU |
id_ID |
id |
id_ID |
it_IT |
IT |
it_IT |
ja_JP |
ja |
ja_JP |
ko_KR |
ko |
ko_KR |
es_ES es_CO es_MX |
ES |
es_ES |
nl_NL |
NL |
nl_NL |
nb_NR. |
nb |
nb_NR. |
pl_PL. |
pl. |
pl_PL. |
pt_PT pt_BR |
pt |
pt_PT |
ru_RU |
RU |
ru_RU |
ro_RO |
ro |
ro_RO |
zh_CN zh_TW |
zh |
zh_CN |
sv_SE |
sv |
sv_SE |
ar_SA |
ar |
ar_SA |
tr_TR |
tr. |
tr_TR |
Die Gebietsschemas es_ CO, id_ ID, nb_ NO und pt_ PT werden von Webex Meeting-Sites nicht unterstützt. Für diese Gebietsschemata sind Die Webex Meetings-Sites nur auf Englisch verfügbar. Englisch ist das Standardgebietsschema für Sites, wenn keine/ungültige/nicht unterstützte Gebietsschema für die Site erforderlich ist. Dieses Sprachfeld ist beim Erstellen einer Organisations- und Webex Meetings-Site anwendbar. Wenn in einem Beitrag oder in der API des Subscribers keine Sprache erwähnt wird, wird die Sprache aus der Vorlage als Standardsprache verwendet. |
Markenbildung
Partneradministratoren können die erweiterten Branding-Anpassungen verwenden, um anzupassen, wie die Webex App für die Kundenorganisationen aussieht, die der Partner verwaltet. Partneradministratoren können die folgenden Einstellungen anpassen, um sicherzustellen, dass die Webex App die Marke und Identität ihres Unternehmens widerspiegelt:
Firmenlogos
Eindeutige Farbschemata für den hellen oder dunklen Modus
Angepasste Support-URLs
Weitere Informationen zum Anpassen des Brandings finden Sie unter Konfigurieren erweiterter Branding-Anpassungen .
|
Kundenvorlagen
Mit Kundenvorlagen können Sie die Parameter definieren, nach denen Kunden und zugehörige Subscriber automatisch in Webex für Cisco BroadWorks bereitgestellt werden. Sie können mehrere Kundenvorlagen nach Bedarf konfigurieren, aber wenn Sie einen Kunden integrieren, ist er nur einer Vorlage zugeordnet (Sie können nicht mehrere Vorlagen auf einen Kunden anwenden).
Einige der primären Vorlagenparameter sind unten aufgeführt.
Paket
Sie müssen ein Standardpaket auswählen, wenn Sie eine Vorlage erstellen (Details finden Sie unter Pakete im Abschnitt Übersicht). Alle Benutzer, die mit dieser Vorlage bereitgestellt werden, ob durch Flowthrough- oder Self-Provisioning, erhalten das Standardpaket.
Sie haben die Kontrolle über die Paketauswahl für verschiedene Kunden, indem Sie mehrere Vorlagen erstellen und jeweils unterschiedliche Standardpakete auswählen. Sie können dann je nach ausgewählter Bereitstellungsmethode des Benutzers für diese Vorlagen unterschiedliche Bereitstellungslinks oder verschiedene Bereitstellungsadapter pro Unternehmen verteilen.
Sie können das Paket bestimmter Subscriber in diesem Standard mithilfe der Bereitstellungs-API ändern (siehe Webex für Cisco BroadWorks API-Dokumentation oder über Partner Hub (siehe Benutzerpaket in Partner Hub ändern).
Sie können das Paket eines Subscribers nicht über BroadWorks ändern. Die Zuweisung des integrierten IM&P-Dienstes ist entweder ein- oder ausgeschaltet. Wenn dem Subscriber dieser Dienst in BroadWorks zugewiesen wird, definiert die mit der Bereitstellungs-URL des Unternehmens des Subscribers verknüpfte Partner-Hub-Vorlage das Paket.
Wiederverkäufer und Unternehmen oder Dienstleister und Gruppen?
Die Konfiguration Ihres BroadWorks-Systems hat Auswirkungen auf den Ablauf der Bereitstellung. Wenn Sie ein Reseller mit Enterprises sind, müssen Sie den Enterprise-Modus aktivieren, wenn Sie eine Vorlage erstellen.
Wenn Ihr BroadWorks-System im Dienstleistermodus konfiguriert ist, können Sie den Enterprise-Modus in Ihren Vorlagen deaktiviert lassen.
Wenn Sie vorhaben, Kundenorganisationen mit beiden BroadWorks-Modi bereitzustellen, müssen Sie verschiedene Vorlagen für Gruppen und Unternehmen verwenden.
Stellen Sie sicher, dass Sie die BroadWorks-Patches angewendet haben, die für die Flow-Through-Bereitstellung erforderlich sind. Weitere Informationen finden Sie unter „Erforderliche Patches mit Flow-through-Bereitstellung“ .
|
Authentifizierungsmodus
Entscheiden Sie, wie sich Abonnenten bei der Anmeldung bei Webex authentifizieren sollen. Sie können den Modus mit der Einstellung Authentifizierungsmodus in der Kundenvorlage zuweisen. In der folgenden Tabelle sind einige Optionen aufgeführt.
Diese Einstellung hat keine Auswirkungen auf die Anmeldung beim Benutzeraktivierungsportal. Benutzer, die sich beim Portal anmelden, müssen ihre BroadWorks-Benutzer-ID und ihr Kennwort eingeben, wie in BroadWorks konfiguriert, unabhängig davon, wie Sie den Authentifizierungsmodus in der Kundenvorlage konfigurieren.
|
Authentifizierungsmodus | BroadWorks | Webex |
Primäre Benutzeridentität | BroadWorks-Benutzer-ID | E-Mail-Adresse |
Identitätsanbieter | BroadWorks.
|
Cisco Common Identity |
Multi-Faktor-Authentifizierung? | Nein | Erfordert Kunden-IdP, der die Multi-Faktor-Authentifizierung unterstützt. |
Pfad zur Validierung der Anmeldeinformationen |
|
|
Eine detailliertere Aufschlüsselung des SSO-Anmeldeflusses mit direkter Authentifizierung bei BroadWorks finden Sie unter SSO-Anmeldefluss .
|
UTF-8-Verschlüsselung mit BroadWorks-Authentifizierung
Bei der BroadWorks-Authentifizierung empfehlen wir, die UTF-8-Kodierung für den Authentifizierungs-Header zu konfigurieren. UTF-8 behebt ein Problem, das mit Passwörtern auftreten kann, die Sonderzeichen verwenden, bei denen der Webbrowser die Zeichen nicht ordnungsgemäß codiert. Mit einem UTF-8-codierten, Basis-64-codierten Header wird dieses Problem behoben.
Sie können die UTF-8-Kodierung konfigurieren, indem Sie einen der folgenden CLI-Befehle auf dem XSP oder ADP ausführen:
XSP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
ADP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
Land
Sie müssen ein Land auswählen, wenn Sie eine Vorlage erstellen. Dieses Land wird automatisch als Organisationsland für alle Kunden zugewiesen, die mit der Vorlage in Common Identity bereitgestellt werden. Darüber hinaus bestimmt das Land der Organisation die globalen Standardeinwahlnummern für Cisco PSTN in Webex Meeting-Sites.
Die globalen Standardeinwahlnummern der Site werden auf die erste verfügbare Einwahlnummer festgelegt, die basierend auf dem Land der Organisation in der Telefonie-Domäne definiert ist. Wenn das Land der Organisation nicht in der in der Telefonie-Domäne definierten Einwahlnummer gefunden wird, wird die Standardnummer dieses Standorts verwendet.
S-Nr. |
Standort |
Landesvorwahl |
Name des Landes |
---|---|---|---|
1 |
AMER |
+1 |
UNS, CA |
2 |
Asien-Pazifik-Raum |
+65 |
Singapur |
3 |
ANZ |
+61 |
Australien |
4 |
EMEA |
+44 |
GB |
5 |
EURO-EINFÜHRUNG |
+49 |
Deutschland |
Vereinbarungen mit mehreren Partnern
Werden Sie Webex für Cisco BroadWorks unter die Lizenz eines anderen Serviceanbieters übertragen? In diesem Fall benötigt jeder Serviceanbieter eine eigene Partnerorganisation in Webex Control Hub, damit er die Lösung für seinen Kundenstamm bereitstellen kann.
Adapter und Vorlagen bereitstellen
Wenn Sie die Flowthrough-Bereitstellung verwenden, wird die Bereitstellungs-URL, die Sie in BroadWorks eingeben, von der Vorlage in Control Hub abgeleitet. Sie können über mehrere Vorlagen und somit über mehrere Bereitstellungs-URLs verfügen. Auf diese Weise können Sie Unternehmen für Unternehmen auswählen, welches Paket für Abonnenten gelten soll, wenn ihnen der integrierte IM&P-Dienst gewährt wird.
Sie müssen prüfen, ob Sie eine Bereitstellungs-URL auf Systemebene als Standard-Bereitstellungspfad festlegen möchten und welche Vorlage Sie dafür verwenden möchten. Auf diese Weise müssen Sie nur explizit die Bereitstellungs-URL für Unternehmen festlegen, die eine andere Vorlage benötigen.
Beachten Sie außerdem, dass Sie möglicherweise bereits eine Bereitstellungs-URL auf Systemebene verwenden, z. B. mit UC-One SaaS. Wenn dies der Fall ist, können Sie die URL auf Systemebene für Bereitstellungsbenutzer auf UC-One SaaS beibehalten und diese Unternehmen überschreiben, die zu Webex für Cisco BroadWorks . Alternativ können Sie auch den anderen Weg gehen und die URL auf Systemebene für Webex für BroadWorks festlegen und die Unternehmen neu konfigurieren, die Sie auf UC-One SaaS beibehalten möchten.
Die Konfigurationsoptionen im Zusammenhang mit dieser Entscheidung sind unter „Anwendungsserver mit Bereitstellungsdienst-URL konfigurieren“ beschrieben.
Adapter-Proxy bereitstellen
Für zusätzliche Sicherheit können Sie mit dem Proxy des Bereitstellungsadapters einen HTTP(S)-Proxy auf der Anwendungs-Bereitstellungsplattform für die Durchlaufbereitstellung zwischen dem AS und Webex verwenden. Die Proxy-Verbindung erstellt einen Ende-zu-Ende-TCP-Tunnel, der den Datenverkehr zwischen dem AS und Webex weiterleitet, wodurch der AS keine direkte Verbindung mit dem öffentlichen Internet herstellen muss. Für sichere Verbindungen kann TLS verwendet werden.
Diese Funktion erfordert, dass Sie den Proxy in BroadWorks einrichten. Weitere Informationen finden Sie unter Cisco BroadWorks Proxy-Funktionsbeschreibung für den Adapter .
Mindestanforderungen
Konten
Alle Subscriber, die Sie für Webex bereitstellen, müssen im BroadWorks-System vorhanden sein, das Sie in Webex integrieren. Sie können bei Bedarf mehrere BroadWorks-Systeme integrieren.
Alle Subscriber müssen über BroadWorks-Lizenzen und eine primäre Nummer oder einen Anschluss verfügen.
Webex verwendet E-Mail-Adressen als primäre Identifikatoren für alle Benutzer. Wenn Sie eine Flowthrough-Bereitstellung mit vertrauenswürdigen E-Mails verwenden, müssen Ihre Benutzer gültige Adressen im E-Mail-Attribut in BroadWorks haben.
Wenn Ihre Vorlage die BroadWorks-Authentifizierung verwendet, können Sie die E-Mail-Adressen der Subscriber in das Attribut „Alternative ID“ in BroadWorks kopieren. Dies ermöglicht es Benutzern, sich mit ihren E-Mail-Adressen und BroadWorks-Passwörtern bei Webex anzumelden.
Ihre Administratoren müssen ihre Webex-Konten verwenden, um sich bei Partner Hub anzumelden.
Das Onboarding eines BroadWorks-Administrators in Webex für Cisco BroadWorks wird nicht unterstützt. Sie können nur BroadWorks-Anrufbenutzer mit einer primären Nummer und/oder Durchwahl integrieren. Wenn Sie die Flowthrough-Bereitstellung verwenden, müssen Benutzern auch der integrierte IM&P-Dienst zugewiesen werden.
|
Server in Ihren Netzwerk- und Softwareanforderungen
BroadWorks-Instanz(en) mit mindestens Version R22. Informationen zu unterstützten Versionen und Patches finden Sie in den BroadWorks-Softwareanforderungen (in diesem Dokument). Weitere Informationen finden Sie unter Lebenszyklusrichtlinie für BroadSoft-Produkte Abschnitt in BroadSoft Lifecycle Policy und BroadWorks Software Compatibility Matrix .
Die BroadWorks-Instanz(n) sollte(n) mindestens die folgenden Server umfassen:
Anwendungsserver (AS) mit BroadWorks-Version wie oben
Netzwerkserver (NS)
Profilserver (PS)
Öffentliche XSP-Server oder Application Delivery Platform (ADP), die die folgenden Anforderungen erfüllen:
Authentifizierungsdienst (BWAuth)
Schnittstellen für XSI-Aktionen und -Ereignisse
DMS (Web-Anwendung für die Geräteverwaltung)
CTI-Schnittstelle (Computer Telephony Intergration)
TLS 1.2 mit einem gültigen Zertifikat (nicht selbstsigniert) und allen erforderlichen Zwischenprodukten. Erfordert einen Systemebenen-Administrator, um die Suche im Unternehmen zu erleichtern.
Mutual TLS (mTLS)-Authentifizierung für den Authentifizierungsdienst (erfordert die als Vertrauensanker installierte öffentliche Webex-Client-Zertifikatskette)
Mutual TLS (mTLS)-Authentifizierung für CTI-Schnittstelle (erfordert die als Vertrauensanker installierte öffentliche Webex-Client-Zertifikatskette)
Ein separater XSP/ADP-Server, der als „Push-Server für Anrufbenachrichtigungen“ fungiert (ein NPS in Ihrer Umgebung, der verwendet wird, um Anrufbenachrichtigungen an Apple/Google zu übertragen. Wir nennen es hier „CNPS“, um es von dem Dienst in Webex zu unterscheiden, der Push-Benachrichtigungen für Nachrichten und Präsenz bereitstellt).
Dieser Server muss sich auf R22 oder höher befinden.
Wir beauftragen einen separaten XSP/ADP-Server für CNPS, da sich die Unberechenbarkeit der Last von Webex für BWKS-Cloudverbindungen negativ auf die Leistung des NPS-Servers auswirken kann, was zu einer erhöhten Benachrichtigungslatenz führen kann. Weitere Informationen zur XSP-Skalierung finden Sie im Cisco BroadWorks Systementwicklungsleitfaden.
Webex-App-Plattformen
Um die englische Version der Webex-App herunterzuladen, gehen Sie zu https://www.webex.com/webexfromserviceproviders-downloads.html. Die Webex-App ist verfügbar in:
Windows-PCs/Laptops
Apple-PCs/Laptops mit MacOS
iOS (Apple Store)
Android (Play Store)
Webbrowser (gehen Sie zu https://teams.webex.com/)
Lokalisierte Versionen
Verwenden Sie einen der folgenden Links, um eine lokalisierte Version der Webex-App herunterzuladen:
https://origin-webex-uat.cisco.com/ko/webexfromserviceproviders-downloads.html (Koreanisch)
https://origin-webex-uat.cisco.com/fr/webexfromserviceproviders-downloads.html (Französisch)
https://origin-webex-uat.cisco.com/pt/webexfromserviceproviders-downloads.html (Portugiesisch)
https://origin-webex-uat.cisco.com/zh-tw/webexfromserviceproviders-downloads.html (Traditionell Chinesisch)
https://origin-webex-uat.cisco.com/zh-cn/webexfromserviceproviders-downloads.html (Chinesisch vereinfacht)
https://origin-webex-uat.cisco.com/ja/webexfromserviceproviders-downloads.html (Japan)
https://origin-webex-uat.cisco.com/es/webexfromserviceproviders-downloads.html (Spanien)
https://origin-webex-uat.cisco.com/de/webexfromserviceproviders-downloads.html (Deutsch)
https://origin-webex-uat.cisco.com/it/webexfromserviceproviders-downloads.html (Italienisch)
Physische Telefone und Zubehör
Cisco IP-Telefone:
Cisco IP-Telefon 6800-Serie mit Multiplattform-Firmware
Cisco IP-Telefon 7800-Serie mit Multiplattform-Firmware
Cisco IP-Telefon 8800-Serie mit Multiplattform-Firmware
Siehe https://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phones/multiplatform-firmware.html für Modelle und weitere Informationen.
Wir unterstützen Drittanbieter-Telefone genauso wie andere BroadWorks-Integrationen. Sie haben jedoch noch keine Kontakte und Anwesenheitsintegration mit Webex für Cisco BroadWorks.
Adapter:
Cisco ATA 191 Multiplattform-Analogtelefonadapter
Cisco ATA 192 Multiplattform-Analogtelefonadapter
Siehe https://www.cisco.com/c/en/us/products/unified-communications/ata-190-series-analog-telephone-adapters/index.html für Modelle und weitere Informationen.
Headsets:
Cisco-Headset 500-Serie
Siehe <UNK> https://www.cisco.com/c/en/us/products/collaboration-endpoints/headset-500-series/index.html <UNK> für Modelle und mehr Informationen.
- Room OS-Geräte:
Webex Room- und Room Kit-Serie
Webex Desk-Serie
Webex Board-Serie
Geräteintegration
Weitere Informationen zum Integrieren und Verwalten von Room OS- und MPP-Geräten für Webex für Cisco BroadWorks finden Sie im Handbuch zur Geräteintegration für Webex für Cisco BroadWorks.
Geräteprofile
Im Folgenden finden Sie die DTAF-Dateien, die Sie auf Ihre Anwendungsserver laden müssen, um die Webex-App als Calling-Client zu unterstützen. Es handelt sich um die gleichen DTAF-Dateien wie für UC-One SaaS, es gibt jedoch eine neue config-wxt.xml.template
für die Webex-App verwendet wird.
Um die neuesten Geräteprofile herunterzuladen, rufen Sie die Site „Application Delivery Platform Software Downloads “ auf, um die neuesten DTAF-Dateien abzurufen. Diese Downloads funktionieren sowohl für ADP als auch für XSP.
Client-Name |
Geräteprofiltyp und Paketname |
---|---|
Webex Mobile Vorlage |
Identität/Geräteprofiltyp: Verbinden – Mobil DTAF: Konfigurationsdatei: |
Webex Tablet Vorlage |
Identität/Geräteprofiltyp: Verbinden – Tablet DTAF: Konfigurationsdatei: |
Webex Desktop Vorlage |
Identität/Geräteprofiltyp: Business Communicator – PC DTAF: Konfigurationsdatei: |
Geräteprofil identifizieren
Allen Webex für Cisco BroadWorks-Benutzern muss in BroadWorks ein Identität/Geräteprofil zugewiesen sein, das eines der oben genannten Geräteprofile verwendet, um Anrufe mit der Webex-App zu tätigen. Das Profil stellt die Konfiguration bereit, mit der der Benutzer Anrufe tätigen kann.
Abrufen von OAuth-Anmeldeinformationen für Webex für Cisco BroadWorks
Erheben Sie eine Serviceanfrage bei Ihrem Onboarding-Agenten oder bei Cisco TAC, um Cisco OAuth für Ihr Cisco Identity Provider Federation-Konto bereitzustellen.
Verwenden Sie den folgenden Anforderungstitel für die entsprechenden Funktionen:
XSP AuthService Configuration“, um den Dienst auf XSP zu konfigurieren.
„NPS-Konfiguration für Authentifizierungsproxy-Setup“, um NPS für die Verwendung eines Authentifizierungsproxys zu konfigurieren.
CI User UUID Sync' für CI User UUID sync. Weitere Informationen zu dieser Funktion finden Sie unter: Cisco BroadWorks-Unterstützung für CI UUID .
Konfigurieren Sie BroadWorks, um die Cisco-Rechnungsstellung für BroadWorks und Webex Für BroadWorks-abonnements zu aktivieren.
Cisco stellt Ihnen eine OAuth-Client-ID, ein Client-Geheimnis und ein Aktualisierungstoken zur Verfügung, das 60 Tage lang gültig ist. Wenn das Token vor der Verwendung abläuft, können Sie eine andere Anfrage stellen.
Wenn Sie bereits Cisco OAuth Identity Provider-Anmeldeinformationen erhalten haben, schließen Sie eine neue Dienstanforderung ab, um Ihre Anmeldeinformationen zu aktualisieren. |
Bestellzertifikate
Zertifikatanforderungen für die TLS-Authentifizierung
Sie benötigen Sicherheitszertifikate, die von einer bekannten Zertifizierungsstelle signiert und für alle erforderlichen Anwendungen auf Ihren Öffentlichen XSPs bereitgestellt werden. Diese werden verwendet, um die TLS-Zertifikatsverifizierung für alle eingehenden Verbindungen zu Ihren XSP-Servern zu unterstützen.
Diese Zertifikate sollten Ihren öffentlichen vollqualifizierten XSP-Domänennamen als allgemeinen Antragstellernamen oder alternativen Antragstellernamen enthalten.
Die genauen Anforderungen für die Bereitstellung dieser Serverzertifikate hängen davon ab, wie Ihre öffentlich zugänglichen XSPs bereitgestellt werden:
Über einen TLS-Überbrückungsproxy
Über einen TLS-Passthrough-Proxy
Direkt zum XSP
Das folgende Diagramm fasst zusammen, wo das CA-signierte öffentliche Serverzertifikat in diesen drei Fällen geladen werden muss:
Die öffentlich unterstützten Zertifizierungsstellen, die die Webex-App für die Authentifizierung unterstützt, sind unter „Unterstützte Zertifizierungsstellen für Webex-Hybriddienste“ aufgeführt.
TLS-Zertifikatanforderungen für TLS-Bridge-Proxy
Das öffentlich signierte Serverzertifikat wird in den Proxy geladen.
Der Proxy übergibt dieses öffentlich signierte Serverzertifikat an Webex.
Webex vertraut der öffentlichen Zertifizierungsstelle, die das Serverzertifikat des Proxy signiert hat.
Ein internes CA-signiertes Zertifikat kann auf den XSP geladen werden.
Der XSP übergibt dieses intern signierte Serverzertifikat an den Proxy.
Der Proxy vertraut der internen CA, die das XSP-Serverzertifikat signiert hat.
TLS-Zertifikatanforderungen für TLS-Passthrough-Proxy oder XSP in DMZ
Das öffentlich signierte Serverzertifikat wird in die XSPs geladen.
Die XSPs präsentieren öffentlich signierte Serverzertifikate für Webex.
Webex vertraut der öffentlichen CA, die die Serverzertifikate der XSPs signiert hat.
Zusätzliche Zertifikatanforderungen für die Mutual TLS-Authentifizierung über die CTI-Schnittstelle
Beim Herstellen einer Verbindung mit der CTI-Schnittstelle legt Webex ein Client-Zertifikat als Teil der Mutual TLS-Authentifizierung vor. Das CA-/Chain-Zertifikat des Webex-Clientzertifikats ist über Control Hub zum Download verfügbar.
So laden Sie das Zertifikat herunter:
Melden Sie sich bei Partner Hub an, gehen Sie zu
und klicken Sie auf den Link zum Herunterladen des Zertifikats.Die genauen Anforderungen für die Bereitstellung dieser Webex CA-Zertifikatskette hängen davon ab, wie Ihre öffentlich zugänglichen XSPs bereitgestellt werden:
Über einen TLS-Überbrückungsproxy
Über einen TLS-Passthrough-Proxy
Direkt zum XSP
Das folgende Diagramm fasst die Zertifikatanforderungen in diesen drei Fällen zusammen:
(Option) Zertifikatanforderungen für TLS-Bridge-Proxy
Webex legt dem Proxy ein öffentlich signiertes Clientzertifikat vor.
Der Proxy vertraut der internen Cisco CA, die das Clientzertifikat signiert hat. Sie können diese CA/Kette aus Control Hub herunterladen und zum Vertrauensspeicher des Proxys hinzufügen. Das öffentlich signierte XSP-Serverzertifikat wird ebenfalls in den Proxy geladen.
Der Proxy übergibt das öffentlich signierte Serverzertifikat an Webex.
Webex vertraut der öffentlichen Zertifizierungsstelle, die das Serverzertifikat des Proxy signiert hat.
Der Proxy stellt den XSPs ein intern signiertes Clientzertifikat vor.
Für dieses Zertifikat muss das Erweiterungsfeld „Erweiterte Schlüsselnutzung“ x509.v3 mit der BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 und dem TLS clientAuth ausgefüllt sein. Z. B.:
X509v3 extensions: X509v3 Extended Key Usage: 1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication
Der CN des internen Zertifikats muss bwcticlient.webex.com sein.
Beachten Sie bei der Generierung interner Client-Zertifikate für den Proxy, dass SAN-Zertifikate nicht unterstützt werden. Interne Serverzertifikate für den XSP können SAN sein.
Öffentliche Zertifizierungsstellen sind möglicherweise nicht bereit, Zertifikate mit der proprietären BroadWorks-OID zu signieren, die erforderlich ist. Im Falle eines Überbrückungsproxys müssen Sie möglicherweise eine interne CA verwenden, um das Clientzertifikat zu signieren, das der Proxy dem XSP vorlegt.
Die XSPs vertrauen der internen CA.
Die XSPs präsentieren ein intern signiertes Serverzertifikat.
Der Proxy vertraut der internen Zertifizierungsstelle.
Die „ ClientIdentity“ des Anwendungsservers enthält den CN des intern signierten Clientzertifikats, das dem XSP vom Proxy vorgelegt wird.
(Option) Zertifikatanforderungen für TLS-Passthrough Proxy oder XSP in DMZ
Webex stellt den XSPs ein von Cisco internes CA-signiertes Clientzertifikat vor.
Die XSPs vertrauen der internen Cisco CA, die das Clientzertifikat signiert hat. Sie können diese CA/Kette aus Control Hub herunterladen und zum Vertrauensspeicher des Proxys hinzufügen. Das öffentlich signierte XSP-Serverzertifikat wird auch in die XSPs geladen.
Die XSPs präsentieren die öffentlich signierten Serverzertifikate für Webex.
Webex vertraut der öffentlichen CA, die die Serverzertifikate der XSPs signiert hat.
Der Anwendungsserver ClientIdentity enthält den CN des von Cisco signierten Clientzertifikats, das dem XSP von Webex vorgelegt wird.
Ihr Netzwerk vorbereiten
Weitere Informationen zu Verbindungen, die von Webex für Cisco BroadWorks verwendet werden, finden Sie unter: Netzwerkanforderungen für Webex für Cisco BroadWorks . Dieser Artikel enthält eine Liste der IP-Adressen, Ports und Protokolle, die zum Konfigurieren der Firewall-Ingress- und -Egress-Regeln erforderlich sind.
Netzwerkanforderungen für Webex-Dienste
In den vorhergehenden Firewall-Tabellen für Ingress- und Egress-Regeln werden nur Verbindungen dokumentiert, die spezifisch für Webex für Cisco BroadWorks sind. Allgemeine Informationen zu Verbindungen zwischen der Webex-App und der Webex-Cloud finden Sie unter Netzwerkanforderungen für Webex-Dienste . Dieser Artikel ist allgemein für Webex, aber in der folgenden Tabelle sind die verschiedenen Abschnitte des Artikels und die Relevanz der einzelnen Abschnitte für Webex für Cisco BroadWorks aufgeführt.
Abschnitt zum Artikel zu Netzwerkanforderungen |
Relevanz der Informationen |
---|---|
Zusammenfassung der von Webex unterstützten Gerätetypen und Protokolle |
Informativ |
Transportprotokolle und Verschlüsselungscodes für in der Cloud registrierte Webex-Apps und -Geräte |
Informativ |
Muss gelesen werden |
|
Muss gelesen werden |
|
Domänen und URLs, auf die für Webex-Dienste zugegriffen werden muss |
Muss gelesen werden |
Optional |
|
Optional |
|
Optional |
|
Optional |
|
Optional |
|
Eine Zusammenfassung weiterer Webex-Hybriddienste und -dokumentation |
Optional |
Webex-Dienste für FedRAMP-Kunden |
k. A. |
Zusätzliche Informationen
Weitere Informationen finden Sie unter Webex App Firewall Whitepaper (PDF).
BroadWorks-Redundanzunterstützung
Die Webex Cloud-Dienste und die Webex-Client-Apps, die auf das Netzwerk des Partners zugreifen müssen, unterstützen vollständig die vom Partner bereitgestellte Broadworks XSP-Redundanz. Wenn ein XSP oder ein Standort für eine geplante Wartung oder aus einem ungeplanten Grund nicht verfügbar ist, können die Webex-Dienste und -Apps zu einem anderen XSP oder Standort wechseln, der vom Partner bereitgestellt wird, um eine Anfrage abzuschließen.
Netzwerktopologie
Die Broadworks XSPs können direkt im Internet bereitgestellt werden oder sich in einer DMZ befinden, die von einem Lastausgleichselement wie der F5 BIG-IP angesteuert wird. Zur Bereitstellung von Geo-Redundanz können die XSPs in zwei (oder mehr) Rechenzentren bereitgestellt werden, wobei jeder von einem Lastenausgleichsmodul mit jeweils einer öffentlichen IP-Adresse angesteuert werden kann. Wenn sich die XSPs hinter einem Lastenausgleich befinden, sehen die Webex-Mikrodienste und die App nur die IP-Adresse des Lastenausgleichs und Broadworks scheint nur einen XSP zu haben, selbst wenn mehrere XSPs zurückliegen.
Im folgenden Beispiel werden die XSPs an zwei Standorten, Standort A und Standort B, eingesetzt. Es gibt zwei XSPs, die von einem Lastenausgleichs an jedem Standort vorgegeben werden. Standort A hat XSP1- und XSP2-Fronten von LB1 und Standort B hat XSP3- und XSP4-Fronten von LB2. Lediglich die Lastenausgleichsträger werden im öffentlichen Netz exponiert, die XSPs in den privaten Netzwerken der DMZ.
Webex Cloud-Dienste
DNS-Konfiguration
Die Webex Cloud-Mikrodienste müssen den/die Broadworks XSP-Server(s) für die Verbindung mit den Xsi-Schnittstellen, dem Authentifizierungsdienst und CTI finden können.
Die Webex Cloud-Mikrodienste führen eine DNS A/AAAA-Suche des konfigurierten XSP-Hostnamens durch und stellen eine Verbindung mit der zurückgegebenen IP-Adresse her. Dies kann ein Edge-Element für den Lastausgleich sein oder der XSP-Server selbst. Wenn mehrere IP-Adressen zurückgegeben werden, wird die erste IP in der Liste ausgewählt. SRV-Suche wird derzeit nicht unterstützt.
Beispiel: Der DNS A-Datensatz des Partners zur Entdeckung von Round-Robin ausgewogenen internetbasierten XSP-Server-/Lastenausgleich.
Datensatztyp |
Name |
Ziel |
Zweck |
---|---|---|---|
A |
|
|
Punkte auf LB1 (Standort A) |
A |
|
|
Punkte auf LB2 (Standort B) |
Failover
Wenn die Webex-Microservices eine Anforderung an den XSP/Load Balancer senden und die Anforderung fehlschlägt, können verschiedene Dinge passieren:
Wenn der Fehler auf einem Netzwerkfehler beruht (z. B.: TCP, SSL) markieren die Webex-Mikrodienste die IP als blockiert und führen sofort eine Weiterleitung zur nächsten IP durch.
Wenn ein Fehlercode (HTTP5xx) zurückgegeben wird, markieren die Webex-Mikrodienste die IP als blockiert und führen sofort eine Weiterleitung zur nächsten IP durch.
Wenn innerhalb von 2 Sekunden keine HTTP-Antwort empfangen wird, wird bei der Anforderung eine Zeitüberschreitung durchgeführt, und die Webex-Mikrodienste markieren die IP als blockiert und führen einen Routenvorgriff zur nächsten IP durch.
Jede Anforderung wird 3 Mal versucht, bevor ein Fehler an den Microservice zurückgemeldet wird.
Wenn sich eine IP in der Sperrliste befindet, wird sie nicht in die Liste der Adressen aufgenommen, die Sie beim Senden einer Anforderung an ein XSP versuchen sollten. Nach einem vorgegebenen Zeitraum läuft eine blockierte IP ab und kehrt in die Liste zurück, um zu versuchen, wenn eine andere Anforderung gestellt wird.
Wenn alle IP-Adressen blockiert sind, versucht der Microservice weiterhin, die Anforderung durch zufällige Auswahl einer IP-Adresse aus der Sperrliste zu senden. Bei erfolgreicher Ausführung wird diese IP-Adresse aus der Sperrliste entfernt.
Status
Der Status der Konnektivität der Webex Cloud-Dienste mit den XSPs oder Load Balancern kann in Control Hub angezeigt werden. Unter einem BroadWorks Calling-Cluster wird für jede der folgenden Schnittstellen ein Verbindungsstatus angezeigt:
XSI-Aktionen
XSI-Ereignisse
Authentifizierungsdienst
Der Verbindungsstatus wird aktualisiert, wenn die Seite geladen wird oder während der Eingabeaktualisierungen. Der Verbindungsstatus kann Folgendes sein:
Grün: Wenn die Schnittstelle auf einem der IPs in der A-Datensatzsuche erreicht werden kann.
Rot: Wenn alle IPs in der A-Datensatzsuche nicht erreichbar sind und die Schnittstelle nicht verfügbar ist.
Die folgenden Dienste nutzen die Microservices, um sich mit den XSPs zu verbinden und sind von der Verfügbarkeit der XSP-Schnittstelle betroffen:
Webex-App-Anmeldung
Aktualisierung des Webex-App-Tokens
Nicht vertrauenswürdige E-Mail/Selbstaktivierung
BroadWorks-Dienstzustandsprüfung
Webex-App
DNS-Konfiguration
Die Webex-App greift auf die Dienste Xtended Services Interface (XSI-Actions & XSI-Events) und Device Management Service (DMS) auf dem XSP zu.
Um den XSI-Dienst zu finden, führt die Webex-App eine DNS SRV-Suche durch für _xsi-client._tcp.<webex app xsi domain>
. Der SRV verweist auf die konfigurierte URL für die XSP-Hosts oder Load Balancer für den XSI-Dienst. Wenn die SRV-Suche nicht verfügbar ist, greift die Webex-App auf die A/AAAA-Suche zurück.
Der SRV kann auf mehrere A/AAAA-Ziele aufgelöst werden. Jeder A/AAAA-Datensatz muss jedoch nur einer einzigen IP-Adresse zugeordnet werden. Wenn mehrere XSPs in einer DMZ hinter dem Lastenausgleichs-/Edge-Gerät vorhanden sind, muss der Lastenausgleichs so konfiguriert werden, dass die Sitzungspersistenz aufrechterhalten bleibt, um alle Anfragen derselben Sitzung an denselben XSP weiterzuleiten. Wir leiten diese Konfiguration ein, da die XSI-Event-Heartbeats des Clients zu demselben XSP gehen müssen, der zum Einrichten des Event-Kanals verwendet wird.
In Beispiel 1 ist der A/AAAA-Datensatz für webex-app-xsp.example.com nicht vorhanden und muss es nicht. Wenn Ihr DNS vorschreibt, dass ein A/AAAA-Datensatz definiert werden muss, dann sollte nur 1 IP-Adresse zurückgegeben werden. Unabhängig davon muss der SRV weiterhin für die Webex-App definiert sein. Wenn die Webex-App den A/AAAA-Namen verwendet, der zu mehr als einer IP-Adresse aufgelöst wird, oder wenn das Lastenausgleichs-/Edge-Element die Sitzungspersistenz nicht aufrechterhält, sendet der Client schließlich Heartbeats an einen XSP, bei dem kein Ereigniskanal eingerichtet wurde. Dies führt dazu, dass der Kanal abgerissen wird, und auch zu einem deutlich größeren internen Datenverkehr, der die Leistung Ihres XSP-Clusters beeinträchtigt. Da die Webex Cloud und die Webex App unterschiedliche Anforderungen in der A/AAAA-Datensatzsuche haben, müssen Sie für den Zugriff auf Ihre XSPs einen separaten FQDN für die Webex Cloud und die Webex App verwenden. Wie in den Beispielen gezeigt, verwendet Webex Cloud Einen Datensatz |
Beispiel 1 – Mehrere XSPs, jeweils hinter separaten Lastenausgleichern
In diesem Beispiel weist der SRV darauf hin, A-Datensätze zu mutillen, wobei jeder A-Datensatz auf einen anderen Lastenausgleichsträger an einer anderen Stelle verweist. Die Webex-App verwendet immer die erste IP-Adresse in der Liste und wird nur zum nächsten Datensatz verschoben, wenn die erste nicht verfügbar ist.
Datensatztyp |
Aufzeichnen |
Ziel |
Zweck |
---|---|---|---|
SRV |
|
|
Client-Erkennung der Xsi-Schnittstelle |
SRV |
|
|
Client-Erkennung der Xsi-Schnittstelle |
A |
|
|
Verweist auf LB1 (Standort A) |
A |
|
|
Punkte auf LB2 (Standort B) |
Beispiel 2 – Mehrere XSPs hinter einem einzelnen Lastenausgleichs (mit TLS-Brücke)
Für die anfängliche Anforderung wählt der Lastenausgleichsmotor einen zufälligen XSP aus. XSP gibt einen Cookie zurück, den die Webex-App in zukünftigen Anforderungen enthält. Für zukünftige Anfragen verwendet der Load Balancer das Cookie, um die Verbindung zum richtigen XSP weiterzuleiten, um sicherzustellen, dass der Event-Kanal nicht bricht.
Datensatztyp |
Aufzeichnen |
Ziel |
Zweck |
---|---|---|---|
SRV |
|
|
Lastenausgleich |
A |
LB.example.com |
|
IP-Adresse des Lastenausgleichs (XSPs liegen hinter Lastenausgleichs) |
DMS-URL
Während des Anmeldevorgangs ruft die Webex-App auch die DMS-URL ab, um die Konfigurationsdatei herunterzuladen. Der Host in der URL wird geparst, und die Webex-App führt eine DNS A/AAAA-Suche des Hosts durch, um eine Verbindung mit dem XSP herzustellen, der den DMS-Dienst hostet.
Beispiel: DNS A-Datensatz für die Entdeckung von Round-Robin ausgewogenen internetbasierten XSP-Server/Load Balancers durch die Webex-App zum Herunterladen von Konfigurationsdateien über DMS:
Datensatztyp |
Name |
Ziel |
Zweck |
---|---|---|---|
A |
|
|
Verweist auf LB1 (Standort A) |
A |
|
|
Punkte auf LB2 (Standort B) |
So findet die Webex-App XSP-Adressen
Der Client versucht, die XSP-Knoten mit dem folgenden DNS-Flow zu lokalisieren:
Der Client ruft anfänglich Xsi-Actions/Xsi-Events-URLs aus der Webex Cloud ab (Sie haben sie beim Erstellen des zugehörigen BroadWorks-Anrufclusters eingegeben). Der Xsi-Hostname/die Domäne wird über die URL analysiert, und der Client führt eine SRV-Suche wie folgt durch:
Client führt eine SRV-Suche für _xsi-client durch._tcp.<xsi domain="">
Wenn die SRV-Suche ein oder mehrere A/AAAA-Ziele zurückgibt:
Der Client führt eine A/AAAA-Suche nach diesen Zielen durch und speichert die zurückgegebenen IP-Adressen im Zwischenspeicher.
Der Client verbindet sich mit einem der Ziele (und somit seinem A/AAAA-Datensatz mit einer einzigen IP-Adresse) basierend auf der SRV-Priorität, dann der Gewichtung (oder zufällig, wenn alle gleich sind).
Wenn die SRV-Suche keine Ziele zurückgibt:
Der Client führt eine A/AAAA-Suche des Xsi-Root-Parameters durch und versucht dann, eine Verbindung mit der zurückgegebenen IP-Adresse herzustellen. Dies kann ein Edge-Element für den Lastausgleich sein oder der XSP-Server selbst.
Wie bereits erwähnt, muss der A/AAAA-Datensatz aus den gleichen Gründen zu einer IP-Adresse aufgelöst werden.
(Optional) Anschließend können Sie mithilfe der folgenden Tags benutzerdefinierte XSI-Aktionen/XSI-Ereignisse in der Gerätekonfiguration für die Webex-App angeben:
<protocols> <xsi> <paths> <root>%XSI_ROOT_WXT%</root> <actions>%XSI_ACTIONS_PATH_WXT%</actions> <events>%XSI_EVENTS_PATH_WXT%</events> </paths> </xsi> </protocols>
Diese Konfigurationsparameter haben Vorrang vor allen Konfigurationen in Ihrem BroadWorks-Cluster im Control Hub.
Wenn sie vorhanden sind, wird der Client mit der ursprünglichen XSI-Adresse verglichen, die er über die BroadWorks-Cluster-Konfiguration erhalten hat.
Wenn ein Unterschied erkannt wird, initialisiert der Client seine XSI-Aktionen/XSI-Ereignisse-Konnektivität neu. Der erste Schritt besteht darin, denselben DNS-Lookup-Prozess durchzuführen, der unter Schritt 1 aufgeführt ist – diesmal wird eine Suche nach dem Wert im %XSI_ROOT_WXT% Parameter aus seiner Konfigurationsdatei angefordert.
Stellen Sie sicher, dass Sie die entsprechenden SRV-Datensätze erstellen, wenn Sie dieses Tag verwenden, um die Xsi-Schnittstellen zu ändern.
Failover
Während der Anmeldung führt die Webex-App eine DNS SRV-Suche nach _xsi-client._tcp.<xsi domain=""> durch, erstellt eine Liste der Hosts und stellt basierend auf der SRV-Priorität und der Gewichtung eine Verbindung zu einem der Hosts her. Dieser verbundene Host wird für alle zukünftigen Anforderungen ausgewählt. Ein Event-Kanal wird dann für den ausgewählten Gastgeber geöffnet und ein Heartbeat wird regelmäßig gesendet, um den Kanal zu überprüfen. Alle Anfragen, die nach dem ersten gesendet werden, enthalten ein Cookie, das in der HTTP-Antwort zurückgegeben wird. Daher ist es wichtig, dass der Lastenausgleichsmodule die Sitzungspersistenz (Affinität) aufrechterhält und immer Anfragen an denselben XSP-Backend-Server sendet.
Wenn eine Anforderung oder eine Heartbeat-Anforderung an einen Gastgeber fehlschlägt, können verschiedene Dinge passieren:
Wenn der Fehler auf einem Netzwerkfehler beruht (z. B.: TCP, SSL) wechselt die Webex-App-Route sofort zum nächsten Gastgeber in der Liste.
Wenn ein Fehlercode (HTTP5xx) zurückgegeben wird, markiert die Webex-App diese IP-Adresse als blockiert und leitet die Fortschritte an den nächsten Host in der Liste weiter.
Wenn eine Antwort nicht innerhalb eines Zeitraums empfangen wird, wird die Anforderung aufgrund einer Zeitüberschreitung als fehlgeschlagen betrachtet und die nächsten Anforderungen werden an den nächsten Gastgeber gesendet. Die Anfrage mit Zeitüberschreitung wird jedoch als fehlgeschlagen betrachtet. Einige Anfragen werden nach einem Fehler erneut versucht (mit zunehmender Wiederholungszeit). Die Anfragen, dass das angenommene Nicht-Vital nicht erneut versucht wird.
Wenn ein neuer Gastgeber erfolgreich versucht wird, wird er zum neu ausgewählten Gastgeber, wenn der Gastgeber in der Liste vorhanden ist. Nachdem der letzte Gastgeber in der Liste versucht wurde, wird die Webex-App auf den ersten verschoben.
Wenn bei einem Heartbeat zwei aufeinanderfolgende Anforderungsfehler auftreten, initialisiert die Webex-App den Event-Kanal neu.
Beachten Sie, dass die Webex-App kein Failback durchführt und die DNS-Diensterkennung nur einmal bei der Anmeldung durchgeführt wird.
Während der Anmeldung versucht die Webex-App, die Konfigurationsdatei über die XSP/Dms-Schnittstelle herunterzuladen. Es führt eine A/AAAA-Datensatzsuche des Hosts in der abgerufenen DMS-URL durch und stellt eine Verbindung zur ersten IP her. Es wird zuerst versuchen, die Anforderung zum Herunterladen der Konfigurationsdatei mit einem SSO-Token zu senden. Wenn dies aus irgendeinem Grund fehlschlägt, wird es erneut versuchen, jedoch mit dem Benutzernamen und dem Kennwort des Geräts.