Troubleshooting de SBC para Teams Direct Routing: Falhas de SIP OPTIONS, Erros de TLS, Problemas de Audio e Desativacao de Dominio

O Microsoft Teams Direct Routing tem um modo de falha frustrante: o Teams quase nunca informa por que algo quebrou. O trunk de Direct Routing do SBC passa de “Active” para “Inactive” no admin center, as chamadas param de conectar, e o unico sinal operacional que voce recebe e a ausencia de um.

Este guia aborda as categorias de falha que surgem em implantacoes reais de producao (falhas de heartbeat SIP OPTIONS, erros de handshake TLS, problemas de audio unidirecional e sem audio, desativacao de dominio de Direct Routing, peculiaridades de NAT e firewall especificas do Teams DR), e fornece uma ordem de triagem que resolve a maioria dos incidentes em menos de uma hora. O guia assume que o SBC ja esta implantado e funcionou em algum momento no passado, e que voce tem acesso ao call trace, captura de pacotes e configuracao do perfil TLS do SBC. Se voce ainda esta em fase de implantacao inicial, o guia de Teams Direct Routing cobre os requisitos e a configuracao inicial; este artigo continua de onde aquele parou.

O Modelo Mental de Tres Camadas para Triagem

Praticamente todo problema de Teams Direct Routing se reduz a uma falha em uma de tres camadas, e o sintoma observado indica qual delas investigar primeiro. Construir esse modelo mental e a diferenca entre trinta minutos de triagem e tres horas de tentativa e erro.

Camada de sinalizacao. O handshake TLS e a troca SIP entre o proxy SIP da Microsoft e o seu SBC. Falhas aqui produzem trunks marcados como “Inactive”, erros sustentados de SIP OPTIONS e chamadas que nunca chegam ao estado de toque.

Camada de midia. A troca SRTP/RTP entre o Teams (ou o Teams Media Processor) e o seu SBC, e depois entre o SBC e a operadora. Falhas aqui produzem chamadas que conectam e atendem normalmente, mas sem audio, com audio unidirecional, ou audio que corta aleatoriamente apos reter ou retomar uma chamada.

Camada de aplicacao. Politicas de roteamento do Teams, rotas de voz, planos de discagem, atribuicao de licenca de usuario e regras de roteamento do SBC. Falhas aqui produzem usuarios especificos ou padroes de discagem especificos que falham enquanto todo o resto funciona.

O erro mais comum e ir direto para uma captura de pacotes antes de classificar em qual camada esta a falha. A tabela de Triagem Rapida abaixo foi criada para fazer essa classificacao rapidamente, em duas colunas de tomada de decisao antes de abrir o Wireshark.

Triagem Rapida: Sintoma para Causa Provavel

Mapeie o que voce esta observando para a causa mais provavel e a camada a investigar primeiro. A maioria dos incidentes em producao se enquadra em uma dessas linhas.

Uma vez identificada a camada, a secao correspondente abaixo traz o detalhe diagnostico.

Falhas de SIP OPTIONS: A Causa de Interrupcao Mais Comum

Falha de SIP OPTIONS e a causa unica mais comum de uma interrupcao de Teams DR que afeta todo o sistema em vez de uma chamada especifica. Entender o que o OPTIONS faz, e exatamente como o Teams reage quando ele para de funcionar, leva voce a causa raiz mais rapido do que uma captura de pacotes.

E uma troca coordenada em ambos os lados: a Microsoft envia OPTIONS para o FQDN do seu SBC na porta TLS 5061, espera um 200 OK em poucos segundos e repete aproximadamente a cada minuto. Seu SBC faz o mesmo na direcao reversa, enviando OPTIONS para o proxy SIP regional da Microsoft e esperando um 200 OK de volta. Ambas as direcoes devem ter sucesso continuamente para que o Teams considere o trunk saudavel. Se qualquer direcao falhar consistentemente por varios minutos, o Teams muda o FQDN para “Inactive” e para de rotear chamadas para ou daquele SBC.

OPTIONS falha por causa de TLS ou falha de resolucao DNS, nao SIP. A causa raiz mais frequente de falha do OPTIONS nao e a requisicao OPTIONS em si, mas o handshake TLS que precisa ter sucesso antes que qualquer requisicao SIP possa ser enviada. Se o TLS falha, nenhuma requisicao OPTIONS e trocada, o SBC nao ve nada, e a Microsoft ve uma ausencia completa de resposta. A secao de Handshake TLS abaixo cobre essas causas raiz em detalhe.

OPTIONS falha porque o SBC parou de enviar ou a resolucao DNS falhou. A direcao reversa (SBC para Microsoft) quebra se o NAP de saida para a Microsoft esta mal configurado, se seu perfil TLS aponta para o certificado errado, ou se uma regra de roteamento bloqueia o metodo SIP OPTIONS no caminho de saida. O sinal no log do SBC e “no response” ou “timeout” contra o endereco do proxy SIP da Microsoft, sem um 200 OK de entrada correspondente.

O 200 OK que parece correto mas nao e. Um SBC pode responder ao OPTIONS da Microsoft com um 200 OK que contem cabecalhos Contact ou Via que o Teams nao aceita. O Teams trata a resposta como malformada e pode ainda marcar o FQDN como “Inactive” apesar do sucesso aparente. Se o log do SBC mostra o OPTIONS sendo recebido e um 200 OK sendo enviado, mas o trunk continua “Inactive”, capture o 200 OK completo em um trace de pacotes e inspecione cada cabecalho. O cabecalho Contact deve se referir ao FQDN do SBC, nao ao seu IP, e a cadeia Via deve ser valida.

Como o Teams decide desativar. A Microsoft nao publica os limites exatos, mas na pratica uma falha sustentada de OPTIONS (varios minutos consecutivos de falha em qualquer direcao) e suficiente para mudar o trunk para “Inactive”. A recuperacao nem sempre e imediata quando a causa e corrigida: o Teams tipicamente espera por sucesso sustentado antes de voltar para “Active”, o que pode levar de cinco a quinze minutos apos a correcao real estar aplicada. Nao assuma que sua correcao nao funcionou so porque o admin center demora para atualizar.

Falhas de Handshake TLS

Falhas de TLS sao a causa raiz unica mais comum de uma interrupcao de Direct Routing, e possuem um conjunto pequeno de gatilhos bem conhecidos. A tabela abaixo os resume, com o sinal de log que voce pode usar para confirmar cada um e a correcao.

Dois desses gatilhos merecem uma analise mais detalhada. A atualizacao de CA raiz da Microsoft que entrou em vigor ao longo de 2026 causou uma onda de falhas “Unknown CA” em implantacoes de Direct Routing porque o trust store do SBC nao continha as novas raizes DigiCert e Microsoft 2017 que a Microsoft comecou a apresentar em seus certificados de servidor. Se o seu SBC esta na configuracao de trust mais antiga e seu trunk tem estado intermitente ou inativo desde o inicio de 2026, essa e a causa mais provavel e a resolucao e importar as sete CAs raiz necessarias no trust store.

O outro gatilho a observar e a incompatibilidade de FQDN apos uma renovacao de certificado. Renovacoes as vezes perdem uma entrada de Subject Alternative Name (SAN), especialmente em implantacoes multi-tenant onde o SBC apresenta um certificado wildcard cobrindo varios subdominios. Apos cada renovacao de certificado, execute um teste TLS contra o FQDN do SBC na porta 5061 e confirme que o certificado servido inclui cada FQDN registrado para aquele SBC no Teams. O guia de configuracao de TLS e SRTP para SBC cobre os padroes de configuracao completos; este artigo foca no que os quebra.

Problemas de Audio Unidirecional e Sem Audio

Quando a sinalizacao funciona (chamadas conectam, o telefone do destinatario toca, ambos os lados atendem) mas o audio esta ausente em uma ou ambas as direcoes, o problema esta no caminho de midia. A parte dificil da triagem de midia e que existem varias causas distintas que produzem o mesmo sintoma principal, e apenas uma captura de pacotes ou relatorio MOS por chamada as diferencia.

Incompatibilidade de contexto criptografico SRTP. Ambos os lados concordam com SRTP no SDP, mas a chave criptografica, cipher suite ou comprimento da tag de autenticacao nao correspondem. O lado do Teams requer AES-CM com HMAC-SHA1; se o SDP do lado da operadora oferece um cipher diferente ou omite o atributo crypto, o SBC negocia contextos inconsistentes em cada leg e precisa realizar a re-criptografia SRTP por conta propria, com custo de desempenho e latencia. A correcao e impor a lista de cipher AES-CM em ambos os perfis de NAP e confirmar que o SBC esta realizando a reescrita criptografica entre legs em vez de passar o SDP sem modificacao. A visao geral de SRTP cobre as opcoes de cipher em detalhe.

Mudanca de chave criptografica SRTP ao longo das trocas SDP. O Microsoft Teams exige que a chave criptografica SRTP permaneca a mesma durante toda a duracao da chamada. Nenhuma renegociacao de chave SRTP deve ocorrer; caso contrario, o audio pode ser cortado ou decriptografado incorretamente, e a chamada pode ate ser derrubada pelo Teams.

Caminho de midia do SBC nunca abre para um lado. Se o SBC tem multiplas interfaces de rede (uma interface publica voltada para o Teams e uma privada voltada para a operadora), o roteamento de midia deve ser explicitamente vinculado a interface correta por NAP. Configuracao incorreta produz um caminho RTP semi-aberto: o SBC envia midia para um lado e os pacotes de retorno vao para uma interface obsoleta. O sinal e “no RTP received” em um leg no call trace, com o outro leg mostrando contagens normais de pacotes.

Traducao NAT quebra a porta RTP de entrada. Quando o SBC esta atras de um NAT, o endereco publico anunciado no SDP deve corresponder ao endereco que o firewall realmente mapeia. Um modo de falha comum e que a midia do SBC esta vinculada ao seu endereco privado, o SDP anuncia esse endereco, e o lado remoto tenta enviar RTP para um destino nao roteavel. A correcao e definir o endereco de midia externo do SBC explicitamente no NAP voltado para o Teams e confirmar que o firewall tem um mapeamento de porta estavel para o range de midia.

Incompatibilidade de oferta/resposta de codec. O Teams DR requer SILK, OPUS ou G.711 no lado do Teams. Se o lado da operadora oferece AMR, GSM ou iLBC e o SBC nao possui transcodificador por hardware, o SBC negocia G.711 no lado do Teams e falha em entregar qualquer midia no lado da operadora. O sinal e “no compatible codec” ou um 488 Not Acceptable Here em um leg. Alinhe a lista de codecs no trunk da operadora ou adicione um transcodificador.

Media bypass habilitado sem preparacao de firewall. O media bypass muda o caminho de midia: em vez da midia fluir pelo Media Processor regional da Microsoft, ela flui diretamente entre o cliente Teams e o SBC. O firewall do SBC agora deve aceitar midia de todo o range de IP de midia da Microsoft (nao apenas o range do proxy SIP), e pela internet publica em vez de dentro da rede controlada da Microsoft. O bypass que funcionou em laboratorio frequentemente quebra em producao porque essa mudanca de firewall nunca foi feita.

Audio corta em um intervalo regular. Audio que corta no mesmo intervalo e quase sempre um problema de session timer SIP (RFC 4028) em vez de um problema de midia. Um dos lados nao esta renovando a sessao via re-INVITE ou UPDATE, o timer expira e a chamada e encerrada. O session timer e o mensageiro e nao a causa raiz, que e quase sempre um problema de interoperabilidade em SRTP durante a negociacao SDP que afeta a sequencia de rollover dos pacotes RTP. O passo de troubleshooting ainda e configurar o SBC para renovar a sessao no lado que nao esta fazendo isso.

Dominio de Direct Routing Marcado como “Inactive”

O estado “Inactive” no Teams Admin Center e o unico sinal operacional visivel que a Microsoft fornece, e ele e consequencia de qualquer falha que o causou. Trate “Inactive” como um sintoma, nao como um diagnostico.

O estado e mostrado em Voice → Direct Routing → SBCs no Teams Admin Center, por FQDN de SBC. A pagina mostra a saude atual do SBC e o horario da ultima troca bem-sucedida de SIP OPTIONS em cada direcao. Quando o FQDN esta “Inactive”, o Teams para de rotear novas chamadas de saida para aquele SBC e rejeita INVITEs de entrada dele. Chamadas ja em andamento geralmente continuam ate a terminacao natural.

A sequencia de recuperacao e consistente na maioria dos casos:

1. Confirme que o FQDN do SBC resolve publicamente e que o SBC e alcancavel em TCP/TLS 5061 pela internet publica.
2. Confirme a resolucao DNS do SBC.
3. Confirme que o certificado do SBC nao esta expirado e inclui o FQDN registrado no seu SAN.
4. Confirme que o trust store do SBC inclui as CAs raiz atuais da Microsoft (cadeia DigiCert Global Root G2 mais raizes Microsoft 2017, conforme exigido pela atualizacao de CA raiz de 2026).
5. Inspecione o call trace do SBC para OPTIONS de entrada e OPTIONS de saida. Confirme que ambas as direcoes estao presentes e retornando 200 OK.
6. Se ambas as direcoes parecem saudaveis no SBC e o trunk continua “Inactive”, capture um trace de pacotes da resposta 200 OK e inspecione cada cabecalho. Cabecalhos Contact ou Via malformados sao o assassino silencioso de uma resposta aparentemente valida.

Se o FQDN nunca ficou “Active” (um novo SBC sendo adicionado), a causa raiz mais provavel e incompatibilidade de FQDN entre o SAN do certificado e o valor registrado no Teams, ou DNS ainda nao propagado para o FQDN. Ambos produzem “Inactive” indefinidamente sem recuperacao; nao ha falha da qual se recuperar porque o caminho de confianca nunca foi estabelecido.

NAT e Firewall: Peculiaridades Especificas do Teams DR

Regras genericas de firewall para SIP nao sao suficientes para o Teams Direct Routing. A Microsoft usa um conjunto especifico de enderecos de sinalizacao, o range de enderecos de midia e muito maior do que a maioria das equipes espera, e o recurso de firewall mais propenso a interferir (SIP ALG) vem habilitado por padrao em muitos firewalls corporativos. Tres coisas quebram o Teams DR mais do que qualquer outra.

SIP ALG deve ser desabilitado. SIP Application Layer Gateways reescrevem cabecalhos SIP e enderecos SDP em transito, o que quase nunca e compativel com mTLS (o firewall nao consegue ver dentro do stream criptografado para reescrever) e nunca e compativel com o comportamento SDP previsivel que o Teams espera. Se o firewall na interface publica do SBC tem SIP ALG habilitado, o Teams DR vai funcionar intermitentemente ou nao funcionar, e o modo de falha se parece com um problema de midia ou de cabecalho SIP. Desabilite o SIP ALG no firewall. A visao geral de seguranca do SBC explica por que a aplicacao de seguranca SIP pertence ao SBC, nao ao firewall.

O range de enderecos de sinalizacao da Microsoft deve estar alcancavel. A sinalizacao do Teams DR vem de um range de IP documentado da Microsoft (os FQDNs do proxy SIP sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com e sip3.pstnhub.microsoft.com resolvem nesse range). O firewall deve permitir TLS de entrada na porta 5061 desses enderecos para o FQDN do seu SBC. A Microsoft atualiza esse range periodicamente; se seu firewall usa uma allowlist estatica, voce vera interrupcoes intermitentes quando a Microsoft expandir o range. Use regras de permissao baseadas em FQDN ou assine o feed de URLs e ranges de IP da Microsoft.

O range de enderecos de midia e maior do que as pessoas esperam. O Teams Media Processor usa um range de enderecos; o media bypass usa outro (o endereco do cliente Teams, que pode estar em qualquer lugar da internet publica). Se o firewall do seu SBC abre apenas o range do Media Processor, o media bypass vai falhar. Se voce quer bypass, o range de portas de midia do SBC deve ser acessivel de qualquer IP de origem, com a filtragem SIP-aware do SBC fazendo a validacao por chamada em vez do firewall.

Uma outra peculiaridade que aparece repetidamente: NAT assimetrico em um SBC multi-homed. Se o SBC tem interfaces publica e privada separadas e o bind de midia esta errado, o RTP sai por uma interface e os pacotes de retorno chegam na outra. O SBC os descarta porque a origem nao corresponde a sessao estabelecida. Vincule o bind de midia explicitamente a interface correta no NAP voltado para o Teams.

Lendo Traces SIP para Teams DR

Uma vez identificada a camada e eliminadas as causas obvias, a ferramenta diagnostica e o trace SIP. Os dois recursos do ProSBC mais usados para triagem de Teams DR sao o call trace por NAP (que registra a sinalizacao SIP no nivel do grupo de troncos) e a captura Wireshark ao vivo (que da visibilidade completa em nivel de pacote da mensagem SIP, resolucao DNS e midia). Ambos rodam no SBC sem sondas externas.

Ha uma lista curta de coisas a inspecionar primeiro em qualquer trace de Teams DR.

A troca de OPTIONS. Confirme que o OPTIONS esta sendo recebido da Microsoft e retornado com um 200 OK. Confirme que o OPTIONS esta sendo enviado do SBC para a Microsoft e um 200 OK esta voltando. Se qualquer direcao estiver ausente, o relacionamento de confianca esta quebrado e o trunk estara “Inactive” independentemente do trafego de chamadas.

O handshake TLS. Se voce tem captura em nivel de pacote, o handshake TLS indica imediatamente se o problema e validacao de certificado, negociacao de cipher ou incompatibilidade de versao. Um handshake que completa mas e imediatamente seguido por um alerta TLS da Microsoft significa que o certificado passou, mas algo dentro da troca SIP foi inaceitavel.

Os cabecalhos do 200 OK. Inspecione os cabecalhos Contact e Via no 200 OK do OPTIONS. O Contact deve ser o FQDN do seu SBC sobre o transporte configurado. O Via deve refletir o SBC, nao um sistema downstream.

O SDP no setup da chamada. Para casos de falha de audio, o SDP tanto no INVITE quanto no 200 OK de resposta indica a lista de codecs que cada lado ofereceu, o atributo crypto SRTP e o endereco de midia. Compare o endereco anunciado com o endereco de onde a midia esta realmente chegando. As melhores praticas de monitoramento VoIP cobrem o que rastrear continuamente para que esse tipo de triagem comece de uma baseline mais rica.

Confirmacao de reescrita de cabecalho. O Teams tem um dialeto SIP especifico, e uma implantacao funcional de Teams DR quase sempre depende de manipulacao de cabecalhos SIP no SBC para normalizar entre o Teams e a operadora. Se os cabecalhos nao estao sendo reescritos, o trace mostrara os cabecalhos do Teams passando sem alteracao para a operadora (ou vice-versa), e um dos lados rejeitara a chamada. Confirme que as regras de reescrita nos NAPs relevantes estao carregadas.

O Playbook de Triagem

Quando um incidente de Teams DR chega e voce so tem “as chamadas nao estao funcionando”, os passos abaixo resolvem a maioria dos casos em menos de uma hora. Estao ordenados por probabilidade, nao por severidade.

1. Abra o Teams Admin Center e verifique o estado do FQDN do SBC. Se “Inactive”, o problema e sinalizacao e voce vai para o passo 2. Se “Active”, o problema e midia ou aplicacao e voce pula para o passo 5.
2. Confirme que o certificado do SBC nao esta expirado e que o FQDN registrado corresponde a um Subject Alternative Name no certificado servido. A maioria dos incidentes de “Inactive” em campo sao problemas de certificado.
3. Confirme que o trust store do SBC contem as CAs raiz atuais da Microsoft (a atualizacao de CA raiz de 2026 e a mudanca mais recente a ser aplicada). Raizes ausentes produzem falhas de handshake “Unknown CA” e “Inactive” imediato.
4. Inspecione o call trace do SBC para OPTIONS de entrada e de saida. Se o OPTIONS de saida esta ausente, o NAP de saida para a Microsoft esta mal configurado. Se o OPTIONS de entrada chega mas o 200 OK tem Contact ou Via malformado, a resposta e o problema.
5. Se o trunk esta “Active” mas chamadas de entrada nao chegam ao usuario, a causa e a camada de aplicacao do Teams (politica de roteamento de voz, rota de voz, plano de discagem, atribuicao de licenca, flag de usuario habilitado para Teams Phone). O SBC esta saudavel; a configuracao do Teams nao esta.
6. Se o audio esta ausente em chamadas que conectam, capture um trace em nivel RTP e confirme que a midia esta chegando ao SBC de ambas as direcoes. Midia ausente em um lado e um problema de caminho de midia ou NAT; midia presente mas sem audio e um problema de contexto criptografico SRTP.
7. Se o audio corta em intervalos regulares, a causa e tipicamente session timers RFC 4028, nao o caminho de midia. Configure o SBC para renovar a sessao.
8. Se os problemas sao novos e apareceram sem um catalisador, verifique expiracao de certificado nos proximos 30 dias, timeout de NAT menor que o intervalo do OPTIONS e mudancas recentes no firewall ou configuracao da operadora.

Se voce chegar ao final do playbook e o problema nao estiver resolvido, o proximo passo e uma captura de pacotes filtrada para o endereco do proxy SIP da Microsoft e os enderecos de midia relevantes. Nesse ponto, os dados necessarios para escalar o suporte, seja para a TelcoBridges, sua operadora ou a Microsoft, estao em maos.

Perguntas Frequentes