Webex til Fejlfindingsprocesser for BroadWorks

Eskalerer et problem

Efter du har fulgt nogle af fejlfindingsvejledningen, bør du have en rimelig idé om, hvor problemet er rooted.

1

Indsaml så mange oplysninger, som du kan, fra systemerne i forbindelse med problemet

2

Kontakt det relevante team hos Cisco for at åbne en sag (se afsnittet Kontakter)

Hvilke klientoplysninger skal indsamles

Hvis du mener, at du har brug for at åbne en sag eller eskalere et problem, skal du indsamle følgende oplysninger under fejlfinding med brugeren:

  • Brugeridentifikator: CI-e-mailadresse eller bruger UUID (dette er Webex-id, men hvis du også får brugerens BroadWorks-id, så hjælper det)

  • Organisationsidentifikator

  • Tilnærme tidsramme, hvor problemet blev oplevet

  • Klientplatform og -version

  • Send eller indsaml logfiler fra klienten

  • Optag sporings-id'et, hvis det vises på klienten

Kontroller brugeroplysninger i Help Desk

1

Log på https://admin.webex.com/helpdesk.

2

Søg efter , og klik på brugeren. Dette åbner brugeroversigtsskærmen.

3

Klik på brugernavn for at se den detaljerede brugerkonfiguration.

Nyttige oplysninger i denne visning omfatter brugerens UUID-klynge (Common Identity, CI), Webex-appklynge, opkaldsadfærd og GUID til BroadWorks-konto.

4

Klik Kopier, hvis du har brug for at bruge disse oplysninger i et andet værktøj, eller vedhæft dem til en Cisco-sag.

Vis kundeorganisation i Help Desk

1

Log på https://admin.webex.com/helpdesk.

2

Søg efter, og klik derefter på navnet på kundens organisation.

3

Rul ned, indtil du ser kundeportalvisning, og klik på Vis kundenavn for at se en skrivebeskyttet visning af kundeorganisationen – herunder brugere og konfiguration.

Hent brugerlogfiler fra Partner Hub

Når der skal fejlfindes problemer med desktop- og mobilklienter, er det vigtigt, at partnere (og TAC) kan se klientlogfilerne.

1

Bed brugeren om at sende logfiler.

2

Bed brugeren om at eksportere opkaldsmiljøet og sende dig ced.dat-filen.

3

Få klientlogfilerne fra Partner Hub eller Help Desk (se nedenfor).

Valgmuligheden Partner Hub:

  1. Log ind på Partner Hub, og find brugerens kundeorganisation.

  2. Vælg Fejlfinding.

  3. Vælg Logge.

  4. Søg efter brugeren (via e-mail).

  5. Se og download klientlogfilerne som en zip-fil.

Help Desk valgmulighed:

  1. Log ind på Help Desk.

  2. Søg efter organisationen.

  3. Klik på organisationen (åbner oversigtsskærmen).

  4. Rul ned for at klikke på Vis kunde.

  5. Vælg Fejlfinding.

  6. Vælg Logs.

  7. Søg efter brugeren (via e-mail).

  8. Se og download klientlogfilerne som en zip-fil.

Klientkontrol for opkaldstjeneste

1

Log ind på Webex-klienten.

2

Kontroller, at ikonet Opkaldsmuligheder (et håndsæt med et tandhjul over det) er til stede på sidebjælken.

Hvis ikonet ikke er til stede, er brugeren muligvis endnu ikke aktiveret for opkaldstjenesten i Control Hub.

3

Åbn menuen Indstillinger/Præferencer, og gå til afsnittet Telefontjenester. Du bør se statussen SSO session du er logget på.

(Hvis en anden telefontjeneste, f.eks. Webex-opkald, vises, bruger bruger ikke Webex til BroadWorks.)

Denne bekræftelse betyder:

  • Klienten har gennemført de nødvendige Webex-mikrotjenester.
  • Brugeren er blevet godkendt.
  • Klienten er blevet udstedt en langsigtet JSON-webtoken af dit BroadWorks-system.
  • Klienten har hentet sin enhedsprofil og er tilmeldt BroadWorks.

Få Klientlogger eller Feedback

  • Se afsnittet Ressourcer for at finde specifikke klientlogs på Webex-desktopklienter, eller bed brugere om at sende logfiler.

  • Bed brugere af mobilklienter om at sende logfiler, så kan du få dem via Partner Hub eller Help Desk.


Send logge er lydløs. Men hvis en bruger sender feedback, går det til Webex App devops-teamet. Sørg for at optage brugerens feedbacknummer, hvis du ønsker at følge op på Cisco. Eksempel:

Hent data for opkaldsmiljø

Webex-klientlogfiler er kraftigt redigeret for at fjerne personligt identificerbare oplysninger. Du skal eksportere data for opkaldsmiljø fra klienten i den samme session, når du bemærker problemet.

1

I klienten skal du klikke på profilbillede og derefter klikke på Hjælp > eksporter opkaldsmiljødata.

2

Gem den resulterende fil ced.dat til fejlfinding af opkaldsproblemer for denne bruger.

Vigtigt: Log ud fra, eller genstart klienten rydder den interne cache. Hvis du eksporterer ced.dat efter dette, svarer de eksporterede data ikke til nogen logfiler, der blev sendt før cachen.

Nulstil Webex-database

1

På klienten skal du klikke på > til Sundhedskontrol.

2

Vælg Nulstil database.

Dette udløser en fuld nulstilling af klienten og indlæser Login-skærmen i Webex-appen.

Bekræft, at Webex skal tilmelde sig BroadWorks

Webex-appen kontrollerer følgende oplysninger for at bestemme, om du vil tilmelde dig BroadWorks:

  • Brugerberettigelse til broadworks-connector

  • Opkaldsadfærd for organisation og bruger

Kontrollér en brugers opkaldsadfærd og konnektorberettigelse

  1. Log ind på Help Desk (https://admin.webex.com/helpdesk) med dine partneradministratorlegitimationsoplysninger.

  2. Søg efter brugeren.

  3. Klik på brugeren, og marker posten Opkaldsadfærd. Det bør være "Opkald i Webex".

  4. Klik på brugernavn for at åbne skærmen Brugeroplysninger.

  5. Rul ned for at finde entitlements afsnit, og verifiser, at broadworks-connector er inkluderet.


    En Webex til BroadWorks-bruger må IKKE have bc-sp-standard berettigelse, hvis de har til hensigt at bruge Webex til BroadWorks. Dette er berettigelse til "Webex-opkald (Broadcloud)", som er Webex-appen, der ringer via en Cisco-administreret opkaldstjeneste via Cloud.

Kontrollér organisationens opkaldsadfærd

  1. Log ind på Help Desk (https://admin.webex.com/helpdesk) med dine partneradministratorlegitimationsoplysninger.

  2. Søg efter organisationen.

  3. Klik på organisationen, og marker posten Opkaldsadfærd. Det bør være "Opkald i Webex".

Analyser PSLog for problemer med bruger klargøring

Brug applikationsserverens PSLog til at se HTTP POST-anmodningen til klargøringsbroen og svaret fra Webex.

I en korrekt arbejdssag er svaret 200 OK, og efter et par minutter kan du se brugeren - og ny kundeorganisation, hvis den er første bruger - er blevet oprettet i Webex.

Du kan bekræfte dette ved at Help Desk efter den e-mailadresse, du ser i POST.

Før du begynder

Indsaml en PSLog fra applikationsserveren under et flowthrmut-klargøringsforsøg med en testbruger.

1

Den første, der skal kontrolleres, er HTTP-responskoden:

  • Alt andet end 200 OK er en fejl i bruger klargøring.

  • 200 OK kan stadig angive en fejl, hvis noget om abonnentprofilen ikke virker i Webex-tjenesterne opstrøms for klargøringsbroen.

  • 400 kan indeholde et message knude i svaret. Klargøringsbroen kunne ikke behandle noget i subscriberProfile. Der kan være noget galt med abonnentoplysningerne eller inkompatibilitet med en indstilling i skabelonen.

  • 401 betyder, at klargøringsoplysningerne, der er indtastet på AS, ikke stemmer overens med dem, der er indtastet på skabelonen i Partner Hub.

  • 403 kunne angive noget forkert konfigureret på applikationsserveren. Kontroller anmodningens mål. det må ikke være en IP-adresse. Det bør være klargøringsbroens URL-adresse, som du kan se på din skabelon i Partner Hub.

  • 409 angiver en konflikt mellem de leverede subscriberProfile og eksisterende Webex-data. Der er muligvis en eksisterende bruger med denne e-mailadresse. Kontrollér message i svaret.

2

Du kan også kontrollere den oprindelige HTTP POST for enhver mistanke om værdier, der kan forårsage, at klargøring mislykkes.

POST indeholder en subscriberProfile XML-struktur. Indeni dette er nyttige knudepunkter at kontrollere:

  • bwuserid: Brug denne til at finde abonnentprofilen, hvis du har brug for at redigere den i BroadWorks.

  • group: Hvis skabelonen er i "Tjenesteudbyder-tilstand", sænkes denne og bliver navnet på den kundeorganisation, du ser i Partner Hub.

  • serviceProvider: Hvis skabelonen er i "Virksomhedstilstand", sænkes den og bliver navnet på den kundeorganisation, du ser i Partner Hub.

  • primaryPhoneNumber: Skal findes. Klargøring mislykkedes uden den.

  • email: Bliver den bruger-id i Webex. Skal være gyldig og unik for Webex. Ellers mislykkes klargøring.


 

Ignorer services Stanza: det er oprettet af AS og accepteret, men ikke brugt af Webex.

Analyser XSP-logfiler til fejlfinding af abonnentlog ind

Dette flow beskriver BroadWorks-godkendelsestilstand. Du kan se godkendelsestilstanden på BroadWorks-skabelonen i Partner Hub. Se Konfigurer dine kundeskabeloner i https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Følgende stigediagram viser interaktionen mellem brugeren, klienten, Webex-tjenesteydelser og BroadWorks-systemet, når brugeren udfører BroadWorks-godkendelse i Webex-appen. Desuden er forbindelsen mellem Webex og XSP sikret af MTLS.

Diskussionen, der følger, forklarer, hvad du kan forvente at se, når loggene undersøges for et vellykket login.

Figur 1. BroadWorks-godkendelse og enhedskonfiguration

Bruger interagerer med klient, klient interagerer med Webex-tjenester:

  • Brugeren leverer sin e-mailadresse til Webex-appen (1 i diagram).

  • CI ved, at du skal omdirigere denne bruger til at indtaste deres BroadWorks-adgangskode (via UAP) (2 i diagrammet).

  • IDP-proxyen indsender en get-profilanmodning til Xsi-grænsefladen på XSP'en.

I tomcat-access_log:

  • Se efter GET-anmodningen om abonnentprofilen fra Webex over for Xsi-Actions-grænsefladen (2.1 i diagram). Det har Webex-bruger-id. F.eks.

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

I XsiActionsLog:

  • Se efter profilens GET-anmodning fra Webex (2.1 i diagram). Det har Webex-bruger-id. F.eks.

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

    Sidehovederne inkluderer authorization: Basic og user-agent: broadworksTeamsClient

  • XSP udfører derefter OCI-P grundlæggende godkendelse mod BroadWorks (AuthenticationVerifyRequest og AuthenticationVerifyResponse, som enhver anden applikation foretager grundlæggende godkendelse via Xsi) og også en UserGetRequest og ServiceProviderGetRequest for at indsamle abonnentoplysninger.

  • Xsi-svaret på Webex indeholder en XML Profile bloker, der indeholder (BroadWorks) userId og andre oplysninger (2.2 i diagram).

Klient- og Webex-tjenesteydelsesinteraktioner:

  • IDP-proxy matches brugerprofil der er modtaget fra BroadWorks og problemer MED SAML-klient (2.3 i diagram)

  • Klient udvekslinger SAML-påstand for et CI-token (3 i diagram)

  • Klienten kontrollerer, at den bruger, der er logget ind, har berettigelse til broadworks-connector (4 i diagram). Du kan kontrollere brugerberettigelser i Help Desk)

  • Klient bruger CI-token til at anmode om et JSON-webtoken (JWT) fra IDP-proxy (5 i diagram)

  • IDP-proxy validerer CI-token på CI

  • IDP proxy anmoder JWT fra godkendelsestjeneste

I bekræftelsesserviceloggen:

  • Se efter tokenanmodningen fra Webex (5.2 i diagrammet), f.eks.:

    GET /authService/token

    som har http_bw_userid sidehoved og andre.

  • XSP gør OCI-P UserGetLoginInfoRequest for at validere, at det ngivne bruger-id svarer til en BroadWorks-bruger (5.3 i diagram). AuthService har etableret tillid til Webex ved hjælp af mTLS-forbindelsen, så kan udstede LLT.

  • Se efter svaret (5.4 i diagrammet) fra LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

    og StatusCode=200 som du kan tilknytte den oprindelige anmodning ved hjælp af trackingid: CLIENT… Header.

I XsiActionsLog:

  • Klienten er nu i stand til at præsentere den længe eksisterende token på Xsi-Actions-grænsefladen for at få sin enhedsprofil (6 i diagram). F.eks.:

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

    Med sidehovederne authorization: Bearer token og user-agent: WebexTeams (variant/version)

  • Xsi-Actions-grænsefladeN GIVER TOKEN til sikkerhedstjenesten (konfigureret til at være på loopback-grænsefladen), f.eks.: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    som du kan korrelere med trackingid: CLIENT… sidehoved i fanen GET og X-BROADSOFT-CORRELATION-ID : CLIENT… sidehoved i fanen POST.

I bekræftelsesserviceloggen:

  • Modtagelse af POST fra Xsi (loopback)

  • A StatusCode=200 tilbage til Xsi

  • Og et tokenbekræftelsessvar, der har et "token" JSON-blokering i brødteksten.

  • Forbundet ved hjælp af trackingid: CLIENT…

I XsiActionsLog:

  • Efter at have modtaget 200 OK fra authservice, som validerede klientens token, sender Xsi-Actions-applikationen nu OCI-P-anmodning om UserPrimaryAndSCADeviceGetListRequest

  • Modtager OCI-P UserPrimaryAndSCADeviceGetListResponse med accessDeviceTable XML-struktur.

  • OCI-P-svaret er kodet som Xsi-svar til klient, inklusive AccessDevices XML-strukturen, som har deviceTypes F.eks. Business Communicator – PC og URL-adresserne, hvor klienten kan hente enhedskonfigurationsfilerne.

Klient fortsætter som normalt:

  • Vælger en enhedsindtastning og interagerer med DMS for at få enhedsprofil (6 i diagram)

  • Registrer til BroadWorks via SBC hentet i konfiguration fra DMS (7 i diagram)