Danke für Ihr Feedback.

Dieser Artikel richtet sich an das technische Support-Team der Service Provider-Organisation, das sich selbst und seine Kunden unterstützt. Sie sollten mit der allgemeinen Problembehandlung, dem Lesen von Protokollen und der Arbeit mit Abonnentenfällen vertraut sein.

Dieser Artikel ist in drei Hauptabschnitte unterteilt:

• Ressourcen — bietet eine Liste von Tools, Lesematerial, Protokollen und Kontakten, die Sie möglicherweise benötigen.
• Prozesse — beschreibt einige der Maßnahmen, die Sie bei der Behebung eines Kundenproblems ergreifen können.
• Spezifische Probleme — kategorisiert und listet Probleme auf, von denen bekannt ist, wie man sie erkennt und wie Sie sie möglicherweise lösen können.

Nützliche Protokolldateien

Leseliste

• Webex für Cisco BroadWorks Partner-Wissensportal
• XSP-Plattform-Konfigurationshandbuch (R23)
• BroadWorks Software-Management-Handbuch (R23)
• Cisco BroadWorks Device Management-Konfigurationshandbuch (R23)
• Broadworks Xsp Administrationshandbuch für die Befehlszeilenschnittstelle
• Funktionsbeschreibung des langlebigen Authentifizierungstokens Version 23.0
• Integrationsleitfaden zur SAML-Authentifizierung, R23
• Leitfaden zu Cisco BroadWorks SSL-Supportoptionen
• Beschreibung der Funktionen des Cisco CI-Supports
• Push-Server für Benachrichtigungen (Funktionsbeschreibung)
• Unterstützung von Push-Benachrichtigungen für Anrufe, Funktionsbeschreibung Version 22.0
• Vorgehensweise bei der Migration von Connect (Android) zu Firebase
• Cisco BroadWorks Speicherung von Geräte-Token für Push-Benachrichtigungen Funktionsbeschreibung Version 22.0
• Cisco Broadworks System Capacity Planner (Tabelle)
• Leitfaden zur Dimensionierung der Cisco BroadWorks-Plattform
• Cisco Broadworks System-Engineering-Handbuch
• Dokument mit den Anforderungen an die CI-Authentifizierung, Version 1.0, MR-7136

Bekannte Probleme und Einschränkungen

Der Artikel Bekannte Probleme und Einschränkungen enthält aktuelle Informationen zu bekannten Problemen, die wir in der Webex for BroadWorks-Lösung identifiziert haben.

Brauchbarkeits-Konnektor

Der Webex Serviceability Service erhöht die Geschwindigkeit, mit der Mitarbeiter des technischen Kundendienstes von Cisco Probleme mit der Infrastruktur diagnostizieren können. Es automatisiert das Suchen, Abrufen und Speichern von Diagnoseprotokollen und Informationen zu einem SR-Fall. Der Service löst auch eine Analyse anhand von Diagnosesignaturen aus, sodass TAC Probleme mit Ihren Geräten vor Ort effizienter identifizieren und lösen kann.

Einzelheiten zur Bereitstellung des Serviceability Connectors finden Sie im Bereitstellungshandbuch für Cisco Webex Serviceability Connector.

Ein Problem eskalieren

Nachdem Sie einige der Anleitungen zur Fehlerbehebung befolgt haben, sollten Sie eine vernünftige Vorstellung davon haben, wo das Problem seinen Ursprung hat.

Verfahren

1. Sammeln Sie so viele Informationen wie möglich aus den Systemen, die sich auf das Problem beziehen.
2. Wenden Sie sich an das entsprechende Team bei Cisco, um einen Fall zu eröffnen.

Welche Kundeninformationen müssen gesammelt werden

Wenn Sie der Meinung sind, dass Sie einen Fall eröffnen oder ein Problem eskalieren müssen, sammeln Sie bei der Problembehandlung mit dem Benutzer die folgenden Informationen:

• Benutzer-ID: CI-E-Mail-Adresse oder Benutzer-UUID (das ist die Webex-ID, aber wenn Sie auch die BroadWorks-ID des Benutzers erhalten, geben Sie sie in den Falldetails an).
• Organisationskennung.
• Ungefährer Zeitraum, in dem das Problem aufgetreten ist.
• Client-Plattform und Version.
• Senden oder sammeln Sie Protokolle vom Client.
• Notieren Sie sich die Tracking-ID, falls sie auf dem Kunden angezeigt wird.

Überprüfen Sie die Benutzerdetails im Helpdesk

Partneradministratoren mit den Rollenrechten Helpdesk-Administrator (Basic oder Advanced) können dieses Verfahren verwenden, um Benutzerdetails in der Helpdesk-Ansicht zu überprüfen.

Verfahren

1. Melden Sie sich beim Helpdesk an.
2. Suchen Sie nach dem Benutzer und klicken Sie dann darauf. Das öffnet den Bildschirm mit der Benutzerübersicht.
3. Klicken Sie auf den Benutzernamen, um die detaillierte Benutzerkonfiguration zu sehen. Zu den nützlichen Informationen in dieser Ansicht gehören die UUID des Benutzers, der Common Identity (CI) -Cluster, der Webex-App-Cluster, das Anrufverhalten, die 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 eine Cisco-Hülle an.

Kundenorganisation im Helpdesk anzeigen

Partneradministratoren mit den Rollenrechten Helpdesk-Administrator (Basic oder Advanced) können dieses Verfahren verwenden, um Details zur Kundenorganisation in der Helpdesk-Ansicht anzuzeigen.

Verfahren

1. Melden Sie sich beim Helpdesk an.
2. Suchen Sie nach dem Namen der Kundenorganisation und klicken Sie dann darauf.
3. Scrollen Sie nach unten, bis Sie die Kundenportalansicht sehen, und klicken Sie auf Kundenname anzeigen, um eine schreibgeschützte Ansicht der Kundenorganisation zu sehen — einschließlich Benutzer und Konfiguration.

Benutzerprotokolle von Partner Hub abrufen

