Call Analytics: por onde começar quando alguém diz que a chamada falhou

Alguém da sua equipe chega e diz: "a chamada caiu, não dava pra ouvir nada, o Teams travou". Por onde você começa?

A resposta curta é: pelo Teams admin center, na experiência de troubleshooting de reuniões e chamadas. É lá que você encontra o diagnóstico por usuário, por reunião e por sessão. Vou mostrar o caminho.

Antes de tudo: as permissõesLink para esta seção

Para acessar as informações de chamada de um usuário, você precisa de uma função de administrador com suporte no Microsoft Entra ID. A Microsoft criou duas funções específicas para isso, que podem ser atribuídas ao pessoal de suporte sem dar acesso ao resto do admin center:

• Teams communications support specialist (nível 1): lidam com problemas básicos de qualidade de chamada. Não investigam reuniões. Coletam informação e escalam.
• Teams communications support engineer (nível 2): veem os logs detalhados de chamada, incluindo dispositivos, endereço IP, mapeamento de subnet, sufixo DNS e SSID. Esses detalhes ficam ocultos para o nível 1.

A lista completa de funções suportadas está em Use Microsoft Teams administrator roles to manage Teams ((abre em nova aba)). Se a sua organização usa Administrative Units (AUs), o escopo do que você vê depende da sua atribuição. Parceiros com GDAP precisam ter a função TCSS ou TCSE no tenant do cliente.

No seu tenant, confirme quem tem qual função antes de precisar. Não dá para investigar uma chamada no meio do incidente descobrindo que falta acesso.

Onde encontrar os dados de chamadaLink para esta seção

Entre no Teams admin center ((abre em nova aba)). Na navegação à esquerda, selecione Manage users, escolha o usuário e vá até a aba Meetings & calls.

Lá você encontra duas listas:

• In-progress meetings: reuniões acontecendo agora. Dados em tempo real, atualizados a cada minuto. Todos os usuários aparecem aqui independentemente do tipo de licença, enquanto a reunião estiver ativa.
• Completed meetings: reuniões que já terminaram e tiveram a telemetria processada. Pode levar de 30 minutos a 2 horas para os dados aparecerem depois do encerramento.

O período de retenção é de 30 dias para reuniões e chamadas em que o usuário participou. Uma reunião ou chamada só aparece se gerou sessões de mídia. Se ninguém entrou, ela não aparece na lista.

O que mudou (e por que isso importa)Link para esta seção

A Microsoft atualizou a experiência de troubleshooting. Antes, a qualidade era classificada como "Good" ou "Poor". Agora, você vê se o usuário enfrentou issues (problemas) de qualidade ou confiabilidade. A classificação usa classificadores inteligentes de qualidade de mídia ((abre em nova aba)), modelos de machine learning treinados na telemetria real do Teams.

Isso significa que o sistema não marca "Poor" com base em um único número fora da faixa. Ele avalia o conjunto dos dados e diz: "aqui teve degradação perceptível pelo usuário". É mais preciso.

As abas Advanced e Debug do modelo anterior foram removidas. A telemetria mais relevante está agora nas abas de dados em tempo real e dados agregados. Se você quiser analisar mais a fundo, pode exportar tudo o que antes estava nessas abas usando o botão Export.

A investigação em três níveisLink para esta seção

A experiência atual oferece três visões que se conectam:

Visão do usuário. Mostra o histórico de reuniões da pessoa, com tendências semanais de qualidade e atividade. Aqui você vê o panorama: a pessoa tem tido problemas recorrentes ou foi um evento isolado?

Visão da reunião. Mostra os detalhes de uma reunião específica: participantes, duração, tipo de atividade. A seção de Issues lista cada problema encontrado, com tipo (áudio, vídeo, compartilhamento de tela), descrição, participantes afetados, causa raiz possível e ações recomendadas.

As causas raiz são categorizadas em quatro áreas:

• Network: problema causado por condições ruins de rede.
• Compute: falta de recursos de processamento ou memória no dispositivo do usuário.
• Device: problema no microfone, alto-falante/fone ou câmera.
• Media: alta confiança de que o usuário experimentou degradação perceptível na qualidade da mídia.

Visão do participante. O diagnóstico por sessão. Se o usuário entrou na reunião de mais de um dispositivo ou reconectou durante a reunião, cada sessão aparece separadamente. Aqui você encontra as métricas de telemetria: jitter, perda de pacotes, round-trip time, codec usado, dispositivo de captura e renderização, tipo de conectividade (Ethernet, WiFi), e até a plataforma VDI, se for o caso.

O que procurar nos númerosLink para esta seção

Na telemetria de sessão, valores fora do esperado aparecem destacados em vermelho. Isso não significa necessariamente que o usuário teve qualidade ruim, mas é um sinal para investigar.

Para áudio, os indicadores principais são:

• Jitter: variação no atraso dos pacotes. Muito alto, o áudio fica entrecortado.
• Perda de pacotes: pacotes que não chegaram ao destino. Percentual sobre o total enviado.
• Round-trip time: tempo que um pacote leva para ir e voltar. Muito alto causa latência.
• Local healed ratio: quando o "curador" de áudio do Teams está sendo acionado com frequência. O usuário percebe como áudio "robótico" ou picotado.

Para vídeo, além de jitter e perda de pacotes, vale olhar:

• Loss recovery attempt rate: quantas vezes o sistema pediu recuperação de perda de rede, o que faz o vídeo congelar.
• Source freeze count: quantas vezes a câmera não gerou um quadro novo por mais de um segundo.
• Frame rate: quadros por segundo. Abaixo do esperado pode indicar recurso insuficiente no dispositivo, largura de banda baixa ou problema na câmera.

E quando a chamada simplesmente não conecta?Link para esta seção

O código de erro Ms-diag 20-29 indica que a configuração da chamada falhou. O usuário não conseguiu entrar. Nesse caso, a telemetria de sessão pode não estar disponível porque a conexão foi interrompida antes de gerar dados de Quality of Experience (QoE). A classificação da sessão aparece como unavailable.

Para chamadas de Direct Routing, o Call Analytics mostra códigos SIP padrão quando a chamada chega aos componentes internos do Direct Routing e falha. Mas se o problema é anterior a isso (por exemplo, o nome do trunk FQDN está mal configurado ou o pareamento do SBC não funciona), o Call Analytics não ajuda. Nesse cenário, a fonte de verdade são os logs do SBC.

As limitações que você precisa conhecerLink para esta seção

• O Call Analytics não cobre participantes somente visualização em reuniões.
• Em eventos ao vivo e reuniões otimizadas para grandes audiências, a telemetria está disponível apenas para apresentadores e organizadores. Participantes como audiência não aparecem.
• Em reuniões federadas: se um usuário da sua organização entrou em uma reunião organizada por outro tenant, você vê apenas os dados dos seus próprios usuários. O tenant organizador vê todos os participantes.
• A retenção de telemetria em tempo real varia por licença: contas com Teams Premium e Teams Rooms Pro mantêm os dados por sete dias após o término da reunião. Para as demais licenças, a telemetria em tempo real fica disponível apenas durante a reunião. A telemetria agregada fica disponível para todos os usuários por 30 dias.

O fluxo práticoLink para esta seção

Quando alguém disser que a chamada falhou, o passo a passo é:

1. Confirme se você tem a função de administrador correta.
2. Vá ao Teams admin center, encontre o usuário, abra a aba Meetings & calls.
3. Se a reunião ainda estiver acontecendo, olhe a lista In-progress meetings. Se já terminou, vá em Completed meetings.
4. Selecione a reunião. Na visão de detalhes, veja os Issues e a causa raiz sugerida.
5. Selecione o participante para ver a telemetria de sessão. Procure valores em vermelho.
6. Se a telemetria de áudio não aparecer e a sessão estiver como unavailable, provavelmente a chamada caiu antes de gerar dados de QoE.
7. Se for Direct Routing e o Call Analytics não mostrar nada, vá para os logs do SBC.

Nada substitui conhecer o ambiente antes do problema acontecer. Subir o arquivo de dados prediais (um .csv ou .tsv com informação de edifício e site) faz o Call Analytics mapear endereços IP a locais físicos. Isso transforma "o usuário X teve perda de pacotes" em "os usuários do prédio Y estão todos com perda de pacotes". É esse salto que tira o troubleshooting do individual e leva para o sistêmico.

Fontes consultadas:

• Monitor and troubleshoot Teams meetings and calls from the Teams admin center ((abre em nova aba))
• Set up call analytics for Teams ((abre em nova aba))
• Use Call Analytics to troubleshoot poor call quality ((abre em nova aba))
• Improve call quality in Microsoft Teams ((abre em nova aba))
• Monitor Direct Routing ((abre em nova aba))