Opciones de SBC de código abierto: qué existe realmente y cuándo tiene sentido

La frase “SBC de código abierto” sugiere un proyecto único que se puede descargar, instalar y colocar en el borde de la red de voz del mismo modo que se desplegaría un Session Border Controller comercial. Ese producto no existe. Lo que sí existe es un conjunto de motores de señalización SIP de código abierto, motores de medios y herramientas complementarias que, correctamente ensamblados y reforzados, pueden realizar la misma función. El costo de licencia de ese stack es cero. El costo de ingeniería y operación no lo es.

Esta página mapea las opciones realistas de código abierto, describe qué hace realmente cada una, detalla lo que usted debe construir por cuenta propia para alcanzar paridad de funcionalidades con un SBC comercial, y le ayuda a decidir si construir, comprar o tomar un camino híbrido es la decisión correcta para su equipo.

Por qué no existe un SBC de código abierto único

Un SBC comercial es un producto empaquetado. Señalización SIP, manejo de medios, seguridad, enrutamiento, detección de fraude, integración de STIR/SHAKEN, monitoreo y alta disponibilidad están diseñados y probados en conjunto, se entregan como un solo artefacto y cuentan con el soporte de un único proveedor.

El ecosistema de telecomunicaciones de código abierto evolucionó de manera diferente. La capa de señalización y la capa de medios crecieron como proyectos separados, escritos en lenguajes distintos, con cadencias de lanzamiento, comunidades y filosofías de diseño diferentes. OpenSIPS y Kamailio son descendientes directos del SIP Express Router original, optimizados para el procesamiento de SIP a altas tasas. RTPengine y rtpproxy fueron construidos como manejadores de medios complementarios porque los servidores SIP no tocan RTP en absoluto. FreeSWITCH y Asterisk fueron diseñados como plataformas de telefonía orientadas al manejo de medios, no como SBC de borde, aunque ambos pueden configurarse para cumplir el rol de SBC.

Un “SBC de código abierto” es, por lo tanto, un stack que el operador ensambla. El costo de licencia de cada componente es cero. El trabajo de integración, el reforzamiento operativo, las actualizaciones a través de múltiples proyectos, la cadencia de seguridad, la integración de firma STIR/SHAKEN y el soporte en producción son trabajo de ingeniería que el operador asume.

Las opciones realistas de SBC de código abierto

Los seis proyectos a continuación son los que los equipos realmente utilizan cuando desean ejecutar un SBC con software de código abierto. Se dividen en dos grupos: motores de señalización SIP que necesitan un motor de medios separado, y plataformas con capacidad de medios que pueden operar como SBC en modo B2BUA por sí solas.

OpenSIPS

OpenSIPS es un proxy SIP y motor de enrutamiento optimizado para señalización a escala de operador. Maneja registro, enrutamiento, balanceo de carga, traversal de NAT y políticas de seguridad básicas a altas tasas de transacciones. El modelo de configuración utiliza su propio lenguaje de scripting, que es potente pero poco familiar para equipos sin experiencia previa en OpenSIPS.

OpenSIPS no maneja RTP. Para anclar medios, transcodificar códecs o terminar SRTP, se combina con RTPengine o rtpproxy en el mismo host o en hosts adyacentes. El reemplazo por fin de vida de despliegues OpenSIPS es un motivador recurrente de evaluaciones de SBC comerciales, porque la complejidad operativa se acumula a medida que el despliegue crece.

Kamailio

Kamailio comparte el linaje y la arquitectura de OpenSIPS. Es un servidor SIP, no un B2BUA, con un ecosistema de módulos diferente y un estilo de configuración ligeramente distinto. Kamailio se utiliza ampliamente como front-end SIP en despliegues de operadores grandes y plataformas CPaaS, a menudo en pares activo/standby con IPs flotantes para redundancia.

Al igual que OpenSIPS, Kamailio depende de un motor de medios complementario para RTP. Los equipos que operan Kamailio a escala generalmente escriben sus propias bibliotecas de configuración, despliegan fail2ban o limitadores de tasa personalizados para protección contra DoS, e integran sistemas externos para firma STIR/SHAKEN y scoring de fraude. La capa de señalización es robusta; todo lo demás es responsabilidad del operador.

drachtio

drachtio ofrece un servidor SIP programable controlado desde aplicaciones Node.js. En lugar de editar un archivo de configuración en un lenguaje de scripting dedicado, el operador escribe una aplicación JavaScript o TypeScript que recibe eventos SIP y decide qué hacer con ellos. drachtio se combina con RTPengine o FreeSWITCH para medios.

