Katastrofalne spotkanie w ratuszu Teams – Jak OfficeExpert TrueDEM pomogło wyizolować przyczynę

Jedną z najtrudniejszych i najbardziej frustrujących rzeczy we wspieraniu użytkowników, którzy doświadczają złych połączeń, jest zebranie wszystkich właściwych informacji. Jest wiele ruchomych części, które mogą mieć wpływ na to, czego użytkownicy doświadczają podczas połączenia. Od uwierzytelnienia, przez urządzenie i sprzęt peryferyjny, sieć lokalną i dostawcę usług internetowych, aż po samą chmurę Microsoft. Wszystko może mieć wpływ na jakość połączenia. A to wszystko razy liczba uczestników połączenia. Ponieważ problem nie musi pochodzić od doświadczających go uczestników.

Często widzimy, jak trudno jest radzić sobie ze złymi wezwaniami, a poniższy przykład nie jest wyjątkiem. Pozwól nam więc pokazać, jak skomplikowane może być ustalenie, co się dzieje i w jaki sposób monitorowanie doświadczenia użytkownika może pomóc w wyizolowaniu przyczyny.

Duże zespoły Spotkanie w ratuszu zostało zaplanowane z udziałem prawie 500 osób u jednego z naszych klientów.
Uczestnicy dołączali z różnych lokalizacji i stref czasowych, zarówno z domów, jak i z biur.
Organizatorzy byli osobiście w tym samym biurze.

Spotkanie się rozpoczęło i wszystko szło dobrze, dopóki organizator nie chciał wyłączyć wyciszenia uczestnika. Włączanie ich do dyskusji na ekranie. Wydawało się, że wyłączenie wyciszenia nie zadziałało, a zamiast tego nagle jakość dźwięku zaczęła się pogarszać. Przez 12–15 minut uczestnicy skarżyli się, że mają problemy ze słuchem lub zrozumieniem, co się dzieje. Porównując to z 500 uczestnikami, otrzymasz ponad 100 godzin potencjalnej utraty produktywności! Co zrozumiałe, wywołało to wiele zamieszania, nawet wśród uwagi na poziomie C. W rezultacie dział IT otrzymał zadanie zbadania, co się stało.

Z pomocą OfficeExpert TrueDEM, przyjrzymy się temu katastrofalnemu wezwaniu do ratusza Teams, aby zobaczyć, co się stało i co można zrobić z prevent żeby to się nie powtórzyło.

Jakość dźwięku ma kluczowe znaczenie podczas rozmów i spotkań w aplikacji Microsoft Teams, ponieważ problemy z dźwiękiem mają zwykle znacznie większy wpływ niż inne, związane z udostępnianiem ekranu lub wideo. Tam, gdzie niewyraźne wideo, choć irytujące, można tolerować przez jakiś czas; słaba jakość dźwięku może zatrzymać komunikację na jej ścieżce. W końcu, jeśli Cię nie widzę, ale nadal Cię słyszę, możemy się porozumieć. Jeśli Cię nie słyszę lub Twój dźwięk jest zniekształcony… komunikacja staje się niemożliwa. Chyba, że ​​znasz język migowy. Coś, czego większość z nas nie robi.

Wróćmy do naszej analizy. Aby zrozumieć i przeanalizować rozmowę w aplikacji Microsoft Teams, musisz poznać technologię. Sposób, w jaki Microsoft Teams przesyła dane audio, wideo i inne.

Aby przekazać połączenie, Microsoft Teams dzieli różne dane wejściowe (audio, wideo, udostępnianie ekranu, aplikacje itp.) na osobne strumienie. Dzieląc je ponownie na przychodzące (co otrzymujesz z chmury) strumieni i wychodzące (to, co wysyłasz do chmury) strumieni. W zależności od tego, co to jest, jest on następnie dzielony na małe pakiety (ramki) reprezentujące niewielką ilość dźwięku, wideo itp. W ten sposób rozmiar każdego pojedynczego przesyłanego pakietu jest minimalny. co z kolei oznacza, że ​​jeśli pakiety gubią się, wpływ jest zminimalizowany.

Microsoft Teams przesyła każdą sekundę dźwięku jako sekwencja 50 klatek, z których każda zawiera do 20 ms treści mowy. Z OfficeExpert TrueDEM śledzimy pakiety (ramki) protokołu czasu rzeczywistego w obu kierunkach w odstępie 30 sekund. Dlatego też w przypadku aktywnie mówiącego uczestnika spodziewamy się transmitować około 1,500 pakietów audio w każdym 30-sekundowym odstępie. Jest to niezależne od wideo i innych pakietów, które są wysyłane oddzielnie.

Ponieważ było to spotkanie w ratuszu usługi Teams i dźwięk uległ zepsuciu, warto najpierw przyjrzeć się głównemu mówcy. W końcu była to osoba wysyłająca większość dźwięku, którego inni mieli problemy ze słyszeniem.

Poniższe zdjęcie pokazuje, że około godz. (rozpoczęcie spotkania) liczba pakietów audio wysłanych z jej urządzenia wzrosła do oczekiwanego poziomu i utrzymywała się na tym poziomie do około 7:7:51. W tym momencie obserwujemy ogromny spadek liczby wysyłanych pakietów. To wyjaśnia, dlaczego inni jej nie słyszeli; jej dźwięk nie docierał do chmury, a tym samym do pozostałych uczestników!

Kiedy patrzymy na surowe dane tego użytkownika, widzimy dokładny moment rozpoczęcia i zakończenia problemu. Niewiele pakietów audio przedostaje się przez system.

Trwało to prawie 12 minut. Co pokrywa się z tym, co twierdzili inni użytkownicy.

Więc teraz wiemy dokładnie jeśli chodzi o komunikację i motywację tak się stało, czy możemy dowiedzieć się, co było przyczyną?

Przyjrzyjmy się najpierw sieci, ponieważ złe połączenia sieciowe często powodują złe połączenia. Żaden z organizatorów nie zgłosił żadnych problemów z siecią, ale jak wiadomo, połączenia WIFI są notorycznie niestabilne. Dlatego warto od tego zacząć.
Patrząc na dane widać, że prędkość połączenia wychodzącego utrzymywała się na stałym poziomie w czasie i nie spadła w momencie wystąpienia problemów.

Zauważalne jest to, że mniej więcej w czasie wystąpienia problemu z dźwiękiem urządzenie otrzymało dużą ilość przychodzących danych (patrz pierwszy wykres poniżej).

Wydaje się, że ten dodatkowy ruch przychodzący wynika głównie z przychodzących strumieni wideo. Świadczy o tym fakt, że zaczynamy widzieć napływ pakietów wideo (patrz poniżej).

Przychodzący ~2 Mbit/s Ruch wideo jest normalny w przypadku odbierania przychodzących strumieni wideo, ale interesujące jest to, że prędkość 2 Mbit/s występuje tylko przez 2-3 minuty, a następnie spada prawie do zera. Może to oznaczać, że użytkownik wysyłający wideo po prostu zamknął kamerę. Lub że strumienie wideo również nie przepływały już przez system.

Sprawdzając, kto „wysyłał” wideo, szybko stwierdzamy, że zrobił to tylko jeden inny użytkownik, czyli ten, który nie miał włączonego wyciszenia. Patrząc na ich dane, wydaje się, że po dwóch minutach po prostu zamknęli aparat. Zatem szczyt przychodzących danych wideo był zgodny z oczekiwaniami i trwał tylko tak krótko, ponieważ drugi użytkownik zatrzymał kamerę.

Jeśli więc nie była to sieć, czy coś się działo na urządzeniu?

Następnym krokiem jest przyjrzenie się temu, co dzieje się na urządzeniu głównego głośnika. Użytkownik, u którego zaobserwowaliśmy spadek liczby wysyłanych pakietów.

Patrząc na TrueDEM data, widzimy, że ten użytkownik korzystał tylko z aplikacji Teams i zamknął wszystkie inne programy. Wykorzystanie procesora i pamięci RAM mieściło się w normalnym zakresie i nie wykazało niczego, co wyjaśniałoby 12 minut słabej jakości dźwięku. W rzeczywistości procesor i pamięć RAM nie wykazywały żadnych zauważalnych szczytów w momencie wystąpienia problemów.

