SIP Firewall vs SBC: cómo elegir el perímetro de voz adecuado

La mayoría de los debates “firewall vs SBC” agrupan tres categorías de productos diferentes en dos. Existe un firewall de red, que típicamente opera en la capa 3/4 y no realiza control completo con reconocimiento SIP. Existe un SIP firewall, que inspecciona la señalización SIP pero típicamente no llega al manejo completo de medios. Y existe un controlador de borde de sesión, que termina y reorigina la señalización de forma independiente y puede anclar, retransmitir, proteger o transformar los medios según las políticas en el perímetro de red. Tratar cualquiera de estos dos como intercambiables lleva a comprar de más, proteger de menos, o ambas cosas.

La palabra clave “SIP firewall” es la que causa más confusión. Es una categoría de producto real vendida por proveedores como Ingate, ciertos SKU de AudioCodes y dispositivos Borderware más antiguos, y también es una etiqueta que algunos firewalls aplican cuando un módulo SIP Application Layer Gateway (ALG) está habilitado. Los dos casos no son equivalentes. El comprador que pregunta “¿necesito un SIP firewall o un SBC?” generalmente quiere una respuesta directa sobre qué clase de producto se ajusta a su implementación, no una explicación de por qué un firewall de red no puede inspeccionar SIP.

Esta guía separa las tres categorías, las compara en las capacidades que realmente importan para la voz y recorre seis escenarios de implementación comunes para que pueda mapear su entorno a la clase de producto correcta. La comparación de capacidades está en el centro del artículo y es la forma más rápida de revisar las diferencias si solo tiene un minuto.

Las tres categorías de productos en el perímetro de voz

Cada red de voz tiene un perímetro, y cada perímetro necesita alguna combinación de tres controles. Leer “SIP firewall vs SBC” como una pregunta binaria oculta el hecho de que la mayoría de las implementaciones en producción usan al menos dos de los tres, y algunas usan los tres.

Un firewall de red se ubica en el borde de la red IP. Controla quién puede alcanzar la infraestructura de voz a nivel de paquete. IP de origen, IP de destino, protocolo de transporte y número de puerto son los controles. El firewall no analiza SIP, no ve RTP como medios y trata ambos como UDP o TCP genérico. Casi todas las implementaciones de voz tienen uno de estos, ya sea como un dispositivo dedicado o como un grupo de seguridad del proveedor de nube.

Un SIP firewall abarca una gama más amplia de productos de lo que el nombre sugiere. La categoría incluye dispositivos dedicados con reconocimiento de señalización (Ingate SIParator es el ejemplo canónico, con entradas heredadas de Borderware y dispositivos Polycom más antiguos), módulos de software integrados dentro de un firewall de propósito general (el SIP ALG en Cisco ASA, Fortinet, Palo Alto, SonicWall) y compilaciones de código abierto donde Kamailio u OpenSIPS se configura como un perímetro SIP. Lo que comparten es el reconocimiento de señalización sin terminación completa de medios: analizan los encabezados SIP, aplican reglas a la señalización y típicamente reenvían los medios sin establecer un control de medios independiente.

Un controlador de borde de sesión realiza el conjunto completo de funciones del perímetro de voz en ambos planos. Termina el diálogo SIP entrante, origina uno nuevo saliente y hace lo mismo con el flujo de medios mediante el anclaje de medios. Esta arquitectura, el B2BUA, es lo que permite al SBC aplicar cifrado por tramo, manipular encabezados, ocultar topología, ejecutar lógica de enrutamiento, realizar transcodificación, anclar y convertir SRTP, integrarse con servicios de firma STIR/SHAKEN y absorber tráfico de denegación de servicio en la capa de aplicación. La mayoría de los productos SBC publicados hoy son basados en software y se ejecutan en infraestructura estándar.

Las tres categorías se superponen en los bordes, especialmente porque el marketing de los fabricantes a veces etiqueta el mismo dispositivo como “SIP firewall” o “controlador de borde de sesión” según la audiencia. La tabla de capacidades más adelante en esta guía es la forma más confiable de determinar a qué clase de producto pertenece realmente un dispositivo dado.

Qué hace un firewall de red para SIP y qué no

Un firewall de red es esencial para la voz. Cada perímetro de voz debería tener uno. La pregunta es qué puede y qué no puede hacer una vez que el tráfico SIP lo atraviesa.

En cuanto a lo que sí puede hacer, un firewall de red aplica listas de permitidos por IP de origen para pares de operadores confiables, restringe los puertos SIP y RTP a rangos conocidos, descarta ataques volumétricos obvios (inundaciones TCP SYN, amplificación UDP, inundaciones ICMP) antes de que alcancen la infraestructura de voz, y proporciona la política básica de acceso de capa 3/capa 4 que mantiene el tráfico aleatorio de Internet fuera del listener SIP. En implementaciones en la nube, este es el rol de un grupo de seguridad de AWS, un NSG de Azure o una regla de firewall de Google Cloud, más cualquier depuración DDoS que el proveedor de nube ofrezca en el perímetro de red.

En cuanto a lo que no puede hacer, un firewall de red no puede inspeccionar el cuerpo de un mensaje SIP. Una inundación SIP INVITE, una inundación SIP REGISTER, un mensaje SIP malformado diseñado para agotar los recursos de procesamiento o activar errores del parser, y una configuración de llamada normal se ven idénticos para un firewall: paquetes UDP al puerto 5060. El firewall no tiene forma de limitar la tasa por método SIP, no tiene forma de detectar que los registros están llegando con credenciales secuenciales o inválidas, y no tiene forma de identificar una inundación que usa IP de origen falsificadas. Para un análisis completo de por qué las inundaciones SIP evaden los controles de capa 3/capa 4, consulte la guía detallada de prevención de ataques DoS SIP.

El SIP ALG que viene con la mayoría de los firewalls de propósito general está diseñado para cubrir esta brecha, y generalmente empeora las cosas. Los SIP ALG son bien conocidos por reescribir encabezados SIP de formas que rompen los flujos de llamadas, interferir con el recorrido de NAT, manejar incorrectamente los re-INVITE y producir audio de un solo sentido que es difícil de diagnosticar. Muchos ingenieros de voz desactivan el SIP ALG como primer paso al solucionar problemas en una nueva implementación. La guía de seguridad del SBC cubre los modos de falla del SIP ALG en detalle.

La conclusión es directa. Un firewall de red pertenece a la arquitectura. Es necesario pero no suficiente para el tráfico SIP, y el SIP ALG rara vez es la forma correcta de llenar la brecha.

Qué es realmente un “SIP firewall”

El SIP firewall es la zona gris. La etiqueta cubre productos con capacidades muy diferentes, por lo que dos compradores que comparan “SIP firewalls” pueden terminar evaluando dispositivos que hacen cosas casi completamente distintas.

El caso más claro es un dispositivo SIP firewall dedicado. Ingate SIParator es el producto de referencia de larga trayectoria en esta categoría y se posiciona explícitamente como un híbrido SIP firewall + E-SBC. El dispositivo analiza SIP, aplica reglas de permiso/denegación en la capa SIP, puede limitar la tasa por método SIP, maneja el tráfico de registro y ancla o reenvía transparentemente los medios según la configuración. Otros fabricantes han ofrecido dispositivos similares a lo largo de los años, incluyendo dispositivos Borderware heredados y ciertos SKU de Polycom y AudioCodes E-SBC comercializados en modo firewall para implementaciones SMB. Estos son dispositivos de perímetro reales con reconocimiento de señalización.

Un segundo caso es el SIP ALG dentro de un firewall de propósito general, que algunos fabricantes y revendedores denominan función de “SIP firewall”. Como se señaló anteriormente, el SIP ALG tiene reconocimiento de señalización en teoría y es operacionalmente frágil en la práctica. Llamarlo SIP firewall difumina la categoría, porque el perfil de capacidades es mucho más estrecho que el de un dispositivo dedicado.

Un tercer caso es el código abierto. Kamailio y OpenSIPS pueden configurarse para actuar como un perímetro SIP que filtra, limita la tasa y reenvía el tráfico SIP a una plataforma de procesamiento de llamadas aguas abajo. Algunos operadores los ejecutan frente a una instalación de Asterisk o FreePBX como un nivel de “SIP firewall,” frecuentemente combinados con fail2ban para la lista de bloqueados por IP de origen. Esto funciona para implementaciones pequeñas donde el operador tiene la profundidad de ingeniería para mantenerlo y donde los medios se transmiten sin modificaciones.

Lo que la mayoría de los SIP firewalls comparten es el enfoque en la señalización. Analizan los mensajes SIP, aplican políticas a esos mensajes y pasan RTP a través de un pinhole en lugar de reoriginarlo. Típicamente se implementan como proxies SIP en lugar de como B2BUA, lo que significa que no crean una separación firme entre los diálogos externos e internos. Las implicaciones prácticas son grandes: ocultación de topología limitada, sin política de cifrado por tramo, sin limitación de tasa en el plano de medios, y desafíos de integración con plataformas que requieren manejo estricto de medios como Enrutamiento directo de Microsoft Teams.

Un SIP firewall es una clase de producto real y útil. También es una clase de producto más estrecha de lo que el término implica, y un SIP firewall no es un controlador de borde de sesión incluso cuando los fabricantes difuminan las etiquetas.

Qué agrega un SBC completo por encima de un SIP firewall

Un SBC parte del mismo lugar que un SIP firewall, que es el reconocimiento de señalización en el perímetro de red. Luego agrega el plano de medios, un motor de enrutamiento, normalización, manejo de registros y ocultación de topología.

Anclaje y cifrado de medios es la diferencia más visible. El SBC recibe RTP en el tramo externo y lo retransmite en el tramo interno, con contextos de cifrado separados en cada lado. Esto es lo que hace posible la retransmisión SRTP y la conversión RTP a SRTP. Una implementación de Enrutamiento directo de Microsoft Teams, una integración WebRTC y una PBX heredada detrás de un operador moderno dependen de este comportamiento. Un SIP firewall solo de señalización no tiene medios que terminar, por lo que no puede realizar ninguna de las dos.

La normalización SIP cubre las reglas que ajustan los encabezados SIP por tramo de llamada o grupo de troncales para hacer que los entornos multifabricante interoperen. La manipulación de encabezados SIP incluye cosas como la corrección de P-Asserted-Identity para compatibilidad con STIR/SHAKEN, correcciones del encabezado Via para mensajes malformados, manejo de temporizadores de sesión bajo RFC 4028 y la eliminación o adición de extensiones específicas del fabricante. Un SIP firewall frecuentemente proporciona normalización limitada, pero generalmente expone menos control por tramo que las plataformas SBC.

El motor de enrutamiento es donde un SBC pasa de ser un dispositivo de perímetro a un punto de control para el flujo de llamadas. Las reglas de enrutamiento pueden despachar llamadas a diferentes operadores por prefijo de destino, por hora del día, por menor costo, por nivel de atestación, o por el resultado de una consulta de API externa contra un servicio de calificación de fraude, una base de datos LNP o un CRM. La guía de integración de API REST del SBC para enrutamiento de llamadas lo explica en detalle. La mayoría de los SIP firewalls tienen una superficie de enrutamiento más pequeña y dependen de una plataforma aguas abajo para cualquier lógica no trivial.

El manejo de registros es la otra gran diferencia. Un SBC puede actuar como un reenviador de registros para registrars aguas arriba, puede proteger al registrar de escaneo de registros y relleno de credenciales, y puede mantener el estado de registro para terminales detrás de NAT. Muchas implementaciones de SIP firewall proporcionan un reconocimiento de registro limitado en comparación con las plataformas SBC.

La ocultación de topología funciona gracias a la arquitectura B2BUA. Los encabezados de enrutamiento y sensibles a la topología son generados por el SBC según las políticas, no reenviados desde el lado externo, por lo que las direcciones IP internas, nombres de host e identificadores nunca alcanzan la Internet pública. Un SIP firewall en modo proxy reenvía los encabezados originales y por lo tanto filtra más topología a menos que esté fuertemente configurado.

La integración STIR/SHAKEN es la adición moderna. Un SBC es el lugar natural para consultar un servicio de firma, generar y adjuntar la información de identidad PASSporT transportada en el encabezado Identity en el INVITE saliente, y validar el encabezado Identity en las llamadas entrantes. ProSBC admite esto a través de scripts de enrutamiento Ruby que se integran con TransNexus ClearIP, Neustar y otros proveedores STI-AS, con redundancia primaria/secundaria y control de atestación por llamada. Un SIP firewall solo de señalización carece de la superficie de enrutamiento para tomar decisiones de atestación por llamada.

Cada una de estas capacidades está a un escenario de comprador de ser crítica. El marco de decisión en la siguiente sección mapea esos escenarios a clases de productos.

Comparación de capacidades lado a lado

La tabla a continuación mapea las capacidades que importan en el perímetro de voz a las tres categorías de productos. “Parcial” se usa donde la capacidad está técnicamente presente pero es materialmente más estrecha que la categoría de la columna a la derecha.

Capacidad	Firewall de red	SIP Firewall	Controlador de borde de sesión
Filtrado IP/puerto en capa 3/4	Propósito principal	Frecuentemente incluido	Granularidad por NAP
Inspección de mensajes SIP (capa de aplicación)	Solo SIP ALG, frecuentemente desactivado	Análisis SIP completo	Análisis SIP completo
Arquitectura B2BUA (terminación completa del diálogo)		Generalmente modo proxy
Limitación de tasa con reconocimiento SIP (por método, por origen, por troncal)		Solo por método	Los tres alcances
Listas de bloqueados dinámicas y listas grises	Solo bloqueos IP estáticos	Solo IP dinámica	Incluyendo listas grises por porcentaje
Protección contra escaneo de registros		Solo filtrado REGISTER	Detección basada en patrones
Manejo del plano de medios (anclaje RTP)	Solo pinholes	Paso directo típico	Anclaje de medios completo
Terminación TLS para señalización SIP		Algunos productos	Por tramo
Retransmisión SRTP y conversión RTP a SRTP
Manipulación de encabezados SIP para normalización de fabricantes		Solo descartar/pasar	Reescritura por tramo
Ocultación de topología		Limitada en modo proxy	Nativa del B2BUA
Motor de enrutamiento configurable		Reglas básicas	Basado en API
Transcodificación (conversión de codec)			DSP por software o hardware
Firma y verificación STIR/SHAKEN			Integración STI-AS
Compatibilidad con Enrutamiento directo de Microsoft Teams		Sin SRTP

Comparación de capacidades entre las tres categorías de productos en el perímetro de voz.

Un marco de decisión por escenario de implementación

La clase de producto correcta depende de lo que está detrás del perímetro y de lo que lo atraviesa. Los seis escenarios a continuación cubren la mayoría de las implementaciones de voz en producción.

Pequeña empresa individual, una sola PBX, sin SIP expuesto a Internet

El sitio tiene una PBX hospedada o una PBX local que se comunica con un operador a través de un circuito privado o una troncal SIP gestionada en una sola IP estática. La exposición de la infraestructura de voz a Internet es cero. Un firewall de red con listas de permitidos estrictas sobre la IP del operador y los rangos de puertos SIP y RTP es suficiente. Un SIP firewall agrega poco, y un SBC es comprar de más a menos que el sitio necesite cifrado de medios, Enrutamiento directo de Teams o enrutamiento multioperador.

PyME con una troncal SIP sobre la Internet pública

El sitio tiene una o más troncales SIP que alcanzan al operador a través de la Internet pública. Las IP de origen del operador pueden rotar, o el operador puede insistir en conectividad basada en FQDN. Un SIP firewall es una elección defendible si los únicos requisitos son filtrado de señalización y aplicación de IP de origen. Un SBC pequeño es la elección más común en 2026 porque el mismo dispositivo le da al sitio SRTP, normalización de encabezados y la opción de agregar un segundo operador más adelante sin rediseñar el perímetro.

MSP que sirve de 10 a 200 clientes empresariales (Enrutamiento directo de Teams)

Este es el escenario dominante de SBC para MSP. Enrutamiento directo de Microsoft Teams es el disparador, y Microsoft requiere TLS para la señalización SIP, SRTP para los medios, TLS mutuo para la interfaz de Teams y un FQDN que coincida con un certificado de una CA confiable de Microsoft. Un SIP firewall no puede cumplir estos requisitos porque no termina los medios y no ejecuta políticas TLS/SRTP por tramo. La clase de producto correcta es un SBC, implementado como multi-inquilino para que un dispositivo sirva a muchos inquilinos de clientes. Consulte la guía de Enrutamiento directo de Teams para el recorrido completo de configuración.

