Tack för din feedback.

Den här artikeln är avsedd för tekniskt supportteam på tjänsteleverantörsorganisationen som stöder sig själva och sina kunder. De bör vara bekanta med allmän felsökning, läsa loggar och arbeta med abonnentärenden.

Denna artikel är indelad i tre huvudavsnitt:

• Resurser — innehåller en lista över verktyg, läsmaterial, loggar och kontakter du kan behöva.
• Processer — beskriver några av de åtgärder du kan vidta när du felsöker ett kundproblem.
• Specifika problem — kategoriserar och listar problem som man vet har inträffat, hur man upptäcker dem och hur du eventuellt kan lösa dem.

Användbara loggfiler

Läslista

• Webex för Cisco BroadWorks Partner Knowledge Portal
• Konfigurationsguide för XSP-plattformen (R23)
• BroadWorks programvaruhanteringsguide (R23)
• Konfigurationsguide för Cisco BroadWorks enhetshantering (R23)
• Administrationshandbok för Broadworks Xsp kommandoradsgränssnitt
• Funktionsbeskrivning för långlivad autentiseringstoken Release 23.0
• Integrationsguide för SAML-autentisering, R23
• Handbok för Cisco BroadWorks SSL Supportalternativ
• Beskrivning av Cisco CI Support
• Notification Push Server (funktionsbeskrivning)
• Stöd för push-meddelanden för samtal Funktionsbeskrivning Release 22.0
• Anslut (Android) Migrering till Firebase Procedurmetod
• Cisco BroadWorks Lagring av enhetstoken för push-meddelanden Funktionsbeskrivning Release 22.0
• Cisco BroadworksSystemkapacitetsplanerare (kalkylblad)
• Cisco BroadWorks-plattformsdimensioneringsguide
• Cisco Broadworks systemteknikguide
• Krav på stöd för CI-autentisering Dokument Version 1.0 MR-7136

Kända problem och begränsningar

Artikeln Kända problem och begränsningar innehåller aktuell information om kända problem som vi har identifierat i Webex för BroadWorks-lösningen.

Servicevänlighetsanslutning

Tjänsten Webex Serviceability ökar hastigheten med vilken Ciscos tekniska assistanspersonal kan diagnostisera problem med infrastrukturen. Det automatiserar uppgifterna att hitta, hämta och lagra diagnostiska loggar och information i ett SR-fall. Tjänsten utlöser också analys mot diagnostiska signaturer så att TAC effektivare kan identifiera och lösa problem med din lokala utrustning.

Mer information om hur du distribuerar Serviceability-anslutningen finns i Distributions guide för Cisco Webex Serviceability Connec tor.

Eskalera ett problem

När du har följt några av felsökningsriktlinjerna bör du ha en rimlig uppfattning om var problemet är rotat.

Förfarande

1. Samla in så mycket information som möjligt från systemen relaterade till problemet.
2. Kontakta lämpligt team på Cisco för att öppna ett ärende.

Vilken kundinformation som ska samlas in

Om du tror att du behöver öppna ett ärende eller eskalera ett problem samlar du in följande information medan du felsöker med användaren:

• Användaridentifierare: CI-e-postadress eller användar-UUID (detta är Webex-identifieraren, men om du också får användarens BroadWorks-identifierare, inkludera den i ärendeinformationen).
• Organisationsidentifierare.
• Ungefärlig tidsram under vilken problemet upplevdes.
• Klientplattform och version.
• Skicka eller samla in loggar från klienten.
• Registrera spårnings-ID om det visas på klienten.

Kontrollera användaruppgifter i Help Desk

Partneradministratörer som har rollbehörighet för Help Desk Administrator (Basic eller Advanced) kan använda den här proceduren för att kontrollera användarinformation i Helpdesk-vyn.

Förfarande

1. Logga in på Help Desk.
2. Sök efter och klicka sedan på användaren. Detta öppnar skärmen för användarsammanfattning.
3. Klicka på användarnamnet 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 App-kluster, Samtalsbeteende, BroadWorks-konto GUID
4. Klicka på Kop iera om du behöver använda den här informationen i ett annat verktyg, eller bifoga den till ett Cisco-fodral.

Visa kundorganisation i Help Desk

Partneradministratörer som har rollbehörighet för Help Desk-administratör (grundläggande eller avancerad) kan använda den här proceduren för att visa information om kundorganisationen i Helpdesk-vyn.

Förfarande

1. Logga in på Help Desk.
2. Sök efter och klicka sedan på kundorganisationens namn.
3. Rulla nedåt tills du ser Kundportalvyn och klicka på Visa kundnamn för att se en skrivskyddad vy av kundorganisationen — inklusive användare och konfiguration.

Hämta användarloggar från Partner Hub

Vid felsökning av problem med stationära och mobila klienter är det viktigt att Partners (och TAC) kan visa klientloggar.

Förfarande

1. Be användaren att skicka loggar. För hjälp, se: Webex-appen | Rapportera ett problem.
2. Be användaren att exportera samtalsmiljön och skicka dig filen ced.dat.
3. Hämta klientloggar från Partner Hub eller Help Desk.

   Alternativ för Partner Hub:

   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 ladda ner klientloggar som en zip-fil.

   Helpdesk-alternativ:

   1. Logga in på Help Desk.
   2. Sök efter organisationen.
   3. Klicka på organisationen (öppnar sammanfattningsskärmen).
   4. Bläddra ner 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 ladda ner klientloggar som en zip-fil.

Hur man hittar klientversion

Förfarande

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 för samtalstjänst

Förfarande

1. Logga in på Webex-klienten.
2. Kontrollera att ikonen Samtalsalternativ (en handenhet med ett kugghjul ovanför) finns i sidofältet. Om ikonen inte finns kanske användaren ännu inte är aktiverad för samtalstjänsten i Control Hub.
3. Öppna menyn Inställningar/In ställningar och gå till avsnittet Telefontjänster. Du bör se stat usen SSO-session Du är inloggad. (Om en annan telefontjänst, till exempelWebex Calling, visas, använder användaren inte Webex för Cisco BroadWorks.)

   Denna verifiering innebär:

   • Klienten har framgångsrikt korsat de nödvändiga Webex-mikrotjänsterna.
   • Användaren har lyckats autentisera.
   • Klienten utfärdas en långlivad JSON-webbtoken av ditt BroadWorks-system.
   • Klienten har hämtat sin enhetsprofil och har registrerat sig på BroadWorks.

Få klientloggar eller feedback

• Se avsnittet Resurser för att hitta specifika klientloggar på Webex-skrivbordsklienter, eller be användare att skicka loggar. För hjälp, se: Webex-appen | Rapportera ett problem.
• Be användare av mobilklienter att skicka loggar, så kan du få dem via Partner Hub eller Help Desk.
  Skicka loggar är tyst. Men om en användare skickar feedback går den till Webex App devops-teamet. Var noga med att registrera användarens feedbacknummer om du vill följa upp med Cisco. Till exempel:

  

Hämta samtalsmiljödata

Webex-klientloggar redigeras kraftigt 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.

Förfarande

1. Klicka på Hjälp > Hälsokontroll på klienten.
2. Välj Återställ databas. Detta utlöser en fullständig återställning av klienten och laddar inloggningsskärmen för Webex App.

Kontrollera att Webex ska registrera sig på BroadWorks

Webex-appen kontrollerar följande information för att avgöra om du vill registrera dig på BroadWorks:

• Användarrätt till broad works-connector.
• Anropsbeteende för organisation och användare.

Kontrollera användarens samtalsbeteende och anslutningsbehörighet

1. Logga in på Help Desk med dina partneradministratörsuppgifter.
2. Sök efter användaren.
3. Klicka på användaren och kontrollera posten Samtalsbeteende. Det borde vara ”Calling in Webex”.

   

4. Klicka på användarnamnet för att öppna skärmen Användarinformation.
5. Bläddra nedåt för att hitta behörighets sektionen och kontrollera att broadworks-connector ingår

   

   En Webex för Cisco BroadWorks-användare bör inte ha bc-sp-standardrättigheten om de avser att använda Webex för Cisco BroadWorks. Detta är rättigheten för ”Webex Calling(Broadcloud)” som är Webex App-samtal via en Cisco-hanterad molnsamtalstjänst.

Kontrollera organisationens samtalsbeteende

1. Logga in på Help Desk med dina partneradministratörsuppgifter.
2. Sök efter organisationen.
3. Klicka på organisationen och kontrollera posten Sam talsbeteende. Det borde vara ”Calling in Webex”.

Analysera PSLog för problem med användarprovisionering

Använd programserverns PSlog för att se HTTP POST-begäran till etableringsbryggan och svaret från Webex. I ett korrekt fungerande fall är svaret 200 OK och efter några minuter kan du se användaren - och ny kundorgan om det är första användaren - har skap ats i Webex. Du kan verifiera detta genom att söka i Help Desk efter den e-postadress du ser i POST.

Innan du börjar

Samla in en PSlog från programservern under ett genomflödesprovisioneringsförsök med en testanvändare.

Förfarande

1. Kontrollera först HTTP-svarskoden:
   • Allt annat än 200 OK är ett användaretableringsfel.
   • 200 OK kan fortfarande indikera ett fel om något om abonnentprofilen inte fungerar i Webex-tjänsterna uppströms om provisioneringsbryggan.
   • 400 kan innehålla en meddelan de-nod i svaret. Tilldelningsbryggan kunde inte bearbeta något i Subscri ber Profile. Det kan vara något fel med abonnentinformationen eller inkompatibilitet med en inställning i mallen.
   • 401 innebär att de etableringsuppgifter som anges i AS inte matchar dem som anges i mallen i Partner Hub.
   • 403 kan indikera något felkonfigurerat på Application Server. Kontrollera målet för förfrågan. det ska inte vara en IP-adress, det ska vara den etableringsbrygga URL som du kan se på din mall i Partner Hub.
   • 409 indikerar en konflikt mellan den medföljande Subscri berProfile och befintliga Webex-data. Det kan finnas en befintlig användare med den e-postadressen. Kontrollera meddelandet i svaret.
2. Du kan också kontrollera det ursprungliga HTTP POST för eventuella misstänkta värden som kan orsaka att etableringen misslyckas. POST innehåller en Subscri berProfile XML- struktur. Inuti detta är användbara noder att kontrollera:
   • bwuserid: Använd detta för att hitta abonnentprofilen om du behöver redigera den i BroadWorks.
   • group: Om mallen är i ”Service Provider Mode” skrivs detta med små bokstäver och blir namnet på den kundorgan som du ser i Partner Hub.
   • ServicePro vider: Om mallen är i ”Enterprise-läge” skrivs detta med små bokstäver och blir namnet på den kundorgan som du ser i Partner Hub.
   • PrimaryPhoneNumber: Måste finnas. Tillhandahållande misslyckas utan det.
   • e-post: Blir användar-ID i Webex. Måste vara giltig och unik för Webex, annars misslyckas etableringen.

     Ignorera tjänst strofen: den skapas av AS och accepteras men används inte av Webex.

Analysera XSP-loggar för att felsöka abonnentinloggning

Detta flöde beskriver BroadWorks autentiseringsläge. Du kan se autentiseringsläget på Broad Works-mallen i Partner Hub. Se Konfigurera dina kundmallar på https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Följande stegdiagram visar interaktionen mellan användaren, klienten, Webex-tjänsterna och BroadWorks-systemet när användaren utför BroadWorks-autentisering i Webex-appen. Dessutom är anslutningen mellan Webex och XSP säkrad 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 en lyckad inloggning.

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

• Användaren anger sin e-postadress till Webex-appen (1 i diagram).
• CI vet att omdirigera den här användaren för att ange sitt BroadWorks-lösenord (via UAP) (2 i diagram).
• IDP-proxyservern skickar en begäran om hämtningsprofil till Xsi-gränssnittet på XSP.

I tomcat access_log:

• Leta efter GET-förfrågan för abonnentprofilen, från Webex mot Xsi-Actions-gränssnittet (2.1 i diagram). Den har Webex användar-ID. Till exempel:

  SKAFFA /com.broadsoft.xsi-actions/v2.0/användar/ webexuserid@example.com /profil

I XSIActionsLog:

• Leta efter profilen GET-förfrågan från Webex (2.1 i diagram). Den har Webex användar-ID. Till exempel:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Rubrikerna inkluderar behörighet: Basic och user-agent: BroadworkSteamsClient

• XSP gör sedan OCI-P Basic-autentisering mot BroadWorks (AuthenticationVerifyRequest och AuthenticationVerifyResponse, som alla andra applikationer som gör grundläggande autentisering via Xsi) och även en UserGetRequest och ServiceProviderGetRequest för att samla in abonnentinformationen.
• Xsi-svaret på Webex innehåller ett XML- profil block som innehåller (BroadWorks) användar-ID och andra detaljer (2.2 i diagram).

Interaktioner mellan klient- och Webex-tjänster:

• IDP-proxy matchar användarprofilen som mottagits från BroadWorks och utfärdar SAML-påstående till klienten (2.3 i diagram).
• Klienten utbyter SAML-påstående mot en CI-token (3 i diagram).
• Klienten kontrollerar att den inloggade användaren har broadworks-connector-behörigheten (4 i diagram). Du kan kontrollera användarrättigheter i Help Desk.
• Klienten använder CI-token för att begära en JSON Web Token (JWT) från IDP-proxy (5 i diagram).
• IDP-proxy validerar CI-token vid CI.
• IDP-proxy begär JWT från autentiseringstjänsten.

I AuthenticationService-loggen:

• Leta efter tokenförfrågan från Webex (5.2 i diagrammet), Till exempel: GET /AuthService/token som har http _bw_userid-rubri k och andra.
• XSP gör OCI-P UserGetLoginInForequest, för att bekräfta att det angivna användar-id motsvarar en BroadWorks- användare (5.3 i diagram). AuthService har etablerat förtroende för Webex på grund av MTLS-anslutningen, så kan utfärda LLT.
• Leta efter svaret (5.4 i diagram) från LongLivedTokenManager - Token genererad, ämne: bwksUserId@example.com, utfärdare: BroadWorks... och statusCode=200 som du kan associera med den ursprungliga begäran med hjälp av trackingid: CLIENT... header.

I XSIActionsLog:

• Klienten kan presentera den långlivade token vid Xsi-Actions-gränssnittet för att få sin enhetsprofil (6 i diagram). Till exempel: GET /com.broadsoft.xsi-actions/v2.0/user/bwksuSerid %40example.com/profile/device Med rubrikerna behörighet: Bärartoken och användaragent: WebExTeams (variant/version)
• Xsi-Actions-gränssnittet POSTAR token till authservice (konfigurerad att vara på loopback-gränssnittet) Till exempel: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token som du kan korrelera med trackingid: CLIENT... header i GET och X-BROADSOFT-CORRELATION-ID: CLIENT... header i POST.

I AuthenticationService-loggen:

• Kvittot på POST från Xsi (loopback)

• A StatusCode=200 tillbaka till Xsi

• Och ett tokenvalideringssvar, med ett "token" JSON-block i kroppen.

• Korrelerad med hjälp av trackingid: CLIENT...

I XSIActionsLog:

• Efter att ha fått 200 OK från authservice, som validerade klientstoken, skickar Xsi-Actions-applikationen nu OCI-P-begäran för UserPrimaryAndScaDeviceGetListRequest
• Tar emot OCI-P UserPrimaryAndSc adeviceGetListResponse som innehåller XML-strukturen AccessDeviceTable.
• OCI-P-svaret kodas som Xsi-svar till klienten, inklusive AccessDevices XML-struktur, som har DeviceTypes. Till exempel: Business Communicator - PC och webbadresserna där klienten kan hämta enhetens konfigurationsfiler.

Klienten fortsätter som vanligt:

• Väljer en enhetspost och interagerar med DMS för att få enhetsprofil (6 i diagram).
• Registrerar till BroadWorks via SBC hämtad i konfiguration från DMS (7 i diagram).

Problem med Partner Hub

1. Administratören kan inte se kundorganisationer

Som administratör för din partnerorganisation i Webex bör du ha rollen Fullständig administratör. Den rollen används för att hantera din partnerorganisation, inklusive tilldela administratörsbehörighet till dig själv och andra. Om du vill hantera kundorganisationer måste du ge dig själv (eller andra personer) rollen För säljningsadministratör eller rollen För säljningsadministratör. Mer information finns i Tilldela organisationskontoroller i Control Hub.

Problem med användarprovisionering

1. Integrerade IM&P-fel för specifika företag/kunder

Om du har en blandning av företag som använder olika molnsamarbetstjänster, till exempel UC-One SaaS och Webex för Cisco BroadWorks, kan du ha valt att ändra provisioneringsadaptern per företag.

Om du vill kontrollera vad som är konfigurerat för Integrerad IM&P (standard för företag, såvida inte en mer specifik inställning finns), kör AS _CLI/Interface/Messaging> get. För ett visst företags provisioneringsparametrar öppnar du företaget och går till Tjän ster > Integrerad IM&P.

Kontrollera att den integrerade IM&P-konfigurationen för företaget matchar exakt vad som visas i kundmallen i partnerhubben. Följande inställningar måste matcha, annars misslyckas etableringen för alla användare i företaget:

2. Integrerade IM&P-fel för specifika användare

Detta gäller om du använder genomflödesprovisionering och förutsätter att provisionering fungerar för vissa eller de flesta användare (så att du kan utesluta ett konfigurationsproblem). Om du ser integrerade IM&P-fel i BroadWorks, till exempel ”[Error 18215] Provisioning error with Messaging server” och ”[Fel 18211] Kommunikationsfel med meddelandeservern”, bör du undersöka följande potentiella orsaker:

• Användarens e-postadress kan redan existera CI. Sök efter användaren i Help Desk för att kontrollera om deras e-postadress redan finns där. Detta är inte nödvändigtvis avgörande, eftersom användaren kan finnas i en organisation vars data du inte får se i Help Desk.
• Användaren registrerade sig självständigt på Webex innan den tilldelades den integrerade IM&P-tjänsten. I det här fallet är ett alternativ att låta användaren ta bort sina gratiskonton så att de kan bli en del av den kundorganisation du tillhandahåller. Instruktioner finns på https://help.webex.com/5m4i4y
• Användaren har inget primärt telefonnummer tilldelat sin profil (alla Webex för Cisco BroadWorks-abonnenter måste ha en primär DID). Se ämnet om analys av PSlog från AS.

3. Fel vid tillhandahållande av användare som svar från provisi oneringsbryggan

Om användare inte visas i Control Hub, inom några minuter efter att ha tilldelat integrerad IM&P, kan du titta på svarskoderna från provisioneringsbryggtjänsten. Kör en PSlog för att titta på HTTP-svarskoderna.

200 OK

Ett svar på 200 OK betyder inte att användaren har klargjorts. Det betyder att provisioneringstjänsten tog emot begäran och skickade in motsvarande begäran om skapande av användare till uppströmstjänster. Tilldelningstransaktionen är asynkron av design. Tjänsten svarar 200 OK eftersom processen för att skapa användare kan ta flera minuter och av prestandaskäl vill vi inte ta emot flera förfrågningar om att skapa samma användare. Men om användaren inte så småningom visas i kundorganisationen efter ett 200 OK-svar kan det indikera att användarskapandet misslyckades i Webex-tjänsterna uppströms för provisioneringstjänsten. Du måste eskalera ett etableringsfel som har ett svar på 200 OK.

400 Dålig begäran

Kontrollera HTTP-svaret som borde ha mer information om potentiella problem som kan orsaka detta svar från provisioneringstjänsten. Några exempel på noden:

• ”Det går inte att lita på BroadWorks e-post med äldre API för provisionering.” E-postadressen som är kopplad till den misslyckade begäran om tillhandahållande av användare är ogiltig eller har skrivits felaktigt, men du har hävdat i mallen att e-postadresserna kan vara betrodda. Kontrollera användarnas profiler i BroadWorks, särskilt e-post-id.
• Kundorgan finns inte i databasen och flaggan för skapande av ny organisation är inte aktiverad.” Den här misslyckade etableringsbegäran bör skapa en ny kundorganisation i Webex, men mallen är konfigurerad för att förhindra att nya kundorganisationer skapas. Om du vill tillåta nya organisationer, för e-postdomäner som inte matchar befintliga kunder i Webex, kan du konfigurera om mallen i Partner Hub och testa om etablerings begäran. Men om du inte förväntar dig att en ny organisation ska skapas för den här användaren kanske e-postadressen är felskriven (särskilt domändelen). Kontrollera användar ens e-post-id i BroadWorks.

403 Förbjuden

Tilldelningsbegäran kan inte lyckas förrän du har åtgärdat konfigurationen. Du måste undersöka begäran och svaret i det här fallet. Om du till exempel ser en IP-adress som mål för etableringsbegäran — i stället för lämplig URL för etableringsbryggan för organisationen (se avsnittet om brandväggskonfiguration i lösningsguiden) — kan det indikera att programservern saknar en nödvändig patch (ap373197).

Kontrollera att alla nödvändiga korrigeringsfiler tillämpas på programservern och att du har slutfört den relaterade konfigurationen för framgångsrik genomflödesprovisionering.

409 Konflikt

Tilldelningsbegäran kan inte fortsätta eftersom det finns en befintlig användare i Webex som matchar e-postadressen i begäran.

4. Användare Redan i CI

Hämta abonnentens e-post från HTTP POST-förfrågan och sök efter det i Help Desk. Du kanske inte ser användaren om du inte är tillåten, men du kan också se att användaren är i en ”fri” organisation t.ex. ”Konsument”. Du kan be den här användaren att ta bort sitt gratis konto, eller så kan du använda en annan e-postadress för att tillhandahålla dem. Se https://help.webex.com/ndta402.

Problem med användarinloggning

1. Användaraktiveringsportalen laddas inte

Det normala inloggningsflödet för Webex för Cisco BroadWorks inkluderar en användaraktiveringsportal där användare anger sina lösenord. Ibland laddas inte den här portalen efter att användaren har angett sin e-postadress i inloggningsskärmen för Webex App. Detta problem kan orsakas på klientsidan eller på servicesidan. På klientsidan orsakas det vanligtvis av att klientens inbyggda webbläsare är inkompatibel på något sätt med tjänsten.

2. Enkel inloggning misslyckades

• Kontrollera att användaren har tilldelats enhetstyperna för Webex-appen i BroadWorks (se avsnittet Enhets profiler i avsnittet Förbered din miljö i lösningsguiden).
• Kontrollera att användaren använder rätt lösenord. Om mallen som du använde för att tillhandahålla användarens kundorganisation (i Partner Hub) är konfigurerad för BroadWorks- autentisering, bör användaren ange sitt BroadWorks ”Web Access” -lösenord. Använ daren kan också behöva ange sitt BroadWorks användar-ID om deras e-postadress inte är konfigurerad som ett alternativt användar-ID. Kontrollera att användaren har skrivit in versaler och gemener korrekt.

Anropskonfigurations- och registreringsproblem

När en användare har etablerats i Webex och de har loggat in på Webex-appen registrerar appen sig på BroadWorks. Följande är den förväntade registreringssekvensen och de resulterande tecknen på en hälsosam registrering (sett från Webex-appen):

1. Förväntad registreringssekvens

1. Klienten ringer XSI för att få en enhetshanteringstoken och webbadressen till DMS.
2. Klienten begär sin enhetsprofil från DMS genom att presentera token från steg 1.
3. Klienten läser enhetsprofilen och hämtar SIP-autentiseringsuppgifter, adresser och portar.
4. Klienten skickar ett SIP-REGISTER till SBC med hjälp av informationen från steg 3.
5. SBC skickar SIP-REGISTER till AS (SBC kan utföra en sökning i NS för att hitta ett AS om SBC inte redan känner SIP-användaren.)

2. Förväntade tecken på framgångsrik kundregistrering

Ikonen för samtalsalternativ visas i Webex-gränssnittet.

På fliken Telefontjänster i Webex App (t.ex. Inställningar > Telefontjänster i Windows, In ställningar > Telefontjänster på Mac) betyder meddelandet ”SSO-session: Du är inloggad” att appen har registrerats framgångsrikt (i det här fallet till BroadWorks).

3. Klienten har ingen samtalsik on

För det mesta betyder detta att användaren inte har rätt licens/rättigheter.

Detta är en misslyckad registrering. Det finns flera anledningar till varför en Webex App-klient misslyckas med att registrera sig med BroadWorks:

4. Flera samtalstjänster testas med samma klienter

Det här kända problemet kan orsakas av att klienten byter mellan olika uppringningsenheter. Det är mest troligt att det inträffar under försök av olika samtalstjänster som erbjuds via (samma) Webex App-klienter. Du kan återställa klientdatabasen (länk) för att åtgärda problemet.

5. Felaktig konfiguration av autentiseringstjänsten

Kontrollera XSP (erna) som är värd för autentiseringstjänsten mot lösningsguiden (se Konfigurera tjänster på din Webex för Cisco BroadWorks XSP). Specifikt:

• RSA-nycklarna (som du genererar på en XSP) kopieras till alla XSP: er
• Autentiseringstjänstens URL har tillhandahållits till webbbehållaren på alla XSP:er och har matats in korrekt i klustret i Partner Hub
• Extern autentisering med certifikat är konfigurerad:

  xsp_CLI/System/Kommunikationsverktyg/Standardinställningar/ExternalAuthentication/Certificate Authentication>GET

  allowUserApp = false

  allowClientApp = true

• När du använder MTLS måste du ladda upp Webex-klientcertifikatet till XSP: erna (du kan hämta certifikatet från Partner Hub, på sidan BroadWorks Settings).

6. Felaktig konfiguration av BroadWorks-taggar

Kontrollera att du har konfigurerat de nödvändiga BroadWorks-taggarna för Webex-appen. Mer information om konfigurationstaggar finns i konfigurationsguiden för Webex för Cisco BroadWorks. Se till att det inte finns några konflikter eller felaktiga värden. Specifikt bör taggen %SBC_ADDRESS_WXT% vara SBC mot din SIP-registrar för Webex App-klienter.

7. Skrivbordsklienten kopplar bort telefontjänster efter framgångsrik SSO-anslutning

Problemet kan orsakas av att samma användare loggar in på flera klienter på samma plattformstyp. Om en användare till exempel loggar in på Webex-appen i Windows och sedan loggar in på Webex-appen på en annan Windows-dator finns det bara en aktiv SSO-session på en av datorerna. Detta är av design. Om du absolut behöver lösa problemet kan du konfigurera BroadWorks för att ha flera instanser av samma enhetstyp, men de måste ha unika SIP-adresser. Den här konfigurationen ligger utanför räckvidden för Webex för Cisco BroadWorks.

8. Stationär enhet som inte är etablerad för användaren

Denna signatur syns i klientloggen:

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

onAccessDeviceListSucceded:bwc:scf: configDownload - enhetsprofilen 'Business Communicator - PC' hittades inte.

9. Inkommande mobilsamtal ringer en gång eller kan inte besvaras

Inkommande samtal till Webex mobil ringer bara en gång, eller så kan användaren inte svara på det inkommande samtalet. Andra slutpunkter för samma användare kan fortsätta att ringa.

Hur identifierar man?

I Webex mobilklientloggar letar du efter XSI-felkod 101002 i push-samtalsflödet. Till exempel:

Svarskod: 400

<callID>handlePushCallInfoFailure:bwc:Internal: Push-anrop: xsi-status för callID: xsi felkod: 101002

<callID>ClosePushCallWithReason:bwc:Internal: Försök att stänga push-samtal med id =, reason = callAbandoned

Orsak: Felkod 101002 kan indikera att fel Application Server (AS) returneras i Loc ateUser-svaret. Detta kan hända när användaren har migrerat till ett sekundärt AS.

Rekommenderade kontroller:

Från ADP eller XSP där Push distribueras kör du LocateUser för den berörda användaren:

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

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

Lösning: Om LocateUser returnerar det sekundära AS för användaren kör du skriptet MigrateUserToDefaultNode.pl på den primära NS-servern för att migrera användare tillbaka till klustrets primära programserver.

Logga in på NS-servern via SSH, gå till /usr/local/broadworks/bw_base/bin katalogen och kör: migrateU serToDefaultNode.pl <hostingNE>

Exempel: Migrate UserToDefaultNode.pl bwas1

För att få HostingNE- värdet, kör: NS_CLI/System/Device/Hostingne> get

Skriptet kontrollerar först om det kan hitta värdtjänstens NE som du anger som argument. När den har verifierat att värdtjänstens NE är giltig uppdaterar den DN, tillägg och URL till standardnoden för den värdtjänstens NE.

Kör skriptet under en period med låg trafik när det är möjligt. Det är dock allmänt acceptabelt att köra skriptet när som helst om det behövs för att återställa tjänsten för drabbade användare.

Skriptet kan inte köras endast för en enskild användare. Det migrerar alla användare som listas i Locate User-utdata. Om du inte kan köra skriptet tar du bort och bygger om den berörda användaren i BroadWorks så att användaren byggs om på rätt AS.

Alla SIP-meddelanden från användarenheten till det sekundära AS kan leda till att användaren migrerar. Användare rullar vanligtvis tillbaka till det primära AS efter standardintervallet på 15 minuter såvida inte inkommande förfrågningar fortsätter att nå det sekundära AS. Om SBC till exempel inte kan ansluta till AS1 och återgår till det sekundära AS kan berörda användare byta till det sekundära AS. Beroende på distributionen kan en enda trunkgrupp eller användare förbli fäst vid det sekundära AS om SBC fortsätter att ha problem med att nå det primära AS.

Mer information finns i följande dokument:

• Avsnitt 3.4.5 Funktion för återställning av applikationsserveranvändare och 5.4.5 Automatisk återställning i Cisco BroadWorks Redundancy Guide

• Cisco BroadWorks ASR Förbättringar Funktionsbeskrivning

9. Telefontjänster frånkopplade

Om telefontjänster visas som frånkopplade efter att användaren loggar in på Webex-appen, eller om telefontjänster kopplas bort medan användaren använder klienten, kontrollera klienttyp och registreringsflöde.

För Windows- och Mac-klienter registrerar Webex App för SIP och behåller en aktiv SIP-registrering medan användaren är inloggad.

Kontrollera följande:

1. Kontrollera att config-wxt.xml har laddats ner framgångsrikt.

Sök efter ConfigDownload i klientloggarna.

En lyckad nedladdning visar:

ConfigDownload - slutfördes framgångsrikt

Om loggarna visar följande fel kontrollerar du om det finns tokenrelaterade fel i AuthService-loggarna:

ConfigDownload - misslyckades med felkod: 1511

2. Kontrollera att Webex-enhetsprofilen hittas.

Bekräfta i klientloggarna att åtkomstenheten har hittats och att used_value är 1. Om used_value är 0 kontrollerar du om Primär linje är aktiverad eller inaktiverad och verifierar taggvärdet. Mer information finns i avsnitt 6.1.44 Primär profil i konfigurationsguiden för Webex för BroadWorks.

Exempel på loggposter:

:BWC:SCF: configDownload - åtkomstenhet hittades

:BWC:SCF: configDownload - åtkomstenhet: DeviceType=Business Communicator - PC, DeviceLevel=grupp, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Delat samtalsutseende

:BWC:SCF: configDownload - åtkomstenhet: DeviceType=Anslut - Mobil, DeviceLevel=grupp, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Delat samtalsutseende

:BWC:SCF: configDownload - åtkomstenhet: DeviceType=Anslut - Surfplatta, DeviceLevel=grupp, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Delat samtalsutseende

3. Kontrollera om det finns DNS-fel när du löser SIP-proxyadressen.

Mer information om identifiering av SIP-proxy finns i avsnitt 6.1.6 Dynamisk SIP-proxyidentifiering i konfigurationsguiden för Webex för BroadWorks.

En framgångsrik proxyupptäckt visar:

Proxyupptäckten är klar, fick <number>resultat

4. Kontrollera om SIP-registreringen misslyckas.

Om loggarna visar MRegistration: TCPTimeout eller Reason: SIP; cause=200; text="last=TCP-timeout” kan Webex-klienten inte upprätta en TCP-anslutning på låg nivå till SBC. SIP-registreringen slutförs inte när det här felet inträffar. Kontrollera om TCP är blockerad i användarens nätverk eller om SBC avvisar TCP-anslutningen.

Om SIP REGISTER-begäran avvisas eller inte får något svar söker du efter REGISTER sip i loggarna och kontrollerar att SIP/2.0 200 OK returneras. Om det inte returneras kontrollerar du om användarens nätverk blockerar SIP eller om SBC avvisar begäran.

Gå till Använ dare > Verktyg > Registreringar i BroadWorks Admin och kontrollera att en giltig SIP-registrering finns för Webex-klienten.

För Android- och iOS-mobilklienter registrerar Webex-appen inte för SIP förrän ett samtal görs eller tas emot. Registreringen tas bort när samtalet är klart. Mobilklienter registrerar sig för push-aviseringar.

För mobila klienter, kontrollera följande:

1. Kontrollera att config-wxt.xml hämtas framgångsrikt och att enhetsprofilen hittas, enligt beskrivningen för Windows- och Mac-klienter.

2. Kontrollera att push-registreringen lyckas.

I Webex-loggarna letar du efter push-registreringsläget:

OnPushRegistrationStateChanged: :Push-registreringsläget ändrat, state=Oregistrerad

OnPushRegistrationStateChanged: :Push-registreringsstatus ändrat, state=registrerad

Gå till Använ dare > Verktyg > Registreringar för push- meddelanden i BroadWorks Admin och kontrollera att en giltig push-registrering finns för Webex-klienten.

Problem med webbvyn för samtalsinställningar

1. Självvårdsknappen/länk visas inte i Webex-appen

Ett annat symptom på problemet är när knappen/länken visas, men om du klickar på den öppnas en extern webbläsare.

• Kontrollera att den önskade klientkonfigurationsmallen är distribuerad och att CSW-taggar är korrekt inställda. (Se avsnittet Webb vy för samtalsinställningar i lösningsguiden för Webex för Cisco BroadWorks).
• Kontrollera att Webex-appen är registrerad för samtal i BroadWorks.
• Kontrollera att Webex-appen är en ny version som stöder CSWV.

2. Tom sida eller fel efter att ha klickat på Self Care-knappen/länk

I allmänhet indikerar detta beteende i Webex-appen ett konfigurations- eller distributionsproblem med CSWV-programmet på BroadWorks XSP. Samla in information för vidare utredning, inklusive CSWV-loggar, åtkomstloggar, config-wxt.xml arkiv och mallfil, och ta sedan upp ett ärende.

Problem med domänanspråk

Användarregistreringsfel kan uppstå som ett resultat av fel som görs vid anspråk på domäner. Innan du gör anspråk på några domäner, se till att du förstår följande:

• Tjänsteleverantörer bör inte göra anspråk på domänerna för kundorganisationer som de hanterar. De bör endast göra anspråk på domänerna för de användare som finns i tjänstel everantörens interna organisation. Att göra anspråk på domänen för användare i en separat organisation (även en som tjänsteleverantören hanterar) kan resultera i registrerings fel för användarna i kundorganisationen eftersom begäranden om användarautentisering dirigeras via tjänsteleverantören i stället för kundorganisationen.
• Om två kundorganisationer (Företag A och Företag B) delar samma domän och Företag A har gjort anspråk på domänen kan registreringen för företag B-användare misslyckas på grund av att användarautentiseringsbegäranden dirigeras genom den organisation som har domänen begärt (Företag A).

  Om du gör anspråk på några domäner av misstag och behöver ta bort ett anspråk läser du artikeln Hantera dina domäner Webex.

Felkoder för slutanvändare

Följande tabell beskriver slutanvändarens felkoder som kan visas i klientanvändar aktiveringsportalen.

Felkoder för katalogsynkronisering

Följande felkoder gäller för katalogsynkronisering.