Przygotuj swoje środowisko

Punkty decyzyjne

rozwaga Pytania, na które należy odpowiedzieć Zasoby

Architektura & Infrastruktura

Ile XSPs?

Jak biorą mTLS?

Planer pojemności systemu Cisco BroadWorks

Przewodnik inżynierii systemu Cisco BroadWorks

Odwołanie do interfejsu wiersza polecenia XSP

Niniejszy dokument

Inicjowanie obsługi administracyjnej dla klientów i użytkowników

Czy możesz twierdzić, że ufasz e-mailom w BroadWorks?

Czy chcesz, aby użytkownicy podawali adresy e-mail w celu aktywowania własnych kont?

Czy możesz tworzyć narzędzia do korzystania z naszego INTERFEJSU API?

Publiczne dokumenty API pod adresem https://developer.webex.com

Niniejszy dokument

Wygląd i elementy graficzne Jakiego koloru i logo chcesz użyć? Artykuł o znakowaniu aplikacji Webex
Szablony Jakie są twoje różne przypadki użycia klienta? Niniejszy dokument
Funkcje subskrybenta na klienta/przedsiębiorstwo/grupę Wybierz pakiet, aby zdefiniować poziom usługi dla na szablon. Podstawowy, standardowy, premium lub softphone.

Niniejszy dokument

Macierz funkcji/pakietów

Uwierzytelnianie użytkownika BroadWorks lub Webex Niniejszy dokument
Karta inicjowania obsługi administracyjnej (dla opcji inicjowania obsługi administracyjnej przepływowego)

Czy używasz już Zintegrowanego IM&P, np.

Czy zamierzasz używać wielu szablonów?

Czy przewiduje się bardziej powszechny przypadek użycia?

Niniejszy dokument

Odwołanie do interfejsu wiersza polecenia serwera aplikacji

Architektura & Infrastruktura

  • Od jakiej skali zamierzasz zacząć? Jest możliwe skalowanie w górę w przyszłości, ale bieżące oszacowanie użycia powinno napędzać planowanie infrastruktury.

  • Pracuj z menedżerem konta Cisco / przedstawicielem handlowym, aby powspościć infrastrukturę XSP, zgodnie z Cisco BroadWorks System Capacity Planner ( ) ihttps://xchange.broadsoft.com/node/1051462Cisco BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/1051496).

  • W jaki sposób Webex będzie wzajemne połączenia TLS do XSP? Bezpośrednio do XSP w DMZ, lub za pośrednictwem serwera proxy TLS? Ma to wpływ na zarządzanie certyfikatami i adresy URL używane dla interfejsów. (Nieobsługujemy niezaszyfrowanych połączeń TCP z krawędziąsieci).

Inicjowanie obsługi administracyjnej dla klientów i użytkowników

Która metoda inicjowania obsługi administracyjnej użytkownika najbardziej Ci odpowiada?

  • Flowthrough inicjowania obsługi administracyjnej z zaufanych wiadomoście-mail: Przypisując usługę "Integrated IM&P" w BroadWorks, subskrybent jest automatycznie aprowizowany w webex.

    Jeśli można również potwierdzić, że adresy e-mail subskrybenta w BroadWorks są prawidłowe i unikatowe dla Webex, a następnie można użyć "zaufanego e-mail" wariant flowthrough inicjowania obsługi administracyjnej. Konta Webex subskrybenta są tworzone i aktywowane bez ich interwencji; po prostu pobrać klienta i zalogować się.

    Adres e-mail jest kluczowym atrybutem użytkownika w webex. W związku z tym Usługodawca musi podać prawidłowy adres e-mail użytkownika w celu udostępnienia go usługom Webex. Musi to być atrybut identyfikatora e-mail użytkownika w BroadWorks. Zaleca się skopiowanie go do atrybutu identyfikator alternatywny.

  • Flowthrough inicjowania obsługi administracyjnej bez zaufanych wiadomoście-mail: Jeśli nie można ufać adresom e-mail subskrybenta, nadal można przypisać zintegrowaną usługę IM&P w BroadWorks do aprowizowania użytkowników w webex.

    Za pomocą tej opcji konta są tworzone podczas przypisywania usługi, ale subskrybenci muszą podać i zweryfikować swoje adresy e-mail, aby aktywować konta Webex.

  • Samoaicymiszwanie obsługi administracyjnej przezużytkownika: Ta opcja nie wymaga przypisania usługi IM&P w BroadWorks. Zamiast tego użytkownik (lub twoi klienci) rozpowszechniają łącze aprowizującego i łącza do pobierania różnych klientów wraz z jego znakowaniem i instrukcjami.

    Subskrybenci podążają za linkiem, a następnie podają i weryfikują swoje adresy e-mail, aby utworzyć i aktywować swoje konta Webex. Następnie pobierają klienta i logują się, a Webex pobiera dodatkową konfigurację na ich temat z BroadWorks (w tym ich numery podstawowe).

  • Sp kontrolowane inicjowania obsługi administracyjnej za pośrednictwem interfejsówAPI: Webex udostępnia zestaw publicznych interfejsów API, które umożliwiają dostawcom usług tworzenie inicjowania obsługi administracyjnej użytkownika/subskrybenta w istniejących przepływach pracy.

Szablony klienta

Szablony klientów umożliwiają definiowanie parametrów, za pomocą których klienci i powiązani subskrybenci są automatycznie aprowizowani w witrynie Webex dla BroadWorks. Można skonfigurować wiele szablonów klienta zgodnie z wymaganiami, ale po pokładzie klienta jest skojarzony tylko z jednym szablonem (nie można zastosować wiele szablonów do jednego klienta).

Niektóre parametry szablonu podstawowego są wymienione poniżej.

