SBC multi-tenant para Microsoft Teams Direct Routing: guia para MSPs e provedores de serviços

Geralmente começa com um cliente pedindo chamadas pelo Microsoft Teams. Depois, mais três pedem no mês seguinte, e de repente você percebe que o portfólio passou a ser majoritariamente Teams. Se você é um Provedor de Serviços Gerenciados (MSP) ou provedor de serviços que ainda sobe um SBC separado para cada cliente, a conta não fecha rápido. Entre configurações duplicadas, ciclos de atualização por cliente e uma pilha crescente de grupos de troncos que ninguém tem tempo de auditar, isso se torna um trabalho em tempo integral.

Existe um modelo melhor. Um único Controlador de Borda de Sessão (SBC) multi-tenant, ou Session Border Controller, pode atender todos os tenants Microsoft 365 dos seus clientes a partir de uma implantação centralizada, com isolamento total entre tenants e gerenciamento unificado para você. Este guia cobre o business case, a arquitetura Microsoft que torna isso possível, os recursos de SBC necessários e a economia em escala de MSP.

Por que MSPs precisam de uma abordagem multi-tenant para Teams Direct Routing

O Teams Direct Routing é o principal motivador de compra para MSPs norte-americanos avaliando um SBC. O padrão é consistente: a equipe de TI de um cliente decide consolidar a colaboração no Microsoft Teams e depois pergunta ao MSP sobre conectar o Teams ao sistema telefônico existente ou aos troncos PSTN. O MSP precisa de um SBC para fazer essa ponte.

O modelo de implantação por cliente funciona quando você tem dois ou três clientes no Teams. Com 20 clientes, ele gera uma sobrecarga operacional real. Cada implantação requer seus próprios certificados TLS, suas próprias configurações de tronco, suas próprias políticas de segurança e seu próprio cronograma de atualização. Quando o administrador do SBC sai da empresa, essa carga operacional recai sobre quem herda a função, frequentemente gerando uma conversa imediata sobre serviços gerenciados.

O modelo multi-tenant consolida tudo isso em uma única instância de SBC. Você gerencia uma implantação com infraestrutura compartilhada, mas o tráfego de cada cliente é totalmente isolado por meio de grupos de troncos separados. Políticas de segurança, regras de roteamento e CDRs permanecem por tenant. Você atualiza um sistema, monitora um painel e mantém um conjunto de certificados.

Para MSPs, isso também é um modelo de receita. O Teams Direct Routing entregue como serviço gerenciado, com a infraestrutura de SBC centralizada sob seu controle, se torna uma receita recorrente mensal em vez de um projeto pontual. (Para uma visão mais ampla do que os MSPs precisam de um SBC além do Teams DR, consulte nosso guia de SBC para MSPs.)

Como funciona a arquitetura multi-tenant de Direct Routing da Microsoft

A Microsoft projetou uma arquitetura específica para operadoras e provedores de serviços entregarem Teams Direct Routing em múltiplos tenants Microsoft 365 a partir de um SBC compartilhado. Entender essa arquitetura é pré-requisito para selecionar e configurar seu SBC. (Para uma introdução mais ampla ao Teams Direct Routing, incluindo implantações single-tenant, consulte nosso guia de SBC para Microsoft Teams Direct Routing.)

Estrutura de domínio e subdomínio

A arquitetura usa um domínio base de propriedade da operadora ou MSP, com um subdomínio criado para cada tenant de cliente. Por exemplo, se seu MSP possui o domínio sbc.seumsp.com, cada tenant de cliente recebe um subdomínio: client1.sbc.seumsp.com, client2.sbc.seumsp.com, e assim por diante.

O domínio base é registrado no tenant da operadora (sua própria organização Microsoft 365). Cada subdomínio é então ativado no tenant do cliente correspondente. Isso permite que a Microsoft associe chamadas de entrada e saída ao tenant correto enquanto roteia tudo através do seu SBC compartilhado.

Certificado TLS wildcard

A Microsoft exige criptografia TLS para toda a sinalização SIP nos troncos voltados para o Teams. Para uma implantação multi-tenant, seu SBC precisa de um certificado TLS wildcard correspondente ao padrão do seu domínio base, por exemplo *.sbc.seumsp.com. Esse único certificado autentica conexões em todos os subdomínios de tenants, eliminando a necessidade de certificados por cliente.

