Pregătiți-vă mediul

Puncte de decizie

considerație Întrebări la care trebuie să răspundeți Resurse

Arhitectură și infrastructură

Câte XSP-uri?

iau mTLS?

Planificator de capacitate a sistemului Cisco BroadWorks

Cisco BroadWorks System Engineering Ghid

Referință CLI XSP

Acest document

Asigurarea accesului clienților și utilizatorilor

Puteți afirma că aveți încredere în e-mailurile din BroadWorks?

Doriți ca utilizatorii să furnizeze adrese de e-mail pentru a-și activa propriile conturi?

Puteți construi instrumente pentru a utiliza API-ul nostru?

Documente API publice la https://developer.webex.com

Acest document

Branding Ce culoare și siglă doriți să utilizați? Articol de branding pentru aplicații Webex
Modele Care sunt diferitele cazuri de utilizare a clienților dvs.? Acest document
Caracteristici abonat per client/întreprindere/grup Alegeți pachetul pentru a defini nivelul serviciului per șablon. Basic, Standard, Premium sau Softphone.

Acest document

Matrice caracteristică/pachet

Autentificarea utilizatorului BroadWorks sau Webex Acest document
Adaptor de asigurare a accesului (pentru opțiunile de asigurare a accesului prin flux)

Utilizați deja IM&P integrat, de exemplu pentru UC-One SaaS?

Intenționați să utilizați mai multe șabloane?

Există un caz de utilizare mai frecvente anticipate?

Acest document

Referință CLI server aplicație

Arhitectură și infrastructură

  • Cu ce fel de scară intenționezi să începi? Este posibil să vă extindeți în viitor, dar estimarea de utilizare curentă ar trebui să conducă la planificarea infrastructurii.

  • Lucrați cu managerul de cont Cisco / reprezentantul de vânzări pentru a vă dimensiona infrastructura XSP, în conformitate cu Cisco BroadWorks System Capacity Planner ( ) și Ciscohttps://xchange.broadsoft.com/node/1051462BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/1051496).

  • va face Webex conexiuni TLS reciproce la XSP-urile dvs.? Direct la XSP într-un DMZ, sau prin proxy TLS? Acest lucru afectează gestionarea certificatelor și URL-urile pe care le utilizați pentru interfețe. (Nuacceptăm conexiuni TCP necriptate la marginea rețeleidvs.).

Asigurarea accesului clienților și utilizatorilor

Ce metodă de asigurare a accesului pentru utilizatori vi se potrivește cel mai bine?

  • Flowthrough Provisioning cu e-mailuri deîncredere: Prin atribuirea serviciului "IM&P integrat" pe BroadWorks, abonatul este furnizat automat în Webex.

    Dacă puteți afirma, de asemenea, că adresele de e-mail ale abonaților din BroadWorks sunt valide și unice pentru Webex, atunci puteți utiliza varianta "e-mail de încredere" de asigurare a accesului prin flux. Conturile Webex ale abonaților sunt create și activate fără intervenția acestora; pur și simplu descarcă clientul și se conectează.

    Adresa de e-mail este un atribut cheie al utilizatorului pe Webex. Prin urmare, Furnizorul de servicii trebuie să furnizeze o adresă de e-mail validă pentru utilizator pentru a le furniza pentru servicii Webex. Acest lucru trebuie să fie în atributul ID-ul de e-mail al utilizatorului din BroadWorks. Vă recomandăm să îl copiați și în atributul ID alternativ.

  • Flowthrough provisioning fără e-mailuri deîncredere: Dacă nu puteți avea încredere în adresele de e-mail ale abonaților, puteți atribui în continuare serviciul IM&P integrat în BroadWorks utilizatorilor de furnizare din Webex.

    Cu această opțiune, conturile sunt create atunci când atribuiți serviciul, dar abonații trebuie să furnizeze și să valideze adresele lor de e-mail pentru a activa conturile Webex.

  • Autoaprovizionare utilizator: Această opțiune nu necesită atribuirea serviciului IM&P în BroadWorks. Tu (sau clienții tăi) distribuiți în schimb un link de asigurare a accesului și linkurile pentru a descărca diferiții clienți, cu brandingul și instrucțiunile dvs.

    Abonații urmează linkul, apoi furnizează și validează adresele lor de e-mail pentru a-și crea și activa conturile Webex. Apoi descarcă clientul și se conectează, iar Webex preia o configurație suplimentară despre ei de la BroadWorks (inclusiv numerele lor primare).

  • Provizionare controlată SP prinAPI- uri: Webex expune un set de API-uri publice care permit furnizorilor de servicii să construiască furnizarea de utilizator/abonat în fluxurile de lucru existente.

Modele clienți

Șabloanele de client vă permit să definiți parametrii după care clienții și abonații asociați sunt furnizați automat pe Webex pentru BroadWorks. Aveți posibilitatea să configurați mai multe șabloane client după este necesar, dar când sunteți la bordul unui client este asociat cu un singur șablon (nu aveți posibilitatea să aplicați mai multe șabloane unui singur client).

