Uma reunião desastrosa do Teams Town Hall – Como OfficeExpert TrueDEM ajudou a isolar a causa

Uma das coisas mais difíceis e frustrantes no suporte a usuários que estão enfrentando chamadas ruins é reunir todas as informações corretas. Existem muitas partes móveis que podem influenciar a experiência dos usuários durante uma chamada. Desde a autenticação, ao dispositivo e equipamento periférico, à rede local e ISP até à própria nuvem da Microsoft. Todos podem desempenhar um papel na qualidade de uma chamada. E tudo isso multiplicado pelo número de participantes da teleconferência. Como o problema não precisa se originar dos participantes que o vivenciam.

Muitas vezes vemos como é difícil lidar com chamadas ruins e o exemplo abaixo não é exceção. Então, deixe-nos mostrar como pode ser complexo descobrir o que está acontecendo e como o monitoramento da experiência do usuário pode ajudar a isolar a causa.

Uma grande equipe Reunião na prefeitura foi planejado com quase 500 participantes em um de nossos clientes.
Os participantes estavam vindo de diferentes locais e fusos horários, tanto em casa quanto no escritório.
Os organizadores estiveram todos pessoalmente no mesmo escritório.

A reunião começou e tudo estava indo bem até que o organizador quis ativar o som de um participante. Trazendo-os para a discussão na tela. A ativação do som não pareceu funcionar e, de repente, a qualidade do áudio começou a piorar. Durante 12 a 15 minutos, os participantes reclamaram de dificuldade para ouvir ou entender o que estava acontecendo. Compare isso com os 500 participantes e você terá mais de 100 horas de perda potencial de produtividade! Compreensivelmente, isso causou muito alvoroço até mesmo com a atenção do nível C. E como consequência, o departamento de TI foi encarregado de pesquisar o que aconteceu.

Com o auxílio de OfficeExpert TrueDEM, analisaremos esta desastrosa convocação do Teams Town Hall para ver o que aconteceu e o que poderia ser feito para prevent isso aconteça novamente.

A qualidade do áudio é crucial em chamadas e reuniões do Microsoft Teams, pois os problemas de áudio tendem a ter um impacto muito maior do que outros que envolvem compartilhamento de tela ou vídeo. Onde vídeos borrados, por mais irritantes que sejam, podem ser tolerados por um tempo; a má qualidade do áudio pode interromper a comunicação. Afinal, se não consigo te ver, mas ainda te ouço, podemos nos comunicar. Se eu não consigo ouvir você ou seu áudio está distorcido… a comunicação se torna impossível. A menos que você conheça a linguagem de sinais. Algo que a maioria de nós não faz.

De volta à nossa análise. Para compreender e analisar uma chamada do Microsoft Teams, você precisa entender a tecnologia. A forma como o Microsoft Teams transmite áudio, vídeo e outros dados.

Para transmitir uma chamada, o Microsoft Teams divide as diversas entradas (áudio, vídeo, compartilhamento de tela, aplicativos, etc.) em fluxos separados. Dividindo-os novamente em entrada (o que você recebe da nuvem) transmite e saída (o que você envia para a nuvem). Dependendo do que seja, ele é dividido em pequenos pacotes (quadros) que representam uma pequena quantidade de áudio, vídeo, etc. Dessa forma, o tamanho de cada pacote individual transmitido é mínimo. o que por sua vez significa que se pacotes se perdem, o impacto é minimizado.

O Microsoft Teams transmite cada segundo de áudio conforme uma sequência de 50 quadros, cada um contendo até 20 ms de conteúdo de fala. Com OfficeExpert TrueDEM rastreamos os pacotes (quadros) do Real Time Protocol em ambas as direções em um intervalo de 30 segundos. Para um participante que fala ativamente, esperamos ver cerca de 1,500 pacotes de áudio transmitidos a cada intervalo de 30 segundos. Isso é independente do vídeo e de outros pacotes, sendo enviados separadamente.

Como era uma reunião do Teams Town Hall e o áudio estava ruim, faz sentido começar olhando primeiro para o palestrante principal. Afinal, era a pessoa que enviava a maior parte do áudio que outras pessoas tinham dificuldade em ouvir.

A imagem a seguir mostra que por volta das 7h. (início da reunião), a quantidade de pacotes de áudio enviados de seu aparelho subiu ao nível esperado e permaneceu lá até aproximadamente 7h51min30. Nesse ponto, vemos uma queda enorme nos pacotes que estão sendo enviados. Isso explica por que outras pessoas não conseguiam ouvi-la; o áudio dela não estava chegando à nuvem e, portanto, aos outros participantes!

Quando analisamos os dados brutos desse usuário, vemos o momento exato em que o problema começa e termina. Poucos pacotes de áudio passam pelo sistema.

Isso continuou por quase 12 minutos. O que coincide com o que os outros usuários estavam afirmando.

Então agora sabemos exatamente quando isso aconteceu, podemos descobrir o que estava causando isso?

