Teams recebe mas não liga aponta para falha em uma camada específica: licença, política de chamadas, roteamento PSTN, SBC ou rede — e o diagnóstico correto começa isolando cada uma com testes objetivos.
Se sua operação depende do Teams para telefonia e as chamadas falham na produção, o erro comum é culpar a operadora ou o provedor antes de verificar a configuração interna. O problema raramente está em um único ponto; ele se espalha por camadas que precisam ser testadas na ordem certa.
Teams recebe chamadas, mas não consegue ligar: por onde começar o diagnóstico?
O sintoma "recebe mas não liga" indica que a chamada chega ao seu número, mas o caminho de saída está bloqueado. Isso separa o problema em duas direções: a recepção usa um tronco ou operadora, e a saída depende de roteamento, política e permissão de chamada.
Para um administrador Microsoft 365, o primeiro passo é verificar se o usuário tem licença de Telefonia do Teams e plano de chamadas ou roteamento via Direct Routing. Sem licença válida, o botão de discar pode aparecer, mas a chamada não completa — o Teams recebe mas não liga por falta de permissão.
O diagnóstico por camadas segue esta ordem: licença, política de chamadas, roteamento PSTN, SBC, rede e dispositivo. Cada camada tem sinais observáveis que apontam para a causa sem depender de suposição.
Equipes que isolam a falha por camadas antes de acionar o provedor reduzem o tempo de indisponibilidade e evitam trocas desnecessárias de operadora.
Licença e política: a primeira barreira para chamadas de saída
Verifique se o usuário tem a licença de Telefonia do Teams atribuída e se o plano de chamadas está ativo. Sem isso, o Teams permite receber chamadas via operadora, mas bloqueia a saída por falta de permissão.
Políticas de chamadas também controlam quem pode fazer chamadas externas. Uma política restritiva aplicada ao usuário impede a saída mesmo com licença e roteamento corretos.
Teste prático: peça ao usuário para tentar ligar para um número interno e depois externo. Se interno funciona e externo falha, o problema está na política ou no roteamento — não no SBC ou na rede.
Roteamento PSTN e SBC: onde as chamadas de saída travam
No Direct Routing, a chamada de saída precisa de uma rota configurada no Teams que aponte para o SBC correto. Sem rota ou com rota incorreta, a chamada falha silenciosamente — o Teams recebe mas não liga.
Verifique se o SBC está registrado no tenant e se o tronco está ativo. Teste com um número de teste via PSTN para confirmar que o caminho de mídia funciona.
Se você usa Operator Connect ou Calling Plans, a rota é gerenciada pela operadora, mas a política de chamadas ainda pode bloquear a saída. Confirme a atribuição da política antes de abrir chamado com o provedor.
Rede e dispositivo: a camada que ninguém verifica primeiro
O Call Quality Dashboard mostra se a chamada falhou por problemas de rede — jitter, perda de pacotes ou latência. Esses dados ajudam a distinguir falha de configuração de falha de infraestrutura.
Dispositivos com firmware desatualizado ou fones USB com driver antigo também causam falhas de saída. Teste com o aplicativo desktop e com o celular para isolar o problema de hardware.
Para uma análise mais profunda, o Call Analytics mostra o motivo exato da falha, como "rota não encontrada" ou "permissão negada". Use esses dados para direcionar o próximo passo.
Quando a falha persiste: próximos passos objetivos
Após testar licença, política, roteamento, SBC e rede, documente o resultado de cada teste. Essa documentação é essencial para abrir chamado com a Microsoft ou com o provedor de telefonia.
Se o problema ocorre apenas com alguns usuários, compare a configuração deles com a de usuários que funcionam. A diferença entre as duas configurações geralmente revela a causa.
Para cenários de produção, mantenha um checklist de diagnóstico por camadas. Isso padroniza a resposta e reduz o tempo de resolução.
Saiba como diagnosticar o caminho inverso no guia sobre Teams liga mas não recebe chamadas.
Tabela de decisão para diagnosticar "Teams recebe mas não liga"
| Sintoma observado | Camada provável | Teste objetivo | Ação recomendada |
|---|---|---|---|
| Chamada interna funciona, externa falha | Política de chamadas ou roteamento | Verificar política de saída no Teams Admin Center | Ajustar política ou rota de saída |
| Botão de discar aparece, mas chamada não completa | Licença ou permissão | Confirmar licença de Telefonia e plano de chamadas | Atribuir licença ou plano correto |
| Falha intermitente em chamadas de saída | Rede ou SBC | Verificar Call Quality Dashboard para jitter e perda de pacotes | Corrigir QoS ou revisar configuração do SBC |
| Falha em horários específicos | Capacidade do SBC ou operadora | Monitorar tráfego no SBC durante o pico | Revisar capacidade ou roteamento de contingência |
Erros comuns ao diagnosticar chamadas de saída no Teams
- Culpar a operadora antes de verificar política e roteamento interno — a maioria das falhas está na configuração do tenant.
- Ignorar o Call Quality Dashboard — ele mostra a causa raiz da falha de mídia sem precisar de suposição.
- Trocar de fornecedor sem documentar os testes — isso adia a resolução e repete o problema com o novo provedor.
- Esquecer de testar dispositivo — fones e headsets com driver desatualizado causam falhas que parecem problema de rede.
Quais são as causas mais comuns para chamadas saindo falhando no Teams?
Chamadas de saída falhando no Teams raramente têm uma única causa. O problema quase sempre está em uma das cinco camadas: licença, política, roteamento PSTN, SBC ou rede. Cada camada exige um teste específico antes de culpar a operadora.
Teams recebe mas não liga é uma falha de chamada de saída em que o usuário recebe chamadas normalmente, mas ao tentar discar, a ligação falha ou não completa. Isso indica que a configuração de entrada está saudável, enquanto a cadeia de saída — licença, política, roteamento ou SBC — apresenta uma interrupção específica.
- Licença Teams Phone não atribuída ou sem plano de chamadas: Sem a licença Microsoft Teams Phone, o botão de discagem pode aparecer, mas a chamada não completa. Verifique no Centro de administração do Microsoft 365 se o usuário tem a licença atribuída e se existe um plano de chamadas ou créditos de comunicação ativos.
- Política de roteamento de voz incorreta ou sem usuário atribuído: A política de roteamento de voz define qual tronco ou plano será usado para a chamada. Se ela não estiver atribuída ao usuário, o Teams não sabe para onde enviar a ligação. Teste atribuindo uma política conhecida e válida a um usuário de teste.
- SBC não configurado corretamente para Direct Routing: O Session Border Controller precisa ter o FQDN autorizado no tenant, o certificado válido e as rotas de chamada configuradas. Um erro comum é o FQDN não corresponder exatamente ao registrado no Microsoft 365. Teste com o cmdlet
Get-CsOnlinePSTNGatewaypara validar o gateway. - Problemas de rede: firewall, QoS, banda insuficiente: Firewalls que bloqueiam portas SIP/TLS ou políticas de QoS mal configuradas podem derrubar chamadas de saída. Verifique se os endpoints do Microsoft Teams estão acessíveis e se a porta 5061 (TLS) para SIP está liberada para o SBC.
- Número DID não provisionado ou associado ao usuário: O número de saída pode não estar habilitado para chamadas externas ou pode estar associado a outro usuário. Confirme no Centro de administração se o número está atribuído corretamente e se o uso permitido inclui chamadas de saída.
A ordem dos testes importa. Comece pela licença, depois política, roteamento, SBC e rede — nessa sequência. Pular etapas faz você perder tempo reconfigurando o SBC quando o problema está na licença do usuário.
O cenário mais comum em produção combina duas falhas: usuário com licença correta, mas política de roteamento de voz não atribuída. O Teams recebe chamadas normalmente porque a entrada usa configuração diferente, mas a saída falha porque não há política associada ao usuário.
Equipes que testam cada camada isoladamente reduzem o tempo de diagnóstico de horas para minutos. A documentação oficial da Microsoft sobre Direct Routing especifica que o SBC deve ter um certificado público emitido por uma autoridade confiável e que o FQDN não pode ser um endereço IP. Se o seu SBC usa IP no lugar de FQDN, a chamada de saída falhará na autenticação com o tenant.
Quando o problema persiste após validar essas cinco camadas, o próximo passo é verificar a operadora. Uma falha no tronco SIP ou uma rota mal configurada no provedor pode impedir a chamada de saída, mesmo com toda a configuração do Teams correta. Nesse caso, peça ao provedor o log de sinalização SIP da chamada para identificar onde ela foi rejeitada.
Para chamadas que falham apenas em horários de pico, o problema pode ser banda insuficiente. O Microsoft Teams requer aproximadamente 1,5 Mbps para chamadas de áudio de alta qualidade. Se a sua operação usa o Teams para chamadas simultâneas, o link de internet pode saturar e derrubar chamadas de saída — mesmo com toda a configuração de voz correta.
A configuração do SBC para Direct Routing exige que o gateway esteja habilitado para chamadas de saída. Verifique também se o tronco configurado no SBC aponta para o número correto da operadora. Um tronco apontando para o número errado faz a chamada completar, mas cair em destino incorreto — o que parece ser falha de saída, mas é erro de roteamento.
Para diagnosticar com precisão, use o diagnóstico de chamadas do Centro de administração do Teams. Ele mostra o caminho completo da chamada, incluindo o SBC e o tronco usado. Esse relatório indica se a chamada falhou antes de chegar ao SBC (problema de política/licença) ou depois (problema de SBC/operadora).
Se o problema for recorrente, documente cada teste realizado. Isso evita retrabalho e ajuda a identificar padrões. Por exemplo, se todas as chamadas de saída falham para números móveis, mas funcionam para fixos, o problema pode estar na operadora, não na configuração do Teams.
O erro mais comum ao diagnosticar é trocar o SBC ou o provedor sem antes validar a política de roteamento de voz. A Microsoft documenta que a política de roteamento de voz é obrigatória para chamadas de saída via Direct Routing. Sem ela, o Teams não envia a chamada para o SBC, mesmo com tudo mais configurado corretamente.
Para evitar esse tipo de retrabalho, crie um checklist de verificação antes de qualquer alteração. Inclua: licença ativa, política de roteamento atribuída, FQDN do SBC autorizado, certificado válido, porta 5061 liberada e número DID associado ao usuário. Esse checklist cobre as cinco causas mais comuns de falha de saída no Teams.
Se você já verificou todas as camadas e o problema persiste, considere testar com outro usuário. Isso ajuda a identificar se o problema está na configuração do usuário específico ou na infraestrutura compartilhada. Um usuário com configuração correta que falha indica problema no SBC ou na operadora.
Para chamadas de saída via Calling Plans, a verificação é diferente. Nesse caso, não há SBC envolvido — o problema está na atribuição do número ou no saldo de créditos de comunicação. Verifique se o usuário tem um número de telefone atribuído e se o plano de chamadas permite chamadas de saída para o destino desejado.
O mesmo vale para Operator Connect, que usa a infraestrutura da operadora para conectar ao Teams. Nesse modelo, a falha de saída geralmente está na operadora ou na configuração do operador no tenant. Teste com uma chamada para um número interno para validar se o problema é geral ou específico de destinos externos.
Quando a falha é intermitente, o problema provavelmente está na rede. Verifique a qualidade do link de internet e a configuração de QoS nos switches. Chamadas que falham apenas em horários de pico indicam saturação de banda ou priorização incorreta de tráfego de voz.
Para validar a rede, use o teste de qualidade de chamada do Teams. Ele mede jitter, latência e perda de pacotes — os três indicadores que afetam chamadas de voz. Se esses valores estiverem fora do aceitável, o problema está na rede, não na configuração do Teams.
Se você precisa de ajuda para diagnosticar chamadas falhando no Teams, veja como resolvemos o cenário inverso neste guia. A TW Solutions atua com telefonia em nuvem desde 2007 e pode ajudar a identificar a causa exata da falha de saída na sua operação.
Como diagnosticar o problema por camadas: guia prático para o administrador
Quando o Teams recebe chamadas, mas as de saída falham, o diagnóstico deve seguir uma ordem lógica: licença, política, roteamento, SBC e rede. Comece pela camada mais barata de testar e avance apenas quando ela estiver descartada.
Teams recebe mas não liga é um sintoma de falha em uma das cinco camadas da telefonia: licença do Teams Phone, política de chamadas, roteamento PSTN, configuração do SBC ou rede. O diagnóstico correto isola cada camada com testes objetivos antes de alterar qualquer configuração de produção.
- Verifique a licença e atribuição do Teams Phone
Acesse o Centro de administração do Microsoft 365 e confirme se o usuário possui a licença Teams Phone atribuída e habilitada. Sem essa licença, o botão de discagem pode aparecer, mas a chamada é bloqueada antes de sair do Teams. Teste objetivo: tente fazer uma chamada interna para outro usuário da mesma organização — se funcionar, a licença está ativa. - Valide as políticas de voz e o roteamento de chamadas
No Teams Admin Center, abra Políticas de voz e confirme se o usuário está associado a uma política que permite chamadas de saída. Verifique também se o plano de discagem está configurado para o formato correto de números. Teste objetivo: use o diagnóstico de chamadas do Teams Admin Center para ver qual política foi aplicada à chamada falhada. - Teste a conectividade PSTN pelo caminho que você usa
Se você usa Calling Plan, verifique se há créditos de comunicação disponíveis. Se usa Operator Connect ou Direct Routing, confirme se o tronco está ativo e se o número de saída está habilitado. Teste objetivo: faça uma chamada de teste para um número externo usando o aplicativo Teams para desktop, não o cliente web — o comportamento pode ser diferente. - Analise os logs do SBC e as sessões no Teams
O SBC registra o código SIP de rejeição (como 403, 404 ou 480) que indica onde a chamada travou. Compare esses logs com as sessões de chamada no Call Quality Dashboard para identificar o ponto exato da falha. Teste objetivo: gere um relatório de sessão no CQD filtrando pelo usuário que não consegue ligar e verifique o código SIP final.
Esse fluxo de diagnóstico por camadas evita que você troque de operadora ou altere o SBC sem antes confirmar onde a falha realmente acontece. Na prática, a maioria dos casos de "Teams recebe mas não liga" está em política de voz mal configurada ou em roteamento PSTN incompleto — não no provedor.
O diagnóstico por camadas reduz o tempo de resolução porque cada etapa elimina uma hipótese com evidência objetiva. Se você chegou até aqui e ainda não identificou a causa, o próximo passo é analisar o tráfego de rede durante uma chamada de teste com o WireShark ou o próprio CQD. Para cenários mais complexos, como Direct Routing com múltiplos SBCs, vale consultar a documentação oficial da Microsoft sobre Direct Routing e o guia de resolução de problemas do Call Quality Dashboard.
Quando o problema persiste após todas as verificações, o caminho é registrar um chamado com a Microsoft ou com o suporte do seu provedor de telefonia. Tenha em mãos o horário exato da chamada falhada, o código SIP retornado e o log do SBC — isso acelera qualquer atendimento. Se a falha estiver associada a chamadas de saída para ramais internos, o problema pode estar no PABX, não no Teams — verifique separadamente cada fluxo de chamada.
Quando faz sentido aplicar esse diagnóstico e quando não faz
Esse passo a passo faz sentido quando a falha é intermitente ou afeta usuários específicos. Se todas as chamadas de saída falham simultaneamente, o problema provavelmente está no tronco ou no SBC — pule para a etapa 4 diretamente.
O diagnóstico por camadas não faz sentido quando a chamada nem chega a conectar com o Teams, ou seja, quando o usuário nem consegue abrir o discador. Nesse caso, o problema é de aplicativo ou autenticação, não de telefonia.
| Cenário observado | Camada provável | Teste inicial | Ação recomendada |
|---|---|---|---|
| — | Rede ou QoS | CQD: perda de pacotes e jitter | Corrigir QoS ou banda na rede |
| Chamada falha imediatamente com tom de erro | Política ou roteamento | Política de voz no Teams Admin | Ajustar política ou plano de discagem |
| Erro 403 ou 404 no SBC | Roteamento PSTN | Logs do SBC | Corrigir regra de tradução ou tronco |
| Chamada funciona no desktop, falha no celular | Dispositivo ou rede do usuário | Teste em outra rede Wi-Fi | Verificar VPN ou firewall do dispositivo |
Para administradores que precisam reduzir o tempo até o primeiro áudio, a ordem do diagnóstico muda: verifique primeiro a rede, depois o SBC. A latência de processamento no Teams raramente é a causa de chamadas que não completam.
Se a sua operação depende de chamadas de saída para atendimento ao cliente, o diagnóstico estruturado evita interrupções prolongadas. Um administrador que documenta cada teste realizado e o resultado obtido reduz o tempo de resolução na próxima ocorrência. Essa documentação também é útil para integrações de voz com outras plataformas que compartilham o mesmo tronco.
Como escolher
Quando o Teams recebe chamadas normalmente, mas as de saída falham, o problema está em uma das cinco camadas: licença, política de chamadas, roteamento PSTN, SBC ou rede. A tabela abaixo relaciona sintomas observáveis, causas prováveis, testes objetivos e ações recomendadas para cada cenário.
| Sintoma observável | Causa provável | Teste para confirmar | Ação recomendada |
|---|---|---|---|
| Chamadas de saída não conectam, mas recebe normalmente | Política de voz sem permissão de chamada de saída ou roteamento PSTN incorreto | Verificar logs de chamadas no Teams Admin Center e testar com usuário de teste | Corrigir política de voz ou ajustar roteamento PSTN; validar com chamada de teste |
| Chamada sai, mas cai após alguns segundos | Configuração incorreta de tronco SBC ou balanceamento de chamadas | Analisar logs do SBC e comparar com relatório de chamadas do Teams | Ajustar configuração do tronco e validar codecs; verificar se o SBC está registrado corretamente |
| Chamada de saída falha apenas para números externos | Política de chamada restringe números externos ou roteamento para PSTN incompleto | Testar chamada para número interno e externo; revisar política de voz | Atualizar política para permitir chamadas externas e conferir regras de normalização |
| Chamada falha apenas em horários de pico | Capacidade do SBC ou link de rede saturado | Monitorar tráfego no SBC e latência da rede durante pico | Dimensionar capacidade do SBC ou priorizar tráfego de voz na rede |
| Chamada falha apenas para um usuário específico | Licença de chamada ausente ou política atribuída incorretamente | Verificar licença do usuário no M365 Admin Center e políticas atribuídas | Atribuir licença de chamada correta e reaplicar política de voz |
O teste mais rápido para diferenciar camada de configuração de camada de rede é usar o diagnóstico de chamadas do Teams Admin Center. Ele mostra se a falha ocorreu antes ou depois do tráfego chegar ao SBC. Com esse dado, você elimina a rede ou o roteamento como causa em poucos minutos.
Para chamadas que falham esporadicamente, o relatório de qualidade de chamadas (CQD) ajuda a correlacionar horário, usuário e dispositivo. Se a falha é constante, a causa está mais provavelmente em licença ou política — que são as camadas mais fáceis de corrigir. A ordem de diagnóstico deve ser licença, política, roteamento, SBC e rede — nessa sequência, porque cada camada depende da anterior.
Se você já confirmou que a licença e a política estão corretas, o próximo passo é verificar o roteamento PSTN. A documentação oficial da Microsoft sobre roteamento de voz detalha como configurar troncos e regras de normalização para chamadas de saída. Quando o roteamento está correto e o SBC responde, a falha residual aponta para rede ou dispositivo.
Na prática, a maioria das falhas de chamada de saída no Teams é resolvida com ajuste de política ou correção de roteamento — não com troca de operadora. Antes de culpar o provedor PSTN, valide cada camada com os testes acima. Isso evita horas de troubleshooting e retrabalho com fornecedores.
Quando o problema é do SBC ou da operadora?
O SBC (Session Border Controller) é a primeira suspeita quando o Teams recebe chamadas, mas as de saída falham. Verifique o status de registro do SBC no painel do Direct Routing: se o tronco aparece como "Inactive", o problema está na autenticação ou conectividade do SBC com a Microsoft.
Logs de sinalização SIP no SBC mostram se a chamada saiu do Teams e onde parou. Um código 403 ou 404 na resposta SIP indica que a operadora rejeitou o número; um timeout aponta para roteamento ou rede. A documentação oficial da Microsoft sobre Direct Routing exige que o SBC envie o header P-Asserted-Identity com o número autorizado.
Para testar a operadora, faça uma chamada do mesmo número usando um aparelho físico ou um softphone fora do Teams. Se a ligação completar, o problema está na integração, não no tronco. Se falhar, a operadora bloqueou o número ou o roteamento de saída.
Administradores que isolam a falha entre SBC, operadora e rede antes de trocar fornecedor resolvem chamadas de saída em horas, não em dias.
Erro comum: culpar a operadora sem verificar os logs do SBC. Um tronco SIP pode estar ativo e ainda assim falhar chamadas de saída se o SBC não estiver enviando o número no formato E.164. Confira o prefixo de saída e o plano de discagem antes de abrir chamado na operadora.
Outro erro: ignorar o CQD (Call Quality Dashboard) do Teams. Ele mostra se a falha é generalizada ou pontual, e separa problemas de rede de problemas de configuração. Se o CQD indica boa qualidade, o problema está na configuração do SBC ou da operadora.
Quando o problema persistir, documente o horário exato, o número chamado e o código de erro SIP. Esses três dados reduzem o tempo de diagnóstico em qualquer fornecedor. Sem eles, você fica dependente de tentativa e erro — e o time de telecom da operadora também fica.
Para chamadas de saída que falham apenas para números específicos, teste com um número móvel e um fixo. Se apenas um falhar, o bloqueio é da operadora, não do SBC. Se ambos falharem, revise o roteamento no Direct Routing e a política de chamadas no Teams.
Se o problema for no SBC, reinicie o serviço e verifique se o certificado TLS está válido. Certificados expirados são causa frequente de falha intermitente em chamadas de saída no Teams. A Microsoft exige certificados assinados por uma autoridade pública para o Direct Routing.
Quando a falha estiver na operadora, peça o trace SIP da chamada. A operadora consegue ver se o número foi apresentado corretamente e se o bloqueio foi por política ou por roteamento. Com o trace em mãos, o ajuste é objetivo.
Se o problema for na rede, priorize o tráfego SIP e RTP na qualidade de serviço (QoS). Sem QoS, picos de uso podem degradar a chamada sem derrubar a sessão — o áudio falha, mas a chamada continua. O CQD mostra esses casos como "poor call rate" alto.
Para saber mais sobre o caminho inverso, veja nosso artigo sobre Teams liga mas não recebe chamadas. E para entender como a infraestrutura de voz se comporta em operação, consulte o guia sobre streaming para reduzir delay de voz.
Como configurar corretamente o Direct Routing para evitar falhas?
Para configurar o Direct Routing sem falhas, o administrador precisa validar quatro elementos na ordem: certificado e FQDN no SBC, políticas de roteamento de voz, associação de usuários e testes com logs. Um SBC registrado com FQDN inválido ou certificado expirado derruba chamadas de saída mesmo com licenças corretas.
- Valide o certificado e o FQDN do SBC — O certificado deve ser emitido por uma autoridade pública e o FQDN precisa ser resolvível publicamente. O nome comum (CN) ou Subject Alternative Name (SAN) do certificado deve corresponder exatamente ao FQDN registrado no Microsoft 365. Um erro comum é usar IP no lugar do FQDN, o que a Microsoft rejeita no registro do SBC.
- Crie as políticas de roteamento de voz — Acesse o Centro de administração do Teams e crie uma política de roteamento de voz com uma regra PSTN. Associe essa regra ao tronco do SBC que você configurou, definindo o padrão de discagem (por exemplo, ^\+?[1-9]\d{1,14}$) e a prioridade. Sem essa regra, o Teams não sabe para qual SBC enviar a chamada.
- Associe os usuários às políticas — Atribua a política de roteamento de voz e a política de discagem ao usuário ou ao grupo que fará as chamadas. A associação pode ser feita por usuário individual ou em lote via PowerShell. Verifique também se o usuário tem um plano de chamadas ou créditos de comunicação, dependendo do modelo de licenciamento.
- Habilite e configure o tronco do SBC — No portal do Teams, adicione o SBC como tronco e defina o número de chamadas simultâneas, o código de resposta esperado e o encaminhamento para a operadora. Configure o SBC para aceitar somente tráfego do Microsoft 365 e valide o status de registro como "Ativo".
- Teste chamadas reais e monitore logs — Faça uma chamada de teste para um número externo e verifique os logs do SBC e do Teams. No portal do Teams, use o diagnóstico de chamadas para confirmar se a chamada chegou ao SBC. Nos logs do SBC, procure por códigos SIP 200 OK (sucesso), 4xx (configuração) ou 5xx (servidor).
Equipes que configuram o Direct Routing sem validar os logs do SBC após cada etapa prolongam o tempo de inatividade das chamadas de saída. O diagnóstico por camadas evita que você troque de operadora quando o problema está no certificado ou na política. Se a chamada falhar, compare o timestamp da tentativa nos logs do Teams e do SBC para identificar onde o tráfego parou. A documentação oficial da Microsoft sobre Direct Routing especifica que o FQDN do SBC deve ser exclusivo e não pode ser compartilhado com outro tenant.
Quais erros evitar ao diagnosticar chamadas no Teams?
O erro mais comum é pular direto para a operadora sem validar a licença do usuário. Uma chamada de saída falha quando o plano de chamadas ou o crédito de comunicação não está atribuído corretamente.
Teste a licença antes de qualquer outra camada. Se o usuário não tem permissão de chamada de saída, o Teams recebe mas não liga por bloqueio de política, não por falha de rede.
- Não verificar licença antes de tudo: Administradores assumem que a licença está ativa porque o usuário recebe chamadas. A recepção usa um caminho diferente da saída. Valide a atribuição do plano de chamadas e o crédito de comunicação no centro de administração do Microsoft 365.
- Culpar a operadora sem testar outras camadas: Antes de abrir chamado com o provedor PSTN, teste uma chamada interna entre dois usuários do Teams. Se a chamada interna funciona, o problema está no roteamento para o SBC ou na configuração do Direct Routing.
- Ignorar logs do SBC: O Session Border Controller registra cada tentativa de chamada com código SIP e motivo de falha. Um código 403 indica permissão; um 408 indica timeout de roteamento. Sem consultar esses logs, o diagnóstico fica no escuro.
- Não usar o Call Quality Dashboard: O CQD mostra a qualidade das chamadas por usuário, rede e servidor. Ele revela se o problema é latência, perda de pacotes ou jitter antes de atingir o SBC. A documentação oficial da Microsoft recomenda o CQD como primeira fonte de análise de qualidade.
- Alterar configurações sem backup: Modificar políticas de chamada ou roteamento sem registrar o estado anterior pode transformar uma falha pontual em uma indisponibilidade geral. Exporte as políticas atuais e documente cada alteração antes de aplicar.
O diagnóstico por camadas exige disciplina: licença, política, roteamento, SBC, rede. Pular etapas aumenta o tempo de resolução e pode levar à troca desnecessária de operadora.
Se você precisa de apoio para isolar a causa exata, fale com um especialista em telefonia Teams que conheça o Direct Routing e o SBC na prática.
Quando escalar para um especialista em telefonia Teams?
Se você seguiu o diagnóstico por camadas e as chamadas de saída continuam falhando, o próximo passo é escalar o caso para um especialista em telefonia Teams. A persistência do problema após testes objetivos indica que a causa está em logs avançados, configuração fina do SBC ou interação complexa entre operadora e Direct Routing que exige análise profunda.
Um especialista analisa logs de sinalização SIP, verifica o roteamento de mídia e valida a configuração do SBC em nível de pacote, algo que o painel do Teams não mostra. A documentação oficial da Microsoft sobre Direct Routing define os requisitos de certificado, FQDN e porta, mas a aplicação prática em produção frequentemente exige ajustes que só aparecem em cenários reais de tráfego.
Profissionais de telecom e gestores de TI que tentaram resolver por conta própria costumam gastar horas em testes de rede sem identificar a falha. O custo de não agir é operacional: chamadas de saída falhando impactam o atendimento ao cliente, a produtividade das equipes e a confiança na plataforma de telefonia.
Quando o problema persiste após validar licença, política de chamadas, roteamento PSTN e rede, o suporte especializado é o caminho mais rápido para restabelecer a operação. A TW Solutions oferece suporte especializado em telefonia Teams, com análise de logs avançados e configuração de SBC para ambientes de produção.
Se a sua operação depende do Teams para chamadas de saída e o diagnóstico interno chegou ao limite, consulte o guia sobre chamadas recebidas e avalie a arquitetura atual. Fale com um consultor da TW Solutions e avalie a arquitetura ideal para sua operação.
Perguntas frequentes
Teams recebe chamadas mas não liga: o que exatamente significa esse sintoma e por onde começo a investigação?
Esse sintoma indica que a configuração de entrada está saudável, mas a cadeia de saída — licença, política, roteamento ou SBC — apresenta uma interrupção. O diagnóstico correto começa isolando cada camada com testes objetivos, começando pela licença do usuário, antes de culpar a operadora ou alterar qualquer configuração de produção.
Qual a diferença prática entre falha por licença do Teams Phone e falha por configuração do SBC quando o Teams recebe mas não liga?
A falha por licença ocorre quando o Teams Phone não está atribuído ou o plano de chamadas/crédito está ausente, bloqueando a saída mesmo com o resto funcionando. A falha por SBC aparece quando o tronco está 'Inactive' ou o certificado/FQDN está inválido. O teste de licença é mais barato e deve ser feito primeiro, antes de investigar o SBC.
Antes de contratar um especialista em telefonia Teams, quais verificações internas gratuitas devo fazer para resolver o problema de chamadas que não saem?
Antes de escalar, valide gratuitamente: a atribuição da licença Teams Phone e do plano de chamadas no centro de administração do Microsoft 365, a política de voz com permissão de saída, o status do tronco SBC no painel do Direct Routing e os logs de chamadas. Esses testes isolam a camada problemática sem custo adicional.
Quais requisitos do SBC e da operadora devo verificar quando o Teams recebe chamadas mas as de saída falham com código 403 ou timeout?
Verifique o status de registro do SBC no painel do Direct Routing. Um código 403 ou 404 na resposta SIP indica que a operadora rejeitou o número; timeout aponta para roteamento ou rede. Confirme que o SBC envia o header P-Asserted-Identity com o número autorizado, conforme a documentação oficial da Microsoft.
Como configurar o Direct Routing para evitar que o Teams receba chamadas mas não consiga ligar?
Valide quatro elementos na ordem: certificado e FQDN no SBC, políticas de roteamento de voz, associação de usuários e testes com logs. O certificado deve ser de autoridade pública com CN/SAN correspondendo exatamente ao FQDN registrado. Um FQDN inválido ou certificado expirado derruba chamadas de saída mesmo com licenças corretas.
Que evidências objetivas devo coletar para provar que o problema de chamada de saída no Teams está na operadora e não na configuração interna?
Colete logs de sinalização SIP no SBC mostrando onde a chamada parou. Se o tronco está 'Active' e a chamada saiu do Teams, mas a operadora respondeu com 403 ou 404, a evidência aponta para rejeição externa. Um timeout após o envio indica roteamento ou rede. Esses logs são a prova objetiva para escalar à operadora.
Quando o Teams recebe chamadas normalmente mas as de saída falham, isso indica que a operadora está com problema ou a configuração interna está errada?
O problema raramente está em um único ponto. A causa mais comum está em política de chamadas ou roteamento de voz, não na operadora. Licenças insuficientes ou mal atribuídas também bloqueiam chamadas. O diagnóstico correto isola cada camada — licença, política, roteamento, SBC e rede — na ordem certa antes de culpar o provedor externo.
