- Preparazione dell'ambiente
- Punti decisione
- Architettura e infrastruttura
- Provisioning clienti e utenti
- Branding
- Modelli cliente
- Accordi con più partner
- Adattatore e modelli di provisioning
- Requisiti minimi
- Account
- Server nella rete e requisiti software
- Piattaforme client Teams
- Telefoni e accessori fisici
- Profili dispositivi
- Ordina certificati
- Requisiti di certificato per l'autenticazione TLS
- Requisiti del certificato TLS per il proxy con bridge TLS
- Requisiti certificato TLS per proxy passle TLS o XSP in DMZ
- Requisiti di certificato aggiuntivi per l'autenticazione TLS reciproca con AuthService
- Requisiti del certificato TLS reciproca per il proxy con bridge TLS
- Requisiti del certificato TLS reciproca per il proxy passizzato TLS o XSP in DMZ
- Ulteriori requisiti di certificato per l'autenticazione TLS reciproca su interfaccia CTI
- Preparazione della rete
- Mappa connessione
- Configurazione del firewall
- Regole di ingresso EMEA
- Regole di uscita EMEA
- Regole di ingresso USA
- Regole di uscita USA
- Configurazione DNS
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 |
|
|
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) .
Piattaforme client Teams
https://www.webex.com/downloads.html
PC/laptop Windows
PC Apple / laptop con MacOS
iOS (Apple Store)
Android (Play store)
Browser Web (https://teams.webex.com/)
Telefoni e accessori fisici
Telefoni IP Cisco:
Cisco IP Phone serie 6800 con firmware Multitform
Cisco IP Phone serie 7800 con firmware Multitform
Cisco IP Phone serie 8800 con firmware Multiplatform
Vedere https://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phones/multiplatform-firmware.html modelli e ulteriori informazioni.
I telefoni di terze parti sono supportati allo stesso modo delle altre integrazioni BroadWorks. Tuttavia, non dispongono ancora di contatti e integrazione di presenza con Webex per BroadWorks.
Adattatori
Adattatore telefono analogico a multipiattaforma Cisco ATA 191
Adattatore telefono analogico a multipiattaforma Cisco ATA 192 Multiplatform
Vedere https://www.cisco.com/c/en/us/products/unified-communications/ata-190-series-analog-telephone-adapters/index.html per modelli e ulteriori informazioni.
Cuffie
Cisco Headset serie 500
Vedere https://www.cisco.com/c/en/us/products/collaboration-endpoints/headset-500-series/index.html modelli e ulteriori informazioni.
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: File di configurazione: |
Webex Teams Desktop Template Da https://xchange.broadsoft.com/support/uc-one/communicator/software |
Tipo di profilo identità/dispositivo: Communicator Aziendale - PC DTAF: File di configurazione: |
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:
Andare a Impostazioni > chiamata BroadWorks.
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 >
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:

(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:
Requisiti di rete per Webex Teams (tutto eccetto le riunioni).
Come è possibile consentire Webex Meetings traffico sulla rete?(requisiti di rete delle riunioni).
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:
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:
Il client esegue una SRV ricerca dei
_xsi-client._tcp.<xsi domain="">
(Vedere l'esempio seguente 1)
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).
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)
(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>
Questi parametri di configurazione hanno la precedenza su qualsiasi configurazione nel cluster BroadWorks in Control Hub.
Se esistono, il client verrà confrontato con l'indirizzo XSI originale ricevuto tramite la configurazione del cluster BroadWorks.
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
Tipo di record |
Registra |
Destinazione |
Scopo |
SRV |
|
|
Rilevamento client dell'interfaccia Xsi |
SRV |
|
|
Rilevamento client dell'interfaccia Xsi |
A |
|
|
Ricerca di IP XSP |
A |
|
|
Ricerca di IP XSP |
Tipo di record |
Nome |
Destinazione |
Scopo |
A |
|
|
Ricerca dell'IP servizio di bilanciamento del carico Edge |
Tipo di record |
Nome |
Destinazione |
Scopo |
A |
|
|
Ricerca di IP XSP |
A |
|
|
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.