Pakiet

  • Podczas tworzenia szablonu należy wybrać pakiet domyślny (szczegółowe informacje można znaleźć w sekcji Przegląd). Wszyscy użytkownicy, którzy są aprowizacji z tego szablonu, czy przez flowthrough- lub samoeksprowiedzenie, otrzymują pakiet domyślny.

  • Masz kontrolę nad wyborem pakietu dla różnych klientów, tworząc wiele szablonów i wybierając różne pakiety domyślne w każdym. Następnie można rozpowszechniać różne łącza inicjowania obsługi administracyjnej lub różne karty inicjowania obsługi administracyjnej dla przedsiębiorstw, w zależności od wybranej metody inicjowania obsługi administracyjnej dla tych szablonów.

  • Pakiet określonych subskrybentów można zmienić z tego domyślnego interfejsu API inicjowania obsługi administracyjnej (zobacz Integrowanie z webex dla interfejsu API inicjowania obsługi administracyjnej BroadWorks w sekcji Odwołania) lub za pośrednictwem Centrum partnerów.

  • Nie można zmienić pakietu subskrybenta z BroadWorks. Przypisanie zintegrowanej usługi IM&P jest włączone lub wyłączone; Jeśli subskrybentowi jest przypisana ta usługa w BroadWorks, szablon Centrum partnerów skojarzony z adresem URL inicjowania obsługi administracyjnej tego dostawcy definiuje pakiet.

odsprzedawcy i przedsiębiorstw lub usługodawcy i grup?

  • Sposób konfigurowania systemu BroadWorks ma wpływ na przepływ poprzez inicjowanie obsługi administracyjnej. Jeśli jesteś sprzedawcą w przedsiębiorstwach, musisz włączyć tryb Enterprise podczas tworzenia szablonu.
  • Jeśli system BroadWorks jest skonfigurowany w trybie usługodawcy, można wyłączyć tryb Enterprise w szablonach.
  • Jeśli planujesz aprowizować organizacje odbiorców przy użyciu obu trybów BroadWorks, należy użyć różnych szablonów dla grup i przedsiębiorstw.

Upewnij się, że zastosowano poprawki BroadWorks, które są wymagane do obsługi administracyjnej przepływu. Aby uzyskać szczegółowe informacje, zobacz Wymagane poprawki z aprowizowania przepływuprzez .

Tryb uwierzytelniania

W jaki sposób subskrybenci klientów będą uwierzytelniać się?

Tryb uwierzytelniania BroadWorks ( BroadWorks ) Webex
Podstawowa tożsamość użytkownika Identyfikator użytkownika BroadWorks Adres e-mail
dostawca tożsamości

BroadWorks.

  • Jeśli skonfigurujesz bezpośrednie połączenie z BroadWorks, aplikacja Webex uwierzytelnia się bezpośrednio na serwerze BroadWorks. Należy zauważyć, że ta opcja wymaga włączenia przełącznika funkcji.

  • W przeciwnym razie uwierzytelnianie w BroadWorks jest ułatwione za pośrednictwem usługi pośredniczącej obsługiwanej przez webex.

Wspólna tożsamość Cisco
Uwierzytelnianie wieloskładnikowe? Nie Wymaga customer IdP, który obsługuje uwierzytelnianie wieloskładnikowe.

Ścieżka sprawdzania poprawności poświadczeń

  1. Przeglądarka jest uruchamiana, gdy użytkownik dostarcza posoń wiadomość e-mail do początkowego przepływu logowania i odkrywa tryb uwierzytelniania.

  2. Przeglądarka jest następnie przekierowywany do Webex hostowane BroadWorks strony logowania (Ta strona jest brandable)

  3. Użytkownik dostarcza identyfikator użytkownika i hasło BroadWorks na stronie logowania.

  4. Poświadczenia użytkownika są sprawdzane w u użytkownika w ucho.

  5. Po sukcesie kod autoryzacji jest uzyskiwany z webex. Służy to do uzyskania niezbędnych tokenów dostępu dla usług Webex.

  1. Przeglądarka jest uruchamiana, gdy użytkownik dostarcza posoń wiadomość e-mail do początkowego przepływu logowania i odkrywa tryb uwierzytelniania.

  2. Przeglądarka jest przekierowana do IdP (cisco wspólnej tożsamości lub customer IdP), gdzie zostaną one przedstawione z portalu logowania.

  3. Użytkownik dostarcza odpowiednie poświadczenia na stronie logowania

  4. Uwierzytelnianie wieloskładnikowe może mieć miejsce, jeśli obsługuje to IdP klienta.

  5. Po sukcesie kod autoryzacji jest uzyskiwany z webex. Służy to do uzyskania niezbędnych tokenów dostępu dla usług Webex.


Aby uzyskać bardziej szczegółowy podział przepływu logowania z bezpośrednim uwierzytelnianiem do BroadWorks, zobacz temat przepływu logowania logowania w sekcjiWebex dla BroadWorks Reference.

Wiele umów partnerskich

Czy zamierzasz sub-licencji Webex dla BroadWorks do innego dostawcy usług? W takim przypadku każdy dostawca usług będzie potrzebował odrębnej organizacji partnerskiej w Webex Control Hub, aby umożliwić im aprowizowanie rozwiązania dla ich bazy klientów.

Karta inicjowania obsługi administracyjnej i szablony

Podczas korzystania z obsługi administracyjnej przepływu, adres URL inicjowania obsługi administracyjnej wprowadzone w BroadWorks pochodzi z szablonu w Centrum sterowania. Możesz mieć wiele szablonów, a zatem wiele adresów URL inicjowania obsługi administracyjnej. Dzięki temu można wybrać, w zależności od przedsiębiorstwa, który pakiet ma zastosowanie do subskrybentów, gdy są one przyznawane zintegrowanej usługi IM&P.

