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 adattatori per provisioning aziendali, 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 Enterprises (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?

(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.:

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

  Il CN del certificato interno deve essere bwcticlient.webex.com.

  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.

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.

Come le app Webex individuano gli indirizzi XSP

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 di_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.

      Ogni record A/AAAA deve mappare un indirizzo IP. Questa configurazione è obbligatoria poiché i heartbeat XSI-event del client devono passare allo stesso indirizzo IP utilizzato per stabilire il canale dell'evento. Se si associa il nome A/AAAA a più di un indirizzo IP, il client alla fine invia heartbeat a un indirizzo in cui non ha stabilito un canale per l'evento. Ciò determina l'errore del canale e, inoltre, un traffico significativamente più interno che incide sulle prestazioni del cluster XSP.

      Il client si connette a uno dei destinazioni (e pertanto, il relativo record A/AAAA con un singolo indirizzo IP) in base alla priorità SRV, quindi avere lo stesso peso (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.

      Come indicato sopra, il record A/AAAA deve risolversi in un indirizzo IP per gli stessi motivi.

      (Vedere l'esempio seguente 2)

2. (Opzionale) In un secondo tempo, è possibile fornire dettagli XSI-Actions/XSI-Events personalizzati nella configurazione del dispositivo per l'app Webex, 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, questa volta richiedendo una ricerca del valore in%XSI_ROOT_WXT%parametro del relativo file di configurazione.

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

Record DNS di esempio

Se si associa il record DNS A/AAAA a più indirizzi IP (per fornire connessioni ridondanti per i microservizi, come mostrato nella tabella precedente), non è necessario utilizzare lo stesso record A/AAAA dell'indirizzo XSI del client. In tal caso, è possibile configurare un record SRV per i client (come mostrato nella Tabella 1 precedente), ma il SRV deve risolversi in un set diverso di record A/AAAA. Come indicato in precedenza, tali record A/AAAA devono essere mappati a ciascun indirizzo IP.

Consigli DNS per nodi XSP

• Utilizzare un singolo record A/AAAA se occorre risolvere un proxy inverso di bilanciamento del carico nei server XSP.

• Utilizzare i record A/AAAA round-robin solo se:

  • si dispone di più server XSP con connessione Internet che si desidera trovare ai microservizi Webex.

  • non si utilizzano i record A/AAAA round-robin per risolvere l'indirizzo XSI del client.

• 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.