Grazie per il feedback.

Questo articolo è destinato al team di supporto tecnico dell'organizzazione del fornitore di servizi che fornisce assistenza a se stesso e ai propri clienti. Dovrebbero avere familiarità con la risoluzione dei problemi generali, la lettura dei registri e la gestione dei casi degli abbonati.

Questo articolo è diviso in tre sezioni principali:

• Risorse: fornisce un elenco di strumenti, materiale di lettura, registri e contatti di cui potrebbe aver bisogno.
• Processi: descrive alcune delle azioni che può intraprendere per risolvere il problema di un cliente.
• Problemi specifici: classifica ed elenca i problemi noti, come individuarli e come potenzialmente risolverli.

File di registro utili

Elenco di lettura

• Webex per Cisco BroadWorks Partner Knowledge Portal
• Guida alla configurazione della piattaforma XSP (R23)
• Guida alla gestione del software BroadWorks (R23)
• Guida alla configurazione della gestione dei dispositivi Cisco BroadWorks (R23)
• Guida all'amministrazione dell'interfaccia a riga di comando Broadworks Xsp
• Descrizione della funzionalità del token di autenticazione a lungo termine Release 23.0
• Guida all'integrazione dell'autenticazione SAML, R23
• Guida alle opzioni di supporto SSL di Cisco BroadWorks
• Descrizione della funzionalità di supporto Cisco CI
• Notification Push Server (descrizione della funzionalità)
• Supporto per le notifiche push per le chiamate Descrizione della funzionalità Release 22.0
• Metodo di procedura per la migrazione di Connect (Android) a Firebase
• Cisco BroadWorks Archiviazione dei token del dispositivo per le notifiche push Descrizione della funzionalità Release 22.0
• Cisco Broadworks System Capacity Planner (foglio di calcolo)
• Guida al dimensionamento della piattaforma Cisco BroadWorks
• Guida alla progettazione dei sistemi Cisco Broadworks
• Documento sui requisiti di supporto per l'autenticazione CI versione 1.0 MR-7136

Problemi e limitazioni noti

L'articolo Problemi e limitazioni noti contiene informazioni aggiornate sui problemi noti che abbiamo identificato nella soluzione Webex per BroadWorks.

Connettore di manutenzione

Il servizio Webex Serviceability aumenta la velocità con cui il personale di assistenza tecnica di Cisco può diagnosticare i problemi con l'infrastruttura. Automatizza le attività di ricerca, recupero e archiviazione dei registri diagnostici e delle informazioni in un caso SR. Il servizio attiva anche l'analisi sulla base delle firme diagnostiche in modo che il TAC possa identificare e risolvere in modo più efficiente i problemi con le apparecchiature locali.

Per dettagli su come distribuire il Serviceability Connector, vedere la Deployment Guide for Serviceability Connector. Cisco Webex

Inasprimento di un problema

Dopo aver seguito alcune linee guida per la risoluzione dei problemi, dovrebbe avere un'idea ragionevole della radice del problema.

Procedura

1. Raccolga quante più informazioni possibile dai sistemi relativi al problema.
2. Contatti il team appropriato di Cisco per aprire un caso.

Quali informazioni sui clienti raccogliere

Se ritiene di dover aprire un caso o aggravare un problema, raccolga le seguenti informazioni durante la risoluzione dei problemi con l'utente:

• Identificatore utente: indirizzo email CI o UUID utente (questo è l'identificatore Webex, ma se ottiene anche l'identificatore BroadWorks dell'utente, lo includa nei dettagli del caso).
• Identificatore dell'organizzazione.
• Periodo di tempo approssimativo durante il quale si è verificato il problema.
• Piattaforma e versione client.
• Inviare o raccogliere i log dal cliente.
• Registra l'ID di tracciamento se mostrato sul cliente.

Controlli i dati dell'utente nell'Help Desk

Gli amministratori partner con privilegi di amministratore dell'Help Desk (base o avanzato) possono utilizzare questa procedura per controllare i dettagli degli utenti utilizzando la visualizzazione Help Desk.

Procedura

1. Accedi all'Help Desk.
2. Cerca e poi clicca sull'utente. Si apre la schermata di riepilogo utente.
3. Faccia clic sul nome utente per visualizzare la configurazione utente dettagliata. Le informazioni utili in questa visualizzazione includono l'UUID dell'utente, il cluster di identità comune (CI), il cluster di app Webex, il comportamento di chiamata, il GUID dell'account BroadWorks
4. Faccia clic su Copia se desidera utilizzare queste informazioni in un altro strumento o allegarle a un case Cisco.

Visualizza l'organizzazione dei clienti nell'Help Desk

Gli amministratori partner con privilegi di amministratore dell'Help Desk (base o avanzato) possono utilizzare questa procedura per visualizzare i dettagli dell'organizzazione del cliente nella visualizzazione Help Desk.

Procedura

1. Accedi all'Help Desk.
2. Cerca e poi clicca sul nome dell'organizzazione del cliente.
3. Scorra verso il basso fino a visualizzare Customer Portal View e fare clic su View CustomerName per visualizzare una visualizzazione di sola lettura dell'organizzazione del cliente, inclusi utenti e configurazione.

Recupera i log degli utenti da Partner Hub

Quando si risolvono i problemi dei client desktop e mobili, è importante che i partner (e il TAC) siano in grado di visualizzare i registri dei clienti.

Procedura

1. Chieda all'utente di inviare i log. Per assistenza, vedere: App Webex | Segnalare un problema.
2. Chieda all'utente di esportare l'ambiente di chiamata e inviarle il file ced.dat.
3. Ottenga i log dei clienti da Partner Hub o dall'Help Desk.

   Opzione Partner Hub:

   1. Accedi a Partner Hub e trovi l'organizzazione clienti dell'utente.
   2. Seleziona Risoluzione dei problemi.
   3. Seleziona Registri.
   4. Cerca l'utente (tramite e-mail).
   5. Visualizza e scarica i log dei clienti come file zip.

   Opzione Help Desk:

   1. Accedi all'Help Desk.
   2. Cerca l'organizzazione.
   3. Faccia clic sull'organizzazione (apre la schermata di riepilogo).
   4. Scorra verso il basso per fare clic su Visualizza cliente.
   5. Seleziona Risoluzione dei problemi.
   6. Seleziona Registri.
   7. Cerca l'utente (tramite e-mail).
   8. Visualizza e scarica i log dei clienti come file zip.

Come trovare la versione client

Procedura

1. Condividi questo link con l'utente: https://help.webex.com/njpf8r5
2. Chieda all'utente di inviarle il numero di versione.

Controllo del cliente per il servizio di chiamata

Procedura

1. Accedere al client Webex.
2. Verifichi che l'icona delle Opzioni di chiamata (un ricevitore con un ingranaggio sopra) sia presente nella barra laterale. Se l'icona non è presente, l'utente potrebbe non essere ancora abilitato al servizio di chiamata in Control Hub.
3. Aprire il menu Impostazioni/Preferenze e andare alla sezione Servizi telefonici. Dovrebbe vedere lo stato della sessione SSO. Ha effettuato l'accesso. (Se viene visualizzato un servizio telefonico diverso, ad esempioWebex Calling, l'utente non utilizza Webex per Cisco BroadWorks.)

   Questa verifica significa:

   • Il cliente ha attraversato con successo i microservizi Webex richiesti.
   • L'utente si è autenticato con successo.
   • Al cliente viene rilasciato un token web JSON di lunga durata dal suo sistema BroadWorks.
   • Il cliente ha recuperato il profilo del suo dispositivo e si è registrato a BroadWorks.

Ottenere registri o feedback dei clienti

• Vedere la sezione Risorse per trovare registri client specifici sui client desktop Webex o chiedere agli utenti di inviare registri. Per assistenza, vedere: App Webex | Segnalare un problema.
• Chieda agli utenti dei client mobili di inviare i log, poi potrà ottenerli tramite Partner Hub o Help Desk.
  L'invio dei log è silenzioso. Tuttavia, se un utente invia un feedback, lo invia al team di sviluppo dell'app Webex. Si assicuri di registrare il numero di feedback dell'utente se desidera contattare Cisco. Ad esempio:

  

Ottenere dati sull'ambiente di chiamata

I registri dei clienti Webex sono fortemente oscurati per rimuovere le informazioni di identificazione personale. Dovrebbe esportare i dati dell'ambiente di chiamata dal client nella stessa sessione in cui nota il problema.

Procedura

1. Sul cliente faccia clic su Aiuto > Health Checker.
2. Seleziona Reimposta database. Ciò attiva un ripristino completo del client e carica la schermata di accesso dell'app Webex.

Verifichi che Webex si registri a BroadWorks

L'app Webex controlla le seguenti informazioni per determinare se registrarsi a BroadWorks:

• Diritto dell'utente a Broadworks-Connector.
• Comportamento di chiamata per organizzazione e utente.

Controllare il comportamento di chiamata e l'autorizzazione del connettore di un utente

1. Accedi all'Help Desk con le sue credenziali di amministratore partner.
2. Cerca l'utente.
3. Faccia clic sull'utente e controlli la voce Comportamento di chiamata. Dovrebbe essere «Calling in Webex».

   

4. Faccia clic sul nome utente per aprire la schermata Dettagli utente.
5. Scorra verso il basso per individuare la sezione dei diritti e verificare che Broadworks-Connector sia incluso

   

   Un utente Webex per Cisco BroadWorks non dovrebbe avere l'autorizzazione bc-sp-standard se intende utilizzare Webex per Cisco BroadWorks. Questo è il diritto per «Webex Calling(Broadcloud)», che è l'app Webex che chiama tramite un servizio di chiamata cloud gestito da Cisco.

Controlli il comportamento di chiamata dell'organizzazione

1. Accedi all'Help Desk con le sue credenziali di amministratore partner.
2. Cerca l'organizzazione.
3. Faccia clic sull'organizzazione e controlli la voce Comportamento di chiamata. Dovrebbe essere «Calling in Webex».

Analizza PSLog per i problemi di provisioning degli utenti

Utilizza il PSLog dell'Application Server per visualizzare la richiesta HTTP POST al provisioning bridge e la risposta di Webex. In un caso funzionante, la risposta è 200 OK e dopo pochi minuti può vedere che l'utente - e la nuova organizzazione del cliente se è il primo utente - è stata creata in Webex. Può verificarlo cercando nell'Help Desk l'indirizzo email che vede nel POST.

Prima che Lei cominci

Raccogli un PSLog dall'Application Server durante un tentativo di provisioning a flusso continuo con un utente di test.

Procedura

1. Innanzitutto, controlli il codice di risposta HTTP:
   • Qualsiasi cosa diversa da 200 OK è un errore di provisioning da parte dell'utente.
   • 200 OK potrebbe comunque indicare un errore se qualcosa sul profilo dell'abbonato non funziona nei servizi Webex a monte del bridge di provisioning.
   • 400 può contenere un nodo messaggio nella risposta. Il provisioning bridge non è riuscito a elaborare qualcosa nel SubscriberProfile. Potrebbe esserci qualcosa di sbagliato nei dati dell'abbonato o un'incompatibilità con un'impostazione nel modello.
   • 401 significa che le credenziali di provisioning inserite nell'AS non corrispondono a quelle inserite nel modello in Partner Hub.
   • 403 potrebbe indicare qualcosa di non configurato correttamente sull'Application Server. Controlli la destinazione della richiesta. Non dovrebbe essere un indirizzo IP, dovrebbe essere l'URL del provisioning bridge che può vedere nel suo modello in Partner Hub.
   • 409 indica un conflitto tra il SubscriberProfile fornito e i dati Webex esistenti. Potrebbe esserci un utente esistente con quell'indirizzo email. Controlli il messaggio nella risposta.
2. Può anche controllare l'HTTP POST originale per eventuali valori sospetti che potrebbero causare il fallimento del provisioning. Il POST contiene una struttura XML SubscriberProfile . All'interno di questo, i nodi utili da controllare sono:
   • bwuserid: Lo usi per trovare il profilo dell'abbonato se deve modificarlo in BroadWorks.
   • gruppo: Se il modello è in «modalità fornitore di servizi», è in minuscolo e diventa il nome dell'organizzazione clienti che vede in Partner Hub.
   • ServiceProvider: Se il modello è in «modalità Enterprise», è in minuscolo e diventa il nome dell'organizzazione clienti che vede in Partner Hub.
   • Numero di telefono principale: deve esistere. Il provisioning fallisce senza di esso.
   • email: diventa l'ID utente in Webex. Deve essere valido e unico per Webex, altrimenti il provisioning non riesce.

     Ignori la sezione dei servizi: è creata da AS e accettata ma non utilizzata da Webex.

Analizza i log XSP per risolvere i problemi di accesso degli abbonati

Questo flusso descrive la modalità di autenticazione BroadWorks. Può vedere la modalità di autenticazione sul modello BroadWorks, in Partner Hub. Vedere Configurare i modelli per i clienti in https://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 esegue l'autenticazione BroadWorks nell'app Webex. Inoltre, la connessione tra Webex e XSP è protetta da MTLS.

La discussione che segue spiega cosa può aspettarsi di vedere esaminando i log per un accesso riuscito.

L'utente interagisce con il cliente, il cliente interagisce con i servizi Webex:

• L'utente fornisce il proprio indirizzo e-mail all'app Webex (1 nel diagramma).
• CI sa reindirizzare questo utente per inserire la propria password BroadWorks (tramite UAP) (2 nel diagramma).
• Il proxy IDP invia una richiesta di accesso al profilo all'interfaccia Xsi sull'XSP.

Nel tomcat access_log:

• Cerchi la richiesta GET per il profilo dell'abbonato, da Webex verso l'interfaccia Xsi-Actions (2.1 nel diagramma). Ha l'ID utente Webex. Ad esempio:

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

Nel registro XSIActionsLog:

• Cerca la richiesta GET del profilo da Webex (2.1 nel diagramma). Ha l'ID utente Webex. Ad esempio:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Le intestazioni includono l'autorizzazione: Basic e user-agent: BroadworkSteamsClient

• L'XSP esegue quindi l'autenticazione OCI-P Basic con BroadWorks (AuthenticationVerifyRequest e AuthenticationVerifyResponse, come qualsiasi altra applicazione che esegue l'autenticazione di base tramite Xsi) e anche UserGetRequest e ServiceProviderGetRequest per raccogliere le informazioni sull' abbonato.
• La risposta Xsi a Webex contiene un blocco di profilo XML contenente l'ID utente (BroadWorks) e altri dettagli (2.2 nel diagramma).

Interazioni tra clienti e servizi Webex:

• Il proxy IDP corrisponde al profilo utente ricevuto da BroadWorks e invia l'asserzione SAML al client (2.3 nel diagramma).
• Il cliente scambia l'asserzione SAML con un token CI (3 nel diagramma).
• Il cliente verifica che l'utente che ha effettuato l'accesso abbia l'autorizzazione Broadworks-Connector (4 nel diagramma). Può verificare i diritti degli utenti nell'Help Desk.
• Il cliente utilizza il token CI per richiedere un JSON Web Token (JWT) dal proxy IDP (5 nel diagramma).
• Il proxy IDP convalida il token CI presso CI.
• Il proxy IDP richiede JWT dal servizio di autenticazione.

Nel registro di AuthenticationService:

• Cerca la richiesta di token da Webex (5.2 nel diagramma), ad esempio: GET /AuthService/Token con l'intestazione http_bw_userid e altre.
• L'XSP esegue OCI-P UserGetLoginInfoRequest, per convalidare che l'ID utente fornito corrisponda a un utente BroadWorks (5.3 nel diagramma). AuthService ha stabilito un rapporto di fiducia con Webex in virtù della connessione MTLS, quindi può emettere LLT.
• Cerchi la risposta (5.4 nel diagramma) di LongLivedTokenManager - Token generated, oggetto: bwksUserId@example.com, issuer: BroadWorks... e statusCode=200 che può associare alla richiesta originale utilizzando l'intestazione trackingid: CLIENT...

Nel registro XSIActionsLog:

• Il cliente è in grado di presentare il token di lunga durata nell'interfaccia Xsi-Actions per ottenere il profilo del suo dispositivo (6 nel diagramma). Ad esempio: GET /com.broadsoft.xsi-actions/v2.0/user/BWKSUserID %40example.com/profile/device Con l'autorizzazione delle intestazioni: token al portatore e user-agent: WebexTeams (variant/versione)
• L'interfaccia Xsi-Actions invia il token all'authservice (configurato per essere sull'interfaccia di loopback) Ad esempio: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token che può correlare con l'intestazione trackingid: CLIENT... nell'intestazione GET e l'intestazione X-BROADSOFT-CORRELATION-ID: CLIENT... nel POST.

Nel registro di AuthenticationService:

• La ricezione del POST da Xsi (loopback)

• A StatusCode=200 torna a Xsi

• E una risposta di convalida del token, con un blocco JSON «token» nel corpo.

• Correlato utilizzando il trackingid: CLIENTE...

Nel registro XSIActionsLog:

• Dopo aver ricevuto 200 OK da authservice, che ha convalidato il token del cliente, l'applicazione Xsi-Actions ora invia una richiesta OCI-P per UserPrimary e SCADeviceGetListRequest
• Riceve OCI-P UserPrimary e SCADeviceGetListResponse contenente la struttura XML AccessDeviceTable.
• La risposta OCI-P è codificata come risposta Xsi al client, inclusa la struttura XML AccessDevices, che ha i DeviceTypes. Ad esempio: Business Communicator — PC e gli URL in cui il cliente può recuperare i file di configurazione del dispositivo.

Il cliente continua normalmente:

• Seleziona una voce del dispositivo e interagisce con il DMS per ottenere il profilo del dispositivo (6 nel diagramma).
• Registri a BroadWorks tramite SBC recuperati in configurazione da DMS (7 nel diagramma).

Problemi con il Partner Hub

1. L'amministratore non può vedere le organizzazioni dei clienti

In qualità di amministratore della sua organizzazione partner in Webex, dovrebbe avere il ruolo di amministratore completo. Questo ruolo viene utilizzato per gestire la sua organizzazione partner, inclusa l'assegnazione di privilegi amministrativi a Lei e ad altri. Per gestire le organizzazioni dei clienti, deve concedere a sé stesso (o ad altre persone) il ruolo di Amministratore completo delle vendite o il ruolo di Amministratore delle vendite. Per i dettagli, vedere Assegnare i ruoli degli account dell'organizzazione in Control Hub.

Problemi di provisioning da parte degli utenti

1. Errori IM&P integrati per imprese/clienti specifici

Se ha un mix di aziende che utilizzano diversi servizi di collaborazione cloud, ad esempio UC-One SaaS e Webex per Cisco BroadWorks, potrebbe aver scelto di modificare l'adattatore di provisioning per azienda.

Per verificare cosa è configurato per Integrated IM&P (impostazione predefinita per le aziende, a meno che non esista un'impostazione più specifica), esegua as_CLI/interface/messaging> get. Per i parametri di provisioning di un'azienda specifica, apra l'azienda e acceda a Servizi > IM&P integrato.

Verifichi che la configurazione IM&P integrata per quell'azienda corrisponda esattamente a quella mostrata nel modello cliente in Partner Hub. Le seguenti impostazioni devono corrispondere o il provisioning non riesce per tutti gli utenti dell'azienda:

2. Errori IM&P integrati per utenti specifici

Questo vale se utilizza il provisioning flowthrough e presuppone che il provisioning funzioni per alcuni o la maggior parte degli utenti (quindi può escludere un problema di configurazione). Se riscontra errori IM&P integrati in BroadWorks, ad esempio «[Errore 18215] Errore di provisioning con il server di messaggistica» e «[Errore 18211] Errore di comunicazione con il server di messaggistica», dovrebbe esaminare le seguenti potenziali cause:

• L'indirizzo email dell'utente potrebbe già esistere CI. Cerca l'utente nell'Help Desk per verificare se il suo indirizzo email è già presente. Questo non è necessariamente conclusivo, perché l'utente può esistere in un'organizzazione i cui dati non Le è consentito vedere nell'Help Desk.
• L'utente si è iscritto in modo indipendente a Webex, prima di ricevere il servizio IM&P integrato. In questo caso, un'opzione è chiedere all'utente di eliminare i propri account gratuiti che possono entrare a far parte dell'organizzazione clienti che sta fornendo. Le istruzioni sono disponibili all'indirizzo https://help.webex.com/5m4i4y
• L'utente non ha un numero di telefono principale assegnato al proprio profilo (tutti gli abbonati Webex per Cisco BroadWorks devono avere un ID principale). Vedi l'argomento sull'analisi di PSLog di AS.

3. Errori di provisioning da parte degli utenti in risposta al provisioning bridge

Se gli utenti non compaiono in Control Hub, entro pochi minuti dall'assegnazione di Integrated IM&P, dia un'occhiata ai codici di risposta del servizio di provisioning bridge. Esegui un PSLog per esaminare i codici di risposta HTTP.

200 OK

Una risposta 200 OK non significa che l'utente abbia ricevuto correttamente il provisioning. Significa che il servizio di provisioning ha ricevuto la richiesta e ha inviato con successo la corrispondente richiesta di creazione utente ai servizi upstream. La transazione di provisioning è asincrona per progettazione. Il servizio risponde 200 OK perché il processo di creazione dell'utente può richiedere diversi minuti e, per motivi di prestazioni, non vogliamo ricevere più richieste per creare lo stesso utente. Tuttavia, se alla fine l'utente non compare nell'organizzazione cliente dopo una risposta di 200 OK, potrebbe indicare che la creazione dell'utente non è riuscita nei servizi Webex a monte del servizio di provisioning. Deve aggravare un errore di provisioning con una risposta di 200 OK.

400 Richiesta errata

Controlli la risposta HTTP che dovrebbe contenere maggiori dettagli sui potenziali problemi che potrebbero causare questa risposta da parte del servizio di provisioning. Alcuni esempi del nodo:

• «Non posso fidarmi delle email di BroadWorks con API di provisioning legacy». L'indirizzo email associato alla richiesta di provisioning utente non riuscita non è valido o è stato digitato in modo errato, ma nel modello ha affermato che gli indirizzi email possono essere considerati attendibili. Controlli i profili degli utenti in BroadWorks, in particolare l'ID email.
• L'organizzazione del cliente non è presente nel database e inoltre il flag per la creazione di una nuova organizzazione non è abilitato.» Questa richiesta di provisioning non riuscita dovrebbe creare una nuova organizzazione clienti in Webex, ma il suo modello è configurato per impedire la creazione di nuove organizzazioni clienti. Se desidera consentire nuove organizzazioni, per i domini di posta elettronica che non corrispondono ai clienti esistenti in Webex, può riconfigurare il suo modello in Partner Hub e ripetere il test della richiesta di provisioning. Tuttavia, se non si aspetta che venga creata una nuova organizzazione per questo utente, forse l'indirizzo email è stato digitato male (in particolare la parte del dominio). Controlli l'ID email dell'utente in BroadWorks.

403 Proibito

La richiesta di provisioning non può avere esito positivo finché Lei non corregge la configurazione. In questo caso dovrà esaminare la richiesta e la risposta. Ad esempio, se vede un indirizzo IP come destinazione della richiesta di provisioning, anziché l'URL del bridge di provisioning appropriato per la sua organizzazione (vedere gli argomenti sulla configurazione del firewall nella Guida alla soluzione), potrebbe indicare che al suo Application Server manca una patch richiesta (ap373197).

Verifichi che tutte le patch richieste siano applicate all'Application Server e che Lei abbia completato la relativa configurazione per un corretto provisioning del flowthrough.

409 Conflitto

La richiesta di provisioning non può procedere perché esiste un utente esistente in Webex che corrisponde all'indirizzo email nella richiesta.

4. Utente già iscritto a CI

Estrarre l'email dell'abbonato dalla richiesta HTTP POST e cercarla nell'Help Desk. Potrebbe non vedere l'utente se non è autorizzato, ma potrebbe anche vedere che l'utente fa parte di un'organizzazione «libera», ad es. «Consumatore». Può chiedere a questo utente di eliminare il suo account gratuito oppure può utilizzare un indirizzo email diverso per fornirlo. Vedere https://help.webex.com/ndta402.

Problemi di accesso dell'utente

1. Il portale di attivazione degli utenti non si carica

Il normale flusso di accesso a Webex per Cisco BroadWorks include un portale di attivazione degli utenti in cui gli utenti inseriscono le proprie password. A volte questo portale non si carica dopo che l'utente ha fornito il proprio indirizzo email nella schermata di accesso dell'app Webex. Questo problema può essere causato dal lato cliente o dal lato del servizio. Dal lato client, in genere è causato dal fatto che il browser nativo del cliente è in qualche modo incompatibile con il servizio.

2. Single Sign-On non riuscito

• In BroadWorks, verificare che all'utente siano stati assegnati i tipi di dispositivo per l'app Webex (vedere la sezione Profili dei dispositivi nella sezione Prepara il tuo ambiente della Guida alla soluzione).
• Verifichi che l'utente stia utilizzando la password corretta. Se il modello utilizzato per fornire l'organizzazione clienti dell'utente (in Partner Hub) è configurato per l'autenticazione BroadWorks, l'utente deve inserire la propria password «Web Access» di BroadWorks. L' utente potrebbe dover inserire il proprio ID utente BroadWorks anche se il suo indirizzo email non è configurato come ID utente alternativo. Si assicuri che l'utente abbia inserito correttamente i caratteri maiuscoli e minuscoli.

Problemi di configurazione e registrazione delle chiamate

Dopo che un utente ha ricevuto il provisioning in Webex e ha effettuato correttamente l'accesso all'app Webex, l'app viene registrata su BroadWorks. Di seguito sono riportati la sequenza di registrazione prevista e i conseguenti segni di una registrazione corretta (come si vede dall'app Webex):

1. Sequenza di registrazione prevista

1. Il cliente chiama XSI per ottenere un token di gestione del dispositivo e l'URL del DMS.
2. Il cliente richiede il profilo del suo dispositivo al DMS presentando il token del passaggio 1.
3. Il cliente legge il profilo del dispositivo e recupera le credenziali SIP, gli indirizzi e le porte.
4. Il cliente invia un REGISTRO SIP a SBC utilizzando le informazioni del passaggio 3.
5. SBC invia il SIP REGISTER all'AS (SBC può eseguire una ricerca nel NS per individuare un AS se SBC non conosce già l'utente SIP.).

2. Segni attesi di una corretta registrazione del cliente

L'icona delle opzioni di chiamata viene visualizzata nell'interfaccia Webex.

Nella scheda Servizi telefonici dell'app Webex (ad esempio Impostazioni > Servizi telefonici su Windows, Preferenze > Servizi telefonici su Mac), il messaggio «Sessione SSO: ha effettuato l'accesso» indica che l'app è stata registrata correttamente (in questo caso a BroadWorks).

3. Il cliente non ha l'icona di chiamata

Il più delle volte ciò significa che l'utente non dispone della licenza/dei diritti corretti.

La registrazione non è andata a buon fine. Esistono diversi motivi per cui un client dell'app Webex non riesce a registrarsi con BroadWorks:

4. Più servizi di chiamata in fase di test con gli stessi clienti

Questo problema noto può essere causato dal fatto che il cliente passa da un call-end all'altro. È molto probabile che si verifichi durante le prove di diversi servizi di chiamata offerti tramite (gli stessi) client dell'app Webex. Può reimpostare il database dei clienti (link) per risolvere questo problema.

5. Configurazione errata del servizio di autenticazione

Controlli gli XSP che ospitano il servizio di autenticazione con la Guida alla soluzione (vedere Configurare i servizi sul suo Webex per Cisco BroadWorks XSP). Nello specifico:

• Le chiavi RSA (che Lei genera su un XSP) vengono copiate su tutti gli XSP
• L'URL del servizio di autenticazione è stato fornito al contenitore web su tutti gli XSP e inserito correttamente nel cluster in Partner Hub
• L'autenticazione esterna tramite certificati è configurata:

  XSP_CLI/System/Communication Utility/Impostazioni predefinite/Autenticazione esterna/Autenticazione del certificato > GET

  allowUserApp = false

  allowClientApp = true

• Quando si utilizza MTLS, deve caricare il certificato client Webex sugli XSP (può ottenere il certificato da Partner Hub, nella pagina delle impostazioni BroadWorks).

6. Configurazione errata dei tag BroadWorks

Verifichi di aver configurato i tag BroadWorks richiesti per l'app Webex. Fare riferimento alla Guida alla configurazione di Webex per Cisco BroadWorks per informazioni sui tag di configurazione. Si assicuri che non vi siano conflitti o valori errati. In particolare, il tag %SBC_ADDRESS_WXT% dovrebbe essere l'SBC verso il suo registrar SIP per i client dell'app Webex.

7. Il client desktop disconnette i servizi telefonici dopo una connessione SSO riuscita

Questo problema può essere causato dallo stesso utente che accede a più clienti sullo stesso tipo di piattaforma. Ad esempio, se un utente accede correttamente all'app Webex su Windows e quindi accede all'app Webex su un altro computer Windows, c'è solo una sessione SSO attiva su uno dei computer. Questo è di progettazione. Se ha assolutamente bisogno di risolvere questo problema, può configurare BroadWorks in modo che abbia più istanze dello stesso tipo di dispositivo, ma devono avere indirizzi SIP univoci. Questa configurazione non rientra nell'ambito di Webex per Cisco BroadWorks.

8. Dispositivo desktop non predisposto per l'utente

Questa firma è visibile nel registro del cliente:

[0x70000476b000] BroadworksConfigDownloader.cpp:106 <Error>

onAccessDeviceListSucceeded:bwc:scf: configDownload: il profilo del dispositivo 'Business Communicator - PC' non è stato trovato.

9. Le chiamate mobili in entrata squillano una volta o non si può rispondere

Le chiamate in entrata verso Webex mobile squillano solo una volta, altrimenti l'utente non può rispondere alla chiamata in entrata. Altri endpoint dello stesso utente potrebbero continuare a squillare.

Come identificarsi?

Nei registri del client mobile Webex, cerca il codice di errore XSI 101002 nel flusso delle chiamate push. Ad esempio:

Codice di risposta: 400

<callID>handlePushCallInfoFailure:BWC:Internal: Push call: stato xsi per CallID: codice di errore xsi: 101002

<callID>ClosePushCallWithReason:BWC:Internal: Prova a chiudere la chiamata push con id =, reason = callAbandoned

Causa: il codice di errore 101002 può indicare che nella risposta LocateUser viene restituito l'Application Server (AS) errato. Questo può accadere quando l'utente è migrato a un sistema operativo secondario.

Controlli consigliati:

Dall'ADP o XSP in cui è distribuito Push, esegui LocateUser per l'utente interessato:

<FQDN or IP address of NS Server>curl 'http: //:80/servlet/locateUser? <BW userID @domain >url=&returnCompatibleXSP=true&callprequest=vero'

Esempio: curl 'http://1.1.1.1:80/servlet/LocateUser? url= 9721112222@gmail.com &returnCompatibleXSP=true&callprequest=true'

Risoluzione: se LocateUser restituisce l'AS secondario per l'utente, esegua lo script MigrateUserToDefaultNode.pl sul server NS primario per migrare gli utenti all'Application Server primario per il cluster.

Accedere al server NS tramite SSH, andare alla directory /usr/local/broadworks/bw_base/bin ed eseguire: MigrateUserToDefaultNode.pl <hostingNE>

Esempio: MigrateUserToDefaultNode.pl bwas1

Per ottenere il valore HostingNE, esegui: NS_CLI/System/Device/HostingNE> get

Lo script controlla innanzitutto se riesce a trovare il NE di hosting fornito come argomento. Dopo aver verificato che il NE di hosting è valido, aggiorna il DN, l'estensione e l'URL al nodo predefinito per quel NE di hosting.

Esegui lo script in un periodo di basso traffico, quando possibile. Tuttavia, è generalmente accettabile eseguire lo script in qualsiasi momento, se necessario per ripristinare il servizio per gli utenti interessati.

Lo script non può essere eseguito per un solo utente. Migra tutti gli utenti elencati nell'output di LocateUser. Se non riesce a eseguire lo script, elimini e ricostruisca l'utente interessato in BroadWorks in modo che l'utente venga ricostruito sull'AS corretto.

Qualsiasi messaggio SIP dal dispositivo utente all'AS secondario può causare la migrazione dell'utente. Gli utenti in genere tornano all'AS primario dopo l'intervallo predefinito di 15 minuti, a meno che le richieste in arrivo non continuino a raggiungere l'AS secondario. Ad esempio, se l'SBC non riesce a connettersi all'AS1 e ricorre all'AS secondario, gli utenti interessati possono passare all'AS secondario. A seconda dell'implementazione, un singolo gruppo o utente può rimanere bloccato sull'AS secondario se l'SBC continua ad avere problemi a raggiungere l'AS primario.

Per ulteriori informazioni, consulti i seguenti documenti:

• Sezioni 3.4.5 Capacità di rollback degli utenti dell'Application Server e 5.4.5 Rollback automatico nella Guida alla ridondanza di Cisco BroadWorks

• Descrizione della funzionalità Cisco BroadWorks ASR Enhancements

9. Servizi telefonici disconnessi

Se i servizi telefonici risultano disconnessi dopo che l'utente ha effettuato l'accesso all'app Webex, o se i servizi telefonici si disconnettono mentre l'utente utilizza il client, controlla il tipo di client e il flusso di registrazione.

Per i client Windows e Mac, l'app Webex si registra per SIP e mantiene una registrazione SIP attiva mentre l'utente è connesso.

Controlli quanto segue:

1. Verifichi che config-wxt.xml sia stato scaricato correttamente.

Nei log dei client, cerca ConfigDownload.

Un download riuscito mostra:

configDownload - completato con successo

Se i registri mostrano il seguente errore, controlli i log di AuthService per eventuali errori relativi ai token:

configDownload - non riuscito con codice di errore: 1511

2. Verificare che sia stato trovato il profilo del dispositivo Webex.

Nei log del cliente, confermi che il dispositivo di accesso sia stato trovato e che used_value sia 1. Se used_value è 0, controlli se Primary Line è abilitato o disabilitato e verifichi il valore del tag. Per maggiori dettagli, vedere la sezione 6.1.44 Profilo primario nella Guida alla configurazione di Webex for BroadWorks.

Esempi di voci di registro:

:BWC:SCF: ConfigDownload - dispositivo di accesso trovato

:BWC:SCF: configDownload - dispositivo di accesso: deviceType=Business Communicator - PC, deviceLevel=Group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Aspetto di chiamata condivisa

:BWC:SCF: configDownload - dispositivo di accesso: deviceType=Connect - Mobile, deviceLevel=Group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Aspetto di chiamata condivisa

:BWC:SCF: configDownload - dispositivo di accesso: deviceType=Connect - Tablet, deviceLevel=Group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Aspetto di chiamata condivisa

3. Verificare la presenza di errori DNS durante la risoluzione dell'indirizzo proxy SIP.

Per dettagli sul rilevamento del proxy SIP, vedere la sezione 6.1.6 Dynamic SIP Proxy Discovery nella Webex for BroadWorks Configuration Guide.

Un proxy discovery riuscito mostra:

La scoperta del proxy è terminata, ha ottenuto <number>risultati

4. Verifichi se la registrazione SIP non va a buon fine.

Se i registri mostrano mRegistration: TCPTimeout o Reason: SIP; cause=200; text="last=TCP-Timeout», il client Webex non è in grado di stabilire una connessione TCP di basso livello all'SBC. La registrazione SIP non viene completata quando si verifica questo errore. Verifichi se il TCP è bloccato sulla rete dell'utente o se l'SBC sta rifiutando la connessione TCP.

Se la richiesta SIP REGISTER viene rifiutata o non riceve risposta, cerchi REGISTER sip nei log e verifica che venga restituito SIP/2.0 200 OK. Se non viene restituito, controlli se la rete dell'utente sta bloccando il SIP o se l'SBC sta rifiutando la richiesta.

In BroadWorks Admin, vai su Utente > Utilità > Registrazioni e verifica che sia presente una registrazione SIP valida per il client Webex.

Per i client mobili Android e iOS, l'app Webex non si registra per SIP finché non viene effettuata o ricevuta una chiamata. La registrazione viene rimossa al termine della chiamata. I clienti mobili si registrano per le notifiche push.

Per i clienti mobili, controlli quanto segue:

1. Verifichi che config-wxt.xml venga scaricato correttamente e che il profilo del dispositivo sia stato trovato, come descritto per i client Windows e Mac.

2. Verifichi che la registrazione push abbia esito positivo.

Nei log di Webex, cerchi lo stato della registrazione push:

onPushRegistrationStateChanged: :Stato di registrazione push modificato, state=Unregistered

onPushRegistrationStateChanged: :Stato di registrazione push modificato, state=Registrato

In BroadWorks Admin, vai su Utente > Utilità > Registrazioni con notifiche push e verifica che sia presente una registrazione push valida per il client Webex.

Problemi con le impostazioni delle chiamate webview

1. Il pulsante/link Self Care non viene visualizzato nell'app Webex

Un altro sintomo di questo problema è quando viene mostrato il pulsante/link, ma facendo clic su di esso si apre un browser esterno.

• Verifichi che il modello di configurazione client richiesto sia distribuito e che i tag CSW siano impostati correttamente . (Vedere la sezione Call Settings Webview nella Guida alla soluzione Webex per Cisco BroadWorks).
• Verificare che l'app Webex sia registrata per le chiamate in BroadWorks.
• Verificare che l'app Webex sia una versione recente che supporti il CSWV.

2. Pagina vuota o errore dopo aver fatto clic sul pulsante/link Self Care

In genere, questo comportamento nell'app Webex indica un problema di configurazione o distribuzione con l'applicazione CSWV su BroadWorks XSP. Raccogli i dettagli per ulteriori indagini, inclusi i log CSWV, i log degli accessi, il repository config-wxt.xml e il file modello, e poi sollevi un caso.

Problemi relativi alla rivendicazione del dominio

Gli errori di registrazione degli utenti possono verificarsi a causa di errori commessi nella richiesta dei domini. Prima di richiedere qualsiasi dominio, si assicuri di aver compreso quanto segue:

• I fornitori di servizi non devono rivendicare i domini delle organizzazioni clienti che gestiscono. Dovrebbero rivendicare solo i domini degli utenti che fanno parte dell'organizzazione interna del fornitore di servizi. La rivendicazione del dominio degli utenti di un'organizzazione separata (anche gestita dal fornitore di servizi) può comportare errori di registrazione per gli utenti dell'organizzazione cliente poiché le richieste di autenticazione degli utenti vengono indirizzate tramite il fornitore di servizi anziché l'organizzazione del cliente.
• Se due organizzazioni clienti (Società A e Società B) condividono lo stesso dominio e la Società A ha rivendicato il dominio, la registrazione per gli utenti della Società B potrebbe non riuscire perché le richieste di autenticazione degli utenti vengono inoltrate all'organizzazione che ha il dominio rivendicato (Società A).

  Se rivendica un dominio per errore e deve rimuovere un reclamo, faccia riferimento all'articolo Gestire i suoi domini Webex.

Codici di errore per l'utente finale

La tabella seguente riporta i codici di errore dell'utente finale che possono essere visualizzati nel portale di attivazione degli utenti client.

Codici di errore per Directory Sync

I seguenti codici di errore si applicano a Directory Sync.