Resumen

  • La RFC 3057 separó la terminación física del canal D RDSI del lugar donde se procesaba Q.931: la pasarela de señalización terminaba Q.921 e IUA transportaba las primitivas de esa frontera hasta un servidor de aplicaciones mediante SCTP.
  • El cambio entre procesos ASP podía redirigir la señalización, pero recuperar el transporte no recuperaba el estado de una llamada. La RFC 4233, sucesora de la RFC 3057, dice que las llamadas en transición pueden fallar si los procesos de aplicación no comparten su estado por un mecanismo externo a IUA.

Se trasladó la capa superior, no el cable

En una arquitectura RDSI tradicional, el canal D lleva la señalización que permite a los terminales establecer y gestionar llamadas conmutadas por circuitos. Q.921 proporciona el servicio de enlace de datos; Q.931 y QSIG se apoyan en él. Publicada en febrero de 2001, la RFC 3057 aprovechó esa frontera para separar dónde se ejecutaba cada función.

La pasarela de señalización (SG) recibía señalización desde una interfaz RDSI estándar y terminaba Q.921. En el lado IP, un controlador de pasarela de medios (MGC) alojaba la capa Q.931 par y el procesamiento de llamadas. Entre ambos, la capa de adaptación de usuarios de Q.921 —IUA— transportaba las primitivas de esa frontera mediante SCTP. No convertía el bucle de abonado, el canal D ni cada circuito en un objeto IP: la SG conservaba la interfaz física y el comportamiento local de Q.921.

La distinción era operativa. La primitiva DL-DATA entrega un mensaje Q.931; establecimiento, liberación y datos no confirmados representan resultados distintos del enlace. Por eso IUA debía conservar la identidad de la interfaz y el sentido de cada primitiva. El controlador remoto podía procesar mensajes de llamada sin fingir que había asumido el propio canal D.

Un identificador de interfaz, una correspondencia local

El identificador de interfaz asociaba un mensaje con la interfaz física correspondiente de la SG. Podía representarse como entero o texto, pero su significado era local: la pasarela y su servidor de aplicaciones acordaban el valor. La RFC no lo convertía en un identificador común entre pasarelas. Lo que parecía un nombre de red era, en realidad, una clave de unión local entre contextos de señalización.

La SG asociaba ese identificador con un servidor de aplicaciones y con un proceso de servidor de aplicaciones (ASP) activo. El servidor podía ser un servicio lógico compuesto por una lista ordenada de ASP, como un controlador principal y uno de respaldo. La pasarela debía saber qué proceso recibía el tráfico de cada interfaz; esa asignación podía cambiar durante una conmutación por error.

La RFC 3057 recomendó SCTP y un flujo SCTP separado para cada canal D, a fin de reducir esperas y almacenamiento intermedio entre canales independientes. El flujo pertenecía al transporte; el identificador seguía indicando a qué interfaz física correspondía el mensaje. El estado de la asociación, la secuencia del flujo, la correspondencia local y el estado activo del ASP estaban relacionados, pero ninguno sustituía a los demás.

Conmutar el proceso no copia el historial de la llamada

El diseño permitía elegir el nivel de redundancia. Un esquema 1+0 no tenía ASP redundantes. En 1+1 activo/en espera, un proceso atendía el tráfico y otro podía reemplazarlo. El modelo general n+k describía n procesos necesarios para la carga y k procesos de reserva. Los mensajes IUA permitían a la SG y a los ASP intercambiar estados y decidir dónde dirigir la señalización.

Sin embargo, mantener una asociación con el proceso de respaldo no demuestra que este conozca el estado de una llamada que ya está en curso. La RFC 4233, que reemplazó a la RFC 3057 en 2006, lo aclara: en redes de nivel operador, la falla de un ASP NO DEBERÍA liberar llamadas estables; alcanzar ese objetivo puede requerir que los ASP compartan el estado de llamada. Las llamadas en transición PUEDEN fallar. La memoria compartida o un protocolo ASP-a-ASP podrían reducir el riesgo, pero ese protocolo quedaba fuera del alcance de IUA.

No era un defecto oculto de SCTP. SCTP puede informar el estado de una asociación, secuenciar mensajes dentro de cada flujo y admitir multihoming. Son propiedades del transporte; no le dicen al controlador de respaldo qué decisiones sobre la llamada ya se tomaron, qué mensajes llegaron a la otra parte ni si la llamada estaba estable o a mitad de una transición. IUA podía cambiar la ruta de señalización; la continuidad de la aplicación seguía siendo otra responsabilidad.

Qué cambió la norma y qué no demuestra

La RFC 3057 incorporó a SIGTRAN una adaptación definida para los usuarios de Q.921. Hizo posible distribuir el procesamiento de llamadas a través de un enlace IP sin perder la frontera estándar con la red de circuitos. En 2006, la RFC 4233 la reemplazó y refinó la misma adaptación. Esa evolución documental no demuestra qué operadores la desplegaron, qué equipos compraron ni cuántas llamadas sobrevivieron a una falla real.

La lección de ingeniería es más concreta que «la telefonía pasó a IP». Una frontera de servicio puede trasladarse aunque la interfaz física siga en otro sitio. La terminación del enlace, la adaptación de primitivas, la asociación de transporte, el proceso receptor y el estado que hace coherente una llamada requieren pruebas distintas. Una asociación SCTP restablecida o un ASP activo no certifican que una llamada haya concluido.

Fuentes