Como se tornar um provedor de Microsoft Teams Direct Routing: os requisitos do SBC

Toda empresa que usa Microsoft Teams Phone acaba fazendo a mesma pergunta: quem vai conectá-lo à rede telefônica, e a que custo? Para provedores de serviços gerenciados, ISPs e operadoras, essa pergunta é uma oportunidade. Em vez de ver clientes pagando as tarifas do Microsoft Calling Plan ou entregando sua voz a uma operadora Operator Connect, você pode fornecer conectividade PSTN usando seus próprios números, suas próprias tarifas e seu próprio roteamento. Isso é o que significa se tornar um provedor de Microsoft Teams Direct Routing.

Todo o modelo depende de uma peça de infraestrutura: um Controlador de Borda de Sessão (SBC). A Microsoft não conecta o Teams a uma operadora diretamente. Ela exige um SBC suportado na borda, terminando o tronco Teams de um lado e o tronco da operadora do outro, e o Teams simplesmente se recusa a conectar a um SBC que não atenda seus requisitos técnicos de criptografia, normalização SIP e sinalização de saúde. Este guia trata desses requisitos. Se você já entende o que é Teams Direct Routing, o próximo passo é saber exatamente o que o SBC precisa fazer para oferecer Direct Routing como negócio e como escalá-lo para múltiplos tenants de clientes. O lado comercial, como precificar, empacotar e vender o serviço, é coberto separadamente no guia de serviço gerenciado para MSPs.

Por que oferecer Teams Direct Routing como serviço?

A Microsoft dá às empresas três formas de conectar o Teams Phone ao mundo externo, e duas delas deixam dinheiro e controle na mesa para o cliente. Microsoft Calling Plans agrupam minutos nas tarifas da Microsoft sem escolha de operadora. Operator Connect limita os clientes às operadoras dentro do programa da Microsoft. Direct Routing é o caminho aberto: qualquer operadora, qualquer tarifa, controle total de roteamento, entregue através de um SBC. Para uma comparação detalhada dos três modelos, veja Operator Connect versus Teams Direct Routing.

Esse caminho aberto é onde o provedor se insere. Se você já opera SIP Trunks, minutos wholesale ou um negócio de PBX hospedado, Direct Routing permite que você adicione voz Teams ao que já vende. No mercado norte-americano, Teams Direct Routing é a razão mais comum pela qual um provedor de serviços gerenciados procura um SBC. O cliente quer chamadas Teams, não quer operar seu próprio SBC, e prefere comprar voz de um provedor que já conhece do que da Microsoft.

Quem se torna um provedor de Direct Routing

• Provedores de serviços gerenciados adicionam chamadas Teams a um stack existente de clientes FreePBX, 3CX ou NetSapiens, entregando voz para dezenas ou centenas de clientes empresariais a partir de uma única plataforma. Veja como MSPs avaliam um SBC para a visão do comprador.
• ISPs e operadoras já possuem os SIP Trunks e a numeração, então Direct Routing é uma forma de subir na cadeia de valor, da conectividade wholesale para um serviço Teams de varejo.
• Operadores de contact center e CPaaS usam o mesmo SBC para entregar caminhos Bring Your Own Carrier para o Teams junto com suas outras plataformas.

Três formas de entregar Direct Routing

Antes de olhar para o SBC em si, decida qual modelo de entrega você está construindo. A escolha define quanto da plataforma você opera e o que seus clientes acessam.

Modelo	Quem opera o SBC	Melhor para	Multi-tenant
Direct Routing como serviço	Provedor hospeda	MSPs atendendo muitos tenants SMB	Obrigatório
Hospedado pelo cliente, gerenciado pelo provedor	Nuvem do cliente, você opera	Tenants maiores com requisitos de conformidade	Por implantação
Auto-hospedado pela empresa	Cliente opera	Grande empresa única com equipe de voz interna	Tenant único

A maioria dos provedores que constroem um negócio repetível opta pelo primeiro modelo, entregando Direct Routing como serviço a partir de um SBC compartilhado e multi-tenant. Ele tem o menor custo por cliente e a integração mais rápida, porque um novo tenant é uma mudança de configuração em vez de uma nova implantação. O modelo intermediário atende clientes que precisam do SBC dentro de sua própria conta de nuvem por questões de residência de dados ou conformidade, mas ainda deixam a operação diária com você. Esta é uma escolha técnica de hospedagem; a compensação comercial entre operar o SBC e revendê-lo como serviço gerenciado é avaliada no guia de serviço gerenciado para MSPs. Qualquer que seja o modelo escolhido, os requisitos de SBC abaixo se aplicam.

O que a Microsoft exige de um SBC para Direct Routing

A Microsoft publica um conjunto de requisitos técnicos que todo SBC de Direct Routing precisa satisfazer, e o Teams simplesmente se recusa a conectar a um SBC que não os atenda. Como provedor, você atende esses requisitos uma vez, corretamente, e depois reutiliza a mesma configuração para cada tenant que integrar.

Um SBC suportado e um FQDN registrado

A Microsoft mantém uma lista de SBCs validados para Direct Routing, e seu SBC deve estar nessa lista ou satisfazer de outra forma a interface de Direct Routing que o Teams espera. Cada SBC precisa de um Nome de Domínio Totalmente Qualificado (FQDN) publicamente resolvido, registrado no Teams Admin Center, que o Teams usa para roteamento SIP e para validar o certificado TLS. Endereços IP puros não são aceitos.

TLS para sinalização SIP

Toda sinalização SIP entre o Teams e seu SBC deve usar Transport Layer Security, com um certificado de uma Autoridade Certificadora confiável pela Microsoft cujo Subject Alternative Name corresponda ao FQDN do SBC. Como o Teams e o SBC se autenticam mutuamente, isso é efetivamente uma relação de confiança mútua, e a cadeia de certificados precisa permanecer válida ao longo do tempo. A Microsoft atualiza periodicamente as raízes de CA que confia para Direct Routing, então manter o certificado atualizado faz parte da operação do serviço.

SRTP para criptografia de mídia

O Teams aceita apenas mídia criptografada, então todo RTP do SBC precisa ser Secure RTP. Muitas operadoras ainda entregam RTP não criptografado, o que significa que seu SBC converte de forma transparente entre os dois formatos, gerenciando a troca de chaves em cada ponta de forma independente, sem que a operadora ou o Teams precisem mudar nada.

O heartbeat SIP OPTIONS

O Teams envia solicitações periódicas de SIP OPTIONS para confirmar que o SBC está ativo, e o SBC precisa responder cada uma com um 200 OK. Uma resposta perdida ou atrasada faz o Teams marcar aquele tronco como offline, e para um provedor multi-tenant uma única configuração incorreta pode afetar o tenant que o compartilha. Respostas OPTIONS perdidas são a causa raiz mais comum por trás de tickets “SBC aparece offline”, um padrão coberto em profundidade no guia de troubleshooting de Direct Routing.

Compatibilidade de mensagens SIP

O Teams fala um dialeto SIP específico, e cabeçalhos ou corpos comuns em SIP de operadoras tradicionais, como certos P-headers ou extensões proprietárias, podem ser rejeitados. Seu SBC normaliza em ambas as pontas, removendo ou remapeando o que o Teams não aceita na entrada e traduzindo o SIP do Teams para sua operadora na saída.

O que um SBC de classe provedora precisa além do mínimo

Atender os requisitos da Microsoft conecta um tenant. Operar um negócio de Direct Routing com muitos tenants exige mais do SBC, e é aqui que a escolha da plataforma separa um serviço viável de um fardo de suporte.

Multi-tenancy e isolamento por tenant

Um SBC de provedor precisa atender muitos clientes a partir de uma instância mantendo o roteamento, numeração e tráfego de cada tenant logicamente separados. O mecanismo prático é a configuração por grupo de troncos: cada tenant recebe seu próprio grupo de troncos com suas próprias regras SIP e seu próprio roteamento, e um FQDN base com subdomínios por tenant permite que o Teams enderece cada um. A arquitetura por trás disso é coberta em SBC multi-tenant para Teams Direct Routing. Sem multi-tenancy sólido, cada novo cliente se torna uma nova implantação e a economia nunca funciona.

Escala de grupos de troncos e sessões

Confirme o teto do SBC em sessões concorrentes, grupos de troncos e registros de endpoints contra seu plano de crescimento, não apenas a contagem de clientes de hoje. Uma plataforma que suporta na ordem de mil grupos de troncos e dezenas de milhares de sessões concorrentes por instância dá ao provedor espaço real para adicionar tenants sem re-arquitetar.

Arquitetura B2BUA

Um Back-to-Back User Agent (B2BUA) termina completamente a sessão SIP em uma ponta e re-origina uma nova na outra, dando ao SBC controle completo sobre cada mensagem em ambas as direções. Um proxy SIP simples passa mensagens com capacidade limitada de modificá-las, o que é um limite rígido quando você precisa remover cabeçalhos proprietários de uma operadora antes que cheguem ao Teams ou ajustar cabeçalhos de identidade por tenant. A arquitetura B2BUA é o que permite manipulação profunda de cabeçalhos, criptografia independente por ponta e ocultação de topologia, e a diferença é explicada em mais detalhes em o que é um SBC e o que ele faz.

Manipulação configurável de cabeçalhos SIP

Diferentes operadoras e diferentes tenants precisam de tratamentos SIP diferentes, então um motor de manipulação de cabeçalhos baseado em regras, configurável por grupo de troncos, é essencial. Quanto mais configurável o motor, mais fácil é integrar uma operadora com uma implementação SIP incomum ou um tenant com regras específicas de apresentação de caller-ID, sem tocar na configuração de ninguém.

Segurança na borda

Seu SBC está exposto à internet no lado da operadora, o que o torna um alvo. Mitigação integrada de DoS e DDoS, proteção contra varredura de registro SIP e blacklisting dinâmico de faixas de IP ou padrões de números são expectativas básicas para infraestrutura de voz voltada para a internet. Para um provedor que entrega Direct Routing a clientes pagantes, a pontuação de fraude por chamada também importa, porque fraude de tarifação em uma plataforma compartilhada se torna sua exposição de faturamento em todos os tenants de uma vez.

Alta disponibilidade

Quando uma empresa opera seu próprio SBC, uma queda afeta uma empresa. Quando um provedor opera um SBC compartilhado, uma queda afeta todos os tenants nele. Isso eleva a alta disponibilidade de um recurso desejável a um requisito básico. Procure redundância ativo/standby, tipicamente expressa como HA 1+1, para que manutenções e falhas não derrubem toda a sua base de clientes.

Implantação em nuvem e híbrida

O Teams Phone roda no Microsoft Azure, então um SBC implantável nativamente no Azure mantém a latência baixa para a infraestrutura Teams. Para provedores com data centers existentes, ou clientes que exigem o SBC dentro de sua própria conta de nuvem, disponibilidade em Azure e AWS ou em VMware, KVM e baremetal permite posicionar o SBC onde o negócio precisa.

Requisitos de SBC para provedores em resumo

Requisito	Necessário para	Prioridade do provedor
SBC suportado + FQDN registrado	Teams aceitar a conexão	Obrigatório
Sinalização TLS + certificado confiável	Tronco Teams criptografado e autenticado	Obrigatório
SRTP com conversão RTP-para-SRTP	Conectar mídia não criptografada da operadora ao Teams	Obrigatório
Multi-tenancy por tenant	Atender muitos clientes a partir de uma instância	Crítico para escala
Manipulação configurável de cabeçalhos SIP	Normalizar operadoras e tenants variados	Crítico para escala
Segurança na borda e pontuação de fraude	Proteger uma plataforma compartilhada voltada para a internet	Fortemente recomendado
Alta disponibilidade 1+1	Manter todos os tenants online durante falhas	Fortemente recomendado

Integrando um tenant: o caminho geral

Com a plataforma operando, adicionar um cliente segue uma sequência repetível. As telas exatas dependem do seu SBC, mas o fluxo é consistente em um serviço de Direct Routing bem construído.

1. Registre o domínio do tenant no Teams Admin CenterAdicione o FQDN ou subdomínio do SBC do cliente em Voice, Direct Routing, para que o Teams saiba para onde rotear as chamadas do tenant e qual certificado validar.
2. Confirme que o certificado cobre o tenantVerifique se seu certificado TLS, ou um wildcard cobrindo seus subdomínios, é válido para o FQDN do tenant e emitido por uma CA confiável pela Microsoft.
3. Crie o grupo de troncos do tenant em direção ao TeamsConfigure o transporte para TLS, mídia para SRTP, aplique suas regras de normalização SIP compatíveis com Teams e habilite ocultação de topologia, tudo com escopo neste tenant.
4. Mapeie o tenant a um tronco de operadoraAponte o tenant para o tronco de operadora que carregará seu tráfego PSTN, usando uma operadora wholesale compartilhada ou uma operadora atribuída a esse cliente.
5. Atribua números e configure o roteamentoProvisione os números do tenant e defina o roteamento de entrada e saída entre o tronco Teams e o tronco de operadora, com prioridade e fallback para resiliência.
6. Verifique OPTIONS e faça chamadas de testeConfirme que o tronco do tenant aparece saudável no Teams Admin Center, depois teste chamadas em ambas as direções e verifique a qualidade de áudio e a apresentação do caller-ID antes de entrar em produção.

O lado comercial: preços e empacotamento

A estrutura de custos do SBC define suas margens, e o licenciamento baseado em sessões se encaixa bem no modelo de provedor porque seu custo escala com a capacidade concorrente que você realmente usa, em vez de uma grande compra de hardware antecipada. Como você precifica e empacota voz Teams para seus próprios clientes, os modelos por seat, por canal e escalonados, as regras de quando aceitar ou não uma conta, e quem é dono da atestação STIR/SHAKEN quando você é o provedor de origem, é uma decisão de negócio por si só. Esse guia é coberto de ponta a ponta em como oferecer Teams Direct Routing como serviço gerenciado. Este guia foca nos requisitos de SBC que tornam o serviço tecnicamente possível.

Perguntas frequentes

Conclusão

Tornar-se um provedor de Microsoft Teams Direct Routing tem menos a ver com o Teams e mais com o SBC sobre o qual você constrói o serviço. Os requisitos da Microsoft, um SBC suportado com um FQDN registrado, sinalização TLS, mídia SRTP, o heartbeat OPTIONS e compatibilidade SIP, conectam um único tenant. Transformar isso em um negócio significa um SBC que é genuinamente multi-tenant, escala para seus alvos de grupos de troncos e sessões, oferece controle SIP configurável por tenant, defende uma plataforma compartilhada na borda e permanece disponível quando todos os seus clientes dependem dele.

Acerte essas peças e cada novo cliente se torna uma mudança de configuração em vez de um projeto, que é exatamente a economia que um provedor precisa. Seja hospedando o SBC você mesmo ou revendendo-o como serviço gerenciado, a plataforma por baixo é a diferença entre uma oferta de Direct Routing que escala e uma que consome sua equipe de suporte.