Implantações de Voz na Nuvem e o SBC: Arquitetura para Voz Multi-Cloud, Híbrida e SaaS

As plataformas de nuvem absorveram a maioria das cargas de trabalho corporativas, mas a voz continua sendo a exceção que confirma a regra. E-mail, CRM e colaboração migraram para SaaS com atrito mínimo porque toleram latência, rodam sobre HTTPS e nunca tocam a rede telefônica pública. A voz é diferente. Ela roda sobre SIP, exige latência de ida e volta inferior a 150ms, e toda chamada que alcança um número telefônico precisa cruzar uma interconexão de operadora regida por décadas de regulamentação de telecomunicações e implementações SIP específicas de cada fornecedor.

O Controlador de Borda de Sessão (SBC) é o componente que conecta essas duas realidades. Seja sua plataforma de voz rodando inteiramente na nuvem, abrangendo múltiplos provedores de nuvem, ou dividida entre infraestrutura local e uma nuvem pública, o SBC fica no limite onde os SIP Trunks (troncos de voz sobre IP) encontram os serviços de nuvem. Ele termina conexões de operadoras de um lado e conexões de plataformas de nuvem do outro, tratando tradução de criptografia, normalização SIP e aplicação de segurança que nem a operadora nem a plataforma de nuvem fornecem sozinhas.

Este artigo aborda por que a voz na nuvem ainda requer um SBC na borda da rede, como os três padrões de implantação dominantes funcionam e o que acontece no limite de interconexão de operadoras para arquiteturas CPaaS, UCaaS e híbridas.

Por Que a Voz na Nuvem Ainda Precisa de uma Borda Física

As plataformas de voz na nuvem tratam controle de chamadas, gerenciamento de usuários e funcionalidades cada vez mais sofisticadas como agentes de voz com IA e transcrição em tempo real. O que elas não tratam é a transferência para a operadora. Toda chamada originada ou terminada na rede telefônica pública precisa cruzar um limite de SIP Trunk onde a plataforma de nuvem encontra uma operadora de telecomunicações, e esse limite é onde os problemas se concentram.

As operadoras entregam tráfego SIP com implementações de cabeçalhos específicas do fornecedor, suporte variável a criptografia e requisitos de transporte que diferem de tronco para tronco. Uma operadora pode enviar SIP sobre UDP sem criptografia; outra pode exigir TLS 1.2 com autenticação mútua por certificado. A plataforma de nuvem do outro lado tem seus próprios requisitos. O Microsoft Teams Direct Routing exige TLS e SRTP em toda conexão. O Genesys Cloud espera formatos específicos de cabeçalho SIP para sua interface de tronco BYOC. O SIP Trunking Elástico da Twilio tem seus próprios requisitos de normalização.

O SBC resolve essa incompatibilidade operando como um B2BUA que termina completamente o SIP de um lado e o re-origina do outro. Cada lado recebe a criptografia, os cabeçalhos, os codecs e o transporte esperados, negociados de forma independente. Sem um SBC, cada combinação operadora-plataforma exige trabalho de integração personalizado que o fornecedor da plataforma de nuvem não vai realizar e que a operadora não tem incentivo para suportar.

Além da tradução de protocolo, o SBC fornece o perímetro de segurança que as plataformas de nuvem assumem que existe, mas não implementam. Proteção contra Negação de Serviço (DoS) na camada SIP, lista de bloqueio dinâmica, defesa contra varredura de registros SIP e prevenção de fraude telefônica executam no SBC antes que o tráfego alcance a aplicação na nuvem. Expor uma plataforma de voz na nuvem diretamente ao tráfego SIP da operadora sem um SBC é o equivalente em voz a colocar uma aplicação web na internet pública sem um firewall.

Três Padrões de Implantação para SBCs na Nuvem

Implantações de SBC na nuvem se dividem em três padrões arquitetônicos. A escolha certa depende de onde suas cargas de trabalho de voz rodam, onde suas operadoras se conectam e quanta infraestrutura local você pretende manter.

Nuvem Pura

Em uma implantação de nuvem pura, o SBC roda como uma máquina virtual junto com a aplicação de voz no mesmo provedor de nuvem. Esse é o padrão mais simples: a instância do SBC é implantada na AWS, Azure, VMware ou KVM/Proxmox, os SIP Trunks da operadora terminam na interface pública do SBC, e a plataforma de voz se conecta ao SBC pela rede interna do provedor de nuvem. A latência entre o SBC e a aplicação é mínima porque ambos ficam no mesmo data center ou zona de disponibilidade.

A nuvem pura funciona bem para organizações que migraram completamente para uma plataforma de voz na nuvem e não possuem mais equipamentos de telefonia locais. Ela elimina totalmente os appliances de SBC de hardware, substituindo despesas de capital por um modelo de assinatura que escala conforme a contagem real de sessões.

Multi-Cloud

Implantações multi-cloud posicionam instâncias de SBC em dois ou mais provedores ou regiões de nuvem. Um Provedor de Serviços Gerenciados (MSP) entregando Teams Direct Routing multi-tenant pode rodar seu SBC primário no Azure para menor latência ao Microsoft 365, com uma instância em espera na AWS para diversidade de operadoras e redundância geográfica. Um operador de central de atendimento rodando Genesys Cloud BYOC pode posicionar instâncias de SBC tanto no US-East quanto no EU-West para cumprir requisitos de residência de dados mantendo capacidade de failover.

O SBC é particularmente adequado para multi-cloud porque opera como uma função de rede autônoma. Cada instância se conecta às suas operadoras locais e terminais de plataforma de nuvem de forma independente, com regras de roteamento que podem direcionar tráfego entre instâncias com base em carga, disponibilidade ou política. O suporte do ProSBC a AWS, Azure, VMware, KVM/Proxmox e baremetal significa que os mesmos padrões de software e configuração se aplicam independentemente de qual nuvem hospeda uma determinada instância.

Híbrido: Local + Nuvem

O híbrido é o padrão mais comum na prática, porque a maioria das organizações não migra todas as cargas de trabalho de voz para a nuvem de uma vez. Uma implantação híbrida típica mantém um PBX local (Avaya, Cisco ou FreeSWITCH) para ramais internos enquanto roteia chamadas externas através de um SBC hospedado na nuvem que se conecta tanto ao PBX legado quanto a uma plataforma UCaaS na nuvem. O SBC trata a normalização SIP entre o dialeto SIP do PBX legado e os requisitos da plataforma de nuvem, criptografa o tráfego que cruza a internet pública e fornece um ponto único de gerenciamento para conexões de operadoras que servem ambos os ambientes.

Implantações híbridas também servem como caminho de migração do local para a nuvem completa. A arquitetura baseada em NAP do SBC permite que operadores migrem grupos de troncos um de cada vez, movendo conexões de operadoras da perna local para a perna na nuvem progressivamente. A qualquer momento, reverter um único grupo de troncos é uma mudança de roteamento, não uma reestruturação de arquitetura.

Interconexão de Operadoras para CPaaS e UCaaS

O papel do SBC se torna mais visível no limite de interconexão de operadoras para plataformas CPaaS e UCaaS. Essas plataformas abstraem a voz em APIs e serviços gerenciados, mas a abstração falha no limite da PSTN, onde SIP Trunks reais carregam chamadas reais para números de telefone reais.

UCaaS: Teams, Zoom, RingCentral

Plataformas UCaaS apresentam o padrão de integração com SBC mais limpo porque o fornecedor da plataforma define os requisitos SIP explicitamente. O Microsoft Teams exige TLS com certificado de uma CA confiável, SRTP para toda mídia, monitoramento de heartbeat via SIP OPTIONS e formatação específica de cabeçalhos SIP. O SBC termina o SIP Trunk da operadora de um lado (frequentemente UDP não criptografado) e apresenta TLS/SRTP compatível com Teams do outro. O ProSBC suporta Microsoft Teams Direct Routing e foi implantado com sucesso em ambientes Teams DR em redes de MSPs, Provedores de Serviços de Internet (ISP) e empresas.

Para MSPs atendendo múltiplos clientes, o SBC permite entrega de voz multi-tenant para Teams a partir de uma única instância. O tenant Microsoft 365 de cada cliente se conecta através de um NAP dedicado com seu próprio subdomínio FQDN, certificado TLS e regras de roteamento, enquanto compartilha as conexões de operadoras e a infraestrutura de SBC subjacentes.

CPaaS: Twilio, Telestax, Cloudoni

A interconexão de operadoras para CPaaS funciona de maneira diferente porque o SBC fica entre a plataforma CPaaS e as operadoras próprias da organização em um modelo BYOC. Em vez de usar a telefonia incluída do provedor CPaaS (e pagar tarifas por minuto em escala), a organização traz seus próprios SIP Trunks e usa o SBC para normalizar o tráfego entre suas operadoras e o terminal SIP da plataforma CPaaS.

Esse padrão é cada vez mais comum entre organizações que constroem agentes de voz com IA, discadores automáticos de saída e sistemas de IVR programáveis. A plataforma CPaaS fornece a lógica de aplicação, mas o SBC fornece roteamento de operadoras, segurança, assinatura STIR/SHAKEN e controle de custos. A Aircall, por exemplo, usa o ProSBC na AWS para normalizar o tráfego SIP de provedores internacionais para mais de 50.000 usuários, aproveitando o motor de manipulação de cabeçalhos SIP e a API RESTful do SBC para gerenciar diversidade de operadoras em múltiplos países.

BYOC para Centrais de Atendimento

Plataformas de central de atendimento na nuvem (Genesys Cloud, Five9, NICE CXone, Talkdesk) suportam modelos BYOC onde o cliente fornece seus próprios SIP Trunks através de um SBC. O SBC trata a mesma normalização de operadoras e tradução de criptografia do caso UCaaS, com requisitos adicionais de alta densidade de sessões, tratamento de mídia com baixa latência e integração com sistemas de prevenção de fraude que avaliam chamadas durante a configuração.

Segurança na Borda de Voz na Nuvem

Mover a voz para a nuvem não elimina a superfície de ataque; apenas a desloca. O SBC se torna o perímetro de segurança entre a internet pública (onde o tráfego SIP da operadora chega) e o ambiente de nuvem (onde as aplicações de voz rodam). Um tratamento completo das capacidades de segurança do SBC está disponível no guia dedicado de segurança do SBC, mas as preocupações específicas da nuvem merecem atenção focada.

Bridging de criptografia é a função de segurança mais fundamental. Plataformas de nuvem exigem TLS e SRTP, enquanto muitas operadoras ainda entregam tráfego sobre UDP não criptografado. O SBC termina SIP/RTP não criptografados do lado da operadora e re-origina TLS/SRTP criptografados do lado da nuvem. O ProSBC negocia TLS 1.3 exclusivamente, sem fallback para versões anteriores, garantindo que a perna criptografada atenda ao padrão mais forte disponível. Pares que não conseguem negociar TLS 1.3 se conectam por pernas UDP ou TCP, onde o SBC ainda fornece inspeção de sinalização e ancoragem de mídia.

Ocultação de topologia ganha importância adicional em ambientes de nuvem. Orquestradores de contêineres, balanceadores de carga e camadas de rede na nuvem introduzem endereços IP internos que nunca devem vazar nos cabeçalhos SIP que cruzam a internet pública. A arquitetura B2BUA do SBC substitui todos os endereços internos pelo IP público do próprio SBC, tornando a infraestrutura de nuvem arquitetonicamente invisível para partes externas.

Prevenção de ataques na camada SIP protege a aplicação na nuvem contra ameaças que firewalls de rede não conseguem tratar. Ataques de inundação SIP, varredura de registros e exploits de mensagens SIP malformadas visam a camada de aplicação. O SBC inspeciona o tráfego SIP no nível do protocolo, aplicando limitação de taxa por método, por origem e por grupo de troncos, com lista de bloqueio dinâmica que bloqueia automaticamente origens que excedem os limites configurados.

Alta Disponibilidade e Failover Entre Regiões de Nuvem

A voz tolera mal a indisponibilidade. Uma aplicação web que retorna um erro 503 por trinta segundos causa inconveniência; uma plataforma de voz que derruba chamadas por trinta segundos causa disrupção operacional e, para provedores de serviços, violações de SLA com penalidades financeiras. A Alta Disponibilidade (HA) em implantações de SBC na nuvem opera em dois níveis: nível de instância e nível de região.

HA em nível de instância usa um par 1+1 onde uma instância de SBC em espera monitora a primária e assume seu endereço IP e sessões ativas caso a primária falhe. O HA 1+1 do ProSBC roda em máquinas virtuais padrão sem exigir rede de nuvem especializada, tornando-o implantável na AWS, Azure, VMware ou KVM sem modificação. A instância em espera mantém sincronização de configuração com a primária, portanto o failover não requer intervenção manual.

Redundância em nível de região protege contra falhas de zona de disponibilidade ou região da nuvem ao posicionar instâncias de SBC em locais geograficamente separados. Registros DNS SRV do lado da operadora ou monitoramento de saúde baseado em SIP OPTIONS direcionam o tráfego para a instância disponível. Para organizações com requisitos rigorosos de uptime, implantações ativo-ativo entre regiões distribuem o tráfego continuamente, com cada instância tratando uma parcela da carga de chamadas e absorvendo o tráfego da outra durante uma falha.

Implantações de SBC na nuvem também se beneficiam da camada de Monitoramento como Serviço (MaaS), que fornece dashboards em tempo real, alertas baseados em limites e análise de tendências históricas em todas as instâncias de SBC independentemente de onde estão hospedadas. O MaaS detecta padrões de degradação (jitter crescente em um tronco de operadora específico, anomalias na contagem de registros, capacidade de sessões se aproximando dos limites) antes que se tornem indisponibilidades, dando às equipes de operações tempo para responder antes que o failover seja necessário.

Perguntas Frequentes

Conclusão

A voz pode ser a última grande carga de trabalho a migrar para a nuvem, mas a migração está em pleno andamento. O que distingue implantações de voz na nuvem bem-sucedidas das problemáticas é como o limite da operadora é tratado. O SBC fornece a tradução de protocolo, bridging de criptografia, aplicação de segurança e alta disponibilidade que as plataformas de voz na nuvem exigem, mas não implementam nativamente.

Seja implantando uma arquitetura de nuvem pura em um único provedor, abrangendo múltiplas nuvens para redundância e conformidade, ou mantendo um ambiente híbrido durante uma migração gradual, o SBC opera como o ponto de controle consistente em cada interconexão de operadora. Sua arquitetura B2BUA garante que cada lado da conexão receba exatamente o comportamento SIP, criptografia e roteamento que necessita, sem exigir que nenhum dos lados se adapte ao outro.

Para organizações avaliando sua arquitetura de voz na nuvem, o SBC não é um componente opcional a ser adicionado depois que os problemas aparecem. É a camada fundamental que faz a interconexão de operadoras, interoperabilidade multi-fornecedor e segurança de voz funcionarem corretamente desde o início.