Processi di risoluzione dei problemi Webex for BroadWorks

Escalation di un problema

Dopo aver seguito alcune indicazioni sulla risoluzione dei problemi, si dovrebbe avere un'idea ragionevole di dove si verifica il problema.

1

Raccogliere il maggior numero di informazioni possibile dai sistemi correlati al problema
2

Contattare il team appropriato in Cisco per aprire un caso (vedere la sezione Contatti)

Quali informazioni del client raccogliere

Se si ritieni di aprire un caso o inoltrare un problema al supporto, raccogliere le seguenti informazioni durante la risoluzione dei problemi con l'utente:

  • IDENTIFICATIVO utente: Indirizzo e-mail CI o UUID utente (questo è l'identificativo Webex ma se si riceve anche l'identificativo BroadWorks dell'utente, che sarà di aiuto)

  • ID organizzazione

  • Periodo di tempo approssimativo durante il quale si è verificato il problema

  • Piattaforma e versione client

  • Invia o raccoglie i log dal client

  • Registra l'ID di verifica se visualizzato sul client

Controllo dei dettagli utente in help desk

1

Accedere a https://admin.webex.com/helpdesk.
2

Cercare e fare clic sull'utente. Viene visualizzata la schermata di riepilogo degli utenti.
3

Fare clic sulla nome utente per visualizzare la configurazione utente dettagliata.

Informazioni utili in questa visualizzazione includono l'UUID dell'utente, il cluster di identità comune (CI), il cluster dell'app Webex, il comportamento di chiamata, il GUID dell'account BroadWorks.
4

Fare clic su Copia se occorre utilizzare queste informazioni in un altro strumento o allegarlo a un caso Cisco.

Visualizza organizzazione cliente in help desk

1

Accedere a https://admin.webex.com/helpdesk.
2

Cercare e fare clic sul nome dell'organizzazione cliente.
3

Scorrere fino a visualizzare la vista del portale cliente e fare clic su Visualizza nome cliente per visualizzare una vista di sola lettura dell'organizzazione del cliente, inclusi utenti e configurazione.

Recupera log utenti da hub partner

Nella risoluzione dei problemi del client desktop e mobile, è importante che i partner (e TAC) siano in grado di visualizzare i registri dei client.

1

Richiedere all'utente di inviare i registri.
2

Richiedere all'utente di esportare l'ambiente di chiamata per inviare il file ced.dat.
3

Ottenere i registri client da Partner Hub o help desk (vedere di seguito).

Opzione Hub partner:

  1. Accedere all'hub del partner e individuare l'organizzazione cliente dell'utente.

  2. Selezionare Risoluzione dei problemi.

  3. Selezionare Log.

  4. Ricercare l'utente (per e-mail).

  5. Visualizzare e scaricare i log del client come file zip.

help desk opzione:

  1. Eseguire l'accesso help desk.

  2. Cercare l'organizzazione.

  3. Fare clic sull'organizzazione (viene visualizzata la schermata di riepilogo).

  4. Scorrere in basso per fare clic su View customer (Visualizza cliente).

  5. Selezionare Risoluzione deiproblemi.

  6. Selezionare Registri.

  7. Ricercare l'utente (per e-mail).

  8. Visualizzare e scaricare i log del client come file zip.

Come trovare la versione del client

1

Condividere questo collegamento con l'utente: https://help.webex.com/njpf8r5.
2

Richiedere all'utente di inviare il numero di versione.

Controllo client per servizio di chiamata

1

Accedere al client Webex.
2

Controllare che l'icona Opzioni di chiamata (un ricevitore con un ingranaggio sopra) sia presente sulla barra laterale.

Se l'icona non è presente, è possibile che l'utente non sia ancora abilitato per il servizio di chiamata in Control Hub.
3

Aprire il menu Impostazioni/Preferenze e andare alla sezione Servizi telefonici. Viene visualizzato lo stato SSO è stato eseguito l'accesso.

(Se un servizio telefonico diverso, come Webex Calling, viene visualizzato, l'utente non utilizza Webex per BroadWorks.

Ciò significa:

  • Il client ha attraversato correttamente i microservizi Webex richiesti.
  • L'utente è stato autenticato correttamente.
  • Il client è stato emesso un token Web JSON a lungo termine dal sistema BroadWorks.
  • Il client ha recuperato il profilo del dispositivo ed è registrato per BroadWorks.

Ottieni registri client feedback

  • Vedere la sezione Risorse per trovare log del client specifici sui client desktop Webex o chiedere agli utenti di inviare i registri.

  • Chiedere agli utenti dei client mobili di inviare i registri, in modo da poterli ottenere tramite l'hub del partner o l'help desk.

Invio dei registri invisibile all'utente. Tuttavia, se un utente invia un feedback, viene inviato all'Cisco Webex team devops dell'app. Accertarsi di registrare il numero del feedback dell'utente se si desidera eseguire il follow-up con Cisco. Ad esempio:

Ottieni dati ambiente di chiamata

I log del client Webex vengono riattivati pesantemente per rimuovere le informazioni di identificazione personale. È necessario esportare i dati dell'ambiente di chiamata dal client nella stessa sessione in cui si nota il problema.

1

Nel client, fare clic sul pulsante immagine profilo, quindi fare clic su Guida > Esportare i dati dell'ambiente di chiamata.
2

Salvare il file risultante ced.dat per risolvere i problemi di chiamata per questo utente.

Importante: La disconnessione o il riavvio del client cancella la cache interna. Se si esegue l'esportazione di ced.dat in seguito, i dati esportati non corrispondono ad eventuali registri inviati prima della cache.

Ripristina database Webex

1

Nel client, fare clic su Help > Health Checker(Controllo stato).
2

Selezionare Ripristina database.

In questo modo viene attivato un ripristino completo del client e viene caricata la schermata di accesso dell'app Webex.

Verificare che Webex debba registrarsi a BroadWorks

L'app Webex verifica le seguenti informazioni per determinare se eseguire l'iscrizione a BroadWorks:

  • Diritto utente per broadworks-connector

  • Funzionamento della chiamata per organizzazione e utente

Controllare il funzionamento delle chiamate e l'autorizzazione connector di un utente

  1. Accedere a help desk (https://admin.webex.com/helpdesk) con le credenziali dell'amministratore del partner.

  2. Ricercare l'utente.

  3. Fare clic sull'utente e selezionare la voce Funzionamento chiamata. Deve essere "Chiamata in Webex".

  4. Fare clic sulla nome utente per aprire la schermata Dettagli utente.

  5. Scorrere verso il basso per individuare la sezione diritti e verificare chebroadworks-connector sia incluso.

    Un utente Webex per BroadWorks NON deve disporre dell'autorizzazione standard bc-sp se intende utilizzare Webex per BroadWorks. Questo è il diritto per "Webex Calling (Broadcloud)" che chiama l'app Webex attraverso un servizio di chiamata cloud gestito da Cisco.

Controllare il funzionamento delle chiamate dell'organizzazione

  1. Accedere a help desk (https://admin.webex.com/helpdesk) con le credenziali dell'amministratore del partner.

  2. Cercare l'organizzazione.

  3. Fare clic sull'organizzazione e selezionare la voce Funzionamento chiamata. Deve essere "Chiamata in Webex".

Analizza PSLog per problemi di provisioning utenti

Utilizzare il registro PSLog del server applicazioni per visualizzare la richiesta HTTP POST al bridge di provisioning e la risposta da Webex.

In un caso funzionante corretto, la risposta è stata 200 OK e dopo alcuni minuti è possibile visualizzare l'utente, e la nuova organizzazione cliente, se primo utente, è stata creata in Webex.

È possibile verificare questa opzione ricercando help desk indirizzo e-mail visualizzato nel POST.

Operazioni preliminari

Raccoglie un registro PSLog dal server applicazioni durante un tentativo di provisioning flow con un utente di test.

1

La prima cosa da verificare è il codice di risposta HTTP:

  • Un errore di provisioning dell'utente è qualsiasi elemento diverso da 200 OK.

  • 200 OK potrebbe comunque indicare un errore se qualcosa sul profilo dell'abbonato non funziona nei servizi Webex upstream del bridge di provisioning.

  • 400 può contenere un nodo di messaggi nella risposta. Il bridge di provisioning non ha potuto elaborare qualcosa nel profilo dell'utente. Si potrebbe essere verificato un problema con i dettagli dell'abbonato o incompatibilità con un'impostazione nel modello.

  • 401 significa che le credenziali di provisioning inserite su AS non corrispondono a quelle inserite nel modello in Partner Hub.

  • 403 potrebbe indicare una configurazione errata sul server applicazioni. Controllare la destinazione della richiesta. non deve essere un indirizzo IP; dovrebbe essere l'URL del bridge di provisioning che è possibile visualizzare nel modello in Partner Hub.

  • 409 indica un conflitto tra il profilo dell'utente fornito e i dati Webex esistenti. Potrebbe essere presente un utente esistente con tale indirizzo e-mail. Controllare il messaggio nella risposta.
2

È anche possibile controllare il POST HTTP originale per qualsiasi valore sospettato che potrebbe causare errori di provisioning.

Il POST contiene una struttura XML subscriberProfile. All'interno di questa funzione, i nodi utili da verificare sono:

  • bwuserid: Utilizzare questa opzione per individuare il profilo dell'abbonato se occorre modificarlo in BroadWorks.

  • gruppo: Se il modello è in "modalità provider di servizi clienti", tale modello viene visualizzato in minuscolo e diventa il nome dell'organizzazione cliente visualizzata in Partner Hub.

  • serviceProvider: Se il modello è in "modalità Enterprise", questa viene minuscola e diventa il nome dell'organizzazione cliente visualizzata in Partner Hub.

  • numerophoneprimario: Deve esistere. Il provisioning non riesce.

  • email(e-mail): Diventa il ID utente in Webex. Deve essere valido e univoco per Webex, altrimenti il provisioning non riesce.


 

Ignora stanza servizi: viene creato da AS e accettato ma non utilizzato da Webex.

Analizzare i registri XSP per risolvere i problemi di accesso degli abbonati

Questo flusso descrive la modalità di autenticazione BroadWorks. È possibile visualizzare la modalità di autenticazione sul Modello BroadWorks, in Partner Hub. Vedere Configurazione dei modelli cliente inhttps://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Il seguente diagramma a scala mostra l'interazione tra utente, client, servizi Webex e sistema BroadWorks, quando l'utente sta effettuando l'autenticazione BroadWorks nell'app Webex. Inoltre, la connessione tra Webex e XSP è protetta da MTLS.

La discussione seguente descrive cosa ci si può aspettare quando si esegue la ricerca di un registro per un accesso corretto.

Figura 1. Autenticazione BroadWorks e configurazione dei dispositivi

L'utente interagisce con il client e il client interagisce con i servizi Webex:

  • L'utente fornisce l'indirizzo e-mail all'app Webex (1 in diagramma).

  • CI è in grado di reindirizzare questo utente per inserire la propria password BroadWorks (tramite UAP) (2 in diagramma).

  • Il proxy IDP invia una richiesta di richiesta di ottenere il profilo all'interfaccia Xsi su XSP.

Nel campo tomcat access_log:

  • Ricercare la richiesta GET per il profilo dell'abbonato, da Webex all'interfaccia Xsi-Actions (2.1 in diagramma). Dispone del ID utente Webex. Ad esempio.

    GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

Nel registro XsiActionsLog:

  • Ricercare il profilo RICHIESTA GET da Webex (2.1 in diagramma). Dispone del ID utente Webex. Ad esempio.

    GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

    Le intestazioni includono l'autorizzazione: Agente di base e utente: client broadworksTeamsClient

  • XSP quindi esegue l'autenticazione base OCI-P nei confronti di BroadWorks (AuthenticationVerifyRequest e AuthenticationVerifyResponse, come qualsiasi altra applicazione che effettua l'autenticazione di base tramite Xsi) e anche di UserGetRequest e ServiceProviderGetRequest per raccogliere le informazioni del sotto sottoscrittore.

  • La risposta Xsi a Webex contiene un blocco di profilo XML contenente l'ID utente (BroadWorks) e altri dettagli (2.2 in diagramma).

Interazioni tra client e servizi Webex:

  • Il proxy IDP corrisponde profilo utente ricevuto da BroadWorks e problemi dell'asserzione SAML al client (2.3 in diagramma)

  • Il client scambia l'asserzione SAML per un token CI (3 in diagramma)

  • Il client verifica che l'utente che ha eseguito l'accesso dispone dell'autorizzazione per broadworks-connector (4 in diagramma). È possibile controllare i diritti utente in help desk)

  • Il client utilizza il token CI per richiedere un token Web JSON (J VISIO) dal proxy IDP (5 nel diagramma)

  • Il proxy IDP convalida token CI su CI

  • Il proxy IDP richiede JNTASSI dal servizio di autenticazione

Nel log authenticationService:

  • Ricercare la richiesta di token da Webex (5.2 nel diagramma), ad esempio:

    GET /authService/token

    con intestazione http_bw_userid e altri nomi.

  • L'XSP fa in modo che OCI-P UserGetLoginInfoRequest , per verificare che l'ID utente fornito corrisponda a un utente BroadWorks (5.3 in diagramma). AuthService ha stabilito una relazione di trust con Webex in virtù della connessione mTLS, pertanto può emettere LLT.

  • Ricercare la risposta (5.4 nel diagramma) da LongLivedTokenManager - Token generato, oggetto: bwksUserId@example.com, emittente: BroadWorks ...

    e StatusCode=200 che è possibile associare alla richiesta originale utilizzando il parametro trackingid: CLIENT IN CORSO... Intestazione.

Nel registro XsiActionsLog:

  • Il client ora è in grado di presentare il token a lungo termine sull'interfaccia Xsi-Actions per ottenere il profilo del dispositivo (6 nel diagramma). Ad esempio.:

    GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device

    Con autorizzazione delle intestazioni: Token oratore e agente utente: WebexTeams(varianti/versioni)

  • L'interfaccia Xsi-Actions POSTs il token per il servizio di autenticazione (configurato per essere sull'interfaccia di loopback) ad esempio: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    che è possibile associare al trackingid: CLIENT IN CORSO... intestazione nell'intestazione GET e X-BROADSOFT-CORRELATION-ID : CLIENT...nell'intestazione POST.

Nel log authenticationService:

  • Ricezione di POST da Xsi (loopback)

  • Uno StatusCode=200 torna a Xsi

  • E una risposta di convalida token, con un blocco JSON "token" nel corpo.

  • Correlato mediante id verifica: Client...

Nel registro XsiActionsLog:

  • Dopo aver ricevuto 200 OK da authservice, che ha convalidato token del client, l'applicazione Xsi-Actions ora invia la richiesta OCI-P per UserPrimaryAndSCADeviceGetListRequest

  • Riceve userPrimaryAndSCADeviceGetListResponse contenente la struttura XML accessDeviceTable.

  • La risposta OCI-P viene codificata come risposta Xsi al client, inclusa la struttura XML AccessDevices, che dispone di deviceType, ad esempio, Business Communicator – PC e URL in cui il client può recuperare i file di configurazione del dispositivo.

Il client continua normalmente:

  • Seleziona la voce di un dispositivo e interagisce con il DMS per ottenere il profilo del dispositivo (6 in diagramma)

  • I registri per BroadWorks tramite SBC recuperati nella configurazione dal DMS (7 in diagramma)