Webex för BroadWorks felsökningsprocesser

Eskalera ett problem

När du har följt några av felsökningsvägledningen bör du ha en skälig idé om var problemet ligger.

1

Samla in så mycket information du kan från systemen som är relaterade till problemet
2

Kontakta teamet på Cisco för att öppna ett ärende (se avsnittet Kontakter)

Vilken klientinformation att samla in

Om du tror att du måste öppna ett ärende eller eskalera ett problem samlar du in följande information när du felsöker med användaren:

  • Användaridentifierare: CI-e-postadress eller användar-UUID (det här är Webex-identifieraren, men om du även får användarens BroadWorks-identifierare som hjälper)

  • Organisationsidentifierare

  • Ungefärlig tidsram under vilken problemet upplevdes

  • Klientplattform och version

  • Skicka eller samla in loggar från klienten

  • Spela in spårnings-ID:t om det visas i klienten

Kontrollera användaruppgifterna i Help Desk

1

Logga in på https://admin.webex.com/helpdesk.
2

Sök efter och klicka sedan på användaren. Då öppnas skärmbilden användarsammanfattning.
3

Klicka på användarnamn för att se den detaljerade användarkonfigurationen.

Användbar information i den här vyn inkluderar användarens UUID, CI-kluster (Common Identity), Webex-appkluster, Samtalsbeteende, BroadWorks-konto-GUID.
4

Klicka på Kopiera om du behöver använda den här informationen i ett annat verktyg, eller bifoga den till ett Cisco-ärende.

Visa kundorganisation i Help Desk

1

Logga in på https://admin.webex.com/helpdesk.
2

Sök efter och klicka sedan på kundens organisationsnamn.
3

Bläddra nedåt tills du ser kundportalvyn och klickar på Visa kundnamn för att se en skrivskyddade vy av kundorganisationen, inklusive användare och konfiguration.

Hämta användarloggar från partnerhubben

Vid felsökning av problem med stationära och mobila klienter är det viktigt för partner (och TAC) att kunna se klientloggarna.

1

Be användaren att skicka loggar.
2

Be användaren att exportera samtalsmiljön för att skicka filen ced.dat till dig.
3

Hämta klientloggarna från partnerhubben eller Help Desk (se nedan).

Partner Hub-alternativ:

  1. Logga in på Partner Hub och hitta användarens kundorganisation.

  2. Välj Felsökning.

  3. Välj Loggar.

  4. Sök efter användaren (via e-post).

  5. Visa och hämta klientloggarna som en zip-fil.

Help Desk alternativ:

  1. Logga in på Help Desk.

  2. Sök efter organisationen.

  3. Klicka på organisationen (öppnar sammanfattningsskärmen).

  4. Bläddra nedåt för att klicka på Visa kund.

  5. Välj Felsökning.

  6. Välj Loggar.

  7. Sök efter användaren (via e-post).

  8. Visa och hämta klientloggarna som en zip-fil.

Så här hittar du klientversionen

1

Dela den här länken med användaren: https://help.webex.com/njpf8r5.
2

Be användaren att skicka versionsnumret till dig.

Klientkontroll av samtalstjänst

1

Logga in på Webex-klienten.
2

Kontrollera att ikonen Samtalsalternativ (en telefon med kugghjulet ovanför) finns på sidopanelen.

Om ikonen inte finns är det möjligt att användaren ännu inte har aktiverats för samtalstjänsten i Control Hub.
3

Öppna menyn Inställningar/Inställningar och gå till avsnittet Telefontjänster. Du bör se statusen SSO Session du ärinloggad.

(Om en annan telefontjänst, till exempel Webex Calling, visas att användaren inte använder Webex för BroadWorks.)

Den här verifieringen innebär:

  • Klienten har förflyttat sig över de Nödvändiga Webex-mikrotjänster.
  • Användaren har verifierats.
  • Klienten har utfärdat en JSON-webbtoken som är long-en dån av ditt BroadWorks-system.
  • Klienten har hämtat sin enhetsprofil och har registrerats i BroadWorks.

Få Klientloggar eller feedback

  • Se avsnittet Resurser för att hitta specifika klientloggar på Webex-skrivbordsklienter eller be användare att skicka loggar.

  • Be användare av mobilklienter att skicka loggar och sedan kan du få dem via en partnerhubb eller helpdesk.

Skicka loggar är tyst. Men om en användare skickar feedback går den till Cisco Webex devops-appen. Se till att spela in användarens feedbacknummer om du vill följa upp med Cisco. Till exempel:

Hämta data för samtalsmiljö

Webex-klientloggar är i stort fel för att ta bort personligt identifierbar information. Du bör exportera samtalsmiljödata från klienten i samma session som du märker problemet.

1

I -klienten klickar du på ikonen profilbild och sedan på Hjälp > Exportera samtalsmiljödata.
2