Bei der Behebung von Problemen mit Desktop- und Mobilclients ist es wichtig, dass Partner (und TAC) die Kundenprotokolle einsehen können.

Verfahren

1. Bitten Sie den Benutzer, Protokolle zu senden. Hilfe finden Sie unter: Webex App | Ein Problem melden.
2. Bitten Sie den Benutzer, die Anruf-Umgebung zu exportieren und Ihnen die Datei ced.dat zu senden.
3. Holen Sie sich die Kundenprotokolle von Partner Hub oder Helpdesk.

   Partner-Hub-Option:

   1. Melden Sie sich bei Partner Hub an und suchen Sie die Kundenorganisation des Benutzers.
   2. Wählen Sie Problembehandlung aus.
   3. Wählen Sie Logs aus.
   4. Suchen Sie nach dem Benutzer (per E-Mail).
   5. Sehen Sie sich die Kundenprotokolle an und laden Sie sie als Zip-Datei herunter.

   Helpdesk-Option:

   1. Melden Sie sich beim Helpdesk an.
   2. Suchen Sie nach der Organisation.
   3. Klicken Sie auf die Organisation (öffnet den Übersichtsbildschirm).
   4. Scrollen Sie nach unten, um auf Kunde anzeigen zu klicken.
   5. Wählen Sie Problembehandlung aus.
   6. Wählen Sie Logs aus.
   7. Suchen Sie nach dem Benutzer (per E-Mail).
   8. Sehen Sie sich die Kundenprotokolle an und laden Sie sie als Zip-Datei herunter.

So finden Sie die Client-Version

Verfahren

1. Teilen Sie diesen Link mit dem Benutzer: https://help.webex.com/njpf8r5
2. Bitten Sie den Benutzer, Ihnen die Versionsnummer zu schicken.

Kundencheck für den Anrufservice

Verfahren

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, wie zum BeispielWebex Calling, angezeigt wird, verwendet der Benutzer Webex für Cisco BroadWorks nicht.)

   Diese Verifizierung bedeutet:

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

Kundenprotokolle oder Feedback einholen

• Sehen Sie sich den Abschnitt Ressourcen an, um bestimmte Kundenprotokolle auf Webex-Desktop-Clients zu finden, oder bitten Sie Benutzer, Protokolle zu senden. Hilfe finden Sie unter: Webex App | Ein Problem melden.
• Bitten Sie Benutzer von mobilen Clients, Protokolle zu senden, dann können Sie sie über Partner Hub oder Helpdesk abrufen.
  Das Senden von Protokollen ist stumm. Wenn ein Benutzer jedoch Feedback sendet, geht es an das Webex App DevOps-Team. Notieren Sie sich unbedingt die Feedback-Nummer des Benutzers, wenn Sie Cisco kontaktieren möchten. Zum Beispiel:

  

Daten zur Anruf-Umgebung abrufen

Webex-Kundenprotokolle werden stark redigiert, um persönlich identifizierbare Informationen zu entfernen. Sie sollten die Anrufumgebungsdaten vom Client in derselben Sitzung exportieren, in der Sie das Problem feststellen.

Verfahren

1. Klicken Sie auf dem Client auf Hilfe > Health Checker.
2. Wählen Sie Datenbank zurücksetzen. Dies löst einen vollständigen Reset des Clients aus und lädt den Anmeldebildschirm der Webex-App.

Vergewissern Sie sich, dass Webex sich bei BroadWorks registrieren sollte

Die Webex-App überprüft die folgenden Informationen, um festzustellen, ob Sie sich bei BroadWorks registrieren müssen:

• Benutzeranspruch auf den Broadworks-Connector.
• Anrufverhalten für Organisation und Benutzer.

Überprüfen Sie das Anrufverhalten und die Connector-Berechtigung eines Benutzers

1. Melden Sie sich mit Ihren Partneradministrator-Anmeldedaten beim Helpdesk an.
2. Suchen Sie den Benutzer.
3. Klicken Sie auf den Benutzer und überprüfen Sie den Eintrag Anrufverhalten. Es sollte „Calling in Webex“ lauten.

   

4. Klicken Sie auf den Benutzernamen, um den Bildschirm mit den Benutzerdetails zu öffnen.
5. Scrollen Sie nach unten, um den Abschnitt „Berechtigungen“ zu finden, und überprüfen Sie, ob der Broadworks-Connector enthalten ist

   

   Ein Benutzer von Webex for Cisco BroadWorks sollte nicht die bc-sp-standard-Berechtigung haben, wenn er beabsichtigt, Webex for Cisco BroadWorks zu verwenden. Das ist der Anspruch für „Webex Calling(Broadcloud)“, bei dem es sich um Webex-App-Aufrufe über einen von Cisco verwalteten Cloud-Anrufdienst handelt.

Überprüfen Sie das Anrufverhalten der Organisation

1. Melden Sie sich mit Ihren Partneradministrator-Anmeldedaten beim Helpdesk an.
2. Suchen Sie nach der Organisation.
3. Klicken Sie auf die Organisation und überprüfen Sie den Eintrag Anrufverhalten. Es sollte „Calling in Webex“ lauten.

Analysieren Sie PSLog auf Probleme mit der Benutzerverwaltung

Verwenden Sie das PSLog des Anwendungsservers, um die HTTP-POST-Anfrage an die Provisioning Bridge und die Antwort von Webex zu sehen. In einem korrekt funktionierenden Fall ist die Antwort 200 OK und nach ein paar Minuten können Sie sehen, dass der Benutzer — und die neue Kundenorganisation, falls es sich um den ersten Benutzer handelt — in Webex erstellt wurde. Sie können dies überprüfen, indem Sie den Helpdesk nach der E-Mail-Adresse durchsuchen, die Sie in der POST sehen.

Vorbereitungen

Erfassen Sie während eines Flowthrough-Provisioning-Versuchs mit einem Testbenutzer ein PSLog vom Anwendungsserver.

Verfahren

1. Überprüfen Sie zunächst den HTTP-Antwortcode:
   • Alles andere als 200 OK ist ein Fehler bei der Benutzerbereitstellung.
   • 200 OK, könnte immer noch auf einen Fehler hinweisen, wenn etwas am Abonnentenprofil in den Webex-Diensten vor der Provisioning Bridge nicht funktioniert.
   • 400 kann einen Nachrichtenknoten in der Antwort enthalten. Die Provisioning Bridge konnte etwas im SubscriberProfile nicht verarbeiten. Möglicherweise stimmt etwas mit den Abonnentendaten nicht oder es besteht eine Inkompatibilität mit einer Einstellung in der Vorlage.
   • 401 bedeutet, dass die auf dem AS eingegebenen Bereitstellungsdaten nicht mit denen übereinstimmen, die in der Vorlage in Partner Hub eingegeben wurden.
   • 403 könnte auf etwas hinweisen, das auf dem Anwendungsserver falsch konfiguriert ist. Überprüfen Sie das Ziel der Anfrage. Es sollte keine IP-Adresse sein, es sollte die Provisioning Bridge-URL sein, die Sie in Ihrer Vorlage in Partner Hub sehen können.
   • 409 weist auf einen Konflikt zwischen dem angegebenen Abonnentenprofil und vorhandenen Webex-Daten hin. Möglicherweise gibt es einen bestehenden Benutzer mit dieser E-Mail-Adresse. Überprüfen Sie die Nachricht in der Antwort.
2. Sie können auch den ursprünglichen HTTP-POST auf verdächtige Werte überprüfen, die dazu führen könnten, dass die Bereitstellung fehlschlägt. Der POST enthält eine SubscriberProfile-XML-Struktur. Darin befinden sich nützliche Knoten, die Sie überprüfen sollten:
   • bwuserid: Verwenden Sie dies, um das Abonnentenprofil zu finden, falls Sie es in BroadWorks bearbeiten müssen.
   • Gruppe: Wenn sich die Vorlage im „Service Provider-Modus“ befindet, wird dies in Kleinbuchstaben geschrieben und wird zum Namen der Kundenorganisation, die Sie in Partner Hub sehen.
   • ServiceProvider: Wenn sich die Vorlage im „Unternehmensmodus“ befindet, wird dies in Kleinbuchstaben geschrieben und wird zum Namen der Kundenorganisation, die Sie in Partner Hub sehen.
   • PrimaryPhoneNumber: Muss existieren. Ohne sie schlägt die Bereitstellung fehl.
   • E-Mail: Wird zur Benutzer-ID in Webex. Muss gültig und einzigartig für Webex sein, andernfalls schlägt die Bereitstellung fehl.

     Ignorieren Sie die Servicezeile: Sie wurde von AS erstellt und akzeptiert, aber nicht von Webex verwendet.

Analysieren Sie XSP-Protokolle, um Probleme bei der Abonnenten-Anmeldung zu beheben

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

Das folgende Leiterdiagramm zeigt die Interaktion zwischen dem Benutzer, dem Client, den Webex-Diensten und dem BroadWorks-System, wenn der Benutzer die BroadWorks-Authentifizierung in der Webex-App durchführt. Außerdem ist die Verbindung zwischen Webex und dem XSP durch MTLS gesichert.

In der folgenden Diskussion wird erklärt, was Sie erwarten können, wenn Sie die Logs auf eine erfolgreiche Anmeldung hin untersuchen.

Der Benutzer interagiert mit dem Kunden, der Kunde interagiert mit den Webex-Diensten:

• Der Benutzer gibt seine E-Mail-Adresse in die Webex-App ein (1 im Diagramm).
• CI weiß, dass dieser Benutzer zur Eingabe seines BroadWorks-Passworts (über UAP) weitergeleitet werden muss (2 im Diagramm).
• Der IDP-Proxy sendet eine Anfrage zum Abrufen eines Profils an die XSI-Schnittstelle auf dem XSP.

Im Tomcat Access_Log:

• Suchen Sie nach der GET-Anfrage für das Abonnentenprofil, von Webex zur Xsi-Actions-Schnittstelle (2.1 im Diagramm). Es hat die Webex-Benutzer-ID. Zum Beispiel:

  HOLEN SIE SICH /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile

Im xsiActionsLog:

• Suchen Sie nach der Profil-GET-Anfrage von Webex (2.1 im Diagramm). Es hat die Webex-Benutzer-ID. Zum Beispiel:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Die Header beinhalten Authorization: Basic und User-Agent: BroadworkSteamsClient

• Das XSP führt dann die OCI-P-Basic-Authentifizierung gegen BroadWorks durch (AuthenticationVerifyRequest und AuthenticationVerifyResponse, wie jede andere Anwendung, die die Standardauthentifizierung über Xsi durchführt) sowie UserGetRequest und ServiceProviderGetRequest, um die Abonnenteninformationen zu sammeln.
• Die Xsi-Antwort an Webex enthält einen XML-Profilblock, der die (BroadWorks) Benutzer-ID und andere Details enthält (2.2 im Diagramm).

Interaktionen zwischen Kunden und Webex-Diensten:

• Der IDP-Proxy stimmt mit dem von BroadWorks erhaltenen Benutzerprofil überein und gibt eine SAML-Assertion an den Kunden aus (2,3 im Diagramm).
• Der Kunde tauscht eine SAML-Assertion gegen ein CI-Token aus (3 im Diagramm).
• Der Kunde überprüft, ob der angemeldete Benutzer die Broadworks-Connector-Berechtigung hat (4 im Diagramm). Sie können die Benutzerberechtigungen im Helpdesk überprüfen.
• Der Kunde verwendet CI-Token, um ein JSON-Web-Token (JWT) vom IDP-Proxy anzufordern (5 im Diagramm).
• Der IDP-Proxy validiert das CI-Token bei CI.
• IDP-Proxy fordert JWT vom Authentifizierungsdienst an.

Im AuthenticationService-Protokoll:

• Suchen Sie nach der Token-Anfrage von Webex (5.2 im Diagramm), zum Beispiel: GET /authService/Token, das den Header http_bw_userid und andere hat.
• Das XSP führt OCI-P UserGetLoginInfoRequest durch, um zu überprüfen, ob die angegebene Benutzer-ID einem BroadWorks-Benutzer entspricht (5.3 im Diagramm). AuthService hat aufgrund der mTLS-Verbindung Vertrauen zu Webex aufgebaut, kann also LLT ausstellen.
• Suchen Sie nach der Antwort (5.4 im Diagramm) von LongLiveTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks... and statusCode=200, die Sie mit der ursprünglichen Anfrage verknüpfen können, indem Sie den trackingid: CLIENT... -Header verwenden.

Im xsiActionsLog:

• Der Client kann das langlebige Token auf der Xsi-Actions-Schnittstelle präsentieren, um sein Geräteprofil abzurufen (6 im Diagramm). Zum Beispiel: GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserID %40example.com/profile/device Mit der Header-Autorisierung: Bearer-Token und User-Agent: WebExTeams (Variant/Version)
• Die Xsi-Actions-Schnittstelle POSTET das Token an den Authservice (konfiguriert für die Loopback-Schnittstelle) Zum Beispiel: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token, was Sie mit dem trackingid: CLIENT... -Header im GET und dem X-BROADSOFT-CORRELATION-ID: CLIENT... -Header im POST korrelieren können.

Im AuthenticationService-Protokoll:

• Der Erhalt der POST von Xsi (Loopback)

• Ein StatusCode=200, zurück zu Xsi

• Und eine Token-Validierungsantwort mit einem „Token“ -JSON-Block im Hauptteil.

• Korreliert mit der Tracking-ID: KUNDE...

Im xsiActionsLog:

• Nachdem die Xsi-Actions-Anwendung 200 OK vom Authservice erhalten hat, der das Token des Kunden validierte, sendet sie jetzt eine OCI-P-Anfrage für UserPrimary und SCADeviceGetListRequest
• Empfängt OCI-P UserPrimary und SCADeviceGetListResponse, die die AccessDeviceTable-XML-Struktur enthalten.
• Die OCI-P-Antwort ist als Xsi-Antwort an den Client kodiert, einschließlich der AccessDevices-XML-Struktur, die die DeviceTypes enthält. Zum Beispiel: Business Communicator — PC und die URLs, unter denen der Client die Gerätekonfigurationsdateien abrufen kann.

Der Kunde fährt wie gewohnt fort:

• Wählt einen Geräteeintrag aus und interagiert mit DMS, um das Geräteprofil abzurufen (6 im Diagramm).
• Registriert sich bei BroadWorks über SBC, das in der Konfiguration von DMS abgerufen wird (7 im Diagramm).

Probleme mit dem Partner Hub

1. Administrator kann Kundenorganisationen nicht sehen

Als Administrator für Ihre Partnerorganisation in Webex sollten Sie die Rolle „Volladministrator“ haben. Diese Rolle wird für die Verwaltung Ihrer Partnerorganisation verwendet, einschließlich der Zuweisung von Administratorrechten für Sie und andere. Um Kundenorganisationen zu verwalten, müssen Sie sich selbst (oder anderen Personen) die Rolle des vollständigen Verkaufsadministrators oder die Rolle des Vertriebsadministrators gewähren. Einzelheiten finden Sie unter Rollen für Organisationskonten in Control Hub zuweisen.

Probleme mit der Nutzerverwaltung

1. Integrierte IM&P-Fehler für bestimmte Unternehmen/Kunden

Wenn Sie eine Mischung aus Unternehmen haben, die verschiedene Cloud-Collaboration-Dienste nutzen, zum Beispiel UC-One SaaS und Webex für Cisco BroadWorks, haben Sie sich möglicherweise dafür entschieden, den Provisioning-Adapter auf Unternehmensbasis zu ändern.

Um zu überprüfen, was für Integrated IM&P konfiguriert ist (Standard für Unternehmen, es sei denn, es gibt eine spezifischere Einstellung), führen Sie AS_CLI/Interface/Messaging> get aus. Für die Bereitstellungsparameter eines bestimmten Unternehmens öffnen Sie das Unternehmen und gehen Sie zu Services > Integrated IM&P.

Vergewissern Sie sich, dass die integrierte IM&P-Konfiguration für dieses Unternehmen genau dem entspricht, was in der Kundenvorlage in Partner Hub angezeigt wird. Die folgenden Einstellungen müssen übereinstimmen, sonst schlägt die Bereitstellung für alle Benutzer im Unternehmen fehl:

2. Integrierte IM&P-Fehler für bestimmte Benutzer

Das gilt, wenn Sie Flowthrough-Provisioning verwenden und davon ausgehen, dass die Bereitstellung für einige/die meisten Benutzer funktioniert (sodass Sie ein Konfigurationsproblem ausschließen können). Wenn Sie integrierte IM&P-Fehler in BroadWorks sehen, zum Beispiel „[Fehler 18215] Bereitstellungsfehler mit Messaging-Server“ und „[Fehler 18211] Kommunikationsfehler mit Messaging-Server“, sollten Sie die folgenden möglichen Ursachen untersuchen:

• Die E-Mail-Adresse des Benutzers könnte bereits existieren CI. Suchen Sie im Helpdesk nach dem Benutzer, um zu überprüfen, ob seine E-Mail-Adresse bereits dort ist. Das ist nicht unbedingt aussagekräftig, weil der Benutzer möglicherweise in einer Organisation existiert, deren Daten Sie im Helpdesk nicht sehen dürfen.
• Der Benutzer hat sich unabhängig bei Webex angemeldet, bevor ihm der integrierte IM&P-Dienst zugewiesen wurde. In diesem Fall besteht eine Möglichkeit darin, den Benutzer seine kostenlosen Konten löschen zu lassen, sodass er Teil der Kundenorganisation werden kann, die Sie bereitstellen. Anweisungen finden Sie unter https://help.webex.com/5m4i4y
• Dem Benutzer ist keine primäre Telefonnummer in seinem Profil zugewiesen (alle Abonnenten von Webex for Cisco BroadWorks müssen eine primäre DID haben). Siehe das Thema zur Analyse von PSLog von AS.

3. Fehler bei der Benutzerbereitstellung als Reaktion auf die Provisioning Bridge

Wenn Benutzer nicht in Control Hub erscheinen, schauen Sie sich innerhalb weniger Minuten nach der Zuweisung von Integrated IM&P die Antwortcodes des Provisioning Bridge Service an. Führen Sie ein PSLog aus, um sich die HTTP-Antwortcodes anzusehen.

200 OK

Eine Antwort von 200 OK bedeutet nicht, dass der Benutzer erfolgreich bereitgestellt wurde. Das bedeutet, dass der Provisioning Service die Anfrage erhalten hat und die entsprechende Anfrage zur Benutzererstellung erfolgreich an die Upstream-Dienste gesendet hat. Die Bereitstellungstransaktion ist von Natur aus asynchron. Der Service antwortet 200 OK, weil der Benutzererstellungsprozess mehrere Minuten dauern kann und wir aus Leistungsgründen nicht mehrere Anfragen erhalten möchten, um denselben Benutzer zu erstellen. Wenn der Benutzer jedoch nach einer Antwort mit 200 OK nicht in der Kundenorganisation erscheint, könnte dies darauf hinweisen, dass die Benutzererstellung in den Webex-Diensten, die dem Bereitstellungsdienst vorgelagert sind, fehlgeschlagen ist. Sie müssen einen Bereitstellungsfehler eskalieren, der eine Antwort von 200 OK hat.

400 Schlechte Anfrage

Überprüfen Sie die HTTP-Antwort, die mehr Details zu möglichen Problemen enthalten sollte, die zu dieser Antwort des Bereitstellungsdienstes führen könnten. Einige Beispiele für den Knoten:

• „Ich kann BroadWorks Email mit der veralteten Provisioning-API nicht vertrauen.“ Die E-Mail-Adresse, die mit der fehlgeschlagenen Benutzerbereitstellungsanfrage verknüpft ist, ist ungültig oder wurde falsch eingegeben, aber Sie haben in der Vorlage versichert, dass den E-Mail-Adressen vertraut werden kann. Überprüfen Sie die Benutzerprofile in BroadWorks, insbesondere die E-Mail-ID.
• Die Kundenorganisation wurde in der Datenbank nicht gefunden und auch die Markierung für die Erstellung einer neuen Organisation ist nicht aktiviert.“ Diese fehlgeschlagene Bereitstellungsanfrage sollte die Erstellung einer neuen Kundenorganisation in Webex sein, aber Ihre Vorlage ist so konfiguriert, dass keine neuen Kundenorganisationen erstellt werden. Wenn Sie neue Organisationen zulassen möchten, für E-Mail-Domains, die nicht mit bestehenden Kunden in Webex übereinstimmen, können Sie Ihre Vorlage in Partner Hub neu konfigurieren und die Bereitstellungsanfrage erneut testen. Wenn Sie jedoch nicht erwarten, dass eine neue Organisation für diesen Benutzer erstellt wird, ist die E-Mail-Adresse möglicherweise falsch eingegeben (insbesondere der Domänenteil). Überprüfen Sie die E-Mail-ID des Benutzers in BroadWorks.

403 Verboten

Die Bereitstellungsanfrage kann erst erfolgreich sein, wenn Sie die Konfiguration korrigieren. In diesem Fall müssen Sie die Anfrage und die Antwort untersuchen. Wenn Sie zum Beispiel eine IP-Adresse als Ziel der Bereitstellungsanfrage sehen — und nicht die entsprechende Provisioning Bridge-URL für Ihr Unternehmen (siehe die Themen zur Firewall-Konfiguration im Solution Guide) — könnte das darauf hinweisen, dass Ihrem Anwendungsserver ein erforderlicher Patch fehlt (ap373197).

Vergewissern Sie sich, dass alle erforderlichen Patches auf dem Anwendungsserver installiert sind und dass Sie die entsprechende Konfiguration für eine erfolgreiche Flowthrough-Bereitstellung abgeschlossen haben.

409 Konflikt

Die Bereitstellungsanfrage kann nicht fortgesetzt werden, da in Webex bereits ein Benutzer vorhanden ist, der mit der E-Mail-Adresse in der Anfrage übereinstimmt.

4. Benutzer ist bereits in CI

Holen Sie die Abonnenten-E-Mail aus der HTTP-POST-Anfrage heraus und suchen Sie im Helpdesk danach. Sie sehen den Benutzer möglicherweise nicht, wenn Sie nicht berechtigt sind, aber Sie können auch sehen, dass der Benutzer einer „kostenlosen“ Organisation angehört, z. „Verbraucher“. Sie können diesen Benutzer bitten, sein kostenloses Konto zu löschen, oder Sie können eine andere E-Mail-Adresse verwenden, um ihn bereitzustellen. Siehe https://help.webex.com/ndta402.

Probleme bei der Benutzeranmeldung

1. Das Benutzeraktivierungsportal wird nicht geladen

Der normale Anmeldevorgang für Webex für Cisco BroadWorks beinhaltet ein Benutzeraktivierungsportal, in dem Benutzer ihre Passwörter eingeben. Manchmal wird dieses Portal nicht geladen, nachdem der Benutzer seine E-Mail-Adresse auf dem Anmeldebildschirm der Webex-App angegeben hat. Dieses Problem kann auf der Kundenseite oder auf der Serviceseite verursacht werden. Auf der Client-Seite wird es in der Regel dadurch verursacht, dass der native Browser des Kunden in irgendeiner Weise nicht mit dem Dienst kompatibel ist.

2. Single Sign-On ist fehlgeschlagen

