Uno de los problemas de interoperabilidad SIP más persistentes en las redes modernas es el manejo confiable de respuestas provisionales, especialmente cuando se conectan despliegues SIP clásicos con entornos orientados a IMS. En redes con fuerte presencia IMS, el soporte de RFC 3262 se da por sentado: los campos 100rel, RSeq, RAck y el método PRACK dejan de ser opcionales y pasan a formar parte del establecimiento normal de llamadas. Del otro lado del enlace, sin embargo, muchos dispositivos SIP, aplicaciones adyacentes a SBC, PBX heredados o gateways SIP hacia la PSTN directamente no implementan respuestas provisionales confiables, o lo hacen de forma parcial. El resultado es conocido: un lado espera PRACK, el otro no sabe qué hacer con él, y el establecimiento de la llamada falla por razones que no tienen nada que ver con la lógica de servicio real. opensips

Con OpenSIPS 4.0 se introduce soporte nativo de interoperabilidad PRACK directamente en el módulo de diálogo, permitiendo a OpenSIPS actuar como puente activo para salvar estas brechas de capacidad. El soporte cubre tanto el lado UAC como el lado UAS: en modo UAC, OpenSIPS genera el PRACK hacia el lado downstream cuando este exige manejo confiable de provisionales; en modo UAS, OpenSIPS termina los PRACK entrantes y protege al lado remoto de tener que entender RFC 3262. opensips

La forma más sencilla de habilitar esta funcionalidad es el nuevo modo automático, en el cual OpenSIPS detecta respuestas provisionales confiables dentro de un diálogo y genera automáticamente el PRACK requerido en la pata correspondiente. La configuración se reduce a crear el diálogo con el flag "auto-prack" en la llamada a create_dialog(). OpenSIPS 4.0 agrega también control sobre la política de fallo: mediante el parámetro auto_prack_hangup_on_failure (por defecto en false) se puede decidir si un fallo de PRACK debe simplemente registrarse o debe resultar en la terminación activa del diálogo. opensips

Para quienes necesitan control fino sobre la señalización, existe el modo manual, que expone la lógica completa al scripting en opensips.cfg. En el lado UAC, basta con detectar una respuesta provisional confiable en un onreply_route y emitir el PRACK mediante dlg_send_sequential("PRACK", "callee"). En el lado UAS, OpenSIPS puede agregar la cabecera Require: 100rel, sintetizar el RSeq, validar el RAck y responder localmente con un 200 OK al PRACK recibido. Los bloques de construcción disponibles incluyen valores de diálogo, local_route, onreply_route, correlación de diálogos, cabeceras auxiliares para el manejo interno de transacciones, mi_script y lógica de t_reply() diferida. opensips

La historia de interoperabilidad no termina en PRACK. Otro punto de dolor frecuente en entornos SIP mixtos es el interworking de UPDATE en mid-dialog: los sistemas orientados a IMS suelen depender del método UPDATE para refrescos de SDP y cambios de sesión, mientras que otros extremos SIP o sistemas adyacentes a PSTN pueden no soportar UPDATE en absoluto, aunque sí sean capaces de manejar un re-INVITE clásico. Mediante lógica de routing consciente del diálogo, OpenSIPS puede detectar un UPDATE entrante en mid-dialog, conservar la transacción original y disparar un INVITE en la pata opuesta. Si ese re-INVITE tiene éxito, OpenSIPS responde con 200 OK al UPDATE original; si falla, rechaza el UPDATE pendiente e incluso puede terminar el diálogo si esa es la política de servicio deseada. El mecanismo consiste en capturar el UPDATE, generar la transacción INVITE saliente con dlg_send_sequential(), y transportar el identificador de la transacción original como cabecera auxiliar para su correlación posterior en un local_route. opensips

En conjunto, estas capacidades posicionan a OpenSIPS 4.0 como un nodo de interworking señalizante completo: capaz de hablar el dialecto RFC 3262 hacia un lado y ocultar esa complejidad hacia el otro, o de traducir UPDATE en re-INVITE de forma transparente. Para entornos donde coexisten núcleos IMS, SBCs de acceso, servidores de aplicaciones y endpoints SIP de capacidades reducidas, esto deja de ser un parche de scripting artesanal y pasa a ser infraestructura de primera clase dentro del propio motor de diálogos.

¿Qué es IMS?

IMS (IP Multimedia Subsystem) es una arquitectura estandarizada por el 3GPP para la provisión de servicios multimedia sobre redes IP, originalmente diseñada para redes móviles pero adoptada también en entornos fijos y convergentes. Su núcleo de señalización está basado en SIP, pero con un perfil estricto y obligatorio de extensiones que en el mundo SIP genérico son opcionales: entre ellas, precisamente, RFC 3262 y el uso de PRACK para garantizar la entrega confiable de respuestas provisionales. Operadores de telecomunicaciones, redes VoLTE, RCS y plataformas de voz sobre 4G/5G son los contextos más habituales donde IMS aparece en producción, lo que explica por qué la interoperabilidad con entornos SIP clásicos —menos estrictos en cuanto a extensiones obligatorias— es un problema recurrente y no trivial.