Spara den resulterande filen ced.dat för att felsöka samtalsproblem för den här användaren.

Viktigt: Logga ut från eller starta om klienten rensar det interna cacheminnet. Om du exporterar ced.dat efter det kommer de exporterade data inte att överensstämma med loggar som skickades innan cachen.

Återställ Webex-databasen

1

På klienten klickar du på Hjälp > Hälsokontroll.
2

Välj Återställ databas.

Detta utlöser en fullständig återställning av klienten och läser in inloggningsskärmen för Webex-appen.

Verifiera att Webex ska registrera sig i BroadWorks

Webex-appen kontrollerar följande information för att avgöra om den ska registreras i BroadWorks:

  • Användarberättigande för broadworks-connector

  • Samtalsbeteende för organisation och användare

Kontrollera en användares samtalsbeteende och anslutningsberättigande

  1. Logga in på Help Desk (https://admin.webex.com/helpdesk) med dina autentiseringsuppgifter som partneradministratör.

  2. Sök efter användaren.

  3. Klicka på användaren och kontrollera posten Samtalsbeteende. Det ska vara "Ringer i Webex".

  4. Klicka på användarnamn här sidan för att öppna skärmbilden Användarinformation.

  5. Bläddra ner tills du hittar entitlements och kontrollera att broadworks-connector inkluderas.


    En Webex för BroadWorks-användare ska INTE ha bc-sp-standard berättigande om de avser att använda Webex för BroadWorks. Detta är berättigandet för "Webex Calling (Broadcloud)" som är samtal från Webex-appar via en Cisco-hanterad molnsamtalstjänst.

Kontrollera organisationens samtalsbeteende

  1. Logga in på Help Desk (https://admin.webex.com/helpdesk) med dina autentiseringsuppgifter som partneradministratör.

  2. Sök efter organisationen.

  3. Klicka på organisationen och markera posten Samtalsbeteende. Det ska vara "Ringer i Webex".

Analysera PSLog vid problem vid användareetablering

Använd programserverns PSLog för att se HTTP POST-begäran till etableringsbryggan och svaret från Webex.

I ett korrekt arbetsfall är svaret 200 OK och efter några minuter kan du se användaren och den nya kundorganisationen om den är den första användaren – har skapats i Webex.

Du kan verifiera detta genom att Help Desk efter den e-postadress du ser i POST.

Innan du börjar

Samla in en PSLog från programservern under ett flowuppräckningsförsök med en testanvändare.

1

Det första du ska kontrollera är HTTP-svarskoden:

  • Allt annat än 200 OK är ett fel vid användareablering.

  • 200 OK kan fortfarande indikera ett fel om något om prenumerantens profil inte fungerar i Webex-tjänsterna före etableringsbryggan.

  • 400 kan innehålla ett message noden i svaret. Provisioneringsbryggan kunde inte bearbeta något i subscriberProfile. Det kan vara något fel med prenumerantinformationen eller inkompatibilitet med mallens inställning.

  • 401 innebär att de autentiseringsuppgifter för tillhandahållande som angavs i AS inte överensstämmer med de som angavs i mallen i partnerhubben.

  • 403 kan indikera att något är felaktigt konfigurerat på programservern. Kontrollera målet för förfrågan. det ska inte vara en IP-adress, utan den URL för tillhandahållande bridge som du kan se i din mall i partnerhubben.

  • 409 indikerar en konflikt mellan det tillhandahållna subscriberProfile och befintliga Webex-data. Det kan finnas en befintlig användare med den e-postadressen. Kontrollera kryssrutan message i svaret.

2

Du kan även kontrollera original-HTTP POST med alla misstänker värden som kan orsaka att etableringen misslyckas.

POST innehåller ett subscriberProfile XML-struktur. I det här är användbara noder att kontrollera:

  • bwuserid: Använd den här för att hitta prenumerantens profil om du behöver redigera den i BroadWorks.

  • group: Om mallen är i "tjänsteleverantör-läge" är denna i små bokstäver och blir namnet på kundorganisationen du ser i partnerhubben.

  • serviceProvider: Om mallen är i "Företagsläge" är denna i små bokstäver och blir namnet på kundorganisationen du ser i partnerhubben.

  • primaryPhoneNumber: Måste finnas. Etablering misslyckas utan den.

  • email: Blir den användar-id i Webex. Måste vara giltigt och unikt för Webex, annars misslyckas etableringen.


 

Ignorera services Stanza: den skapas av AS och accepteras men används inte av Webex.

Analysera XSP-loggar för att felsöka prenumeranters inloggning

Det här flödet beskriver BroadWorks-autentiseringsläge. Du kan se autentiseringsläget för BroadWorks-mallen i Partner Hub. Se Konfigurera kundmallar i https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Följande ladder-diagram visar interaktionen mellan användaren, klienten, Webex-tjänster och BroadWorks-systemet när användaren gör BroadWorks-autentisering i Webex-appen. Dessutom säkras anslutningen mellan Webex och XSP av MTLS.

Diskussionen som följer förklarar vad du kan förvänta dig att se när du undersöker loggarna för ett lyckat inloggningsförsök.

Figur 1. BroadWorks-autentisering och enhetskonfiguration

Användaren interagerar med klient, klienten interagerar med Webex-tjänster:

  • Användaren levererar sin e-postadress till Webex-appen (1 i diagrammet).

  • CI vet att den här användaren ska omdirigeras för att ange sitt BroadWorks-lösenord (via UAP) (2 i diagrammet).

  • IDP-proxyn skickar in en begäran om att hämta profilen till Xsi-gränssnittet på XSP:en.

I tomcat-access_log:

  • Sök efter GET-begäran för prenumerantens profil, från Webex till Xsi-Actions-gränssnittet (2.1 i diagrammet). Den har Webex-användar-id. E.g.

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

I XsiActionsLog:

  • Sök efter profilen GET-begäran från Webex (2.1 i diagrammet). Den har Webex-användar-id. E.g.

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

    Sidhuvudet inkluderar authorization: Basic och user-agent: broadworksTeamsClient

  • XSP gör sedan RESPONS-P Basic-autentisering mot BroadWorks (AuthenticationVerifyRequest och AuthenticationVerifyResponse, precis som för alla andra program som gör grundläggande autentisering via Xsi) och även en UserGetRequest och ServiceProviderGetRequest för att samla in prenumerantens information.

  • Xsi-svaret till Webex innehåller ett XML- Profile blockera som innehåller (BroadWorks) userId och andra detaljer (2.2 i diagrammet).

Interaktioner mellan klienter och Webex-tjänster:

  • IDP-proxyn matchar användarprofil från BroadWorks och problem med SAML-försäkran till klienten (2.3 i diagrammet)

  • Klientutbyten SAML-kontroll för en CI-token (3 i diagram)

  • Klienten kontrollerar att den inloggade användaren har broadworks-connector-behörighet (4 i diagrammet). Du kan kontrollera användarberättiganden i Help Desk)

  • Klienten använder CI-token för att begära en JSON-webbtoken (JWT) från IDP-proxy (5 i diagrammet)

  • IDP-proxy validerar CI-token hos CI

  • IDP-proxy begär JWT från verifieringstjänsten

I authenticationService-loggen:

  • Leta efter tokenbegäran från Webex (5.2 i diagrammet), t.ex.:

    GET /authService/token

    som har http_bw_userid sidhuvudet och andra.

  • XSP gör EN-P UserGetLoginInfoRequest, för att validera att det angivna användar-ID:t motsvarar en BroadWorks-användare (5.3 i diagrammet). AuthService har etablerat förtroende för Webex genom mTLS-anslutningen, så kan problemet LLT.

  • Leta efter svaret (5.4 i diagrammet) från LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

    och StatusCode=200 som du kan koppla till den ursprungliga begäran med hjälp av trackingid: CLIENT… Huvudet.

I XsiActionsLog:

  • Klienten kan nu presentera den sedan länge aktuella token i Xsi-Actions-gränssnittet för att få enhetsprofilen (6 i diagrammet). E.g.:

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

    Med sidhuvudet authorization: Bearer token och user-agent: WebexTeams (variant/version)

  • Xsi-Actions-gränssnittet, POST-token till authservice (konfigurerat för att vara i loopback-gränssnittet), t.ex.: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    som du kan jämföra med trackingid: CLIENT… sidhuvudet i GET och X-BROADSOFT-CORRELATION-ID : CLIENT… sidhuvudet i POST.

I authenticationService-loggen:

  • Post har mottagits från Xsi (loopback)

  • A StatusCode=200 tillbaka till Xsi

  • Och ett svar på tokenvalidering, med ett "token" JSON-blockering i texttexten.

  • Är förknippad med användning av trackingid: CLIENT…

I XsiActionsLog:

  • Efter att ha tagit emot 200 OK från authservice, som validerat klientens token, skickar Xsi-Actions-programmet nu EN-P-begäran om UserPrimaryAndSCADeviceGetListRequest

  • Tar emot EN-P UserPrimaryAndSCADeviceGetListResponse som innehåller accessDeviceTable XML-struktur.

  • EN-P-svaret kodas som Xsi-svar till klienten, inklusive AccessDevices XML-struktur, som har deviceTypes E.g. Business Communicator – PC och URL:er där klienten kan hämta enhetens konfigurationsfiler.

Klienten fortsätter som vanligt:

  • Väljer en enhetspost och interagerar med DMS för att hämta enhetsprofilen (6 i diagrammet)

  • Registreringar i BroadWorks via SBC som har hämtats i konfigurationen från DMS (7 i diagrammet)