Troubleshooting de SBC para Teams Direct Routing: Falhas de SIP OPTIONS, Erros de TLS, Problemas de Áudio e Desativação de Domínio

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 único sinal operacional que você recebe é a ausência de um.

Este guia aborda as categorias de falha que surgem em implantações reais de produção (falhas de heartbeat SIP OPTIONS, erros de handshake TLS, problemas de áudio unidirecional e sem áudio, desativação de domínio de Direct Routing, peculiaridades de NAT e firewall específicas 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 já está implantado e funcionou em algum momento no passado, e que você tem acesso ao call trace, captura de pacotes e configuração do perfil TLS do SBC. Se você ainda está em fase de implantação inicial, o guia de Teams Direct Routing cobre os requisitos e a configuração inicial; este artigo continua de onde aquele parou.

O Modelo Mental de Três Camadas para Triagem

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

Camada de sinalização. 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 mídia. 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 áudio, com áudio unidirecional, ou áudio que corta aleatoriamente após reter ou retomar uma chamada.

Camada de aplicação. Políticas de roteamento do Teams, rotas de voz, planos de discagem, atribuição de licença de usuário e regras de roteamento do SBC. Falhas aqui produzem usuários específicos ou padrões de discagem específicos que falham enquanto todo o resto funciona.

O erro mais comum é ir direto para uma captura de pacotes antes de classificar em qual camada está a falha. A tabela de Triagem Rápida abaixo foi criada para fazer essa classificação rapidamente, em duas colunas de tomada de decisão antes de abrir o Wireshark.

Triagem Rápida: Sintoma para Causa Provável

Mapeie o que você está observando para a causa mais provável e a camada a investigar primeiro. A maioria dos incidentes em produção se enquadra em uma dessas linhas.

Uma vez identificada a camada, a seção correspondente abaixo traz o detalhe diagnóstico.

Falhas de SIP OPTIONS: A Causa de Interrupção Mais Comum

Falha de SIP OPTIONS é a causa única mais comum de uma interrupção de Teams DR que afeta todo o sistema em vez de uma chamada específica. Entender o que o OPTIONS faz, e exatamente como o Teams reage quando ele para de funcionar, leva você à causa raiz mais rápido do que uma captura de pacotes.

É 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 direção reversa, enviando OPTIONS para o proxy SIP regional da Microsoft e esperando um 200 OK de volta. Ambas as direções devem ter sucesso continuamente para que o Teams considere o trunk saudável. Se qualquer direção falhar consistentemente por vários 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 resolução DNS, não SIP. A causa raiz mais frequente de falha do OPTIONS não é a requisição OPTIONS em si, mas o handshake TLS que precisa ter sucesso antes que qualquer requisição SIP possa ser enviada. Se o TLS falha, nenhuma requisição OPTIONS é trocada, o SBC não vê nada, e a Microsoft vê uma ausência completa de resposta. A seção de Handshake TLS abaixo cobre essas causas raiz em detalhe.

OPTIONS falha porque o SBC parou de enviar ou a resolução DNS falhou. A direção reversa (SBC para Microsoft) quebra se o NAP de saída para a Microsoft está mal configurado, se seu perfil TLS aponta para o certificado errado, ou se uma regra de roteamento bloqueia o método SIP OPTIONS no caminho de saída. O sinal no log do SBC é “no response” ou “timeout” contra o endereço do proxy SIP da Microsoft, sem um 200 OK de entrada correspondente.

O 200 OK que parece correto mas não é. Um SBC pode responder ao OPTIONS da Microsoft com um 200 OK que contém cabeçalhos Contact ou Via que o Teams não 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 cabeçalho. O cabeçalho Contact deve se referir ao FQDN do SBC, não ao seu IP, e a cadeia Via deve ser válida.

Como o Teams decide desativar. A Microsoft não publica os limites exatos, mas na prática uma falha sustentada de OPTIONS (vários minutos consecutivos de falha em qualquer direção) é suficiente para mudar o trunk para “Inactive”. A recuperação nem sempre é imediata quando a causa é corrigida: o Teams tipicamente espera por sucesso sustentado antes de voltar para “Active”, o que pode levar de cinco a quinze minutos após a correção real estar aplicada. Não assuma que sua correção não funcionou só porque o admin center demora para atualizar.

Falhas de Handshake TLS

Falhas de TLS são a causa raiz única mais comum de uma interrupção de Direct Routing, e possuem um conjunto pequeno de gatilhos bem conhecidos. A tabela abaixo os resume, com o sinal de log que você pode usar para confirmar cada um e a correção.

Dois desses gatilhos merecem uma análise mais detalhada. A atualização de CA raiz da Microsoft que entrou em vigor ao longo de 2026 causou uma onda de falhas “Unknown CA” em implantações de Direct Routing porque o trust store do SBC não continha as novas raízes DigiCert e Microsoft 2017 que a Microsoft começou a apresentar em seus certificados de servidor. Se o seu SBC está na configuração de trust mais antiga e seu trunk tem estado intermitente ou inativo desde o início de 2026, essa é a causa mais provável e a resolução é importar as sete CAs raiz necessárias no trust store.

O outro gatilho a observar é a incompatibilidade de FQDN após uma renovação de certificado. Renovações às vezes perdem uma entrada de Subject Alternative Name (SAN), especialmente em implantações multi-tenant onde o SBC apresenta um certificado wildcard cobrindo vários subdomínios. Após cada renovação 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 configuração de TLS e SRTP para SBC cobre os padrões de configuração completos; este artigo foca no que os quebra.

Problemas de Áudio Unidirecional e Sem Áudio

Quando a sinalização funciona (chamadas conectam, o telefone do destinatário toca, ambos os lados atendem) mas o áudio está ausente em uma ou ambas as direções, o problema está no caminho de mídia. A parte difícil da triagem de mídia é que existem várias causas distintas que produzem o mesmo sintoma principal, e apenas uma captura de pacotes ou relatório MOS por chamada as diferencia.

Incompatibilidade de contexto criptográfico SRTP. Ambos os lados concordam com SRTP no SDP, mas a chave criptográfica, cipher suite ou comprimento da tag de autenticação não 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 própria, com custo de desempenho e latência. A correção é impor a lista de cipher AES-CM em ambos os perfis de NAP e confirmar que o SBC está realizando a reescrita criptográfica entre legs em vez de passar o SDP sem modificação. A visão geral de SRTP cobre as opções de cipher em detalhe.

Mudança de chave criptográfica SRTP ao longo das trocas SDP. O Microsoft Teams exige que a chave criptográfica SRTP permaneça a mesma durante toda a duração da chamada. Nenhuma renegociação de chave SRTP deve ocorrer; caso contrário, o áudio pode ser cortado ou decriptografado incorretamente, e a chamada pode até ser derrubada pelo Teams.

Caminho de mídia do SBC nunca abre para um lado. Se o SBC tem múltiplas interfaces de rede (uma interface pública voltada para o Teams e uma privada voltada para a operadora), o roteamento de mídia deve ser explicitamente vinculado à interface correta por NAP. Configuração incorreta produz um caminho RTP semi-aberto: o SBC envia mídia para um lado e os pacotes de retorno vão para uma interface obsoleta. O sinal é “no RTP received” em um leg no call trace, com o outro leg mostrando contagens normais de pacotes.

Tradução NAT quebra a porta RTP de entrada. Quando o SBC está atrás de um NAT, o endereço público anunciado no SDP deve corresponder ao endereço que o firewall realmente mapeia. Um modo de falha comum é que a mídia do SBC está vinculada ao seu endereço privado, o SDP anuncia esse endereço, e o lado remoto tenta enviar RTP para um destino não roteável. A correção é definir o endereço de mídia externo do SBC explicitamente no NAP voltado para o Teams e confirmar que o firewall tem um mapeamento de porta estável para o range de mídia.

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 não possui transcodificador por hardware, o SBC negocia G.711 no lado do Teams e falha em entregar qualquer mídia no lado da operadora. O sinal é “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 preparação de firewall. O media bypass muda o caminho de mídia: em vez da mídia fluir pelo Media Processor regional da Microsoft, ela flui diretamente entre o cliente Teams e o SBC. O firewall do SBC agora deve aceitar mídia de todo o range de IP de mídia da Microsoft (não apenas o range do proxy SIP), e pela internet pública em vez de dentro da rede controlada da Microsoft. O bypass que funcionou em laboratório frequentemente quebra em produção porque essa mudança de firewall nunca foi feita.

Áudio corta em um intervalo regular. Áudio que corta no mesmo intervalo é quase sempre um problema de session timer SIP (RFC 4028) em vez de um problema de mídia. Um dos lados não está renovando a sessão via re-INVITE ou UPDATE, o timer expira e a chamada é encerrada. O session timer é o mensageiro e não a causa raiz, que é quase sempre um problema de interoperabilidade em SRTP durante a negociação SDP que afeta a sequência de rollover dos pacotes RTP. O passo de troubleshooting ainda é configurar o SBC para renovar a sessão no lado que não está fazendo isso.

Domínio de Direct Routing Marcado como “Inactive”

O estado “Inactive” no Teams Admin Center é o único sinal operacional visível que a Microsoft fornece, e ele é consequência de qualquer falha que o causou. Trate “Inactive” como um sintoma, não como um diagnóstico.

O estado é mostrado em Voice → Direct Routing → SBCs no Teams Admin Center, por FQDN de SBC. A página mostra a saúde atual do SBC e o horário da última troca bem-sucedida de SIP OPTIONS em cada direção. Quando o FQDN está “Inactive”, o Teams para de rotear novas chamadas de saída para aquele SBC e rejeita INVITEs de entrada dele. Chamadas já em andamento geralmente continuam até a terminação natural.

A sequência de recuperação é consistente na maioria dos casos:

1. Confirme que o FQDN do SBC resolve publicamente e que o SBC é alcançável em TCP/TLS 5061 pela internet pública.
2. Confirme a resolução DNS do SBC.
3. Confirme que o certificado do SBC não está 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 raízes Microsoft 2017, conforme exigido pela atualização de CA raiz de 2026).
5. Inspecione o call trace do SBC para OPTIONS de entrada e OPTIONS de saída. Confirme que ambas as direções estão presentes e retornando 200 OK.
6. Se ambas as direções parecem saudáveis no SBC e o trunk continua “Inactive”, capture um trace de pacotes da resposta 200 OK e inspecione cada cabeçalho. Cabeçalhos Contact ou Via malformados são o assassino silencioso de uma resposta aparentemente válida.