ISP, ILEC o proveedor de voz mayorista

El operador revende troncales SIP, ejecuta atestación STIR/SHAKEN, se interconecta con múltiples operadores y maneja una mezcla amplia de terminales de clientes. Nada de esto está en el alcance de un SIP firewall. El SBC es la única clase de producto que ejecuta el motor de enrutamiento, la lógica de atestación por llamada y la normalización de encabezados multifabricante que este perfil requiere. La guía de autenticación de llamadas STIR/SHAKEN cubre por qué la atestación debe vivir en la capa de enrutamiento.

Centro de contacto migrando a una plataforma en la nube (BYOC)

El centro de contacto está migrando de voz local a una plataforma en la nube como Genesys, Five9 o NICE, con un modelo Bring Your Own Carrier. La plataforma en la nube comúnmente se beneficia de un SBC en el borde para que el centro de contacto retenga la elección de operador, el control de fraude, la integración de grabación y las métricas de calidad independientes de la plataforma. Un SIP firewall no proporciona los puntos de integración de grabación, los hooks de enrutamiento para calificación de fraude ni el aislamiento de CDR por NAP que un centro de contacto necesita. El SBC es la clase correcta.

Tránsito y peering de operadores

El operador es un carrier de tránsito o un hub de peering con muchas relaciones SIP aguas arriba y aguas abajo. La política de cifrado por par, la normalización de encabezados, los límites de tasa antifraude y la ocultación de topología de cada par son todos críticos. Este es el caso de uso original del SBC, y la clase de producto SIP firewall nunca lo tuvo como objetivo.

La trampa del “ya tenemos un firewall”

El error más común en la planificación del perímetro de voz es concluir que un firewall de red cubre SIP porque tiene una casilla de SIP ALG. Las secciones anteriores cubrieron por qué esto se queda corto. Tres modos de falla merecen ser señalados explícitamente porque tienden a aparecer solo después de un incidente.

Los ataques de inundación SIP pasan a través de los firewalls sin modificaciones. Una inundación INVITE, una inundación REGISTER, una inundación OPTIONS y un ataque de mensajes malformados se ven como tráfico UDP válido para el firewall. La guía detallada de prevención de ataques DoS SIP cubre cada tipo de ataque y cómo la limitación de tasa en la capa de aplicación lo detiene. Un SIP firewall cubre parte de esta superficie (limitación de tasa en la capa de señalización), y un SBC cubre toda, incluyendo las inundaciones del plano de medios.

El cifrado de medios es imposible sin terminación de medios. SRTP requiere que el dispositivo maneje el flujo RTP, derive claves por tramo y recifre en el lado saliente. Ni un firewall de red ni un SIP firewall solo de señalización hacen esto. Las implementaciones que necesitan SRTP por cumplimiento normativo (Enrutamiento directo de Teams, WebRTC, ePHI relacionada con HIPAA en tránsito) requieren un SBC. Consulte la guía de configuración de TLS y SRTP del SBC para los patrones de implementación.

La filtración de topología es difícil de corregir retroactivamente. Un SIP firewall en modo proxy reenvía los encabezados SIP que recibe, incluyendo los encabezados Via, Contact e identity que revelan direcciones IP internas y nombres de host. Una vez que las partes externas han visto esos encabezados, los atacantes pueden apuntar a la infraestructura interna directamente y evadir el perímetro por completo. La arquitectura B2BUA en un SBC escribe nuevos encabezados en el lado interno, por lo que la topología interna permanece interna. La guía de seguridad del SBC cubre la ocultación de topología junto a las otras cuatro capas de seguridad.

La arquitectura correcta para una implementación de voz que usa cualquiera de las plataformas de voz modernas es por capas. El firewall de red maneja la política de tráfico de capa 3/capa 4. El SBC maneja SIP, medios, cifrado, enrutamiento y topología. El SIP firewall tiene un ajuste más estrecho y es más útil donde la implementación genuinamente no necesita manejo de medios ni enrutamiento.

Dónde encaja ProSBC

ProSBC es un controlador de borde de sesión por software y cubre toda la columna SBC de la tabla de comparación. Las funciones que aparecen con más frecuencia en los escenarios de comprador anteriores están todas incluidas: arquitectura B2BUA, TLS y SRTP por tramo, normalización SIP completa, limitación de tasa por NAP y listas de bloqueados dinámicas con listas grises basadas en porcentaje, protección contra escaneo de registros SIP, ocultación de topología, enrutamiento configurable a través de una API Ruby e integración de firma STIR/SHAKEN con TransNexus ClearIP y Neustar.

ProSBC escala hasta 60 000 sesiones por servidor, admite hasta 1024 NAP para implementaciones multi-inquilino y se ejecuta en AWS, Azure, VMware, KVM, Proxmox o bare metal. Los precios comienzan desde tan solo $1.40 por sesión por año en suscripción, con una prueba gratuita de 30 días para evaluación comercial y una licencia permanente de ProSBC Lab que proporciona tres sesiones simultáneas para pruebas y trabajo de integración.

El punto de entrada más común para los compradores que comparan SIP firewalls contra SBC es la licencia de ProSBC Lab. Ejecuta el conjunto completo de funciones, toma aproximadamente 20 minutos para implementar y permite al comprador probar el comportamiento del perímetro contra sus integraciones reales de operador y plataforma antes de comprometerse con un nivel de pago.

Preguntas frecuentes

¿Es un SIP firewall lo mismo que un SBC?

No. Un SIP firewall tiene reconocimiento de señalización y típicamente opera como un proxy SIP sin terminar los medios. Un controlador de borde de sesión termina y reorigina la señalización de forma independiente, y puede anclar, retransmitir, proteger o transformar los medios según las políticas como un B2BUA, lo que permite la retransmisión SRTP, la transcodificación, la política de cifrado por tramo, la ocultación de topología y un motor de enrutamiento configurable. Algunos fabricantes usan las etiquetas de forma intercambiable, pero los perfiles de capacidades difieren.

¿Puedo simplemente habilitar el SIP ALG en mi firewall existente?

La mayoría de los ingenieros de voz desactivan los SIP ALG como primer paso de resolución de problemas. Los SIP ALG reescriben encabezados SIP de formas que frecuentemente rompen la configuración de llamadas, el recorrido de NAT, los re-INVITE y la negociación SRTP, y ofrecen una pequeña fracción de la capacidad de un SIP firewall dedicado o un SBC.

¿Necesito un SBC para Enrutamiento directo de Microsoft Teams?

Sí. Microsoft requiere TLS para la señalización SIP, SRTP para los medios, TLS mutuo para la interfaz de Teams, un FQDN con un certificado de una CA confiable de Microsoft y manejo de SIP OPTIONS para el monitoreo de salud. La mayoría de los productos SIP firewall no están diseñados para satisfacer los requisitos completos de Enrutamiento directo de Microsoft Teams porque no terminan los medios. Microsoft también publica una lista de SBC certificados; ProSBC admite Enrutamiento directo de Teams pero no está en la lista certificada de Microsoft al momento de escribir este artículo.

¿Dónde encaja el firewall de red si tengo un SBC?

Ambos están presentes en la arquitectura. El firewall de red aplica la política de acceso de capa 3 y capa 4 y absorbe los ataques volumétricos de red. El SBC se ubica detrás de él y maneja todo el control SIP y RTP. En implementaciones en la nube, los grupos de seguridad y la protección DDoS del proveedor de nube cubren el rol del firewall de red.

¿Cuándo es un SIP firewall la elección correcta en lugar de un SBC?

Un SIP firewall se ajusta a un perfil estrecho: una implementación que necesita filtrado SIP en la capa de aplicación, no tiene requisitos de plano de medios (sin SRTP, sin transcodificación, sin Enrutamiento directo de Teams), usa un entorno SIP único y homogéneo, y prefiere un dispositivo más pequeño y económico. Una vez que la implementación agrega cualquier plataforma de voz moderna o requisito de cifrado, el SBC se convierte en la clase correcta.

¿ProSBC también es un SIP firewall?

ProSBC incluye toda capacidad que un SIP firewall ofrece (análisis de señalización, limitación de tasa en la capa de aplicación, listas de bloqueados dinámicas, protección contra escaneo de registros, ocultación de topología) y agrega el conjunto completo de capacidades SBC encima de ellas. Los compradores que comparan productos SIP firewall contra ProSBC están comparando un dispositivo más estrecho contra un superconjunto.