drachtio es adecuado para equipos que ya ejecutan un stack Node.js y quieren que la capa SIP se sienta como una aplicación propia. No proporciona herramientas de seguridad de grado operador, monitoreo ni protección contra DoS por defecto. Esas capas siguen siendo responsabilidad del operador.

RTPengine

RTPengine es el componente de manejo de medios más común para Kamailio y OpenSIPS. Se ejecuta como un daemon separado al que el servidor SIP envía señales, indicándole que retransmita o transcodifique medios para cada llamada. RTPengine maneja SRTP, ICE, transcodificación básica y captura de paquetes. Es un componente de medios, no un SBC completo.

FreeSWITCH como SBC

FreeSWITCH es una plataforma de telefonía orientada a medios que opera como B2BUA. Maneja SIP, RTP, SRTP, WebRTC y transcodificación de códecs de forma nativa, lo que lo convierte en la opción de proyecto único más cercana al rol de SBC en comparación con OpenSIPS o Kamailio. Proveedores de servicio en América Latina y otras regiones han desplegado FreeSWITCH en el borde para tráfico a escala de operador.

La contrapartida es que FreeSWITCH fue diseñado como servidor de medios y plataforma de conferencias. Utilizarlo como SBC expuesto a Internet implica reforzar la configuración contra ataques de inundación SIP, construir protección de limitación de tasa y escaneo de registros por cuenta propia, integrar un servicio externo de firma STIR/SHAKEN, y desarrollar la capa de monitoreo que su equipo de operaciones necesita. Si ya eligió FreeSWITCH para su stack de plataforma, reutilizarlo como SBC es razonable. Si no lo hizo, comenzar con FreeSWITCH por su costo de licencia es un compromiso mayor de lo que la página de descarga sugiere.

Asterisk como SBC

Asterisk es la plataforma de telefonía de código abierto más ampliamente desplegada en el mundo. Funciona como B2BUA y maneja tanto señalización como medios. Existen configuraciones de SBC basadas en Asterisk, frecuentemente construidas alrededor del channel driver chan_pjsip, y el ecosistema FreePBX ha empaquetado parte de esta funcionalidad.

Para despliegues de bajo volumen y un solo tenant donde Asterisk ya forma parte del stack, tratar a Asterisk como SBC mantiene la arquitectura simple. A escala de operador, en entornos multi-tenant, o donde la protección contra DoS y el aislamiento de enrutamiento por tenant son importantes, Asterisk requiere un trabajo externo significativo para alcanzar el perfil operativo que un SBC comercial incluye de fábrica.

Lo que usted construye vs lo que obtiene

Capacidad	Stack de código abierto	SBC comercial (ej., ProSBC)
Señalización SIP	Incluida	Incluida
Arquitectura B2BUA	FreeSWITCH/Asterisk sí; Kamailio/OpenSIPS no	B2BUA completo
Anclaje de medios, SRTP, transcodificación	Componente separado o nativo en FS/Asterisk	Nativo
Motor de manipulación de encabezados SIP	Mediante scripting en lenguaje de configuración	Motor de reglas por NAP
Protección DoS/DDoS	El operador la construye	Nativa
Protección contra escaneo de registros SIP	El operador la construye	Nativa
Listas negras dinámicas, ACL, greylisting	Módulos + trabajo personalizado	Nativo
Integración de firma STIR/SHAKEN	El operador integra STI-AS externo	Módulos preintegrados de TransNexus / Neustar
Alta disponibilidad 1+1	VRRP/keepalived + replicación de estado personalizada	Productizado en ProSBC+
API de enrutamiento programable	Nativo (scripting de configuración)	Motor de enrutamiento Ruby
Monitoreo, MOS, CDR, captura de paquetes	Requiere integración de herramientas externas	Nativo con opción MaaS
Soporte del proveedor y SLA	Comunidad o soporte comercial-OSS pagado	Contratos de soporte 9×5 o 24×7
Costo de licencia	Cero	Desde tan solo $1.40/sesión/año

Las áreas donde la columna de código abierto está vacía o parcial no son deficiencias de los proyectos. Son decisiones de alcance: OpenSIPS, Kamailio, drachtio, RTPengine, FreeSWITCH y Asterisk no fueron construidos para ser SBC comerciales listos para usar. Alcanzar una postura de SBC en producción significa construir, integrar y operar las capas adicionales.

Cuándo un SBC de código abierto es la respuesta correcta