Należy rozważyć, czy chcesz ustawić adres URL inicjowania obsługi administracyjnej na poziomie systemu jako domyślną ścieżkę inicjowania obsługi administracyjnej i szablon, który ma być używany w tym celu. W ten sposób wystarczy tylko jawnie ustawić adres URL inicjowania obsługi administracyjnej dla tych przedsiębiorstw, które potrzebują innego szablonu.

Ponadto należy pamiętać, że może już być przy użyciu adresu URL inicjowania obsługi administracyjnej na poziomie systemu, na przykład z UC-One SaaS. W takim przypadku można zachować adres URL poziomu systemu do inicjowania obsługi administracyjnej użytkowników w uc-one SaaS i zastąpić dla tych przedsiębiorstw, które przenoszą się do webex dla BroadWorks. Alternatywnie można przejść w drugą stronę i ustawić adres URL poziomu systemu dla webex dla BroadWorks i ponownie skonfigurować te przedsiębiorstwa, które chcesz zachować na UC-One SaaS.

Opcje konfiguracji związane z tą decyzją są szczegółowo opisane w sekcji Konfigurowanie serwera aplikacji z adresem URL usługi inicjowania obsługi administracyjnej w sekcji Wdrażanie programu Webex dla broadworks.

Minimalne wymagania

Konta

Wszyscy subskrybenci, których inicjujesz inicjując inicjowanie obsługi administracyjnej dla systemu Webex, muszą istnieć w systemie BroadWorks, który można zintegrować z webex. W razie potrzeby można zintegrować wiele systemów BroadWorks.

Wszyscy subskrybenci muszą mieć licencje BroadWorks i numery podstawowe.

Webex używa adresów e-mail jako podstawowych identyfikatorów dla wszystkich użytkowników. Jeśli używasz flowthrough inicjowania obsługi administracyjnej z zaufanych wiadomości e-mail, użytkownicy muszą mieć prawidłowe adresy w atrybucie wiadomości e-mail w BroadWorks.

Jeśli szablon używa uwierzytelniania BroadWorks, można skopiować adresy e-mail subskrybenta do atrybutu Identyfikator alternatywny w BroadWorks. Umożliwia to użytkownikom logowanie się do webex przy użyciu ich adresów e-mail i haseł BroadWorks.

Administratorzy muszą używać swoich kont Webex, aby zalogować się do Centrum partnerów.

Serwery w sieci i wymagania dotyczące oprogramowania

  • Wystąpienia BroadWorks z minimalną wersją dodatku SP1 R21. Aby uzyskać obsługiwane wersje i poprawki, zobacz Wymagania dotyczące oprogramowania BroadWorks (w tym dokumencie). Zobacz też Zarządzanie cyklem życia — Serwery BroadSoft.


    R21 SP1 jest obsługiwany tylko do połowy 2021 roku. Mimo że obecnie można zintegrować webex z usługą R21 SP1, zdecydowanie zalecamy r22 lub nowsze w celu integracji z webexem.

  • Wystąpienia BroadWorks powinny zawierać co najmniej następujące serwery:

    • Application Server (AS) z wersją BroadWorks jak wyżej

    • Serwer sieciowy (NS)

    • Serwer profilu (PS)

  • Serwery XSP lub ADP (ADP) wychodzące naprzemierowanie publiczne spełniające następujące wymagania:

    • Usługa uwierzytelniania (BWAuth)

    • Interfejsy akcji i zdarzeń XSI

    • DMS (aplikacja internetowa do zarządzania urządzeniami)

    • Interfejs CTI (Intergration telefonii komputerowej)

    • TLS 1.2 z ważnym certyfikatem (nie podpisanym w podpisie) i wymaganymi półproduktami. Wymaga administratora poziomu systemu, aby ułatwić wyszukiwanie w przedsiębiorstwie.

    • Wzajemne uwierzytelnianie TLS (mTLS) dla usługi uwierzytelniania (wymaga publicznego łańcucha certyfikatów klienta Webex zainstalowanego jako kotwice zaufania)

    • Wzajemne uwierzytelnianie TLS (mTLS) dla interfejsu CTI (wymaga publicznego łańcucha certyfikatów klienta Webex zainstalowanego jako kotwice zaufania)

  • Oddzielny serwer XSP/ADP działający jako "Serwer push powiadomień o połączeniach" (serwer NPS w Twoim środowisku używany do przekazywania powiadomień o połączeniach do firmy Apple/Google. Nazywamy to "CNPS" tutaj, aby odróżnić go od usługi w Webex, która dostarcza powiadomienia push dla wiadomości i obecności).

    Ten serwer musi być włączony R22 lub nowszym.

  • Nakazujemy oddzielny serwer XSP/ADP dla CNPS, ponieważ nieprzewidywalność obciążenia z Webex dla połączeń w chmurze BWKS może negatywnie wpłynąć na wydajność serwera NPS, w wyniku zwiększenia opóźnienia powiadomień. Więcej informacji na temat skalihttps://xchange.broadsoft.com/node/422649XSP można znaleźć w Przewodniku inżynierii systemu Cisco BroadWorks () .

Telefony fizyczne i akcesoria

Profile urządzeń

Są to pliki DTAF, które należy załadować na serwery aplikacji, aby obsługiwać aplikacje Webex jako klientów wywołujących. Są to te same pliki DTAF, które są używane dla UC-One SaaS, jednak istnieje nowa config-wxt.xml.template plik używany w aplikacjach Webex.

Nazwa klienta

Typ profilu urządzenia i nazwa pakietu

Szablon telefonu komórkowego Webex

https://xchange.broadsoft.com/support/uc-one/connect/software

Typ profilu tożsamości/urządzenia: Połącz się - Komórkowy

DTAF: ucone-mobile-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Plik konfiguracyjny: config-wxt.xml

Szablon tabletu Webex

