Eine katastrophale Team-Rathaussitzung – Wie OfficeExpert TrueDEM half bei der Eingrenzung der Ursache

Eines der schwierigsten und frustrierendsten Dinge bei der Unterstützung von Benutzern, die Probleme mit Anrufen haben, besteht darin, alle richtigen Informationen zusammenzutragen. Es gibt so viele bewegliche Teile, die beeinflussen können, was Benutzer 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. Alles kann eine Rolle bei der Qualität eines Anrufs spielen. Und das alles multipliziert mit der Anzahl der Teilnehmer des Anrufs. Denn das Problem muss nicht unbedingt bei den Teilnehmern selbst liegen.

Wir sehen oft, wie schwierig es ist, mit schlechten Anrufen umzugehen, und das folgende Beispiel bildet da keine Ausnahme. Wir erklären Ihnen, wie komplex es sein kann, herauszufinden, was vor sich geht, und wie die Überwachung der Benutzererfahrung dabei helfen kann, die Ursache zu isolieren.

Ein großes Team Bürgerversammlung war mit knapp 500 Teilnehmern bei einem unserer Kunden geplant.
Die Teilnehmer kamen aus verschiedenen Standorten und Zeitzonen, sowohl von zu Hause als auch von Bürostandorten aus.
Die Organisatoren waren alle persönlich am selben Bürostandort.

Das Meeting begann und alles lief gut, bis der Organisator die Stummschaltung eines Teilnehmers aufheben wollte. Bringen Sie sie auf dem Bildschirm in die Diskussion ein. Das Aufheben der Stummschaltung schien nicht zu funktionieren und stattdessen begann plötzlich die Audioqualität zu versagen. 12 bis 15 Minuten lang beklagten sich die Teilnehmer darüber, dass sie Schwierigkeiten hatten, zu hören oder zu verstehen, was vor sich ging. Wenn man das mit den 500 Teilnehmern vergleicht, ergibt sich ein potenzieller Produktivitätsverlust von mehr als 100 Stunden! Verständlicherweise sorgte dies selbst auf C-Ebene für großen Aufruhr. Infolgedessen wurde die IT-Abteilung damit beauftragt, den Vorfall zu untersuchen.

Mit Hilfe von OfficeExpert TrueDEM, wir werden uns diesen katastrophalen Aufruf im Rathaus des Teams ansehen, um zu sehen, was passiert ist und was für PR getan werden kannevent dass es nicht wieder passiert.

Die Audioqualität ist bei Microsoft Teams-Anrufen und -Besprechungen von entscheidender Bedeutung, da Audioprobleme tendenziell weitaus größere Auswirkungen haben als andere, bei denen eine Bildschirmfreigabe oder Videoübertragung erforderlich ist. Wo verschwommenes Video, so nervig es auch sein mag, für eine Weile toleriert werden kann; Eine schlechte Audioqualität kann die Kommunikation zum Erliegen bringen. Denn wenn ich Sie nicht sehen, aber trotzdem 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 beherrschen die Gebärdensprache. Etwas, das die meisten von uns nicht tun.

Zurück zu unserer Analyse. Um einen Microsoft Teams-Anruf 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 Eingaben (Audio, Video, Bildschirmfreigabe, Anwendungen usw.) in separate Streams auf. Teilen Sie diese noch einmal auf Inbound (was Sie aus der Cloud erhalten) Streams und outbound (was Sie an die Cloud senden) Streams. Je nachdem, um was es sich handelt, wird es dann weiter in winzige Pakete (Frames) aufgeteilt, die eine kleine Menge an Audio, Video usw. darstellen. Auf diese Weise ist die Größe jedes einzelnen übertragenen Pakets minimal. was wiederum bedeutet, dass wenn Pakete gehen verloren, die Auswirkungen werden minimiert.

Microsoft Teams überträgt jede Sekunde Audio als eine Folge von 50 Frames, die jeweils bis zu 20 ms Sprachinhalt enthalten. Mit OfficeExpert TrueDEM Wir verfolgen die Real Time Protocol-Pakete (Frames) in beiden Richtungen in einem 30-Sekunden-Intervall. Für einen aktiv sprechenden Teilnehmer gehen wir daher davon aus, dass in jedem 1,500-Sekunden-Intervall etwa 30 Audiopakete übertragen werden. Dies ist unabhängig davon, dass Video- und andere Pakete separat gesendet werden.

Da es sich um ein Team-Town-Hall-Meeting handelte und der Ton nicht funktionierte, ist es sinnvoll, zunächst den Hauptredner anzuschauen. Dies war schließlich die Person, die die meisten Audiosignale sendete, die andere nur schwer verstehen konnten.

Das folgende Bild zeigt, dass gegen 7 Uhr (Beginn des Meetings) stieg die Anzahl der von ihrem Gerät gesendeten Audiopakete auf das erwartete Niveau und blieb auf diesem Niveau bis etwa 7:51:30 Uhr. Zu diesem Zeitpunkt sehen wir einen massiven Rückgang der gesendeten Pakete. Dies erklärt, warum andere sie nicht hören konnten; Ihr Ton gelangte nicht in die Cloud und damit auch nicht zu den anderen Teilnehmern!

Wenn wir uns die Rohdaten für diesen Benutzer ansehen, sehen wir den genauen Zeitpunkt, zu dem das Problem beginnt und endet. Nur wenige Audiopakete gelangen durch das System.

Dies dauerte fast 12 Minuten. Was mit den Aussagen der anderen Benutzer übereinstimmt.

Jetzt wissen wir es also genau wann Das ist passiert. Können wir herausfinden, was die Ursache war?

Schauen wir uns zunächst die Vernetzung an, da schlechte Netzwerkverbindungen häufig zu schlechten Anrufen führen. Keiner der Veranstalter meldete Netzwerkprobleme, aber wie Sie wissen, sind WLAN-Verbindungen bekanntermaßen instabil. Daher ist es sinnvoll, dort anzufangen.
Wenn wir uns die Daten ansehen, können wir sehen, dass die Geschwindigkeit der ausgehenden Verbindung über die Zeit hinweg stabil war und zu dem Zeitpunkt, als die Probleme begannen, nicht abnahm.

Auffällig ist, dass das Gerät zu dem Zeitpunkt, als das Audioproblem auftrat, eine große Menge an eingehenden Daten empfing (siehe erste Grafik unten).

Dieser zusätzliche eingehende Datenverkehr scheint hauptsächlich auf eingehende Videostreams zurückzuführen zu sein. Das zeigt sich daran, dass wir zunehmend Videopakete sehen (siehe unten).

~2 Mbit/s eingehender Videoverkehr ist für den Empfang eingehender Videostreams normal, aber es ist interessant zu sehen, dass die 2 Mbit/s nur für 2–3 Minuten bestehen und dann auf fast Null abfallen. Dies könnte darauf hindeuten, dass der Benutzer, der das Video gesendet hat, einfach seine Kamera geschlossen hat. Oder dass auch Videostreams nicht mehr durch das System liefen.

Wenn wir uns ansehen, wer das Video „gesendet“ hat, stellen wir schnell fest, dass dies nur ein anderer Benutzer getan hat, bei dem es sich um den Benutzer handelt, dessen Stummschaltung aufgehoben wurde. Wenn man sich ihre Daten ansieht, sieht es so aus, als hätten sie ihre Kamera nach zwei Minuten einfach geschlossen. Die Spitze der eingehenden Videodaten war also wie erwartet und dauerte nur so kurz, weil der andere Benutzer seine Kamera gestoppt hatte.

Wenn es also nicht am Netzwerk lag, ist dann etwas auf dem Gerät passiert?

Der nächste Schritt besteht darin, genauer hinzuschauen, was auf dem Gerät des Hauptlautsprechers passiert. Der Benutzer, bei dem wir diesen Rückgang der gesendeten Pakete gesehen haben.

Mit Blick auf die TrueDEM Daten können wir sehen, dass dieser Benutzer nur Teams ausgeführt hat und alle anderen Programme geschlossen hat. Die CPU- und RAM-Auslastung lag innerhalb eines normalen Bereichs und zeigte nichts, was 12 Minuten schlechten Ton erklären könnte. Tatsächlich zeigten CPU und RAM zum Zeitpunkt des Auftretens der Probleme keine nennenswerten Spitzenwerte.

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

Als nächstes schauen wir uns an, welche Aufnahme- und Rendering-Geräte verwendet werden. Die folgende Tabelle zeigt, dass der Benutzer ein peripheres AV-Produktionssystem namens AV Bridge MatrixMIX verwendet hat, um den Anruf zu leiten. Dabei handelt es sich um ein Hardware-Tool, das bei der Leitung großer Meetings wie einer Teams Town Hall hilft und bei der Verwaltung von Audio und Video sowie anderen Dingen hilft.

Wir sehen, dass ungefähr zu dem Zeitpunkt, zu dem der Organisator in der Teams Town Hall-Besprechung versucht, die Stummschaltung des Teilnehmers aufzuheben, das Rendern eingehender Videos beginnt. Wir wissen bereits, dass dies daran liegt, dass der Teilnehmer, dessen Stummschaltung aufgehoben wurde, seine Kamera aktiviert hat. Also nicht unbedingt etwas, was man nicht erwarten würde.

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

Wie es wahrscheinlich jeder in dieser Situation tun würde, versucht der Sprecher dann mehrere Dinge, um das Problem zu lösen. Dazu gehört offenbar auch das Anhalten der Kamera und der Wechsel des Audiosystems gegen ca. 8:02 Uhr. Von diesem Moment an verwendet das System das interne Audio (AMD High Definition Audio Device) anstelle der AV-Audio-Brücke und dies scheint das Problem endlich zu lösen, da ab diesem Moment wieder Audiopakete ausgehen und die Audioprobleme bestehen bleiben.

Also, tat es Das Ausschalten des Audiosystems löste das Problem, oder war das Ausschalten der Kamera auch ein Faktor?

Wir sehen (in der Tabelle oben), dass die Kamera nach einigen Minuten (~20:07) mithilfe des AV-Bridge-Systems reaktiviert wird. Ohne Auswirkungen auf die Anzahl der Audiopakete. Daher ist es sehr wahrscheinlich, dass das Ausschalten des Videos durch den Hauptredner in diesem Fall keine Rolle spielte.

Aus den Fakten lässt sich folgendes ableiten OfficeExpert TrueDEM hat ans Licht gebracht:

Die Teams Town Hall-Besprechung funktionierte einwandfrei, bis der nicht stummgeschaltete Teilnehmer hinzugefügt wurde.

In diesem Moment scheint das vom Hauptredner für Video und Audio verwendete AV-Produktionssystem Probleme beim Senden von Audio zu haben (die Audiopakete fallen innerhalb einer Minute von 1500 auf fast 0). War es das Aufheben der Stummschaltung des Teilnehmers, die plötzlich eingehenden Videodaten, als der aufgehobene Teilnehmer seine Kamera aktivierte? Oder war es vielleicht, so unwahrscheinlich es auch scheint, nur reiner Zufall, dass es im selben Moment geschah? Es ist schwer zu sagen.

Tatsache ist, dass das Problem eindeutig beim Hauptlautsprecher lag (keine ausgehenden Audiopakete) und höchstwahrscheinlich von dessen externem AV-Produktionssystem herrührte. Der Wechsel von der Verwendung des externen AV-Bridge-System-Audios zur Verwendung des internen Geräte-Audios schien das Problem behoben zu haben.

Der Anruf war geprobt und nichts von dem, was die Organisatoren taten, einschließlich der Aufhebung der Stummschaltung eines Teilnehmers, war falsch. Wenn man jedoch weiß, dass es sich höchstwahrscheinlich um das AV-Produktionssystem handelte, in dem es entstand, und dass eingehende Videos es wahrscheinlich auslösten, können bestimmte allgemeine Empfehlungen ausgesprochen werden, die für die zukünftige Verwendung überprüft werden sollten: