SIP Firewall vs SBC: como escolher o perímetro de voz certo

A maioria dos debates sobre “firewall vs SBC” reduz três categorias de produto diferentes a duas. Existe o firewall de rede, que normalmente opera na Camada 3/4 e não realiza controle completo com reconhecimento de SIP. Existe o SIP firewall, que inspeciona a sinalização SIP, mas geralmente não abrange o tratamento completo de mídia. E existe o Controlador de Borda de Sessão (SBC), que termina e re-origina a sinalização de forma independente e pode ancorar, retransmitir, proteger ou transformar a mídia de acordo com políticas na borda da rede. Tratar quaisquer duas dessas categorias como intercambiáveis leva a comprar demais, proteger de menos, ou ambos.

A palavra-chave “SIP firewall” é a que causa mais confusão. É uma categoria de produto real, comercializada por fabricantes como Ingate, determinados SKUs da AudioCodes e appliances legados da Borderware. É também um rótulo que alguns firewalls aplicam quando um módulo SIP Application Layer Gateway (ALG) está habilitado. Os dois casos não são equivalentes. O comprador que pergunta “preciso de um SIP firewall ou de um SBC?” geralmente quer uma resposta direta sobre qual classe de produto se encaixa na sua implantação, não uma explicação sobre por que um firewall de rede não consegue inspecionar SIP.

Este guia separa as três categorias, compara-as nas capacidades que realmente importam para voz e percorre seis cenários comuns de implantação para que você possa mapear seu ambiente à classe de produto correta. A tabela de comparação de capacidades está no meio do artigo e é a forma mais rápida de visualizar as diferenças se você tiver apenas um minuto.

As três categorias de produto no perímetro de voz

Toda rede de voz tem um perímetro, e todo perímetro precisa de alguma combinação de três controles. Interpretar “SIP firewall vs SBC” como uma questão binária esconde o fato de que a maioria das implantações em produção usa pelo menos dois dos três, e algumas usam os três.

Um firewall de rede fica na borda da rede IP. Ele determina quem pode acessar a infraestrutura de voz no nível de pacote. IP de origem, IP de destino, protocolo de transporte e número de porta são os controles. O firewall não analisa SIP, não reconhece RTP como mídia e trata ambos como UDP ou TCP genérico. Praticamente toda implantação de voz tem um desses, seja como appliance dedicado ou como security group de um provedor de nuvem.

Um SIP firewall abrange uma gama mais ampla de produtos do que o nome sugere. A categoria inclui appliances dedicados com reconhecimento de sinalização (Ingate SIParator é o exemplo canônico, com produtos legados da Borderware e dispositivos Polycom mais antigos), módulos de software embutidos em firewalls de uso geral (o SIP ALG no Cisco ASA, Fortinet, Palo Alto, SonicWall) e construções open-source onde Kamailio ou OpenSIPS é configurado como perímetro SIP. O que eles compartilham é o reconhecimento de sinalização sem terminação completa de mídia: analisam cabeçalhos SIP, aplicam políticas a essas mensagens e encaminham a mídia com um pinhole em vez de re-originá-la.

Um Controlador de Borda de Sessão executa o conjunto completo de funções do perímetro de voz em ambos os planos. Ele termina o diálogo SIP de entrada, origina um novo na saída e faz o mesmo para o fluxo de mídia via ancoragem de mídia. Essa arquitetura, o B2BUA, é o que permite ao SBC aplicar criptografia por perna, manipular cabeçalhos, ocultar topologia, executar lógica de roteamento, realizar transcodificação, ancorar e converter SRTP, integrar-se a serviços de assinatura STIR/SHAKEN e absorver tráfego de Negação de Serviço (DoS) na camada de aplicação. A maioria dos produtos SBC publicados hoje são baseados em software e executam em infraestrutura commodity.

As três categorias se sobrepõem nas bordas, especialmente porque o marketing de alguns fabricantes rotula o mesmo dispositivo como “SIP firewall” ou “session border controller” dependendo do público. A tabela de capacidades mais adiante neste guia é a forma mais confiável de determinar a qual classe de produto um determinado dispositivo realmente pertence.

O que um firewall de rede faz pelo SIP, e o que não faz

