Una reunión desastrosa de Teams Town Hall: cómo OfficeExpert TrueDEM ayudó a aislar la causa

Una de las cosas más difíciles y frustrantes de ayudar a los usuarios que tienen malas llamadas es reunir toda la información correcta. Hay tantas partes móviles que pueden influir en lo que experimentan los usuarios durante una llamada. Desde la autenticación hasta el dispositivo y el equipo periférico, la red local y el ISP hasta la propia nube de Microsoft. Todo puede influir en la calidad de una llamada. Y todo eso, multiplicado por el número de participantes en la llamada. Ya que el problema no tiene por qué originarse en que los participantes lo experimenten.

A menudo vemos lo difícil que es abordar malas decisiones y el siguiente ejemplo no es una excepción. Entonces, permítanos explicarle lo complejo que puede ser descubrir qué está sucediendo y cómo el monitoreo de la experiencia del usuario puede ayudar a aislar la causa.

Un gran equipo Reunión del ayuntamiento Se planificó con casi 500 asistentes en uno de nuestros clientes.
Los asistentes se unieron desde diferentes lugares y zonas horarias, tanto desde sus hogares como desde sus oficinas.
Todos los organizadores estuvieron personalmente en la misma oficina.

La reunión comenzó y todo iba bien hasta que el organizador quiso activar el sonido de un asistente. Incluyéndolos en la discusión en pantalla. Activar el silencio no pareció funcionar y, en cambio, de repente, la calidad del audio comenzó a fallar. Durante 12 a 15 minutos, los participantes se quejaron de tener problemas para oír o comprender lo que estaba pasando. Si comparamos esto con los 500 asistentes, ¡tendrá más de 100 horas de pérdida potencial de productividad! Es comprensible que esto haya causado mucho revuelo incluso con la atención del nivel C. Y como consecuencia, se encargó al departamento de TI investigar lo sucedido.

Con la ayuda de OfficeExpert TrueDEM, analizaremos esta desastrosa convocatoria del Ayuntamiento de Teams para ver qué sucedió y qué se podría hacer para prevent que vuelva a suceder.

La calidad del audio es crucial en las llamadas y reuniones de Microsoft Teams, ya que los problemas de audio tienden a tener un impacto mucho mayor que otros que implican compartir pantalla o video. Donde los vídeos borrosos, por molestos que sean, pueden tolerarse durante un tiempo; La mala calidad del audio puede detener la comunicación. Después de todo, si no puedo verte pero aun así escucharte, podemos comunicarnos. Si no puedo escucharte o tu audio es confuso… la comunicación se vuelve imposible. A menos que sepas el lenguaje de señas. Algo que la mayoría de nosotros no hacemos.

Volvamos a nuestro análisis. Para comprender y analizar una llamada de Microsoft Teams, es necesario comprender la tecnología. La forma en que Microsoft Teams transmite audio, video y otros datos.

Para transmitir una llamada, Microsoft Teams divide las distintas entradas (audio, vídeo, pantalla compartida, aplicaciones, etc.) en secuencias separadas. Dividiéndolos nuevamente en entrante (lo que recibes de la nube) transmisiones y saliente (lo que envías a la nube) transmisiones. Dependiendo de lo que sea, esto se divide en pequeños paquetes (cuadros) que representan una pequeña cantidad de audio, video, etc. De esa manera, el tamaño de cada paquete individual que se transmite es mínimo. lo que a su vez significa que si los paquetes se pierden, el impacto se minimiza.

Microsoft Teams transmite cada segundo de audio como una secuencia de 50 fotogramas, cada uno de los cuales contiene hasta 20 ms de contenido de voz. Con OfficeExpert TrueDEM Realizamos un seguimiento de los paquetes (tramas) del Protocolo de tiempo real en ambas direcciones en un intervalo de 30 segundos. Por lo tanto, para un asistente activo a una conferencia, esperamos ver alrededor de 1,500 paquetes de audio transmitidos por cada intervalo de 30 segundos. Esto es independiente del vídeo y otros paquetes, siendo enviados por separado.

Como se trataba de una reunión pública de Teams y el audio salió mal, tiene sentido comenzar mirando primero al orador principal. Después de todo, esta era la persona que enviaba la mayor parte del audio que otros tenían problemas para escuchar.

La siguiente imagen muestra que alrededor de las 7 p.m. (inicio de la reunión), la cantidad de paquetes de audio enviados desde su dispositivo aumentó al nivel esperado y permaneció allí hasta aproximadamente las 7:51:30 p.m. En ese momento vemos una caída masiva en los paquetes que se envían. Esto explica por qué los demás no podían oírla; su audio no llegaba a la nube y, por lo tanto, a los demás participantes.

Cuando miramos los datos sin procesar de este usuario, vemos el momento exacto en el que comienza y termina el problema. Pocos paquetes de audio pasan por el sistema.

Esto continuó durante casi 12 minutos. Lo cual coincide con lo que afirmaban los demás usuarios.

Entonces ahora sabemos exactamente cuando Esto sucedió, ¿podemos averiguar qué lo causó?

Veamos primero las redes, ya que las malas conexiones de red a menudo provocan malas llamadas. Ninguno de los organizadores informó de ningún problema de red, pero como sabes, las conexiones WIFI tienen fama de ser inestables. Por tanto, tiene sentido empezar por ahí.
Al observar los datos, podemos ver que la velocidad de la conexión saliente se mantuvo estable a lo largo del tiempo y no disminuyó en el momento en que comenzaron los problemas.

Lo que llama la atención es que en el momento en que ocurrió el problema de audio, el dispositivo recibió una gran cantidad de datos entrantes (consulte el primer gráfico a continuación).

Este tráfico entrante añadido parece deberse principalmente a las transmisiones de vídeo entrantes. Lo demuestra el hecho de que empezamos a ver paquetes de vídeo (ver más abajo).

~2 Mbits/seg. El tráfico de vídeo entrante es normal para recibir transmisiones de vídeo entrantes, pero es interesante ver que los 2 Mbit/seg existen sólo durante 2 o 3 minutos y luego caen a casi cero. Esto podría indicar que el usuario que estaba enviando el vídeo simplemente cerró su cámara. O que las transmisiones de vídeo ya no pasaban por el sistema.

Al observar quién estaba "enviando" el video, rápidamente encontramos que solo lo hizo otro usuario, que resulta ser el usuario que no estaba silenciado. Al observar sus datos, parece que simplemente cerraron la cámara después de dos minutos. Entonces, el pico de datos de video entrante fue el esperado y duró solo ese breve tiempo porque el otro usuario detuvo su cámara.

Entonces, si no fue la red, ¿sucedió algo en el dispositivo?

El siguiente paso es observar más de cerca lo que está sucediendo en el dispositivo del altavoz principal. El usuario donde vimos esa caída en el envío de paquetes.

En cuanto al TrueDEM datos, podemos ver que este usuario estaba ejecutando solo Teams y había cerrado todos los demás programas. La utilización de CPU y RAM estuvo dentro de lo que sería un rango normal y no mostró nada que pudiera explicar 12 minutos de audio deficiente. De hecho, la CPU y la RAM no mostraron ningún pico notable en el momento en que ocurrieron los problemas.

¿Podrían haber influido los dispositivos periféricos de entrada y salida?

A continuación veremos qué dispositivos de captura y renderizado se utilizan. La siguiente tabla muestra que el usuario estaba utilizando un sistema de producción AV periférico llamado AV Bridge MatrixMIX para dirigir la llamada. Que es una herramienta de hardware para ayudar a dirigir reuniones grandes, como un ayuntamiento de Teams, y ayuda a administrar el audio y el video, entre otras cosas.

Vemos que aproximadamente en el momento en que el organizador de la reunión pública de Teams intenta activar el silencio del asistente, comienza la representación del video entrante. Ya sabemos que esto se debe a que el asistente que estaba activado activó su cámara. Así que no necesariamente es algo que no esperarías.

Pero lo que es sospechoso es que este es también el momento exacto en el que empiezan a surgir problemas con el audio.

Como probablemente haría cualquiera en esta situación, el hablante intenta varias cosas para resolver el problema. Al parecer, incluye detener la cámara y cambiar el sistema de audio alrededor de las 8:02 p.m. A partir de este momento el sistema utiliza el audio interno (AMD High Definición Audio Device) en lugar del puente de Audio AV y esto finalmente parece solucionar el problema, ya que en ese momento los paquetes de audio empiezan a salir nuevamente y los problemas de audio residen.

Así lo hizo ¿Detener el sistema de audio lo resolvió o el apagado de la cámara también fue un factor?

Vemos (en la tabla anterior) que después de varios minutos (~20:07) la cámara se reactiva usando el sistema AV Bridge. Sin afectar el número de paquetes de audio. Por lo tanto, es muy probable que apagar el vídeo mediante el altavoz principal no haya sido un factor en este caso.

De los hechos se puede deducir lo siguiente OfficeExpert TrueDEM ha sacado a la luz:

La reunión pública de Teams funcionó bien hasta el momento en que se agregó el participante no silenciado.

En ese momento, el sistema de producción AV utilizado por el orador principal para video y audio parece comenzar a tener problemas para enviar audio (los paquetes de audio bajan de 1500 a casi 0 en el lapso de un minuto). ¿Fue la activación del sonido del participante, los datos de video entrantes repentinos cuando el participante activado activó su cámara? ¿O fue quizás, por improbable que parezca, pura coincidencia que sucediera en ese mismo momento? Es difícil de decir.

El hecho es que el problema claramente se originó en el altavoz principal (sin paquetes de audio salientes) y muy probablemente proveniente de su sistema de producción AV externo. Ya que cambiar del uso del audio del sistema AV Bridge externo al uso del audio del dispositivo interno parecía haber solucionado el problema.

La llamada había sido ensayada y ninguna de las cosas que hicieron los organizadores, incluido activar el silencio de un participante, estuvo mal. Sin embargo, saber que probablemente fue el sistema de producción audiovisual donde se originó y que el video entrante probablemente lo activó, significa que se pueden hacer ciertas recomendaciones generales que se deben verificar para uso futuro: