Call Insights
Call Insights ermöglicht es Kunden, einen Call effizient zu bewerten, ohne sämtliche Call-Metriken durchgehen zu müssen. Die übergeordneten Informationen sind im Dashboard Call Debug Level verfügbar und werden durch das folgende Panel angezeigt, das oberhalb der Karte sichtbar ist:
Ein Klick auf das Panel öffnet das Dashboard Single Call Insights.
Auf dem Dashboard gibt es mehrere Tabellen, die Informationen über die Arten der gefundenen Insights, die davon betroffenen Benutzer und die Netzwerke liefern, in denen die betroffenen Benutzer gearbeitet haben. Insights setzen sich aus einer Analyse mehrerer Faktoren zusammen, die während des Calls in bestimmten Kombinationen auftreten. Sie weisen in der Regel auf ungewöhnliche oder potenziell problematische Situationen hin und können Administratoren dabei helfen, die Ursachen von Problemen schneller zu ermitteln. Die bisher ermittelte Liste der Insights ist unten aufgeführt und kann im Laufe der Zeit um weitere Insights erweitert werden.
Elemente:
- KPI’s: Liefern allgemeine Übersichtsinformationen über die Benutzer, für die Insights registriert wurden (ausgenommen Benutzer im Call ohne Insights!)
- Insights: Listet jeden einzelnen Insight pro Benutzer mit zusätzlichen Details zur Netzwerksituation des Benutzers während des Calls auf. Ein einzelner Insight kann mehrfach auftreten, und Benutzer können mehrere Insights haben, aber ein Insight kann nicht mehrfach für denselben Benutzer auftreten.
- Device Platform(s) Used: Zeigt für jeden Benutzer die Plattformen, die er/sie während des Calls verwendet hat, und gibt an, wann Wechsel stattgefunden haben.
- Network Switches During Call: Liefert Informationen darüber, ob Benutzer zwischen zwei verwalteten Netzwerken gewechselt haben.
Liste der Insights
Aktuelle Liste möglicher Insights
| Insight Message | Details |
|---|---|
| Potential Firewall Port Exhaustion Detected | Bedingungen: Es traten keine lokalen Netzwerkänderungen auf; ein einzelner Audiostream (der Benutzer erlitt keinerlei Disconnect); öffentlich zugängliche / externe NAT-Portänderungen traten während des Calls auf. Mögliche Maßnahmen? NAT-/Firewall-Konfiguration bzgl. Timeout-UDP-Binding-Einstellungen prüfen; Betriebssystem prüfen, ob eine Ressourcenbeschränkung vorlag (das OS hat möglicherweise das UDP geschlossen und ein neues recycelt); … |
| Audio stream was transferred between mobile and desktop versions of Teams | Dies kann darauf hindeuten, dass der Benutzer Probleme mit einem Gerät hat und wechselt, um zu sehen, ob es sich verbessert. Dies kann natürlich auch aus anderen Gründen geschehen. Mögliche Maßnahmen? Der Benutzer hat entschieden, den Call zu übertragen - qualitatives Feedback des Benutzers ist erforderlich |
| More than 5 BSSIDs were used | Das Gerät des Benutzers hat sich während des Calls mit mehr als 5 verschiedenen (eindeutigen) WLAN-Access-Points verbunden. Dies kann auftreten, wenn sich Benutzer während eines Calls bewegen, kann aber auch auf Benutzer hindeuten, die sich in einer Umgebung befinden, in der Access Points überlappende Bereiche abdecken. Dies kann ein unerwünschtes/unnötiges Wechseln zwischen Access Points verursachen und sich nachteilig auf die Call-Experience des Benutzers auswirken. Mögliche Maßnahmen? Beteiligte BSSIDs hinsichtlich des genutzten Channels prüfen; Abstand und Frequenz der beteiligten BSSIDs prüfen; das Client-Gerät zu zwingen, nur eine bestimmte Frequenz (z. B. 5 GHz) zu verwenden, könnte helfen, die Anzahl der Wechsel zu verringern |
| TCP was used for Audio traffic | UDP wird stets für die Performance empfohlen und von Microsoft Teams bevorzugt; TCP ist ein Fallback für unzuverlässige Verbindungen oder Fälle, in denen UDP blockiert ist. Benutzer, die während Calls TCP verwenden, können auf falsch konfigurierte Konfigurations- und/oder Netzwerkrichtlinien hindeuten. Mögliche Maßnahmen? Firewall auf dem OS prüfen, ob UDP zugelassen ist; Standort-Firewall prüfen, ob UDP zugelassen ist; prüfen, ob UDP für Remote Access (VPN) zugelassen ist |
| Non-default Audio Ports Detected | Audio sollte die lokalen Ports 50000-50019 verwenden. Andere Ports könnten dazu führen, dass QoS-Richtlinien den Traffic nicht identifizieren und priorisieren. https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams#step-3-choose-initial-port-ranges-for-each-media-type Mögliche Maßnahmen? Wenn die Einstellung beabsichtigt ist, stellen Sie sicher, dass die QoS-Einstellungen für Teams Voice diese UDP-Ports berücksichtigen |
| User Experienced Mid-Call Failure(s) | Wie vom Teams-Client und/oder von Call Records gemeldet. Dieser Insight wird von Microsoft identifiziert und erkannt. Mögliche Maßnahmen? Welche Netzwerkverbindung wurde verwendet? War sie aufgrund von WLAN volatil? Irgendwelche UDP-TCP-Verbindungen? Firewall-NAT-Timeout-Einstellungen prüfen; Antivirus- oder andere Sicherheitssoftware auf dem Client-Gerät prüfen; QoS-Einstellungen prüfen, sodass Teams Voice priorisiert wird; … |
| Mid-Call Network Disconnect/Reconnect | Windows OS erkennt ein Netzwerkänderungsereignis während des Calls. Dieser Insight wird von TrueDEM identifiziert und erkannt. Dieser Insight ist zuverlässiger als der Microsoft-Report (siehe vorheriger Insight). Idealerweise sollten beide Insights gleichzeitig erscheinen. Mögliche Maßnahmen? Welche Netzwerkverbindung wurde verwendet? War sie aufgrund von WLAN volatil? Irgendwelche UDP-TCP-Verbindungen? Firewall-NAT-Timeout-Einstellungen prüfen; Antivirus- oder andere Sicherheitssoftware auf dem Client-Gerät prüfen; QoS-Einstellungen prüfen, sodass Teams Voice priorisiert wird; … |
| Audio switched between wired and Wi-Fi In-Call | Der Teams-Audiostream wechselt während eines Calls zwischen WLAN- und kabelgebundenen Verbindungen, und dieser Wechsel war nicht das Ergebnis eines Netzwerkänderungsereignisses. Sowohl WLAN- als auch kabelgebundene Netzwerke wurden im selben Audiosegment verwendet. Mögliche Maßnahmen? Stellen Sie sicher, dass nur eine Konnektivität in Verwendung ist (kabelgebunden oder WLAN); das automatische Netzwerkwechseln unter Windows zu deaktivieren, könnte eine Option sein; den Flugmodus verwenden, während Sie über eine Ethernet-Verbindung verbunden sind; den Endbenutzer schulen; … |
| Multiple Audio Segments were used | Mehr als 1 eindeutiges Audiosegment UND keine Anzeichen für die zuvor aufgeführten Netzwerk- oder Teams-Probleme (Disconnect, Mid-Call-Failure usw.). Dies kann auf geräte- (Mikrofon) oder treiberbezogene Probleme zurückzuführen sein - fehlerhafte Hardware/veralteter Treiber. Es kann aber auch mit Codec-Wechseln oder OS-Aktivität zusammenhängen. Mögliche Maßnahmen? Gerät und Gerätetreiber prüfen; Konnektivität des Geräts prüfen (USB / Bluetooth); … |
| Audio traffic used a managed VPN | Der Audio-Traffic wurde über VPN (in einem verwalteten Netzwerk) geroutet. Mögliche Maßnahmen? Erwägen Sie die Verwendung von Split Tunneling. Dieser Insight ist eher informativer Natur. |
| AV1 codec detected in VBSS stream | AV1-Codec während des Screen-Sharings erkannt. AV1 ist ein hocheffizienter Codec. Er ist jedoch auf Sender-/Empfängerseite sehr ressourcenintensiv, da mehr Rechenleistung erforderlich ist, um den eingehenden Stream zu decodieren bzw. den ausgehenden Stream zu codieren. Beispielsweise kann jede Verzögerung beim Decodieren von AV1-Frames Lag oder verworfene Frames verursachen. Leider gibt es keine Möglichkeit, diesen Codec für VBSS abzuschalten. Der Teams-Client entscheidet dies automatisch und kann auf h264 zurückfallen. Mögliche Maßnahmen? Bildschirmauflösung senken - um Rechenleistung zu verringern; Hardware aufrüsten, da das Codieren/Decodieren von neueren GPUs profitiert; versuchen, andere unnötige Anwendungen während des Calls zu schließen |
| VBSS codec changes detected | Screen-Sharing-Codec-Wechsel während des Calls. HW oder SW / AV1 oder H264. Der Teams-Client entscheidet anhand bestimmter Bedingungen, welcher Codec verwendet wird, und fällt auf h264 hw, sw zurück. Diese Wechsel wirken sich in der Regel auf die Endbenutzer-Experience aus (Loss Rate, …) Mögliche Maßnahmen? Bildschirmauflösung senken - um Rechenleistung zu verringern; Hardware aufrüsten, da das Codieren/Decodieren von neueren GPUs profitiert; … |
| Video codec changes detected | Video-Codec-Wechsel während des Calls. HW oder SW, H264. Der Teams-Client und das Betriebssystem entscheiden anhand bestimmter Bedingungen, welcher Codec verwendet wird, und fallen auf h264 hw, sw zurück. Diese Wechsel wirken sich in der Regel auf die Endbenutzer-Experience aus (Loss Rate, …) Mögliche Maßnahmen? Der Teams-Anwendung eine Grafikkarte zuweisen, sodass eine GPU verwendet wird (für HW-En-/Decodierung); … |
| Audio codec changes detected | Audio-Codec-Wechsel während des Calls. SATIN, SATINFullband, Opus usw. Der Teams-Client entscheidet anhand bestimmter Bedingungen, welcher Codec verwendet wird, und fällt auf h264 hw, sw zurück. Diese Wechsel wirken sich in der Regel auf die Endbenutzer-Experience aus (Loss Rate, …). Mögliche Maßnahmen? Kabelgebundene Netzwerkverbindung verwenden; sicherstellen, dass QoS für Teams-Traffic vorhanden ist; Mute-/Unmute-Aktivitäten vermeiden; das Abspielen von Videos während des Screen-Sharings vermeiden; versuchen, den High-Fidelity-Modus nur in wenigen Fällen zu verwenden (um ständige Codec-Wechsel zu vermeiden); … |
| Spatial Audio Detected | Spatial Audio während des Calls erkannt. Der Spatial-Modus benötigt 4 Mb/s up und down im Vergleich zu SATIN, das lediglich 36k pro Richtung benötigt. Die Verwendung von Spatial Audio wirkt sich auf die Audioqualität aus. TrueDEM kann unterscheiden, ob Spatial Audio empfangen und/oder gesendet wurde. Typischerweise ist der Audio-Codec x-multichannel2 einer der Hinweise darauf. Mögliche Maßnahmen? Spatial Audio in Fällen mit eingeschränkter Netzwerkkonnektivität vermeiden; Audiotreiber aktuell halten; Traffic priorisieren (QoS); sicherstellen, dass der Endbenutzer eine Stereo-Ausgabe verwenden kann, andernfalls ergibt Spatial Audio überhaupt keinen Sinn; … |
| User transmitted streams with the potential to impact older devices | Der Sender verwendet AV1 oder Spatial Audio. Da Teams nicht transcodiert, müssen alle anderen Geräte (Empfänger) das Decodieren übernehmen (höherer Ressourcenbedarf) Mögliche Maßnahmen? Spatial Audio in Fällen vermeiden, in denen die Endbenutzergeräte alt sind; versuchen, den Videotreiber und die Videohardware zu aktualisieren; … |
| A firewall or other network equipment blocked traffic to a required IP address and port | MissingFWIPBlockExemptionRule in den Call-Daten weist typischerweise auf eine Firewall-Regel hin, die notwendigen Traffic blockiert, damit Teams-Calls korrekt funktionieren. Dies kann zu schlechter Call-Qualität oder sogar zu fehlgeschlagenen Calls führen. Mögliche Maßnahmen? Erforderliche Teams-IP-Adressen und -Ports für Teams-Traffic über die Netzwerkelemente hinweg prüfen; Firewall-Regeln auf dem lokalen Gerät prüfen |
| User Experienced Call Initialization Failure(s) | Dieser Insight erscheint, wenn ein Ereignis MissingFWIPBlockExemptionRule oder CallSetupFailure einen Initialisierungsfehler verursacht hat. Das Problem könnte entweder mit Firewall- und Netzwerkgründen oder mit anderen Ereignissen zusammenhängen, bei denen der Call-Aufbau nicht erfolgreich war. Mögliche Maßnahmen? Erforderliche Teams-IP-Adressen und -Ports für Teams-Traffic über die Netzwerkelemente hinweg prüfen; Firewall-Regeln auf dem lokalen Gerät prüfen; Stabilität der Netzwerkverbindung prüfen (WLAN, Ethernet); … |
| Multiple SSIDs Detected | Der Benutzer verwendete während des Calls mehrere verschiedene SSIDs. Mögliche Maßnahmen? Automatischen SSID-Wechsel vermeiden (Netzwerkeinstellungen); … |
Hinweis! Wenn die Spalte UserDisplayName die User-GUID(s) anstelle des tatsächlichen Benutzernamens anzeigt, dann existiert der Call Record von Microsoft für diesen Call noch nicht und wurde daher noch nicht eingebunden. Insights werden sowohl aus Echtzeitdaten als auch aus Microsoft-Call-Record-Daten abgeleitet; daher ist das Abwarten des vollständigen Datensatzes der empfohlene Weg, um alle Insights zu sehen.