Um firewall de rede é essencial para voz. Todo perímetro de voz deve ter um. A questão é o que ele pode e não pode fazer quando o tráfego SIP o atravessa.

No que ele pode fazer, um firewall de rede aplica allowlists de IP de origem para peers de operadoras confiáveis, restringe portas SIP e RTP a faixas conhecidas, descarta ataques volumétricos óbvios (TCP SYN floods, amplificação UDP, ICMP floods) antes que atinjam a infraestrutura de voz e fornece a política básica de acesso na Camada 3 / Camada 4 que mantém tráfego aleatório da internet longe do listener SIP. Em implantações na nuvem, esse é o papel de um security group da AWS, um NSG do Azure ou uma regra de firewall do Google Cloud, somados a qualquer scrubbing de DDoS que o provedor de nuvem oferece na borda da rede.

No que ele não pode fazer, um firewall de rede não consegue inspecionar o corpo de uma mensagem SIP. Um flood de INVITE, um flood de REGISTER, uma mensagem SIP malformada projetada para esgotar recursos de processamento ou disparar erros de parser, e um setup normal de chamada são todos idênticos para o firewall: pacotes UDP na porta 5060. O firewall não tem como limitar taxa por método SIP, não tem como detectar que registros estão chegando com credenciais sequenciais ou inválidas e não tem como identificar um flood que usa IPs de origem falsificados. Para um walkthrough completo de por que floods SIP evadem controles de Camada 3 / Camada 4, veja o guia detalhado de prevenção de ataques SIP DoS.

O SIP ALG que vem com a maioria dos firewalls de uso geral tem o objetivo de preencher essa lacuna, e geralmente piora as coisas. SIP ALGs são conhecidos por reescrever cabeçalhos SIP de formas que quebram fluxos de chamada, interferir na travessia de NAT, tratar incorretamente re-INVITEs e produzir áudio unidirecional difícil de diagnosticar. Muitos engenheiros de voz desabilitam o SIP ALG como primeiro passo ao fazer troubleshooting de uma nova implantação. O guia de segurança SBC cobre os modos de falha do SIP ALG em detalhe.

A conclusão é direta. Um firewall de rede pertence à arquitetura. Ele é necessário, mas não suficiente para tráfego SIP, e o SIP ALG raramente é a forma certa de preencher a lacuna.

O que um “SIP firewall” realmente é

O SIP firewall é o meio-termo nebuloso. O rótulo abrange produtos com capacidades muito diferentes, então dois compradores comparando “SIP firewalls” podem acabar avaliando dispositivos que fazem coisas completamente distintas.

O caso mais claro é um appliance SIP firewall dedicado. O Ingate SIParator é o produto de referência de longa data nessa categoria e é posicionado explicitamente como um híbrido de SIP firewall mais E-SBC. O dispositivo analisa SIP, aplica regras de permissão / bloqueio na camada SIP, pode limitar taxa por método SIP, trata tráfego de registro e ancora ou encaminha mídia de forma transparente dependendo da configuração. Outros fabricantes ofereceram dispositivos semelhantes ao longo dos anos, incluindo appliances legados da Borderware e certos SKUs de E-SBC da AudioCodes comercializados em modo firewall para implantações SMB. Esses são dispositivos de perímetro com reconhecimento de sinalização reais.

Um segundo caso é o SIP ALG dentro de um firewall de uso geral, que alguns fabricantes e revendedores chamam de recurso de “SIP firewall”. Como mencionado acima, o SIP ALG tem reconhecimento de sinalização em teoria e é operacionalmente frágil na prática. Chamá-lo de SIP firewall confunde a categoria, porque o perfil de capacidades é muito mais limitado do que um appliance dedicado.

Um terceiro caso é o open-source. Kamailio e OpenSIPS podem ser configurados para atuar como um perímetro SIP que filtra, limita taxa e encaminha tráfego SIP para uma plataforma de processamento de chamadas downstream. Alguns operadores executam esses em frente a uma instalação Asterisk ou FreePBX como uma camada de “SIP firewall”, frequentemente combinada com fail2ban para bloqueio de IP de origem. Isso funciona para implantações pequenas onde o operador tem a profundidade de engenharia para mantê-lo e onde a mídia passa sem modificação.