Unii dintre parametrii șablonului principal sunt enumerați mai jos.

Pachet

  • Trebuie să selectați un pachet implicit atunci când creați un șablon (consultați Pachetele din secțiunea Prezentare generală pentru detalii). Toți utilizatorii care au acces la acel șablon, fie prin flux, fie prin auto-asigurare, primesc pachetul implicit.

  • Aveți control asupra selecției pachetelor pentru diferiți clienți, creând mai multe șabloane și selectând pachete implicite diferite în fiecare. Apoi, puteți distribui diferite linkuri de asigurare a accesului sau adaptoare de asigurare a accesului la fiecare întreprindere, în funcție de metoda de asigurare a accesului pentru utilizatori aleasă pentru șabloanele respective.

  • Aveți posibilitatea să modificați pachetul de abonați specifici din această valoare implicită, utilizând API-ul de asigurare a accesului (consultați Integrarea cu Webex pentru API-ul de asigurare a accesului BroadWorks în secțiunea Referință) sau prin Hub partener.

  • Nu puteți modifica pachetul unui abonat din BroadWorks. Atribuirea serviciului integrat IM&P este activată sau dezactivată; dacă abonatului i se atribuie acest serviciu în BroadWorks, șablonul Hub partener asociat cu URL-ul de asigurare a accesului al întreprinderii abonatului respectiv definește pachetul.

Reseller și întreprinderi sau furnizor și grupuri de servicii?

  • Modul în care este configurat sistemul BroadWorks are un impact asupra fluxului prin asigurarea accesului. Dacă sunteți distribuitor la Întreprinderi, atunci trebuie să activați modul Enterprise atunci când creați un șablon.
  • Dacă sistemul BroadWorks este configurat în modul Furnizor de servicii, aveți posibilitatea să lăsați comutatorul mod Întreprindere oprit în șabloane.
  • Dacă intenționați să furnizați organizații de clienți utilizând ambele moduri BroadWorks, trebuie să utilizați șabloane diferite pentru grupuri și întreprinderi.

Asigurați-vă că ați aplicat corecțiile BroadWorks care sunt necesare pentru asigurarea accesului prin flux. Pentru detalii, consultați Corecții necesare cu asigurare acces prin flux.

Mod autentificare

se vor autentifica abonații clienților?

Mod autentificare BroadWorks Webex
Identitatea principală a utilizatorului ID utilizator BroadWorks Adresă de e-mail
Furnizor de identitate

BroadWorks.

  • Dacă configurați o conexiune directă la BroadWorks, aplicația Webex se autentifică direct la serverul BroadWorks. Rețineți că această opțiune necesită activarea unui comutator de caracteristică.

  • În caz contrar, autentificarea la BroadWorks este facilitată printr-un serviciu intermediar găzduit de Webex.

Identitate comună Cisco
Autentificare multi-factor? Nu Necesită IdP client care acceptă autentificarea cu mai mulți factori.

Cale de validare acreditări

  1. Browser-ul este lansat în cazul în care utilizatorul furnizează e-mail la fluxul de conectare inițială și de a descoperi modul lor de autentificare.

  2. Browser-ul este apoi redirecționat către un Webex găzduit BroadWorks login pagină (Această pagină este brandable)

  3. Utilizatorul furnizează id-ul de utilizator broadworks și parola pe pagina de conectare.

  4. Acreditările de utilizator sunt validate împotriva BroadWorks.

  5. La succes, se obține un cod de autorizare de la Webex. Aceasta este utilizată pentru a obține token-urile de acces necesare pentru serviciile Webex.

  1. Browser-ul este lansat în cazul în care utilizatorul furnizează e-mail la fluxul de conectare inițială și de a descoperi modul lor de autentificare.

  2. Browser-ul este redirecționat către IdP (fie Cisco Common Identity, fie Customer IdP) unde vor fi prezentate cu un portal de conectare.

  3. Utilizatorul furnizează acreditările corespunzătoare pe pagina de conectare

  4. Autentificarea multi-factor poate avea loc dacă IDP-ul clientului acceptă acest lucru.

  5. La succes, se obține un cod de autorizare de la Webex. Aceasta este utilizată pentru a obține token-urile de acces necesare pentru serviciile Webex.


Pentru o defalcare mai detaliată a fluxului de conectare SSO cu autentificare directă la BroadWorks, consultați subiectul Flux de conectare SSO din secțiunea Webex pentru referință BroadWorks.

Aranjamente multiple pentru parteneri

Aveți de gând să sublicențiați Webex pentru BroadWorks unui alt furnizor de servicii? În acest caz, fiecare furnizor de servicii va avea nevoie de o organizație parteneră distinctă în Hubul de control Webex pentru a le permite furnizarea soluției pentru baza lor de clienți.

Adaptor și șabloane de asigurare a accesului

Când utilizați asigurarea accesului prin flux, URL-ul de asigurare a accesului pe care îl introduceți în BroadWorks este derivat din șablonul din Control Hub. Puteți avea mai multe șabloane și, prin urmare, mai multe URL-uri de asigurare a accesului. Acest lucru vă permite să selectați, în funcție de întreprindere, ce pachet să se aplice abonaților atunci când li se acordă serviciul IM&P integrat.