https://xchange.broadsoft.com/support/uc-one/connect/software

Typ profilu tożsamości/urządzenia: Connect - Tablet

DTAF: ucone-tablet-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Plik konfiguracyjny: config-wxt.xml

Szablon pulpitu Webex

https://xchange.broadsoft.com/support/uc-one/communicator/software

Typ profilu tożsamości/urządzenia: Komunikator biznesowy - PC

DTAF: ucone-desktop-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Plik konfiguracyjny: config-wxt.xml

Certyfikaty zamówień

Wymagania dotyczące certyfikatów dla uwierzytelniania TLS

Certyfikaty zabezpieczeń, podpisane przez dobrze znany urząd certyfikacji i wdrożone w publicznych urządzeniach XSPs, dla wszystkich wymaganych aplikacji. Będą one używane do obsługi weryfikacji certyfikatów TLS dla wszystkich połączeń przychodzących z serwerami XSP.

Certyfikaty te powinny zawierać publiczną w pełni kwalifikowaną nazwę domeny XSP jako nazwę pospolitą podmiotu lub nazwę alternatywną podmiotu.

Dokładne wymagania dotyczące wdrażania tych certyfikatów serwera zależy od sposobu wdrażania publicznych xsps stoi:

  • Za pośrednictwem serwera proxy pomostowego TLS

  • Za pośrednictwem serwera proxy przekazywania TLS

  • Bezpośrednio do XSP

Na poniższym diagramie podsumowano, gdzie certyfikat serwera publicznego podpisany z urzędem certyfikacji musi zostać załadowany w tych trzech przypadkach:

Publicznie obsługiwane urzędy certyfikacji obsługiwane przez aplikację Webex do uwierzytelniania są wymienione w obsługiwanych urzędach certyfikacji dla usług hybrydowych Webex.

Wymagania dotyczące certyfikatu TLS dla serwera proxy mostka TLS

  • Publicznie podpisany certyfikat serwera jest ładowany do serwera proxy.

  • Serwer proxy przedstawia ten publicznie podpisany certyfikat serwera webex.

  • Webex ufa publicznemu urzędowi certyfikacji, który podpisał certyfikat serwera serwera.

  • Do certyfikatu XSP można załadować wewnętrzny certyfikat podpisany przez urząd certyfikacji.

  • XSP przedstawia ten wewnętrznie podpisany certyfikat serwera do serwera proxy.

  • Serwer proxy ufa wewnętrznej ucho, która podpisała certyfikat serwera XSP.

Wymagania dotyczące certyfikatów TLS dla serwera proxy TLS-passthrough lub XSP w strefie DMZ

  • Publicznie podpisany certyfikat serwera jest ładowany do plików XSPs.

  • Programy XSPs prezentują publicznie podpisane certyfikaty serwera w witrynie Webex.

  • Webex ufa publicznemu urzędowi certyfikacji, który podpisał certyfikaty serwera XSPs.

Dodatkowe wymagania dotyczące certyfikatów dla wzajemnego uwierzytelniania TLS za pomocą interfejsu CTI

Podczas łączenia się z interfejsem CTI Webex przedstawia certyfikat klienta w ramach wzajemnego uwierzytelniania TLS. Certyfikat ca/łańcucha certyfikatu klienta Webex jest dostępny do pobrania za pośrednictwem centrum Control Hub.

Aby pobrać certyfikat:

Zaloguj się do Centrum partnerów, przejmij ustawienia > połączenia BroadWorks i kliknij łącze pobierz certyfikat.

Dokładne wymagania dotyczące wdrażania tego łańcucha certyfikatów urzędu certyfikacji webex zależą od sposobu wdrażania publicznych programów XSPs:

  • Za pośrednictwem serwera proxy pomostowego TLS

  • Za pośrednictwem serwera proxy przekazywania TLS

  • Bezpośrednio do XSP

Na poniższym diagramie podsumowano wymagania dotyczące certyfikatów w tych trzech przypadkach:

Rysunek 1. Wymiana certyfikatów mTLS dla CTI za pośrednictwem różnych konfiguracji krawędzi

(Opcja) Wymagania dotyczące certyfikatów dla serwera proxy mostka TLS

  • Webex przedstawia publicznie podpisany certyfikat klienta do serwera proxy.

  • Serwer proxy ufa wewnętrznej uchyłku cisco, który podpisał certyfikat klienta. Możesz pobrać ten urząd certyfikacji / łańcuch z usługi Control Hub i dodać go do magazynu zaufania serwera proxy. Publicznie podpisany certyfikat serwera XSP jest również ładowany do serwera proxy.

  • Serwer proxy przedstawia webexowi publicznie podpisany certyfikat serwera.

  • Webex ufa publicznemu urzędowi certyfikacji, który podpisał certyfikat serwera serwera.

  • Serwer proxy przedstawia wewnętrznie podpisany certyfikat klienta do listy XSPs.

    Ten certyfikat musi mieć pole rozszerzenia x509.v3 rozszerzone użycie klucza wypełnione broadworks oid 1.3.6.1.4.1.6431.1.1.8.2.1.3 i celem klienta TLSAuth. Przykład.:

    X509v3 extensions:
        X509v3 Extended Key Usage:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

    CN świadectwa wewnętrznego musi być bwcticlient.webex.com.


    • Podczas generowania wewnętrznych certyfikatów klienta dla serwera proxy należy pamiętać, że certyfikaty sieci SAN nie są obsługiwane. Wewnętrzne certyfikaty serwera dla XSP mogą być siecią SAN.

    • Wymagane są urzędy certyfikacji publicznej mogą nie chcieć podpisywać certyfikatów z wymaganym zastrzeżonym oidem BroadWorks. W przypadku serwera proxy pomostowego może być zmuszony do użycia wewnętrznego urzędu certyfikacji do podpisania certyfikatu klienta, który serwer proxy przedstawia XSP.

  • Dostawcy usług XSP ufają wewnętrznej uchyłomieniu urzędu certyfikacji.

  • Programy XSPs przedstawiają wewnętrznie podpisany certyfikat serwera.

  • Serwer proxy ufa wewnętrznej uchyłku urzędu certyfikacji.

  • ClientIdentity serwera aplikacji zawiera CN wewnętrznie podpisanego certyfikatu klienta przedstawionego XSP przez serwer proxy.

(Opcja) Wymagania dotyczące certyfikatów dla serwera proxy TLS-passthrough lub XSP w strefie DMZ

  • Webex przedstawia certyfikat klienta z podpisem urzędu certyfikacji Cisco do listy XSPs.

  • Dostawcy usług XSP ufają wewnętrznej umowy certyfikacji Cisco, która podpisała certyfikat klienta. Możesz pobrać ten urząd certyfikacji / łańcuch z usługi Control Hub i dodać go do magazynu zaufania serwera proxy. Publicznie podpisany certyfikat serwera XSP jest również ładowany do programów XSP.

  • Programy XSPs przedstawiają publicznie podpisane certyfikaty serwera webex.

  • Webex ufa publicznemu urzędowi certyfikacji, który podpisał certyfikaty serwera XSPs.

  • ClientIdentity serwera aplikacji zawiera CN certyfikatu klienta podpisanego cisco przedstawione xsp przez Webex.

Przygotowanie sieci

Mapa połączenia

Na poniższym diagramie przedstawiono punkty integracji. Punkt diagramu jest pokazanie, że należy przejrzeć ip i portów dla połączeń do i z środowiska. Połączenia używane przez webex dla BroadWorks są opisane w kolejnych tabelach.

Wymagania zapory dla normalnego funkcjonowania aplikacji klienckiej są wymienione jako odwołania, ponieważ są już udokumentowane w help.webex.com.

Konfiguracja zapory

Mapa połączeń i poniższe tabele opisują połączenia i protokoły wymagane między klientami (w sieci klienta lub poza nią), siecią i platformą Webex.

Zasady wnikania EMEA

(Do sieci)

cel Źródło protokół Miejsce docelowe Port docelowy

WebexCloud (Usługa WebexCloud)

CTI/Auth/XSI

18.196.116.47

35.156.83.118

35.158.206.190

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

Protokół HTTPS

CtI (CTI)

Twój XSP

Protokół TCP/TLS 8012

443

Aplikacja Webex

Xsi/DMS

jakikolwiek

Protokół HTTPS

Twój XSP

443

Webex aplikacji VoIP punktów końcowych SIP

jakikolwiek

SIP

Twój SBC

Protokół i port zdefiniowany przez SP

Protokół TCP/UDP


Zdecydowanie wskazane jest, aby port SIP różnił się od 5060 (na przykład 5075) ze względu na znane problemy z używaniem standardowego portu SIP (5060) z urządzeniami mobilnymi.

Zasady wyjścia z EMEA

(Poza siecią)

cel

Źródło

protokół

Miejsce docelowe

Port docelowy

Inicjowanie obsługi administracyjnej użytkowników za pośrednictwem interfejsów API

Serwer aplikacji

Protokół HTTPS

webexapis.com

443

Powiadomienia push proxy (usługa produkcyjna)

Twój serwer NPS

Protokół HTTPS

https://nps.uc-one.broadsoft.com/

OR 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Wspólna tożsamość Webex

Twój serwer NPS

Protokół HTTPS

https://idbroker-eu.webex.com

443

Wspólna tożsamość Webex

Usługa Auth XSP

Protokół HTTPS

https://idbroker-eu.webex.com/idb

https://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

Usługi APNS i FCM

Twój serwer NPS

Protokół HTTPS

Dowolny adres IP*

443

Powiadomienia push proxy (usługa produkcyjna)

Wspólna tożsamość Webex

Usługi APNS i FCM

Twój serwer NPS

Protokół HTTPS

https://nps.uc-one.broadsoft.com/ *

https://idbroker-eu.webex.com

Dowolny adres IP*

443

Inicjowanie obsługi administracyjnej przez kartę inicjowania obsługi administracyjnej BroadWorks

Twój BroadWorks AS

Protokół HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(gdzie * może być dowolna litera. Dokładny adres URL inicjowania obsługi administracyjnej jest dostępny w szablonie utworzonym w Centrum partnerów)

443

† Te zakresy zawierają hosty serwera proxy SERWERA NPS, ale nie możemy podać dokładnych adresów. Zakresy mogą również zawierać hosty, które nie są związane z Webex for BroadWorks. Zaleca się skonfigurowanie zapory, aby zezwolić na ruch do serwera FQDN serwera proxy SERWERA NPS zamiast, aby upewnić się, że wyjście jest tylko do hostów, które udostępniamy dla serwera proxy NPS.

* APNS i FCM nie mają stałego zestawu adresów IP.

Zasady w ruchu w USA

(Do sieci)

cel

Źródło

protokół

Miejsce docelowe

Port docelowy

WebexCloud (Usługa WebexCloud)

CTI/Auth/XSI

13.58.232.148

18.217.166.80

18.221.216.175

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

Protokół HTTPS

CtI (CTI)

Twój XSP

Protokół TCP/TLS 8012

TLS 443

Aplikacja Webex   

Xsi/DMS

jakikolwiek

Protokół HTTPS

Twój XSP

443

Punkty końcowe VoIP aplikacji Webex

jakikolwiek

SIP

Twój SBC

Protokół i port zdefiniowany przez SP

Protokół TCP/UDP


Zdecydowanie wskazane jest, aby port SIP różnił się od 5060 (na przykład 5075) ze względu na znane problemy z używaniem standardowego portu SIP (5060) z urządzeniami mobilnymi.

Usa Zasady wyjścia

(Poza siecią)

cel

Źródło

protokół

Miejsce docelowe

Port docelowy

Inicjowanie obsługi administracyjnej użytkowników za pośrednictwem interfejsów API

Serwer aplikacji

Protokół HTTPS

webexapis.com

443

Powiadomienia push proxy (usługa produkcyjna)

Twój serwer NPS

Protokół HTTPS

https://nps.uc-one.broadsoft.com/

OR 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Wspólna tożsamość Webex

Twój serwer NPS

Protokół HTTPS

https://idbroker.webex.com

https://idbroker-b-us.webex.com

443

Wspólna tożsamość Webex

Usługa Auth XSP

Protokół HTTPS

https://idbroker.webex.com/idb

https://idbroker-b-us.webex.com/idb

https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

https://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

Usługi APNS i FCM

Twój serwer NPS

Protokół HTTPS

Dowolny adres IP*

443

Inicjowanie obsługi administracyjnej przez kartę inicjowania obsługi administracyjnej BWKS

Twój BroadWorks AS

Protokół HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(gdzie * może być dowolna litera. Dokładny adres URL inicjowania obsługi administracyjnej jest dostępny w szablonie utworzonym w Centrum partnerów)

443

† Te zakresy zawierają hosty serwera proxy SERWERA NPS, ale nie możemy podać dokładnych adresów. Zakresy mogą również zawierać hosty, które nie są związane z Webex for BroadWorks. Zaleca się skonfigurowanie zapory, aby zezwolić na ruch do serwera FQDN serwera proxy SERWERA NPS zamiast, aby upewnić się, że wyjście jest tylko do hostów, które udostępniamy dla serwera proxy NPS.

* APNS i FCM nie mają stałego zestawu adresów IP.

Wymagania sieciowe dotyczące usług Webex

Poprzednie tabele zapory reguł ruchu przychodzącego i transferu danych przychodzących dokumentują tylko połączenia specyficzne dla webex dla broadworks. Aby uzyskać ogólne informacje na temat połączeń między aplikacją Webex a chmurą Webex, zobacz Wymagania sieciowe dotyczące usług Webex. Ten artykuł jest ogólny dla Webex, ale w poniższej tabeli określono różne sekcje artykułu i jak istotne jest każda sekcja webex dla BroadWorks.

Tabela 1. Wymagania sieciowe dotyczące połączeń aplikacji Webex (ogólne)

Sekcja wymagań sieciowych Artykuł

Adekwatność informacji

Podsumowanie typów urządzeń i protokołów obsługiwanych przez Webex

Komunikat informacyjny

Protokoły transportu i szyfry szyfrowania dla zarejestrowanych w chmurze aplikacji i urządzeń Webex

Komunikat informacyjny

Usługi Webex — numery portów i protokoły

Lektura obowiązkowa

Podsieci IP dla usług multimedialnych Webex

Lektura obowiązkowa

Domeny i adresy URL, do których należy uzyskać dostęp do usług Webex

Lektura obowiązkowa

Dodatkowe adresy URL dla usług hybrydowych Webex

Opcjonalnie

Funkcje serwera proxy

Opcjonalnie

802.1X – Kontrola dostępu do sieci oparta na porcie

Opcjonalnie

Wymagania sieciowe dla usług Webex opartych na SIP

Opcjonalnie

Wymagania sieciowe dla webex edge audio

Opcjonalnie

Podsumowanie innych usług i dokumentacji webex hybrid

Opcjonalnie

Usługi Webex dla klientów FedRAMP

nd.

Dodatkowe informacje

Aby uzyskać dodatkowe informacje, zobacz Oficjalny dokument zapory aplikacji Webex (PDF).

Obsługa nadmiarowości BroadWorks

Usługi w chmurze Webex i aplikacje klienckie Webex, które muszą uzyskać dostęp do sieci partnera, w pełni obsługują nadmiarowość Broadworks XSP zapewnianą przez partnera. Gdy XSP lub witryna jest niedostępna z powodu planowanej konserwacji lub nieplanowanej przyczyny, usługi Webex & aplikacje mogą przejść do innego systemu XSP lub witryny dostarczonej przez partnera w celu wypełnienia żądania.

Topologia sieci

XSPs Broadworks mogą być wdrażane bezpośrednio w Internecie, lub może znajdować się w DMZ fronted przez element równoważenia obciążenia, takich jak F5 BIG-IP. Aby zapewnić nadmiarowość geograficzną, XSPs można wdrożyć w dwóch (lub więcej) centrach danych, z których każdy może być frontowany przez moduł równoważenia obciążenia, z których każdy ma publiczny adres IP. Jeśli XSP są za moduł równoważenia obciążenia, mikrousług Webex i aplikacji zobacz tylko adres IP modułu równoważenia obciążenia i Broadworks wydaje się mieć tylko jeden XSP, nawet jeśli istnieje wiele XSP za.

W poniższym przykładzie programy XSPs są wdrażane w dwóch lokacjach, lokacji A i lokacji B. Istnieją dwa XSPs fronted przez load balancer w każdej lokacji. Strona A ma XSP1 i XSP2 fronted przez LB1, a strona B ma XSP3 i XSP4 fronted przez LB2. Tylko moduły równoważenia obciążenia są widoczne w sieci publicznej, a dostawcy usług XSP znajdują się w sieciach prywatnych strefy DMZ.

Usługi w chmurze Webex

Konfiguracja DNS

Mikrousługi Webex Cloud muszą być w stanie znaleźć serwery XSP Broadworks do łączenia się z interfejsami Xsi, usługą uwierzytelniania i cti.

Mikrousługi Webex Cloud będą wykonywać wyszukiwanie DNS A/AAAA skonfigurowanej nazwy hosta XSP i łączyć się z zwracanym adresem IP. Może to być element krawędzi równoważenia obciążenia lub może to być sam serwer XSP. Jeśli zwracanych jest wiele adresów IP, zostanie wybrany pierwszy adres IP na liście. Wyszukiwanie SRV nie są obecnie obsługiwane.

Przykład: Rekord DNS A partnera do wykrywania zrównoważonych modułów równoważącego system xsp z internetem

Typ rekordu

Nazwa

Cel

cel

A

xsp.example.com

198.51.100.48

Wskazuje na LB1 (witryna A)

A

xsp.example.com

198.51.100.49

Wskazuje na LB2 (strona B)

Przewija w ten sposób,

Gdy mikrousługi Webex wysłać żądanie do XSP/Load Balancer i żądanie kończy się niepowodzeniem, kilka rzeczy może się zdarzyć:

  • Jeśli błąd jest spowodowany błędem sieci (np. TCP, SSL), mikrousług Webex oznaczyć IP jako zablokowane i natychmiast wykonać trasę zaliczki do następnego adresu IP.

  • Jeśli zwracany jest kod błędu (HTTP 5xx), mikrousługi Webex oznaczają adres IP jako zablokowane i natychmiast wykonują przesuw trasy do następnego adresu IP.

  • Jeśli w ciągu 2 sekund nie zostanie odebrana żadna odpowiedź HTTP, upłynie limit czasu żądania, a mikrousługi Webex oznaczyły adres IP jako zablokowany i wykonały przesuń trasę do następnego adresu IP.

Każde żądanie jest wypróbowywać 3 razy, zanim błąd zostanie zgłoszony z powrotem do mikrousługi.

Gdy adres IP znajduje się na liście zablokowanych, nie zostanie uwzględniony na liście adresów, aby spróbować podczas wysyłania żądania do XSP. Po upływie określonego czasu zablokowany adres IP wygasa i wraca na listę, aby spróbować, gdy zostanie wykonane inne żądanie.

Jeśli wszystkie adresy IP są zablokowane, mikrousługi nadal będzie próbować wysłać żądanie, losowo wybierając adres IP z listy zablokowanych. Jeśli to się powiedzie, ten adres IP zostanie usunięty z listy zablokowanych.

Stan

Stan łączności usług Webex Cloud z serwerami XSPs lub Load Balancers można zobaczyć w Centrum sterowania. W klastrze wywoływania BroadWorks dla każdego z tych interfejsów wyświetlany jest stan połączenia:

  • Czynności XSI

  • Zdarzenia XSI

  • Usługa uwierzytelniania

Stan połączenia jest aktualizowany po załadowaniu strony lub podczas aktualizacji wejściowych. Stany połączeń mogą być następujące:

  • zielony: Gdy interfejs można uzyskać na jednym z usług IP w odnośnika rekordu A.

  • czerwony: Gdy wszystkiepy w odnośnika rekordu A są nieosiągalne, a interfejs jest niedostępny.

Następujące usługi używają mikrousług do łączenia się z platformami XSP i mają wpływ na dostępność interfejsu XSP:

  • Logowanie do aplikacji Webex

  • Odświeżanie tokenu aplikacji Webex

  • Niezaufany e-mail / aktywacja własna

  • Kontrola kondycji usługi Broadworks

Aplikacja Webex

Konfiguracja DNS

Aplikacja Webex uzyskuje dostęp do usług Xtended Services Interface (XSI-Actions & XSI-Events) i Usługi zarządzania urządzeniami (DMS) w usłudze XSP.

Będzie on akcesji DNS SRV dla _xsi-client._tcp.<xsi domain> skonfigurowanego adresu URL, aby znaleźć hosty XSP lub moduły równoważenia obciążenia dla usługi XSI.

Poniżej znajduje się przykład rekordów SRV.

Typ rekordu

Nagraj

Cel

cel

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc1.example.com

Odnajdowanie przez klienta interfejsu Xsi

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc2.example.com

Odnajdowanie przez klienta interfejsu Xsi

A

xsp-dc1.example.com

198.51.100.48

Wskazuje na LB1 (strona A)

A

xsp-dc2.example.com

198.51.100.49

Wskazuje na LB2 (strona B)


Każdy rekord A/AAAA musi być mapowana na jeden adres IP. Jeśli istnieje wiele XSP w strefie DMZ za urządzeniem równoważenia obciążenia/krawędzi, wymagane jest, aby moduł równoważenia obciążenia został skonfigurowany do obsługi trwałości sesji w celu kierowania wszystkich żądań tej samej sesji do tego samego XSP.

Zamówimy tę konfigurację, ponieważ pulsy zdarzenia XSI klienta muszą przejść do tego samego pliku XSP, który jest używany do ustanawiania kanału zdarzeń.

Jeśli zamapujesz nazwę A/AAAA na więcej niż jeden adres IP lub jeśli element równoważenia obciążenia/krawędzi nie utrzymuje trwałości sesji, klient ostatecznie wysyła pulsy do protokołu XSP, gdzie nie ustanowił kanału zdarzeń. Powoduje to, że kanał jest zburzona, a także w znacznie większy ruch wewnętrzny, który pogarsza wydajność klastra XSP.

Podczas procesu logowania aplikacja Webex pobierze również adres URL DMS, aby pobrać plik konfiguracyjny. Host w adresie URL będzie analizowany, a aplikacja Webex przeprowadzi wyszukiwanie DNS A/AAAA hosta, aby połączyć się z XSP obsługującym usługę DMS.

Przykład: REKORD DNS do wykrywania round-robin zrównoważony serwer XSP /Load Balancers przez Webex App do pobierania plików konfiguracyjnych za pośrednictwem DMS:

Typ rekordu