O que a maioria dos SIP firewalls compartilha é o foco na sinalização. Eles analisam mensagens SIP, aplicam políticas a essas mensagens e passam RTP através de um pinhole em vez de re-originá-lo. Geralmente são implantados como proxies SIP e não como B2BUAs, o que significa que não criam uma separação rígida entre diálogos externos e internos. As implicações práticas são grandes: ocultação de topologia limitada, nenhuma política de criptografia por perna, nenhuma limitação de taxa no plano de mídia e desafios de integração com plataformas que exigem tratamento estrito de mídia, como Microsoft Teams Direct Routing.

Um SIP firewall é uma classe de produto real e útil. Também é uma classe de produto mais restrita do que o termo implica, e um SIP firewall não é um Controlador de Borda de Sessão, mesmo quando fabricantes borram os rótulos.

O que um SBC completo adiciona além de um SIP firewall

Um SBC parte do mesmo ponto que um SIP firewall: reconhecimento de sinalização na borda da rede. Depois, adiciona o plano de mídia, um motor de roteamento, normalização, tratamento de registro e ocultação de topologia.

Ancoragem de mídia e criptografia é a diferença mais visível. O SBC recebe RTP no lado externo e retransmite no lado interno, com contextos de criptografia separados em cada lado. É isso que torna possíveis o relay de SRTP e a conversão de RTP para SRTP. Uma implantação de Microsoft Teams Direct Routing, uma integração WebRTC e um PBX legado atrás de uma operadora moderna dependem desse comportamento. Um SIP firewall que opera apenas na sinalização não tem mídia para terminar, portanto não pode realizar nenhum dos dois.

Normalização SIP abrange as regras que ajustam cabeçalhos SIP por perna de chamada ou grupo de troncos para fazer ambientes multi-vendor interoperarem. A manipulação de cabeçalhos SIP inclui correção de P-Asserted-Identity para compatibilidade com STIR/SHAKEN, correções de cabeçalho Via para mensagens malformadas, tratamento de session timer conforme RFC 4028 e remoção ou adição de extensões específicas de fabricante. Um SIP firewall frequentemente oferece normalização limitada, mas geralmente expõe menos controle por perna do que plataformas SBC.

O motor de roteamento é onde o SBC deixa de ser um dispositivo de perímetro e se torna um ponto de controle para o fluxo de chamadas. Regras de roteamento podem direcionar chamadas para diferentes operadoras por prefixo de destino, por horário do dia, por menor custo, por nível de atestação ou pelo resultado de uma consulta API externa a um serviço de scoring de fraude, uma base de dados LNP ou um CRM. O guia de roteamento de chamadas via REST API do SBC detalha esse processo. A maioria dos SIP firewalls tem uma superfície de roteamento menor e depende de uma plataforma downstream para qualquer lógica não-trivial.

Tratamento de registro é outra grande diferença. Um SBC pode atuar como encaminhador de registro para registrars upstream, pode proteger o registrar contra varredura de registro e credential stuffing, e pode manter estado de registro para terminais atrás de NAT. Muitas implementações de SIP firewall oferecem reconhecimento de registro limitado em comparação com plataformas SBC.

Ocultação de topologia funciona por causa da arquitetura B2BUA. Cabeçalhos sensíveis a roteamento e topologia são gerados pelo SBC conforme a política, não encaminhados do lado externo, de modo que endereços IP internos, hostnames e identificadores nunca alcançam a internet pública. Um SIP firewall em modo proxy encaminha os cabeçalhos originais e assim expõe mais topologia, a menos que seja fortemente configurado.

Integração STIR/SHAKEN é a adição moderna. O SBC é o lugar natural para consultar um serviço de assinatura, gerar e anexar a informação de identidade PASSporT transportada no cabeçalho Identity ao INVITE de saída, e validar o cabeçalho Identity em chamadas de entrada. O ProSBC suporta isso através de scripts Ruby de roteamento que se integram com TransNexus ClearIP, Neustar e outros provedores STI-AS, com redundância primário / secundário e controle de atestação por chamada. Um SIP firewall que opera apenas na sinalização não tem a superfície de roteamento para tomar decisões de atestação por chamada.

Cada uma dessas capacidades está a um cenário de comprador de distância de ser crítica. O framework de decisão na próxima seção mapeia esses cenários para classes de produto.

Comparação de capacidades lado a lado

A tabela abaixo mapeia as capacidades que importam no perímetro de voz para as três categorias de produto. “Parcial” é usado quando a capacidade está tecnicamente presente, mas é materialmente mais limitada do que a categoria uma coluna à direita.

Capacidade	Firewall de rede	SIP Firewall	Controlador de Borda de Sessão
Filtragem de IP / porta na Camada 3 / 4	Função principal	Frequentemente incluída	Granularidade por NAP
Inspeção de mensagens SIP (camada de aplicação)	Apenas SIP ALG, geralmente desabilitado	Parsing SIP completo	Parsing SIP completo
Arquitetura B2BUA (terminação completa de diálogo)		Geralmente modo proxy
Limitação de taxa SIP-aware (por método, por origem, por tronco)		Apenas por método	Todos os três escopos
Lista de bloqueio dinâmica e greylisting	Apenas bloqueios de IP estáticos	Apenas IP dinâmico	Incluindo greylisting percentual
Proteção contra varredura de registro		Apenas filtragem de REGISTER	Detecção baseada em padrões
Tratamento do plano de mídia (ancoragem RTP)	Apenas pinholes	Pass-through típico	Ancoragem de mídia completa
Terminação TLS para sinalização SIP		Alguns produtos	Por perna
Relay de SRTP e conversão RTP para SRTP
Manipulação de cabeçalhos SIP para normalização de vendor		Apenas descartar / passar	Reescrita por perna
Ocultação de topologia		Limitada em modo proxy	Nativa do B2BUA
Motor de roteamento configurável		Regras básicas	Baseado em API
Transcodificação (conversão de codec)			DSP por software ou hardware
Assinatura e verificação STIR/SHAKEN			Integração STI-AS
Suporte a Microsoft Teams Direct Routing		Sem SRTP

Comparação de capacidades entre as três categorias de produto no perímetro de voz.

Framework de decisão por cenário de implantação

A classe de produto correta depende do que está atrás do perímetro e do que o atravessa. Os seis cenários abaixo cobrem a maioria das implantações de voz em produção.

Pequena empresa, PBX único, sem SIP exposto à internet

O site tem um PBX hospedado ou um PBX on-premises que se comunica com uma única operadora por circuito privado ou SIP Trunk gerenciado em um único IP estático. A exposição da infraestrutura de voz à internet é zero. Um firewall de rede com allowlists restritas no IP da operadora e nas faixas de portas SIP e RTP é suficiente. Um SIP firewall agrega pouco, e um SBC é comprar além do necessário, a menos que o site precise de criptografia de mídia, Teams Direct Routing ou roteamento multi-operadora.

PME com SIP Trunk pela internet pública

O site tem um ou mais SIP Trunks alcançando a operadora pela internet pública. IPs de origem da operadora podem mudar, ou a operadora pode exigir conectividade baseada em FQDN. Um SIP firewall é uma escolha defensável se os únicos requisitos forem filtragem de sinalização e controle de IP de origem. Um SBC pequeno é a escolha mais comum em 2026 porque o mesmo dispositivo oferece SRTP, normalização de cabeçalhos e a opção de adicionar uma segunda operadora depois sem re-arquitetar o perímetro.

Provedor de Serviços Gerenciados (MSP) atendendo 10 a 200 clientes empresariais (Teams Direct Routing)

Este é o cenário dominante de SBC para MSP. Microsoft Teams Direct Routing é o gatilho, e a Microsoft exige TLS para sinalização SIP, SRTP para mídia, TLS mútuo para a interface Teams e um FQDN correspondente a um certificado de uma CA confiável pela Microsoft. Um SIP firewall não pode atender a esses requisitos porque não termina mídia e não executa política de TLS / SRTP por perna. A classe de produto correta é um SBC, implantado em modo multi-tenant para que um único dispositivo atenda muitos tenants de clientes. Veja o guia de Teams Direct Routing para o walkthrough completo de configuração.

Provedor de Serviços de Internet (ISP), ILEC ou operadora de voz wholesale

A operadora revende SIP Trunks, executa atestação STIR/SHAKEN, faz peering com múltiplas operadoras e trata uma ampla variedade de terminais de clientes. Nada disso está no escopo de um SIP firewall. O SBC é a única classe de produto que executa o motor de roteamento, a lógica de atestação por chamada e a normalização de cabeçalhos multi-vendor que esse perfil exige. O guia de autenticação de chamadas STIR/SHAKEN explica por que a atestação precisa residir na camada de roteamento.

Contact center migrando para uma plataforma de nuvem (BYOC)

O contact center está migrando de voz on-premises para uma plataforma de nuvem como Genesys, Five9 ou NICE, com modelo Bring Your Own Carrier. A plataforma de nuvem comumente se beneficia de um SBC na borda para que o contact center retenha escolha de operadora, controle de fraude, integração de gravação e métricas de qualidade independentes da plataforma. Um SIP firewall não fornece os pontos de integração de gravação, os hooks de roteamento para scoring de fraude ou o isolamento de Registro de Detalhe de Chamada (CDR) por NAP que um contact center precisa. O SBC é a classe correta.

Trânsito e peering de operadoras

A operadora é uma operadora de trânsito ou um hub de peering com muitos relacionamentos SIP upstream e downstream. Política de criptografia por peer, normalização de cabeçalhos, limites de taxa anti-fraude e ocultação de topologia em relação a cada peer são todos críticos. Este é o caso de uso original do SBC, e a classe de produto SIP firewall nunca o visou.

A armadilha do “já temos um firewall”

O erro mais comum no planejamento do perímetro de voz é concluir que um firewall de rede cobre SIP porque tem uma caixa de seleção de SIP ALG. As seções anteriores explicaram por que isso é insuficiente. Três modos de falha merecem destaque explícito porque tendem a aparecer apenas após um incidente.

Ataques de flood SIP passam pelos firewalls sem modificação. Um flood de INVITE, um flood de REGISTER, um flood de OPTIONS e um ataque de mensagem malformada são todos tráfego UDP válido para o firewall. O guia detalhado de prevenção de ataques SIP DoS cobre cada tipo de ataque e como a limitação de taxa na camada de aplicação o detém. Um SIP firewall cobre parte dessa superfície (limitação de taxa na camada de sinalização), e um SBC cobre toda ela, incluindo floods no plano de mídia.

Criptografia de mídia é impossível sem terminação de mídia. SRTP requer que o dispositivo manipule o fluxo RTP, derive chaves por perna e re-criptografe no lado de saída. Nem um firewall de rede nem um SIP firewall que opera apenas na sinalização fazem isso. Implantações que precisam de SRTP para conformidade (Teams Direct Routing, WebRTC, ePHI em trânsito relacionado a HIPAA) requerem um SBC. Veja o guia de configuração de TLS e SRTP do SBC para os padrões de implantação.

Vazamento de topologia é difícil de corrigir retroativamente. Um SIP firewall em modo proxy encaminha os cabeçalhos SIP que recebe, incluindo Via, Contact e cabeçalhos de identidade que revelam endereços IP internos e hostnames. Uma vez que partes externas viram esses cabeçalhos, atacantes podem mirar a infraestrutura interna diretamente e contornar o perímetro por completo. A arquitetura B2BUA em um SBC gera novos cabeçalhos no lado interno, então a topologia interna permanece interna. O guia de segurança SBC cobre ocultação de topologia junto com as outras quatro camadas de segurança.

A arquitetura correta para uma implantação de voz que usa qualquer plataforma de voz moderna é em camadas. O firewall de rede cuida da política de tráfego na Camada 3 / Camada 4. O SBC cuida de SIP, mídia, criptografia, roteamento e topologia. O SIP firewall tem um encaixe mais restrito e é mais útil onde a implantação genuinamente não precisa de tratamento de mídia ou roteamento.

Onde o ProSBC se encaixa

O ProSBC é um Controlador de Borda de Sessão por software e cobre a coluna SBC completa da tabela de comparação. Os recursos que aparecem com mais frequência nos cenários de compra acima estão todos incluídos: arquitetura B2BUA, TLS e SRTP por perna, normalização SIP completa, limitação de taxa por NAP e lista de bloqueio dinâmica com greylisting percentual, proteção contra varredura de registro SIP, ocultação de topologia, roteamento configurável via Ruby API e assinatura STIR/SHAKEN através de integrações abertas com TransNexus ClearIP e Neustar.

O ProSBC escala para 60.000 sessões por servidor, suporta até 1.024 NAPs para implantações multi-tenant e roda em AWS, Azure, VMware, KVM, Proxmox ou bare metal. O preço começa a partir de $1.40 por sessão por ano em assinatura, com um trial gratuito de 30 dias para avaliação comercial e uma licença permanente ProSBC Lab que fornece três sessões simultâneas para testes e trabalho de integração.

O ponto de entrada mais comum para compradores comparando SIP firewalls com SBCs é a licença ProSBC Lab. Ela roda o conjunto completo de recursos, leva cerca de 20 minutos para implantar e permite que o comprador teste o comportamento do perímetro contra suas integrações reais de operadora e plataforma antes de se comprometer com um plano pago.

Perguntas frequentes

Um SIP firewall é a mesma coisa que um SBC?

Não. Um SIP firewall tem reconhecimento de sinalização e tipicamente opera como proxy SIP sem terminar mídia. Um Controlador de Borda de Sessão termina e re-origina a sinalização de forma independente, e pode ancorar, retransmitir, proteger ou transformar mídia de acordo com políticas como B2BUA, o que habilita relay de SRTP, transcodificação, política de criptografia por perna, ocultação de topologia e motor de roteamento configurável. Alguns fabricantes usam os rótulos de forma intercambiável, mas os perfis de capacidade diferem.

Posso simplesmente habilitar o SIP ALG no meu firewall existente?

A maioria dos engenheiros de voz desabilita SIP ALGs como primeiro passo de troubleshooting. SIP ALGs reescrevem cabeçalhos SIP de formas que frequentemente quebram setup de chamada, travessia de NAT, re-INVITEs e negociação SRTP, e oferecem uma pequena fração da capacidade de um SIP firewall dedicado ou de um SBC.

Preciso de um SBC para Microsoft Teams Direct Routing?

Sim. A Microsoft exige TLS para sinalização SIP, SRTP para mídia, TLS mútuo para a interface Teams, um FQDN com certificado de uma CA confiável pela Microsoft e tratamento de SIP OPTIONS para monitoramento de saúde. A maioria dos produtos SIP firewall não é projetada para satisfazer o conjunto completo de requisitos do Microsoft Teams Direct Routing porque não termina mídia. A Microsoft também publica uma lista de SBCs certificados; o ProSBC suporta Teams Direct Routing, mas não está na lista certificada da Microsoft no momento desta publicação.

Onde o firewall de rede se encaixa se eu já tenho um SBC?

Ambos estão presentes na arquitetura. O firewall de rede aplica política de acesso nas Camadas 3 e 4 e absorve ataques volumétricos de rede. O SBC fica atrás dele e cuida de todo controle SIP e RTP. Em implantações na nuvem, os security groups e a proteção contra DDoS do provedor de nuvem cobrem o papel do firewall de rede.

Quando um SIP firewall é a escolha certa em vez de um SBC?

Um SIP firewall atende um perfil restrito: uma implantação que precisa de filtragem SIP na camada de aplicação, não tem requisitos de plano de mídia (sem SRTP, sem transcodificação, sem Teams Direct Routing), usa um ambiente SIP único e homogêneo e prefere um dispositivo menor e mais barato. Quando a implantação adiciona qualquer plataforma de voz moderna ou requisito de criptografia, o SBC se torna a classe correta.

O ProSBC também é um SIP firewall?

O ProSBC inclui todas as capacidades que um SIP firewall oferece (parsing de sinalização, limitação de taxa na camada de aplicação, lista de bloqueio dinâmica, proteção contra varredura de registro, ocultação de topologia) e adiciona o conjunto completo de capacidades SBC por cima delas. Compradores comparando produtos SIP firewall com o ProSBC estão comparando um dispositivo mais restrito com um superconjunto.