Vejamos primeiro a rede, pois conexões de rede ruins geralmente causam chamadas ruins. Nenhum dos organizadores relatou problemas de rede, mas como você sabe, as conexões WIFI são conhecidas por serem instáveis. Faz sentido, portanto, começar por aí.
Observando os dados, podemos ver que a velocidade da conexão de saída permaneceu estável ao longo do tempo e não diminuiu no momento em que os problemas começaram.

O que é notável é que na época em que ocorreu o problema de áudio, o dispositivo recebeu uma grande quantidade de dados recebidos (veja o primeiro gráfico abaixo).

Este tráfego de entrada adicionado parece ser principalmente devido aos fluxos de vídeo de entrada. Evidenciado pelo fato de começarmos a ver pacotes de vídeo chegando (veja abaixo).

O tráfego de vídeo de entrada de aproximadamente 2 Mbits/s é normal para receber fluxos de vídeo de entrada, mas é interessante ver que os 2 Mbits/s existem apenas por 2 a 3 minutos e depois caem para quase zero. Isso pode indicar que o usuário que estava enviando o vídeo simplesmente fechou a câmera. Ou que os fluxos de vídeo também não passavam mais pelo sistema.

Observando quem estava ‘enviando’ o vídeo, descobrimos rapidamente que apenas um outro usuário o fez, que acabou sendo o usuário que estava com o som ativado. Olhando para os dados, parece que eles simplesmente fecharam a câmera depois de dois minutos. Portanto, o pico de dados de vídeo de entrada foi conforme o esperado e durou pouco porque o outro usuário desligou a câmera.

Então, se não foi a rede, algo aconteceu no dispositivo?

O próximo passo é observar mais de perto o que está acontecendo no dispositivo do alto-falante principal. O usuário para onde vimos aquela queda nos pacotes enviados.

Olhando para o TrueDEM dados, podemos ver que este usuário estava executando apenas Teams e fechou todos os outros programas. A utilização de CPU e RAM estava dentro do que seria uma faixa normal e não mostrou nada que explicasse 12 minutos de áudio ruim. Na verdade, a CPU e a RAM não apresentaram picos perceptíveis na época em que os problemas ocorreram.

Os dispositivos periféricos de entrada e saída poderiam ter desempenhado um papel?

A seguir, veremos quais dispositivos de captura e renderização são usados. A tabela a seguir mostra que o usuário estava usando um sistema periférico de produção AV chamado AV Bridge MatrixMIX para conduzir a chamada. Que é uma ferramenta de hardware para ajudar a conduzir grandes reuniões, como o Teams Town Hall, e ajuda a gerenciar áudio e vídeo, entre outras coisas.

Vemos que, no momento em que o organizador da reunião do Teams Town Hall tenta ativar o som do participante, a renderização do vídeo de entrada é iniciada. Já sabemos que isso ocorre porque o participante que estava com o som ativado ativou sua câmera. Portanto, não necessariamente algo que você não esperaria.

Mas o que se suspeita é que este também seja o exato momento em que começam a surgir problemas com o áudio.

Como provavelmente faria qualquer pessoa nesta situação, o orador tenta então várias coisas para resolver o problema. Incluindo, ao que parece, parar a câmera e mudar o sistema de áudio por volta das 8h02. A partir deste momento, o sistema utiliza o áudio interno (AMD High Definition Audio Device) em vez da ponte AV Audio e isso finalmente parece resolver o problema, pois nesse momento os pacotes de áudio começam a sair novamente e os problemas de áudio residem.

Assim o fez parar o sistema de áudio resolveu ou o desligamento da câmera também foi um fator?

Vemos (na tabela acima) que após alguns minutos (~20:07) a câmera é reativada usando o sistema AV Bridge. Sem impactar o número de pacotes de áudio. Portanto, é muito provável que desligar o vídeo do alto-falante principal não tenha sido um fator neste caso.

O seguinte pode ser deduzido com base nos fatos OfficeExpert TrueDEM trouxe à luz:

A reunião do Teams Town Hall estava funcionando bem até o momento em que o participante com som ativado foi adicionado.

Naquele momento, o sistema de produção AV usado pelo alto-falante principal para vídeo e áudio parece começar a ter problemas para enviar áudio (os pacotes de áudio caem de 1500 para quase 0 no espaço de um minuto). Foi a ativação do som do participante, a entrada repentina de dados de vídeo quando o participante com o som ativado ativou sua câmera? Ou talvez tenha sido, por mais improvável que pareça, apenas pura coincidência que isso tenha acontecido naquele mesmo momento? É difícil dizer.

O fato é que o problema claramente se originou no alto-falante principal (sem pacotes de áudio de saída) e provavelmente no sistema de produção AV externo. Como mudar do áudio do sistema AV Bridge externo para o áudio do dispositivo interno parecia ter resolvido o problema.

A chamada foi ensaiada e nenhuma das coisas que os organizadores fizeram, incluindo ativar o som de um participante, foi errada. No entanto, saber que provavelmente foi o sistema de produção AV onde se originou e que o vídeo recebido provavelmente o acionou, significa que certas recomendações gerais podem ser feitas e devem ser verificadas para uso futuro: