Tak for din feedback.

Denne artikel er beregnet til teknisk supportteam hos serviceudbyderorganisationer, der støtter sig selv og deres kunder. De bør være bekendt med generel fejlfinding, læsning af logfiler og arbejde med abonnentsager.

Denne artikel er opdelt i tre hovedafsnit:

• Ressourcer – indeholder en liste over værktøjer, læsemateriale, logfiler og kontakter, du måtte have brug for.
• Processer – beskriver nogle af de handlinger, du kan udføre, når du fejlfinder et kundeproblem.
• Specifikke problemer – kategoriserer og oplister problemer, der er kendt for at opstå, hvordan man opdager dem, og hvordan man potentielt kan løse dem.

Nyttige logfiler

Læseliste

• Webex til Cisco BroadWorks Partner Vidensportal
• XSP-platformkonfigurationsvejledning (R23)
• BroadWorks-softwarehåndteringsvejledning (R23)
• Cisco BroadWorks-enhedsstyringskonfigurationsvejledning (R23)
• Administrationsvejledning til Broadworks Xsp-kommandolinjegrænsefladen
• Udgivelse 23.0 af bekræftelsestoken, der indeholder mange autentificeringsfunktionen
• SAML-godkendelsesintegrationsvejledning, R23
• Guide til supportmuligheder for Cisco BroadWorks SSL
• Beskrivelse af Cisco CI-supportfunktion
• Meddelelses-pushserver (funktionsbeskrivelse)
• Push-underretningssupport til opkald funktionsbeskrivelse udgivelse 22.0
• Fremgangsmåde for migrering af Connect (Android) til Firebase
• Cisco BroadWorks-lagring af enhedstokens til push-notifikationer Funktionsbeskrivelse Version 22.0
• Cisco BroadWorksSystem Kapacitetsplanlægger (regneark)
• Dimensioneringsvejledning til Cisco BroadWorks-platformen
• Guide til systemudvikling af Cisco Broadworks
• CI-godkendelse supportkrav dokument version 1.0 MR-7136

Kendte problemer og begrænsninger

Artiklen Kendte problemer og begrænsninger indeholder opdaterede oplysninger om kendte problemer, som vi har identificeret i Webex til BroadWorks-løsningen.

Konnektor til Servicevenlighed

Webex Serviceability-tjenesten øger den hastighed, hvormed Ciscos tekniske assistancepersonale kan diagnosticere problemer med infrastrukturen. Det automatiserer opgaverne med at finde, hente og lagre diagnostiske logs og information i en SR-sag. Tjenesten udløser også analyse mod diagnostiske signaturer, så TAC mere effektivt kan identificere og løse problemer med dit lokale udstyr.

For detaljer om, hvordan du implementerer Serviceability-connectoren, se Implementeringsvejledning til Cisco Webex Serviceability Connector.

Eskalering af et problem

Når du har fulgt nogle af fejlfindingsvejledningerne, burde du have en rimelig idé om, hvor problemet ligger.

Procedure

1. Indsaml så mange oplysninger som muligt fra de systemer, der er relateret til problemet.
2. Kontakt det relevante team hos Cisco for at åbne en sag.

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-identifikatoren, men hvis du også får brugerens BroadWorks-identifikator, skal du inkludere den i sagsoplysningerne).
• Organisationsidentifikator.
• Omtrentlig tidsramme, hvor problemet opstod.
• Klientplatform og version.
• Send eller indsaml logfiler fra klienten.
• Registrer sporings-ID'et, hvis det vises på klienten.

Tjek brugeroplysninger i Help Desk

Partneradministratorer med rollen Help Desk-administrator (grundlæggende eller avanceret) kan bruge denne procedure til at kontrollere brugeroplysninger ved hjælp af Help Desk-visningen.

Procedure

1. Log ind på 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, fælles identitetsklynge (CI), Webex-appklynge, opkaldsadfærd og BroadWorks-konto-GUID.
4. Klik på Kopier, hvis du har brug for at bruge disse oplysninger i et andet værktøj, eller vedhæft dem til en Cisco-sag.

Se kundeorganisation i Help Desk

Partneradministratorer med rollen Help Desk-administrator (grundlæggende eller avanceret) kan bruge denne procedure til at se oplysninger om kundeorganisationen i Help Desk-visningen.

Procedure

1. Log ind på 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 – inklusive brugere og konfiguration.

Hent brugerlogfiler fra Partner Hub

Ved fejlfinding af problemer med desktop- og mobilklienter er det vigtigt, at partnere (og TAC) kan se klientlogfilerne.

Procedure

1. Bed brugeren om at sende logfiler. For hjælp henvises til: Webex-app | Rapportér et problem.
2. Bed brugeren om at eksportere opkaldsmiljøet og sende dig filen ced.dat.
3. Hent klientloggene fra Partner Hub eller Help Desk.

   Valgmuligheden Partner Hub:

   1. Log ind på Partner Hub, og find brugerens kundeorganisation.
   2. Vælg Fejlfinding.
   3. Vælg Logs.
   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.

Sådan finder du klientversionen

Procedure

1. Del dette link med brugeren: https://help.webex.com/njpf8r5
2. Bed brugeren om at sende dig versionsnummer.

Klienttjek for opkaldstjeneste

Procedure

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 Cisco BroadWorks.)

   Denne bekræftelse betyder:

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

Få klientlogfiler eller feedback

• Se afsnittet Ressourcer for at finde specifikke klientlogs på Webex-desktopklienter, eller bed brugere om at sende logfiler. For hjælp henvises til: Webex-app | Rapportér et problem.
• 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.

Procedure

1. Klik på Hjælp i klienten. > Sundhedstjekker.
2. Vælg Nulstil database. Dette udløser en fuld nulstilling af klienten og indlæser Webex-appens loginskærm.

Bekræft, at Webex skal registreres til BroadWorks

Webex-appen kontrollerer følgende oplysninger for at afgøre, om den skal registreres til BroadWorks:

• Brugerrettigheder til broadworks-connector.
• Opkaldsadfærd for organisation og bruger.

Kontrollér en brugers opkaldsadfærd og konnektorberettigelse

1. Log ind på Help Desk med dine partneradministratoroplysninger.
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 afsnittet entitlements, og bekræft, at broadworks-connector er inkluderet

   

   En Webex til Cisco BroadWorks-bruger bør ikke have rettigheden bc-sp-standard, hvis de har til hensigt at bruge Webex til Cisco BroadWorks. Dette er berettigelsen til "Webex Calling (Broadcloud)", som er Webex App-opkald via en Cisco-administreret cloud-opkaldstjeneste.

Kontrollér organisationens opkaldsadfærd

1. Log ind på Help Desk med dine partneradministratoroplysninger.
2. Søg efter organisationen.
3. Klik på organisationen, og marker posten Opkaldsadfærd. Det bør være "Opkald i Webex".

Analysér PSLog for problemer med brugerprovisionering

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.

Procedure

1. Tjek først HTTP-svarkoden:
   • Alt andet end 200 OK er en fejl i bruger klargøring.
   • 200 OK kan stadig indikere en fejl, hvis noget ved abonnentprofilen ikke fungerer i Webex-tjenesterne opstrøms for provisioneringsbroen.
   • 400 kan indeholde en message node i svaret. Provisioneringsbroen 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 angivne subscriberProfile og eksisterende Webex-data. Der er muligvis en eksisterende bruger med denne e-mailadresse. Marké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'en 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 "Tjenesteudbydertilstand", skrives dette med små bogstaver 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 eksistere. Klargøring mislykkedes uden den.
   • email: Bliver bruger-id i Webex. Skal være gyldig og unik for Webex. Ellers mislykkes klargøring.

     Ignorer services -strofen: den er oprettet af AS og accepteret, men ikke brugt af Webex.

Analysér XSP-logfiler for at fejlfinde abonnentlogin

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 ladderdiagram viser interaktionen mellem brugeren, klienten, Webex-tjenester og BroadWorks-systemet, når brugeren udfører BroadWorks-godkendelse i Webex-appen. Forbindelsen mellem Webex og XSP er også sikret af MTLS.

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

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

