Ein katastrophales Teams-Town-Hall-Meeting – wie OfficeExpert TrueDEM half, die Ursache zu isolieren

Eines der schwierigsten und frustrierendsten Dinge bei der Unterstützung von Benutzern, die schlechte Anrufe erhalten, ist es, alle richtigen Informationen zusammen zu bekommen. Es gibt so viele bewegliche Teile, die beeinflussen können, was die Nutzer während eines Anrufs erleben. Von der Authentifizierung über das Gerät und die Peripheriegeräte, das lokale Netzwerk und den ISP bis hin zur Microsoft Cloud selbst. Sie alle können eine Rolle für die Qualität eines Anrufs spielen. Und das alles multipliziert mit der Anzahl der Teilnehmer an dem Gespräch. Denn das Problem muss nicht von den Teilnehmern ausgehen, die es erleben.

Wir sehen oft, wie schwierig es ist, gegen schlecht empfundene Call Qualität vorzugehen, und das folgende Beispiel ist keine Ausnahme. Wir zeigen Ihnen, wie komplex es sein kann, herauszufinden, was los ist, und wie die Überwachung der Benutzererfahrung dabei helfen kann, die Ursache zu isolieren.

Bei einem unserer Kunden wurde ein großes Teams Town Hall Meeting mit fast 500 Teilnehmern geplant.
Die Teilnehmer kamen aus verschiedenen Orten und Zeitzonen, sowohl von zu Hause als auch vom Büro aus.
Die Organisatoren waren alle persönlich am selben Bürostandort anwesend.

Die Sitzung begann und alles lief gut, bis der Organisator die Stummschaltung eines Teilnehmers aufheben wollte. In die Diskussion einbeziehen. Das Aufheben der Stummschaltung schien nicht zu funktionieren, und stattdessen brach plötzlich die Tonqualität ein. 12 bis 15 Minuten lang beklagten sich die Teilnehmer darüber, dass sie Schwierigkeiten hatten, etwas zu hören oder zu verstehen. Rechnet man das auf die 500 Teilnehmer um, so ergibt sich ein potenzieller Produktivitätsverlust von mehr als 100 Stunden! Verständlicherweise sorgte dies für große Aufregung, bis hin zur Führungsebene. Daraufhin wurde die IT-Abteilung mit der Untersuchung des Vorfalls beauftragt.

Mit Hilfe von OfficeExpert TrueDEM werden wir uns dieses katastrophale Teams Town Hall Call ansehen, um herauszufinden, was passiert ist und was getan werden kann, um eine Wiederholung zu verhindern.

Die Audioqualität ist bei Microsoft Teams-Anrufen und -Besprechungen von entscheidender Bedeutung, da Audioprobleme in der Regel weitaus größere Auswirkungen haben als Probleme bei der gemeinsamen Nutzung von Bildschirmen oder Videos. Während unscharfe Videos, so ärgerlich sie auch sein mögen, eine Zeit lang toleriert werden können, kann eine schlechte Audioqualität die Kommunikation zum Erliegen bringen. Denn wenn ich Sie nicht sehen, aber hören kann, können wir kommunizieren. Wenn ich Sie nicht hören kann oder Ihr Ton verstümmelt ist, wird die Kommunikation unmöglich. Es sei denn, Sie können die Lippen lesen. Etwas, das die meisten von uns nicht können.

Zurück zu unserer Analyse. Um einen Microsoft Teams Call zu verstehen und zu analysieren, müssen Sie die Technologie verstehen. Die Art und Weise, wie Microsoft Teams Audio-, Video- und andere Daten überträgt.

Um einen Anruf zu übertragen, teilt Microsoft Teams die verschiedenen Eingänge (Audio, Video, Bildschirmfreigabe, Anwendungen usw.) in separate Streams auf. Diese werden wiederum in eingehende (was Sie von der Cloud erhalten) und ausgehende (was Sie an die Cloud senden) Ströme aufgeteilt. Je nachdem, um was es sich handelt, wird es dann weiter in winzige Pakete (Frames) aufgeteilt, die eine kleine Menge an Audio, Video usw. enthalten. Auf diese Weise ist die Größe jedes einzelnen übertragenen Pakets minimal. was wiederum bedeutet, dass die Auswirkungen von Paketverlusten minimal sind.

Microsoft Teams überträgt jede Sekunde Audio als eine Folge von 50 Frames, die jeweils bis zu 20 ms Sprachinhalt enthalten. Mit OfficeExpert TrueDEM verfolgen wir die Real Time Protocol-Pakete (Frames) in beide Richtungen in einem 30-Sekunden-Intervall. Für einen aktiv sprechenden Teilnehmer erwarten wir daher, dass pro 30-Sekunden-Intervall etwa 1.500 Audiopakete übertragen werden. Dies ist unabhängig von den Video- und anderen Paketen, die separat gesendet werden.

Da es sich um beim Town-Hall-Meeting um ein Teams Meeting handelte und der Ton ausgefallen ist, ist es sinnvoll, sich zuerst den Hauptredner anzusehen. Schließlich war dies die Person, die den Großteil der Audiosignale sendete, die andere nicht hören konnten.

Die folgende Abbildung zeigt, dass die Anzahl der von ihrem Gerät gesendeten Audiopakete gegen 19.00 Uhr (Beginn der Sitzung) auf das erwartete Niveau anstieg und bis etwa 19.51.30 Uhr auf diesem Niveau blieb. An diesem Punkt kommt es zu einem massiven Rückgang der gesendeten Pakete. Das erklärt, warum die anderen sie nicht hören konnten: Ihr Ton kam nicht in der Cloud an, und damit auch nicht bei den anderen Teilnehmern!

Wenn wir uns die Rohdaten dieses Nutzers ansehen, sehen wir den genauen Zeitpunkt, an dem das Problem beginnt und endet. Nur wenige Audiopakete schaffen es durch das System.

Dies dauerte fast 12 Minuten lang. Das deckt sich mit dem, was die anderen Nutzer sagten.

Jetzt, da wir genau wissen, wann das passiert ist, können wir herausfinden, was die Ursache dafür war?

Schauen wir uns zunächst die Netzwerkdaten an, da schlechte Netzwerkverbindungen oft zu schlechten Anrufen führen. Keiner der Organisatoren meldete Netzwerkprobleme, aber wie Sie wissen, sind WIFI-Verbindungen bekanntermaßen instabil. Es ist daher sinnvoll, dort anzusetzen.
Ein Blick auf die Daten zeigt, dass die Geschwindigkeit der ausgehenden Verbindung über die Zeit stabil war und zum Zeitpunkt des Auftretens der Probleme nicht abnahm.

Auffallend ist, dass das Gerät um die Zeit, in der das Audioproblem auftrat, eine große Menge an eingehenden Daten empfing (siehe erste Grafik unten).

Dieser zusätzliche eingehende Verkehr scheint hauptsächlich auf eingehende Videostreams zurückzuführen zu sein. Ein Beweis dafür ist die Tatsache, dass die ersten Videopakete eintreffen (siehe unten).

~2Mbits/sec eingehender Videodatenverkehr ist normal für den Empfang eingehender Videostreams, aber es ist interessant zu sehen, dass die 2Mbit/sec nur für 2-3 Minuten vorhanden waren und dann auf fast Null abfielen. Dies könnte darauf hindeuten, dass der Nutzer, der das Video gesendet hat, einfach seine Kamera abgeschaltet hat. Oder dass auch Videoströme nicht mehr durch das System liefen.

Wenn wir uns ansehen, wer Videos „gesendet“ hat, stellen wir schnell fest, dass nur ein anderer Nutzer dies getan hat, und zwar der Nutzer, dessen Stummschaltung aufgehoben war. Wenn man sich die Daten ansieht, scheint es so, als hätten sie ihre Kamera nach zwei Minuten einfach geschlossen. Die Spitze der eingehenden Videodaten war also wie erwartet und hielt nur so kurz an, weil der andere Benutzer seine Kamera anhielt.

Wenn es also nicht am Netzwerk lag, war es etwas, das auf dem Gerät geschah?

Der nächste Schritt besteht darin, genauer zu untersuchen, was auf dem Gerät des Hauptsprechers passiert. Der Benutzer, bei dem wir den Abfall der gesendeten Pakete gesehen haben.

Ein Blick auf die TrueDEM-Daten zeigt, dass dieser Benutzer nur Teams ausführte und alle anderen Programme geschlossen hatte. Die CPU- und RAM-Auslastung lag im normalen Bereich und zeigte nichts, was 12 Minuten schlechten Ton erklären würde. Tatsächlich wiesen CPU und RAM zu dem Zeitpunkt, als die Probleme auftraten, keine nennenswerten Spitzenwerte auf.

Könnten periphere Eingabe- und Ausgabegeräte eine Rolle gespielt haben?

Als Nächstes sehen wir uns an, welche Erfassungs- und Rendering-Geräte verwendet werden. Die folgende Tabelle zeigt, dass der Benutzer ein peripheres AV-Produktionssystem namens AV Bridge MatrixMIX verwendet hat, um das Gespräch zu führen. Dabei handelt es sich um ein Hardware-Tool, das bei der Leitung großer Besprechungen wie z. B. einer Teams Town Hall hilft und u. a. die Verwaltung von Audio und Video unterstützt.

Wir sehen, dass zu dem Zeitpunkt, an dem der Organisator des Town Hall Teams Meetings versucht, die Stummschaltung des Teilnehmers aufzuheben, das Rendering des eingehenden Videos beginnt. Wir wissen bereits, dass dies darauf zurückzuführen ist, dass der Teilnehmer, der nicht stummgeschaltet war, seine Kamera aktiviert hat. Also nicht unbedingt etwas, was man nicht erwarten würde.

Verdächtig ist jedoch, dass genau in diesem Moment auch Probleme mit dem Ton auftreten.

Wie jeder, der sich in dieser Situation befindet, versucht der Redner, das Problem auf verschiedene Weise zu lösen. Dazu gehört anscheinend auch das Anhalten der Kamera und der Wechsel des Audiosystems um ~8:02 Uhr. Von diesem Moment an verwendet das System das interne Audio (AMD High Definition Audio Device) anstelle der AV-Audio-Bridge und dies scheint das Problem endlich zu lösen, da in diesem Moment die Audiopakete wieder ausgegeben werden und die Audioprobleme verschwinden.

Also, hat das das Ausschalten des Audiosystems das Problem gelöst, oder war das Ausschalten der Kamera auch ein Faktor?

Wir sehen (in der obigen Tabelle), dass die Kamera nach einigen Minuten (~20:07) über das AV-Bridge-System reaktiviert wird. Ohne die Anzahl der Audiopakete zu beeinträchtigen. Es ist daher sehr wahrscheinlich, dass das Ausschalten des Videos durch den Hauptlautsprecher in diesem Fall keine Rolle gespielt hat.

Aus den von OfficeExpert TrueDEM aufgedeckten Fakten lässt sich folgendes ableiten:

Das Teams Town Hall Meeting funktionierte einwandfrei, bis der nicht stummgeschaltete Teilnehmer hinzugefügt wurde.

In diesem Moment scheint das AV-Produktionssystem, das der Hauptredner für Video und Audio verwendet, Probleme bei der Übertragung von Audio zu haben (Audio-Pakete fallen innerhalb einer Minute von 1500 auf fast 0). War es das Aufheben der Stummschaltung des Teilnehmers, die plötzlich eintreffenden Videodaten, als der aufgeschaltete Teilnehmer seine Kamera aktivierte? Oder war es vielleicht, so unwahrscheinlich es auch erscheinen mag, reiner Zufall, dass es genau in diesem Moment geschah? Das ist schwer zu sagen.

Tatsache ist, dass das Problem eindeutig von dem Hauptsprecher ausging (keine ausgehenden Audiopakete) und höchstwahrscheinlich von dessen externen AV-Produktionssystem verursacht wurde. Die Umstellung von der Verwendung des externen AV-Bridge-Audiosystems auf das interne Geräte-Audio schien das Problem zu beheben.

Der Aufruf war geprobt worden, und nichts von dem, was die Organisatoren taten, einschließlich der Stummschaltung eines Teilnehmers, war falsch. Mit dem Wissen, dass es sich höchstwahrscheinlich um das AV-Produktionssystem handelte, von dem es ausging, und dass das eingehende Video wahrscheinlich der Auslöser war, können jedoch bestimmte allgemeine Empfehlungen ausgesprochen werden, die für die künftige Verwendung überprüft werden sollten: