Migrar desde AudioCodes Mediant: guía de migración para proveedores de servicios
Las implementaciones de AudioCodes Mediant funcionan. Ese rara vez es el problema. La pregunta sobre la migración surge cuando algo más cambia: un Mediant 4000 o 9000 recibe un aviso de fin de vida, una política de adquisición exclusivamente OPEX llega al escritorio, la unidad de negocio del centro de contacto pregunta por qué el proveedor del SBC también está registrando a sus clientes empresariales a través de Operator Connect, o la partida de transcodificación en la cotización de renovación deja de tener sentido. Ninguno de esos detonantes requiere descartar el resto de la pila de AudioCodes. El controlador de borde de sesión (SBC) es un componente individual en el borde, y puede reemplazarse por separado.
Esta página es la versión operativa de la comparativa con la alternativa a AudioCodes. Asume que la decisión de evaluar un reemplazo ya se tomó y recorre lo que realmente implica una migración de AudioCodes Mediant a ProSBC: cómo auditar la configuración existente del Mediant, cómo se traducen los objetos de configuración de AudioCodes a los de ProSBC, cómo ejecutar ambos SBC en paralelo de forma segura y cómo planificar un corte con una ruta real de reversión.
Qué motiva una migración de AudioCodes Mediant 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 a un entorno determinado define cómo se dimensiona el proyecto.
El fin de vida del hardware es el detonante más predecible. AudioCodes ha publicado avisos de fin de venta y fin de soporte para chasis Mediant más antiguos, incluyendo algunas revisiones de CPU de la serie 4000 y tarjetas anteriores de la serie 1000. Cuando el dispositivo alcanza el fin de soporte, la elección es una actualización tipo forklift con el mismo proveedor o una migración limpia a un SBC por software que se ejecute en hardware genérico.
La política de adquisición OPEX es el segundo. Proveedores de servicios y operadores de centros de contacto que han trasladado todas las demás categorías de infraestructura a facturación por suscripción encuentran cada vez más un compromiso CapEx con su SBC. AudioCodes ofrece precios por suscripción y por uso, pero el ciclo de negociación y la ausencia de tarifas por sesión publicadas dificultan modelar márgenes antes de recibir una cotización.
El conflicto de canal importa específicamente a los MSP y a los operadores de centros de llamadas que revenden llamadas de Teams. AudioCodes es Microsoft Premier Partner y proveedor de Operator Connect, lo que significa que el mismo proveedor que suministra el SBC también vende servicios de llamadas de Teams a los clientes potenciales del MSP. Mover el SBC a un proveedor de infraestructura que no tiene un programa de Operator Connect elimina ese conflicto a nivel tecnológico.
La economía de la transcodificación es el cuarto, y tiende a surgir tarde. El licenciamiento de transcodificación de AudioCodes es por canal y por códec, y a escala la partida en una cotización de renovación se vuelve significativa. Los proveedores de servicios que necesitan conversión de Opus a G.711 para tráfico móvil y WebRTC son quienes más lo sienten.
Si el detonante aplica a un solo Mediant en un parque multi-SBC, la migración puede limitarse a ese único elemento. La PBX, los operadores, el plan de marcado y el resto de la flota Mediant permanecen donde están.
Fase 0: inventario de lo que hay en el Mediant hoy
Toda migración exitosa de SBC comienza con una auditoría honesta de la configuración actual. Omitir este paso es la causa más común de sorpresas durante el corte. El resultado no es una captura de pantalla de la interfaz web de AudioCodes, sino una lista estructurada que se traduce limpiamente a lo que el SBC de reemplazo necesita como configuración.
Extraiga lo siguiente del Mediant 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. La mayoría de las implementaciones de Mediant operan muy por debajo de su capacidad nominal, y el SBC de reemplazo debe dimensionarse según el uso real. ProSBC escala hasta 60 000 sesiones por servidor, por lo que la pregunta práctica de dimensionamiento suele ser el licenciamiento, no el hardware.
El inventario de IP Groups. Liste cada IP Group en el Mediant: troncales de operador, la PBX, cualquier tenant de Teams Direct Routing u Operator Connect, cualquier plataforma de grabación o análisis SIP, y cualquier endpoint de prueba interno. Para cada uno, capture el transporte (UDP, TCP, TLS), la dirección proxy, el IP Profile asociado y el SRD al que pertenece.
El catálogo de IP Profiles. Documente las preferencias de códec, los requisitos de transcodificación, la política de SRTP y TLS, los intervalos de keep-alive OPTIONS, el manejo de early-media y cualquier particularidad por lado para cada perfil. Una implementación real del Mediant generalmente tiene menos perfiles distintos que IP Groups, y un mismo perfil suele reutilizarse entre múltiples pares.
Manipulation Sets y tablas de enrutamiento IP-to-IP. Exporte cada regla de Manipulation Set y cada entrada de enrutamiento. Esta es la parte de la configuración que contiene la mayor cantidad de lógica de negocio: reescrituras de P-Asserted-Identity para operadores específicos, normalización del encabezado From, transformaciones del plan de marcado, etiquetado de atestación para STIR/SHAKEN, entre otros. Todo lo que no sobreviva a la migración se pierde durante el corte.
Certificados, ACLs y política de seguridad. Capture cada certificado TLS y su fecha de expiración, cada lista de permitidos o denegados por IP, cada regla de clasificación 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.
Integraciones de STIR/SHAKEN y fraude. Si el Mediant firma o verifica mediante el STIR/SHAKEN integrado de AudioCodes, documente el servicio de firma, el certificado y la política de atestación. Lo mismo aplica para cualquier integración antifraude que se conecte al SBC. Es muy probable que estas piezas necesiten una decisión arquitectónica diferente en ProSBC, donde la firma y el fraude son funciones de primera clase del motor de enrutamiento en lugar de interruptores de configuración.
Fase 1: correspondencia de objetos AudioCodes Mediant con objetos ProSBC
La mayor fuente de fricción en una migración no es la red, sino el modelo de configuración. AudioCodes 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 de la correspondencia antes de iniciar la construcción en laboratorio.
La siguiente tabla cubre los objetos que aparecen en toda implementación del Mediant. La correspondencia 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 AudioCodes Mediant | Equivalente en ProSBC | Qué cambia en la práctica |
|---|---|---|
| IP Group | NAP (Network Access Point) | Correspondencia uno a uno. El NAP incluye transporte, proxy, lista de códecs, configuración de SRTP y ACL que el Mediant divide entre el IP Group y su IP Profile asociado. |
| SRD (SIP Realm Definition) | Agrupación de NAPs en la lógica de enrutamiento | ProSBC no tiene un contenedor de dominio separado. La segregación por tenant o unidad de negocio se maneja mediante nomenclatura de NAPs, lógica de routing script y ACLs en lugar de un objeto de configuración padre. |
| IP Profile | Campos de configuración del NAP y SIP Profiles | El comportamiento SIP y de medios por lado se integra en el NAP o en los Profiles. Todo lo que esté fuera de la configuración del NAP o de los Profiles en ProSBC es común a todos los NAP y troncales SIP. |
| Media Realm | Vinculación de interfaz de medios del NAP | La selección de interfaz de medios se configura directamente en el NAP. No hay un objeto de dominio separado que mantener. |
| SIP Interface | Transporte e interfaz de señalización del NAP | Integrado en el NAP. ProSBC trata la interfaz de señalización como una propiedad del NAP, no como un recurso compartido. |
| Message Manipulation Set | Routing Script (módulo Ruby) | El cambio conceptual más importante. Las listas estáticas de reglas se convierten en código procedural que se ejecuta por llamada. Los ingenieros obtienen consultas HTTP externas, lógica condicional sobre cualquier parámetro de llamada y la capacidad de integrar fraude, LNP y STIR/SHAKEN en la decisión de enrutamiento misma. |
| Tabla de enrutamiento IP-to-IP | Tabla de enrutamiento más Routing Script | Las entradas de enrutamiento simples se traducen directamente. El enrutamiento condicional (conmutación por error entre operadores, enrutamiento por horario, menor costo) se implementa en el Routing Script en lugar de filas adicionales en la tabla. |
| Classification Rules | Coincidencia de IP de origen del NAP más ACLs | La clasificación entrante se resuelve comparando la IP de origen y las características SIP con la definición del NAP. |
| Coder Group | Lista de códecs del Profile | Los Profiles contienen la lista de códecs, no los NAP. Un solo Profile puede asignarse a múltiples NAPs, pero cada NAP utiliza un solo Profile. |
| TLS Context | 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 sigue el mismo patrón que en el Mediant. |
| STIR/SHAKEN (integrado) | Módulo de firma en Routing Script | El STIR/SHAKEN de ProSBC se ejecuta a través del motor de enrutamiento y se integra con proveedores externos STI-AS (TransNexus ClearIP, Neustar o cualquier servicio de firma basado en HTTP) con endpoints primario y secundario y fallback P-Identity-Bypass. La atestación se convierte en una decisión por llamada en lugar de una configuración por troncal. |
| OVOC / Routing Manager | Portal web de ProSBC más API | La gestión de panel único se consolida en el portal web de ProSBC. La orquestación multielemento se maneja mediante la API en lugar de un producto de gestión separado. |
La correspondencia no es la migración. Es el contrato sobre el cual trabajan las dos fases siguientes.
Fases 2-4: el plan de migración
El plan a continuación asume un solo Mediant reemplazado por una sola instancia de ProSBC. Las implementaciones multielemento del Mediant siguen el mismo patrón elemento por elemento. Toda la secuencia suele abarcar de cuatro a ocho semanas desde el laboratorio hasta el corte, dependiendo de cuántos operadores e integraciones con PBX distintas estén dentro del alcance.
Fase 2: construcción en laboratorio
Levante una instancia de ProLab en el mismo segmento de red que el Mediant. La licencia de ProLab es permanentemente gratuita, ofrece tres sesiones concurrentes y se aprovisiona en aproximadamente veinte minutos. Utilice el laboratorio para replicar un IP Group del lado del operador, un IP Group del lado de la PBX y cualquier regla de Manipulation Set asociada. El objetivo de la fase de laboratorio es validar la correspondencia de la tabla de configuración anterior contra el dialecto específico de SIP que envía el operador actual, no recrear la configuración completa de producción.
Si Teams Direct Routing está dentro del alcance, pruebe mTLS, SRTP y el flujo OPTIONS de SBC a Teams contra un tenant de prueba. La certificación de Teams importa como requisito de adquisición en algunas organizaciones: ProSBC permite Teams Direct Routing y está implementado en entornos de producción de Teams DR, pero no ha obtenido la certificación formal de Microsoft. Si existe un requisito estricto de certificación, la lista publicada de Microsoft es la fuente de verdad.
Fase 3: replicar
Una vez que la construcción en laboratorio valida la correspondencia, construya la configuración completa de producción en la instancia de ProSBC. Replique cada NAP a partir del inventario de IP Groups, traslade las listas de códecs de los IP Profiles y convierta los Manipulation Sets en lógica de módulos Ruby. Aquí es donde se invierte el tiempo, y es la fase que más se beneficia de un inventario limpio en la Fase 0.
Cargue los certificados TLS y configure los ajustes TLS a nivel de NAP. Si se requiere TLS y SRTP de extremo a extremo, valide los conjuntos de cifrado y los crypto suites de SRTP contra lo que los operadores y la PBX realmente negocian, no lo que la configuración del Mediant aparenta indicar. Las discrepancias entre la política configurada y el tráfico observado son la segunda causa más común de sorpresas durante el corte.
Si la firma STIR/SHAKEN está dentro del alcance, apunte el routing script al mismo servicio externo de firma que utiliza el Mediant, o a un proveedor diferente si la migración es el momento adecuado para cambiar. Configure URLs de firma primaria y secundaria y confirme el comportamiento de fallback P-Identity-Bypass.
Fase 4: ejecución en paralelo
Mantenga el Mediant en producción. Enrute un troncal de operador a través de ProSBC mientras todos los demás troncales permanecen en el Mediant. De dos a cuatro semanas de ejecución en paralelo suelen detectar 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 horas pico, un intervalo OPTIONS que difiere del valor documentado, o un código de respuesta SIP específico que el Mediant maneja de forma silenciosa y ProSBC necesita una regla explícita.
Compare las tasas de completación de llamadas, puntuaciones MOS, precisión de CDR y niveles de atestación STIR/SHAKEN entre las dos rutas durante el periodo de ejecución en paralelo. Si una regla de enrutamiento del Mediant resulta estar haciendo trabajo que nadie documentó, encontrarla con el cinco por ciento del tráfico es mucho mejor que encontrarla con el cien por ciento.
Corte
Programe el corte durante una ventana de mantenimiento con el Mediant encendido y operativo. Mueva los troncales de operador restantes uno por uno, validando cada uno antes de mover el siguiente. Actualice los registros DNS y cualquier referencia de enrutamiento upstream para apuntar al ProSBC.
Deje el Mediant encendido y accesible durante al menos treinta días. Esta es la ruta de reversión. Si surge un problema que afecte a los clientes después del corte, redirigir el tráfico de vuelta al Mediant es un cambio de red, no un proyecto de recuperación. Una vez que pasa la ventana de validación, decomisione el chasis del Mediant o la instancia virtual y cancele la partida de soporte.
Validación posterior al corte
Las primeras setenta y dos horas después del corte son la ventana de validación de mayor rendimiento. Tres verificaciones son las más importantes.
Conciliación de CDR cubre si los registros de llamadas en el nuevo SBC coinciden con el volumen y la distribución 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 Mediant y los primeros tres días en ProSBC. Una divergencia generalmente apunta a una regla de enrutamiento que no sobrevivió a la correspondencia, más que a un problema de red.
Validación de umbrales de fraude importa específicamente porque las reglas de detección de fraude telefónico ajustadas al comportamiento del Mediant pueden dispararse en exceso o pasar por alto patrones en el nuevo SBC. Si la puntuación de fraude en tiempo real está integrada a través de TransNexus ClearIP, SecureLogix o YouMail, observe la primera semana de decisiones con atención y ajuste los umbrales según los falsos positivos observados.
Continuidad del monitoreo cubre cualquier telemetría que fluía desde el Mediant: traps SNMP, feeds de syslog, flujos de CDR por RADIUS o una integración con el producto de gestión de elementos del Mediant. ProSBC expone métricas por NAP y por llamada que pueden dirigirse a Datadog, Prometheus, un SIEM o un servicio de monitoreo gestionado. Confirme que los dashboards están leyendo el nuevo feed antes de declarar el corte como completo.
Errores comunes en la migración
En migraciones de MSP, ISP y centros de contacto, cuatro errores aparecen con más frecuencia que cualquier otro. Ninguno es una sorpresa técnica por sí solo, pero cada uno tiende a costar uno o dos días si no se anticipa.
Lógica no documentada en Manipulation Sets. Las implementaciones del Mediant acumulan reglas de reescritura de encabezados a lo largo de los años, frecuentemente agregadas por personas que ya no están en el equipo. Tratar las reglas existentes como definitivas sin entender por qué existe cada una es la forma más rápida de romper un operador específico durante el corte. Lo correcto es revisar cada regla de Manipulation Set durante la Fase 0 y marcar las que no tienen un propósito obvio para pruebas explícitas durante la Fase 4.
Suposiciones de transcodificación. Los Mediant de AudioCodes realizan transcodificación asistida por hardware para un amplio conjunto de códecs, incluyendo Opus, G.729 y AMR. La transcodificación por software de ProSBC actualmente cubre G.711 ALAW y ULAW; la transcodificación de códecs adicionales está en la hoja de ruta pero requiere confirmación cuidadosa antes de una migración que dependa de ella. El tráfico móvil y WebRTC que actualmente depende de la transcodificación del Mediant necesita un plan confirmado, no una suposición.
Transferencia de cadenas de certificados TLS. Los Mediant y sus pares upstream a veces negocian cadenas de certificados que incluyen intermediarios que el Mediant sirve automáticamente. Cuando el mismo certificado se traslada a ProSBC, la configuración de la cadena debe ser explícita. Pruebe mTLS para Teams Direct Routing y cualquier troncal de operador con TLS en el laboratorio antes de depender de ello en producción.
Compatibilidad de hiperplataforma para HA en Azure. ProSBC se ejecuta en VMware, KVM, Proxmox, AWS, Azure y bare metal. La HA nativa 1+1 en Azure requiere configuración adicional en comparación con el comportamiento predeterminado en VMware o KVM. Si el Mediant existente se ejecuta en Azure con HA, plantee ese requisito durante la Fase 2 en lugar de descubrirlo durante la Fase 4.
Preguntas frecuentes
¿Cuánto tiempo toma típicamente una migración de AudioCodes Mediant?
De cuatro a ocho semanas desde la auditoría de Fase 0 hasta el corte completo es el rango típico para una migración de un solo elemento. La Fase 0 y la Fase 1 (auditoría y correspondencia) suelen tomar de una a dos semanas, la Fase 2 (construcción en laboratorio) toma aproximadamente una semana, la Fase 3 (replicar la configuración completa) lleva de dos a tres semanas dependiendo de la complejidad de los Manipulation Sets, y la Fase 4 (ejecución en paralelo) toma de dos a cuatro semanas. El corte en sí es una única ventana de mantenimiento. Las implementaciones multielemento escalan linealmente: cada Mediant que se reemplaza agrega su propio trabajo de Fase 3 y Fase 4.
¿Necesitamos cambiar nuestra PBX, plan de marcado o contratos con operadores para migrar desde el Mediant?
No. El SBC se ubica en el borde entre los operadores y la infraestructura de voz interna, y reemplazarlo no requiere cambios en la PBX, el plan de marcado ni los contratos de troncales SIP con los operadores. La PBX continúa enviando SIP a la dirección IP que el SBC presenta, y los operadores continúan terminando troncales a la dirección IP que el SBC les presenta. Solo cambia el equipo en el medio.
¿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 STI-AS (TransNexus ClearIP, Neustar o cualquier servicio de firma basado en HTTP) en lugar de un módulo de firma integrado. Durante la migración, el servicio de firma puede permanecer igual, o este puede ser el momento para evaluar un proveedor diferente. Los endpoints de firma primario y secundario proporcionan redundancia, y un fallback P-Identity-Bypass asegura que las llamadas no se caigan si el servicio de firma no está disponible brevemente. La atestación se convierte en una decisión por llamada en el routing script en lugar de una configuración por troncal.
¿Puede ProSBC ejecutarse en el mismo hipervisor que usamos para Mediant VE?
Mediant VE es compatible con VMware, KVM, Hyper-V, OpenStack, AWS, Azure, GCP y entornos de contenedores. ProSBC se ejecuta en VMware, KVM, Proxmox, AWS, Azure y bare metal. Si la implementación existente del Mediant VE está en VMware, KVM, AWS o Azure, ProSBC se ejecuta en la misma plataforma. Las implementaciones en Hyper-V, GCP y contenedores no son compatibles actualmente con ProSBC y necesitarían una decisión de plataforma antes de la migración. La HA nativa en Azure también requiere configuración adicional en ProSBC en comparación con el comportamiento predeterminado en VMware y KVM.
¿Qué pasa si no tenemos experiencia interna en SBC para manejar la migración?
TelcoBridges ofrece un servicio gestionado que se encarga de la migración de principio a fin: auditoría de Fase 0, correspondencia de configuración, implementación de ProSBC, gestión de la ejecución en paralelo y ejecución del corte. 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. Para equipos sin ingenieros de SBC dedicados, 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 del corte?
El Mediant permanece encendido y accesible durante al menos treinta días después del corte. Si surge un problema que afecte a los clientes en esa ventana, redirigir el tráfico de vuelta al Mediant es un cambio de red, no un proyecto de recuperación. El plan de cuatro fases está diseñado específicamente en torno a esta ruta de reversión: el Mediant nunca se decomisiona hasta que ProSBC haya sido validado bajo tráfico real de producción durante varias semanas. La mayoría de las migraciones nunca necesitan la reversión, pero tenerla en su lugar es lo que hace que la ejecución en paralelo y el corte sean seguros de ejecutar.
Comience la migración de AudioCodes Mediant con un laboratorio, no con un compromiso
La forma de menor riesgo para evaluar si ProSBC se adapta a un entorno AudioCodes Mediant existente es implementar una instancia de ProLab y replicar un IP Group contra un operador real. La licencia de ProLab es permanentemente gratuita, ofrece tres sesiones concurrentes y se aprovisiona en aproximadamente veinte minutos. No se requiere interacción comercial para comenzar.
Para equipos que prefieren una evaluación guiada, el servicio gestionado cubre la migración completa: auditoría, correspondencia, implementación, ejecución en paralelo, corte y operaciones continuas.
¿Comparando proveedores primero? Vea la comparativa completa de ProSBC vs. AudioCodes o Reemplazar un SBC de hardware por software.