Migración de SBC Avaya: cómo reemplazar el SBCE sin interrumpir la voz
Las implementaciones de Avaya SBCE siguen procesando llamadas. Ese rara vez es el problema. La conversación sobre migración suele comenzar cuando algo alrededor del SBCE cambia: una segunda solicitud de protección por Chapter 11 reabre la cuestión de riesgo del proveedor, un par de SBCE alcanza el techo de 2,000 sesiones y desencadena una expansión inesperada de licencia, un aviso de fin de venta de Carrier Services obliga a un cambio del lado del SIP trunk de todas formas, o la cotización de renovación del Core Suite llega sin un precio por sesión que el equipo de compras pueda modelar. Ninguno de esos factores requiere tocar Communication Manager, Session Manager ni Aura. El controlador de borde de sesión (SBC) es un componente único en el borde, y en muchas implementaciones puede reemplazarse de forma independiente del resto de la infraestructura de voz.
Esta página es la guía operativa para migrar del Avaya SBCE a ProSBC. Asume que la decisión de evaluar un reemplazo ya fue tomada y recorre lo que la migración realmente implica en producción: cómo auditar la configuración existente del SBCE, cómo los objetos de configuración de Avaya se mapean a los de ProSBC, cómo ejecutar ambos SBC en paralelo de forma segura y cómo planificar una migración con un camino de reversión real.
Qué desencadena una migración de Avaya SBCE en 2026
El detonante de la migración suele ser uno de cuatro eventos específicos, no una insatisfacción general con la plataforma. Saber cuál aplica determina cómo se define el alcance del proyecto y qué tan agresivo debe ser el cronograma.
Reevaluación del riesgo del proveedor es el detonante más frecuente en 2026. Avaya se acogió a Chapter 11 en 2017 y nuevamente en febrero de 2023, la segunda vez eliminando aproximadamente el 75 % de su deuda de 3,400 millones de dólares y emergiendo 76 días después. La organización post-reestructura es más delgada, la dirección estratégica está más enfocada en ofertas de nube y suscripción, y algunos clientes han comenzado a reevaluar cómo desean gestionar la dependencia a largo plazo de la infraestructura local. Nada de eso significa automáticamente que el SBCE vaya a desaparecer, pero sí cambia la forma en que los equipos de compras, riesgo y continuidad responden a la pregunta de si el SBC en el borde de la red debe depender de este proveedor en particular.
El techo de 2,000 sesiones importa para cualquier entorno cuyos volúmenes de llamadas estén creciendo. Las implementaciones de SBCE suelen dimensionarse en torno a una arquitectura de 2,000 sesiones por servidor, lo que significa que el crecimiento más allá de ese punto puede requerir instancias adicionales de SBCE, licencias adicionales y sobrecarga de administración adicional. Los operadores que alcanzan el techo suelen descubrirlo durante un pico de hora punta que desencadena una conversación de licenciamiento no planificada. Un SBC por software que escala a 60,000 sesiones por servidor reduce todo ese problema a un cambio de configuración.
Licenciamiento opaco bajo el modelo de suscripción es el tercero. Avaya migró el SBCE a una suscripción obligatoria, con sesiones agrupadas en proporciones 7:1 Standard-to-Advanced bajo el licenciamiento de Core Suite, y sin precio publicado por sesión. Proyectar los costos del SBC a tres y cinco años requiere una conversación de cotización que depende del resto del contrato de Avaya. Los equipos de compras y finanzas que construyen modelos de TCO para un ciclo OPEX encuentran cada vez más difícil defender esta opacidad internamente.
Señales de fin de venta en el portafolio más amplio de Avaya son el cuarto. Avaya Carrier Services SIP Trunking tiene una fecha límite de migración publicada en septiembre de 2025, y otras líneas de producto han pasado por fin de venta durante la misma ventana. El SBCE en sí no ha sido declarado en fin de venta al momento de escribir este artículo, pero el patrón de racionalización hace que “planificar un reemplazo ahora, en nuestros tiempos, mientras todo aún funciona” sea la opción más segura que esperar una carta con fecha límite.
Si el detonante aplica a un solo par de SBCE en un estado Avaya más amplio, la migración puede acotarse a ese único elemento. Aura, Communication Manager, Session Manager, los planes de marcado y el resto del stack de Avaya permanecen donde están. El SBC es la única pieza que cambia.
Fase 0: inventariar lo que hay en el SBCE hoy
Toda migración de SBC exitosa comienza con una auditoría honesta de la configuración actual. Omitir este paso es la causa más común de sorpresas durante la migración. El resultado no es una captura de pantalla del EMS de Avaya SBCE, sino una lista estructurada que se mapea limpiamente a lo que el SBC de reemplazo necesita para su configuración.
Extraiga lo siguiente del SBCE existente antes de tocar cualquier otra cosa.
Conteos reales de sesiones. Exporte 90 días de CDR y encuentre el conteo real de sesiones concurrentes en hora pico, no el máximo licenciado. Muchas implementaciones de SBCE operan muy por debajo del techo de 2,000 sesiones, lo que significa que el reemplazo puede dimensionarse según el uso real en lugar de la capacidad nominal. ProSBC soporta implementaciones de hasta 60,000 sesiones por servidor, por lo que el dimensionamiento suele estar determinado más por los requisitos de implementación que por los límites del hardware.
El inventario de Server Configuration. Liste cada Server Configuration en el SBCE: trunks de operador, pares de Session Manager, grupos de trunks de Communication Manager, integraciones de centro de contacto o CPaaS, plataformas de grabación o análisis, y cualquier terminal de prueba interno. Para cada uno, capture el transporte (UDP, TCP, TLS), la dirección y el puerto, y qué Routing Profile, Media Rule, Signaling Rule y TLS Profile se vinculan en el End Point Flow.
El catálogo de Media Rule y Signaling Rule. Documente las preferencias de códec, la política de SRTP y TLS, los intervalos de keep-alive de OPTIONS, el manejo de early-media, el comportamiento de DTMF y cualquier particularidad por lado. Una implementación real de SBCE normalmente tiene menos conjuntos de reglas distintas que Server Configurations, y un mismo conjunto de reglas suele reutilizarse en múltiples pares.
Scripts SigMa y Routing Profiles. Exporte cada script SigMa y cada Routing Profile. Esta es la parte de la configuración que contiene la mayor lógica de negocio: reescrituras de P-Asserted-Identity para operadores específicos, normalización de encabezados From para Aura, transformaciones de plan de marcado, etiquetado de atestación para STIR/SHAKEN, entre otros. Cualquier cosa que no se identifique y recree durante la migración puede afectar el comportamiento después de la migración, por lo que los scripts no etiquetados o no documentados merecen atención explícita ahora y no durante la ejecución en paralelo.
Topology Hiding Profiles, TLS Profiles y ACL. Capture cada Topology Hiding Profile, cada certificado TLS y su fecha de expiración, cada lista de IPs permitidas o bloqueadas, cada Application Rule y cualquier umbral de DDoS. TLS en particular requiere un manejo cuidadoso porque la cadena de certificados en el nuevo SBC debe satisfacer a los mismos pares upstream y downstream sin romper la autenticación mutua.
STIR/SHAKEN e integraciones antifraude. Si el SBCE firma o verifica a través de un STI-AS externo, o si una plataforma de fraude telefónico se conecta a él, documente el servicio de firma, los certificados y la política de atestación. Estas piezas son las que más probablemente requieran un enfoque arquitectónico diferente en ProSBC, donde la firma y la detección de fraude se integran directamente en el flujo de enrutamiento en lugar de existir como elementos de configuración por trunk.
Fase 1: mapear objetos de Avaya SBCE a objetos de ProSBC
La mayor fuente de fricción en la migración no es la red, sino el modelo de configuración. Avaya y ProSBC describen las mismas funciones subyacentes del SBC con objetos diferentes, y los ingenieros que ejecutan la migración necesitan un modelo mental funcional del mapeo antes de comenzar la construcción en laboratorio.
La tabla siguiente cubre los objetos que aparecen en toda implementación de SBCE. El mapeo es conceptual, no una equivalencia línea por línea, y la columna derecha captura la diferencia práctica que afecta cómo se traduce la configuración.
| Objeto de Avaya SBCE | Equivalente en ProSBC | Qué cambia en la práctica |
|---|---|---|
| Server Configuration | NAP (Network Access Point) | Mapeo uno a uno. El NAP contiene transporte, dirección, lista de códecs, SRTP y configuración de ACL que el SBCE divide entre Server Configuration, Media Rule y Signaling Rule. |
| Media Rule | Configuración de medios del NAP | Las preferencias de códec, la política de SRTP y el anclaje de medios se integran en el propio NAP. No hay un objeto Media Rule separado que mantener junto a él. |
| Signaling Rule | Configuración de señalización del NAP y SIP Profile | El keep-alive de OPTIONS, el manejo de solicitudes, el manejo de respuestas y el comportamiento SIP por lado se trasladan al NAP. ProSBC trata los parámetros de señalización como propiedades del NAP en lugar de un objeto de regla compartido. |
| Topology Hiding Profile | Configuración de ocultación de topología del NAP | La ocultación de topología se convierte en una configuración por NAP. No existe un objeto de perfil separado para reutilizar entre pares. |
| Script SigMa | Routing Script (módulo Ruby) | El cambio conceptual más grande. El lenguaje propietario de scripting de Avaya se convierte en Ruby, con el beneficio de consultas HTTP externas, lógica condicional contra cualquier parámetro de llamada y la capacidad de integrar fraude, LNP y STIR/SHAKEN en la decisión de enrutamiento misma. |
| Routing Profile | Tabla de enrutamiento más Routing Script | Las entradas de enrutamiento simples se mapean directamente. El enrutamiento condicional (failover de operador, enrutamiento por horario, menor costo) se implementa en el Routing Script en lugar de como entradas adicionales de Routing Profile. |
| End Point Flow (Server / Subscriber Flow) | Coincidencia de IP de origen del NAP más lógica de enrutamiento | La decisión de “qué configuración aplica a qué tráfico” pasa de un objeto Flow a la combinación de reglas de coincidencia del NAP y el Routing Script. La clasificación de entrada se convierte en coincidencia explícita de origen por NAP. |
| Application Rule | Límites de sesión del NAP y umbrales de DDoS | Los límites de sesión por par y los umbrales de DDoS se integran en el NAP. Los umbrales globales residen en la configuración a nivel de sistema. |
| TLS Profile | Configuración TLS del NAP y almacén de certificados | Los certificados se cargan una vez y se referencian por NAP. mTLS para Teams Direct Routing o para trunks de operador sigue el mismo patrón que en el SBCE. |
| Firma STIR/SHAKEN externa | Módulo de firma del Routing Script | STIR/SHAKEN en ProSBC se ejecuta a través del motor de enrutamiento y se integra con proveedores externos de STI-AS (TransNexus ClearIP, Neustar o cualquier servicio de firma basado en HTTP) con terminales primarios y secundarios y respaldo P-Identity-Bypass. La atestación se convierte en una decisión por llamada en lugar de una configuración por trunk. |
| EMS (Element Management System) | Portal web de ProSBC más API | La administración de panel único se consolida en el portal web de ProSBC. La orquestación de múltiples elementos se gestiona mediante la API en lugar de un producto de administración separado. |
El mapeo no es la migración. Es el contrato contra el cual trabajan las tres fases siguientes.
Fases 2-4: el plan de migración
El plan siguiente asume un solo par de SBCE reemplazado por una sola instancia de ProSBC (con ProSBC+ para HA 1+1). Las implementaciones de SBCE con múltiples elementos siguen el mismo patrón elemento por elemento. La secuencia completa típicamente toma de cuatro a ocho semanas desde el laboratorio hasta la migración, dependiendo de cuántos operadores e integraciones con Aura estén dentro del alcance.
Fase 2: construcción en laboratorio
Levante una instancia de ProLab en el mismo segmento de red que el SBCE. La licencia de ProLab es permanentemente gratuita, permite tres sesiones concurrentes y se aprovisiona en aproximadamente veinte minutos. Use el laboratorio para replicar un Server Configuration del lado del operador, un par de Session Manager o Communication Manager, y cualquier lógica SigMa asociada traducida a Ruby. El objetivo de la fase de laboratorio es validar el mapeo de la tabla de configuración anterior contra el dialecto específico de SIP que el operador actual y el lado de Aura realmente envían, no recrear la configuración de producción completa.
Si Teams Direct Routing está dentro del alcance del SBCE actual, pruebe mTLS, SRTP y el flujo de OPTIONS entre el SBC y Teams contra un tenant de prueba. La certificación de Teams importa como requisito de compras en algunas organizaciones: ProSBC soporta Teams Direct Routing y está implementado en entornos de producción con Teams DR, pero no ha obtenido la certificación formal de Microsoft. Si existe un requisito estricto de certificación, la lista publicada por Microsoft es la fuente de verdad.
Fase 3: replicar
Una vez que la construcción en laboratorio valida el mapeo, construya la configuración de producción completa en la instancia de ProSBC. Replique cada NAP a partir del inventario de Server Configuration, traslade las listas de códecs y la política de SRTP desde las Media Rules, y convierta los scripts SigMa en lógica de módulo Ruby. Aquí es donde se invierte el tiempo, y es la fase que más se beneficia de un inventario limpio de la Fase 0.
Cargue los certificados TLS y configure los ajustes de TLS a nivel de NAP. Si se requiere TLS y SRTP de extremo a extremo, valide las suites de cifrado y las suites criptográficas de SRTP contra lo que los operadores y Aura realmente negocian, no contra lo que la configuración del SBCE parece indicar. Las discrepancias entre la política configurada y el tráfico observado son la segunda causa más común de sorpresas durante la migración.
Si la firma STIR/SHAKEN está dentro del alcance, apunte el routing script al mismo servicio de firma externo que el SBCE usa hoy, o a un proveedor diferente si la migración es el momento adecuado para cambiar. Configure las URL de firma primaria y secundaria y confirme el comportamiento de respaldo P-Identity-Bypass.
Fase 4: ejecución en paralelo
Mantenga el SBCE en producción. Enrute un trunk de operador a través de ProSBC mientras todos los demás trunks permanecen en el SBCE. De dos a cuatro semanas de ejecución en paralelo típicamente captura los casos límite que las pruebas de laboratorio no pueden reproducir: un encabezado P-Charge-Info inusual de un operador específico, comportamiento de renegociación de códec en hora pico, un intervalo de OPTIONS que difiere del valor documentado, un comportamiento de encabezado específico de Session Manager que el SBCE maneja silenciosamente, o un código de respuesta SIP específico para el que ProSBC necesita una regla explícita.
Compare las tasas de completación de llamadas, los puntajes MOS, la precisión de CDR y los niveles de atestación STIR/SHAKEN entre ambas rutas durante el período de ejecución en paralelo. Si un script SigMa resulta estar haciendo trabajo que nadie documentó, descubrirlo en el cinco por ciento del tráfico es mucho mejor que descubrirlo en el cien por ciento.
Migración
Programe la migración durante una ventana de mantenimiento con el SBCE encendido y en caliente. Mueva los trunks de operador restantes uno a la vez, validando cada uno antes de mover el siguiente. Actualice los registros DNS y cualquier referencia de enrutamiento upstream para que apunten a ProSBC.
Deje el SBCE encendido y accesible durante al menos treinta días. Este es el camino de reversión. Si un problema que afecta al cliente surge después de la migración, redirigir el tráfico de vuelta al SBCE es un cambio de red, no un proyecto de recuperación. Después de que pase la ventana de validación, descomisione el chasis o la instancia virtual del SBCE y cancele la línea de Core Suite en la próxima renovación.
Validación posterior a la migración
Las primeras setenta y dos horas después de la migración son la ventana de validación de mayor rendimiento. Tres verificaciones son las que más importan.
Reconciliación de CDR cubre si los registros de llamadas en el nuevo SBC coinciden con el volumen y la forma del anterior. Compare los conteos de llamadas hora por hora, la duración promedio de llamada y la distribución de códigos de disposición entre la última semana completa en el SBCE y los primeros tres días en ProSBC. Una divergencia generalmente apunta a una regla SigMa que no sobrevivió al mapeo, más que a un problema de red.
Validación de umbrales antifraude importa específicamente porque las reglas de detección de fraude telefónico ajustadas al comportamiento del SBCE pueden generar falsos positivos o no detectar patrones en el nuevo SBC. Si la calificación de fraude en tiempo real está integrada a través de TransNexus ClearIP, SecureLogix o YouMail, observe la primera semana de decisiones cuidadosamente y ajuste los umbrales con base en los falsos positivos observados.
Continuidad del monitoreo cubre cualquier telemetría que salía del SBCE: traps SNMP, feeds de syslog, flujos de CDR por RADIUS o integración con los productos de administración de elementos de Avaya. ProSBC expone métricas por NAP y por llamada que se enrutan hacia Datadog, Prometheus, un SIEM o un servicio de monitoreo gestionado. Confirme que los tableros de control estén leyendo el nuevo feed antes de declarar la migración como completa.
Errores comunes en la migración
En migraciones de MSP, ISP, centros de contacto y empresas, cuatro errores aparecen con más frecuencia que cualquier otro. Ninguno es una sorpresa técnica en sí mismo, pero cada uno tiende a costar un día o dos si no se anticipa.
Lógica SigMa no documentada. Las implementaciones de SBCE acumulan reglas de reescritura de encabezados durante años, a menudo agregadas por personas que ya no forman parte del equipo. Tratar los scripts existentes como autoritativos sin entender por qué existe cada uno es la forma más rápida de romper un operador específico durante la migración. Lo correcto es revisar cada script SigMa durante la Fase 0 y marcar aquellos cuyo propósito no sea obvio para pruebas explícitas durante la Fase 4.
Manejo de P-headers específicos de Aura. Session Manager y Communication Manager producen comportamiento SIP con P-headers propietarios, particularidades de manejo de sesión y patrones de OPTIONS específicos de Avaya. El SBCE normaliza mucho de esto silenciosamente. El módulo de enrutamiento Ruby en ProSBC necesita reglas explícitas para el mismo comportamiento, y las pruebas de laboratorio contra una instancia real de Aura, no contra un terminal SIP genérico, es lo que saca a la luz estos problemas a tiempo para corregirlos.
Traspasos de cadenas de certificados TLS. Los SBCE y sus pares upstream a veces negocian cadenas de certificados que incluyen intermedios que el SBCE sirve automáticamente. Cuando el mismo certificado se traslada a ProSBC, la configuración de la cadena debe ser explícita. Pruebe mTLS para cualquier trunk de operador con TLS y para Teams Direct Routing en el laboratorio antes de confiar en él en producción.
Supuestos de licenciamiento agrupado. El agrupamiento 7:1 Standard-to-Advanced de Avaya significa que el equipo que ejecuta la migración a veces no tiene una imagen clara de cuáles llamadas estaban consumiendo sesiones Advanced en el SBCE. En ProSBC, donde cada sesión es la misma sesión a $1.40 por sesión por año, el modelo de planificación se convierte en un solo número en lugar de una proporción. Confirme la mezcla real de funciones “equivalentes a Advanced” en uso antes de dimensionar el reemplazo para que la conversación comparativa con finanzas se mantenga fundamentada.
Preguntas frecuentes
¿Cuánto tiempo toma típicamente una migración de Avaya SBCE?
De cuatro a ocho semanas desde la auditoría de la Fase 0 hasta la migración completa es el rango típico para una migración de un solo elemento. La Fase 0 y la Fase 1 (auditoría y mapeo) suelen tomar de una a dos semanas, la Fase 2 (construcción en laboratorio) lleva aproximadamente una semana, la Fase 3 (replicar la configuración completa) toma de dos a tres semanas dependiendo de la complejidad de los scripts SigMa, y la Fase 4 (ejecución en paralelo) toma de dos a cuatro semanas. La migración en sí es una sola ventana de mantenimiento. Los estados Avaya con múltiples elementos de SBCE escalan linealmente: cada par de SBCE que se reemplaza agrega su propio trabajo de Fase 3 y Fase 4.
¿ProSBC será interoperable con nuestro Avaya Aura, Session Manager y Communication Manager existentes?
Sí. ProSBC es un B2BUA en el borde de la red que maneja el comportamiento SIP del lado de Aura a través del mismo motor de manipulación SIP que usa para la normalización del lado del operador. Session Manager, Communication Manager, los planes de marcado y el resto del stack de Aura continúan funcionando tal como están. Este es un reemplazo de SBC, no un reemplazo de Aura, y el perímetro de la migración se detiene en el borde.
¿Necesitamos cambiar nuestros contratos de SIP trunk o la configuración del operador?
No. ProSBC funciona con cualquier proveedor de SIP trunk, y los contratos con el operador permanecen sin cambios. Los operadores continúan terminando trunks hacia cualquier dirección IP que el SBC les presente. Solo cambia el equipo en el medio, que es lo que hace que el alcance de la migración sea lo suficientemente pequeño para planificarlo y revertirlo limpiamente.
¿Qué sucede con nuestra configuración STIR/SHAKEN durante la migración?
ProSBC implementa la firma y verificación STIR/SHAKEN a través de su motor de enrutamiento Ruby, integrándose con proveedores externos de STI-AS (TransNexus ClearIP, Neustar o cualquier servicio de firma basado en HTTP). Durante la migración, el servicio de firma puede permanecer igual, o este puede ser el momento para evaluar un proveedor diferente. Los terminales de firma primarios y secundarios proporcionan redundancia, y un respaldo P-Identity-Bypass asegura que las llamadas no se caigan si el servicio de firma está brevemente no disponible. La atestación se convierte en una decisión por llamada en el routing script en lugar de una configuración por trunk.
¿ProSBC puede ejecutarse en el mismo hipervisor que usamos para el SBCE hoy?
El SBCE soporta VMware y plataformas de nube seleccionadas. ProSBC se ejecuta en VMware, KVM, Proxmox, AWS, Azure y bare metal. Si la implementación del SBCE está en VMware, AWS o Azure, ProSBC se ejecuta en la misma plataforma. KVM y Proxmox están disponibles como alternativas gratuitas para equipos que deseen reducir el licenciamiento de hipervisor en la misma migración. HA nativa 1+1 en Azure requiere configuración adicional en comparación con el comportamiento predeterminado en VMware y KVM, algo que vale la pena identificar durante la Fase 2 en lugar de descubrirlo durante la Fase 4.
¿Qué pasa si no tenemos experiencia interna en SBC para manejar la migración?
TelcoBridges ofrece un Servicio Gestionado que maneja la migración de principio a fin: auditoría de la Fase 0, mapeo de configuración, implementación de ProSBC, administración de la ejecución en paralelo y ejecución de la migración. El Servicio Gestionado incluye ProSBC+ con alta disponibilidad 1+1, soporte 24×7 y monitoreo continuo. Se aloja en infraestructura de TelcoBridges o en una plataforma elegida por el cliente (AWS, Azure, VMware o KVM), con el cliente reteniendo acceso completo. Para equipos sin ingenieros dedicados de SBC, este suele ser el camino correcto: el costo de una migración gestionada es una fracción del costo de contratar un especialista interno en SBC.
¿Cuál es el plan de reversión si algo sale mal después de la migración?
El SBCE permanece encendido y accesible durante al menos treinta días después de la migración. Si un problema que afecta al cliente surge en esa ventana, redirigir el tráfico de vuelta al SBCE es un cambio de red, no un proyecto de recuperación. El plan de cuatro fases está diseñado específicamente alrededor de este camino de reversión: el SBCE nunca se descomisiona hasta que ProSBC haya sido validado bajo tráfico de producción real durante varias semanas. La mayoría de las migraciones nunca necesitan la reversión, pero tenerla disponible es lo que hace que la ejecución en paralelo y la migración sean seguras de ejecutar.
Comience la migración de Avaya SBCE con un laboratorio, no con un compromiso
La forma de menor riesgo para evaluar si ProSBC se adapta a un entorno Avaya SBCE existente es implementar una instancia de ProLab y replicar un Server Configuration contra un operador real o un par real de Session Manager. La licencia de ProLab es permanentemente gratuita, permite tres sesiones concurrentes y se aprovisiona en aproximadamente veinte minutos. No se requiere contacto comercial para comenzar.
Para equipos que prefieren una evaluación guiada, el Servicio Gestionado cubre la migración completa: auditoría, mapeo, implementación, ejecución en paralelo, migración y operaciones continuas.
¿Comparando enfoques primero? Consulte Reemplazo de SBC de hardware por software para el caso más amplio de hardware a software.
¿Prefiere evaluar por su cuenta primero? Comience su prueba gratuita de 30 días.