Como verificar se um SBC é certificado para Direct Routing
Para gestores e equipes responsáveis por avaliar Direct Routing e SBC, o primeiro critério prático é confirmar se o modelo e a versão de firmware constam na lista oficial de Border Controllers certificados da Microsoft. Essa verificação não se limita ao fabricante: um mesmo appliance pode aparecer em uma versão de software e desaparecer em outra. Portanto, o cruzamento correto é sempre modelo, versão de firmware e cenário de implantação — appliance físico, virtualizado em nuvem ou topologia com PABX existente. Ignorar essa distinção gera falsa sensação de conformidade e expõe o projeto a riscos operacionais, como falhas em SIP OPTIONS, mídia RTP desalinhada ou limites de suporte não documentados.
Um arquiteto de colaboração, integrador ou administrador avaliando Direct Routing deve tratar a certificação como pré-requisito, não como garantia absoluta. Estar na lista oficial não cobre firmware fora da faixa homologada, configurações de DNS e firewall incorretas ou voice routing mal definido. O projeto trava em SBC, certificado, DNS, firewall, SIP OPTIONS, RTP ou limites de suporte quando a validação é feita apenas no nome do equipamento. Por isso, o próximo passo é revisar a documentação de configuração de Direct Routing no tenant, incluindo tronco SIP, políticas de voz e tradução de números. Recursos marcados como preview mudam sem aviso, então a leitura deve ocorrer na data da decisão.
Equipes que cruzam modelo, firmware e cenário antes da compra reduzem retrabalho e implementam Direct Routing e SBC com segurança e previsibilidade. A certificação é o ponto de partida, mas a estabilidade depende de monitoramento contínuo de mídia, sinalização e limites de suporte entre Microsoft, fabricante e integrador.
O que a lista oficial da Microsoft realmente certifica — e o que ela não cobre
SBC certificado Direct Routing é um Border Controller cujo modelo e versão de firmware foram testados e homologados pela Microsoft para interoperar com o Teams Phone via Direct Routing. A homologação cobre a sinalização SIP com o serviço; não cobre rede, firewall, DNS interno ou operadora do cliente.
A lista oficial funciona como catálogo de interoperabilidade SIP, organizada por fabricante, modelo, faixa de firmware e tipo de implantação — appliance físico, virtualizado ou em nuvem. Um mesmo modelo pode aparecer em várias linhas, cada uma vinculada a uma versão específica de software. Essa granularidade é o ponto que mais gera erro de leitura: firmware fora da faixa listada invalida a premissa de suporte, mesmo que o hardware esteja na página. A Microsoft documenta esse escopo em Direct Routing Border Controllers, e a leitura correta exige checar versão, não apenas nome do modelo.
Qualidade de voz, jitter e perda de pacote ficam fora do escopo da certificação. Se o sintoma aparece como jitter alto no Teams, a causa costuma estar em roteamento RTP, firewall ou link — camadas que a lista não audita. O mesmo vale para DNS interno, certificados e capacidade contratada da operadora.
Survivable Branch Appliance é uma categoria distinta, com requisitos próprios descritos em documentação específica da Microsoft. Ela mantém chamadas em filiais quando o link com a nuvem cai e não substitui o SBC central. Tratar a lista como garantia de suporte em qualquer versão é o erro técnico mais comum em projetos de Direct Routing.
Para o administrador justificar a escolha internamente, o caminho é documentar três evidências: modelo e firmware homologados, topologia de rede validada e responsabilidade de cada camada.
Checklist de verificação: 7 sinais de que o SBC está no caminho suportado
Antes de fechar a arquitetura, o integrador responsável pelo deploy precisa demonstrar que o SBC opera dentro do perímetro homologado pela Microsoft. Os itens abaixo são verificáveis antes da assinatura do contrato e reduzem o risco de descobrir tarde que o firmware ou o cenário não é suportado.
- Modelo e versão na lista oficial. Confirme fabricante, modelo exato e versão de software na relação de Border Controllers publicada pela Microsoft. Um nome parecido não substitui a entrada homologada.
- Firmware dentro da faixa homologada. Verifique se a build instalada corresponde à versão certificada para aquele modelo. Atualizações fora da faixa podem invalidar o suporte.
- Cenário igual ao certificado. Valide se a implantação é appliance, virtualizada ou em nuvem conforme o cenário aprovado. Mudar o modo de hospedagem muda o escopo da certificação.
- SIP OPTIONS ativo para monitoramento. Confirme que o SBC envia e responde SIP OPTIONS no tronco. Esse mecanismo sustenta failover e detecção de tronco indisponível.
- Codecs de RTP alinhados. Cheque se o SBC negocia os codecs usados pelo Teams e pela operadora. Divergência de mídia gera chamada estabelecida sem áudio.
- DNS, firewall e portas revisados. Siga a documentação de configuração de Direct Routing para liberar FQDNs, ranges e portas exigidos pelo serviço.
- Voice routing e DID conferidos. Revise políticas de voz, rotas e atribuição de números no Teams Admin Center segundo o guia de voice routing. Erro aqui derruba chamada mesmo com SBC saudável.
Quando o SBC certificado resolve o problema — e quando ele não é a resposta
Para um gestor decidindo a arquitetura de voz, o SBC certificado para Direct Routing resolve quando já existe tronco SIP ativo, PABX legado ou contrato com operadora local que não participa do Operator Connect. Nesse caso, o SBC preserva o investimento e traduz a sinalização entre o Teams e a infraestrutura existente. O erro começa quando a escolha do SBC vira padrão sem avaliar alternativas de conectividade PSTN.
| Cenário operacional | Recurso mais aderente | Limite ou risco | Próximo passo |
|---|---|---|---|
| PABX legado com tronco SIP ativo e operadora local | Direct Routing com SBC certificado | Exige SBC homologado e configuração de dial plan | Validar o modelo na lista oficial da Microsoft |
| Operação sem tronco próprio e cobertura geográfica compatível | Calling Plans nativos | Disponibilidade varia por país e tipo de número | Conferir cobertura para cada localidade atendida |
| Filial com link instável ou risco de queda de WAN | Survivable Branch Appliance | Não substitui o SBC central em todos os fluxos | Avaliar SBA por site antes de centralizar toda a voz |
| Operadora já participante do Operator Connect | Operator Connect | Depende do portfólio da operadora no programa | Confirmar habilitação da operadora atual |
| Contact center com URA e gravação | SBC certificado como pré-requisito | Integração com contact center pertence a outra camada | Mapear requisitos de URA e gravação com o fornecedor |
Critérios como aderência ao tronco existente, complexidade de implantação, risco operacional e tempo até valor separam uma escolha da outra. Gestores que cruzam perfil de operação, requisito de conectividade e ação recomendada evitam tratar Calling Plans, Operator Connect e Direct Routing como sinônimos. A documentação da Microsoft sobre Phone System no Office 365 detalha as opções de conectividade PSTN.
Erros que quebram o deploy mesmo com SBC na lista oficial
Estar na lista de homologação da Microsoft não elimina falhas em produção. Para o administrador em operação, o cenário mais desgastante é aquele em que chamadas falham intermitentemente sem causa clara: o tronco aparece ativo, o SBC responde, mas ligações específicas caem ou nem completam. Nesses casos, o diagnóstico precisa começar pela camada de sinalização e avançar em ordem.
O primeiro ponto é validar o monitoramento de SIP OPTIONS. Sem esse sinal periódico, a indisponibilidade do tronco só aparece quando o usuário tenta ligar. O segundo é revisar o fluxo de RTP no firewall: regras assimétricas ou NAT que reescreve apenas um sentido geram áudio unidirecional e chamadas que completam sem voz. O terceiro é conferir a resolução de DNS para os FQDNs do Direct Routing, pois inconsistência entre o SBC e a Microsoft quebra registro e validação de certificado. O quarto é separar licenciamento de conectividade PSTN: Teams, Teams Phone e tronco são camadas distintas, e a falha em uma não indica falha na outra.
Antes de escalar para a Microsoft, o administrador deve validar firmware, sinalização, mídia e licenciamento na ordem documentada em Direct Routing configuration. Para sintomas de qualidade, o roteiro de monitoramento de qualidade de chamada e QoS ajuda a localizar a camada real do problema. Diagnosticar por camada, começando pelo SBC e pela rede local, reduz o tempo de resolução de falhas intermitentes e evita tickets prematuros.
Como testar, medir e saber a hora de escalar para um especialista
Um SBC certificado Direct Routing só prova valor quando a operação consegue isolar a falha por camada. A sequência abaixo separa problema de SBC, de rede, de operadora e de licença antes de acionar terceiros. Cada passo gera evidência verificável e um critério objetivo para avançar ou escalar.
- Validar a certificação do modelo. Confirme modelo, versão de firmware e cenário de uso na lista oficial da Microsoft. Se o firmware estiver fora da faixa homologada, o suporte do fornecedor pode recusar o caso. Próximo passo: registrar essa evidência antes de qualquer chamado.
- Checar SIP OPTIONS e estado do tronco. Verifique o status do tronco no próprio SBC e no Teams Admin Center. Divergência entre os dois lados indica problema de sinalização, não de mídia. Próximo passo: comparar timestamps de falha nos dois painéis.
- Medir qualidade com dados oficiais. Use o Call Quality Dashboard para cruzar jitter, perda e latência por sub-rede. Confronte com as métricas de QoS do roteador para confirmar se a degradação está na rede local ou no caminho até a Microsoft.
- Revisar voice routing e atribuição de números. Confira políticas de voz, rotas e DIDs na página oficial de gestão de números de telefone. Erro de atribuição derruba chamada mesmo com tronco saudável. Próximo passo: auditar cada DID contra o usuário ou fila esperado.
- Simular failover e link degradado. Derrube o link primário e observe o tempo de recomposição do tronco em uma filial. O trade-off é claro: redundância custa configuração contínua, mas evita queda total. Próximo passo: documentar o comportamento real por site.
- Escalar quando a camada não for sua. Se o sintoma persistir em operadora, certificado SIP ou integração com contact center, o ganho de manter o caso interno cai.
O que fazer depois de confirmar a certificação do SBC
Confirmar que o modelo está na lista oficial resolve a compatibilidade, não a operação. A partir daí, o gestor precisa estar pronto para decidir fornecedor com base em responsabilidades claras, e não apenas na presença do equipamento na lista da Microsoft. O problema mais comum nessa etapa é a falta de clareza sobre quem opera cada camada: a Microsoft responde pelo serviço Direct Routing e pela documentação de configuração; o fabricante responde pelo firmware e pelas versões suportadas do SBC; a operadora ou integrador responde pelo tronco SIP, pela conectividade de rede e pelo suporte de ponta a ponta. Quando essa divisão não está escrita, cada incidente vira uma negociação nova e o chamado circula sem dono definido.
Para equipes que não querem manter essa carga internamente, o caminho costuma ser o Direct Routing gerenciado com SBC e tronco SIP operados por um provedor. Nesse modelo, a operação da camada de borda, o monitoramento e a conectividade com a operadora ficam com o fornecedor, enquanto você mantém o controle do voice routing, dos números e da experiência do usuário final. Antes de fechar contrato, confira se o fornecedor documenta por escrito o que cobre em cada camada e valide os recursos que pretende usar na documentação oficial de configuração do Direct Routing e na lista de controladores de borda suportados. Essa clareza operacional pesa mais do que qualquer promessa de disponibilidade.
Perguntas frequentes
Quando um SBC certificado para Direct Routing é realmente necessário em vez de outra opção de conectividade PSTN?
Faz sentido quando já existe tronco SIP ativo, PABX legado ou contrato com operadora local fora do Operator Connect, pois o SBC preserva o investimento e traduz a sinalização entre Teams e infraestrutura existente. O erro é adotá-lo como padrão sem avaliar alternativas de conectividade PSTN.
O que exigir do integrador ao contratar um SBC certificado para Direct Routing antes de assinar o contrato?
Exija demonstração de que o SBC opera dentro do perímetro homologado pela Microsoft: modelo e versão exatos na lista oficial, firmware dentro da faixa certificada e cenário de implantação compatível. Esses itens são verificáveis antes da assinatura e reduzem o risco de descobrir tarde que o firmware não é suportado.
Vale o investimento em um SBC certificado para Direct Routing quando já existe PABX legado com tronco SIP ativo?
Sim, nesse cenário o SBC certificado preserva o investimento existente ao traduzir a sinalização entre o Teams e a infraestrutura legada, evitando trocar operadora ou PABX. O critério prático é confirmar que o modelo e firmware constam na lista oficial antes de fechar a arquitetura.
Quanto tempo leva para validar e implementar um SBC certificado para Direct Routing em produção?
O artigo não define prazos fixos, mas indica que a validação de modelo, versão de firmware e cenário na lista oficial deve ocorrer antes da assinatura do contrato. Confirmar essa certificação antecipadamente evita retrabalho e reduz o risco de descobrir tarde que o firmware ou cenário não é suportado.
Quais integrações precisam ser validadas além da certificação do SBC para Direct Routing funcionar com o Teams Phone?
A homologação cobre apenas a sinalização SIP com o serviço. Não cobre rede, firewall, DNS interno nem operadora do cliente. Por isso, além do SBC certificado, é preciso validar fluxo de RTP no firewall, regras de NAT e o tronco SIP da operadora local antes de considerar o deploy suportado.
Quem responde pelo suporte quando o SBC certificado para Direct Routing apresenta falhas em produção?
A Microsoft responde pelo serviço Direct Routing e documentação de configuração; o fabricante pelo firmware e versões suportadas do SBC; a operadora ou integrador pelo tronco SIP, conectividade de rede e suporte ponta a ponta. Sem essa divisão clara de responsabilidades, o gestor fica sem referência para escalar.