Nazwa

Cel

cel

A

xsp-dms.example.com

198.51.100.48

Wskazuje na LB1 (strona A)

A

xsp-dms.example.com

198.51.100.49

Wskazuje na LB2 (strona B)

Jak aplikacja Webex odnajduje adresy XSP

Klient próbuje zlokalizować węzły XSP przy użyciu następującego przepływu DNS:

  1. Klient początkowo pobiera adresy URL Xsi-Actions/Xsi-Events z webex cloud (wprowadzono je podczas tworzenia skojarzonego klastra wywołującego BroadWorks). Nazwa hosta Xsi/domena jest analizowana z adresu URL, a klient wykonuje wyszukiwanie SRV w następujący sposób:

    1. Klient wykonuje wyszukiwanie SRV dla _xsi-client._tcp.<xsi domain="">

    2. Jeśli wyszukiwanie SRV zwraca jeden lub więcej obiektów docelowych:

      1. Klient wykonuje wyszukiwanie A/AAAA dla tych obiektów docelowych i buforuje zwracane adresy IP.

      2. Klient łączy się z jednym z obiektów docelowych (a zatem jego rekord A/AAAA z jednym adresem IP) na podstawie priorytetu SRV, a następnie wagi (lub losowo, jeśli wszystkie są równe).

    3. Jeśli wyszukiwanie SRV nie zwraca żadnych obiektów docelowych:

      Klient wykonuje wyszukiwanie A/AAAA parametru głównego Xsi, a następnie próbuje połączyć się ze zwracanym adresem IP. Może to być element krawędzi równoważenia obciążenia lub może to być sam serwer XSP.

      Jak wspomniano, rekord A/AAAA musi zostać rozpoznany na jeden adres IP z tych samych powodów.

  2. (Opcjonalnie) Następnie można podać niestandardowe szczegóły XSI-Actions/XSI-Events w konfiguracji urządzenia dla aplikacji Webex, używając następujących tagów:

    <protocols>
    	<xsi>
    		<paths>
    			<root>%XSI_ROOT_WXT%</root>
    			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
    			<events>%XSI_EVENTS_PATH_WXT%</events>
    		</paths>
    	</xsi>
    </protocols>
    1. Te parametry konfiguracji mają pierwszeństwo przed dowolną konfiguracją klastra BroadWorks w ucho.

    2. Jeśli istnieją, klient porówna się z oryginalnym adresem XSI, który otrzymał za pośrednictwem konfiguracji klastra BroadWorks.

    3. Jeśli zostanie wykryta jakakolwiek różnica, klient ponownie zainisalizuje łączność akcji XSI/ XSI Events. Pierwszym krokiem w tym jest wykonanie tego samego procesu wyszukiwania DNS wymienionego w kroku 1 — tym razem żądając odszukaj wartości w parametrze %XSI_ROOT_WXT% z pliku konfiguracyjnego.


      Pamiętaj, aby utworzyć odpowiednie rekordy SRV, jeśli używasz tego tagu do zmiany interfejsów Xsi.
Przewija w ten sposób,

Podczas logowania aplikacja Webex wykonuje wyszukiwanie DNS SRV dla _xsi-client._tcp.<xsi domain="">, tworzy listę hostów i łączy się z jednym z hostów na podstawie priorytetu SRV, a następnie wagi. Ten połączony host staje się wybrany dla wszystkich przyszłych żądań. Kanał zdarzeń jest następnie otwierany dla wybranego hosta i regularnie wysyłane jest bicie serca w celu zweryfikowania kanału. Wszystkie żądania wysyłane po pierwszym zawierają plik cookie, który jest zwracany w odpowiedzi HTTP, dlatego ważne jest, aby moduł równoważenia obciążenia utrzymuje trwałość sesji (koligacja) i zawsze wysyłać żądania do tego samego serwera zaplecza XSP.

Jeśli żądanie lub żądanie pulsu do hosta nie powiedzie się, może się zdarzyć kilka rzeczy:

  • Jeśli błąd jest spowodowany błędem sieci (np. TCP, SSL), aplikacja Webex natychmiast przekieruje zaliczki do następnego hosta na liście.

  • Jeśli zwracany jest kod błędu (HTTP 5xx), żądanie kończy się natychmiast.

  • Jeśli odpowiedź nie zostanie odebrana w określonym czasie, żądanie zostanie uznane za nieudane z powodu przeterminowania, a następne żądania są wysyłane do następnego hosta. Jednak żądanie przesunięty limit czasu jest uważane za nie powiodło się. Niektóre żądania są ponawiane po niepowodzeniu (wraz ze wzrostem czasu ponawiania). Żądania, które zakładane non vital nie są ponawiane.

Po pomyślnym wypróbowaniu nowego hosta staje się on nowym wybranym hostem, jeśli host znajduje się na liście. Po wypróbowaniu ostatniego hosta na liście aplikacja Webex zostanie przerzucana na pierwszą.

W przypadku pulsu, jeśli wystąpią dwa kolejne błędy żądania, aplikacja Webex ponownie zainicjuje kanał zdarzeń.

Należy zauważyć, że aplikacja Webex nie wykonuje powrotu po awarii, a odnajdowanie usługi DNS jest wykonywane tylko raz podczas logowania.

Podczas logowania aplikacja Webex próbuje pobrać plik konfiguracyjny za pośrednictwem interfejsu XSP/Dms. Wykonuje wyszukiwanie rekordu A/AAAA hosta w pobranym adresie URL DMS i łączy się z pierwszym adresem IP. Najpierw spróbuje wysłać żądanie pobrania pliku konfiguracyjnego przy użyciu tokenu SSO. Jeśli to się nie powiedzie z jakiegokolwiek powodu, spróbuje ponownie, ale z nazwą użytkownika i hasłem urządzenia.