Como investigar chamadas ruins no Teams com o Call Quality Dashboard
O Call Quality Dashboard Teams é a ferramenta nativa da Microsoft para diagnosticar qualidade de chamadas no Teams. Ele centraliza métricas como MOS, jitter, perda de pacotes e latência por usuário, dispositivo e rede. Sem ele, sua equipe depende de relatos subjetivos e não consegue identificar onde a chamada degradou.
Quando um usuário reclama de "chamada ruim", o CQD mostra se o problema está no cliente, na rede interna, no SBC ou na operadora. O dashboard transforma sintomas subjetivos em métricas objetivas e acionáveis. Mas o CQD sozinho não fecha o diagnóstico — ele precisa ser correlacionado com Call Analytics, logs de rede e dados do SBC.
O fluxo de investigação em camadas começa no CQD e desce até o tronco SIP. Primeiro, identifique o usuário e o horário exato da chamada. Depois, cruze os dados do CQD com o Call Analytics para ver eventos específicos. Em seguida, análise o trajeto da mídia: rede interna, firewall, SBC e operadora. Cada camada descarta ou confirma uma hipótese.
Na prática, a maioria das chamadas ruins tem causa na rede local, não no Teams. O CQD mostra se o jitter ou a perda de pacotes ocorreu no segmento entre o cliente e o SBC. Se os indicadores de rede estão limpos, o problema provavelmente está no SBC ou na operadora. Esse fluxo evita retrabalho e acelera a resolução.
Para equipes de infraestrutura, o CQD é o ponto de partida, não o fim. Ele define onde investigar, mas não substitui a análise de logs do SBC nem o monitoramento da operadora. A correlação entre CQD, Call Analytics e rede é o que transforma reclamações vagas em alertas operacionais precisos. Equipes que correlacionam CQD, rede, SBC e operadora reduzem o tempo de diagnóstico de chamadas ruins e evitam culpar o Teams por problemas que estão na infraestrutura.
O Call Quality Dashboard Teams também ajuda a criar alertas proativos. Configure consultas para monitorar tendências de MOS, perda de pacotes e jitter por site ou por gateway. Assim, você detecta degradação antes que os usuários reclamem. Isso transforma o CQD em uma ferramenta de observabilidade, não apenas de diagnóstico reativo.
Para aprofundar a correlação com a operadora, consulte o artigo sobre receber ligações de clientes dentro do Microsoft Teams, que detalha o diagnóstico por camadas. E se você está avaliando se o Teams Phone substitui o PABX, veja os limites do Direct Routing e Operator Connect antes de decidir.
Quando o Call Quality Dashboard resolve e quando ele não é suficiente
O Call Quality Dashboard Teams resolve problemas quando a causa está dentro do seu perímetro de rede ou configuração de dispositivo. Ele falha quando o sintoma está na operadora, no SBC ou no tronco PSTN — exatamente onde o dashboard não enxerga.
Call Quality Dashboard Teams é a ferramenta nativa da Microsoft que consolida telemetria de chamadas do Teams para correlacionar sintomas de qualidade — como áudio robótico ou latência — com a infraestrutura de rede interna, dispositivos e configurações de QoS. Ele responde "onde" a chamada degradou, mas não substitui análise de SBC, operadora ou tronco PSTN.
Sua equipe recebe reclamações de "chamada caindo" ou "voz cortando" sem conseguir provar a causa. O dashboard mostra métricas de jitter, perda de pacotes e latência por chamada, mas você precisa saber qual camada investigar primeiro.
| Cenário | Sinais observáveis | Limite do CQD | Ação recomendada |
|---|---|---|---|
| Problema de rede interna (Wi-Fi, switch, cabeamento) | Jitter alto, perda de pacotes em chamadas de um mesmo prédio ou VLAN | Identifica o problema, mas não aponta o equipamento exato | Use o CQD para isolar o subnet ou IP e valide com teste de ping e QoS no switch |
| Configuração de QoS incorreta | Áudio robótico ou cortes em horários de pico, mesmo com banda disponível | Mostra a degradação, mas não valida marcação DSCP no roteador | Confira as políticas de DSCP (EF 46) e compare com o tráfego real no roteador |
| Problema de dispositivo (headset, microfone, driver) | Qualidade ruim em chamadas de um único usuário ou modelo de headset | Correlaciona por usuário, mas não diagnostica firmware ou driver | Atualize driver, teste com outro dispositivo e compare no Call Analytics |
| Problema na operadora ou tronco PSTN | Chamadas externas com eco, atraso ou queda após o atendimento | Não enxerga a perna PSTN — o CQD só vê o tráfego do Teams até o SBC | Escale para o provedor com logs do SBC e horários exatos das chamadas |
| SBC mal configurado (codec, roteamento, TLS) | Chamadas falham ao conectar, áudio unidirecional ou codec errado | Não mostra a configuração interna do SBC | Analise logs do SBC (SIP traces) e compare codecs negociados com o esperado |
Quando a reclamação persiste e o CQD mostra métricas saudáveis, o gargalo está fora do Teams. A perna PSTN, o SBC ou a operadora ficam invisíveis para o dashboard — e é aí que o diagnóstico trava.
Sua equipe precisa de um procedimento claro: primeiro isole com CQD, depois confirme com Call Analytics e, por fim, escale com dados objetivos. Sem esse fluxo, você perde horas correlacionando sintomas subjetivos com causas que o dashboard não cobre.
Para chamadas PSTN, a integração com o SBC e a operadora exige análise além do CQD. O dashboard mostra a qualidade do Teams até o SBC, mas a perna de telefonia pública depende de logs do SBC e medição da operadora — sem isso, o sintoma vira um impasse entre equipes.
Na prática, o CQD é suficiente quando o problema está na rede interna, na configuração de QoS ou no dispositivo. Ele não é suficiente quando o sintoma está no SBC, na operadora ou no tronco PSTN — nesses casos, a ação recomendada é escalar com evidências coletadas do SBC e da operadora.
Como transformar sintomas subjetivos em métricas acionáveis no CQD
Para a equipe de infraestrutura, o maior desafio não é técnico — é tradução. "A ligação está robótica", "está picotando", "tem um delay chato" são reclamações subjetivas de qualidade que chegam sem contexto, sem evidência e sem padrão. O Call Quality Dashboard Teams existe exatamente para converter esse vocabulário impreciso em variáveis mensuráveis, mas a transformação exige método.
O primeiro passo é mapear cada sintoma relatado a uma métrica primária e suas possíveis causas de rede:
- "Áudio picotando ou entrecortado" — Verifique perda de pacotes e, principalmente, variação brusca de jitter. O Call Analytics complementa mostrando se a oscilação ocorreu no trecho do usuário ou no gateway.
- "Chamada abafada ou volume oscilando" — Pode indicar problema de codec negociado ou QoS não aplicado. Confira no CQD o codec utilizado e compare com chamadas bem-sucedidas no mesmo segmento de rede.
- "Caiu do nada" — Analise o motivo de término da chamada no Call Analytics. O CQD mostra padrões de desconexão por subnet, ajudando a identificar se há recorrência em um switch ou link específico.
Para a equipe de infraestrutura, o valor está em criar um dicionário compartilhado entre o que o usuário sente e o que o CQD mede. Quando uma reclamação subjetiva chega, o time já sabe qual métrica consultar, qual filtro aplicar e qual evidência extrair. O Call Analytics entra como ferramenta de zoom: o CQD mostra o padrão agregado, o Call Analytics confirma o comportamento individual da chamada. Juntos, eliminam o ciclo de "não encontramos nada" e substituem por "o problema está neste switch, neste horário, com esta evidência".
Documentar cada ocorrência com métricas, subnet, horário e gateway constrói um histórico que revela recorrências e justifica investimentos. Sem essa base, cada reclamação subjetiva de qualidade reinicia o diagnóstico do zero — e a equipe de infraestrutura permanece reagindo em vez de antecipar.
O que é Call Quality Dashboard e como ele se diferencia do Call Analytics?
O Call Quality Dashboard (CQD) é uma ferramenta da Microsoft que analisa métricas agregadas de qualidade de chamadas em toda a organização do Teams, enquanto o Call Analytics foca em chamadas individuais de usuários específicos. Em outras palavras, o CQD responde "como está a saúde geral da telefonia", e o Call Analytics responde "o que aconteceu com esta ligação específica".
Para a equipe de infraestrutura, essa distinção é operacional. Quando um usuário reclama de uma chamada ruim, o Call Analytics mostra o diagnóstico daquela sessão. Quando você precisa identificar padrões de degradação em um SBC, em um gateway ou em um link de rede, o CQD agrega os dados de todas as chamadas e permite filtrar por sub-rede, por servidor ou por horário.
O erro mais comum é tentar usar o Call Analytics para enxergar tendências ou usar o CQD para investigar uma reclamação isolada. Equipes que documentam perfil, problema e requisitos reduzem ambiguidade na escolha entre Call Quality Dashboard e Call Analytics. A escolha correta depende do escopo da pergunta que você precisa responder.
Quando usar cada ferramenta na prática
| Contexto operacional | Ferramenta adequada | O que ela responde |
|---|---|---|
| Reclamação de um usuário específico | Call Analytics | Qual foi a qualidade da chamada individual? Quais métricas estavam fora do limite? |
| Padrão de chamadas ruins em um setor ou horário | Call Quality Dashboard | Existe uma tendência agregada? Qual sub-rede ou servidor concentra os problemas? |
| Validação de alteração de rede ou SBC | Call Quality Dashboard | A mudança impactou a qualidade geral das chamadas na organização? |
| Suporte ao usuário final | Call Analytics | O problema foi no dispositivo, na rede ou no serviço? |
Na prática, as ferramentas são complementares. O Call Analytics oferece o detalhe da chamada individual, enquanto o CQD oferece a visão macro que orienta decisões de infraestrutura. Uma equipe madura usa o Call Analytics para triagem inicial e o CQD para correlacionar sintomas com causas estruturais.
Critérios para avaliar se o CQD atende sua operação
Avaliar a ferramenta exige responder a quatro perguntas antes de qualquer implementação. Primeiro: o problema que você precisa resolver é coletivo ou individual? Segundo: sua equipe tem acesso aos relatórios do Teams admin center ou precisa de exportação via API? Terceiro: você consegue correlacionar os dados do CQD com logs do seu SBC e da sua operadora? Quarto: o volume de chamadas justifica a análise agregada?
Se você respondeu "coletivo", "sim", "sim" e "sim", o CQD é a ferramenta certa. Se o problema é majoritariamente individual e esporádico, o Call Analytics resolve com menos esforço. O custo de implementar o CQD sem esses critérios é alto: você terá uma ferramenta poderosa gerando relatórios que ninguém correlaciona com a operação real.
O Call Quality Dashboard Teams exige um processo de coleta de dados contínuo. Não é uma ferramenta de consulta pontual. A Microsoft disponibiliza o CQD com dados de telemetria de todas as chamadas do Teams, mas a leitura correta depende de você configurar os relatórios de acordo com sua topologia de rede e seus endpoints.
Para equipes que já operam com telefonia integrada ao Teams, o CQD se torna uma camada de observabilidade essencial. Ele permite enxergar problemas que o usuário reporta como "a ligação está robótica" e transformá-los em métricas de jitter, perda de pacotes ou latência, que são acionáveis pela equipe de rede.
Onde a adoção de Call Quality Dashboard Teams costuma falhar?
Os cinco erros mais comuns na implementação do CQD são: pular a configuração de QoS na rede, ignorar a correlação com SBC e operadora, não definir alertas, não treinar a equipe e tratar o dashboard como ferramenta de busca, não de análise.
- Implementar o dashboard antes de configurar QoS. O CQD reporta perda de pacotes, jitter e latência. Sem QoS configurado no roteador e switches, esses indicadores ficam altos mesmo em chamadas internas. A equipe de infraestrutura perde dias investigando um problema que a própria rede causou. Configure DSCP (46 para áudio) e políticas de fila antes de analisar qualquer relatório.
- Ignorar a correlação com SBC e operadora. O CQD mostra a qualidade do último salto até o Teams. Se o SBC (Session Border Controller) ou o trunk SIP da operadora estiverem mal configurados, a métrica aparece boa no dashboard, mas o áudio chega ruim no usuário. Cruze os relatórios do CQD com logs do SBC e testes de chamada na operadora. Sem isso, você culpa a rede errada.
- Não capacitar a equipe para interpretar relatórios. O CQD entrega tabelas, não diagnósticos. Um analista sem treinamento confunde "chamada ruim" com "chamada perdida" e abre chamado para o fornecedor errado. Estruture um roteiro: verifique a sub-rede, depois o SBC, depois a operadora. A documentação da Microsoft sobre melhores práticas recomenda esse fluxo para evitar retrabalho.
- Tratar o CQD como ferramenta de busca, não de análise. Procurar uma chamada específica no CQD é ineficiente — ele agrega dados, não detalha uma ligação isolada. Para isso existe o Call Analytics. Use o CQD para padrões e tendências; use o Call Analytics para o caso individual. Misturar os dois papéis gera conclusões erradas.
Equipes que configuram QoS antes de analisar dados reduzem drasticamente falsos positivos no Call Quality Dashboard Teams. A ordem de implementação define se a ferramenta será um oráculo ou um enfeite.
Como correlacionar CQD, rede, SBC e operadora em chamadas PSTN?
Para diagnosticar uma chamada PSTN ruim, você precisa cruzar quatro fontes: o Call Quality Dashboard, os logs do SBC, as métricas de rede e o relatório da operadora. O método abaixo isola o ponto de falha em cinco etapas, começando pela identificação do tipo de conexão.
- Identifique o tipo de conexão PSTN
Chamadas PSTN no Teams chegam por três caminhos: Calling Plan (Microsoft), Operator Connect (operadora parceira) ou Direct Routing (via SBC). Cada um expõe dados diferentes no CQD e nos logs do SBC. Verifique no portal do Teams qual método sua operação usa antes de investigar qualquer métrica. - Colete os dados da chamada específica no CQD
No Call Quality Dashboard, filtre pelo número do chamador, número do destino e intervalo de tempo exato. Anote os valores de Jitter, Packet Loss, Round Trip Time e MOS para cada perna da chamada. Se a perna PSTN mostra degradação, o problema está fora do Teams. - Analise os logs do SBC e as métricas de rede
No SBC, procure por códigos SIP de resposta, atrasos de setup e eventos de re-invite. Na rede, valide se os switches e roteadores aplicaram QoS corretamente para o tráfego de mídia. Um log SIP com 408 Request Timeout aponta para falha de rede, não de codec. - Compare com o relatório da operadora
Solicite à operadora o relatório de qualidade do mesmo intervalo de tempo. Compare o MOS reportado pela operadora com o que o CQD registrou. Discrepâncias acima de 0,5 pontos indicam que o problema está no tronco SIP ou no enlace entre o SBC e a operadora. - Isole o ponto de falha
Se o CQD mostra boa qualidade na perna interna e o SBC registra perda de pacotes no envio à operadora, o problema é o enlace WAN ou o provedor. Se ambos mostram degradação, o problema está no SBC ou na configuração de codec. Documente a conclusão com evidências de cada fonte.
Essa correlação transforma a reclamação subjetiva em um diagnóstico com evidências. Equipes que correlacionam CQD, SBC e operadora em um único fluxo reduzem o tempo de resolução de chamadas PSTN ruins. Para aprofundar a investigação em camadas, veja como receber ligações de clientes dentro do Microsoft Teams.
A Microsoft documenta que o Direct Routing exige que o SBC seja configurado com certificados confiáveis e que a porta de mídia seja aberta para o tráfego UDP. Sem essa base, qualquer análise de qualidade ficará comprometida. Consulte a documentação oficial da Microsoft sobre Direct Routing para validar os requisitos de firewall e certificado antes de acusar a operadora.
Quando o sintoma é intermitente, repita o processo com chamadas de teste controladas. Gere chamadas curtas entre ramais e para um número externo, registrando horário e duração. Compare os dados do CQD com os logs do SBC para cada teste, criando um padrão de comportamento.
Se a operadora não fornecer relatórios detalhados, use os códigos SIP do SBC como fonte primária. Códigos como 486 Busy Here indicam problema no destino, enquanto 503 Service Unavailable aponta falha na operadora. Essa distinção evita retrabalho e direciona a ação correta.
Quando escalar para um especialista em telefonia Teams?
Quando as falhas persistem após ajustes de QoS e análise no dashboard, o problema provavelmente está fora do seu alcance imediato. Falhas intermitentes que não se repetem em horários fixos, múltiplas reclamações sem padrão comum e logs de SBC com erros de sinalização são sinais claros de complexidade elevada. Nesse ponto, a equipe de infraestrutura já consumiu tempo de diagnóstico sem chegar a uma causa raiz definitiva.
Um especialista em telefonia Teams atua exatamente onde o autodiagnóstico para: correlação avançada entre o Call Quality Dashboard, logs de SBC e métricas da operadora. Ele identifica se o problema está no Direct Routing, na configuração de mídia ou no roteamento PSTN — algo que exige acesso a camadas que a maioria das equipes internas não possui. Equipes que documentam perfil, problema e requisitos reduzem ambiguidade na escolha de Call Quality Dashboard Teams.
Os critérios objetivos para escalar incluem: chamadas PSTN com falha recorrente após alterações no SBC, degradação de áudio que persiste em diferentes sub-redes e alertas de jitter ou perda de pacotes sem correlação com picos de uso. Se você já validou rede, QoS e configuração do CQD sem resultado, o próximo passo é uma análise especializada. A TW Solutions oferece diagnóstico de arquitetura para telefonia Teams, integrando operadora, SBC e Direct Routing em um único plano de ação.
O custo de não agir é operacional: chamadas ruins geram retrabalho, clientes insatisfeitos e horas de troubleshooting que poderiam ser evitadas. Um especialista também acelera a integração com a operadora, algo que internamente pode levar semanas de idas e vindas. Para saber se sua operação precisa desse suporte, avalie se os problemas persistem por mais de duas semanas com evidências inconclusivas no dashboard.
Fale com um consultor da TW Solutions e avalie a arquitetura ideal para sua operação.
Perguntas frequentes
O que o Call Quality Dashboard Teams mostra sobre chamadas ruins que o Call Analytics não mostra?
O Call Quality Dashboard Teams consolida métricas agregadas de qualidade de chamadas em toda a organização, como MOS, jitter, perda de pacotes e latência. Ele responde 'como está a saúde geral da telefonia', identificando padrões de degradação em subnets, dispositivos ou horários. O Call Analytics, por outro lado, foca em chamadas individuais de usuários específicos, respondendo 'o que aconteceu com esta ligação específica'.
Quando o Call Quality Dashboard Teams é suficiente para investigar chamadas ruins e quando ele não resolve?
O CQD resolve quando a causa da chamada ruim está dentro do seu perímetro de rede ou na configuração de dispositivos, pois ele mostra onde a chamada degradou. Ele não é suficiente quando o sintoma está na operadora, no SBC ou no tronco PSTN, pois o dashboard não enxerga esses pontos. Nesses casos, é preciso correlacionar com logs do SBC e relatórios da operadora.
Quais critérios ajudam a avaliar se o Call Quality Dashboard Teams é a ferramenta certa para minha equipe de infraestrutura?
Avalie se sua dor é identificar padrões de degradação em chamadas do Teams em toda a organização, como problemas em subnets, dispositivos ou horários específicos. Se você precisa de uma visão agregada para correlacionar sintomas subjetivos com métricas de rede, o CQD é adequado. Se o problema é investigar uma chamada individual, o Call Analytics é mais direto.
Quais erros evitar ao implementar o Call Quality Dashboard Teams para não ter relatórios enganosos?
O erro mais comum é implementar o dashboard antes de configurar QoS na rede. Sem DSCP 46 para áudio e políticas de fila em roteadores e switches, os indicadores de perda de pacotes, jitter e latência ficam altos mesmo em chamadas internas. Outros erros incluem ignorar a correlação com SBC e operadora, não definir alertas e tratar o CQD como ferramenta de busca, não de análise.
Qual a diferença prática entre Call Quality Dashboard Teams e Call Analytics para diagnosticar uma reclamação de chamada ruim?
O Call Analytics é a primeira ferramenta para investigar uma reclamação individual, pois mostra o diagnóstico daquela sessão específica. O Call Quality Dashboard Teams é usado depois, para identificar se o problema é um padrão, afetando vários usuários em uma mesma subnet ou horário. Na prática, o CQD responde 'como está a saúde geral da telefonia', e o Call Analytics responde 'o que aconteceu com esta ligação'.
Por que o Call Quality Dashboard Teams pode falhar em apontar a causa raiz de chamadas ruins no Direct Routing?
O CQD mostra onde a chamada degradou, mas não enxerga o SBC, a operadora ou o tronco PSTN. Em chamadas Direct Routing, o dashboard pode indicar que o problema está fora do perímetro da rede, mas sem os logs do SBC e o relatório da operadora, você não consegue fechar o diagnóstico. Falhas intermitentes sem padrão comum são um sinal de que o problema está fora do alcance do CQD.
Em quais cenários de chamadas PSTN o Call Quality Dashboard Teams não é suficiente e exige escalar para um especialista?
Quando as falhas persistem após ajustes de QoS e análise no dashboard, o problema provavelmente está fora do seu alcance imediato. Falhas intermitentes sem horário fixo, múltiplas reclamações sem padrão comum e logs de SBC com erros de sinalização são sinais de complexidade elevada. Nesse ponto, um especialista em telefonia Teams faz a correlação avançada entre CQD, logs de SBC e métricas da operadora.
