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?

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

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

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.