Se o FQDN nunca ficou “Active” (um novo SBC sendo adicionado), a causa raiz mais provável é incompatibilidade de FQDN entre o SAN do certificado e o valor registrado no Teams, ou DNS ainda não propagado para o FQDN. Ambos produzem “Inactive” indefinidamente sem recuperação; não há falha da qual se recuperar porque o caminho de confiança nunca foi estabelecido.

NAT e Firewall: Peculiaridades Específicas do Teams DR

Regras genéricas de firewall para SIP não são suficientes para o Teams Direct Routing. A Microsoft usa um conjunto específico de endereços de sinalização, o range de endereços de mídia é muito maior do que a maioria das equipes espera, e o recurso de firewall mais propenso a interferir (SIP ALG) vem habilitado por padrão em muitos firewalls corporativos. Três coisas quebram o Teams DR mais do que qualquer outra.

SIP ALG deve ser desabilitado. SIP Application Layer Gateways reescrevem cabeçalhos SIP e endereços SDP em trânsito, o que quase nunca é compatível com mTLS (o firewall não consegue ver dentro do stream criptografado para reescrever) e nunca é compatível com o comportamento SDP previsível que o Teams espera. Se o firewall na interface pública do SBC tem SIP ALG habilitado, o Teams DR vai funcionar intermitentemente ou não funcionar, e o modo de falha se parece com um problema de mídia ou de cabeçalho SIP. Desabilite o SIP ALG no firewall. A visão geral de segurança do SBC explica por que a aplicação de segurança SIP pertence ao SBC, não ao firewall.

O range de endereços de sinalização da Microsoft deve estar alcançável. A sinalização 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 endereços para o FQDN do seu SBC. A Microsoft atualiza esse range periodicamente; se seu firewall usa uma allowlist estática, você verá interrupções intermitentes quando a Microsoft expandir o range. Use regras de permissão baseadas em FQDN ou assine o feed de URLs e ranges de IP da Microsoft.

O range de endereços de mídia é maior do que as pessoas esperam. O Teams Media Processor usa um range de endereços; o media bypass usa outro (o endereço do cliente Teams, que pode estar em qualquer lugar da internet pública). Se o firewall do seu SBC abre apenas o range do Media Processor, o media bypass vai falhar. Se você quer bypass, o range de portas de mídia do SBC deve ser acessível de qualquer IP de origem, com a filtragem SIP-aware do SBC fazendo a validação por chamada em vez do firewall.

Uma outra peculiaridade que aparece repetidamente: NAT assimétrico em um SBC multi-homed. Se o SBC tem interfaces pública e privada separadas e o bind de mídia está errado, o RTP sai por uma interface e os pacotes de retorno chegam na outra. O SBC os descarta porque a origem não corresponde à sessão estabelecida. Vincule o bind de mídia explicitamente à interface correta no NAP voltado para o Teams.

Lendo Traces SIP para Teams DR

Uma vez identificada a camada e eliminadas as causas óbvias, a ferramenta diagnóstica é o trace SIP. Os dois recursos do ProSBC mais usados para triagem de Teams DR são o call trace por NAP (que registra a sinalização SIP no nível do grupo de troncos) e a captura Wireshark ao vivo (que dá visibilidade completa em nível de pacote da mensagem SIP, resolução DNS e mídia). Ambos rodam no SBC sem sondas externas.

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

A troca de OPTIONS. Confirme que o OPTIONS está sendo recebido da Microsoft e retornado com um 200 OK. Confirme que o OPTIONS está sendo enviado do SBC para a Microsoft e um 200 OK está voltando. Se qualquer direção estiver ausente, o relacionamento de confiança está quebrado e o trunk estará “Inactive” independentemente do tráfego de chamadas.

O handshake TLS. Se você tem captura em nível de pacote, o handshake TLS indica imediatamente se o problema é validação de certificado, negociação de cipher ou incompatibilidade de versão. Um handshake que completa mas é imediatamente seguido por um alerta TLS da Microsoft significa que o certificado passou, mas algo dentro da troca SIP foi inaceitável.

Os cabeçalhos do 200 OK. Inspecione os cabeçalhos 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, não um sistema downstream.

O SDP no setup da chamada. Para casos de falha de áudio, 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 endereço de mídia. Compare o endereço anunciado com o endereço de onde a mídia está realmente chegando. As melhores práticas de monitoramento VoIP cobrem o que rastrear continuamente para que esse tipo de triagem comece de uma baseline mais rica.

Confirmação de reescrita de cabeçalho. O Teams tem um dialeto SIP específico, e uma implantação funcional de Teams DR quase sempre depende de manipulação de cabeçalhos SIP no SBC para normalizar entre o Teams e a operadora. Se os cabeçalhos não estão sendo reescritos, o trace mostrará os cabeçalhos do Teams passando sem alteração para a operadora (ou vice-versa), e um dos lados rejeitará a chamada. Confirme que as regras de reescrita nos NAPs relevantes estão carregadas.

O Playbook de Triagem

Quando um incidente de Teams DR chega e você só tem “as chamadas não estão funcionando”, os passos abaixo resolvem a maioria dos casos em menos de uma hora. Estão ordenados por probabilidade, não por severidade.

1. Abra o Teams Admin Center e verifique o estado do FQDN do SBC. Se “Inactive”, o problema é sinalização e você vai para o passo 2. Se “Active”, o problema é mídia ou aplicação e você pula para o passo 5.
2. Confirme que o certificado do SBC não está expirado e que o FQDN registrado corresponde a um Subject Alternative Name no certificado servido. A maioria dos incidentes de “Inactive” em campo são problemas de certificado.
3. Confirme que o trust store do SBC contém as CAs raiz atuais da Microsoft (a atualização de CA raiz de 2026 é a mudança mais recente a ser aplicada). Raízes ausentes produzem falhas de handshake “Unknown CA” e “Inactive” imediato.
4. Inspecione o call trace do SBC para OPTIONS de entrada e de saída. Se o OPTIONS de saída está ausente, o NAP de saída para a Microsoft está mal configurado. Se o OPTIONS de entrada chega mas o 200 OK tem Contact ou Via malformado, a resposta é o problema.
5. Se o trunk está “Active” mas chamadas de entrada não chegam ao usuário, a causa é a camada de aplicação do Teams (política de roteamento de voz, rota de voz, plano de discagem, atribuição de licença, flag de usuário habilitado para Teams Phone). O SBC está saudável; a configuração do Teams não está.
6. Se o áudio está ausente em chamadas que conectam, capture um trace em nível RTP e confirme que a mídia está chegando ao SBC de ambas as direções. Mídia ausente em um lado é um problema de caminho de mídia ou NAT; mídia presente mas sem áudio é um problema de contexto criptográfico SRTP.
7. Se o áudio corta em intervalos regulares, a causa é tipicamente session timers RFC 4028, não o caminho de mídia. Configure o SBC para renovar a sessão.
8. Se os problemas são novos e apareceram sem um catalisador, verifique expiração de certificado nos próximos 30 dias, timeout de NAT menor que o intervalo do OPTIONS e mudanças recentes no firewall ou configuração da operadora.

Se você chegar ao final do playbook e o problema não estiver resolvido, o próximo passo é uma captura de pacotes filtrada para o endereço do proxy SIP da Microsoft e os endereços de mídia relevantes. Nesse ponto, os dados necessários para escalar o suporte, seja para a TelcoBridges, sua operadora ou a Microsoft, estão em mãos.

Perguntas Frequentes