Teams Audio Troubleshooting

Auf dieser Seite möchte ich die Schritte beschreiben, mit denen ein Anwender oder IT-Personal Probleme bei Team Audio/Video vorgehen können.

Grundlagen

Ehe wird direkt in die Analyse gehen, sollten Sie kurz verstehen, was Teams bei Audio und Video eigentlich macht.

  • Gegenstellen identifizieren
    Jegliche Audio/Video-Kommunikation ist immer eine 1:1-Verbinung zwischen zwei Teilnehmern. Der Teams-Client verbindet sich direkt über über ein Media Relay mit einem anderen Teams Client, der Teams Konferenzzentrale oder bei Telefonanrufen mit Local Bypass mit dem lokalen VoIP-SBC. Das ist schon der erste Anhaltspunkt. Wenn in einem Meeting nur ein Teilnehmer Probleme hat, dann sollten Sie dessen Verbindung untersuchen und nicht das Meeting als solches.
  • Optimalen Weg bestimmen
    Auch wenn es eine 1:1-Verbindung ist, gibt es verschiedene Optionen. Teams versucht immer direkt eine UDP-Verbindung über bekannte Ports aufzubauen, Wenn dies nicht geht, dann versucht Teams eine TCP-Verbindung und im Worst Case eine HTTPS-Tunnel-Verbindung. Wenn Sie ihre Netzwerk korrekt konfiguriert haben, dann sollten Sie direkt wissen, an welcher Stelle die Pakete vorbei kommen, um Sie später per Firewall-Log oder WireShark zu finden.
    Wenn Sie ihr Netzwerk noch nicht auf Team "optimiert" haben, dann sollten Sie dies möglichst schnell nachholen. Das geht deutlich schneller und ist nachhaltiger als lange eine Fehlersuche.
  • Umgebung bestimmen
    Neben dem installierbaren "Teams.exe"-Client gibt es noch Teams im Browser, Teams auf IOS/Android und Raumsysteme. Wenn Sie mehrere Clients haben, dann können Häufungen von Problemen nach Software, Client, Netzwerk o.ä. korrelieren, um so die Ursache einzugrenzen

Bei der Fehlersuche von Audio/Video-Problemen müssen Sie sich immer vor Augen halten, dass Sie den Kanarienvogel im Netzwerk bei Laune halten. Realtime-Traffic reagiert sehr sensibel auf jegliche Probleme im Netzwerk.

Es gibt keine immer passende Reihenfolge zur Fehlersuche und ein versierter Supporter wird schon anhand der Fehlerbeschreibung einen ersten Verdacht hegen, und entsprechend diesem als erstes Nachgehen. Wenn Sie aber weniger Erfahrung haben oder gar keine Idee zum Fehler haben, dann würde ich folgende Schritte durchlaufen:

Call Analytics

Mein erster Anlaufpunkt sind die Daten von "Call Analytics" im Teams Admin Center. Ich gehe dazu unter https://admin.teams.microsoft.com/users auf den jeweiligen Benutzer und dort auf den Reiter "Meetings&Call". Dort finde ich zwar auch die aktuellen Calls aber wenn das Problem einen vergangen Anruf betrifft, dann ist "Past Meetings" der richtige Punkt. Anhand des Zeitpunkts der Verbindung sollte der Eintrag einfach zu finden sein.

Ein erster Indikator könnte die "Dauer" des Anrufs sein. Damit lassen sich sehr schnell gar nicht korrekt aufgebaute Verbindungen ermitteln.

Sie sehen hier aber noch keinen "Status" der Verbindung, wenn jede Verbindung hat ja mindestens zwei Endpunkte und mehrere Streams. Der nächste Dialog unterscheidet sich dann bei einem Meeting und einem 1:1 Telefonat. Beim Telefonat sehen Sie gleich die beiden Partner mit einigen Übersichtsdaten.

Hier ist aber nur erst einmal ein erster Status zu sehen. Auch wenn hier "Good" steht, muss das noch nichts heißen. Bei einem Meeting sehen Sie erst die Liste der Teilnehmer, bei denen Sie bei "Participant details" auch die individuelle Dauer und zumindest die von Teams eingeschätzte Audio-Qualität anzeigt:

Hier müssen Sie dann auf die Startzeit klicken, um Details zu dem jeweiligen Stream zu erhalten.

Leider zeigt Microsoft hier nicht das "Rate my Call"-Feedback des Anwenders an.

Allerdings können Sie das Icon "Network" anwählen, um erste Details zu sehen:


Auszug für einen Stream aus dem Teams Admin Center.

Die gleichen Daten und mehr Details finden Sie auch im Reiter "Advanced" pro Stream.

Die angegebenen Sollwerte sind nicht absolut zu nehmen, das Sie nur einen Teil wiedergeben und Microsoft selbst an unterschiedlichen Stellen auch unterschiedliche Werte veröffentlicht. Es gibt daher Unterschiede zwischen den "Sollwerten" bei einem Assessment und den tolerierbaren Werten im Betrieb. Zudem hat jeder Benutzer eigene Befindlichkeiten.

Bereich Wert Soll
 Beschreibung

Connectivity

Network ConnectionType

 

Es macht einen Unterschied, ob jemand per WLAN, LAN oder WWLAN online war. LAN ist immer am besten. WLAN kann OK sein, aber dann interessiert mich die Signalstärke.

Connectivity

Wi-Fi signal strength

besser als -65dBm

Bei WLAN sollten Sie die Signalstärke kontrollieren. Sie wird als "Dämpfung" mit einem "Minus" davor angegeben.

  • 0 bis -50dBm OK
  • -51 bis -64dBm geht noch aber kommt an die Grenze
  • -65 dBm: bei so starker Dämpfung dürfet die Verbindung nicht dauerhaft gut genug sein.

In dem Zuge können Sie natürlich auch noch die WiFi Handovers  (Wechsel der Antenne), die Frequenz (2,4GHz ist schlechter als 5 GHz) etc. betrachten,

Inbound Nework und Outbound Network

 Average round-trip time
Maximum round-trip time 		<100ms
<500ms

Microsoft fordert 100ms als maximale RTT eines Clients zum Media Relay. Das ist aber beim Assessment und nicht im Betrieb. Wie beim TÜV muss bei der Prüfung das Profil noch ausreichend sein, auch wenn es später etwas schlechter ist.

Aber natürlich sind lange Latenzzeiten störend. Meist sehe ich 25-50ms, wenn das Meeting auf dem gleichen Kontinent sind. Höhere Werte sind möglich, wenn Sie z.B. Teilnehmer in einem US-Meeting sind. Da sind dann auch 200ms erst einmal nicht alarmierend.

Inbound Nework und Outbound Network

 Average jitter
Maximum jitter

<30ms

Der Jitter ist ein Maß wie gleichmäßig die Pakete übertragen werden. Wenige Millisekunden sind in Ordnung. Wenn da aber z.B. 30ms oder mehr stehen, dann ist das zumindest bei Gesprächen /Meetings innerhalb des gleichen Kontinents zu untersuchen.

Hohe Jitter-Werte können aber auch ein Hinweis darauf sein, dass die A/V-Daten durch einen TCP-Tunnel laufen, so dass ein Paketloss indirekt über den Jitter gemessen wird.

Inbound Nework und Outbound Network

 Average packet loss rate
Maximum packet loss rate

<5%

Paketverlust kommt in einem Netzwerk eigentlich nicht vor, es sei denn irgendwo gibt es eine Überlastsituation, so dass ein Router ein Paket verwerfen muss. Wenn WiFi genutzt wird, kann der Wert auch etwas höher sein. Microsoft setzt <1% als Ziel aber und sie sollten den "Normalwert" ihrer Verbindungen kennen, um Abweichungen zu finden.

Leider ist selbst Microsoft nicht konsistent, welche Werte für Teams nun richtig sind.

Wir haben uns bei Rimscout für die Werte 100ms für Warnung und 500ms für Fehler entschieden, um sowohl die Assessment-Anforderungen zu prüfen als auch nicht überempfindlich zu sein.
Weitere Informationen zu Rimscout finden Sie hier https://www.rimscout.com

Ein paar Informationen finden Sie aber nur auf der Karteikarte "Debug":

Bereich Wert Beschreibung

Report

Connectivity_ICEWarn

Die Skype for Business Administratoren sollten schon länger die Funktion von ICE und Kandidaten und die Bedeutung der Zahl kennen. Jedes Bit jat eine eigene Bedeutung.

Report

 Connectivity_MediaPathLocal
Connectivity_MediaPathRemote

Dieses Feld zeigt das verwendete Protokoll für die erste Teilstrecke von Client zum Mediarelay und der Remote-Path ist der Weg vom Mediarelay zum nächsten System.

  • HostUDP
    Der Client konnte direkt per UDP den High-Port der anderen Seite erreichen. Das ist der optimale Weg und sollte zumindest im internen LAN und mit Local Media der Regelfall sein.
  • StunUDP
    Der Client konnte per STUN über UDP mit der Gegenstelle sprechen. Das ist immer noch gut.
  • TurnUDP
    Anscheinend ist eine direkte Verbindung nicht möglich aber eine TURN-Verbindung per UDP zum TURN-Server ist immer noch tolerierbar.
  • PeerDerived
    Der PC ist hinter einer "FullCone"-Firewall und kann nur über den TURN-Server gehen.
  • *TCP
    Jeder andere Wert ist zumindest zu überprüfen, denn Microsoft schreibt sehr deutlich, dass die Teams Services per UDP erreichbar sein müssen. Prüfen Sie genau, warum der Client an dem Standort keine Verbindung per UDP aufbauen konnte

Im Debug-Bereich kommen die Felder und Wert mehrfach vor. Bei einem Meeting gibt es diese Details natürlich pro Teilnehmer, bei denen ja jeder eine 1:1 Verbindung zur Konferenzmitte aufbaut.

Teams Client Logs

Im Call Analytics finden Sie nur Meldungen von Clients, die einen Call ausführen konnten. Auch der Teams Client protokolliert diverse Aktionen in einem Art Ringbufffer, d.h. die älteren Einträge werden durch neuere Einträge immer wieder überschrieben. Über den Hotkey "CTRL-ALT-SHIFT-1" kann der Client angewiesen werden, die aktuellen Logs ins "Downloads"-Verzeichnis zu exportieren. Diese Textdateien zeigen zwar nicht direkt entsprechende RTP-Daten aber sie können so mal schnell prüfen, ob der Anwender die richtigen Richtlinien anwendet.

Firewall Logs/WireShark/SFlow u.a.

Neben der Analysen auf dem Teams Client und im Teams Admin Center können Sie natürlich auf dem Netzwerk nachschauen. Audio- und Video-Pakete lassen sich aufgrund ihrer Menge, Größe und verwendeter Ports recht gut erkennen.

Wenn es um 1:1 Anrufe im lokalen LAN geht, dann sollten sie auf der Firewall von dem Client keine A/V-Pakete finden, da die Kommunikation intern erfolgen sollte. Etwas anders sieht es bei einem Homeoffice-User ohne VPN. Hier muss die Kommunikation über das Teams Media-Relay laufen, wenn ihre Firewall nicht zu freizügig ist. Bei einer Tunnel-VPN-Verbindung kann es aber wieder eine interne Verbindung sein und bei Meetings muss der Client seine Daten immer zur Microsoft Cloud senden.

Wie die beiden Endpunkte letztlich die Verbindung aufgebaut haben, sehen Sie in "Call Analytics" aber erst nachdem der Call beendet wurde. Sie könnten allenfalls die Realtime Analytics-Funktion nutzen. Häufig ist aber eine direkte Kooperation zwischen Teams Admin und Netzwerk/Firewall-Admin nicht möglich.

Als Firewall-Admin würde ich daher einen Trace oder Flow-Monitor auf die IP-Adresse des Teams Clients einrichten und so die verschiedenen Verbindungen erfassen. Wer direkt Zugriff auf den Client hat, kann dort natürlich auch Programme wie WireShark oder Packetbeat installieren. Ohne Client-Zugriff wäre ein Mirror-Port am Netzwerk das Logging der Firewall oder die NetFlow/sFlow/IPFix/cFlow-Funktionen ihrer Router und Switches gefragt. Also Filterkriterien können Sie heranziehen;

  • Port 50.000-50.059/UDP
    Der Client nutzt diese empfohlenen Ports bei entsprechender Konfiguration durch den Administrator als SourcePort beim Versand und nimmt über diese Ports eingehende Pakete an
  • Port 3478-3481/UDP
    Über diese vier UDP-Ports kommuniziert der Client mit dem Media Relay in der Cloud
  • Port 443/TCP
    Diesen Port nutzt Teams per HTTPS zur Signalisierung. Allerdings kann Teams bei einer Blockade der UDP-Verbindung auch diesen Port für die A/V-Daten nutzen. Sie erkennen das dann natürlich ein sehr vielen Paketen pro Sekunde, wodurch sie klar von der Datenkommunikation per HTTPS zu unterscheiden sind
  • IP-Subnetze 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/39
    Microsoft hat die IP-Subnetze der Teams Media Relays zusammen mit anderen Adressen veröffentlicht. Sie dazu auch IP-Adressen vertrauen. Hinter diesen Adressen verbergen sich die Media Relay und Konferenz-MCUs

Mit dem Wissen, welche Verbindung „gewünscht“ ist  (also z.B. UDP/3479=Audio) kann man in Firewall-Logs schauen, was durchgegangen ist oder geblockt wurde.

Teams Chromium Debugger

Wenn Sie bis dahin immer noch nicht die Ursache gefunden haben, dann können Sie auf dem Client in die Tiefen des Chromium Debuggers hinabsteigen. Wenn Sie Teams im Browser nutzen, dann sollte die F12-Taste den Debugger starten. Wer Teams als installiere EXE-Datei nutzt, drückt erst 7x mit der linken Maustaste auf das Teams-Icon neben der Uhr in der Taskleiste um dann mit der rechten Maustaste das Debugging-Menü zu starten. Hier können Sie dann Teams wahrlich auf die Finger schauen und in den Protokolle nach gewissen Schlüsselworten suchen, um Probleme bei der Rufnummernnormalsierung oder dem Verbindungsaufbau zu analysieren

Die Details hierzu werde ich später auf einer eigenen Seite beschreiben.

Call Quality Dashboard

Microsoft Teams liefert noch zwei weitere Dashboards für die Analyse von Audio/Video-Verbindungen. Beide ist weniger dafür geeignet, einen einzelnen Call genauer zu verfolgen sondern liefern eher einen Überblick und gruppieren Daten nach Standorten, Subnetzen, Headsets etc., um so Gemeinsamkeiten und Unterschiede zu erkennen. Wenn ein Client z.B. in einem Call eine schlechte Performance hatte, dann wäre es schon interessant die gleiche Information von allen Calls aller gleichartigen Clients zu haben, z.B. im gleichen Subnetz,

  • CQD-Dashboard https://cqd.teams.microsoft.com/spd
    Das ist einmal das "alte" CQD-Dashboard, welches nochi die Farbe und den Fair von Skype for Business hat und einen Überblick über alle Anrufe der letzten 30 Tage liefert.
  • PowerBI Dashboard
    Die zweite Option ist PowerBI mit dem von Microsoft bereitgestellten Connector

    Die Performance im "Direct Query"-Mode ist sehr träge aber die Auswertungen sind sehr leistungsfähig und die Wartezeit wert, wenn Sie wissen, nach was sie suchen müssen.

Beide Reports können also helfen, ob das gerade bearbeitete Problem sich nur auf einen Client bezieht oder sich auf einen Standort, auf ein Headset o.ä. Gemeinsamkeiten mit anderen Faktoren.

Weitere Links