• Brugeren angiver sin e-mailadresse til Webex-appen (1 i diagrammet).
• 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 hankatten 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. Eksempel:

  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. Eksempel:

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile Overskrifterne 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 til Webex indeholder en XML Profile -blok, der indeholder (BroadWorks) userId og andre detaljer (2.2 i diagrammet).

Klient- og Webex-tjenesteydelsesinteraktioner:

• IDP-proxy matcher brugerprofil modtaget fra BroadWorks og udsteder SAML-assertion til klienten (2.3 i diagrammet).
• Klienten udveksler SAML-assertion for et CI-token (3 i diagrammet).
• Klienten kontrollerer, at den bruger, der er logget ind, har berettigelse til broadworks-connector (4 i diagram). Du kan tjekke brugerrettigheder i Help Desk.
• Klienten bruger et CI-token til at anmode om et JSON Web Token (JWT) fra en IDP-proxy (5 i diagrammet).
• IDP-proxy validerer CI-token ved CI.
• IDP-proxy anmoder om JWT fra godkendelsestjenesten.

I bekræftelsesserviceloggen:

• Se efter tokenanmodningen fra Webex (5.2 i diagrammet), for eksempel: GET /authService/token som har http_bw_userid header og andre.
• XSP'en udfører OCI-P UserGetLoginInfoRequestfor at validere, at det angivne bruger-id svarer til en BroadWorks-bruger (5.3 i diagrammet). 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 knytte til den oprindelige anmodning ved hjælp af headeren trackingid: CLIENT… .

I XsiActionsLog:

• Klienten kan præsentere det langlivede token på Xsi-Actions-grænsefladen for at få sin enhedsprofil (6 i diagrammet). Eksempel: GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device Med overskrifterne authorization: Bearer token og user-agent: WebexTeams (variant/version)
• Xsi-Actions-grænsefladen sender tokenet til authservice (konfigureret til at være på loopback-grænsefladen). For eksempel: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token som du kan korrelere med trackingid: CLIENT… -overskriften i GET og X-BROADSOFT-CORRELATION-ID : CLIENT… -overskriften i POST.

I bekræftelsesserviceloggen:

• Modtagelse af POST fra Xsi (loopback)

• En StatusCode=200 tilbage til Xsi

• Og et tokenvalideringssvar med en "token" JSON-blok 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 en OCI-P-anmodning om UserPrimaryAndSCADeviceGetListRequest
• Modtager OCI-P UserPrimaryAndSCADeviceGetListResponse indeholdende XML-strukturen accessDeviceTable.
• OCI-P-svaret er kodet som Xsi-svar til klienten, inklusive AccessDevices XML-strukturen, som har deviceTypes. Eksempel: Business Communicator – PC og URL-adresserne, hvor klienten kan hente enhedskonfigurationsfilerne.

Klient fortsætter som normalt:

• Vælger en enhedspost og interagerer med DMS for at hente enhedsprofilen (6 i diagrammet).
• Registre til BroadWorks via SBC hentet i konfigurationen fra DMS (7 i diagrammet).

Problemer med Partner Hub

1. Administrator kan ikke se kundeorganisationer

Som administrator for din partnerorganisation i Webex bør du have rollen Fuld administrator. Denne rolle bruges til at administrere din partnerorganisation, herunder tildeling af administrative privilegier til dig selv og andre. For at administrere kundeorganisationer skal du tildele dig selv (eller andre personer) rollen Salgsadministrator eller rollen Salgsadministrator. For yderligere oplysninger, se Tildel organisationskontoroller i Control Hub.

Problemer med brugerprovisionering

1. Integreret IM & P-fejl for specifikke virksomheder / kunder

Hvis du har en blanding af virksomheder, der bruger forskellige cloud-samarbejdstjenester, for eksempel UC-One SaaS og Webex til Cisco BroadWorks, har du muligvis valgt at ændre klargøringsadapteren for hver enkelt virksomhed.

Sådan kontrollerer du, hvad der er konfigureret til integreret chat & P (standard for virksomheder, medmindre der findes en mere specifik indstilling), kør AS_CLI/Interface/Messaging> get. For en specifik virksomheds klargøringsparametre skal du åbne virksomheden og gå til Tjenester > Integreret IM & P.

Kontroller, at den integrerede IM&P-konfiguration for denne virksomhed passer til præcist det, der vises i kundeskabelonen i Partner Hub. Følgende indstillinger skal være ens, ellers mislykkes klargøring for alle brugere i virksomheden:

2. Integreret IM & P-fejl for specifikke brugere

Dette gælder, hvis du bruger flowthrough-provisionering og antager, at provisioneringen fungerer for some/most brugere (så du kan udelukke et konfigurationsproblem). Hvis du ser integreret chat & P-fejl i BroadWorks, for eksempel, “[Error 18215] Klargøringsfejl med meddelelsesserver” og “[Error 18211] Kommunikationsfejl med meddelelsesserver”, bør du undersøge følgende mulige årsager:

• Brugerens e-mailadresse kunne allerede eksistere CI. Søg efter brugeren i helpdesken for at kontrollere, om deres e-mailadresse allerede er der. Dette er ikke nødvendigvis afgørende, fordi brugeren muligvis findes i en organisation, hvis data du ikke har tilladelse til at se i helpdesk'en.
• Brugeren tilmeldte sig Uafhængigt Webex, før den tildelte den integrerede IM&P-tjeneste. I dette tilfælde er én mulighed at få brugeren til at slette sine gratis konti, så de kan blive en del af den kundeorganisation, du klargør. Instruktionerne er kl. https://help.webex.com/5m4i4y
• Brugeren har ikke et primært telefonnummer tildelt sin profil (alle Webex til Cisco BroadWorks-abonnenter skal have et primært DID). Se emnet for analyse af PSLog fra AS.

3. Brugerklargøringsfejl som svar fra klargøringsbro

Hvis brugerne ikke vises i Control Hub, inden for få minutter efter tildeling af integreret chat & P, se på svarkoderne fra provisioneringsbrotjenesten. Kør en PSLog for at se på HTTP-responskoderne.

200 OK

Et 200 OK-svar betyder ikke, at brugeren er klargjort. Det betyder, at klargøringstjenesten modtog anmodningen og indsendte den tilsvarende anmodning om brugeroprettelse til upstream-tjenester. Klargøringstransaktionen er asynkron af design. Tjenesten svarer 200 OK, fordi brugeroprettelsesprocessen kan tage flere minutter, og vi af ydeevneårsager ikke ønsker at modtage flere anmodninger om at oprette den samme bruger. Hvis brugeren dog ikke vises i kundeorganisationen efter et 200 OK-svar, kan det indikere, at brugeroprettelsen mislykkedes i Webex-tjenesterne forud for klargøringstjenesten. Du skal eskalere en klargøringsfejl, der har et 200 OK-svar.

400 dårlig anmodning

Kontrollér HTTP-svaret, som bør have flere oplysninger om potentielle problemer, der kan forårsage dette svar fra klargøringstjenesten. Her er nogle eksempler på knudepunktet:

• "Kan ikke stole på BroadWorks-e-mail med ældre klargørings-API." E-mailadressen, der er tilknyttet den manglende anmodning om bruger klargøring, er ikke gyldig eller forkert indtastet, men du har påstået i skabelonen, at e-mailadresserne kan være pålidelige. Tjek brugernes profiler i BroadWorks, nærmere betegnet e-mail-id'et.
• Kundeorganisationen findes ikke i databasen, og flaget for oprettelse af ny organisation er heller ikke aktiveret. Denne mislykkede klargøringsanmodning bør oprette en ny kundeorganisation i Webex, men din skabelon er konfigureret til at forhindre, at nye kundeorganisationer oprettes. Hvis du vil tillade nye organisationer, for e-maildomæner, der ikke matcher eksisterende kunder i Webex, kan du konfigurere din skabelon igen i Partner Hub og genteste klargøringsanmodningen. Men hvis du ikke forventer, at der oprettes en ny organisation for denne bruger, er e-mailadressen måske indtastet forkert (specifikt domænet). Kontroller brugerens e-mail-id i BroadWorks.

403 forbudt

Klargøringsanmodningen kan ikke lykkes, før du har rettet konfigurationen. Du skal undersøge anmodningen og svaret i dette tilfælde. Hvis du for eksempel ser en IP-adresse som mål for klargøringsanmodningen – i stedet for den passende URL-adresse til klargøringsbroen for din organisation (se emner om firewallkonfiguration i løsningsvejledningen) – kan det indikere, at din applikationsserver mangler en påkrævet programrettelse (ap373197).

Kontroller, at alle de påkrævede programrettelser er anvendt på applikationsserveren, og at du har fuldført den relaterede konfiguration for vellykket flowthrskaleringsoprettelse.

409 konflikt

Klargøringsanmodningen kan ikke fortsætte, fordi der er en eksisterende bruger i Webex, som matcher e-mailadressen i anmodningen.

4. Bruger er allerede i CI

Få abonnentens e-mail ud af HTTP POST-anmodningen, og søg efter den i Help Desk. Du kan ikke se brugeren, hvis du ikke har tilladelse, men du kan også se, at brugeren er i en "gratis" organisation, f.eks. "Forbruger". Du kan bede denne bruger om at slette deres gratis konto, eller du kan bruge en anden e-mailadresse til at klargøre dem. Se .https://help.webex.com/ndta402

Problemer med brugerlogin

1. Brugeraktiveringsportalen indlæses ikke

Det normale Webex til Cisco BroadWorks-logonflow omfatter en brugeraktiveringsportal, hvor brugere indtaster deres adgangskoder. Nogle gange indlæses denne portal ikke, efter at brugeren har angivet sin e-mailadresse på Webex-appens loginskærm. Dette problem kan være forårsaget af på klientsiden eller på servicesiden. På klientsiden skyldes det typisk, at klientens indbyggede browser på en eller anden måde ikke er kompatibel med tjenesten.

2. Single sign-on mislykkedes

• I BroadWorks skal du kontrollere, at brugeren har fået tildelt enhedstyperne til Webex-appen (se afsnittet Enhedsprofiler i afsnittet Forbered dit miljø i løsningsguiden).
• Kontroller, at brugeren bruger den korrekte adgangskode. Hvis den skabelon, du brugte til at klargøre brugerens kundeorganisation (i Partner Hub), er konfigureret til BroadWorks-godkendelse, skal brugeren indtaste sin BroadWorks-adgangskode til "Webadgang". Brugeren skal muligvis også indtaste sit BroadWorks-bruger-ID, hvis deres e-mailadresse ikke er konfigureret som et alternativt bruger-ID. Sørg for, at brugeren har indtastet store og små bogstaver korrekt.

Problemer med opkaldskonfiguration og registrering

Når en bruger er blevet klargjort i Webex, og de logger ind på Webex-appen, registreres appen til BroadWorks. Følgende er den forventede registreringssekvens og de resulterende tegn på en god registrering (som set fra Webex-appen):

1. Forventet registreringssekvens

1. Klienten ringer til XSI for at få en enhedsadministrationstoken og URL-adressen til DMS.
2. Klienten anmoder om sin enhedsprofil fra DMS ved at præsentere tokenet fra trin 1.
3. Klienten læser enhedsprofilen og henter SIP-legitimationsoplysninger, -adresser og -porte.
4. Klienten sender et SIP REGISTER til SBC ved hjælp af oplysningerne fra trin 3.
5. SBC sender SIP-REGISTERET til AS'en (SBC kan foretage et opslag i NS'en for at finde en AS, hvis SBC ikke allerede kender SIP-brugeren).

2. Forventede tegn på vellykket klientregistrering

Opkaldsvalgmuligheder-ikonet vises i Webex-grænsefladen.

I Webex-appens fane for telefontjenester (f.eks. Indstillinger > Telefontjenester på Windows, Indstillinger > Telefontjenester på Mac), meddelelsen “SSO-session: Du er logget ind" betyder, at appen er tilmeldt (til BroadWorks i dette tilfælde).

3. Klienten har intet opkaldsikon

Det meste af tiden betyder det, at brugeren ikke har den korrekte licens/berettigelser.

Dette er en mislykket registrering. Der er flere grunde til, at en Webex App-klient ikke kan registreres hos BroadWorks:

4. Flere opkaldstjenester testes med de samme klienter

Dette kendte problem kan forårsages af, at klienten ændrer sig mellem forskellige tilbagekaldsslutninger. Det er mest sandsynligt, at det sker under prøveperioder med forskellige opkaldstjenester, der tilbydes via (de samme) Webex-appklienter. Du kan nulstille klientdatabasen (link) for at løse dette problem.

5. Fejlkonfiguration af godkendelsestjenesten

Tjek XSP(er), der er vært for godkendelsestjenesten, i forhold til løsningsvejledningen (se Konfigurer tjenester på din Webex for Cisco BroadWorks XSPs). Specifikt:

• RSA-tasterne (som du genererer på en XSP) kopieres på alle XSP'er
• Bekræftelsestjenestens URL-adresse er blevet leveret til webbeholderen på alle XSPs og indtastet korrekt i klyngen i Partner Hub
• Ekstern godkendelse med certifikater er konfigureret:

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>get

  allowUserApp = false

  allowClientApp = true

• Når du bruger MTLS, skal du uploade Webex-klientcertifikatet til XSP'erne (du kan hente certifikatet fra Partner Hub på siden BroadWorks-indstillinger).

6. Forkert konfiguration af BroadWorks-tags

Kontroller, at du har konfigureret de nødvendige BroadWorks-tags til Webex-appen. Se Webex til Cisco BroadWorks-konfigurationsvejledningen for information om konfigurationstags. Sørg for, at der ikke er konflikter eller forkerte værdier. Specifikt skal %SBC_ADDRESS_WXT% -tagget være SBC'en mod din SIP-registrator for Webex-appklienter.

7. Desktopklient afbryder telefontjenester efter vellykket SSO-forbindelse

Dette problem kan skyldes, at den samme bruger logger ind på flere klienter på den samme platformstype. Hvis en bruger for eksempel logger ind på Webex-appen på Windows og derefter logger ind på Webex-appen på en anden Windows-maskine, er der kun en aktiv SSO-session på én af maskinerne. Dette er efter design. Hvis du har behov for at løse dette problem, kan du konfigurere BroadWorks til at have flere tilfælde af den samme enhedstype, men de skal have unikke SIP-adresser. Denne konfiguration er uden for Webex's rækkevidde for Cisco BroadWorks.

8. Desktop-enhed er ikke klargjort til brugeren

Denne signatur ses i klientloggen:

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - the device profile 'Business Communicator - PC' is not found.

9. Indgående mobilopkald ringer én gang eller kan ikke besvares

Indgående opkald til Webex Mobile ringer kun én gang, eller brugeren kan ikke besvare det indgående opkald. Andre slutpunkter for den samme bruger kan fortsætte med at ringe.

Hvordan identificerer man?

I Webex Mobile-klientloggene skal du se efter XSI-fejlkode 101002 i push-opkaldsflowet. Eksempel:

Svarkode: 400

handlePushCallInfoFailure:BWC:INTERNAL: Push-opkald: xsi-status for callID: <callID> xsi fejlkode: 101002

closePushCallWithReason:BWC:INTERNAL: Prøv at lukke push-opkald med id = <callID>, grund = OpkaldForladt

Årsag: Fejlkode 101002 kan indikere, at den forkerte applikationsserver (AS) returneres i LocateUser -svaret. Dette kan ske, når brugeren er migreret til et sekundært AS.

Anbefalede kontroller:

Fra den ADP eller XSP, hvor Push er implementeret, skal du køre LocateUser for den berørte bruger:

curl 'http://:80/servlet/LocateUser?url=&returnCompatibleXSP=true&callPRequest=true'

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

Opløsning: Hvis LocateUser returnerer det sekundære AS for brugeren, skal du køre scriptet migrateUserToDefaultNode.pl på den primære NS-server for at migrere brugerne tilbage til den primære applikationsserver for klyngen.

Log ind på NS-serveren via SSH, gå til /usr/local/broadworks/bw_base/bin mappen, og kør:migrateUserToDefaultNode.pl

Eksempel: migrateUserToDefaultNode.pl bwas1

For at få værdien hostingNE skal du køre: NS_CLI/System/Device/HostingNE> get

