Migración de Sonus SBC a ProSBC: por qué los ingenieros de voz abandonan la infraestructura legacy de Sonus
El nombre Sonus todavía figura en muchos session border controllers instalados en racks de producción. La empresa detrás de ese nombre dejó de existir como negocio independiente en 2017. Sonus Networks se fusionó con GENBAND ese año y la entidad combinada pasó a llamarse Ribbon Communications, lo que significa que las plataformas SBC 5100, 5200, 5110 y 5210, que los ingenieros aún llaman “las cajas Sonus”, son ahora hardware legacy en una hoja de ruta que controla Ribbon, no Sonus.
Para los ingenieros de voz, la pregunta rara vez es si el hardware todavía cursa llamadas. Por lo general, sí. La pregunta aparece cuando la plataforma alcanza el fin de soporte, cuando una auditoría de seguridad señala un equipo que ya no recibe parches, o cuando Ribbon propone una actualización de reemplazo total hacia su línea actual SBC 5400, 7000 o SWe. En ese punto de decisión, un número creciente de equipos aprovecha el cambio forzado como el momento para evaluar si permanecer dentro del ecosistema Ribbon es realmente la mejor opción.
Esta página cubre lo que significa operar infraestructura legacy de Sonus hoy, el calendario específico de fin de soporte para la línea SBC legacy, y lo que implica una migración desde un Sonus SBC hacia ProSBC. Si está evaluando ProSBC frente a la línea actual de Ribbon en lugar de planificar una migración desde hardware legacy, la comparación entre ProSBC y Ribbon SBC es un mejor punto de partida, y esta página asume que ya la leyó o la leerá.
Cómo Sonus se convirtió en Ribbon, y por qué su SBC todavía dice Sonus
La confusión de marca vale la pena aclararla porque condiciona la conversación sobre soporte. Sonus Networks anunció su fusión con GENBAND en mayo de 2017, en un acuerdo que otorgó a los accionistas de cada empresa aproximadamente la mitad del negocio combinado y valoró la nueva entidad en alrededor de 745 millones de dólares. La fusión se completó ese mismo año y la empresa adoptó el nombre Ribbon Communications.
El portafolio de productos de Sonus no desapareció en ese momento. Las plataformas SBC de la serie 5000, los media gateways GSX y el servidor de políticas PSX continuaron bajo el nombre de Ribbon, y los equipos de ingeniería siguieron manteniéndolos durante años. Por eso un appliance comprado en 2015 o 2016 todavía arranca con la marca Sonus, mientras que cada boletín de soporte, aviso de fin de vida y cotización de renovación llega ahora con el membrete de Ribbon.
La consecuencia práctica es que “operamos Sonus” y “somos clientes de Ribbon” describen la misma situación. Las decisiones de hoja de ruta, el ciclo de vida de soporte y los precios de actualización para ese hardware legacy los define Ribbon hoy.
La realidad operativa de ejecutar infraestructura Sonus sin soporte
El fin de soporte no es una fecha flexible. Cuando una plataforma lo supera, el fabricante deja de entregar actualizaciones de software, deja de emitir correcciones de seguridad y deja de aceptar casos de soporte. Para la línea legacy de Sonus, esas fechas ya pasaron: los SBC 5100 y 5200 perdieron el soporte en febrero de 2020, y los SBC 5110 y 5210 los siguieron en octubre de 2023.
El propio Ribbon plantea la situación en términos de seguridad. Su notificación de fin de soporte para los 5110 y 5210 indica claramente que las organizaciones que aún operan esas plataformas tienen redes vulnerables a ciberataques, y menciona ransomware, exposición al cumplimiento normativo y riesgo de gobernanza de datos como las preocupaciones específicas. Esa evaluación proviene del fabricante que construyó el hardware, y es la señal más clara que un ingeniero de voz puede presentar internamente para justificar un presupuesto de migración.
La exposición se agrava de varias formas. Un SBC se ubica en el borde de la red y actúa como la frontera de seguridad para todo el tráfico SIP, por lo que un SBC sin parches es un firewall sin parches para la red de voz. El hardware que lleva ocho o diez años en servicio también acumula riesgo físico: fuentes de poder, ventiladores y almacenamiento envejecen, y las piezas de repuesto para un chasis fuera de soporte se vuelven más difíciles de conseguir. En cuanto al cumplimiento, los marcos de seguridad y las auditorías de clientes exigen cada vez más que la infraestructura de borde ejecute software soportado con una ruta de parches vigente, y una línea de productos descontinuada no puede satisfacer ese requisito sin importar cuán estable haya sido el equipo.
Nada de esto significa que un Sonus SBC legacy vaya a fallar mañana. Muchos funcionan años después de su fecha de fin de soporte sin una interrupción. El punto es que el riesgo ya no está siendo gestionado activamente por nadie, y el costo de ese riesgo recae completamente en el equipo que opera el equipo.
La encrucijada: actualización de reemplazo total a Ribbon actual, o migrar a otra plataforma
Una vez que el reloj de soporte se agota, la ruta recomendada por Ribbon es una actualización de reemplazo total hacia su línea actual, típicamente el appliance SBC 5400 o 7000 o la edición de software SBC SWe. Esa ruta mantiene el modelo de configuración familiar y preserva el conocimiento operativo existente, lo cual tiene valor real para un equipo que ha invertido años en las herramientas de Sonus.
También reabre todas las preguntas comerciales y arquitectónicas que acompañaron la compra original. Pasar al SBC SWe coloca el despliegue en una plataforma de software actual, pero para muchos operadores de mercado medio esa plataforma históricamente ha funcionado sobre VMware, que tiene su propia trayectoria de costos tras los cambios de licenciamiento de Broadcom. El firmado STIR/SHAKEN de Ribbon pasa por un componente PSX separado en lugar de residir en el SBC. Los precios siguen siendo bajo cotización en lugar de publicados. Estas no son críticas nuevas, y se cubren en detalle en la comparación entre ProSBC y Ribbon SBC, por lo que esta página no las repite. El punto relevante para una decisión de migración es que una actualización de reemplazo total es en sí misma un proyecto con un laboratorio, una ejecución en paralelo y un corte, lo que significa que el esfuerzo adicional para evaluar un proveedor diferente durante esa misma ventana es pequeño.
Ese es el razonamiento que siguen muchos ingenieros de voz. La renovación de hardware va a ocurrir de todas formas. Si el equipo ya está levantando nueva infraestructura, ejecutándola en paralelo y migrando tráfico, entonces hacer ese trabajo hacia ProSBC en lugar de un nuevo appliance de Ribbon cuesta poco extra y elimina los puntos de fricción recurrentes al mismo tiempo. Para una visión más amplia de las fuerzas que empujan a los operadores de appliances fijos a software, la guía para reemplazar SBC de hardware por software presenta el caso general, y el análisis de TCO de SBC de hardware versus software le pone números.
Qué implica migrar desde Sonus
Una migración de Sonus a ProSBC es más un problema de traducción de configuración que un problema de red. Las dos plataformas realizan las mismas funciones de SBC pero las describen con objetos diferentes, así que la primera tarea es construir un modelo mental funcional de cómo la configuración de Sonus se mapea a ProSBC.
La tabla a continuación cubre los objetos que aparecen en casi todos los despliegues de Sonus. Ninguno de los mapeos es exacto, por lo que la tercera columna es la que importa: describe cómo cada concepto de Sonus se comporta de manera diferente una vez reconstruido en ProSBC.
| Objeto Sonus SBC | Equivalente en ProSBC | Qué cambia en la práctica |
|---|---|---|
| Zona (Address Context) | Agrupación de NAP más lógica de enrutamiento | ProSBC no tiene un contenedor de dominio separado. La separación por tenant o unidad de negocio se maneja mediante nomenclatura de NAP, lógica de routing-script y ACL en lugar de un objeto Zona padre. |
| SIP Signaling Port | Interfaz de señalización del NAP | La interfaz de señalización es una propiedad del NAP en ProSBC, no un recurso gestionado por separado y compartido entre grupos de troncales. |
| Grupo de troncales SIP | NAP (Network Access Point) | El mapeo uno a uno más directo. Un solo NAP contiene la configuración de transporte, proxy, lista de códecs y ACL que Sonus distribuye entre el grupo de troncales y sus atributos asociados. |
| IP Peer | Proxy del NAP y dirección del extremo remoto | La dirección del extremo remoto que Sonus referencia en una etiqueta de enrutamiento se convierte en una propiedad del NAP de destino. |
| ERE (Embedded Routing Engine) | Routing Script | La lógica de enrutamiento local pasa al motor de enrutamiento de ProSBC. Las decisiones de enrutamiento estático se mapean directamente; la lógica condicional se convierte en código procedural que se ejecuta por llamada. |
| PSX (Policy Server) | Routing Script con consultas HTTP externas | No se requiere un servidor de políticas separado. La política centralizada que residía en el PSX se reimplementa como lógica de routing-script, que puede consultar sistemas externos vía HTTP para las mismas decisiones que tomaba el PSX. |
| Routing Labels | Tabla de enrutamiento más Routing Script | Las entradas de ruta simples se mapean a la tabla de enrutamiento; la conmutación por error, el enrutamiento por horario y el enrutamiento de menor costo pasan al script. |
| STIR/SHAKEN basado en PSX | Módulo de firmado del Routing Script | El firmado y la verificación se ejecutan a través del motor de enrutamiento y se integran con cualquier servicio de firmado externo, con endpoints primario y secundario y una ruta de respaldo. La atestación se convierte en una decisión por llamada en lugar de una configuración por troncal. |
| EMA / gestión de Ribbon | Portal web de ProSBC más API | La gestión de elementos se consolida en el portal web de ProSBC, con la orquestación multi-elemento manejada a través de la API. |
Las fases que siguen a este mapeo no son específicas de Sonus. Auditar el despliegue actual, dimensionar el reemplazo según el tráfico real, levantar un laboratorio, ejecutar ambos SBC en paralelo, migrar los grupos de troncales uno a la vez y descomisionar la plataforma antigua después de la validación es la misma secuencia sin importar de qué fabricante esté saliendo. En lugar de repetirlo aquí, la guía para reemplazar SBC de hardware por software recorre ese marco de cinco pasos en detalle, incluyendo cómo extraer noventa días de CDR para encontrar los conteos reales de sesiones pico y cómo mantener una ruta de rollback abierta durante el corte.
Consideraciones específicas de la migración desde Sonus
Algunas cosas tienden a ser específicas de las migraciones desde Sonus en lugar de comunes a cualquier movimiento de SBC, y vale la pena identificarlas durante la auditoría en lugar de descubrirlas en el corte.
Dónde reside realmente la lógica de enrutamiento es la primera pregunta. Si el despliegue utiliza un PSX externo, gran parte de la inteligencia de enrutamiento y políticas reside en el PSX y no en el propio SBC, y esa lógica es lo que debe reproducirse en el routing script de ProSBC. Un equipo que audita solo la configuración del SBC y pasa por alto el PSX omitirá la parte más importante de la migración. Mapear la política del PSX suele ser el elemento de trabajo individual más grande en una migración desde Sonus.
El caso solo con ERE es más sencillo. Los despliegues de Sonus más pequeños que nunca implementaron un PSX mantienen todo el enrutamiento en el motor integrado, y esa lógica se traduce de forma bastante directa a la tabla de enrutamiento y el script de ProSBC. Saber qué modelo utiliza el despliegue, solo ERE o respaldado por PSX, define el alcance del proyecto desde el inicio.
La antigüedad de certificados y software importa en hardware que ha estado en servicio desde antes del cambio de nombre a Ribbon. Los certificados TLS en un equipo con una década de servicio pueden usar longitudes de clave o cadenas de confianza que los peers ya no prefieren, y la migración es el momento natural para renovarlos en lugar de trasladar material obsoleto.
La exportación de configuración en el Sonus SBC se realiza por CLI. La configuración en ejecución se captura de forma más completa a través del CLI en lugar de capturas de pantalla de la interfaz de gestión, así que planifique exportarla como texto y trabajar a partir de eso como el inventario autoritativo.
Preguntas frecuentes
¿Mi Sonus SBC todavía tiene soporte?
Para la línea de hardware legacy, casi con certeza no. Los Sonus SBC 5100 y 5200 alcanzaron el fin de soporte el 2 de febrero de 2020, y los SBC 5110 y 5210 alcanzaron el fin de soporte el 15 de octubre de 2023, incluidas las versiones US Federal. Después de esas fechas, Ribbon ya no emite actualizaciones de software, parches de seguridad ni atiende casos de soporte para esas plataformas. Si no está seguro de qué modelo opera, la etiqueta del chasis y la versión de software lo identificarán, y Ribbon publica los boletines de fin de soporte para cada uno.
¿Cuál es la diferencia entre Sonus y Ribbon?
Son el mismo linaje de productos bajo dos nombres. Sonus Networks se fusionó con GENBAND en 2017 y la empresa combinada se renombró Ribbon Communications. Las plataformas SBC que aún llevan la marca Sonus fueron absorbidas por el catálogo de Ribbon, por lo que el soporte, la hoja de ruta y los precios para ese hardware legacy los gestiona Ribbon hoy.
¿Tengo que hacer una actualización de reemplazo total al Ribbon SBC 5400 o SWe?
No. Una renovación hacia la línea actual de Ribbon es una opción, pero no la única. Dado que cualquier movimiento desde el hardware legacy requiere levantar un nuevo SBC, ejecutarlo en paralelo y migrar el tráfico, el mismo esfuerzo de proyecto puede migrar hacia ProSBC en su lugar. Muchos equipos tratan la renovación forzada de hardware como el momento para reevaluar al proveedor en lugar de renovar automáticamente dentro del ecosistema Ribbon.
¿Puede ProSBC reemplazar un Sonus SBC 5100, 5200, 5110 o 5210?
Sí. ProSBC es un SBC de software que escala hasta 60,000 sesiones por servidor y funciona sobre VMware, KVM, Proxmox, AWS, Azure o bare metal, lo que cubre la capacidad de sesiones de la línea de hardware legacy de Sonus con margen de sobra. La migración es un ejercicio de traducción de configuración, mapeando Zonas, grupos de troncales y lógica de enrutamiento a NAP y routing scripts de ProSBC, en lugar de un reemplazo de hardware idéntico.
¿Qué sucede con la lógica de enrutamiento en mi PSX?
Las decisiones de políticas y enrutamiento que residen en un PSX externo de Sonus se reimplementan en el routing script de ProSBC. El script puede consultar sistemas externos vía HTTP para las mismas búsquedas que realizaba el PSX, por lo que la lógica centralizada como enrutamiento de menor costo, traducción de números o calificación de fraude se traslada sin requerir un servidor de políticas separado. Auditar la configuración del PSX suele ser la tarea individual más grande en la migración, por lo que debe dimensionarse desde el inicio.
¿Cómo se comparan los precios de ProSBC con permanecer en Ribbon?
ProSBC utiliza precios de suscripción anual publicados y puede llegar a un mínimo de 1.40 dólares por sesión por año, sin cargo único de instalación. Ribbon no publica sus precios, y una actualización de reemplazo total hacia hardware actual conlleva tanto costos de nuevo appliance o licencia como los servicios asociados. La comparación comercial y arquitectónica completa se cubre en la comparación entre ProSBC y Ribbon SBC.
Comience la migración desde Sonus con un laboratorio, no con un compromiso
La forma de menor riesgo para descubrir si ProSBC se adapta a un entorno Sonus existente es desplegar una instancia de ProLab y reconstruir un grupo de troncales contra un operador real. La licencia ProLab es permanentemente gratuita, proporciona tres sesiones concurrentes y se aprovisiona en aproximadamente veinte minutos, lo cual es suficiente para validar el mapeo de configuración contra el SIP que sus operadores realmente envían antes de comprometerse con nada.
Para los equipos que prefieren no ejecutar el proyecto internamente, el servicio gestionado cubre la migración de principio a fin: auditar la configuración existente de Sonus y PSX, mapearla a ProSBC, desplegar, gestionar la ejecución en paralelo y ejecutar el corte, con alta disponibilidad (HA) 1+1 y soporte 24×7 incluidos.
¿Prefiere evaluar por su cuenta primero? Inicie su prueba gratuita de 30 días.