Übersicht

Mithilfe der Fehlerbehebung für Webex Calling können Sie Probleme mit der Medienqualität und der Anrufkonnektivität für bestimmte Webex Calling-Anrufe beheben. Möglicherweise möchten Sie aus verschiedenen Gründen Probleme mit Anrufen beheben, beispielsweise wenn sich Kunden über eine schlechte Anrufqualität beschweren. In diesem Fall können Sie direkt zur Fehlerbehebungsansicht gehen, nach diesen bestimmten Anrufen suchen und dann die Hop-Details anzeigen, um genau zu bestimmen, wo das Problem liegen könnte. Mithilfe der Fehlerbehebung können Sie die Anrufqualität für das Unternehmen auch proaktiv überwachen und bestimmten Problemen zuvorkommen, bevor sie von den Benutzern bemerkt werden.

Um auf die Fehlerbehebungsansicht zugreifen zu können, müssen Sie in Control Hub über die Rolle des Volladministrators, des schreibgeschützten Administrators oder des Supportadministrators verfügen.

Sie können anhand der folgenden Kriterien suchen, um eine Liste der Anrufe zu erhalten, bei denen eine Mediensitzung mit mindestens einem bei Webex Calling registrierten Endpunkt verwendet wurde:

  • E-Mail-IDs

  • Telefonnummern

  • MAC-Adresse

  • Anruf-IDs

  • Korrelations-ID

Die Teilsuche wird für E-Mail-IDs, Telefonnummern und Anruf-IDs unterstützt. Bei Telefonnummern können Sie die ersten drei bis acht Ziffern eingeben und dann die Eingabetaste drücken, um passende Einträge anzuzeigen. Wenn Sie mehr als acht Ziffern eingeben, versucht die Suche, eine genaue Übereinstimmung zu finden. Beachten Sie, dass Sie beim Kopieren und Einfügen einer Telefonnummer von woanders die +1 damit die Suche funktioniert.

Mit der Fehlerbehebung bei Webex Calling können Sie:

  • Suche nach erfolgreichen, fehlgeschlagenen und abgelehnten Anrufen.

  • Sehen Sie sich die End-to-End-Erfahrung der Teilnehmer des Anrufs an.

  • Zeigen Sie ein Hop-Detail des Anrufs an.

  • Zeigen Sie an, ob die Medien die Webex Calling Cloud oder direkt zwischen den Benutzern durchqueren (mit Interactive Connectivity Connectivity (ICE)).

  • Zeigen Sie Insights an, wenn im Anruf keine Medien vorhanden sind oder wenn die Einrichtung der Pfadoptimierung nicht erfolgreich war.

  • Anrufe der letzten 21 Tage anzeigen.

  • Zeigen Sie signalisierungsbezogene Anruffehler und -ablehnungen an.

  • Analysieren Sie die Kennzahlen zur Anrufqualität, die die Benutzererfahrung beeinflussen. Beispielsweise kann ein Administrator bei Clients über Wi-Fi-Netzwerke einen hohen Jitter feststellen, Paketverlust und Latenz können jedoch akzeptabel sein.

  • Feststellen, ob das Problem mit dem Anrufer oder dem Anrufer besteht.

Die Anrufe, die Webex Calling werden angezeigt, nachdem der Anruf beendet wurde.

Die Ansicht zur Fehlerbehebung hilft bei der Identifizierung des Problembereichs, indem sie alle relevanten Messdaten bereitstellt und Ihnen nicht unbedingt die Grundursache für einen schlechten Anruf nennen kann. Sehen Sie sich diese Zeiger an, um verschiedene Faktoren zu identifizieren und die Auflösungsoptionen zu bestimmen:

  • Die End-to-End-Erfahrung des Benutzers.

  • Die Ansicht Hop-Details.

  • Sie können Metriken vom Benutzer oder vom Media Relay-Punkt senden oder empfangen.

  • Ob der Anruf an oder von einem externen Netzwerk oder zwischen den registrierten Webex Calling-Endpunkten stattgefunden hat.

Suchansicht

Gesuchte Anrufe in der Fehlerbehebung im Control Hub

Bei der Suche nach einem Anruf stehen Ihnen folgende Daten zur Verfügung:

SpaltennameDefinition

Anrufstatus

Ob der Anrufversuch erfolgreich war oder nicht. Wenn der Anrufversuch den Status Ablehnung oder Fehlgeschlagen hat, können Sie mit der Maus über den Status fahren, um den entsprechenden Code anzuzeigen. Mögliche Werte sind:

  • Erfolgreich – Anrufversuch war erfolgreich.

  • Ablehnung – Anrufversuch wurde abgelehnt.

  • Fehler – Anrufversuch fehlgeschlagen.

Qualität

Die Webex Calling-Anrufe werden auf Qualität bewertet. Für Webex-Meetings oder Call-on-Webex-Sitzungen gilt diese Benotung jedoch nicht. Die Anruferfahrung wird als:

  • Schlecht – zeigt an, dass entweder der Anrufer oder der Angerufene eine schlechte End-to-End-Erfahrung hatte (z. B. abgehackter Ton).

  • Gut – Gibt an, dass die End-to-End-Erfahrung für den Anrufer und den Angerufenen die Schwellenwerte nicht überschritten hat.

  • Keiner / Nicht verfügbar – Keine Daten zur Medienqualität verfügbar.

Dienst

Für den Anruf verwendeter Dienst.

Startzeit

Startzeit des Anrufs, basierend auf der neben der Datumsbereichsauswahl ausgewählten Zeitzone.

Treffen / Rufnummer

Telefonnummer des Anrufers.

Name

Anzeigename des Anrufers und des Angerufenen.

Gastgeber/Anrufer

Anzeigename des Anrufers.

Teilnehmer

Anzahl der Benutzer im Anruf.

Dauer

Dauer des Anrufs.

Site/Standort

Webex-Anrufstandort des Anrufers.

Konferenz / Korrelations-ID

Beziehungs-ID, um mehrere Anruf gleichzeitige Teilnessel derselben Anrufsitzung zu binden.

Key Performance Indicators (KPIs) des gesuchten Benutzers

KPIs für einen gesuchten Benutzer bei der Fehlerbehebung im Control Hub

Wenn Sie nach einem Benutzer suchen, stehen Ihnen die folgenden KPIs zur Verfügung:

  • Fehlgeschlagene Anrufe– Anzahl der Anrufe, die im ausgewählten Datumsbereich fehlgeschlagen sind.
  • Schlechte Meeting-Minuten– Anzahl der Minuten während Webex Meetings, die im ausgewählten Datumsbereich eine schlechte Leistung aufwiesen.
  • Anruf über Webex mit schlechter Qualität– Anzahl der Anrufe über Webex, die im ausgewählten Datumsbereich eine schlechte Qualität aufwiesen.
  • Webex Calling-Anrufe mit schlechter Qualität– Anzahl der Webex Calling- -Anrufe mit schlechter Qualität im ausgewählten Datumsbereich.
  • Schlechte WebRTC-Minuten– Anzahl der Minuten mit schlechter Qualität bei der Verwendung von WebRTC im ausgewählten Datumsbereich.
  • Gesamtminuten der Meetings– Gesamtzahl der Webex Meetings Minuten im ausgewählten Datumsbereich.
  • Gesamtanzahl der Anrufe bei Webex-Anrufminuten– Gesamtzahl der Anrufe bei Webex Minuten im ausgewählten Datumsbereich.
  • Webex Calling-Anrufminuten gesamt– Gesamtzahl der Webex Calling-Minuten im ausgewählten Datumsbereich.
  • WebRTC-Minuten gesamt– Gesamtzahl der WebRTC-Minuten im ausgewählten Datumsbereich.

Hop-Detailansicht

Beispiel für die wichtigsten Details eines Webex Calling-Anrufs in der Fehlerbehebung

In der Hop-Detailansicht sind folgende Daten verfügbar:

BegriffDefinition
Endgeräte

Zeigt eine der folgenden Informationen an:

  • Tischtelefon für einen physischen Endpunkt

  • Webex-App

  • Raumgerät für Geräte der Cisco Room Series

Hardware

Zeigt eine der folgenden Informationen an:

  • Informationen zum Tischtelefonmodell für einen physischen Endpunkt

  • "-" für eine Webex-App

  • Modellinformationen der Room Series für Geräte der Cisco Room Series

Standort

Für den Benutzer konfigurierter Webex Calling-Standort. Das Land, in dem Webex Calling bereitgestellt wurde, wird ebenfalls in Klammern angezeigt.

Lokale IP

Die lokale IP-Adresse des Clients für die Netzwerkschnittstelle, die zum Übertragen von Medien verwendet wird. IP-Adressen sind teilweise maskiert, um die persönliche Identität der Benutzer zu bewahren.

Öffentliche IP

Dies ist die öffentliche IP adresse des Clients, die von der Cloud gesehen wird. Für Unternehmen ist dies die Adresse der Firewall, die die NAT ein. IP-Adressen sind teilweise maskiert, um die persönliche Identität der Benutzer zu bewahren.

MAC-Adressen

Die MAC-Adresse des Clientendpunkts.

Geolocation

Geografische Suche der öffentlichen IP-Adresse. Bei einer Verbindung über PNC ist diese Adresse nicht korrekt. Wenn der Benutzer die Webex-App verwendet und sich über ein VPN mit dem Unternehmen verbindet, ist der Standort nicht korrekt.

ISP

Internet Dienstleister, der Netzwerkverbindungen mit der Webex Calling Cloud bietet.

Netzwerk

Die Art der Netzwerkverbindung, die der Client zum Austauschen von Medien verwendet hat. Mögliche Werte sind:

  • WLAN

  • Ethernet

  • Zellulären

  • Unbekannt

Audio-Codec

(Senden oder Empfangen) Das von einem Client übertragene Mediencodierungs- und Dekodierungsformat für die Medien.

Video-Codec

(Senden oder Empfangen) Das von einem Client übertragene Mediencodierungs- und Dekodierungsformat für die Medien. Gilt nur für Videoanrufe.

SIP-Sitzungs-ID

Ursprüngliche (oder anfängliche) und endgültige Sitzungs-IDs.

Trunk

Nur verfügbar, wenn ein lokales Gateway am Hop beteiligt ist. Name des eingehenden und ausgehenden Trunks.

Routen-Gruppe

Nur verfügbar, wenn ein lokales Gateway am Hop beteiligt ist. Name der Routengruppe.

PSTN-Anbietername

Nur verfügbar, wenn PSTN am Hop beteiligt ist. Name des Anbieters.

Einige Metriken werden in den Artikel-Screenshots maskiert, um die Identität des Benutzers zu bewahren.

Aus den Hop-Details können Sie:

  • Zeigen Sie an, ob der Hop über PSTN oder ein lokales Gateway geroutet wurde.

  • Zeigen Sie den Benutzertyp an, der den Anruf getätigt oder empfangen hat. Einige Beispiele sind HuntGroup, VoiceMailGroupund RoutePoint. Der Detaillierte Anrufverlaufsbericht bietet eine Liste aller möglichen Benutzertypen.

  • Sehen Sie sich Einblicke in den Anruf in diesen Szenarien an:

    • Für keinen der mit dem Anruf verbundenen Hops gab es ein No-Media-Signal.

    • Die Einrichtung der Pfadoptimierung war nicht erfolgreich.

    • Einer der Hops ist fehlgeschlagen oder hat den Anruf abgelehnt. Fehlgeschlagene Hops werden rot und abgelehnte Hops gelb markiert. Außerdem wird ein Grund angegeben, warum der Hop fehlgeschlagen ist oder abgelehnt wurde.

  • Fahren Sie mit der Zeit auf das Gerät, um die End-to-End-Anruferfahrung zu sehen.

  • Bewegen Sie den H es auf den Hop zwischen dem Endpunkt und Webex Calling Cloud, um die Hop-Details anzuzeigen.

Das End-to-End-Anruferlebnis basiert auf den Medienqualitätsdaten, die am Ende des Anrufs von jedem bei Webex Calling registrierten Endpunkt (Webex-App oder Gerät wie 8865 oder Desk Pro) erfasst werden. Der Anruf wird als gut bewertet, wenn der Endpunkt die folgenden Schwellenwerte aufweist:

  • Paketverlust weniger als 5%.

  • Latenz oder Round Trip Time (RTT) weniger als 400 ms.

  • Jitter weniger als 150 ms.

Die Qualität des Hops wird aus Daten abgeleitet, die über den Medien-Relay-Punkt in der Webex Calling erfasst werden. Um PSTN CCPP oder einem lokalen Gateway zu tätigen, wird die Datensammlung aus der Webex Calling-Cloud und nicht aus dem PSTN-Endpunkt. Ein Hop wird als gut eingestuft, wenn der Medienrelaispunkt die folgenden Schwellenwerte aufweist:

  • Paketverlust unter 2,5 %.

  • Latenz oder RTT weniger als 200 ms.

  • Jitter weniger als 75 ms

Sie können die Daten auch in den Hopdetails speichern, indem Sie Aktionen auswählen und dann eine der folgenden Optionen wählen:

  • Anrufaufzeichnungen zur Fehlerbehebung speichern (CSV)
  • Anrufbericht speichern (JSON)
  • Teilnehmerdetails speichern (CSV)

Bereich „Anrufdetails“

Die folgenden Daten sind im rechten Bereich „Anrufdetails“ der Hop-Detailansicht verfügbar:

BegriffDefinition
Korrelations-IDBeziehungs-ID, um mehrere Anruf gleichzeitige Teilnessel derselben Anrufsitzung zu binden.
AnrufdatumDas Datum, an dem der Anruf stattgefunden hat.
AnrufzeitDie Uhrzeit, zu der der Anruf begonnen und beendet wurde, wird in der Zeitzone angezeigt, die Sie in der Suchansicht ausgewählt haben.
Sitzungstyp

Der Typ der unterstützten Sitzung. Zum Beispiel: Webex-Anruf

TeilnehmerDie Anzahl der Teilnehmer, die dem Anruf beigetreten sind.
AnrufernameName des Anrufers.
Anrufer-E-Mail-AdresseE-Mail-Adresse des Anrufers.
Nummer des AnrufersTelefonnummer, die der Anrufer während des Anrufs verwendet hat.
AudioDie Art der verwendeten Audiowiedergabe.
VideoZeigt Ja an, wenn Video von einem Teilnehmer aktiviert wurde. Wenn Video überhaupt nicht aktiviert wurde, wird Neinangezeigt.
Pfadoptimierung

Gibt an, ob die Anrufpfad-Optimierung auf den Anruf angewendet wird. Akzeptierte Werte sind:

  • ICE (Interactive Connectivity Establish)

  • PNC (Private Netzwerkverbindung)

  • Keine Optimierung

Anruftyp

Die Art des Anrufs kann eine der folgenden sein:

  • Notfall

  • Enterprise

  • International

  • Mobil

  • National

  • Vermittler

  • Premium

  • Kurzwahlnummer

  • Gebührenfrei

  • Unbekannt

  • URI

Anruf beendet durch

Benutzer, der den Anruf beendet hat.

Gewählte Ziffern

Die vom Benutzer gewählten Tastenfeld-Ziffern vor der Übersetzung.

Verwandter Grund

Gibt einen Grund an, warum der Hop erstellt wurde. Beispielsweise gibt der Wert CallQueue an, dass die Hoffnung auf einen Anrufversuch aus einer Anrufwarteschlange an einen Agenten zurückzuführen ist. Weitere Informationen zu zugehörigen Grundwerten finden Sie im detaillierten Anrufverlaufsbericht von Webex Calling.

Zugriff auf die Webex Calling-Fehlerbehebungsansicht

Die Teilsuche wird für E-Mail-IDs, Telefonnummern und Anruf-IDs unterstützt. Bei Telefonnummern können Sie die ersten drei bis acht Ziffern eingeben und dann die Eingabetaste drücken, um passende Einträge anzuzeigen. Wenn Sie mehr als acht Ziffern eingeben, versucht die Suche, eine genaue Übereinstimmung zu finden. Beachten Sie, dass Sie beim Kopieren und Einfügen einer Telefonnummer von woanders die +1 damit die Suche funktioniert.

Führen Sie die folgenden Schritte durch, um einen Webex-Anruf zu analysieren:

1

Melden Sie sich bei Control Hub an und gehen Sie zu Überwachung > Fehlerbehebung.

2

Suchen Sie nach der E-Mail-ID, Telefonnummer, MAC-Adresse, Anruf-ID oder Korrelations-ID, die Sie anzeigen möchten.

Mithilfe der Korrelations-ID können Sie in der Suchansicht verwandte Anrufe gruppieren.

3

Wenden Sie einen Filter Ihrer Wahl an. Die verfügbaren Filter sind:

  • Standort
  • Persönliche Qualität
  • Gerätetyp
  • Servicetyp

Wenn Sie nach Telefonnummern oder Korrelations-IDs suchen, sind keine Filter verfügbar.

4

Klicken Sie auf einen bestimmten Anruf, um die Hop-Detailansicht zu überprüfen.

Details zum Fehlerbehebungsanruf als CSV-Datei exportieren

Sie können Anrufdetails zur Fehlerbehebung als CSV-Datei exportieren. Das Exportieren dieser Anrufdetails ist bei komplexen Anrufen mit mehreren Hops nützlich, da Sie so Probleme oder Muster auf einen Blick erkennen können. Sie können bis zu 100 Details zu Anrufen zur Fehlerbehebung pro CSV-Datei exportieren.

1

Melden Sie sich bei Control Hub an und gehen Sie zu Überwachung > Fehlerbehebung.

2

Sobald Sie eine Liste der Anrufe haben, die Sie anzeigen möchten, wählen Sie Exportieren > Anrufaufzeichnungen zur Fehlerbehebung speichern (CSV).

Hervorgehobene Schaltfläche „Exportieren“ für gesuchte Anrufe bei der Fehlerbehebung im Control Hub

Beheben von Problemen mit der Medienqualität

Die Hop-by-Hop-Ansicht hilft Ihnen dabei zu finden, wo das Problem aufgetreten ist. Nun, da Sie den Ort des Problems gefunden haben und Sie mit den Metriken (Jitter, Paketverlust, Latenz) Folgendes versuchen können, um das Problem zu beheben.

Typische Möglichkeiten für Medienprobleme sind:

  • Network/ISP/location spezifische Probleme– Aufgrund der Firewall, der Netzwerkkonfiguration oder der Bandbreite gibt es ein Muster schlechter Erfahrungen an einem bestimmten Standort oder in einem bestimmten Netzwerksubnetz. Verwenden Sie die Ansicht zur Fehlerbehebung pro Anruf (identifizieren Sie den Standort, der mit der schlechten Sitzung in Verbindung steht) mit der Analyseansicht, um die Sammelmuster für den Standort zu überprüfen.

  • Benutzerspezifische Probleme– Ein Benutzer oder Gerät ist mit einem schlechten Netzwerk verbunden (z. B. WLAN oder Arbeit von zu Hause aus), was bedeutet, dass die Erfahrung des Benutzers durch die zugehörigen Netzwerkfunktionen beeinträchtigt wird. Informationen zum Identifizieren des Netzwerkproblems finden Sie im Artikel Verwenden Sie CScan, um die Netzwerkqualität von Webex Calling zu testen.

  • Anruftypspezifische Probleme– Die schlechte Erfahrung eines Benutzers ist auf die Qualität am anderen Ende zurückzuführen. Dies ist typisch für PSTN Szenarien, in denen der Benutzer mit einem anderen Benutzer in einem mobilen Netzwerk spricht und die Sitzung über eine hohe Paketverlust im PSTN verfügt.

  • Problem mit fehlenden Medien– In einigen Hops kann es zu keiner Medienübertragung kommen. Das Insights-Banner zeigt die Ursache oben auf der Hop-Detailseite und die haftende Partei im Informationsfeld der Hop-Detailseite an. Einige der möglichen Ursachen für das Fehlen von Medien in Anrufen sowie die haftbaren Parteien sind hier aufgeführt:

    • Webex empfängt keine Medien vom Absender.

    • Webex empfängt keine Medien vom Empfänger.

    • Webex empfängt aus keiner Richtung Medien.

    • Webex sendet keine Medien an den Empfänger. Die Webex-Technik befasst sich mit diesem Problem.

    • Webex empfängt keine Medien von Cloud PSTN. Die Webex-Technik befasst sich mit diesem Problem.

    • Webex empfängt keine Medien vom Cloud-Dienst. Die Webex-Technik befasst sich mit diesem Problem.

    • Webex empfängt keine Medien vom lokalen Gateway. Der Kundenadministrator muss das Problem untersuchen.

  • Fehler bei der Medienpfadoptimierung– Bei einigen Anrufen kann die Medienpfadoptimierung nicht erfolgreich eingerichtet werden. Das Insights-Banner zeigt den Grund für erfolglose ICE-Anrufe und die Lösung oben auf der Hop-Detailseite an.

    Einige der möglichen Gründe sind:

    • ICE aufgrund eines Stun-Serverzugriffs nicht erfolgreich – siehe Referenzinformationen zum Webex Calling-Port.

    • ICE aufgrund der Konnektivitätsprüfung nicht erfolgreich – überprüfen Sie die Konnektivität zwischen den Netzwerken.

    • ICE nicht erfolgreich, da die Standard-Pfad-Roundtrip-Zeit similar/better als jeder optimierte Pfad.

Beschränkungen

Für die folgenden Geräte sind keine Medienqualitätsmetriken sowie Ursprungs- und Zielflüsse von der Netzwerkseite verfügbar:

  • Analogtelefone

  • Geräte von Drittanbietern

  • IPv6-Endpunkte

Unterstützte Anrufabläufe

Die Medienqualitätsberichte werden vom Anrufer, den Anrufer-Endpunkten und den Medien-Relay-Stellen erfasst. Auf diese Weise kann eine Segmentierung der Medienerfahrung eingeengt und identifiziert werden, ob das Problem auftrat:

  • Anrufer oder Anrufer

  • Medienpfad zur oder von der Webex Calling Cloud.

Anrufschreiben werden angezeigt, wenn es eine Mediensitzung gab, die mit mindestens einem Webex Calling Endpunkt des Anrufs eingerichtet wurde. Beispiel: Bei einem ausgehenden Anruf von Sammelanschluss zu acht Agenten kann bei einer Antwort von nur einem Agenten keine Medienbehebung für die anderen sieben Agenten durchgeführt werden.

Es gibt fünf Arten von Medienerfahrungen oder Pfaden zur Webex Calling Fehlerbehebung, die folgenden sind:

  • On-Net-optimiert – Anrufe innerhalb der Organisation, bei denen ICE erfolgreich ist und die Medien direkt zwischen den Benutzern fließen. Weitere Webex Calling finden Sie unter Medienoptimierung mit Interactive Connectivity Connectivity Displays (ICE ).

  • On-Net nicht optimiert – Anrufe innerhalb der Organisation, bei denen die interaktive Konnektivitätsherstellung (ICE) nicht möglich war oder nicht hergestellt werden konnte. In diesem Szenario werden die Medien durch die Webex Calling-Cloud gestromt.

  • On-Net-Cloud-Hosting – Anrufe innerhalb einer Organisation, bei denen Medien von einem in der Cloud gehosteten Medienserver bereitgestellt werden (z. B. Abhören von Voicemail, Einwählen in eine automatische Vermittlung).

  • Off-Net-Anruf zum oder vom registrierten Webex Calling-Endpunkt -

    • über Cloud Connected PSTN Provider– Eingehende und ausgehende Anrufe einer Organisation, bei denen sich die andere Partei im PSTN-Netzwerk befindet. Die Medien werden über einen Cloud Connected PSTN Provider (CCPP) über eine hochwertige Zusammenschaltung weitervermittelt.

    • über lokales Gateway– Eingehende und ausgehende Anrufe einer Organisation, bei denen die Medien der anderen Partei über das Unternehmen laufen. Hinter dem lokalen Gateway kann die Mediensitzung vom im Unternehmen gehosteten Benutzer (z. B. für die Anrufsteuerung im Unternehmen registriert) oder von PSTN verwendet werden, wobei PSTN Unternehmen bereitgestellt wird.

Wenn sich zwei registrierte Benutzer Webex Calling, die an einem Punkt-zu-Punkt-On-Net-Anruf beteiligt sind, werden in der Fehlerbehebungsansicht Metriken für einen oder beide Parteien angezeigt. Wenn der Anruf aus dem Netz ist (Benutzer 1 erhält einen Anruf von einem PSTN-Benutzer), dann bietet die Problembehandlungsansicht nur die Client-Metriken von Benutzer1 sowie die Metriken, die von der Media Relay-Stelle aus geschaltet werden.

Die meisten Anrufszenarien in der Fehlerbehebungsansicht zeigen zwei Anrufanrufe (Anrufer und Anrufer); Bei einigen Anrufszenarien (wie Anruf parken oder abrufen) ist jedoch nur ein Anruf Bruchbruch zu sehen. In diesen Fällen wird das andere Gespräch in der Ansicht zur Fehlerbehebung separat angezeigt. Dies verhindert nicht die Fehlerbehebung des Anrufs und die Erkennung, wo das Problem aufgetreten ist. Es erfordert jedoch, dass der Administrator die beiden Anruf weiterveranruft und dabei eine gemeinsame Entität wie sich überschneidende Zeit verwendet. Zukünftige Verbesserungen an der Problembehandlungsansicht werden die Manuelle Suche nicht mehr benötigen.

Die Hop-Metriken variieren während einer Sitzung je nach Abtastzeit und Schwankungen im Netzwerk. Die vom Media Relay-Punkt und den Clients gemeldeten Werte (End-to-End-Experience) stimmen möglicherweise nicht zusammen. Sie sollten jedoch genau ausgerichtet sein, um eine Segmentierung entlang des Pfads zu ermöglichen.

Wir empfehlen die Verwendung der Anzeige zur Fehlerbehebung einzelner Aufrufe anhand der aggregierten Informationen, die aus Analytics abgeleitet werden.

Analysieren wir die Anrufqualität für die verschiedenen Anruftypen mithilfe der Problembehandlungsansicht.

Anrufe innerhalb der Organisation, in denen ICE erfolgreich ist, und das Medien relay in der Cloud wird aus dem Pfad entfernt. Der Medienfluss wird direkt zwischen den Geräten des Benutzers angezeigt.

Schlussfolgerung:

1

Der Anruf wird als gut bewertet, da sowohl der Anrufer als auch der Anrufer eine gute End-to-End-Erfahrung haben.

2

Der Administrator kann beobachten, dass Medien direkt zwischen den beiden Benutzern fließt und nicht durch die Webex Calling-Cloud reisen.

Optimierte Anrufabläufe können eine schlechte Erfahrung haben, wenn das Problem vom Unternehmens- oder lokalen Netzwerk stammt, da die Medien zwischen den beiden Benutzern das lokale Netzwerk durchqueren werden. Die Latenzzeit oder RTT ist bei einem optimierten Anruf immer niedriger, aber Paketverlust und Jitter können abhängig vom Netzwerk zwischen den beiden Benutzern weiterhin einen Faktor sein.

Anrufe innerhalb der Organisation, wo ein ICE-Anruf nicht erfolgreich war und die Medien durch die Webex Calling werden.

Schlussfolgerung:

Der Administrator kann Folgendes beobachten:

1

Die End-to-End-Erfahrung des Anrufers wird als schlecht bewertet.

2

Es besteht ein Problem mit dem Netzwerk-Hop des Anrufers, das sowohl den Sende- als auch den Empfangs-Stream beeinflusst.

3

Der Netzwerk-Hop des Anrufs hat kein Problem.

4

Die End-to-End-Erfahrung des Anrufers wird aufgrund des Problems des Anrufers als schlecht bewertet.

Anrufe innerhalb einer Organisation, in der die Medien von einem in Medienserver Cloud gehosteten Unternehmen bereitgestellt werden.

Schlussfolgerung:

Der Anruf wird so gut bewertet, wie das End-to-End-Erlebnis des Anrufers innerhalb der akzeptierten Schwellenwerte liegt. Der Administrator kann Folgendes beobachten:

1

Der Netzwerk-Hop für den Anrufer wird als schlecht bewertet, da einige der Metriken über dem zulässigen Schwellenwert liegen.

2

Der Sendestream aus der Voicemail wird nach den Metriken, die über die Medien-Relay-Stelle erfasst wurden, als gut bewertet.

3

Die Medienserver, mit der die Voicemail erfasst oder einhandt, enthält derzeit keine Metriken. Diese Server werden jedoch als Teil der Webex Calling Cloud gehostet und verwaltet, so dass die Qualität dieses Verbindungssegments intern und immer von hoher Qualität und niedriger Latenz ist.

4

Der Administrator kann beobachten, dass die End-to-End-Erfahrung des Anrufers als gut bewertet wird, obwohl der Hop als schlecht bewertet wird. Dies liegt daran, dass der Anrufer über ein gutes Netzwerk versiert ist, das die Leistungsverschlechterung des Anrufersnetzwerks kompensieren kann.

Anrufe von und zu einer Organisation, in der sich der andere Drittanbieter im PSTN befindet. Die Medien werden von einem Cloud Connected PSTN Provider (CCPP) übermittelt.

In diesem Beispiel kommen die Clientmedien von einem anbieterbasierten PSTN über die Cloud.

Der Anruf wird als schlecht bewertet, da die End-to-End-Erfahrung des Anrufs nicht innerhalb der akzeptierten Schwelle liegt. Der Administrator kann Folgendes beobachten:

1

Das Problem besteht im Hop des Anrufers PSTN speziell mit dem Sende-Stream.

2

Der Netzwerk-Hop des Anrufs hat kein Problem.

3

Die End-to-End-Erfahrung des Anrufers wird aufgrund des Problems des Anrufers als schlecht bewertet.

4

Die End-to-End-Erfahrung und die Empfang-Stream-Metriken des Anrufers, der sich im PSTN-Netzwerk befindet, sind derzeit nicht verfügbar, da diese Metriken nicht an die Webex Calling Cloud übertragen werden.

Anrufe in und aus einer Organisation, in der die Medien des Anrufers aus einem Unternehmen kommen. Die Mediensitzung kann von einem im Unternehmen gehosteten Nutzer sein (z. B. bei UCM registriert) oder von PSTN, wo die PSTN im Unternehmen bereitgestellt wird.

Ableitung

Der Anruf wird als schlecht bewertet, da die End-to-End-Erfahrung des Anrufers nicht innerhalb der akzeptierten Grenzwerte liegt. Der Administrator kann Folgendes beobachten:

1

Es gibt ein Problem mit dem Hop des Anrufers zur Webex Calling Cloud sowohl im Senden als auch im Empfangen-Stream.

2

Die End-to-End-Erfahrung des Anrufers wird entweder aufgrund des im Hop beobachteten Problems oder aufgrund von Problemen am Ende des Benutzers (Geräte, Netzwerk und so weiter) als schlecht bewertet.

3

Der eingehende Datenverkehr zur Webex Calling Cloud vom Ende des Anrufs wird als gut bewertet.

4

Die End-to-End-Erfahrung und die Empfang-Stream-Metriken des Anrufers, der vom lokalen Gateway angerufen wird, sind derzeit nicht verfügbar, da diese Metriken nicht an die Webex Calling Cloud übertragen werden.

Fehlerbehebung bei fehlgeschlagenen und abgelehnten Anrufen

Die Spalte Anrufstatus zeigt an, ob ein Anruf erfolgreich war, abgelehnt wurde oder fehlgeschlagen ist. Wenn ein Anruf den Status Ablehnung oder Fehler hat, können Sie mit der Maus über den Status fahren, um den entsprechenden Code anzuzeigen.

Wenn Sie einen Drilldown zur Anrufliste eines Benutzers durchführen, steht ein KPI Fehlgeschlagener Anruf zur Verfügung, um schnell zu erkennen, ob bei diesem Benutzer erhebliche Probleme auftreten. Sie können mit der Maus über den Status Ablehnung oder Fehler fahren, um den spezifischen Code anzuzeigen, der dem jeweiligen Status zugeordnet ist.

In der Hop-Detailansicht wird ein Banner angezeigt, das Ihnen weitere Informationen darüber liefert, warum der Anruf den Status Ablehnung oder Fehler hat. Sie können auch sehen, ob der Anrufstatus während des ursprünglichen oder des endgültigen Hops aufgetreten ist.

Beispiele für fehlgeschlagene Anrufszenarien

Fehlercode: Keine Route zum Ziel

Fehlercode: Beispiel für einen Fehlercode „Keine Route zum Ziel“ für einen Anruf in der Fehlerbehebung

Ein Anrufversuch wurde von einem Arbeitsplatzgerät unternommen, schlug jedoch fehl, da keine Route zum Ziel verfügbar war.

Fehlercode: Protokollfehler

Fehlercode: Beispiel für einen Protokollfehlercode für einen Anruf in der Fehlerbehebung

Ein Anrufversuch wurde von einem Arbeitsplatzgerät unternommen, schlug jedoch aufgrund eines protokollbezogenen Fehlers fehl.

Fehlercode: Interner Fehler

Fehlercode: Beispiel für einen internen Fehlercode für einen Anruf in der Fehlerbehebung

Ein Anruf wurde von einem lokalen Gateway getätigt, schlug jedoch aufgrund interner Fehler beim Arbeitsplatzgerät am Ziel fehl. Der Anruf wurde 14 Minuten lang aufgebaut, bevor ein interner Fehler auftrat.

Beispiel für Ablehnungsanrufszenarien

Ablehnungscode: Anruf abgelehnt

Hop-Detailansicht mit einem Ablehnungscode für abgelehnte Anrufe bei der Fehlerbehebung im Control Hub

Ein Anrufversuch ist fehlgeschlagen, weil das Ziel nicht erreicht werden konnte oder die Schnittstelle zum Ziel nicht richtig funktionierte. Beispiele für abgelehnte Szenarien sind die folgenden:

  • Anrufversuch wird aufgrund anonymer Anrufabweisung abgelehnt.

  • Der Anrufversuch wird aufgrund eingehender Anrufberechtigungen abgelehnt.

  • Der Anrufversuch wird aufgrund der Berechtigung für ausgehende Anrufe abgelehnt.

  • Der Anrufversuch wird aufgrund der Berechtigung für ausgehende Anrufe abgelehnt.

  • Der Anrufversuch wird aufgrund der konfigurierten Anrufabfangfunktion abgelehnt.

  • Der Anrufversuch wird aufgrund eines Fehlers beim Parken oder Abrufen des Anrufs abgelehnt.

  • Anrufversuch wird aufgrund einer Push-to-Talk-Ablehnung abgelehnt.

  • Anrufversuch wird aufgrund selektiver Anrufannahme abgelehnt.

  • Der Anrufversuch wird aufgrund der selektiven Anrufabweisung abgelehnt.

  • Anrufversuche werden aufgrund von Fehlern wie unbekannter Nummer, unzureichenden Berechtigungen usw. abgelehnt.

Fehlercode: Nicht zugewiesene Nummer

Ablehnungscode: Beispiel für einen Fehlercode für eine nicht zugewiesene Nummer bei der Fehlerbehebung

Ein Anrufer hat einen Anrufversuch unternommen, der jedoch abgelehnt wurde, da das Ziel eine nicht zugewiesene Nummer war.

Gründe für das Anrufergebnis

In der folgenden Tabelle sind die für erfolglose Anrufe verfügbaren Codes Ablehnung und Fehler aufgeführt.

Grund für AnrufergebnisDefinition

Erfolg

Anruf war erfolgreich. Mögliche Codes sind:

  • Normal – Anruf erfolgreich abgeschlossen.
  • UserBusy – Der Anruf war erfolgreich, aber der Benutzer ist beschäftigt.
  • NoAnswer – Der Anruf war erfolgreich, aber der Benutzer hat nicht geantwortet.

Ablehnung

Anruf wurde abgelehnt. Mögliche Codes sind:

  • CallRejected – Anrufversuch vom Empfänger abgelehnt.
  • UnassignedNumber – Die gewählte Nummer ist keinem Benutzer oder Dienst zugewiesen.
  • SIP408 – Zeitüberschreitung der Anforderung, da der Benutzer nicht rechtzeitig gefunden werden konnte.
  • InternalRequestTimeout – Zeitüberschreitung der Anforderung, da der Dienst die Anforderung aufgrund eines unerwarteten Zustands nicht erfüllen konnte.
  • Q850102ServerTimeout – Wiederherstellung bei Ablauf des Timers oder Server-Timeout.
  • NoUserResponse – Keine Antwort von einem Endbenutzergerät oder Client.
  • NoAnswerFromUser – Keine Antwort vom Benutzer.
  • SIP480 – Der Angerufene oder die angerufene Partei ist derzeit nicht verfügbar.
  • SIP487 – Die Anfrage wurde beendet, bevor der Anruf beantwortet wurde.
  • TemporarilyUnavailable – Der Benutzer ist vorübergehend nicht verfügbar.
  • LocalGatewayLoop – Schleife zwischen dem lokalen Gateway und Webex Calling erkannt.
  • AdminCallBlock – Anrufversuch wird aufgrund der Anrufsperrliste der Organisation abgelehnt.
  • UserCallBlock – Der Anruf an den Benutzer wird abgelehnt, da die Nummer auf der Sperrliste des Benutzers steht.
  • Nicht erreichbar – Der Anruf kann nicht an das gewünschte Ziel weitergeleitet werden.
  • UserAbsent – Der Benutzer ist vorübergehend nicht erreichbar oder nicht verfügbar.
  • Undefiniert – Keiner der oben genannten Gründe.

Fehler

Anruf fehlgeschlagen. Mögliche Codes sind:

  • DestinationOutOfOrder – Die Serviceanforderung ist fehlgeschlagen, da das Ziel nicht erreicht werden kann oder die Schnittstelle zum Ziel nicht richtig funktioniert.
  • SIP501 – Ungültige Methode und die Anforderungsmethode kann nicht identifiziert werden.
  • SIP503 – Der Dienst ist vorübergehend nicht verfügbar, daher kann die Anfrage nicht verarbeitet werden.
  • ProtocolError – Unbekannter oder nicht implementierter Release-Code.
  • SIP606 – Ein Aspekt der Sitzungsbeschreibung war nicht akzeptabel.
  • NoRouteToDestination – Keine Route zum Ziel verfügbar.
  • Intern – Aus internen Webex Calling-Gründen fehlgeschlagen.
  • MaxConcurrentTerminatingAlertingRequestsExceeded – Die Anzahl gleichzeitiger unbeantworteter Anrufe an ein lokales Gateway für denselben Anrufer und die angerufene Nummer hat den Grenzwert überschritten.
  • Undefiniert – Keiner der oben genannten Gründe.