Trebuie să luați în considerare dacă doriți să setați un URL de asigurare a accesului la nivel de sistem ca cale implicită de asigurare a accesului și ce șablon doriți să utilizați pentru aceasta. În acest fel, trebuie doar să setați în mod explicit ADRESA URL de asigurare a accesului pentru acele întreprinderi care au nevoie de un șablon diferit.

De asemenea, rețineți că este posibil să utilizați deja un URL de asigurare a accesului la nivel de sistem, de exemplu cu UC-One SaaS. În acest caz, puteți opta pentru păstrarea URL-ului la nivel de sistem pentru asigurarea accesului utilizatorilor la UC-One SaaS și pentru preluarea pentru acele întreprinderi care se deplasează la Webex pentru BroadWorks. Alternativ, poate doriți să mergeți în altă parte și să setați URL-ul nivelului de sistem pentru Webex pentru BroadWorks și să reconfigurați acele întreprinderi pe care doriți să le păstrați pe UC-One SaaS.

Opțiunile de configurare legate de această decizie sunt detaliate în Configurarea Application Server cu URL-ul serviciului de asigurare a accesului în secțiunea Implementare Webex pentru BroadWorks.

Cerințe minime

Conturi

Toți abonații pe care îi furnizați pentru Webex trebuie să existe în sistemul BroadWorks pe care îl integrați cu Webex. Puteți integra mai multe sisteme BroadWorks, dacă este necesar.

Toți abonații trebuie să aibă licențe BroadWorks și numere primare.

Webex utilizează adresele de e-mail ca identificatori principali pentru toți utilizatorii. Dacă utilizați asigurarea accesului prin flux cu e-mailuri de încredere, atunci utilizatorii trebuie să aibă adrese valide în atributul de e-mail din BroadWorks.

Dacă șablonul utilizează autentificarea BroadWorks, puteți copia adresele de e-mail ale abonaților în atributul ID alternativ din BroadWorks. Acest lucru face posibil ca utilizatorii să se conecteze la Webex folosind adresele lor de e-mail și parolele broadworks.

Administratorii trebuie să își folosească conturile Webex pentru a se conecta la Hubul de parteneri.

