Webex für BroadWorks-Fehlerbehebungsprozesse

Eskalieren eines Problems

Nachdem Sie einige der Anweisungen zur Fehlerbehebung befolgt haben, sollte eine angemessene Idee davon sein, wo das Problem gerootet wird.

1

Sammeln Sie so viele Informationen wie möglich von den Systemen, die mit dem Problem in Verbindung stehen

2

Wenden Sie sich an das entsprechende Team von Cisco, um einen Fall zu öffnen (siehe Abschnitt "Kontakte")

Welche Kundeninformationen müssen gesammelt werden?

Wenn Sie der Ansicht sind, Sie müssen einen Fall öffnen oder ein Problem eskalieren, erfassen Sie während der Fehlerbehebung mit dem Benutzer die folgenden Informationen:

  • Benutzeridentifikator: CI-E-Mail-Adresse oder Benutzer-UUID (dies ist der Webex-Bezeichner, aber wenn Sie auch den BroadWorks-Bezeichner des Benutzers erhalten, hilft dies)

  • Organisationsbezeichner

  • Ungefährer Zeitraum, in dem das Problem zu erleben war

  • Clientplattform und -version

  • Senden oder Sammeln von Protokollen vom Client

  • Tracking-ID wird auf dem Client angezeigt

Überprüfen Sie die Benutzerdetails in Helpdesk

1

Melden Sie sich bei https://admin.webex.com/helpdesk an.

2

Suchen Sie nach einem Benutzer und klicken Sie anschließend auf diesen. Dadurch wird der Übersichtsbildschirm des Benutzers geöffnet.

3

Klicken Sie auf Benutzername, um eine detaillierte Benutzerkonfiguration zu sehen.

Nützliche Informationen in dieser Ansicht umfassen die UUID des Benutzers, ein CI-Cluster, ein Webex-App-Cluster, Anrufverhalten, BroadWorks-Konto-GUID.

4

Klicken Sie auf Kopieren, wenn Sie diese Informationen in einem anderen Tool verwenden müssen, oder hängen Sie sie an einen Cisco-Fall an.

Anzeigen der Kundenorganisation in Helpdesk

1

Melden Sie sich bei https://admin.webex.com/helpdesk an.

2

Suchen Sie nach einem Unternehmen des Kunden, und klicken Sie dann auf den Namen der Kundenorganisation.

3

Scrollen Sie nach unten, bis die Kundenportalansicht angezeigt wird, und klicken Sie auf Kundenname anzeigen, um eine schreibgeschützte Ansicht der Kunden-Organisation zu sehen, einschließlich Benutzer und Konfiguration.

Abrufen von Benutzerprotokollen aus dem Partner Hub

Bei der Behebung von Problemen mit dem Desktop und mobilen Clients ist es wichtig, dass Partner (und TAC) die Client-Protokolle anzeigen können.

1

Bitten Sie den Benutzer, Protokolle zu senden.

2

Bitten Sie den Benutzer, die Anrufumgebung zu exportieren. Senden Sie Ihnen die Datei ced.dat.

3

Erhalten Sie die Clientprotokolle vom Partner Hub oder Helpdesk (siehe unten).

Partner Hub-Option:

  1. Melden Sie sich bei Partner Hub an und suchen Sie die Kundenorganisation des Benutzers.

  2. Wählen Sie Fehlerbehebung aus.

  3. Wählen Sie Protokolle aus.

  4. Suchen Sie nach dem Benutzer (per E-Mail).

  5. Sie können die Clientprotokolle als ZIP-Datei anzeigen und herunterladen.

Helpdesk Option:

  1. Melden Sie sich an, Helpdesk.

  2. Suchen Sie nach der Organisation.

  3. Klicken Sie auf die Organisation (öffnet den Übersichtsbildschirm).

  4. Scrollen Sie nach unten, um auf Kunden anzeigen zu klicken.

  5. Wählen Sie Fehlerbehebungaus.

  6. Wählen Sie Protokolleaus.

  7. Suchen Sie nach dem Benutzer (per E-Mail).

  8. Sie können die Clientprotokolle als ZIP-Datei anzeigen und herunterladen.

So finden Sie die Client-Version

1

Geben Sie diesen Link an den Nutzer weiter: https://help.webex.com/njpf8r5.

2

Bitten Sie den Nutzer, Ihnen die Versionsnummer zu senden.

Client-Prüfung für Anrufdienst

1

Melden Sie sich beim Webex-Client an.

2

Überprüfen Sie, ob das Symbol "Anrufoptionen" (ein Handset mit einem Zahnrad darüber) in der Seitenleiste angezeigt wird.

Wenn das Symbol nicht vorhanden ist, ist der Benutzer möglicherweise noch nicht für den Anrufdienst in Control Hub aktiviert.

3

Öffnen Sie das Menü Einstellungen/Einstellungen und gehen Sie zum Abschnitt Telefondienste. Während der Sitzung, SSO Sie angemeldet sind, sollte der Status angezeigtwerden.

(Wenn ein anderer Telefondienst, z. B. Webex Callingwird angezeigt, verwendet der Benutzer nicht Webex für BroadWorks.)

Diese Verifizierung bedeutet:

  • Der Client hat die erforderlichen Webex-Microservices erfolgreich überquert.
  • Der Benutzer wurde erfolgreich authentifiziert.
  • Dem Client wurde ein langlebiges JSON-Webtoken von Ihrem BroadWorks-System ausgestellt.
  • Der Client hat sein Geräteprofil abgerufen und sich bei BroadWorks registriert.

Erhalten Kundenprotokolle oder Feedback

  • Im Abschnitt "Ressourcen" können Sie nach bestimmten Client-Protokollen auf Webex-Desktopclients suchen oder Benutzer zum Senden von Protokollen auffordern.

  • Bitten Sie Benutzer von mobilen Clients, Protokolle zu senden. Sie können sie dann über die Partner-Hub oder den Help Desk erhalten.


Das Senden von Protokollen ist unbestummt. Wenn ein Benutzer jedoch Feedback sendet, wird es an das Cisco Webex-Devops-Team gehen. Stellen Sie sicher, dass Sie die Feedback-Nummer des Nutzers aufzeichnen, wenn Sie Cisco weiter verfolgen möchten. Zum Beispiel:

Anrufumgebungsdaten erhalten

Webex-Clientprotokolle sind stark umgekämmt, um persönlich identifizierbare Informationen zu entfernen. Sie sollten die Anrufumgebungsdaten aus dem Client in derselben Sitzung exportieren, in der Sie das Problem bemerken.

1

Klicken Sie im Client auf das Profilbild, und klicken Sie dann auf > Anrufumgebungsdaten exportieren.

2

Speichern Sie die resultierende Datei ced.dat, um Probleme bei Anrufen für diesen Benutzer zu beheben.

Wichtig: Wenn Sie sich vom Client abmelden oder neu starten, wird der interne Cache leert. Wenn Sie anschließend ced.dat exportieren, entsprechen die exportierten Daten keinen Protokollen, die vor dem Cache gesendet wurden.

Webex-Datenbank zurücksetzen

1

Klicken Sie auf dem Client > auf > Integritätsprüfung.

2

Wählen Sie Datenbank zurücksetzenaus.

Dies löst einen vollständigen Reset des Clients aus und lädt den Anmeldebildschirm der Webex-App.

Webex sollte sich bei BroadWorks registrieren

Die Webex-App überprüft die folgenden Informationen, um festzustellen, ob eine Registrierung bei BroadWorks durchgeführt werden soll:

  • Benutzerberechtigung für Broadworks-Connector

  • Anrufverhalten für Organisation und Benutzer

Überprüfen des Anrufverhaltens und der Connector-Berechtigung eines Benutzers

  1. Melden Sie sich an Helpdesk (https://admin.webex.com/helpdesk) mit Ihren Partneradministrator-Anmeldeinformationen an.

  2. Suchen Sie nach dem Benutzer.

  3. Klicken Sie auf den Benutzer und überprüfen Sie den Eintrag Anrufverhalten. Dies sollte "In Webex anrufen" sein.

  4. Klicken Sie auf Benutzername, um den Bildschirm Benutzerdetails zu öffnen.

  5. Scrollen Sie nach unten, um das entitlements und stellen Sie sicher, dass broadworks-connector ist inbegriffen.


    Ein Webex-Benutzer für BroadWorks sollte NICHT über die bc-sp-standard Berechtigung, wenn sie Webex für BroadWorks verwenden möchten. Dies ist die Berechtigung für "Webex Calling (Broadcloud)", bei dem die Webex-App über einen von Cisco verwalteten Cloud-Anrufdienst anruft.

Überprüfen des Anrufverhaltens der Organisation

  1. Melden Sie sich an Helpdesk (https://admin.webex.com/helpdesk) mit Ihren Partneradministrator-Anmeldeinformationen an.

  2. Suchen Sie nach der Organisation.

  3. Klicken Sie auf die Organisation und überprüfen Sie den Eintrag Anrufverhalten. Dies sollte "In Webex anrufen" sein.

PSLog für Probleme mit der Benutzerbereitstellung analysieren

Verwenden Sie das PSLog des Anwendungsservers, um die HTTP POST-Anforderung zur Bereitstellungsbrücke und die Antwort von Webex zu sehen.

Im korrekten Arbeitsfall beträgt die Antwort 200 OK, und nach einigen Minuten können Sie den Benutzer – und die neue Kunden-Organisation, wenn es sich um den ersten Benutzer handelt – in Webex erstellen.

Sie können dies verifizieren, Helpdesk E-Mail-Adresse im POST finden.

Vorbereitungen

Sammeln Sie eine PSLog vom Anwendungsserver während eines Flowthrough-Bereitstellungsversuchs mit einem Testbenutzer.

1

Der erste zu überprüfende Punkt ist der HTTP-Antwortcode:

  • Alles andere als 200 OK ist ein Fehler bei der Benutzerbereitstellung.

  • 200 OK könnte immer noch einen Fehler anzeigen, wenn etwas am Abonnentenprofil in den Webex-Diensten, die an der Bereitstellungs-Bridge angeschaltet sind, nicht funktioniert.

  • 400 darf folgende Elemente enthalten: message Knoten in der Antwort. Die Bereitstellungsbrücke konnte etwas im subscriberProfile. Möglicherweise stimmt etwas mit den Abonnentendetails oder mit einer Einstellung in der Vorlage nicht zusammen.

  • 401 bedeutet, dass die im AS eingegebenen Bereitstellungsnachweise nicht mit den in der Vorlage im Partner Hub eingegebenen Anmeldeinformationen übereinstimmen.

  • 403 könnte auf etwas falsch konfiguriertes Auf Anwendungsserver hindeuten. Überprüfen Sie das Ziel der Anfrage. es sollte keine IP-Adresse sein, es sollte die Bereitstellungs-Bridge-URL sein, die Sie in Ihrer Vorlage im Partner Hub sehen können.

  • 409 zeigt einen Konflikt zwischen dem angegebenen subscriberProfile und vorhandene Webex-Daten. Möglicherweise gibt es einen Benutzer mit dieser E-Mail-Adresse. Überprüfen Sie die message in der Antwort.

2

Sie können auch das ursprüngliche HTTP POST auf möglicherweise möglicherweise fehlschlagende Werte überprüfen, die zu einem Ausfall der Bereitstellung führen könnten.

Der POST enthält einen subscriberProfile XML-Struktur. In dieser sind die nützlichen Knoten, die Sie überprüfen können, wie:

  • bwuserid: Hier können Sie das Abonnentenprofil finden, wenn Sie es in BroadWorks bearbeiten müssen.

  • group: Wenn die Vorlage im "Dienstleister"-Modus vor sich geht, wird dies als Name der Kunden-Organisation angezeigt, die im Partner Hub angezeigt wird.

  • serviceProvider: Wenn die Vorlage im "Enterprise-Modus" angezeigt wird, wird diese kleinformatiert und wird zum Namen der Kunden-Organisation, die Sie im Partner Hub sehen.

  • primaryPhoneNumber: Muss vorhanden sein. Die Bereitstellung schlägt ohne sie fehl.

  • email: Wird die Benutzer-ID in Webex. Muss für Webex gültig und eindeutig sein, andernfalls schlägt die Bereitstellung fehl.


 

Ignorieren Sie den services Stanza: es wurde von AS erstellt und akzeptiert, aber nicht von Webex verwendet.

Analysieren von XSP-Protokollen zur Fehlerbehebung bei der Abonnenten-Anmeldung

Dieser Ablauf beschreibt den BroadWorks-Authentifizierungsmodus. Sie können den Authentifizierungsmodus auf der BroadWorks-Vorlage im Partner Hub sehen. Siehe Kundenvorlagen konfigurieren in https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Der folgende Kontaktplan zeigt die Interaktion zwischen dem Benutzer, dem Client, den Webex-Diensten und dem BroadWorks-System an, wenn der Benutzer eine BroadWorks-Authentifizierung in der Webex-App vor sich hat. Außerdem ist die Verbindung zwischen Webex und XSP durch MTLS gesichert.

In der folgenden Diskussion wird erklärt, was zu erwarten ist, wenn Sie die Protokolle für eine erfolgreiche Anmeldung untersuchen.

Abbildung 1. BroadWorks-Authentifizierung und Gerätekonfiguration

Der Benutzer interagiert mit dem Client, der Client interagiert mit Webex-Diensten:

  • Der Benutzer gibt seine E-Mail-Adresse an die Webex-App an (1 im Diagramm).

  • CI weiß, dass dieser Benutzer umgeleitet wird, um sein BroadWorks-Passwort einzugeben (über UAP) (2 im Diagramm).

  • Der IDP-Proxy übermittelt eine Anforderung zum Erhalten eines Profils an die Xsi-Schnittstelle auf XSP.

Im Tomcat-access_log:

  • Suchen Sie nach der GET-Anforderung für das Abonnentenprofil, von Webex zur Xsi-Actions-Schnittstelle (2.1 im Diagramm). Sie verfügt über die Webex-Benutzer-ID. E.g.

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

Im XsiActionsLog:

  • Suchen Sie nach der GET-Profilanfrage von Webex (2.1 im Diagramm). Sie verfügt über die Webex-Benutzer-ID. E.g.

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

    Die Kopfzeilen enthalten authorization: Basic und user-agent: broadworksTeamsClient

  • Das XSP führt dann OCI-P Basic-Authentifizierung gegen BroadWorks (AuthenticationVerifyRequest und AuthenticationVerifyResponse, wie jede andere Anwendung, die die Basisauthentifizierung über Xsi vorsieht) und ein UserGetRequest und ServiceProviderGetRequest durch, um die Abonnenteninformationen zu erfassen.

  • Die Xsi-Antwort auf Webex enthält eine XML Profile Blockierung, die den (BroadWorks) enthält userId und weitere Details (2.2 im Diagramm).

Interaktionen zwischen Client- und Webex-Diensten:

  • IDP-Proxy stimmt mit Benutzerprofil von BroadWorks erhaltenen Und Problemen der SAML-Assertion mit dem Client ab (2.3 im Diagramm)

  • SamL-Assertion für den Client-Austausch für ein CI-Token (3 im Diagramm)

  • Der Client überprüft, ob der angemeldete Benutzer über die Broadworks-Connector-Berechtigung verfügt (4 im Diagramm). Sie können die Benutzerberechtigungen in der Helpdesk)

  • Client verwendet CI Token, um einen JSON Web Token (JWT) vom IDP-Proxy an fordern (5 im Diagramm)

  • IDP-Proxy validiert CI-Token bei CI

  • IDP-Proxy fordert JWT vom Authentifizierungsdienst an

Im Authentifizierungsserviceprotokoll:

  • Suchen Sie nach der Tokenanforderung von Webex (5.2 im Diagramm), z. B.:

    GET /authService/token

    welche hat http_bw_userid Kopfzeile und andere.

  • Der XSP führt OCI-P aus UserGetLoginInfoRequest, um zu überprüfen, ob die angegebene Benutzer-ID einem BroadWorks-Benutzer entspricht (5.3 im Diagramm). AuthService hat aufgrund der mTLS-Verbindung eine Vertrauensstellung mit Webex aufgebaut, sodass LLT aus angezeigt werden kann.

  • Suchen Sie nach der Antwort (5.4 im Diagramm) von LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

    und StatusCode=200 die Sie mit der ursprünglichen Anfrage verknüpfen können, indem Sie den trackingid: CLIENT… Header.

Im XsiActionsLog:

  • Der Client kann nun das langlebige Token auf der Xsi-Actions-Benutzeroberfläche präsentieren, um sein Geräteprofil abzurufen (6 im Diagramm). E.g.:

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

    Mit den Kopfzeilen authorization: Bearer token und user-agent: WebexTeams (variant/version)

  • Die Xsi-Actions-Schnittstelle POSTs das Token zum Authentifizierungsservice (konfiguriert, um auf der Loopback-Schnittstelle zu sein), z. B.: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    die Sie in Beziehung zum trackingid: CLIENT… Kopfzeile im GET Und die X-BROADSOFT-CORRELATION-ID : CLIENT… Kopfzeile im POST.

Im Authentifizierungsserviceprotokoll:

  • Empfang des POST von Xsi (Loopback)

  • A StatusCode=200 zurück zu Xsi

  • Und eine Tokenvalidierungsantwort, die einen "token" JSON-Block im Text.

  • Verbunden mit der trackingid: CLIENT…

Im XsiActionsLog:

  • Nachdem die Xsi-Aktionen-Anwendung 200 OK vom Authentifizierungsservice erhalten hat, wodurch das Token des Clients überprüft wurde, sendet die Xsi-Actions-Anwendung nun eine OCI-P-Anforderung für UserPrimaryAndSCADeviceGetListRequest

  • Empfängt OCI-P UserPrimaryAndSCADeviceGetListResponse enthält die accessDeviceTable XML-Struktur.

  • Die OCI-P-Antwort wird als Xsi-Antwort an den Client codiert, einschließlich AccessDevices XML-Struktur, die den deviceTypes E.g. Business Communicator – PC und die URLs, über die der Client die Gerätekonfigurationsdateien abrufen kann.

Client wird normal fortgesetzt:

  • Wählt einen Geräteeintrag aus und interagiert mit DMS, um ein Geräteprofil zu erhalten (6 im Diagramm)

  • Registrierung bei BroadWorks über SBC in Konfiguration vom DMS abgerufen (im Diagramm 7)