Preparazione dell'ambiente

Punti decisione

Considerazione Domande a cui rispondere Risorse

Architettura e infrastruttura

Quanti XSP?

Come prendono mTLS?

Pianificatore capacità sistema Cisco BroadWorks

Guida tecnica del sistema Cisco BroadWorks

Riferimento CLI XSP

Questo documento

Provisioning clienti e utenti

È possibile asserre che si considera attendibili i messaggi e-mail in BroadWorks?

Si desidera che gli utenti forniranno gli indirizzi e-mail per attivare i propri account?

È possibile creare strumenti per utilizzare la nostra API?

Doc API pubblici su https://developer.webex.com

Questo documento

Branding Quale colore e logo si desidera utilizzare? Articolo sul branding dei team
Modelli Quali sono i diversi casi d'uso dei clienti? Questo documento
Funzioni del sottoscrittore per cliente/azienda/gruppo Scegliere il pacchetto per definire il livello di servizio per modello. Base, Standard, Premium

Questo documento

Matrice funzioni/pacchetto

Autenticazione utente BroadWorks o Webex Questo documento
Adattatore di provisioning (per le opzioni di provisioning flowre)

Utilizzi già IM&P integrato, ad esempio per UC-One SaaS?

Utilizzare più modelli?

Esiste un caso d'uso più comune previsto?

Questo documento

Riferimento CLI server applicazione

Architettura e infrastruttura

  • Con quale scala intendete iniziare? È possibile aumentare la scalabilità in futuro, ma la stima dell'uso corrente deve guidare la pianificazione dell'infrastruttura.

  • Collaborare con il responsabile dell'account o con il rappresentante di vendita Cisco per ridimensionare l'infrastruttura XSP, in base alla capacità del sistema Cisco BroadWorks ( https://xchange.broadsoft.com/node/473873 ) e alla Guida tecnica del sistema Cisco Broad Works ( https://xchange.broadsoft.com/node/422649).

  • Come è Cisco Webex connessioni TLS reciproche agli XSP? Accedere direttamente a XSP in una DMZ o tramite proxy TLS? Ciò incide sulla gestione certificati e sugli URL utilizzati per le interfacce. ( le connessioni TCP non crittografate non sonosupportate al limite dellarete).

Provisioning clienti e utenti

Quale metodo di provisioning utente è più adatto alle esigenze?

  • Provisioning flow con messaggi e-mailattendibili: Assegnando il servizio "IM&P integrato" su BroadWorks, il sottoscrittore viene predisposto automaticamente nel Cisco Webex.

    Se è anche possibile asserre che gli indirizzi e-mail dell'abbonato in BroadWorks sono validi e univoci per Webex, è possibile utilizzare la varianti "e-mail attendibile" del provisioning flow provisioning. Gli account Webex del sottoscrittore vengono creati e attivati senza il loro intervento; semplicemente scaricare il client ed eseguire l'accesso.

    Indirizzo e-mail è un attributo utente chiave Cisco Webex. Pertanto l'provider di servizi specificare un indirizzo e-mail valido per l'utente per potervi fornire i Cisco Webex assistenza. Deve essere in attributo ID e-mail dell'utente in BroadWorks. Si consiglia di copiarlo nell'attributo ID alternativo.

  • Provisioning flow senza messaggi e-mailattendibili: Se non si riesce a verificare l'attendibilità degli indirizzi e-mail dell'abbonato, è comunque possibile assegnare il servizio IM&P integrato in BroadWorks per il provisioning degli utenti in Webex.

    Con questa opzione, gli account vengono creati quando si assegna il servizio, ma gli abbonati devono fornire e convalidare i relativi indirizzi e-mail per attivare gli account Webex.

  • Self-Provisioningutente: Questa opzione non richiede l'assegnazione del servizio IM&P in BroadWorks. L'utente (o i clienti) distribuiscono invece un collegamento di provisioning e i collegamenti per scaricare diversi client, con il branding e le istruzioni.

    Gli abbonati seguono il collegamento, quindi forniscono e convalidano gli indirizzi e-mail per creare e attivare i propri account Webex. Quindi scaricano il client e a quel punto Webex recuperano alcune configurazioni aggiuntive su di esse da BroadWorks (inclusi i numeri principali).

  • Provisioning controllato da SP tramiteAPI: Cisco Webex una serie di API pubbliche che consentono ai provider di servizi di creare provisioning di utenti/abbonati nei flussi di lavoro esistenti.

Branding

È possibile applicare un logo e un singolo colore (per il barra di navigazione) al Webex Teams client. Il portale di attivazione utenti utilizza le stesse impostazioni.

Modelli cliente

I modelli clienti consentono di definire i parametri in base ai quali i clienti e gli abbonati associati vengono predisposti automaticamente Cisco Webex per BroadWorks. È possibile configurare più modelli cliente come richiesto. Di seguito sono elencati alcuni parametri principali.

Pacchetto

  • È necessario selezionare un pacchetto predefinito quando si crea un modello (per informazioni dettagliate, vedere Pacchetti nella sezione Panoramica). Tutti gli utenti predisposti con tale modello, mediante flusso o auto-provisioning, ricevono il pacchetto predefinito.

  • È possibile controllare la selezione del pacchetto per diversi clienti creando più modelli e selezionando diversi pacchetti predefiniti in ciascuno. È possibile quindi distribuire diversi collegamenti di provisioning o diversi utenti per provisioning aziendale, a seconda del metodo di provisioning dell'utente scelto per tali modelli.

  • È possibile modificare il pacchetto di abbonati specifici da questo valore predefinito, utilizzando l'API di provisioning (vedere Integrazione con l'API di provisioning Webex per BroadWorks nella sezione di riferimento) o attraverso Partner Hub.

  • Non è possibile modificare il pacchetto di un abbonato da BroadWorks. L'assegnazione del servizio IM&P integrato è on-on o off; se l'abbonato è assegnato a questo servizio in BroadWorks, il modello Hub partner associato all'URL di provisioning dell'azienda di tale abbonato definisce il pacchetto.

Rivenditori e aziende o provider di servizi e gruppi?

  • La configurazione del sistema BroadWorks ha un impatto sul flusso attraverso il provisioning. Se si è un rivenditore con Aziende, è necessario abilitare la modalità Enterprise quando si crea un modello.
  • Se il sistema BroadWorks è configurato in provider di servizi interattiva, è possibile lasciare la modalità Enterprise disattivata nei modelli.
  • Se si intende eseguire il provisioning delle organizzazioni dei clienti utilizzando entrambe le modalità BroadWorks, è necessario utilizzare modelli diversi per gruppi e aziende.

Modalità di autenticazione

In che modo gli abbonati dei clienti eseguono l'autenticazione?

Modalità di autenticazione BroadWorks Webex
Identità utente principale File BroadWorks ID utente Indirizzo e-mail
provider di identità

BroadWorks.

L'autenticazione è facilitata da un servizio intermedio ospitato da Cisco Webex.

Cisco Common Identity
Autenticazione multi-fattori? No Richiede un IdP cliente che supporti l'autenticazione multi-factor.

Percorso di convalida credenziali

  1. Il browser viene avviato quando l'utente fornisce messaggi e-mail al flusso di accesso iniziale e rileva la modalità di autenticazione.

  2. Il browser viene quindi reindirizzato a Cisco Webex di accesso BroadWorks ospitata (questa pagina è brandable)

  3. L'utente fornisce ID utente e password BroadWorks nella pagina di accesso.

  4. Le credenziali utente vengono convalidate in base a BroadWorks.

  5. In caso positivo, si ottiene un codice di autorizzazione da Cisco Webex. Utilizzato per ottenere i token di accesso necessari per Cisco Webex servizi.

  1. Il browser viene avviato quando l'utente fornisce messaggi e-mail al flusso di accesso iniziale e rileva la modalità di autenticazione.

  2. Il browser viene reindirizzato all'IdP (Cisco Common Identity o IdP cliente) a cui verrà visualizzato un portale di accesso.

  3. L'utente fornisce le credenziali appropriate sulla pagina di accesso

  4. L'autenticazione a più fattori può verificarsi se l'IdP del cliente supporta tale opzione.

  5. In caso positivo, si ottiene un codice di autorizzazione da Cisco Webex. Utilizzato per ottenere i token di accesso necessari per Cisco Webex servizi.

Accordi con più partner

Stai per aggiungere la licenza secondaria Webex per BroadWorks a un altro provider di servizi? In tal caso, ciascun provider di servizi avrà bisogno di un'organizzazione partner distinta in Webex Control Hub di permettere loro di fornire la soluzione per la propria base clienti.

Adattatore e modelli di provisioning

Quando si utilizza il provisioning flowre, l'URL di provisioning inserito in BroadWorks è derivato dal modello in Control Hub. È possibile disporre di più modelli e, quindi, di più URL di provisioning. Ciò consente di selezionare, su base aziendale, il pacchetto da applicare agli abbonati quando hanno ottenuto la concessione del servizio IM&P integrato.

È necessario considerare se si desidera impostare un URL di provisioning a livello di sistema come percorso di provisioning predefinito e il modello che si desidera utilizzare. In questo modo, è necessario solo impostare in modo esplicito l'URL di provisioning per le aziende che necessitano di un modello diverso.

Tenere presente, inoltre, che potrebbe essere già stato utilizzato un URL di provisioning a livello di sistema, ad esempio UC-One SaaS. In tal caso, è possibile scegliere di mantenere l'URL a livello di sistema per il provisioning degli utenti su UC-One SaaS e sostituire per tali aziende che si trasferino a Webex per BroadWorks. In alternativa, è possibile passare al percorso alternativo e impostare l'URL a livello di sistema per Webex per BroadWorks e riconfigurare le aziende che si desidera mantenere su UC-One SaaS.

Le scelte di configurazione relative a questa decisione sono dettagliate in Configurazione del server applicazioni con URL del servizio di provisioning nella sezione Distribuisci Webex per BroadWorks.

Requisiti minimi

Account

Tutti gli abbonati disponibili per Webex devono esistere nel sistema BroadWorks integrato con Webex. Se necessario, è possibile integrare più sistemi BroadWorks.

Tutti gli abbonati devono disporre di licenze BroadWorks e numeri principali.

Webex utilizza gli indirizzi e-mail come identificativi principali per tutti gli utenti. Se si utilizza il provisioning flow con messaggi e-mail attendibili, gli utenti devono disporre di indirizzi validi nell'attributo e-mail in BroadWorks.

Se il modello utilizza l'autenticazione BroadWorks, è possibile copiare gli indirizzi e-mail dell'abbonato nell'attributo ID alternativo in BroadWorks. Ciò consente agli utenti di accedere a Webex utilizzando gli indirizzi e-mail e le relative password BroadWorks.

Gli amministratori devono utilizzare i relativi account Webex per accedere a Partner Hub.

Server nella rete e requisiti software

  • Istanze BroadWorks con versione minima R21 SP1. Vedere Requisiti software BroadWorks (in questo documento) per le versioni e le patch supportate. Vedere anche Gestione ciclo di vita - Server BroadSoft.


    R21 SP1 è supportato solo fino a metà 2021. Sebbene sia attualmente possibile integrare Webex con R21 SP1, si consiglia vivamente R22 o versioni successive per l'integrazione con Webex.

  • Le istanze BroadWorks devono includere almeno i seguenti server:

    • Server applicazioni (AS) con versione BroadWorks come indicato sopra

    • Server di rete (NS)

    • Server di profilo (PS)

  • I server XSP pubblici o la piattaforma ADP (Application Delivery Platform) soddisfare i seguenti requisiti:

    • Servizio di autenticazione (BWAuth)

    • Interfacce azioni ed eventi XSI

    • DMS (applicazione Web di gestione dispositivi)

    • Interfaccia CTI (Integrazione di telefonia telefonica su computer)

    • TLS 1.2 con un certificato valido (non autofirmato) ed eventuali intermedie richiesti. Richiede l'amministrazione a livello di sistema per facilitare la ricerca aziendale.

    • Autenticazione TLS reciproca (mTLS) per il servizio di autenticazione (richiede l'installazione della catena di certificati del client Cisco Webex pubblica come trust anchor)

    • Autenticazione TLS reciproca (mTLS) per interfaccia CTI (richiede l'installazione della catena di certificati del client Cisco Webex pubblica come trust anchor)

  • Un server XSP/ADP separato funge da "server push notifiche di chiamata" (un server NPS nel proprio ambiente utilizzato per eseguire il push delle notifiche di chiamata ad Apple/Google. Il nome "CNPS" viene chiamato qui per distinguerlo dal servizio in Webex per la consegna di notifiche push per messaggistica e presenza).

    Questo server deve essere su R22 o versioni successive.

  • È obbligatorio creare un server XSP/ADP separato per CNPS poiché l'impossibilità di caricare da Webex per connessioni cloud BWKS potrebbe avere un impatto negativo sulle prestazioni del server NPS, con il risultato di un aumento della latenza di notifica. Per ulteriori informazioni su scalaXSP, vedere la Guida tecnica del sistema Cisco BroadWorks ( https://xchange.broadsoft.com/node/422649) .

Telefoni e accessori fisici

Profili dispositivi

Questi sono i file DTAF che occorre caricare sui server applicazioni per supportare la Webex Teams come client chiamanti. Sono gli stessi file DTAF utilizzati per UC-One SaaS, tuttavia, è presente un nuovo file config-wxt.xml.template utilizzato per Webex Teams.

Nome client Tipo di profilo dispositivo e nome pacchetto

Webex Teams Mobile Template

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

Tipo di profilo identità/dispositivo: Connetti - Mobile

DTAF: ucone-mobile-ucaas_DTAF-#.#.#.###.zip

File di configurazione: config-wxt.xml

Webex Teams Desktop Template

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

Tipo di profilo identità/dispositivo: Communicator Aziendale - PC

DTAF: ucone-desktop-ucaas_DTAF-#.#.#.###.zip

File di configurazione: config-wxt.xml

Ordina certificati

Requisiti di certificato per l'autenticazione TLS

Sono necessari i Certificati di sicurezza, firmati da un'autorità di certificazione attendibile e distribuiti sugli XSP pubblici, per tutte le applicazioni richieste. Verranno utilizzati per supportare la verifica del certificato TLS per tutta la connettività in ingresso ai server XSP.

Questi certificati devono includere il nome nome di dominio completo pubblico XSP come Nome comune oggetto o Nome alternativo oggetto.

I requisiti esatti per la distribuzione di questi certificati server dipendono dalla distribuzione dei XSP pubblici:

  • Tramite un proxy di bridging TLS

  • Tramite un proxy pass-through TLS

  • Direttamente a XSP

Il diagramma seguente riepiloga dove deve essere caricato il certificato del server pubblico firmato da CA in questi tre casi:

Le CA pubblicamente supportate che Webex Teams supportano per l'autenticazione sono elencate in Autorità di certificazione supportate per Cisco Webex ibridi.

Requisiti del certificato TLS per il proxy con bridge TLS

  • Il certificato del server firmato pubblicamente viene caricato nel proxy.

  • Il proxy presenta questo certificato del server firmato pubblicamente in Webex.

  • Webex considera attendibile la CA pubblica che ha firmato il certificato del server del proxy.

  • Un certificato firmato dalla CA interna può essere caricato sul XSP.

  • Il XSP presenta questo certificato del server firmato internamente al proxy.

  • Il proxy considera attendibile la CA interna che ha firmato il certificato del server XSP.

Requisiti certificato TLS per proxy passle TLS o XSP in DMZ

  • Il certificato del server firmato pubblicamente viene caricato negli XSP.

  • Gli XSP presentano certificati server firmati pubblicamente a Webex.

  • Webex considera attendibile la CA pubblica che ha firmato i certificati del server XSP.

Requisiti di certificato aggiuntivi per l'autenticazione TLS reciproca con AuthService

Cisco Webex interagisce con il servizio di autenticazione su una (autenticazione) TLS reciproca autenticata. Ciò significa che Webex presenta un certificato client e il XSP deve convalidarlo. Per garantire l'attendibilità di questo certificato, utilizzare la catena di certificati CA Webex per creare un trust anchor su XSP (o proxy). La catena di certificati è disponibile per il download tramite Partner Hub:

  1. Andare a Impostazioni > chiamata BroadWorks.

  2. Fare clic sul collegamento per il download del certificato.


È possibile ottenere la catena di certificati anche da https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

I requisiti esatti per la distribuzione di questa catena di certificati CA Webex dipendono dalla distribuzione dei XSP pubblici:

  • Tramite un proxy di bridging TLS

  • Tramite un proxy pass-through TLS

  • Direttamente a XSP

Il diagramma seguente riepiloga i punti in cui la catena di certificati CA Webex deve essere distribuita in questi tre casi.

Requisiti del certificato TLS reciproca per il proxy con bridge TLS

  • Webex presenta un certificato client firmato dall'autorità di certificazione Webex nel proxy.

  • La catena di certificati CA Webex viene distribuita sull'archivio di attendibilità del proxy, pertanto il proxy considera attendibile il certificato client.

  • Anche il certificato del server XSP firmato pubblicamente viene caricato nel proxy.

  • Il proxy presenta un certificato del server firmato pubblicamente in Webex.

  • Webex considera attendibile la CA pubblica che ha firmato il certificato del server del proxy.

  • Il proxy presenta un certificato del client firmato internamente agli XSP.

    Questo certificato deve avere il campo dell'estensione x509.v3 Utilizzo chiave estesa compilato con BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3e lo scopo dell'autorizzazione del client TLS. Ad esempio.:

    Estensioni X509v3:

    Uso chiave estesa X509v3:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, Autenticazione client Web TLS 

    Quando si generano certificati del client interno per il proxy, tenere presente che i certificati SAN non sono supportati. I certificati del server interno per XSP possono essere SAN.

  • Gli XSP considerano attendibile la CA interna.

  • Gli XSP presentano un certificato server firmato internamente.

  • Il proxy considera attendibile la CA interna.

Requisiti del certificato TLS reciproca per il proxy passizzato TLS o XSP in DMZ

  • Webex presenta un certificato client firmato dall'Autorità di certificazione Webex sul server XSP.

  • La catena di certificati CA Webex viene distribuita sull'archivio di attendibilità degli XSP, pertanto i criteri XSP 4.5 44 44 45 45 45 50 40 40 50 000 certificati attendibili del client.

  • Anche il certificato del server XSP firmato pubblicamente viene caricato negli XSP.

  • Gli XSP presentano certificati server firmati pubblicamente a Webex.

  • Webex considera attendibile la CA pubblica che ha firmato i certificati del server XSP.

Ulteriori requisiti di certificato per l'autenticazione TLS reciproca su interfaccia CTI

Quando ci si connette all'interfaccia CTI, Cisco Webex un certificato client come parte dell'autenticazione TLS reciproca. Il certificato CA/catena di certificati del client Webex è disponibile per il download tramite Control Hub.

Per scaricare il certificato:

Accedere a Partner Hub, andare a Impostazioni > BroadWorks Calling e fare clic sul collegamento di download del certificato.

I requisiti esatti per la distribuzione di questa catena di certificati CA Webex dipendono dalla distribuzione dei XSP pubblici:

  • Tramite un proxy di bridging TLS

  • Tramite un proxy pass-through TLS

  • Direttamente a XSP

Il diagramma seguente riepiloga i requisiti dei certificati in questi tre casi:

Figura 1. MTLS Certificate Exchange per CTI tramite configurazioni Edge diverse

(Opzione) Requisiti di certificato per proxy tls-bridge

  • Webex presenta un certificato client firmato pubblicamente al proxy.

  • Il proxy considera attendibile la CA interna Cisco che ha firmato il certificato client. È possibile scaricare questa CA/ catena da Control Hub e aggiungerla all'archivio di attendibilità del proxy. Anche il certificato del server XSP firmato pubblicamente viene caricato nel proxy.

  • Il proxy presenta il certificato del server firmato pubblicamente in Webex.

  • Webex considera attendibile la CA pubblica che ha firmato il certificato del server del proxy.

  • Il proxy presenta un certificato del client firmato internamente agli XSP.

    Questo certificato deve avere il campo dell'estensione x509.v3 Utilizzo chiave estesa compilato con BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3e lo scopo dell'autorizzazione del client TLS. Ad esempio.:

    Estensioni X509v3:
        Uso chiave estesa X509v3:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, Autenticazione client Web TLS

    • Quando si generano certificati del client interno per il proxy, tenere presente che i certificati SAN non sono supportati. I certificati del server interno per XSP possono essere SAN.

    • Le autorità di certificazione pubbliche potrebbero non voler firmare i certificati con il OID broadworks proprietario richiesto. In caso di un proxy di bridging, si potrebbe essere obbligati a utilizzare una CA interna per firmare il certificato del client che il proxy presenta al XSP.

  • Gli XSP considerano attendibile la CA interna.

  • Gli XSP presentano un certificato server firmato internamente.

  • Il proxy considera attendibile la CA interna.

  • ClientIdentity del server applicazioni contiene il CN del certificato del client firmato internamente presentato al XSP dal proxy.

(Opzione) Requisiti di certificato per proxy con passpassazione TLS o XSP in DMZ

  • Webex presenta un certificato client firmato da CA interno Cisco agli XSP.

  • Gli XSP considera attendibili la CA interna Cisco che ha firmato il certificato client. È possibile scaricare questa CA/ catena da Control Hub e aggiungerla all'archivio di attendibilità del proxy. Anche il certificato del server XSP firmato pubblicamente viene caricato negli XSP.

  • Gli XSP presentano i certificati del server firmati pubblicamente a Webex.

  • Webex considera attendibile la CA pubblica che ha firmato i certificati del server XSP.

  • Il campo Application Server ClientIdentity (ClientIdentity) contiene il CN del certificato client firmato da Cisco presentato a XSP da Webex.

Preparazione della rete

Mappa connessione

Il diagramma seguente illustra i punti di integrazione. Il punto del diagramma è mostrare che è necessario esaminare gli IP e le porte per le connessioni in entrata e in uscita dal proprio ambiente. Le connessioni utilizzate da Webex per BroadWorks sono descritte nelle tabelle seguenti.

I requisiti del firewall per il normale funzionamento dell'applicazione client vengono tuttavia elencati come riferimenti poiché sono già documentati su help.webex.com.

Configurazione del firewall

La mappa delle connessioni e le tabelle seguenti descrivono le connessioni e i protocolli richiesti tra i client (su o fuori la rete del cliente), la rete e la piattaforma Webex.

Documentiamo solo le connessioni specifiche a Webex per BroadWorks. Le connessioni generiche tra Teams e il cloud Webex non vengono visualizzate, documentate su:

Regole di ingresso EMEA

(Nella rete)

Scopo Origine Protocol Destinazione Porta di destinazione

WebexCloud

CTI/Autorizzazione/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

Cti

Your XSP

TCP/TLS 8012

443

Webex Teams Client App

Xsi/DMS

Any

HTTPS

Your XSP

443

Webex Teams VoIP ENDPOINT SIP

Any

SIP

Il controller SBC

TCP configurato da SP

Regole di uscita EMEA

(Fuori rete)

Scopo

Origine

Protocol

Destinazione

Porta di destinazione

Provisioning utenti tramite API

Server dell'applicazione

HTTPS

webexapis.com

443

Notifiche push proxy (servizio di produzione)

Your NPS Server

HTTPS

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

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

443

Webex Common Identity

Your NPS Server

HTTPS

https://idbroker-eu.webex.com

443

Servizi APNS e FCM

Your NPS Server

HTTPS

Qualsiasi indirizzo IP*

443

Notifiche push proxy (servizio di produzione)

Webex Common Identity

Servizi APNS e FCM

Your NPS Server

HTTPS

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

https://idbroker-eu.webex.com

Qualsiasi indirizzo IP*

443

Provisioning utenti tramite adattatore provisioning BroadWorks

BroadWorks COME

HTTPS

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

(dove * potrebbe essere qualsiasi lettera. L'URL di provisioning esatto è disponibile nel modello creato in Partner Hub)

443

† questi intervalli contengono gli host per il proxy NPS, ma non è possibile fornire gli indirizzi esatti. Gli intervalli possono anche contenere host non correlati a Webex per BroadWorks. Si consiglia di configurare il firewall in modo da consentire il traffico verso il proxy NPS nome di dominio completo, al contrario, per assicurarsi che l'uscita sia solo verso gli host esposti per il proxy NPS.

* APNS e FCM non dispongono di una serie fissa di indirizzi IP.

Regole di ingresso USA

(Nella rete)

Scopo

Origine

Protocol

Destinazione

Porta di destinazione

WebexCloud

CTI/Autorizzazione/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

Cti

Your XSP

TCP/TLS 8012

TLS 443

Webex Teams Client App   

Xsi/DMS

Any

HTTPS

Your XSP

443

Webex Teams VoIP ENDPOINT SIP

Any

SIP

Il controller SBC

TCP configurato da SP

Regole di uscita USA

(Fuori rete)

Scopo

Origine

Protocol

Destinazione

Porta di destinazione

Provisioning utenti tramite API

Server dell'applicazione

HTTPS

webexapis.com

443

Notifiche push proxy (servizio di produzione)

Your NPS Server

HTTPS

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

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

443

Webex Common Identity

Your NPS Server

HTTPS

https://idbroker.webex.com

443

Servizi APNS e FCM

Your NPS Server

HTTPS

Qualsiasi indirizzo IP*

443

Provisioning utente tramite adattatore di provisioning BWKS

BroadWorks COME

HTTPS

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

(dove * potrebbe essere qualsiasi lettera. L'URL di provisioning esatto è disponibile nel modello creato in Partner Hub)

443

† questi intervalli contengono gli host per il proxy NPS, ma non è possibile fornire gli indirizzi esatti. Gli intervalli possono anche contenere host non correlati a Webex per BroadWorks. Si consiglia di configurare il firewall in modo da consentire il traffico verso il proxy NPS nome di dominio completo, al contrario, per assicurarsi che l'uscita sia solo verso gli host esposti per il proxy NPS.

* APNS e FCM non dispongono di una serie fissa di indirizzi IP.

Configurazione DNS

Webex per client BroadWorks deve essere in grado di individuare i server BroadWorks XSP per l'autenticazione, l'autorizzazione, il controllo delle chiamate e la gestione dei dispositivi.

Il cloud Webex deve essere in grado di individuare i server BroadWorks XSP per la connessione alle interfacce Xsi e al servizio di autenticazione.

È possibile che sia necessario registrare più voci DNS se si dispone di server XSP diversi per scopi diversi.


Si consiglia vivamente di configurare SRV record per risolvere i XSP utilizzati con Webex per BroadWorks. L'uso solo dei record A/AAAA provoca un traffico interno non necessario tra gli XSP, riducendo le prestazioni.

Come Cisco Webex cloud rileva gli indirizzi XSP

Cisco Webex Cloud eseguirà una ricerca A/AAA DNS del nome host XSP configurato e si connette all'indirizzo IP restituito. Si potrebbe trattarsi di un elemento edge di bilanciamento del carico o del server XSP stesso. Se vengono restituiti più indirizzi IP, verrà selezionata la voce iniziale nell'elenco.

Gli esempi 2 e 3 seguenti acquisiscono i record A/AAAA mappando rispettivamente uno e più indirizzi IP.

In uno scenario a più indirizzi IP, si consiglia di configurare le voci DNS in modo che ruotano in modo round robin, per distribuire le connessioni client da Webex.

Modalità di individuazione degli indirizzi XSP da parte dei client

Il client tenta di individuare i nodi XSP utilizzando il seguente flusso DNS:

  1. Il client recupera inizialmente gli URL Xsi-Actions/Xsi-Events dal cloud Cisco Webex (inserito durante la creazione del cluster di chiamata BroadWorks associato). Il nome host/dominio Xsi viene analizzato dall'URL e il client esegue SRV ricerca nel modo seguente:

    1. Il client esegue una SRV ricerca dei _xsi-client._tcp.<xsi domain="">

      (Vedere l'esempio seguente 1)

    2. Se la ricerca SRV ricerca restituisce uno o più obiettivi:

      Il client esegue una ricerca di A/AAAA per tali destinazioni e memorizza nella cache gli indirizzi IP restituiti.

      Il client si connette alla porta SRV su uno degli indirizzi IP restituiti. Sceglie un indirizzo in base alla priorità SRV, quindi viene eccesso (o a caso, se tutti sono uguali).

    3. Se la ricerca SRV ricerca non restituisce eventuali obiettivi:

      Il client esegue una ricerca A/AAAA del parametro radice Xsi, quindi tenta di connettersi all'indirizzo IP restituito. Si potrebbe trattarsi di un elemento edge di bilanciamento del carico o del server XSP stesso.

      (Vedere i seguenti esempi 2 e 3)

  2. (Opzionale) Successivamente è possibile fornire dettagli XSI-Actions/XSI-Events personalizzati nella configurazione del dispositivo per il client Webex Teams, utilizzando i seguenti tag:

    
    <protocols>
        <xsi>
            <paths>
                <root>%XSI_ROOT_WXT%</root>             <actions>%XSI_ACTIONS_PATH_WXT%</actions>             <events>%XSI_EVENTS_PATH_WXT%</events>
            </paths>
        </xsi>
    </protocols>
    1. Questi parametri di configurazione hanno la precedenza su qualsiasi configurazione nel cluster BroadWorks in Control Hub.

    2. Se esistono, il client verrà confrontato con l'indirizzo XSI originale ricevuto tramite la configurazione del cluster BroadWorks.

    3. Se vengono rilevate eventuali differenze, il client inizializza nuovamente la connettività XSI Actions/ XSI Events. La prima operazione consiste nell'eseguire lo stesso processo di ricerca DNS elencato al punto 1, utilizzando il parametro %XSI_ROOT_WXT% dal file di configurazione.


      Creare i record delle SRV corrispondenti se si utilizza questo tag per modificare le interfacce Xsi.

Record DNS di esempio

Tabella 1. Esempio 1: Record DNS SRV per rilevamento client di più server XSP internet

Tipo di record

Registra

Destinazione

Scopo

SRV

_xsi-client._tcp.your-xsp.example.com.

xsp01.example.com

Rilevamento client dell'interfaccia Xsi

SRV

_xsi-client._tcp.your-xsp.example.com.

xsp02.example.com

Rilevamento client dell'interfaccia Xsi

A

xsp01.example.com.

198.51.100.48

Ricerca di IP XSP

A

xsp02.example.com.

198.51.100.49

Ricerca di IP XSP

Tabella 2. Esempio 2: Record DNS A per rilevamento pool di server XSP con servizio di bilanciamento del carico

Tipo di record

Nome

Destinazione

Scopo

A

your-xsp.example.com.

198.51.100.50

Ricerca dell'IP servizio di bilanciamento del carico Edge

Tabella 3. Esempio 3: Record DNS A per rilevamento pool di server XSP bilanciato Round-Robin

Tipo di record

Nome

Destinazione

Scopo

A

your-xsp.example.com.

198.51.100.48

Ricerca di IP XSP

A

your-xsp.example.com.

198.51.100.49

Ricerca di IP XSP

Consigli DNS per nodi XSP

  • È necessario utilizzare un singolo record A/AAAA:

    • se occorre risolvere un proxy inverso di bilanciamento del carico nei server XSP

  • È necessario utilizzare record A/AAAA round robin:

    •  se si dispone di più server XSP di interfaccia Internet

  • Utilizzare rilevamento servizio DNS se:

    • È necessaria la ricerca nella rubrica in ambienti con più XSP.

    • Dispone di integrazioni preesistnti che richiedono la SRV rilevamento.

    • Si dispone di configurazioni univoche in cui i record A/AAAA standard non sono sufficienti.