Tack för din feedback.

Den här artikeln är avsedd för teknisk support på tjänsteleverantörsorganisationer som stöder sig själva och sina kunder. De bör vara bekanta med allmän felsökning, läsning av loggar och arbete med prenumerantärenden.

Den här artikeln är indelad i tre huvudavsnitt:

• Resurser – innehåller en lista över verktyg, läsmaterial, loggar och kontakter som du kan behöva.
• Processer – beskriver några av de åtgärder du kan vidta vid felsökning av ett kundproblem.
• Specifika problem – kategoriserar och listar problem som har varit kända för att uppstå, hur man upptäcker dem och hur man potentiellt kan lösa dem.

Användbara loggfiler

Läslista

• Webex för Cisco BroadWorks Partnerkunskapsportal
• Konfigurationsguide för XSP-plattform (R23)
• BroadWorks programvaruhanteringsguide (R23)
• Konfigurationsguide för Cisco BroadWorks-enhetshantering (R23)
• Administrationsguide för Broadworks Xsp-kommandoradsgränssnittet
• Beskrivning av lång autentiserad autentiseringstoken, version 23.0
• Integrationsguide för SAML-autentisering, R23
• Guide till supportalternativ för Cisco BroadWorks SSL
• Beskrivning av funktioner för Cisco CI-support
• Aviseringsserver för push (funktionsbeskrivning)
• Stöd för push-avisering vid samtal, funktionsbeskrivning version 22.0
• Anslut (Android) migrering till Firebase metod
• Cisco BroadWorks-lagring av enhetstokens för push-meddelanden Funktionsbeskrivning Version 22.0
• Cisco BroadWorksSystemkapacitetsplanerare (kalkylblad)
• Dimensioneringsguide för Cisco BroadWorks-plattformen
• Guide för systemutveckling i Cisco Broadworks
• Krav 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.

Kontakt för servicemöjlighet

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

För mer information om hur du distribuerar Serviceability-anslutningen, se Distributionsguide för Cisco Webex Serviceability Connector.

Eskalering av ett problem

När du har följt några av felsökningsråden bör du ha en hyfsad uppfattning om var problemet ligger.

Tillvägagångssätt

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

Vilken klientinformation som ska samlas 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 (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 uppstod.
• Klientplattform och version.
• Skicka eller samla in loggar från klienten.
• Registrera spårnings-ID om det visas på klienten.

Kontrollera användaruppgifter i helpdesk

Partneradministratörer som har behörighet för rollen Help Desk-administratör (grundläggande eller avancerad) kan använda den här proceduren för att kontrollera användarinformation med hjälp av Help Desk-vyn.

Tillvägagångssätt

1. Logga in på 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 och 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

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

Tillvägagångssätt

1. Logga in på Helpdesk.
2. Sök efter och klicka sedan på kundens organisationsnamn.
3. Scrolla ned tills du ser Kundportalvy 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 se klientloggarna.

Tillvägagångssätt

1. Be användaren att skicka loggar. Mer information finns i: Webex-appen | Rapportera ett problem.
2. Be användaren att exportera anropsmiljön och skicka filen ced.dat till dig.
3. Hämta klientloggarna från Partner Hub eller Help Desk.

   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. Scrolla ned 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.

Hur man hittar klientversionen

Tillvägagångssätt

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

Tillvägagångssätt

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, t.ex. Webex Calling med, visas att användaren inte använder Webex för Cisco 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 får en långlivad JSON-webbtoken av ditt BroadWorks-system.
   • Klienten har hämtat enhetsprofilen och har registrerats i BroadWorks.

Hämta klientloggar eller feedback

• Se avsnittet Resurser för att hitta specifika klientloggar på Webex-skrivbordsklienter eller be användare att skicka loggar. Mer information finns i: Webex-appen | Rapportera ett problem.
• Be användare av mobila klienter 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 devops-teamet för Webex-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.

Tillvägagångssätt

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

Verifiera att Webex ska registreras hos BroadWorks

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

• Användarrättighet till broadworks-connector.
• Anropsbeteende för organisation och användare.

Kontrollera en användares samtalsbeteende och anslutningsberättigande

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 ska vara "Ringer i Webex".

   

4. Klicka på användarnamn här sidan för att öppna skärmbilden Användarinformation.
5. Scrolla ned för att hitta avsnittet entitlements och kontrollera att broadworks-connector finns med

   

   En Webex för Cisco BroadWorks-användare bör inte ha behörigheten bc-sp-standard om de avser att använda Webex för Cisco BroadWorks. Detta är behörigheten för "Webex Calling (Broadcloud)", vilket ä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 markera posten Samtalsbeteende. Det ska vara "Ringer i 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 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.

Tillvägagångssätt

1. Kontrollera först HTTP-svarskoden:
   • Allt annat än 200 OK är ett fel vid användareablering.
   • 200 OK kan fortfarande indikera ett fel om något med prenumerantprofilen inte fungerar i Webex-tjänsterna uppströms om provisioneringsbryggan.
   • 400 kan innehålla en message -nod 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 inloggningsuppgifter för provisionering som angetts 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 den angivna subscriberProfile och befintliga Webex-data. Det kan finnas en befintlig användare med den e-postadressen. Markera message i svaret.
2. Du kan även kontrollera original-HTTP POST med alla misstänker värden som kan orsaka att etableringen misslyckas. POST-filen innehåller en subscriberProfile XML-struktur. I detta är användbara noder att kontrollera:
   • bwuserid: Använd denna för att hitta prenumerantens profil om du behöver redigera den i BroadWorks.
   • group: Om mallen är i "Tjänsteleverantörsläge" skrivs detta med gemener och blir namnet på kundorganisationen som du ser i Partner Hub.
   • serviceProvider: Om mallen är i "Företagsläge" är denna i små bokstäver och blir namnet på den kundorganisation du ser i partnerhubben.
   • primaryPhoneNumber: Måste finnas. Etablering misslyckas utan den.
   • email: Blir användar-ID i Webex. Måste vara giltigt och unikt för Webex, annars misslyckas etableringen.

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

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

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 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 klient, klienten interagerar med Webex-tjänster:

• Användaren anger sin e-postadress till Webex-appen (1 i diagrammet).
• CI vet att omdirigering av användaren ska 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 hankatten 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. Till exempel:

  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. Till exempel:

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile Rubrikerna 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 -block som innehåller (BroadWorks) userId och andra detaljer (2.2 i diagrammet).

Interaktioner mellan klienter och Webex-tjänster:

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

I authenticationService-loggen:

• Leta efter tokenbegäran från Webex (5.2 i diagrammet), till exempel: GET /authService/token som har http_bw_userid rubrik och andra.
• XSP:n använder OCI-P UserGetLoginInfoRequestfö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 associera med den ursprungliga begäran med hjälp av rubriken trackingid: CLIENT… .

I XsiActionsLog:

• Klienten kan presentera den långlivade token i Xsi-Actions-gränssnittet för att hämta dess enhetsprofil (6 i diagrammet). Till exempel: GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device Med rubrikerna authorization: Bearer token och user-agent: WebexTeams (variant/version)
• Xsi-Actions-gränssnittet skickar token till authservice (konfigurerat 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… -rubriken i GET och X-BROADSOFT-CORRELATION-ID : CLIENT… -rubriken i POST.

I authenticationService-loggen:

• Post har mottagits från Xsi (loopback)

• En StatusCode=200 tillbaka till Xsi

• Och ett tokenvalideringssvar, med ett "token" JSON-block i brödtexten.

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

I XsiActionsLog:

• Efter att ha mottagit 200 OK från authservice, vilket validerade klientens token, skickar Xsi-Actions-applikationen nu en OCI-P-förfrågan för UserPrimaryAndSCADeviceGetListRequest
• Tar emot OCI-P UserPrimaryAndSCADeviceGetListResponse som innehåller XML-strukturen accessDeviceTable.
• OCI-P-svaret är kodat som Xsi-svar till klienten, inklusive AccessDevices XML-strukturen, som har deviceTypes. Till exempel: 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).
• Register till BroadWorks via SBC hämtade i konfigurationen från DMS (7 i diagrammet).

Problem med Partner Hub

1. Administratören kan inte se kundorganisationerna

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 tilldelning av administratörsbehörigheter till dig själv och andra. För att hantera kundorganisationer måste du ge dig själv (eller andra personer) rollen Fullständig försäljningsadministratör eller rollen Försäljningsadministratör. Mer information finns i Tilldela organisationskontoroller i Control Hub.

Problem med användarprovisionering

1. Integrerad snabbmeddelanden & P-fel för specifika företag / kunder

Om ni har en blandning av företag som använder olika molntjänster för samarbete, till exempel UC-One SaaS och Webex för Cisco BroadWorks, kan ni ha valt att modifiera provisioneringsadaptern för varje företag.

Så här kontrollerar du vad som är konfigurerat för integrerade snabbmeddelanden & 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 specifikt företags provisioneringsparametrar, öppna företaget och gå till Tjänster > Integrerad snabbmeddelanden & P.

Kontrollera att det integrerade im&P-konfiguration för det företaget matchar exakt vad som visas i kundmallen i partnerhubben. Följande inställningar måste matcha eller så misslyckas etableringen för alla användare i företaget:

2. Integrerad snabbmeddelanden & P-fel för specifika användare

Detta gäller om du använder genomflödesprovisionering och förutsätter att provisioneringen fungerar för some/most användare (så att du kan utesluta ett konfigurationsproblem). Om du ser integrerade snabbmeddelanden & P-fel i BroadWorks, till exempel, “[Error 18215] Provisioneringsfel med meddelandeservern” och “[Error 18211] Kommunikationsfel med meddelandeservern”, bör du undersöka följande potentiella orsaker:

• Användarens e-postadress kunde redan finnas CI. Sök efter användaren i helpdesk 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 har behörighet att se i helpdesk.
• Användaren har själv registrerat sig för Webex innan han/hon tilldelas 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 etablerar. Instruktionerna finns på https://help.webex.com/5m4i4y
• Användaren har inget primärt telefonnummer tilldelat sin profil (alla Webex för Cisco BroadWorks-prenumeranter måste ha ett primärt DID). Se ämnet på analysen av PSLog från AS.

3. Användarprovisioneringsfel som svar från provisioneringsbryggan

Om användare inte visas i Control Hub, inom några minuter efter att de tilldelat integrerade snabbmeddelanden & P, ta en titt på svarskoderna från provisioneringsbryggtjänsten. Kör en PSLog för att titta på HTTP-svarskoderna.

200 OK

Ett 200 OK-svar betyder inte att användaren har etablerats korrekt. Det innebär att etableringstjänsten tog emot begäran och skickade motsvarande begäran om skapande av användare till tjänster uppströms. Transaktionen för tillhandahållande är asynkron genom design. Tjänsten svarar 200 OK eftersom det kan ta flera minuter att skapa en användare och vi av prestandaskäl inte vill få 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 tyda på att användarskapandet misslyckades i Webex-tjänsterna uppströms provisioneringstjänsten. Du måste eskalera ett etableringsfel som har ett 200OK-svar.

400 dålig begäran

Kontrollera HTTP-svaret som bör ha mer detaljerad information om potentiella problem som kan orsaka detta svar från etableringstjänsten. Några exempel på nod:

• "Kan inte lita på BroadWorks-e-post med äldre etablerings-API." Den e-postadress som är kopplad till begäran om att användare inte tillhandahållande har misslyckats är ogiltig eller är felaktigt inskrivna, men du har angett i mallen som e-postadresserna kan vara betrodda. Kontrollera användarnas profiler i BroadWorks, specifikt e-post-ID:
• Kundorganisationen hittades inte i databasen och flaggan för att skapa en ny organisation är inte aktiverad. Denna misslyckade etableringsbegäran bör skapa en ny kundorganisation i Webex, men din mall ä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 etableringsbegäran på nytt. Om du inte förväntade dig att en ny organisation skulle skapas för denna användare kanske e-postadressen är felaktig (särskilt domändelen). Kontrollera användarens e-post-ID i BroadWorks.

403 Förbjuden

Provisioneringsbegä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 exempelvis ser en IP-adress som mål för etableringsbegäran – i stället för lämplig URL för etableringsbryggan för din organisation (se ämnen om brandväggskonfigurationen i Lösningsguide) – kan det indikera att din programserver saknar en obligatorisk programfix (ap373197).

Kontrollera att alla nödvändiga programfixar tillämpas på programservern och att du har slutfört relaterad konfiguration för lyckad flowavetablering.

409 Konflikt

Provisioneringsbegäran kan inte fortsätta eftersom det finns en befintlig användare i Webex som matchar e-postadressen i förfrågan.

4. Användaren finns redan i CI

Få prenumerantens e-post från HTTP POST-begäran och sök efter den i Help Desk. Du kanske inte ser användaren om du inte är tillåten, men du kan även se att användaren är i en "gratis"-organisation, t.ex. "konsument". Du kan be den här användaren att radera sitt kostnadsfria 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 på inloggningsskärmen för Webex-appen. Problemet kan orsakas på klientsidan eller på tjänstsidan. På klientsidan orsakas det vanligtvis av att kundens inbyggda webbläsare är inkompatibel på något sätt med tjänsten.

2. Enkel inloggning misslyckades

• I BroadWorks, kontrollera att användaren har tilldelats enhetstyperna för Webex-appen (se avsnittet Enhetsprofiler 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 etablera användarens kundorganisation (i Partner Hub) är konfigurerad för BroadWorks-autentisering, bör användaren ange sitt BroadWorks-lösenord för "webbåtkomst". Användaren kan också behöva ange sitt BroadWorks-användar-ID om deras e-postadress inte är konfigurerad som ett alternativt användar-ID. Se till att användaren har angett korrekt stora och små tecken.

Problem med anropskonfiguration och registrering

När en användare har etablerats i Webex och de har loggat in på Webex-appen registreras appen på BroadWorks. Följande är den förväntade registreringssekvensen och de resulterande tecknen på en felfri registrering (som framgår av Webex-appen):

1. Förväntad registreringssekvens

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

2. Förväntade tecken på lyckad klientregistrering

Samtalsalternativ-ikonen visas i Webex-gränssnittet.

På fliken Webex-appens telefontjänster (t.ex. Inställningar > Telefontjänster i Windows, Inställningar > Telefontjänster på Mac), meddelandet “SSO-session: Du är inloggad" innebär att appen har registrerats (till BroadWorks i det här fallet).

3. Klienten har ingen samtalsikon

För det mesta innebär detta att användaren inte har rätt licens/berättigande.

Detta är en misslyckad registrering. Det finns flera anledningar till varför en Webex-appklient misslyckas med registrering hos BroadWorks:

4. Flera samtalstjänster testas med samma klienter

Det här kända problemet kan orsakas av att klienten ändrar mellan olika avslutat uppringning. Det är mest troligt att det inträffar under utvärderingar av olika samtalstjänster som erbjuds via (samma) Webex-appklienter. Du kan återställa klientdatabasen (länk) för att åtgärda detta problem.

5. Felkonfiguration av autentiseringstjänsten

Kontrollera XSP:erna som är värd för verifieringstjänsten mot lösningsguiden (se Konfigurera tjänster på din Webex för Cisco BroadWorks XSPs). Så här gör du:

• RSA-tangenterna (som du genererar på en XSP) kopieras till alla XSP:er
• URL:en för verifieringstjänsten har tillhandahållits till webbbehållaren på alla XSP:er och har angetts korrekt i klustret i partnerhubben
• Extern verifiering av certifikat har konfigurerats:

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>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-inställningar).

6. Felaktig konfiguration av BroadWorks-taggar

Kontrollera att du har konfigurerat de BroadWorks-taggar som krävs för Webex-appen. Se Webex för Cisco BroadWorks konfigurationsguide för information om konfigurationstaggar. Se till att det inte finns några konflikter eller felaktiga värden. Mer specifikt bör taggen %SBC_ADDRESS_WXT% vara SBC:n mot din SIP-registrator för Webex-appklienter.

7. Skrivbordsklienten kopplar bort telefontjänster efter lyckad SSO-anslutning

Problemet orsakas av att samma användare loggar in på flera klienter på samma plattformstyp. Om till exempel en användare 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 maskinerna. Detta är avsiktligt. Om du absolut måste arbeta runt detta problem kan du konfigurera BroadWorks så att det finns flera instanser av samma enhetstyp, men de måste ha unika SIP-adresser. Den här konfigurationen ligger utanför Webex-omfattningen för CiscoBroadWorks.

8. Skrivbordsenheten har inte tillhandahållits för användaren

Denna signatur syns i klientloggen:

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

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

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

Inkommande samtal till Webex Mobile 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 sig?

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

Svarskod: 400

handlePushCallInfoFailure:BWC:INTERNAL: Push-samtal: xsi-status för samtals-ID: <callID> xsi-felkod: 101002

closePushCallWithReason:BWC:INTERNAL: Försök att avsluta push-samtal med ID = <callID>, anledning = SamtalÖvergivet

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

Rekommenderade kontroller:

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

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

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

Upplösning: Om LocateUser returnerar det sekundära AS:et för användaren, kör skriptet migrateUserToDefaultNode.pl på den primära NS-servern för att migrera användare tillbaka till den primära applikationsservern för klustret.

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

Exempel: migrateUserToDefaultNode.pl bwas1

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

Skriptet kontrollerar först om det kan hitta den värd-NE som du anger som argument. När den har verifierat att värd-NE är giltig uppdaterar den DN, tillägget och URL:en till standardnoden för den värd-NE.

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

Skriptet kan inte köras för endast en enskild användare. Den migrerar alla användare som listas i LocateUser -utdata. Om du inte kan köra skriptet, ta bort och återskapa den berörda användaren i BroadWorks så att användaren återskapas på rätt AS.

Alla SIP-meddelanden från användarenheten till det sekundära AS:et kan orsaka att användaren migrerar. Användare återgår vanligtvis 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 till exempel SBC 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 enskild 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.

För mer information, se följande dokument:

• Avsnitt 3.4.5 Användaråterställningsfunktion för applikationsserver och 5.4.5 Automatisk återställning i Redundansguide för Cisco BroadWorks

• Funktionsbeskrivning för Cisco BroadWorks ASR-förbättringar

Problem med webbvyn för samtalsinställningar

1. Självvård button/link visas inte i Webex-appen

Ett annat symtom för detta problem är när knappen/länken visas, men när man klickar öppnas en extern webbläsare.

• Kontrollera att den nödvändiga klientkonfigurationsmallen har distribuerats och att CSW-taggar är korrekt inställda. (Se avsnittet Samtalsinställningar Webview 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 felmeddelande efter att ha klickat på Självhjälp button/link

Generellt sett indikerar detta beteende i Webex-appen ett konfigurations- eller distributionsproblem med CSWV-applikationen på BroadWorks XSP. Samla in detaljer för vidare undersökning, inklusive CSWV-loggar, åtkomstloggar, lagringsplats för config-wxt.xml och mallfil och höj sedan ett ärende.

Problem med domänanspråk

Fel för användarregistrering kan uppstå till följd av fel som görs i anspråk av domäner. Innan du gör anspråk på några domäner måste du se till att du förstår följande:

• Tjänsteleverantör ska inte göra anspråk på domänerna för kundorganisationer som de hanterar. De ska endast göra anspråk på domänerna för de användare som finns tjänsteleverantör företagets interna organisation. Att göra anspråk på användardomänen i en separat organisation (även en som tjänsteleverantör hanterar) kan resultera i registreringsfel för användarna i kundorganisationen när begäran om användarautentisering dirigeras via tjänsteleverantör i stället för till 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 registrering för företag B-användare misslyckas på grund av att begäran om användarautentisering dirigeras via organisationen som har domänen fordrat (företag A).

  Om du gör anspråk på någon av domänerna i fel form och behöver ta bort ett anspråk, se Webex-artikeln Hantera dina domäner.

Felkoder för slutanvändare

Följande tabell sammanfattar felkoder för slutanvändare som kan ses i klientens portal för användaraktivering.

Felkoder för katalogsynkronisering

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