El código abierto genuinamente es la decisión correcta en un número significativo de situaciones.

Usted cuenta con un equipo interno sólido de ingeniería SIP con experiencia de varios años operando OpenSIPS, Kamailio, FreeSWITCH o Asterisk en producción. El equipo tiene un repositorio de configuración documentado, una ruta de actualización probada y al menos dos ingenieros que pueden ser contactados a las 2 a.m. sin pánico.

Su perfil de tráfico está bien definido y es estable, con picos predecibles y un conjunto conocido de peers SIP. Las ventajas de personalización del código abierto se justifican cuando el despliegue es lo suficientemente estable como para que el trabajo personalizado perdure.

Necesita hacer algo que un SBC comercial no le permitirá hacer, como un puente de protocolo no estándar, un experimento de señalización personalizado, o una integración que ningún proveedor ha construido ni construirá.

Su postura de cumplimiento le permite auto-soportarse porque no está sujeto a un SLA de operador, un requisito regulatorio de tiempo de actividad o un proceso de adquisición empresarial que exija un proveedor en el contrato.

Cuándo la ecuación de costo cero deja de funcionar

Costo total de ingeniería

Un ingeniero de redes o de voz con experiencia a nivel SBC tiene un costo de entre $60,000 y $100,000 por año (costo total) en el mercado norteamericano. Incluso dedicando el 20 por ciento del tiempo de un ingeniero al trabajo de SBC, eso representa entre $12,000 y $20,000 por año solo en costo de personal. Un despliegue de ProSBC de 500 sesiones comienza desde $1,250 por año.

Cadencia de seguridad

Un SBC expuesto a Internet recibe escaneos SIP, ataques de inundación de registros, sondeos de paquetes malformados e intentos de DDoS de forma continua. Un SBC comercial incluye estas mitigaciones de fábrica y las actualiza según la cadencia del proveedor.

Cumplimiento de STIR/SHAKEN

Configurar el motor de señalización de código abierto para consultar un STI-AS externo para atestación de nivel A, manejar fallas de firma, gestionar el fallback de P-Identity-Bypass y sobrevivir una caída del servicio de firma sin perder llamadas es trabajo de ingeniería original.

Disciplina de actualización

Un stack de código abierto con múltiples proyectos tiende a divergir. OpenSIPS lanza actualizaciones según su propio calendario, RTPengine según otro, y el kernel de Linux y las bibliotecas TLS según un tercero. Coordinar actualizaciones, realizar pruebas de regresión de la integración y revertir limpiamente cuando algo falla es un trabajo de ingeniería real.

La realidad de la guardia

La voz es en tiempo real. Una rotación de dos personas es la estructura mínima sostenible de guardia para infraestructura SBC, y tres es lo realista si se quiere evitar el agotamiento.

Caminos híbridos: programabilidad sin el stack

Muchos equipos que evalúan código abierto no están enamorados de la carga operativa. Lo que buscan es programabilidad.

El motor de enrutamiento de ProSBC se configura en Ruby, con una cadena de filtros documentada (before_filter, after_filter, after_remap_filter) y módulos preintegrados para firma STIR/SHAKEN con TransNexus ClearIP y Neustar, scoring de fraude con SecureLogix y YouMail, e integraciones de enrutamiento externas vía REST API basadas en HTTP. El equipo escribe scripts. El proveedor mantiene el núcleo del SBC, el stack de seguridad y la disciplina de actualización.

Para equipos cuyo motivo para considerar código abierto era el control, este camino híbrido es frecuentemente el punto medio práctico.

Preguntas frecuentes

Conclusión

“SBC de código abierto” es un stack que el operador ensambla, no un producto que descarga. OpenSIPS, Kamailio y drachtio manejan señalización SIP; RTPengine maneja medios para esos motores de señalización; FreeSWITCH y Asterisk pueden operar como B2BUA que hacen ambas cosas. Ninguno fue diseñado para ser un SBC comercial listo para usar.

Para un equipo con un sólido banco de ingeniería SIP, tráfico estable y una carga de cumplimiento baja, el código abierto es una elección defendible y a veces la correcta. Para un equipo que quería código abierto por la programabilidad, un SBC comercial con una API de enrutamiento real frecuentemente ofrece el mismo control sin la carga operativa. Para todos los demás, la ecuación del tiempo de ingeniería generalmente apunta hacia un SBC comercial con un precio inicial que es bajo en relación con los salarios de las personas que de otro modo construirían y mantendrían el stack.