Servere în rețeaua dumneavoastră și cerințele de software

  • Instanțe BroadWorks cu versiunea minimă R21 SP1. Consultați Cerințe software BroadWorks (în acest document) pentru versiuni și corecții acceptate. A se vedea, de asemenea, Managementul ciclului de viață - Servere BroadSoft.


    R21 SP1 este acceptat doar până la jumătatea anului 2021. Chiar dacă în prezent puteți integra Webex cu R21 SP1, vă recomandăm cu tărie R22 sau o versiune ulterioară pentru integrarea cu Webex.

  • Instanțele BroadWorks ar trebui să includă cel puțin următoarele servere:

    • Application Server (AS) cu versiunea BroadWorks ca mai sus

    • Server de rețea (NS)

    • Server profil (PS)

  • Serverul (serverele) XSP orientat(e) spre public sau platforma (platformele) de livrare a aplicațiilor (ADP) care îndeplinește următoarele cerințe:

    • Serviciu de autentificare (BWAuth)

    • Interfețele acțiunilor și evenimentelor XSI

    • DMS (aplicație web de gestionare a dispozitivelor)

    • Interfață CTI (Intergration pentru telefonia computerului)

    • TLS 1.2 cu un certificat valid (nesemnat) și orice intermediari necesari. Necesită System Level Admin pentru a facilita căutarea la nivel de întreprindere.

    • Autentificare TLS reciprocă (mTLS) pentru serviciul de autentificare (necesită lanțul public de certificate de client Webex instalat ca ancore de încredere)

    • Autentificare TLS reciprocă (mTLS) pentru interfața CTI (Necesită lanțul public de certificate de client Webex instalat ca ancore de încredere)

  • Un server XSP/ADP separat care acționează ca "Call Notifications Push Server" (un NPS din mediul tău folosit pentru a împinge notificările de apeluri către Apple/Google. Noi o numim "CNPS" aici pentru ao distinge de serviciul din Webex care oferă notificări push pentru mesagerie și prezență).

    Acest server trebuie să fie pe R22 sau o versiune ulterioară.

  • Mandatăm un server XSP /ADP separat pentru CNPS, deoarece imprevizibilitatea încărcării de la Webex pentru conexiunile în cloud BWKS ar putea avea un impact negativ asupra performanței serverului NPS, ca urmare a creșterii latenței notificării. Consultați Ghidul cisco de inginerie a sistemelor BroadWorks (https://xchange.broadsoft.com/node/422649) pentru mai multe informații despre scala XSP.

Telefoane fizice și accesorii

Profiluri de dispozitiv

Acestea sunt fișierele DTAF pe care trebuie să le încărcați pe serverele de aplicații pentru a accepta aplicații Webex ca clienți de apelare. Acestea sunt aceleași fișiere DTAF ca și cele utilizate pentru UC-One SaaS, cu toate acestea există o nouă config-wxt.xml.template care este utilizat pentru aplicații Webex.

Nume client

Tipul profilului dispozitivului și numele pachetului

Șablon webex mobil

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

Tip profil identitate/dispozitiv: Conectare - Mobil

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

Fișier de configurare: config-wxt.xml

Șablon tabletă Webex

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

Tip profil identitate/dispozitiv: Conectare - Tabletă

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

Fișier de configurare: config-wxt.xml

Șablon desktop Webex

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

Tip profil identitate/dispozitiv: Comunicator de afaceri - PC

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

Fișier de configurare: config-wxt.xml

Certificate de comandă

Cerințe de certificat pentru autentificarea TLS

Veți avea nevoie de certificate de securitate, semnate de o autoritate de certificare bine-cunoscută și implementate pe XSP-urile publice cu care se confruntă, pentru toate aplicațiile necesare. Acestea vor fi utilizate pentru a accepta verificarea certificatului TLS pentru toată conectivitatea de intrare la serverele XSP.

Aceste certificate ar trebui să includă numele de domeniu public complet calificat XSP ca nume comun subiect sau nume alternativ subiect.

Cerințele exacte pentru implementarea acestor certificate de server depind de modul în care sunt implementate XSP-urile cu care se confruntă publicul:

  • Printr-un proxy de punte TLS

  • Printr-un proxy pass-through TLS

  • Direct la XSP

Următoarea diagramă rezumă în cazul în care certificatul de server public semnat CA trebuie să fie încărcate în aceste trei cazuri:

CC-urile acceptate public pe care aplicația Webex le acceptă pentru autentificare sunt listate în Autorități de certificare acceptate pentru Servicii hibride Webex.

Cerințe de certificat TLS pentru proxy-ul TLS-bridge

  • Certificatul de server semnat public este încărcat în proxy.

  • Proxy-ul prezintă acest certificat de server semnat public webex.

  • Webex are încredere în CA publice care a semnat certificatul de server proxy lui.

  • Un certificat intern semnat CA poate fi încărcat pe XSP.

  • XSP prezintă acest certificat de server semnat intern la proxy.

  • Proxy-ul are încredere în CA intern care a semnat certificatul de server XSP.

Cerințe de certificat TLS pentru proxy-ul TLS-passthrough sau XSP în DMZ

  • Certificatul de server semnat public este încărcat în XSP-uri.

  • XSP-urile prezintă certificate de server semnate public către Webex.

  • Webex are încredere în CA publice care a semnat certificatele de server XSPs ".

Cerințe suplimentare de certificat pentru autentificarea TLS reciprocă prin interfața CTI

Când vă conectați la interfața CTI, Webex prezintă un certificat de client ca parte a autentificării reciproce TLS. Certificatul de client Webex CA/chain certificat este disponibil pentru descărcare prin Control Hub.

Pentru a descărca certificatul:

Conectați-vă la Hubul partener, accesați Setări > Apelare BroadWorks și faceți clic pe linkul certificatului de descărcare.

Cerințele exacte pentru implementarea acestui lanț de certificate Webex CA depind de modul în care sunt implementate XSP-urile cu care se confruntă publicul:

  • Printr-un proxy de punte TLS

  • Printr-un proxy pass-through TLS

  • Direct la XSP

Următoarea diagramă rezumă cerințele certificatului în aceste trei cazuri:

Figura 1. Schimb de certificate mTLS pentru CTI prin diferite configurații edge

(Opțiune) Cerințe de certificat pentru proxy-ul TLS-bridge

  • Webex prezintă proxy-ului un certificat de client semnat public.

  • Proxy-ul are încredere în CISCO interne CA care a semnat certificatul de client. Puteți descărca acest CA / lanț din Control Hub și îl puteți adăuga la magazinul de încredere al proxy-ului. Certificatul de server XSP semnat public este, de asemenea, încărcat în proxy.

  • Proxy-ul prezintă certificatul de server semnat public webex.

  • Webex are încredere în CA publice care a semnat certificatul de server proxy lui.

  • Proxy-ul prezintă XSP-urilor un certificat de client semnat intern.

    Acest certificat trebuie să aibă câmpul de extensie x509.v3 Utilizare extinsă cheie populată cu scopul BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 și scopul TLS clientAuth. Exemplu.:

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

    NC-ul certificatului intern trebuie bwcticlient.webex.com.


    • Când generați certificate client interne pentru proxy, rețineți că certificatele SAN nu sunt acceptate. Certificatele de server interne pentru XSP pot fi SAN.

    • Este posibil ca autoritățile publice de certificare să nu fie dispuse să semneze certificatele cu OID-ul proprietar BroadWorks care este necesar. În cazul unui proxy punte, este posibil să fiți obligat să utilizați un CA intern pentru a semna certificatul de client pe care proxy-ul îl prezintă XSP.

  • XSP-urile au încredere în CA-ul intern.

  • XSP-urile prezintă un certificat de server semnat intern.

  • Proxy-ul are încredere în CA-ul intern.

  • Id-ul client al serverului de aplicații conține CN-ul certificatului de client semnat intern prezentat XSP de proxy.

(Opțiune) Cerințe de certificat pentru proxy-ul TLS-passthrough sau XSP în DMZ

  • Webex prezintă XSP-urilor un certificat intern de client semnat ca Cisco.

  • XSP-urile au încredere în CISCO intern CA care a semnat certificatul de client. Puteți descărca acest CA / lanț din Control Hub și îl puteți adăuga la magazinul de încredere al proxy-ului. Certificatul de server XSP semnat public este, de asemenea, încărcat în XSP-uri.

  • XSP-urile prezintă webex certificatele de server semnate public.

  • Webex are încredere în CA publice care a semnat certificatele de server XSPs ".

  • Id-ul client Application Server conține CN-ul certificatului de client semnat Cisco prezentat XSP de Webex.

Pregătirea rețelei

Hartă conexiune

Următoarea diagramă ilustrează punctele de integrare. Scopul diagramei este de a arăta că trebuie să revizuiți IP-urile și porturile pentru conexiuni în și din mediul dvs. Conexiunile utilizate de Webex pentru BroadWorks sunt descrise în tabelele ulterioare.

Cerințele paravanului de protecție pentru funcționarea normală a aplicației client sunt listate ca referințe, deoarece acestea sunt deja documentate pe help.webex.com.

Configurare paravan de protecție

Harta conexiunii și următoarele tabele descriu conexiunile și protocoalele necesare între clienți (în rețea sau în afara rețelei clientului), rețea și platforma Webex.

Reguli de intrare EMEA

(În rețeaua dvs.)

scop Sursă protocol Destinație Port destinație

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

HTTPS

ITO

XSP-ul dvs.

TCP/TLS 8012

443

Aplicație Webex

Xsi/DMS

oricare

HTTPS

XSP-ul dvs.

443

Webex app VoIP puncte finale SIP

oricare

SIP

SBC-ul dvs.

Protocol și port definite de SP

TCP/UDP


Este recomandabil ca portul SIP să fie diferit de 5060 (de exemplu, 5075) din cauza problemelor cunoscute legate de utilizarea portului STANDARD SIP (5060) cu dispozitive mobile.

Reguli EMEA privind ieșirea din ue

(În afara rețelei)

scop

Sursă

protocol

Destinație

Port destinație

Asigurarea accesului utilizatorilor prin API-uri

Serverul de aplicații

HTTPS

webexapis.com

443

Notificări push proxy (serviciu de producție)

Serverul NPS

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

Identitate comună Webex

Serverul NPS

HTTPS

https://idbroker-eu.webex.com

443

Identitate comună Webex

Serviciul Auth XSP

HTTPS

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

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

443

Servicii APNS și FCM

Serverul NPS

HTTPS

Orice adresă IP*

443

Notificări push proxy (serviciu de producție)

Identitate comună Webex

Servicii APNS și FCM

Serverul NPS

HTTPS

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

https://idbroker-eu.webex.com

Orice adresă IP*

443

Asigurarea accesului utilizatorilor prin adaptorul de asigurare a accesului BroadWorks

Your BroadWorks AS

HTTPS

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

(în cazul în care * ar putea fi orice scrisoare. ADRESA URL exactă de asigurare a accesului este disponibilă în șablonul pe care îl creați în Hubul pentru parteneri)

443

† Aceste intervale conțin gazdele pentru proxy NPS, dar nu putem da adresele exacte. Intervalele pot conține, de asemenea, gazde care nu sunt legate de Webex pentru BroadWorks. Vă recomandăm să configurați paravanul de protecție pentru a permite traficul către proxy-ul NPS FQDN în schimb, pentru a vă asigura că ieșirea este doar față de gazdele pe care le expunem pentru proxy-ul NPS.

* APNS și FCM nu au un set fix de adrese IP.

Statele Unite ale Americii Ingress Reguli

(În rețeaua dvs.)

scop

Sursă

protocol

Destinație

Port destinație

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

HTTPS

ITO

XSP-ul dvs.

TCP/TLS 8012

TLS 443

Aplicație Webex   

Xsi/DMS

oricare

HTTPS

XSP-ul dvs.

443

Puncte finale Webex App VoIP SIP

oricare

SIP

SBC-ul dvs.

Protocol și port definite de SP

TCP/UDP


Este recomandabil ca portul SIP să fie diferit de 5060 (de exemplu, 5075) din cauza problemelor cunoscute legate de utilizarea portului STANDARD SIP (5060) cu dispozitive mobile.

Statele Unite ale Americii Egress Reguli

(În afara rețelei)

scop

Sursă

protocol

Destinație

Port destinație

Asigurarea accesului utilizatorilor prin API-uri

Serverul de aplicații

HTTPS

webexapis.com

443

Notificări push proxy (serviciu de producție)

Serverul NPS

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

Identitate comună Webex

Serverul NPS

HTTPS

https://idbroker.webex.com

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

443

Identitate comună Webex

Serviciul Auth XSP

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

Servicii APNS și FCM

Serverul NPS

HTTPS

Orice adresă IP*

443

Asigurarea accesului utilizatorilor prin adaptorul de asigurare a accesului BWKS

Your BroadWorks AS

HTTPS

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

(în cazul în care * ar putea fi orice scrisoare. ADRESA URL exactă de asigurare a accesului este disponibilă în șablonul pe care îl creați în Hubul pentru parteneri)

443

† Aceste intervale conțin gazdele pentru proxy NPS, dar nu putem da adresele exacte. Intervalele pot conține, de asemenea, gazde care nu sunt legate de Webex pentru BroadWorks. Vă recomandăm să configurați paravanul de protecție pentru a permite traficul către proxy-ul NPS FQDN în schimb, pentru a vă asigura că ieșirea este doar față de gazdele pe care le expunem pentru proxy-ul NPS.

* APNS și FCM nu au un set fix de adrese IP.

Cerințe de rețea pentru Servicii Webex

Tabelele paravan de protecție anterioare Reguli intrare și ieșire documentează numai conexiunile specifice Webex pentru BroadWorks. Pentru informații generale despre conexiunile dintre aplicația Webex și cloud-ul Webex, consultați Cerințe de rețea pentru Webex Services. Acest articol este generic pentru Webex, dar următorul tabel identifică diferitele secțiuni ale articolului și cât de relevantă este fiecare secțiune pentru Webex pentru BroadWorks.

Tabelul 1. Cerințe de rețea pentru conexiunile aplicației Webex (generic)

Secțiunea cerințelor de rețea Articol

Relevanța informațiilor

Rezumatul tipurilor de dispozitive și protocoalelor acceptate de Webex

Informaţionale

Protocoale de transport și cifruri de criptare pentru aplicațiile și dispozitivele Webex înregistrate în cloud

Informaţionale

Webex Services – Numere de port și protocoale

Trebuie să citiți

Subrețele IP pentru servicii media Webex

Trebuie să citiți

Domenii și URL-uri care trebuie accesate pentru Webex Services

Trebuie să citiți

URL-uri suplimentare pentru servicii hibride Webex

Opțional

Caracteristici proxy

Opțional

802.1X – Control acces rețea bazat pe porturi

Opțional

Cerințe de rețea pentru serviciile Webex bazate pe SIP

Opțional

Cerințe de rețea pentru Webex Edge Audio

Opțional

Un rezumat al altor servicii și documentații Webex Hybrid

Opțional

Servicii Webex pentru clienții FedRAMP

Nu este cazul

Informații suplimentare

Pentru informații suplimentare, consultați Webex App Firewall Whitepaper (PDF).

Asistență pentru redundanță BroadWorks

Serviciile Cloud Webex și aplicațiile client Webex care trebuie să acceseze rețeaua partenerului acceptă pe deplin redundanța Broadworks XSP furnizată de partener. Atunci când un XSP sau un site nu este disponibil din motive de întreținere planificate sau neplanificate, serviciile Webex și aplicațiile pot avansa către un alt XSP sau site furnizat de partener pentru a finaliza o solicitare.

Topologie rețea

XSP-urile Broadworks pot fi implementate direct pe Internet sau pot locui într-un DMZ frontat de un element de echilibrare a sarcinii, ar fi F5 BIG-IP. Pentru a oferi geo-redundanță, XSP-urile pot fi implementate în două (sau mai multe) centre de date, fiecare putând fi fronted de un balansor de sarcină, fiecare având o adresă IP publică. Dacă XSP-urile se află în spatele unui balansor de sarcină, microservicii Webex și App văd doar adresa IP a balansorului de sarcină, iar Broadworks pare să aibă doar un XSP, chiar dacă există mai multe XSP-uri în spate.

În exemplul de mai jos, XSP-urile sunt implementate în două site-uri, site-ul A și site-ul B. Există două XSP-uri frontate de un balancer de încărcare la fiecare site. Site-ul A are XSP1 și XSP2 fronted de LB1, iar site-ul B are XSP3 și XSP4 fronted de LB2. Numai balanțele de încărcare sunt expuse în rețeaua publică, iar XSP-urile se află în rețelele private DMZ.

Servicii Cloud Webex

Configurare DNS

Microservicii Webex Cloud trebuie să poată găsi serverul (serverele) Broadworks XSP pentru conectarea la interfețele Xsi, serviciul de autentificare și CTI.

Microservicii Webex Cloud va efectua DNS A / AAAA căutare a numelui de gazdă XSP configurat și conectați-vă la adresa IP returnată. Acesta ar putea fi un element de margine de echilibrare a sarcinii sau ar putea fi serverul XSP în sine. Dacă sunt returnate mai multe adrese IP, va fi selectat primul IP din listă. Căutarea SRV nu este acceptată în prezent.

Exemplu: DNS-ul partenerului A Record pentru descoperirea serverului XSP/Load Balancers orientat spre internet Round-Robin

Tip înregistrare

Nume

Țintă

scop

A

xsp.example.com

198.51.100.48

Puncte către LB1 (site-ul A)

A

xsp.example.com

198.51.100.49

Puncte către LB2 (site-ul B)

Nereușită

Când microservicii Webex trimite o solicitare la XSP/ Load Balancer și solicitarea nu reușește, se pot întâmpla mai multe lucruri:

  • Dacă eroarea se datorează unei erori de rețea (de exemplu: TCP, SSL), microservicii Webex marca IP ca blocat și să efectueze imediat un avans traseu la IP următoare.

  • Dacă se returnează un cod de eroare (HTTP 5xx), microservicii Webex marchează IP-ul ca blocat și efectuează imediat un avans de rută către următorul IP.

  • Dacă nu se primește niciun răspuns HTTP în decurs de 2 secunde, solicitarea expiră și microservicii Webex marchează IP-ul ca blocat și efectuează un avans de rută către următorul IP.

Fiecare solicitare este încercată de 3 ori înainte ca o defecțiune să fie raportată înapoi la microservicii.

Atunci când un IP se află în lista blocată, acesta nu va fi inclus în lista de adrese pentru a încerca atunci când trimiteți o solicitare către un XSP. După o perioadă predeterminată de timp, un IP blocat expiră și revine în listă pentru a încerca când se face o altă solicitare.

Dacă toate adresele IP sunt blocate, microserviciul va încerca în continuare să trimită solicitarea selectând aleatoriu o adresă IP din lista blocată. Dacă reușește, adresa IP respectivă este eliminată din lista blocată.

Stare

Starea conectivității serviciilor Webex Cloud la XSP-uri sau Balanțe de încărcare poate fi văzută în Control Hub. Sub un cluster de apelare BroadWorks, se afișează o stare de conexiune pentru fiecare dintre aceste interfețe:

  • Acțiuni XSI

  • Evenimente XSI

  • Serviciu de autentificare

Starea conexiunii este actualizată atunci când pagina este încărcată sau în timpul actualizărilor de intrare. Stările conexiunilor pot fi:

  • verde: Când interfața poate fi atinsă pe unul dintre IP-urile din căutarea de înregistrări A.

  • roșu: Când toate IPs în căutarea de înregistrare A sunt inaplicabile și interfața nu este disponibilă.

Următoarele servicii utilizează microservicii pentru a se conecta la XSP-uri și sunt afectate de disponibilitatea interfeței XSP:

  • Conectare Webex App

  • Reîmprospătare simbol Webex App

  • Activare prin e-mail/autoservire de încredere

  • Verificarea stării de sănătate a serviciului Broadworks

Aplicație Webex

Configurare DNS

Aplicația Webex accesează serviciile Xtended Services Interface (XSI-Actions &XSI-Events) și Device Management Service (DMS) pe XSP.

Se va efectua căutarea DNS SRV pentru _xsi-client._tcp.<xsi domain> url-ul configurat pentru a găsi gazdele XSP sau balansoarele de încărcare pentru serviciul XSI.

Mai jos este un exemplu de înregistrări SRV.

Tip înregistrare

Înregistrare

Țintă

scop

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc1.example.com

Descoperirea de catre client a interfetei Xsi

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc2.example.com

Descoperirea de catre client a interfetei Xsi

A

xsp-dc1.example.com

198.51.100.48

Puncte către LB1 (site-ul A)

A

xsp-dc2.example.com

198.51.100.49

Puncte către LB2 (site-ul B)


Fiecare înregistrare A/AAAA trebuie să se mapeze la o singură adresă IP. Dacă există mai multe XSP-uri într-un DMZ în spatele dispozitivului de echilibrare a sarcinii / margine, este necesar ca balansorul de sarcină să fie configurat pentru a menține persistența sesiunii pentru a direcționa toate solicitările aceleiași sesiuni către același XSP.

Mandatăm această configurație, deoarece bătăile inimii evenimentului XSI al clientului trebuie să meargă la același XSP care este utilizat pentru a stabili canalul de evenimente.

Dacă mapați numele A/AAAA la mai multe adrese IP sau dacă elementul de echilibrare/margine de încărcare nu menține persistența sesiunii, clientul trimite în cele din urmă bătăile inimii la un XSP unde nu a stabilit un canal de evenimente. Acest lucru duce la demolarea canalului și, de asemenea, la un trafic intern semnificativ mai mare, ceea ce afectează performanța clusterului XSP.

În timpul procesului de conectare, Aplicația Webex va prelua, de asemenea, URL-ul DMS pentru a descărca fișierul său de configurare. Gazda din URL va fi analizată și Aplicația Webex va efectua căutarea DNS A/AAAA a gazdei pentru a se conecta la XSP care găzduiește serviciul DMS.

Exemplu: DNS O înregistrare pentru descoperirea Round-Robin echilibrat internet cu care se confruntă XSP server / Load Balancers de Webex App pentru a descărca fișiere de configurare prin DMS:

Tip înregistrare

Nume

Țintă

scop

A

xsp-dms.example.com

198.51.100.48

Puncte către LB1 (site-ul A)

A

xsp-dms.example.com

198.51.100.49

Puncte către LB2 (site-ul B)

găsește Webex App adrese XSP

Clientul încearcă să localizeze nodurile XSP utilizând următorul flux DNS:

  1. Clientul regăsește inițial URL-uri Xsi-Actions/Xsi-Events din Webex Cloud (le-ați introdus atunci când creați clusterul de apelare BroadWorks asociat). Numele de gazdă/domeniul Xsi este analizat din URL și clientul efectuează căutarea SRV după urmează:

    1. Clientul efectuează o căutare SRV pentru _xsi-client._tcp.<xsi domain="">

    2. Dacă căutarea SRV returnează una sau mai multe ținte:

      1. Clientul face căutare A/AAAA pentru acele ținte și memorează în cache adresele IP returnate.

      2. Clientul se conectează la una dintre ținte (și, prin urmare, înregistrarea sa A / AAAA cu o singură adresă IP) pe baza priorității SRV, apoi greutatea (sau la întâmplare, dacă toate sunt egale).

    3. Dacă căutarea SRV nu returnează nicio țintă:

      Clientul face căutarea A/AAAA a parametrului rădăcină Xsi și apoi încearcă să se conecteze la adresa IP returnată. Acesta ar putea fi un element de margine de echilibrare a sarcinii sau ar putea fi serverul XSP în sine.

      După sa menționat, înregistrarea A /AAAA trebuie să rezolve la o adresă IP din aceleași motive.

  2. (Opțional) Ulterior, puteți furniza detalii personalizate XSI-Actions/XSI-Events în configurația dispozitivului pentru aplicația Webex, utilizând următoarele etichete:

    <protocols>
    	<xsi>
    		<paths>
    			<root>%XSI_ROOT_WXT%</root>
    			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
    			<events>%XSI_EVENTS_PATH_WXT%</events>
    		</paths>
    	</xsi>
    </protocols>
    1. Acești parametri de configurare au prioritate față de orice configurație din Clusterul BroadWorks din Control Hub.

    2. Dacă există, clientul se va compara cu adresa XSI originală pe care a primit-o prin configurația Cluster BroadWorks.

    3. Dacă există vreo diferență detectată, clientul va re-inițializa conectivitatea XSI Actions / XSI Events. Primul pas în acest sens este de a efectua același proces de căutare DNS enumerate sub pasul 1 - de data aceasta solicitând o căutare pentru valoarea în parametrul %XSI_ROOT_WXT% din fișierul său de configurare.


      Asigurați-vă că creați înregistrările SRV corespunzătoare dacă utilizați această etichetă pentru a modifica interfețele Xsi.
Nereușită

În timpul conectării, Aplicația Webex efectuează o căutare DNS SRV pentru _xsi-client._tcp.<xsi domain="">, construiește o listă de gazde și se conectează la una dintre gazde pe baza priorității SRV, apoi greutatea. Această gazdă conectată devine cea selectată pentru toate solicitările viitoare. Un canal de evenimente este apoi deschis gazdei selectate și o bătaie de inimă este trimisă în mod regulat pentru a verifica canalul. Toate solicitările trimise după prima includ un modul cookie care este returnat în răspunsul HTTP, prin urmare, este important ca balansorul de încărcare să păstreze persistența sesiunii (afinitate) și să trimită întotdeauna solicitări către același server XSP backend.

Dacă o solicitare sau o solicitare de bătăi de inimă către o gazdă nu reușește, se pot întâmpla mai multe lucruri:

  • Dacă eroarea se datorează unei erori de rețea (de exemplu: TCP, SSL), Aplicația Webex direcționează imediat avansurile către următoarea gazdă din listă.

  • Dacă se returnează un cod de eroare (HTTP 5xx), solicitarea nu reușește imediat.

  • Dacă un răspuns nu este primit într-o perioadă de timp, atunci solicitarea este considerată nereușită din cauza expirare și următoarele solicitări sunt trimise la următoarea gazdă. Cu toate acestea, cererea de expirare este considerată nereușită. Unele solicitări sunt reîncercate după eșec (cu creșterea timpului de reîncercare). Cererile ca presupusa non vitale nu sunt rejudecate.

Când o gazdă nouă este încercată cu succes, devine noua gazdă selectată dacă gazda este prezentă în listă. După ce se încearcă ultima gazdă din listă, aplicația Webex se va răsturna la prima.

În cazul bătăilor inimii, dacă există două erori consecutive de solicitare, Aplicația Webex va re-inițializa canalul de evenimente.

Rețineți că Aplicația Webex nu efectuează fail-back, iar descoperirea serviciului DNS se efectuează o singură dată la conectare.

În timpul conectivului, Aplicația Webex încearcă să descarce fișierul de configurare prin interfața XSP/ Dms. Efectuează o căutare de înregistrări A/AAAA a gazdei în URL-ul DMS regăsit și se conectează la primul IP. Acesta va încerca mai întâi să trimită solicitarea de a descărca fișierul de configurare folosind un simbol SSO. Dacă acest lucru nu reușește din orice motiv, va încerca din nou, dar cu numele de utilizator și parola dispozitivului.