Webex pentru procesele de depanare BroadWorks

Escaladarea unei probleme

După ce ați urmat unele dintre instrucțiunile de depanare, ar trebui să aveți o idee rezonabilă despre locul în care problema este înrădăcinată.

1

Colectați cât mai multe informații de la sistemele legate de problemă

2

Contactați echipa corespunzătoare de la Cisco pentru a deschide un caz (consultați secțiunea Contacte)

Ce informații despre client să colecteze

Dacă credeți că trebuie să deschideți un caz sau să escaladați o problemă, colectați următoarele informații în timp ce depanați cu utilizatorul:

  • Identificator utilizator: Adresă de e-mail CI sau UUID utilizator (acesta este identificatorul Webex, dar dacă obțineți și identificatorul BroadWorks al utilizatorului, acest lucru vă va ajuta)

  • Identificator organizație

  • Intervalul de timp aproximativ în care a fost experimentată problema

  • Platforma și versiunea clientului

  • Trimiterea sau colectarea jurnalelor de la client

  • Înregistrați ID-ul de urmărire dacă este afișat pe client

Verificarea detaliilor utilizatorului în Biroul de asistență

1

Conectați-vă la https://admin.webex.com/helpdesk.

2

Căutați, apoi faceți clic pe utilizator. Aceasta deschide ecranul rezumat al utilizatorului.

3

Faceți clic pe numele de utilizator pentru a vedea configurația detaliată a utilizatorului.

Informațiile utile din această vizualizare includ UUID-ul utilizatorului, clusterul de identitate comună (CI), clusterul de aplicații Webex, Comportamentul la apelare, GUID-ul contului BroadWorks.

4

Faceți clic pe Copiere dacă trebuie să utilizați aceste informații într-un alt instrument sau să le atașați la un caz Cisco.

Vizualizare organizație client în Biroul de asistență

1

Conectați-vă la https://admin.webex.com/helpdesk.

2

Căutați, apoi faceți clic pe numele organizației client.

3

Derulați în jos până când vedeți Vizualizare portal clienți și faceți clic pe Vizualizare Nume Client pentru a vedea o vizualizare doar în citire a org-ului Client , inclusiv utilizatorii și configurația.

Regăsire jurnale utilizator din Hub partener

Atunci când depanați problemele cu clienții desktop și mobil, este important ca partenerii (și TAC) să poată vizualiza jurnalele clienților.

1

Solicitați utilizatorului să trimită jurnale.

2

Solicitați utilizatorului să exporte mediul de apelare pentru a vă trimite fișierul ced.dat.

3

Obțineți jurnalele clienților de la Hubul partener sau de la Biroul de asistență (a se vedea mai jos).

Opțiunea Hub partener:

  1. Conectați-vă la Hubul de parteneri și găsiți Organizația clienților utilizatorului.

  2. Selectați Depanare.

  3. Selectați Jurnale.

  4. Căutați utilizatorul (prin e-mail).

  5. Vizualizați și descărcați jurnalele clientului ca fișier zip.

Opțiunea Help Desk:

  1. Conectați-vă la Biroul de asistență.

  2. Căutați organizația.

  3. Faceți clic pe organizație (deschide ecranul rezumat).

  4. Defilați în jos pentru a face clic pe Vizualizare client.

  5. Selectare Depanare.

  6. Selectare jurnale.

  7. Căutați utilizatorul (prin e-mail).

  8. Vizualizați și descărcați jurnalele clientului ca fișier zip.

se găsește versiunea clientului

1

Partajați acest link cu utilizatorul: https://help.webex.com/njpf8r5.

2

Solicitați utilizatorului să vă trimită numărul versiunii.

Serviciu de verificare client pentru apelare

1

Conectați-vă la clientul Webex.

2

Verificați dacă pictograma Opțiuni de apelare (un telefon cu un echipament deasupra acestuia) este prezentă pe bara laterală.

Dacă pictograma nu este prezentă, este posibil ca utilizatorul să nu fie încă activat pentru serviciul de apelare din Control Hub.

3

Deschideți meniul Setări/Preferințe și accesați secțiunea Servicii telefonice. Ar trebui să vedeți starea sesiunii SSO La care v-ați conectat.

(Dacă un alt serviciu telefonic, cum ar fi Webex Calling, este afișat, utilizatorul nu utilizează Webex pentru BroadWorks.)

Această verificare înseamnă:

  • Clientul a traversat cu succes microservicii Webex necesare.
  • Utilizatorul s-a autentificat cu succes.
  • Clientului i s-a emis un token web JSON de lungă durată de către sistemul BroadWorks.
  • Clientul și-a recuperat profilul dispozitivului și s-a înregistrat la BroadWorks.

Obțineți jurnale de clienți sau feedback

  • Consultați secțiunea Resurse pentru a găsi anumite jurnale de clienți pe clienții desktop Webex sau solicitați utilizatorilor să trimită jurnale.

  • Cereți utilizatorilor de clienți mobili să trimită jurnale, apoi le puteți obține prin hub-ul partener sau biroul de asistență.


Trimiterea jurnalelor este silențioasă. Cu toate acestea, dacă un utilizator trimite feedback, acesta merge la echipa Webex App devops. Asigurați-vă că înregistrați numărul de feedback al utilizatorului dacă doriți să urmăriți Cisco. De exemplu:

Obțineți date de mediu de apelare

Jurnalele de clienți Webex sunt puternic redactate pentru a elimina informațiile de identificare personală. Ar trebui să exportați datele mediului apelând de la client în aceeași sesiune în care observați problema.

1

În client, faceți clic pe imaginea de profil, apoi faceți clic pe Ajutor > Export date mediu apelare.

2

Salvați cedarea fișierului rezultat.dat pentru depanarea problemelor de apelare pentru acest utilizator.

Important: Deconectează sau repornește clientul șterge memoria cache internă. Dacă exportați ced.dat după aceea, datele exportate nu vor corespunde cu niciun jurnal care a fost trimis înainte de memoria cache.

Reinițializare bază de date Webex

1

Pe client faceți clic pe Ajutor > Verificator de sănătate.

2

Selectați Reinițializare bază de date.

Acest lucru declanșează o resetare completă a clientului și încarcă ecranul de conectare al aplicației Webex.

Verificați dacă Webex ar trebui să se înregistreze la BroadWorks

Aplicația Webex verifică următoarele informații pentru a determina dacă să vă înregistrați la BroadWorks:

  • Dreptul utilizatorului la conectorul broadworks

  • Apelarea comportamentului pentru organizație și utilizator

Verificați comportamentul de apelare al unui utilizator și dreptul la conector

  1. Conectați-vă la Help Desk (https://admin.webex.com/helpdesk) cu acreditările de administrator partenere.

  2. Căutați utilizatorul.

  3. Faceți clic pe utilizator și verificați intrarea Comportament apelare. Ar trebui să fie "Apelarea în Webex".

  4. Faceți clic pe numele de utilizator pentru a deschide ecranul Detalii utilizator.

  5. Defilați în jos pentru a localiza entitlements secțiune și verificați dacă broadworks-connector este inclusă.


    Un utilizator Webex pentru BroadWorks NU trebuie să aibă bc-sp-standard în cazul în care intenționează să utilizeze Webex pentru BroadWorks. Acesta este dreptul pentru "Webex Calling (Broadcloud)", care este aplicația Webex care apelează printr-un serviciu de apelare în cloud gestionat de Cisco.

Verificați comportamentul de apelare al organizației

  1. Conectați-vă la Help Desk (https://admin.webex.com/helpdesk) cu acreditările de administrator partenere.

  2. Căutați organizația.

  3. Faceți clic pe organizație și verificați intrarea Comportament apelare. Ar trebui să fie "Apelarea în Webex".

Analizați PSLog pentru problemele de asigurare a accesului utilizatorilor

Utilizați PSLog-ul serverului de aplicații pentru a vedea solicitarea HTTP POST la puntea de asigurare a accesului și răspunsul de la Webex.

Într-un caz de lucru corect, răspunsul este de 200 OK și după câteva minute puteți vedea că utilizatorul - și noul Client org dacă este primul utilizator - a fost creat în Webex.

Puteți verifica acest lucru căutând în Biroul de asistență adresa de e-mail pe care o vedeți în POST.

Înainte de a începe

Colectați un PSLog de pe serverul de aplicații în timpul unei încercări de asigurare a accesului prin flux cu un utilizator de test.

1

Primul lucru de verificat este codul de răspuns HTTP:

  • Orice altceva decât 200 OK este o eroare de asigurare a accesului de utilizator.

  • 200 OK ar putea indica în continuare o eroare dacă ceva despre profilul abonatului nu funcționează în serviciile Webex din amonte de podul de aprovizionare.

  • 400 poate conține o message nod în răspuns. Puntea de provizionare nu a putut procesa ceva în subscriberProfile. Este posibil să fie ceva în neregulă cu detaliile abonatului sau incompatibilitate cu o setare din șablon.

  • 401 înseamnă că acreditările de asigurare a accesului introduse în as nu se potrivesc cu cele introduse în șablon în Hubul partenerilor.

  • 403 ar putea indica ceva configurat greșit pe Application Server. Verificați ținta solicitării. nu ar trebui să fie o adresă IP, ar trebui să fie adresa URL a punții de asigurare a accesului pe care o puteți vedea în șablon în Hubul partenerilor.

  • 409 indică un conflict între subscriberProfile și datele Webex existente. Este posibil să existe un utilizator existent cu acea adresă de e-mail. Verificați message în răspuns.

2

De asemenea, puteți verifica postarea HTTP originală pentru orice valori suspecte care ar putea provoca eșecul provizionării.

POST conține o subscriberProfile Structură XML. În interiorul acesteia, noduri utile pentru a verifica sunt:

  • bwuserid: Utilizați acest lucru pentru a găsi profilul de abonat dacă trebuie să îl editați în BroadWorks.

  • group: Dacă șablonul este în "Modul furnizor de servicii", acesta este coborât și devine numele org-ului Client pe care îl vedeți în Hubul partener.

  • serviceProvider: Dacă șablonul este în "Modul întreprindere", acesta este coborât și devine numele org-ului Client pe care îl vedeți în Hubul partener.

  • primaryPhoneNumber: Trebuie să existe. Provizionarea eșuează fără ea.

  • email: Devine ID-ul de utilizator în Webex. Trebuie să fie valid și unic pentru Webex, altfel asigurarea accesului nu reușește.


 

Ignorați services strofă: este creat de AS și acceptat, dar nu utilizat de Webex.

Analizați jurnalele XSP pentru a depana conectarea abonaților

Acest flux descrie modul de autentificare BroadWorks. Puteți vedea modul de autentificare în șablonul BroadWorks, în Hub partener. Consultați Configurarea șabloanelor de client în https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Următoarea diagramă scară afișează interacțiunea dintre utilizator, client, servicii Webex și sistemul BroadWorks, atunci când utilizatorul face autentificare BroadWorks în aplicația Webex. De asemenea, conexiunea dintre Webex și XSP este asigurată de MTLS.

Discuția care urmează explică ceea ce vă puteți aștepta să vedeți atunci când investigați jurnalele pentru o conectare reușită.

Figura 1. Autentificare BroadWorks și configurare dispozitiv

Utilizatorul interacționează cu clientul, clientul interacționează cu serviciile Webex:

  • Utilizatorul furnizează adresa sa de e-mail aplicației Webex (1 în diagramă).

  • CI știe să redirecționeze acest utilizator pentru a introduce parola BroadWorks (prin UAP) (2 în diagramă).

  • Proxy-ul IDP trimite o solicitare de profil pentru interfața Xsi de pe XSP.

În access_log tomcat:

  • Căutați solicitarea GET pentru profilul de abonat, de la Webex la interfața Xsi-Actions (2.1 în diagramă). Are ID-ul de utilizator Webex. De exemplu,

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

În XsiActionsLog:

  • Căutați solicitarea GET de profil de la Webex (2.1 în diagramă). Are ID-ul de utilizator Webex. De exemplu,

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

    Anteturile includ authorization: Basic și user-agent: broadworksTeamsClient

  • XSP face apoi autentificarea de bază OCI-P împotriva BroadWorks (AuthenticationVerifyRequest și AuthenticationVerifyResponse, ca orice altă aplicație care face autentificare de bază prin Xsi) și, de asemenea, un UserGetRequest și ServiceProviderGetRequest pentru a colecta informațiile abonatului.

  • Răspunsul Xsi la Webex conține un XML Profile bloc care conține (BroadWorks) userId și alte detalii (2.2 în diagramă).

Interacțiuni cu serviciile client și Webex:

  • Proxy-ul IDP se potrivește profilului de utilizator primit de la BroadWorks și emite afirmația SAML către client (2,3 în diagramă)

  • Clientul schimbă afirmația SAML pentru un simbol CI (3 în diagramă)

  • Clientul verifică dacă utilizatorul conectat are dreptul de conector broadworks (4 în diagramă). Puteți verifica drepturile utilizatorilor în Help Desk)

  • Clientul utilizează simbolul CI pentru a solicita un simbol Web JSON (JWT) de la proxy IDP (5 în diagramă)

  • Proxy-ul IDP validează simbolul CI la CI

  • Proxy IDP solicită JWT de la serviciul de autentificare

În jurnalul de autentificareService:

  • Căutați solicitarea de simbol de la Webex (5,2 în diagramă), de exemplu:

    GET /authService/token

    care a http_bw_userid antet și altele.

  • XSP face OCI-P UserGetLoginInfoRequest, pentru a valida faptul că ID-ul de utilizator furnizat corespunde unui utilizator BroadWorks (5.3 în diagramă). AuthService a stabilit încrederea cu Webex în virtutea conexiunii mTLS, astfel încât poate emite LLT.

  • Căutați răspunsul (5,4 în diagramă) din LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

    și StatusCode=200 pe care le puteți asocia cu solicitarea inițială utilizând trackingid: CLIENT… Antet.

În XsiActionsLog:

  • Clientul este acum capabil să prezinte token-ul de lungă durată la interfața Xsi-Actions pentru a obține profilul dispozitivului (6 în diagramă). De exemplu:

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

    Cu anteturile authorization: Bearer token și user-agent: WebexTeams (variant/version)

  • Interfața Xsi-Actions POSTs token-ul la authservice (configurat pentru a fi pe interfața loopback) de exemplu: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    pe care le puteți corela cu trackingid: CLIENT… antetul din GET și X-BROADSOFT-CORRELATION-ID : CLIENT… antetul din POST.

În jurnalul de autentificareService:

  • Primirea postului de la Xsi (loopback)

  • A StatusCode=200 înapoi la Xsi

  • Și un răspuns de validare token, având o "token" Blocul JSON din corp.

  • Corelată utilizând trackingid: CLIENT…

În XsiActionsLog:

  • După ce a primit 200 OK de la authservice, care a validat simbolul clientului, aplicația Xsi-Actions trimite acum o solicitare OCI-P pentru UserPrimaryAndSCADeviceGetListRequest

  • Primește OCI-P UserPrimaryAndSCADeviceGetListResponse care conține accessDeviceTable Structură XML.

  • Răspunsul OCI-P este codificat ca răspuns Xsi la client, inclusiv AccessDevices structura XML, care are deviceTypes de exemplu, Business Communicator – PC și URL-urile unde clientul poate prelua fișierele de configurare a dispozitivului.

Clientul continuă ca de obicei:

  • Selectează o intrare de dispozitiv și interacționează cu DMS pentru a obține profilul dispozitivului (6 în diagramă)

  • Registre la BroadWorks prin SBC preluate în configurație de la DMS (7 în diagramă)