Essa é uma simplificação operacional significativa. Em vez de gerenciar dezenas de certificados individuais com datas de renovação escalonadas, você gerencia um único certificado wildcard.

Identificação de tenant via cabeçalhos SIP

Quando uma chamada chega à interface Direct Routing do Microsoft 365, o sistema usa o FQDN no cabeçalho SIP Contact para identificar a qual tenant a chamada pertence. Ele não busca tenants pelo número de telefone, porque números não-DID podem se sobrepor entre tenants. O FQDN do cabeçalho Contact deve resolver para o subdomínio correto de cada cliente.

Isso significa que seu SBC deve ser capaz de manipular cabeçalhos SIP por grupo de troncos, inserindo o FQDN do subdomínio correto para o tráfego de cada tenant. Um SBC com arquitetura de Agente de Usuário Back-to-Back (B2BUA) faz isso nativamente, porque termina e re-origina a sessão SIP em cada perna com controle total sobre o conteúdo dos cabeçalhos.

Configuração de tronco

Cada tenant de cliente requer um tronco configurado no centro de administração do Microsoft Teams, apontando para o FQDN do subdomínio (por exemplo, client1.sbc.seumsp.com). No seu SBC, cada tenant mapeia para um grupo de troncos dedicado com suas próprias regras de roteamento, políticas de segurança e configurações de codec. O SBC roteia chamadas entre o tronco voltado para o Teams (criptografado, TLS/SRTP) e o tronco PSTN ou voltado para a operadora (que pode usar transporte diferente dependendo dos requisitos da sua operadora).

O que seu SBC precisa para suportar Teams DR multi-tenant

Nem todo SBC lida com Teams Direct Routing multi-tenant da mesma forma. Aqui estão as capacidades técnicas que mais importam para esse modelo de implantação.

Capacidade de grupos de troncos e isolamento de tenants

Cada tenant na sua implantação multi-tenant requer pelo menos um grupo de troncos dedicado (frequentemente chamado de Ponto de Acesso de Rede, ou NAP). Se você planeja escalar para 50, 100 ou 200 tenants de clientes, o limite de grupos de troncos do seu SBC é um teto rígido para o crescimento.

O ProSBC suporta até 1.024 Pontos de Acesso de Rede por servidor. Na escala de MSP, onde a maioria dos provedores gerencia de 10 a 200 clientes, essa capacidade oferece margem significativa. Cada NAP mantém suas próprias políticas de segurança, regras de roteamento e saída de CDR, então o isolamento de tenants é aplicado no nível de configuração, não apenas no nível de rede.

TLS e SRTP para cada conexão de tenant

O Microsoft Teams exige TLS para sinalização SIP e SRTP para mídia em cada conexão Direct Routing. Não há exceção. Seu SBC deve suportar TLS e SRTP no lado voltado para o Teams e configurar o transporte de forma independente no lado voltado para a operadora.

Em uma implantação multi-tenant típica, os troncos voltados para o Teams usam TLS/SRTP, enquanto os troncos voltados para a operadora podem usar UDP, TCP ou TLS dependendo dos requisitos da operadora PSTN. Seu SBC pode converter RTP para SRTP por tronco, fazendo a ponte de criptografia entre as duas pernas.

O ProSBC suporta SIP sobre TLS e SRTP com transporte configurável por NAP. Isso significa que o tronco Teams de cada tenant usa TLS/SRTP, enquanto o tronco correspondente da operadora pode usar qualquer transporte que a operadora exija. O SBC faz a conversão RTP-para-SRTP entre as duas pernas sem configuração adicional por tenant.

Manipulação de cabeçalhos SIP para roteamento de tenants

A arquitetura multi-tenant da Microsoft depende do conteúdo preciso dos cabeçalhos SIP, especificamente o FQDN do cabeçalho Contact, para rotear chamadas ao tenant correto. Seu SBC precisa de um mecanismo de manipulação de cabeçalhos SIP capaz de reescrever cabeçalhos por grupo de troncos.