• Überprüfen Sie in BroadWorks, ob dem Benutzer die Gerätetypen für die Webex-App zugewiesen wurden (siehe Abschnitt Geräteprofile im Abschnitt „Bereiten Sie Ihre Umgebung vor“ des Lösungshandbuchs).
• Prüfen Sie, ob der Benutzer das richtige Passwort verwendet. Wenn die Vorlage, die Sie zur Bereitstellung der Kundenorganisation des Benutzers (in Partner Hub) verwendet haben, für die BroadWorks-Authentifizierung konfiguriert ist, sollte der Benutzer sein BroadWorks „Web Access“ -Passwort eingeben. Der Benutzer muss möglicherweise auch seine BroadWorks-Benutzer-ID eingeben, wenn seine E-Mail-Adresse nicht als alternative Benutzer-ID konfiguriert ist. Stellen Sie sicher, dass der Benutzer Groß- und Kleinbuchstaben richtig eingegeben hat.

Probleme mit der Konfiguration und Registrierung von Anrufen

Nachdem ein Benutzer in Webex eingerichtet wurde und er sich erfolgreich bei der Webex-App angemeldet hat, registriert sich die App bei BroadWorks. Im Folgenden sind die erwartete Registrierungssequenz und die daraus resultierenden Anzeichen einer fehlerfreien Registrierung (aus der Webex-App ersichtlich) aufgeführt:

1. Erwartete Registrierungssequenz

1. Der Client ruft XSI an, um ein Geräteverwaltungstoken und die URL zum DMS zu erhalten.
2. Der Client fordert sein Geräteprofil vom DMS an, indem er das Token aus Schritt 1 vorspielt.
3. Der Client liest das Geräteprofil und ruft die SIP-Anmeldeinformationen, Adressen und Ports ab.
4. Der Client sendet ein SIP-REGISTER anhand der Informationen aus Schritt 3 an den SBC.
5. SBC sendet das SIP REGISTER an das AS (SBC kann eine Suche im NS durchführen, um ein AS zu finden, falls SBC den SIP-Benutzer nicht bereits kennt.).

2. Erwartete Anzeichen einer erfolgreichen Kundenregistrierung

Das Symbol für Anrufoptionen wird auf der Webex-Oberfläche angezeigt.

Auf der Registerkarte Webex-App-Telefondienste (z. B. Einstellungen > Telefondienste unter Windows, Voreinstellungen > Telefondienste auf Mac) bedeutet die Meldung „SSO-Sitzung: Sie sind angemeldet“, dass die App erfolgreich registriert wurde (in diesem Fall bei BroadWorks).

3. Kunde hat kein Anrufersymbol

In den meisten Fällen bedeutet das, dass der Benutzer nicht über die richtige Lizenz/Berechtigungen verfügt.

Das ist eine erfolglose Registrierung. Es gibt mehrere Gründe, warum ein Webex-App-Client die Registrierung bei BroadWorks fehlschlagen würde:

4. Mehrere Anrufdienste werden mit denselben Kunden getestet

Dieses bekannte Problem kann dadurch verursacht werden, dass der Client zwischen verschiedenen Call-Backends wechselt. Es ist sehr wahrscheinlich, dass es bei Testversionen verschiedener Anrufdienste auftritt, die über (dieselben) Webex-App-Clients angeboten werden. Sie können die Kundendatenbank (Link) zurücksetzen, um dieses Problem zu beheben.

5. Fehlkonfiguration des Authentifizierungsdienstes

Vergleichen Sie die XSP (s), die den Authentifizierungsdienst hosten, mit dem Solution Guide (siehe Configure Services on your Webex for Cisco BroadWorks XSPs). Konkret:

• Die RSA-Schlüssel (die Sie auf einem XSP generieren) werden auf alle XSPs kopiert
• Die URL des Authentifizierungsdienstes wurde dem Web-Container auf allen xSPs zur Verfügung gestellt und korrekt in den Cluster in Partner Hub eingegeben
• Die externe Authentifizierung durch Zertifikate ist konfiguriert:

  xsp_cli/System/Communication Utility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>GET

  allowUserApp = false

  allowClientApp = true

• Wenn Sie MTLS verwenden, müssen Sie das Webex-Client-Zertifikat auf die xSPs hochladen (Sie können das Zertifikat von Partner Hub auf der BroadWorks-Einstellungsseite erhalten).

6. Fehlkonfiguration der BroadWorks-Tags

Überprüfen Sie, ob Sie die erforderlichen BroadWorks-Tags für die Webex-App konfiguriert haben. Informationen zu Konfigurations-Tags finden Sie im Webex for Cisco BroadWorks Configuration Guide. Stellen Sie sicher, dass es keine Konflikte oder falsche Werte gibt. Insbesondere sollte das Tag %SBC_ADDRESS_WXT% der SBC gegenüber Ihrem SIP-Registrar für Webex-App-Clients sein.

7. Der Desktop-Client trennt die Telefondienste nach erfolgreicher SSO-Verbindung

Dieses Problem kann dadurch verursacht werden, dass sich derselbe Benutzer bei mehreren Kunden auf derselben Plattform anmeldet. Wenn sich ein Benutzer beispielsweise erfolgreich bei der Webex-App unter Windows anmeldet und sich dann auf einem anderen Windows-Computer bei der Webex-App anmeldet, gibt es nur eine aktive SSO-Sitzung auf einem der Computer. Das ist durch das Design. Wenn Sie dieses Problem unbedingt umgehen müssen, können Sie BroadWorks so konfigurieren, dass es mehrere Instanzen desselben Gerätetyps hat, aber sie müssen eindeutige IP-Adressen haben. Diese Konfiguration fällt nicht in den Geltungsbereich von Webex für Cisco BroadWorks.

8. Desktop-Gerät nicht für Benutzer bereitgestellt

Diese Signatur ist im Kundenprotokoll zu sehen:

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

onAccessDeviceListSucceeded:bwc:SCF: ConfigDownload — das Geräteprofil 'Business Communicator - PC' wurde nicht gefunden.

9. Eingehende Handyanrufe klingeln einmal oder können nicht beantwortet werden

Eingehende Anrufe auf das Webex-Handy klingeln nur einmal, oder der Benutzer kann den eingehenden Anruf nicht annehmen. Andere Endgeräte für denselben Benutzer können weiterhin klingeln.

Wie identifiziere ich mich?

Suchen Sie in den Protokollen des Webex-Mobilclients im Push-Anrufablauf nach dem XSI-Fehlercode 101002. Zum Beispiel:

Antwortcode: 400

<callID>handlePushCallInfoFailure:bwc:internal: Push-Anruf: XSI-Status für CallID: XSI-Fehlercode: 101002

<callID>closePushCallWithReason:bwc:internal: Versuchen Sie, den Push-Anruf mit id =, reason = CallAbandoned zu schließen

Ursache: Der Fehlercode 101002 kann darauf hinweisen, dass der falsche Anwendungsserver (AS) in der LocateUser-Antwort zurückgegeben wurde. Das kann passieren, wenn der Benutzer auf ein sekundäres AS migriert ist.

Empfohlene Schecks:

Führen Sie aus dem ADP oder XSP, in dem Push bereitgestellt wird, LocateUser für den betroffenen Benutzer aus:

<FQDN or IP address of NS Server>curl 'http: //:80/servlet/locateUser? <BW userID @domain >url=&returncompatible xsp=true&callprequest=TRUE'

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

Lösung: Wenn LocateUser das sekundäre AS für den Benutzer zurückgibt, führen Sie das migrateUserToDefaultNode.pl-Skript auf dem primären NS-Server aus, um Benutzer zurück zum primären Anwendungsserver für den Cluster zu migrieren.

Melden Sie sich über SSH beim NS-Server an, gehen Sie zum Verzeichnis /usr/local/broadworks/bw_base/bin und führen Sie migrateUserToDefaultNode.pl aus <hostingNE>

Beispiel: MigrateUserToDefaultNode.pl bwas1

Um den HostingNE-Wert zu erhalten, führen Sie Folgendes aus: NS_CLI/System/Device/HostingNE> get

Das Skript prüft zunächst, ob es das Hosting-NE finden kann, das Sie als Argument angeben. Nachdem es verifiziert hat, dass das Hosting-NE gültig ist, aktualisiert es den DN, die Erweiterung und die URL auf den Standardknoten für dieses Hosting-NE.

Führen Sie das Skript wenn möglich in einer Zeit mit wenig Verkehr aus. Es ist jedoch generell akzeptabel, das Skript bei Bedarf jederzeit auszuführen, um den Dienst für die betroffenen Benutzer wiederherzustellen.

Das Skript kann nicht nur für einen einzelnen Benutzer ausgeführt werden. Es migriert alle Benutzer, die in der LocateUser-Ausgabe aufgeführt sind. Wenn Sie das Skript nicht ausführen können, löschen Sie den betroffenen Benutzer in BroadWorks und erstellen Sie ihn neu, sodass der Benutzer auf dem richtigen AS neu erstellt wird.

Jede SIP-Nachricht vom Benutzergerät zum sekundären AS kann dazu führen, dass der Benutzer migriert. Benutzer kehren in der Regel nach dem Standardintervall von 15 Minuten zum primären AS zurück, es sei denn, eingehende Anfragen erreichen weiterhin das sekundäre AS. Wenn der SBC beispielsweise keine Verbindung zu AS1 herstellen kann und rekursiv zum sekundären AS wechselt, können die betroffenen Benutzer zum sekundären AS wechseln. Je nach Bereitstellung kann eine einzelne Trunk-Gruppe oder ein einzelner Benutzer an das sekundäre AS gebunden bleiben, falls der SBC weiterhin Probleme hat, das primäre AS zu erreichen.

Weitere Informationen finden Sie in den folgenden Dokumenten:

• Abschnitte 3.4.5 Rollback-Funktion für Anwendungsserver für Benutzer und 5.4.5 Automatisches Rollback im Cisco BroadWorks Redundancy Guide

• Beschreibung der Funktionen der Cisco BroadWorks ASR-Erweiterungen

9. Die Telefondienste wurden unterbrochen

Wenn die Telefondienste als unterbrochen angezeigt werden, nachdem sich der Benutzer bei der Webex-App angemeldet hat, oder wenn die Telefondienste unterbrochen werden, während der Benutzer den Client verwendet, überprüfen Sie den Kundentyp und den Registrierungsablauf.

Für Windows- und Mac-Clients registriert sich die Webex-App für SIP und behält eine aktive SIP-Registrierung bei, während der Benutzer angemeldet ist.

Überprüfen Sie Folgendes:

1. Vergewissern Sie sich, dass config-wxt.xml erfolgreich heruntergeladen wurde.

Suchen Sie in den Kundenprotokollen nach ConfigDownload.

Ein erfolgreicher Download zeigt:

ConfigDownload — erfolgreich abgeschlossen

Wenn die Protokolle den folgenden Fehler anzeigen, überprüfen Sie die AuthService-Protokolle auf Token-bezogene Fehler:

ConfigDownload — fehlgeschlagen mit Fehlercode: 1511

2. Vergewissern Sie sich, dass das Webex-Geräteprofil gefunden wurde.

Bestätigen Sie in den Client-Protokollen, dass das Zugangsgerät gefunden wurde und dass used_value 1 ist. Wenn used_value 0 ist, überprüfen Sie, ob Primary Line aktiviert oder deaktiviert ist, und überprüfen Sie den Tag-Wert. Weitere Informationen finden Sie in Abschnitt 6.1.44 Primärprofil im Webex for BroadWorks Configuration Guide.

Beispiel für Logeinträge:

:BWC:SCF: ConfigDownload — Zugangsgerät gefunden

:BWC:SCF: ConfigDownload — Zugriffsgerät: DeviceType=Business Communicator - PC, DeviceLevel=Group, AllowTermination=1, IsDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Shared Call Appearance

:BWC:SCF: ConfigDownload — Zugriffsgerät: DeviceType=Connect - Mobile, DeviceLevel=Group, AllowTermination=1, IsDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Shared Call Appearance

:BWC:SCF: ConfigDownload — Zugriffsgerät: DeviceType=Connect - Tablet, DeviceLevel=Group, AllowTermination=1, IsDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Shared Call Appearance

3. Suchen Sie bei der Auflösung der SIP-Proxyadresse nach DNS-Fehlern.

Einzelheiten zur SIP-Proxy-Erkennung finden Sie in Abschnitt 6.1.6 Dynamische SIP-Proxy-Erkennung im Webex for BroadWorks Configuration Guide.

Eine erfolgreiche Proxy-Erkennung zeigt:

Die Proxy-Erkennung ist abgeschlossen, es liegen <number>Ergebnisse vor

4. Prüfen Sie, ob die SIP-Registrierung fehlschlägt.

Wenn in den Protokollen mRegistration: TCPTimeout oder Reason: SIP; cause=200; text="last=TCP-Timeout“ angezeigt wird, kann der Webex-Client keine Low-Level-TCP-Verbindung zum SBC herstellen. Die SIP-Registrierung wird nicht abgeschlossen, wenn dieser Fehler auftritt. Prüfen Sie, ob TCP im Netzwerk des Benutzers blockiert ist oder ob der SBC die TCP-Verbindung ablehnt.

Wenn die SIP-REGISTER-Anfrage abgelehnt wird oder keine Antwort erhält, suchen Sie in den Protokollen nach REGISTER SIP und stellen Sie sicher, dass SIP/2.0 200 OK zurückgegeben wird. Wenn es nicht zurückgegeben wird, überprüfen Sie, ob das Netzwerk des Benutzers SIP blockiert oder ob der SBC die Anfrage ablehnt.

Gehen Sie in BroadWorks Admin zu Benutzer > Dienstprogramme > Registrierungen und stellen Sie sicher, dass eine gültige SIP-Registrierung für den Webex-Client vorhanden ist.

Für mobile Android- und iOS-Clients registriert sich die Webex-App erst für SIP, wenn ein Anruf getätigt oder eingegangen ist. Die Registrierung wird entfernt, wenn der Anruf abgeschlossen ist. Mobile Kunden registrieren sich für Push-Benachrichtigungen.

Für mobile Kunden überprüfen Sie Folgendes:

1. Stellen Sie sicher, dass config-wxt.xml erfolgreich heruntergeladen wurde und dass das Geräteprofil gefunden wurde, wie für Windows- und Mac-Clients beschrieben.

2. Stellen Sie sicher, dass die Push-Registrierung erfolgreich ist.

Suchen Sie in den Webex-Protokollen nach dem Status der Push-Registrierung:

onPushRegistrationStateChanged: :Status der Push-Registrierung geändert, State=unregistered

onPushRegistrationStateChanged: :Status der Push-Registrierung geändert, State=Registered

Gehen Sie in BroadWorks Admin zu Benutzer > Dienstprogramme > Registrierungen für Push-Benachrichtigungen und stellen Sie sicher, dass eine gültige Push-Registrierung für den Webex-Client vorhanden ist.

Probleme mit den Anrufeinstellungen und der Webansicht

1. Self-Care-Button/Link wird in der Webex-App nicht angezeigt

Ein anderes Symptom dieses Problems ist, wenn die Schaltfläche/der Link angezeigt wird, aber wenn Sie darauf klicken, wird ein externer Browser geöffnet.

• Vergewissern Sie sich, dass die erforderliche Client-Konfigurationsvorlage bereitgestellt ist und die CSW-Tags richtig gesetzt sind. (Siehe den Abschnitt Call Settings Webview im Webex for Cisco BroadWorks Solution Guide).
• Vergewissern Sie sich, dass die Webex-App für Anrufe in BroadWorks registriert ist.
• Vergewissern Sie sich, dass die Webex-App eine aktuelle Version ist, die CSWV unterstützt.

2. Leere Seite oder Fehler nach dem Klicken auf die Schaltfläche/den Link Self Care

Im Allgemeinen weist dieses Verhalten in der Webex-App auf ein Konfigurations- oder Bereitstellungsproblem mit der CSWV-Anwendung auf BroadWorks XSP hin. Sammeln Sie Details für weitere Untersuchungen, einschließlich CSWV-Logs, Zugriffsprotokolle, config-wxt.xml Repository und Vorlagendatei, und sprechen Sie dann einen Fall an.

Probleme mit Domainansprüchen

Fehler bei der Benutzerregistrierung können als Folge von Fehlern auftreten, die bei der Inanspruchnahme von Domains gemacht wurden. Stellen Sie vor dem Beanspruchen von Domänen sicher, dass Sie Folgendes verstanden haben:

• Dienstanbieter dürfen keine Domänen von Kundenorganisationen beanspruchen, die sie verwalten. Sie sollten nur die Domänen der Benutzer beanspruchen, die sich in der Dienstleister Organisation des Unternehmens befinden. Die Beanspruchung der Domäne von Benutzern in einer separaten Organisation (selbst eine, die von Dienstleister verwaltet wird) kann zu Registrierungsfehlern für die Benutzer in der Kundenorganisation führen, da Benutzerauthentifizierungsanfragen durch die Dienstleister und nicht durch die Kundenorganisation geroutet werden.
• Wenn zwei Kundenorganisationen (Firma A und Firma B) die gleiche Domäne teilen und Firma A die Domäne beansprucht hat, kann die Registrierung für Benutzer von Firma B fehlschlagen, da Benutzerauthentifizierungsanfragen durch die Organisation geroutet werden, deren Domäne beansprucht ist (Firma A).

  Wenn Sie irrtümlich Domains beanspruchen und einen Anspruch entfernen müssen, lesen Sie den Webex-Artikel Manage Your Domains.

Fehlercodes für Endbenutzer

In der folgenden Tabelle sind die Endbenutzer-Fehlercodes aufgeführt, die im Kundenbenutzeraktivierungsportal angezeigt werden können.

Fehlercodes für Directory Sync

Die folgenden Fehlercodes gelten für die Verzeichnissynchronisierung.