Scriptet kontrollerer først, om det kan finde den hosting-NE, som du angiver som argument. Når den har verificeret, at den hostende NE er gyldig, opdaterer den DN, udvidelsen og URL'en til standardnoden for den hostende NE.

Kør scriptet i en periode med lav trafik, når det er muligt. Det er dog generelt acceptabelt at køre scriptet når som helst, hvis det er nødvendigt for at genoprette tjenesten for berørte brugere.

Scriptet kan ikke køres for kun en enkelt bruger. Den migrerer alle brugere, der er angivet i LocateUser outputtet. Hvis du ikke kan køre scriptet, skal du slette og genopbygge den berørte bruger i BroadWorks, så brugeren genopbygges på det korrekte AS.

Enhver SIP-besked fra brugerenheden til det sekundære AS kan få brugeren til at migrere. Brugere vender typisk tilbage til det primære AS efter standardintervallet på 15 minutter, medmindre indgående anmodninger fortsætter med at nå det sekundære AS. Hvis SBC'en for eksempel ikke kan oprette forbindelse til AS1 og bruger det sekundære AS som rekursivt aktiv, kan berørte brugere skifte til det sekundære AS. Afhængigt af implementeringen kan en enkelt trunk-gruppe eller bruger forblive fastgjort til det sekundære AS, hvis SBC'en fortsat har problemer med at nå det primære AS.

For yderligere information, se følgende dokumenter:

• Afsnit 3.4.5 Brugerrollback-funktionalitet for applikationsserver og 5.4.5 Automatisk rollback i Cisco BroadWorks redundansvejledning

• Beskrivelse af funktioner i Cisco BroadWorks ASR-forbedringer

Problemer med webvisning af opkaldsindstillinger

1. Selvpleje button/link vises ikke i Webex-appen

Et andet symptom på dette problem er, når knappen/linket vises, men når der klikkes på det, åbnes en ekstern browser.

• Bekræft, at den nødvendige klientkonfigurationsskabelon er implementeret, og at CSW-tags er korrekt indstillet. (Se afsnittet Opkaldsindstillinger Webvisning i Webex til Cisco BroadWorks løsningsguide).
• Bekræft, at Webex-appen er registreret til opkald i BroadWorks.
• Kontroller, at Webex-appen er en nyere version, der understøtter CSWV.

2. Tom side eller fejl efter at have klikket på Selvhjælp button/link

Generelt indikerer denne adfærd i Webex-appen et konfigurations- eller implementeringsproblem med CSWV-applikationen på BroadWorks XSP. Indsaml oplysninger om yderligere undersøgelse, herunder CSWV-logfiler, adgangslogfiler, config-wxt.xml-lager og skabelonfil, og røg derefter en sag.

Problemer med domænekrav

Brugertilmeldingsfejl kan opstå som følge af fejl, der opstår under krav på domæner. Inden du gør krav på nogen domæner, skal du sørge for at forstå følgende:

• Tjenesteudbydere bør ikke gøre krav på domænerne for kundeorganisationer, som de administrerer. De bør kun gøre krav på domænerne for de brugere, Tjenesteudbyder er i deres interne organisation. Krav på domænet for brugere i en separat organisation (selv en, som Tjenesteudbyder administrerer) kan resultere i tilmeldingsfejl for brugerne i kundeorganisationen, når brugerbekræftelsesanmodninger bliver dirigeret gennem Tjenesteudbyder i stedet for kundeorganisationen.
• Hvis to kundeorganisationer (virksomhed A og virksomhed B) deler det samme domæne, og virksomhed A har gjort krav på domænet, kan tilmelding til virksomhed B-brugere mislykkes, fordi anmodninger om brugerbekræftelse dirigeres gennem den organisation, der har domænet gjort krav på (virksomhed A).

  Hvis du gør krav på nogle domæner ved en fejl og har behov for at fjerne et krav, kan du se, hvordan du administrerer dine domæner i Webex-artiklen.

Slutbrugerfejlkoder

Følgende tabel giver en oversigt over slutbrugerfejlkoder, der kan ses i kundens aktiveringsportal.

Fejlkoder for Directory Sync

Følgende fejlkoder gælder for adressebogssynkronisering.