Kamailio vs OpenSIPS vs FreeSWITCH: cómo elegir una plataforma SIP (y por qué generalmente se necesita más de una)
Esta comparación se busca como una competencia a tres bandas, pero en realidad no lo es. Kamailio y OpenSIPS son motores de enrutamiento SIP: proxies enfocados en señalización construidos para un rendimiento muy alto de llamadas por segundo. FreeSWITCH es un agente de usuario back-to-back (B2BUA) con un stack de medios completo que cubre transcodificación, IVR, conferencias y grabación. Las plataformas se discuten frecuentemente juntas porque cubren decisiones de ingeniería superpuestas en el ecosistema de voz de código abierto, pero tratarlas como tres productos equivalentes distorsiona la pregunta real.
La pregunta real no es “cuál de estos tres debería implementar.” Es “¿cómo deben combinarse estos componentes, y dónde encaja cada uno en mi arquitectura?” En una implementación de producción típica que sirve miles de llamadas simultáneas, Kamailio u OpenSIPS se ubica al frente manejando registros, balanceo de carga y enrutamiento SIP de alto volumen, mientras que FreeSWITCH maneja las llamadas que necesitan inteligencia de medios. Ninguno de los tres es un controlador de borde de sesión (SBC), y asumir que cualquiera de ellos puede cumplir ese rol en el borde de la red es uno de los errores arquitectónicos más comunes en la voz de código abierto.
Este artículo cubre para qué fue construida cada plataforma, cómo Kamailio y OpenSIPS realmente difieren, por qué el patrón híbrido con FreeSWITCH domina las implementaciones de producción, y qué cubre y qué no cubre el stack de SBC casero.
La división arquitectónica: proxies vs servidores de medios
Kamailio y OpenSIPS son proxies SIP y motores de enrutamiento. En su modo predeterminado, procesan la señalización SIP, toman decisiones de enrutamiento, modifican encabezados, aplican políticas y reenvían la solicitud, pero no tocan la ruta de medios. El audio (RTP) fluye entre los terminales directamente, o a través de un proceso separado de relay de medios como RTPengine o RTPproxy que el proxy controla.
FreeSWITCH es un B2BUA. Termina una llamada SIP en un lado, origina una nueva llamada en el otro lado, y permanece tanto en la ruta de señalización como en la ruta de medios durante toda la duración de la llamada. Esa posición es lo que permite a FreeSWITCH hacer cosas que los proxies no pueden hacer de forma nativa: transcodificar codecs, reproducir prompts, grabar audio, mezclar conferencias, anclar cifrado y ejecutar lógica IVR contra el flujo de medios en vivo.
Esta diferencia arquitectónica determina casi todo lo demás sobre las plataformas. Un proxy SIP es rápido y ligero porque no transporta los medios. Un servidor de medios es más pesado por llamada porque sí lo hace. La mecánica más profunda de proxy versus B2BUA (Via, Route, Record-Route, stateless versus stateful, lo que un proxy puede y no puede reescribir) está cubierta en nuestro análisis de la arquitectura de proxy SIP. La versión corta: reenviar es un conjunto de operaciones, terminar es otro, y lo que está disponible para cada uno es fundamentalmente diferente.
Kamailio en profundidad
Kamailio se bifurcó del proyecto SIP Express Router (SER) en 2008 y ha sido desarrollado activamente desde entonces. Se implementa ampliamente como núcleo de enrutamiento SIP en redes de operadores, plataformas de PBX hospedado y stacks de comunicaciones como servicio (CPaaS) donde la prioridad de diseño es mover volúmenes muy altos de señalización SIP con latencia predecible.
La plataforma se configura a través de kamailio.cfg, un lenguaje de scripting de dominio específico que se lee como un programa estilo C restringido: bloques para el manejo de solicitudes, bloques de ruta para la lógica de enrutamiento, cargas de módulos en la parte superior del archivo. Para equipos que desean escribir la lógica de enrutamiento de llamadas en un lenguaje de propósito general, Kamailio ofrece el Kamailio Embedded Interface (KEMI), que expone el mismo modelo de enrutamiento a Lua, Python, JavaScript y Ruby. Un equipo con herramientas sólidas en Python puede escribir toda la capa de enrutamiento en Python manteniendo las características de rendimiento de Kamailio.
El ecosistema de módulos de Kamailio cubre los componentes que un proveedor de servicios necesita: un registrador SIP que escala a grandes bases de datos de usuarios, un módulo dispatcher para balanceo de carga entre servidores de medios back-end, un módulo de diálogo para rastrear llamadas activas, módulos de presencia y mensajería instantánea, módulos de contabilidad que escriben a MySQL, PostgreSQL o Kafka, e integración estrecha con RTPengine para el manejo de medios. Las implementaciones de alta disponibilidad típicamente ejecutan pares activo-standby con una IP flotante gestionada por Keepalived o Pacemaker.
Los roles comunes de Kamailio incluyen servir como registrador para cientos de miles de suscriptores, actuar como front end de señalización de alto CPS para una plataforma de PBX hospedado o CPaaS, y proporcionar el cerebro de enrutamiento frente a una flota de servidores de medios. La reputación de rendimiento de la plataforma es bien merecida, aunque las cifras específicas de llamadas por segundo dependen en gran medida del hardware, la configuración y lo que cada transacción debe hacer.
OpenSIPS en profundidad
OpenSIPS también se bifurcó de SER en 2008. Los dos proyectos divergieron tanto en filosofía como en código, y las diferencias se han ampliado con el tiempo. OpenSIPS prioriza un enfoque más integrado y con “baterías incluidas” para el enrutamiento SIP, con módulos nativos que cubren territorio que Kamailio deja a herramientas externas.
La arquitectura de OpenSIPS 3.x utiliza un modelo multi-proceso con memoria compartida para el estado, similar a Kamailio en estructura pero con diferentes valores predeterminados. La lógica de enrutamiento se escribe en el lenguaje de scripting procedural propio de la plataforma, que se siente más como un pequeño lenguaje de programación imperativo que el formato estilo configuración de Kamailio. El script tiene flujo de control explícito, variables y llamadas a funciones, y la mayoría de los ingenieros que trabajan con ambos reportan que los scripts de enrutamiento de OpenSIPS son más fáciles de leer a lo largo pero más difíciles de conectar con lenguajes externos.
Dos cosas destacan en el conjunto de módulos de OpenSIPS. El módulo B2BUA nativo de la plataforma es más desarrollado que el de Kamailio, lo que significa que OpenSIPS puede actuar como un agente de usuario back-to-back para flujos de llamada específicos sin agregar un componente separado. Los módulos de integración HTTP y REST también son ricos, lo que hace de OpenSIPS un ajuste cómodo para lógica de enrutamiento que depende de llamadas API externas: consultas de fraude, consultas de portabilidad numérica, verificaciones de facturación en tiempo real. El OpenSIPS Control Panel proporciona una interfaz de gestión basada en web que algunos equipos encuentran útil para visibilidad y operaciones básicas, aunque las implementaciones serias aún manejan la configuración a través del script.
Los roles de OpenSIPS incluyen enrutamiento SIP de alto volumen, control de sesión ligero con B2BUA nativo donde la arquitectura lo requiere, señalización para sistemas de contabilidad y facturación, y cualquier implementación donde el equipo prefiere una plataforma más autónoma en lugar de una que delegue piezas a herramientas externas.
Kamailio vs OpenSIPS: lo que realmente difiere
Para los ingenieros que eligen entre ambos, esto es lo que importa en la práctica.
El modelo de scripting es la primera divergencia. El lenguaje de configuración nativo de Kamailio más KEMI le da a la plataforma un puente limpio hacia Lua, Python, JavaScript y Ruby. Si su equipo escribe herramientas operativas en Python y quiere que la capa de enrutamiento viva en el mismo lenguaje, Kamailio es el ajuste más natural. OpenSIPS mantiene la lógica de enrutamiento en su propio lenguaje y pide al equipo que lo aprenda; los equipos que aprecian un formato procedural único y consistente dentro del propio servidor SIP frecuentemente prefieren esto.
La capacidad B2BUA es la segunda. OpenSIPS tiene un módulo B2BUA nativo más desarrollado. Si sus requisitos de enrutamiento incluyen comportamiento B2BUA para flujos específicos (manejo de re-INVITE, manipulación de tramos de llamada, bifurcación estructurada), OpenSIPS maneja más de eso sin componentes externos. Kamailio es más puramente proxy y se combina con herramientas separadas cuando se necesita semántica B2BUA.
La integración externa cubre el tercer eje. Ambas plataformas pueden consultar sistemas externos vía HTTP para decisiones de enrutamiento. Los módulos REST de OpenSIPS son maduros de fábrica; las capacidades equivalentes de Kamailio son igualmente capaces pero se acceden más comúnmente a través de scripts KEMI que envuelven el cliente HTTP de su lenguaje.
La filosofía de módulos define el cuarto. Kamailio es modular y delega agresivamente a componentes externos (RTPengine para medios, bases de datos separadas para estado, KEMI para lógica no trivial). OpenSIPS incorpora más funcionalidad en su conjunto de módulos nativos. Ninguna filosofía es incorrecta, pero conducen a los equipos hacia diferentes patrones operativos.
La comunidad y cadencia de versiones son aproximadamente comparables. Ambos proyectos tienen comunidades activas, versiones regulares y respaldo comercial estable a través de servicios de capacitación y consultoría. Las listas de correo, conferencias y documentación son saludables para ambos.
En nuestra experiencia, la elección entre Kamailio y OpenSIPS rara vez se reduce a una funcionalidad que uno tiene y el otro no. Se reduce a con cuál modelo mental se alinea su equipo, cómo es su herramienta operativa existente, y qué quiere que la capa de enrutamiento asuma como responsabilidad versus delegue.
FreeSWITCH en este contexto
FreeSWITCH pertenece a esta comparación no como una tercera opción para el mismo trabajo, sino como la plataforma a la que se recurre cuando los proxies no pueden hacer el trabajo. FreeSWITCH termina SIP, ancla medios, transcodifica codecs, ejecuta dialplans, reproduce prompts, mezcla conferencias, graba llamadas y expone la Event Socket Library (ESL) para el control externo completo de sesiones en vivo. Nada de eso es lo que un proxy SIP está diseñado para hacer.
Las características arquitectónicas y operativas de FreeSWITCH (su modelo de threading, envolvente de escala, compatibilidad con WebRTC, licenciamiento bajo la Licencia Pública de Mozilla) están bien documentadas en la literatura de telefonía de código abierto. En lugar de repetir ese material aquí, el punto relevante para este artículo es para qué sirve FreeSWITCH en el contexto de Kamailio y OpenSIPS: el motor de medios back-end que maneja la pequeña fracción de llamadas en cualquier plataforma dada que necesitan inteligencia de medios real.
El patrón híbrido: proxy al frente, servidor de medios detrás
Esta es la arquitectura en la que convergen la mayoría de las plataformas de voz de código abierto a gran escala, y es la conclusión práctica más importante de comparar estas tres plataformas.
El patrón se ve así. Un par de instancias de Kamailio u OpenSIPS se ejecuta en activo-standby con una IP flotante en el punto de entrada SIP. Manejan registros, autentican suscriptores, aplican políticas por cuenta, aplican balanceo de carga y enrutan la mayoría de las llamadas. Para las llamadas que necesitan servicios de medios (IVR, conferencias, grabación, transcodificación), Kamailio reenvía la llamada a un pool de servidores de medios FreeSWITCH y balancea la carga entre ellos. La capa de proxy transporta el peso de señalización a CPS muy alto; la capa de medios escala horizontalmente agregando instancias de FreeSWITCH.
El patrón aparece consistentemente en producción. Un operador latinoamericano de tercerización de procesos de negocio con el que conversamos recientemente ejecuta infraestructura de IBM Cloud con Kamailio en pares activo-standby, al frente de 31 servidores de medios FreeSWITCH dedicados que juntos manejan alrededor de 60,000 llamadas simultáneas a aproximadamente 1,000 llamadas por segundo para un solo cliente grande. Su pico total de plataforma es aproximadamente 300,000 llamadas por minuto. La división entre Kamailio para señalización y FreeSWITCH para medios es lo que permite escalar a la arquitectura: a ninguna plataforma se le pide hacer trabajo para el que la otra es más adecuada, y cada una puede escalarse horizontalmente en su propio eje.
Los operadores más pequeños ejecutan el mismo patrón a números más pequeños. La razón por la que la arquitectura sobrevive a través de diferentes escalas es que la división del trabajo es correcta: la señalización y los medios tienen perfiles de rendimiento diferentes, modos de falla diferentes y comportamiento de escalado diferente, e intentar manejar ambos dentro de un solo proceso crea contención.
Arquitectura de referencia para una plataforma de voz de código abierto de alta densidad: ProSBC en el borde orientado al operador maneja seguridad, normalización y STIR/SHAKEN; Kamailio se ubica detrás como front end de enrutamiento SIP y registrador; las instancias de FreeSWITCH detrás de Kamailio manejan las funciones que requieren anclaje de medios. Haga clic para ampliar.
Elección entre ellos por caso de uso
Para los equipos que toman la decisión de plataforma, la elección generalmente se mapea limpiamente al rol que cada componente desempeña.
- Registrador, balanceador de carga SIP o front end de enrutamiento de alto CPS: Kamailio u OpenSIPS. Cualquiera funciona. Elija según cuál modelo de scripting y filosofía operativa se ajusta a su equipo.
- IVR, conferencias, grabación, transcodificación o cualquier función que requiera anclaje de medios: FreeSWITCH. Combínelo con un proxy al frente para escalar.
- Normalización de señalización de nivel operador con scripting rico en Python o Lua: Kamailio con KEMI.
- Enrutamiento SIP con funcionalidades B2BUA integradas y un lenguaje de scripts de enrutamiento procedural: OpenSIPS.
- Plataforma estilo CPaaS con control de llamadas programable y alta concurrencia: Kamailio u OpenSIPS en el borde, FreeSWITCH para medios, su lógica de aplicación comunicándose con ambos a través de Event Socket y HTTP.
- Plataforma de control de llamadas pura sin carga de trabajo de medios en absoluto: un proxy solo es suficiente. Esto es raro en producción pero existe para algunas implementaciones específicas de solo enrutamiento.
Ninguno de ellos es un SBC: la realidad del SBC casero
Kamailio combinado con RTPengine, u OpenSIPS combinado con RTPproxy, se describe frecuentemente como un SBC casero. Para una definición estrecha de SBC (enrutamiento de señalización, recorrido básico de NAT, relay de medios), esa descripción se sostiene. El stack funciona, y para algunas implementaciones es la arquitectura correcta.
Para implementaciones que necesitan hacer lo que un controlador de borde de sesión en producción realmente se espera que haga, la brecha entre el stack casero y un SBC construido para ese propósito se amplía rápidamente. Las funciones que deben ser diseñadas, integradas, mantenidas y soportadas por cuenta propia incluyen las siguientes.
Firma, atestación y verificación STIR/SHAKEN con failover de STI-AS primario y secundario, decisiones de nivel de atestación por llamada, y el mapeo de causa-razón necesario cuando el servicio de firma devuelve una respuesta que no es éxito. El patrón de integración de servidor de redirección SIP utilizado por TransNexus ClearIP y Neustar (que es cómo funciona toda implementación real de STIR/SHAKEN hoy) requiere lógica de enrutamiento que maneje 302 (avance de ruta con encabezado Identity), 404 y 503 (continuar llamada) y 603 (detener llamada) de forma consistente.
Puntuación de fraude programable en tiempo real contra servicios externos. Evaluación de riesgo por llamada, listas de bloqueados dinámicas, integración con las API de puntuación de TransNexus, YouMail y SecureLogix, y la lógica de enrutamiento para tomar decisiones durante la llamada antes de que esta se establezca.
Mitigación de DoS y DDoS de nivel operador. Limitación de tasa consciente de SIP por origen, por troncal y por método; validación de protocolo que descarta mensajes malformados antes de que toquen su lógica de enrutamiento; detección de escaneo de registro que distingue patrones legítimos de re-registro de ataques; greylisting basado en porcentaje para respuesta graduada durante la investigación.
Normalización SIP multi-vendor impulsada por un motor de manipulación de encabezados que puede reconfigurarse por grupo de troncales sin editar scripts. Las combinaciones de fabricantes cambian a medida que los operadores actualizan sus plataformas, y la carga de mantenimiento de mantener actualizada una capa de reescritura de encabezados hecha a mano a través de docenas de peers se acumula rápidamente.
Ocultación de topología consistente entre señalización y medios. CDR por tramo con métricas de calidad, traps SNMP, una API de gestión RESTful, trazas Wireshark en vivo, y las herramientas operativas que el soporte de producción realmente utiliza.
Soporte del fabricante, acuerdos de nivel de servicio, propiedad del ciclo de vida de certificados y responsabilidad sobre la hoja de ruta. Nada de lo cual existe cuando el equipo que opera la plataforma es también el equipo que recibe la alerta a las 3 a.m.
El patrón que vemos con mayor frecuencia es el de operadores que construyeron una capa de SBC casero hace años y eventualmente la reemplazaron porque la carga de mantenimiento excedió los ahorros de costo. La decisión generalmente se cristaliza cuando STIR/SHAKEN, una nueva integración de operador o una auditoría de seguridad crea una carga de trabajo que el stack existente no puede absorber sin un proyecto de ingeniería de varios trimestres.
Dónde encaja ProSBC
ProSBC es un controlador de borde de sesión B2BUA de TelcoBridges. No compite con Kamailio u OpenSIPS por el rol de motor de enrutamiento, y no compite con FreeSWITCH por funciones de IVR o servidor de medios. Se ubica en el borde de la red frente a cualquiera de esas plataformas que su arquitectura utilice, manejando las funciones de seguridad, normalización y cumplimiento que el stack de código abierto le deja a usted.
En producción, esa ubicación se ve como uno de tres patrones. Frente a FreeSWITCH para interconexión de operadores, donde ProSBC termina el SIP externo, ejecuta la firma y verificación STIR/SHAKEN, normaliza los encabezados SIP que cada operador requiere y entrega SIP limpio a la plataforma de medios. Junto a Kamailio cuando el equipo quiere Kamailio para enrutamiento interno pero no quiere construir la capa de SBC en scripts. Reemplazando el patrón de “Kamailio haciendo demasiados trabajos” cuando una sola instancia ha acumulado responsabilidades de seguridad, fraude y cumplimiento para las que nunca fue diseñada.
Las capacidades verificadas de ProSBC cubren las brechas que el stack casero deja abiertas. Arquitectónicamente es un B2BUA, con terminación SIP completa y re-originación en ambos tramos y ocultación de topología consistente entre señalización y medios. Las cifras de escala del catálogo actual listan hasta 60,000 sesiones simultáneas por servidor, hasta 350,000 registros de terminales, y hasta 1,024 puntos de acceso de red (grupos de troncales) por servidor. Las funciones de seguridad cubren SIP sobre TLS, SRTP, protección contra DoS y DDoS, listas de bloqueados dinámicas con greylisting basado en porcentaje, y protección contra escaneo de registro SIP. STIR/SHAKEN se implementa a través de integración basada en SIP con TransNexus ClearIP y Neustar, con failover primario y secundario y la lógica de enrutamiento de causa-razón que las implementaciones de producción necesitan. El motor de enrutamiento programable en Ruby expone más de 100 parámetros de llamada y es compatible con consultas externas basadas en HTTP para puntuación de fraude, portabilidad numérica, CNAM y cualquier otro sistema que hable REST.
ProSBC se ejecuta en VMware, KVM y Proxmox, AWS y Microsoft Azure, y bare metal, lo que significa que se implementa junto a un stack existente de Kamailio o FreeSWITCH sin nueva infraestructura. Los precios por suscripción comienzan desde tan solo $1.40 por sesión por año según el catálogo actual, y una prueba gratuita de 30 días con activación en línea permite a un equipo probar ProSBC frente a su plataforma existente en su propio entorno. La licencia ProSBC Lab (permanentemente gratuita, tres sesiones, sin límite de tiempo) extiende ese acceso para trabajo continuo de laboratorio e integración.
Una nota para los equipos que consideran ProSBC como un reemplazo directo de la función de registrador de Kamailio: ProSBC no es un registrador SIP independiente. Escala el reenvío de registros y maneja la seguridad relacionada con el registro, pero para bases de datos de registro grandes o gestión de usuarios del lado PBX, los clientes lo combinan con Asterisk, FreePBX o cualquier PBX que su arquitectura ya utilice. Esta es una frontera deliberada entre la capa del SBC y la capa de la PBX, no una brecha que deba solucionarse.
Preguntas frecuentes
¿Es Kamailio mejor que OpenSIPS?
Ninguno es universalmente mejor. Resuelven el mismo problema general con diferentes filosofías. La interfaz KEMI de Kamailio lo convierte en el ajuste natural para equipos que quieren escribir lógica de enrutamiento en Lua, Python o JavaScript. OpenSIPS tiene un módulo B2BUA nativo más desarrollado y un lenguaje de scripts de enrutamiento procedural que algunos equipos encuentran más legible. La elección generalmente se reduce a la alineación operativa, no a la paridad de funcionalidades.
¿Pueden Kamailio u OpenSIPS reemplazar a FreeSWITCH?
No para funciones que requieren anclaje de medios. Kamailio y OpenSIPS son proxies SIP enfocados en señalización; no transcodifican de forma nativa, no ejecutan IVR contra medios en vivo, no mezclan conferencias ni graban. Para cargas de trabajo puras de enrutamiento y registro no necesitan FreeSWITCH; para cualquier cosa que requiera inteligencia de medios se combinan con él.
¿Necesito un SBC si ya tengo Kamailio más RTPengine?
Para muchas implementaciones de producción, sí. Kamailio más RTPengine maneja enrutamiento de señalización y relay de medios, pero no cubre de forma nativa STIR/SHAKEN con failover de STI-AS primario y secundario, puntuación de fraude programable en tiempo real contra servicios externos, mitigación de DoS y DDoS de nivel operador con listas de bloqueados dinámicas, ni las herramientas operativas y la responsabilidad del fabricante que un SBC construido para ese propósito proporciona. Si esa brecha importa depende de las regulaciones a las que esté sujeto, los operadores con los que interconecta, y cuánto de la capa de SBC su equipo quiere diseñar y mantener.
¿Puede FreeSWITCH manejar SIP trunking por sí solo?
Técnicamente sí, pero rara vez es la arquitectura correcta para volumen de producción. FreeSWITCH como la única capa SIP significa que cada llamada, incluso las que no necesitan servicios de medios, pasa por un B2BUA completo. El patrón de proxy más medios existe porque separar esas preocupaciones escala mejor y aísla los modos de falla.
¿Cuál es la arquitectura de producción típica usando los tres?
Kamailio u OpenSIPS en pares activo-standby en el punto de entrada SIP manejando registros, balanceo de carga y enrutamiento de alto CPS; instancias de FreeSWITCH detrás de ellos para cualquier llamada que necesite servicios de medios; un SBC en el borde de la red para interconexión de operadores, seguridad, STIR/SHAKEN y normalización SIP. Cada componente hace lo que fue diseñado para hacer, y cada uno puede escalarse de forma independiente.
Conclusión
Kamailio, OpenSIPS y FreeSWITCH resuelven diferentes problemas en el stack de voz de código abierto. Kamailio y OpenSIPS son motores de enrutamiento SIP para señalización de alto CPS, registro y balanceo de carga. FreeSWITCH es una plataforma de medios B2BUA para IVR, conferencias, transcodificación y grabación. La arquitectura correcta para la mayoría de las plataformas de producción no es uno de los tres, es una combinación: un proxy al frente para señalización, servidores de medios detrás para medios, y un SBC en el borde para todo lo que toca el mundo exterior.
Si está dimensionando una nueva plataforma, comience con el rol que cada componente desempeña en su arquitectura en lugar de la comparación de plataformas. Una vez que sepa qué trabajos le está dando a un proxy y cuáles a un servidor de medios, la elección de Kamailio versus OpenSIPS se convierte en una cuestión de ajuste del equipo, y la elección de dónde trazar la línea entre su capa de código abierto y la capa del SBC se convierte en una decisión de construir versus comprar que es mucho más fácil de tomar desde un punto de partida arquitectónico que desde una lista de funcionalidades.
Pruebe ProSBC con su stack de Kamailio, OpenSIPS o FreeSWITCH
ProSBC es un controlador de borde de sesión de nivel operador basado en software, diseñado para ubicarse frente al stack de voz de código abierto que ya opera. Opera como un B2BUA completo con configuración independiente de TLS/SRTP por grupo de troncales, con manipulación de encabezados SIP, ocultación de topología y protección contra DoS/DDoS incluida en cada implementación.
La plataforma admite hasta 60,000 sesiones simultáneas y 1,024 grupos de troncales (NAP) por servidor, con enrutamiento programable basado en Ruby para integración HTTP con puntuación de fraude, servicios de firma STIR/SHAKEN y consultas de portabilidad numérica. ProSBC se ejecuta de forma nativa en AWS y Microsoft Azure, en VMware, KVM y Proxmox, y en bare metal, por lo que se implementa junto a un stack existente de Kamailio o FreeSWITCH sin nueva infraestructura.
Los precios por suscripción comienzan desde tan solo $1.40 por sesión por año según el catálogo actual. La licencia ProSBC Lab es permanentemente gratuita con tres sesiones y sin límite de tiempo, útil para probar la plataforma contra su configuración existente de Kamailio u OpenSIPS antes de comprometerse.
¿Prefiere evaluar por su cuenta primero? Comience su prueba gratuita de 30 días.