A arquitetura B2BUA do ProSBC oferece controle total sobre a sinalização SIP em ambas as pernas da chamada. Como o SBC termina a sessão SIP de entrada e origina uma nova sessão na perna de saída, cada cabeçalho pode ser inspecionado, modificado ou substituído. Não se trata de um proxy SIP leve que encaminha cabeçalhos sem alterações. O modelo B2BUA permite normalizar o tráfego SIP de qualquer formato de operadora para o formato exato que a Microsoft espera, por tenant, sem interferência entre tenants.

Essa capacidade também resolve ambientes com múltiplas operadoras. Se clientes diferentes usam operadoras PSTN diferentes com convenções de cabeçalho SIP diferentes, o SBC normaliza tudo para um formato consistente no lado do Teams.

Alta disponibilidade para infraestrutura compartilhada

Quando um único SBC atende todos os seus clientes, uma interrupção afeta toda a sua base de clientes simultaneamente. Alta Disponibilidade não é opcional para implantações multi-tenant.

O ProSBC oferece 1+1 HA com redundância ativo/standby, proporcionando máximo uptime e mínimo downtime. Isso está disponível mesmo para implantações menores: uma configuração HA de 500 sessões (ProSBC+) custa $2.000 por ano. Para MSPs construindo um serviço de Teams DR que gera receita, o investimento em HA é pequeno em relação à receita que ele protege.

Segurança na borda da rede

Um SBC multi-tenant é uma fronteira de segurança compartilhada. Ele deve proteger todos os tenants contra:

• Ataques DoS/DDoS: O ProSBC inclui mitigação integrada de ataques de negação de serviço e DDoS, impedindo que ataques de flood SIP interrompam o serviço para todos os tenants.
• Varredura de registro SIP: Detecção e bloqueio de ataques de flood de registro que tentam sondar seu SBC em busca de credenciais válidas.
• Lista de bloqueio dinâmica: Bloqueio de faixas de IP específicas ou números de origem/destino, incluindo greylisting baseado em percentual para tráfego suspeito de fraude.
• Ocultação de topologia: Oculta endereços IP de rede interna de partes externas. Em um modelo multi-tenant, isso também impede que a operadora de um tenant descubra a topologia de rede de outro tenant.

Essas proteções se aplicam globalmente e por NAP, então você pode aplicar políticas de segurança base em todos os tenants e personalizar regras para clientes específicos. (Para um olhar mais detalhado sobre capacidades de segurança de SBC, consulte nosso guia de segurança VoIP e prevenção de fraudes.)

Conformidade STIR/SHAKEN entre tenants

Se você está entregando serviços de chamadas PSTN para múltiplos clientes nos Estados Unidos, a conformidade com STIR/SHAKEN não é opcional. A FCC exige que provedores de serviço de origem assinem chamadas de saída com atestação de identidade do chamador. Para um MSP operando um SBC multi-tenant, isso significa que seu SBC centralizado deve gerenciar a assinatura STIR/SHAKEN para todo o tráfego de chamadas de saída de cada tenant.

O ProSBC se integra com serviços externos de assinatura STIR/SHAKEN (como TransNexus ClearIP ou Neustar) através do seu mecanismo de roteamento configurável. O SBC envia solicitações de assinatura ao serviço escolhido, recebe o cabeçalho Identity assinado e o insere no SIP INVITE de saída. Essa integração suporta níveis de atestação A (total), B (parcial) e C (gateway), com o nível determinado pelo seu relacionamento com a parte chamadora para cada tenant.

A vantagem principal para MSPs é a flexibilidade. O modelo de integração aberta do ProSBC funciona com qualquer serviço de assinatura de terceiros. Alguns SBCs concorrentes usam implementações STIR/SHAKEN proprietárias que prendem você a um parceiro de assinatura escolhido pelo fabricante. Com o ProSBC, você seleciona o serviço de assinatura que se adequa ao seu negócio e pode usar serviços diferentes para tenants diferentes, se necessário.

Para redundância, o ProSBC suporta URLs primária e secundária de serviço de assinatura. Se o serviço primário estiver indisponível após tentativas, o SBC adiciona um cabeçalho P-Identity-Bypass e completa a chamada em vez de descartá-la. Esse mecanismo de fallback impede que interrupções do serviço de assinatura bloqueiem todas as chamadas de saída dos seus tenants.

A economia da entrega multi-tenant de Teams DR

O caso financeiro para uma implantação multi-tenant de SBC se resume à consolidação: uma implantação custa menos que muitas, e o preço por sessão escala linearmente com sua base de clientes.

Preço por sessão em escala de MSP

O ProSBC usa um modelo de assinatura anual por sessão a partir de $1,40 por sessão por ano. O add-on de Teams Direct Routing custa a partir de $1,40 por sessão por ano. Este é um modelo OPEX, não um investimento de capital em appliances de hardware.

Aqui está um exemplo concreto para um MSP com 50 clientes e 500 sessões concorrentes totais:

São $5.375 por ano para um SBC multi-tenant de grau de operadora, protegido por HA, atendendo 50 tenants de clientes com Teams Direct Routing. Para contexto, uma única implantação Oracle Acme Packet com contagem de sessões comparável custaria aproximadamente $50.000 por ano, na taxa de cerca de $100 por sessão da Oracle.

A opção de serviço gerenciado

Se sua equipe não tem banda para gerenciar a infraestrutura de SBC, a TelcoBridges oferece um serviço totalmente gerenciado. Isso inclui ProSBC+ com 1+1 HA, suporte 24/7, setup, integração, testes e monitoramento contínuo. Você escolhe a hospedagem: a TelcoBridges pode hospedar o SBC para você ou implantá-lo na sua própria infraestrutura (AWS, Azure, VMware ou KVM). Você mantém acesso total em ambos os casos.

Oportunidade de receita

O modelo multi-tenant transforma o Teams Direct Routing em um item de receita de serviço gerenciado. Seus clientes pagam mensalmente pelas chamadas Teams, você entrega a partir do seu SBC centralizado, e a margem entre o que você cobra e o que a infraestrutura de SBC custa é receita recorrente.

Com a economia por sessão do ProSBC, mesmo preços modestos por usuário para seus clientes geram margens saudáveis. Um cliente pagando de $3 a $5 por usuário por mês por chamadas Teams gerenciadas custa uma fração disso em licenciamento de SBC.

Gerenciando múltiplas operadoras entre tenants

Na prática, sua implantação multi-tenant não se conectará a uma única operadora PSTN. Clientes diferentes trazem seus próprios relacionamentos com operadoras, ou você como MSP mantém acordos de tronco com múltiplas operadoras para cobertura geográfica, otimização de custos ou redundância. O SBC deve lidar com isso sem proliferação de configurações.

Cada NAP no ProSBC pode se conectar a uma operadora diferente com seu próprio perfil SIP, preferências de transporte e requisitos de codec. O mecanismo de roteamento configurável do SBC suporta roteamento baseado em regras com prioridade, permitindo definir tabelas de roteamento por tenant que selecionam operadoras com base em padrões de números chamados, horário do dia, custo ou métricas de qualidade. Se uma rota de operadora primária falhar, o SBC automaticamente faz failover para rotas secundárias.

Para MSPs gerenciando clientes em diferentes regiões ou países, essa flexibilidade de roteamento por tenant é essencial. Um cliente no Texas pode rotear através de uma operadora regional com tarifas locais competitivas, enquanto um cliente em Nova York usa uma operadora nacional com melhores preços de longa distância. O SBC aplica as regras de roteamento de cada cliente de forma independente, sem interferência de roteamento entre tenants.

O ProSBC também gera CDRs por NAP, fornecendo dados de CDR de grau de faturamento separados por tenant. Isso é crítico para MSPs que faturam clientes com base no uso: você pode extrair volumes de chamadas, durações e destinos por cliente diretamente do SBC sem correlação manual.

Opções de implantação para Teams DR multi-tenant

O ProSBC roda na infraestrutura que você já possui. Implantações multi-tenant de Teams DR são suportadas em:

• AWS: A plataforma de implantação mais popular e testada em batalha para o ProSBC. Cloud-native, sem hardware para adquirir.
• Microsoft Azure: Escolha lógica se sua prática de MSP já está alinhada com Azure. Mantém a infraestrutura de voz na mesma nuvem que o Teams.
• VMware ou KVM/Proxmox: Para MSPs rodando sua própria infraestrutura de virtualização on-premises ou em colocação.
• Servidores baremetal: Para ambientes que exigem hardware dedicado.

Todas as opções de implantação suportam a mesma arquitetura multi-tenant, a mesma configuração de NAP e as mesmas capacidades de HA. O software do SBC é idêntico independente de onde ele roda.

Para MSPs com clientes em indústrias regulamentadas ou regiões com requisitos de residência de dados, todas as implantações podem ser hospedadas na própria infraestrutura do cliente para conformidade com GDPR e proteção de dados.

Monitoramento de uma implantação multi-tenant

O monitoramento centralizado se torna mais importante conforme você adiciona tenants. Um único SBC multi-tenant carregando todo o tráfego dos seus clientes requer visibilidade proativa sobre qualidade de chamada, saúde dos troncos e eventos de segurança em todos os tenants simultaneamente.

O ProSBC oferece acesso via API RESTful para gerenciamento remoto de status e configuração, suporte SNMP para integração com plataformas de monitoramento de rede existentes e pontuação MOS (Mean Opinion Score) para avaliação de qualidade de chamada em tempo real. Captura Wireshark ao vivo e capacidades de rastreamento de chamadas permitem solucionar problemas de chamadas por tenant sem interromper o tráfego de outros tenants.

Para MSPs que desejam monitoramento sem a sobrecarga operacional, a TelcoBridges oferece Monitoring as a Service (MaaS) como produto independente. O MaaS fornece monitoramento contínuo da sua implantação ProSBC, mas é apenas um produto de monitoramento, não uma implantação gerenciada. Se você deseja gerenciamento operacional completo (implantação, atualizações, troubleshooting e suporte), o pacote de Serviço Gerenciado inclui MaaS como parte da oferta.

Primeiros passos: do laboratório à produção

O ProSBC oferece um caminho do zero à produção que não exige ligação comercial, ordem de compra ou envio de hardware.

1. Implante o ProSBC LabO ProSBC Lab é uma licença gratuita e permanente de 3 sessões disponível para download imediato. A configuração leva aproximadamente 20 minutos, e o Lab inclui capacidade de Teams Direct Routing. Este é seu sandbox para validar a configuração multi-tenant antes de comprometer qualquer orçamento.
2. Configure seu domínio base e certificado wildcardRegistre seu domínio base (por exemplo, sbc.seumsp.com) e obtenha um certificado TLS wildcard de uma autoridade certificadora confiável. Configure o certificado na sua instância ProSBC Lab.
3. Configure NAPs para tenants de testeCrie Pontos de Acesso de Rede separados para dois ou três tenants de teste. Configure cada NAP com seu FQDN de subdomínio, tronco TLS/SRTP voltado para o Teams e tronco voltado para a operadora.
4. Valide o fluxo de chamadasConfirme que os health checks SIP OPTIONS passam para cada tenant, faça chamadas de teste em ambas as direções e verifique se os CDRs são gerados por tenant.
5. Escale para produçãoQuando o Lab validar sua arquitetura, passe para o trial gratuito de 30 dias com 500 sessões concorrentes. Isso oferece capacidade em escala comercial para integrar seus primeiros clientes de produção.
6. Avalie o serviço gerenciadoSe a sobrecarga operacional de gerenciar o SBC não é onde você quer investir o tempo da sua equipe, converse com a TelcoBridges sobre a opção de serviço gerenciado. O serviço gerenciado cobre implantação, monitoramento, atualizações e suporte 24/7, permitindo que sua equipe foque em relacionamentos com clientes em vez de manutenção de SBC.

Perguntas frequentes

Próximos passos

Um SBC multi-tenant para Teams Direct Routing é a infraestrutura que transforma a demanda dos clientes por chamadas Teams em um serviço gerenciado escalável e lucrativo. A combinação de preço por sessão, alta capacidade de NAP para isolamento de tenants e a opção de transferir operações para um serviço gerenciado torna esse modelo viável para MSPs de qualquer tamanho.

Comece com o ProSBC Lab para validar sua configuração multi-tenant de Teams DR em menos de uma hora. Quando estiver pronto para escalar, o trial gratuito de 30 dias oferece 500 sessões para integrar seus primeiros clientes de produção.