Czy peryferyjne urządzenia wejściowe i wyjściowe mogły odegrać jakąś rolę?

Następnie przyjrzymy się, jakie urządzenia do przechwytywania i renderowania są używane. Poniższa tabela pokazuje, że użytkownik do prowadzenia połączenia korzystał z peryferyjnego systemu produkcji AV o nazwie AV Bridge MatrixMIX. Jest to narzędzie sprzętowe pomagające w prowadzeniu dużych spotkań, takich jak ratusz w aplikacji Teams, i pomagające zarządzać dźwiękiem i wideo, a także innymi rzeczami.

Widzimy, że mniej więcej w czasie, gdy organizator spotkania Teams Town Hall próbuje wyłączyć wyciszenie uczestnika, rozpoczyna się renderowanie przychodzącego wideo. Wiemy już, że dzieje się tak dlatego, że uczestnik, którego wyciszenie nie było wyciszone, aktywował swoją kamerę. Więc niekoniecznie coś, czego byś się nie spodziewał.

Podejrzewa się jednak, że jest to dokładnie moment, w którym zaczynają pojawiać się problemy z dźwiękiem.

Jak zapewne zrobiłby każdy w takiej sytuacji, mówca następnie próbuje kilku rzeczy, aby rozwiązać problem. Wydaje się, że łącznie z zatrzymaniem kamery i zmianą systemu audio około 8:02. Od tego momentu system wykorzystuje wewnętrzne złącze audio (urządzenie audio AMD High Definition) zamiast mostka AV Audio i wydaje się, że to w końcu rozwiązuje problem, ponieważ w tym momencie pakiety audio znów zaczynają być wysyłane, a problemy z dźwiękiem nadal występują.

Tak więc zatrzymanie systemu audio rozwiązuje problem, czy też wyłączenie kamery również miało na to wpływ?

Widzimy (w tabeli powyżej), że po kilku minutach (~20:07) kamera zostaje ponownie aktywowana za pomocą systemu AV Bridge. Bez wpływu na liczbę pakietów audio. Jest zatem bardzo prawdopodobne, że wyłączenie wideo przez głównego głośnika nie miało w tym przypadku znaczenia.

Na podstawie faktów można wywnioskować, co następuje OfficeExpert TrueDEM wydobyło na światło dzienne:

Spotkanie w ratuszu Teams działało prawidłowo do momentu dodania niewyciszonego uczestnika.

W tym momencie wydaje się, że system produkcji AV używany przez główny głośnik do przesyłania obrazu i dźwięku zaczyna mieć problemy z wysyłaniem dźwięku (pakiety audio spadają z 1500 do prawie 0 w ciągu minuty). Czy było to wyłączenie wyciszenia uczestnika lub nagłe przybycie danych wideo, gdy niewyciszony uczestnik aktywował swoją kamerę? A może to, choć wydaje się to mało prawdopodobne, był czystym zbiegiem okoliczności, że wydarzyło się to w tym samym momencie? Trudno powiedzieć.

Fakt jest taki, że problem najwyraźniej miał swoje źródło w głównym głośniku (brak wychodzących pakietów audio) i najprawdopodobniej pochodził z zewnętrznego systemu produkcyjnego AV. Wydaje się, że przejście z korzystania z zewnętrznego systemu audio AV Bridge na korzystanie z wewnętrznego dźwięku urządzenia rozwiązało problem.

Rozmowa została przećwiczona i żadna z rzeczy, które zrobili organizatorzy, łącznie z wyłączeniem wyciszenia uczestnika, nie była zła. Jednakże wiedza, że ​​najprawdopodobniej był to system produkcyjny AV, z którego pochodzi i że przychodzące wideo prawdopodobnie to wyzwoliło, oznacza, że ​​można poczynić pewne ogólne zalecenia, które należy zweryfikować pod kątem przyszłego wykorzystania: