IMS Application Server: Donde reside la lógica de servicio en el núcleo IMS

Un núcleo IMS puede registrar a un suscriptor, autenticarlo y enrutar una sesión hacia su destino sin entregar jamás una sola funcionalidad. Desvío de llamadas, retención de llamadas, conferencia multiparte, SMS sobre IP, el traspaso que mantiene viva una llamada móvil cuando pierde cobertura LTE: nada de eso reside en la capa de enrutamiento. Reside en el Application Server. El S-CSCF sabe cómo alcanzar el Application Server adecuado y cuándo invocarlo, pero la lógica de servicio en sí se encuentra un plano más arriba, en software diseñado exactamente para esa función.

Este artículo se centra específicamente en el Application Server (AS): qué es, la interfaz ISC que lo conecta al núcleo IMS, cómo el S-CSCF decide entregar una sesión al AS, los modos en que puede operar y los Application Servers comunes que un ingeniero de voz realmente encuentra en producción. Si desea comprender primero la arquitectura IMS completa, nuestra guía sobre qué es IMS cubre el plano de control y las pasarelas. Aquí profundizamos en el elemento donde nacen las funcionalidades. TelcoBridges lleva más de veinte años trabajando en la frontera donde este tráfico se encuentra con el resto del mundo.

Qué es un IMS Application Server

IMS se suele representar como tres planos horizontales: un plano de acceso donde se conecta el dispositivo, un plano de control que registra usuarios y enruta sesiones, y un plano de aplicación donde se ejecuta la lógica de servicio. El Application Server reside en ese plano superior. Mientras los elementos del plano de control se ocupan de alcanzar al suscriptor correcto, el AS se ocupa de lo que sucede una vez que la sesión está en curso: si debe desviarla, bifurcarla a varios destinos, reproducir un anuncio, retenerla o generar un mensaje por cuenta propia.

Un AS es una entidad SIP especializada. Habla el mismo Session Initiation Protocol que el resto del núcleo, definido en RFC 3261, y desde el punto de vista del S-CSCF es simplemente otro destino SIP al que pueden enrutarse las sesiones. Los proveedores venden productos de Application Server, y cada uno mapea el comportamiento estandarizado a su propio software, pero la arquitectura de referencia y la interfaz con el núcleo se mantienen consistentes. Esto es lo que permite a un operador adquirir un Application Server de telefonía de un proveedor y un Application Server de mensajería de otro, y que ambos funcionen detrás del mismo S-CSCF. Si la capa de protocolo no le resulta familiar, nuestra introducción a los fundamentos de señalización SIP cubre los métodos y respuestas sobre los que se construye todo lo que se describe aquí.

La arquitectura está definida por 3GPP, principalmente en TS 23.228 para el IMS en general y en TS 23.218 para la interacción entre el AS y el núcleo. El punto clave a retener es la separación de responsabilidades: el núcleo enruta, el AS entrega funcionalidades, y una única interfaz SIP une a ambos.

La interfaz ISC: Cómo el núcleo alcanza al AS

El enlace entre el S-CSCF y un Application Server es la interfaz ISC, abreviatura de IP Multimedia Service Control. No es un protocolo nuevo. ISC es SIP, utilizado como un punto de referencia con comportamiento definido, razón por la cual un AS puede ser tratado como un servidor SIP ordinario por el resto del núcleo.

Cuando el S-CSCF determina que una sesión necesita lógica de servicio, enruta la solicitud al AS a través de ISC, el AS realiza su trabajo y, en la mayoría de los casos, devuelve la sesión al S-CSCF para que continúe hacia su destino. La sesión sale de la capa de enrutamiento, pasa por la capa de funcionalidades y regresa. Este ida y vuelta es lo que hace que las funcionalidades sean componibles: el S-CSCF puede enviar una única sesión a través de varios Application Servers en secuencia, cada uno añadiendo su propio comportamiento, sin que ninguno necesite conocer a los demás.

Dado que ISC es SIP, el AS ve la misma línea de solicitud, encabezados y cuerpo SDP que viajan en cualquier troncal. Si desea una vista a nivel de campo de lo que contienen estos mensajes, nuestra referencia sobre el flujo de llamada SIP paso a paso recorre cada uno de ellos. La diferencia en IMS no son los mensajes en sí, sino la orquestación que los rodea, y esa orquestación es impulsada por el siguiente componente.

Cómo el S-CSCF decide invocar un AS

El S-CSCF no entrega cada sesión a cada Application Server. Consulta un conjunto de reglas llamadas Initial Filter Criteria, los iFC, que residen en el perfil de servicio del suscriptor. Ese perfil se almacena en el Home Subscriber Server (HSS) y se descarga al S-CSCF cuando el usuario se registra, de modo que cuando llega cualquier sesión, el núcleo ya conoce los derechos de funcionalidades del suscriptor.

Cada entrada en el iFC asocia un disparador con un destino. El disparador se construye a partir de uno o más Service Point Triggers, los SPT, cada uno de los cuales evalúa algo sobre la solicitud: el método SIP, la dirección de la sesión, la presencia o valor de un encabezado, o una línea en el SDP. Cuando una solicitud coincide, el S-CSCF la enruta a través de ISC al Application Server indicado en esa entrada. Las entradas tienen una prioridad, por lo que el S-CSCF las evalúa en orden y puede encadenar varios Application Servers en una misma sesión, cada uno invocado cuando se activa su propio disparador.

Un Application Server a menudo necesita más información sobre el suscriptor de la que lleva una sola solicitud SIP. Para eso se comunica directamente con el HSS a través de la interfaz Sh, un punto de referencia Diameter que utiliza para leer y escribir los datos de servicio de los que depende una funcionalidad, como un número de desvío o una lista de presencia. La división se mantiene limpia: el iFC decide si invocar al AS, ISC transporta la sesión hasta él, y Sh proporciona los datos del suscriptor sobre los que opera el servicio.

Los modos en que puede operar un Application Server

3GPP TS 23.218 define cómo se comporta un Application Server como entidad SIP, y el comportamiento no es un rol fijo único. Dependiendo de la funcionalidad que esté entregando, un AS actúa en uno de varios modos en la interfaz ISC.

Como agente de usuario terminal el AS es el punto final de la sesión. Un servidor de correo de voz que responde una llamada que el suscriptor no atendió actúa de esta manera, terminando la sesión en lugar de pasarla. Como agente de usuario originante el AS crea una sesión propia, que es como un servidor genera una llamada de notificación o envía un mensaje que ningún suscriptor inició. Como SIP proxy el AS observa y reenvía la solicitud con cambios menores, adecuado para registro, filtrado o decisiones de enrutamiento ligeras donde la sesión no se está reconfigurando.

El modo más capaz es el back-to-back user agent (B2BUA), donde el AS termina el tramo entrante y origina uno nuevo, otorgándole control total de la sesión. El control de llamadas de terceros depende de este modo: funcionalidades como la transferencia de llamada, conferencia y desvío complejo necesitan que el AS manipule ambos lados de una llamada, algo que un proxy no puede hacer. La distinción entre un proxy de reenvío y un B2BUA completo es la misma que separa a un enrutador ligero de un verdadero controlador de sesiones, y nuestro artículo explicativo sobre qué es un SIP proxy versus un B2BUA cubre exactamente por qué la diferencia importa. Un AS también puede actuar como servidor de redirección SIP, indicándole al núcleo adónde enviar la sesión en lugar de transportarla.

Application Servers comunes y sus funciones

Los estándares dejan al AS deliberadamente genérico para que cualquier servicio pueda construirse sobre él, pero un puñado de Application Servers aparecen en casi todas las redes de operadores, cada uno con una función reconocible.

El MMTel AS, para telefonía multimedia, es el que la mayoría de las sesiones tocan. Entrega los servicios suplementarios que los suscriptores esperan de una línea telefónica: retención y reanudación de llamada, desvío de llamada en sus diversas variantes, bloqueo de llamadas, conferencia multiparte y los servicios de identidad que presentan o restringen el número del llamante. Cuando un suscriptor VoLTE desvía una llamada o se une a una conferencia, el MMTel AS es el elemento que lo hace posible.

El SCC AS, para centralización y continuidad de servicio, existe para mantener vivas las sesiones a través de fronteras. Su función más conocida es SRVCC, continuidad de voz de radio única, que transfiere una llamada VoLTE en curso a una red de conmutación de circuitos cuando el suscriptor sale de la cobertura LTE. Para lograrlo, el SCC AS ancla la sesión de modo que exista un punto fijo de control para la transferencia, lo cual solo es posible porque se encuentra en la ruta como B2BUA.

El IP-SM-GW, el IP Short Message Gateway, transporta SMS sobre la red IMS. Interconecta mensajes cortos entre el dominio IP y la infraestructura SMS heredada, de modo que un mensaje enviado desde un terminal VoLTE llegue a un suscriptor en una red más antigua, y viceversa. La mensajería y los servicios más avanzados se construyen sobre el mismo patrón: un servidor de presencia rastrea quién está disponible, y un Application Server de RCS entrega los servicios de comunicación enriquecida que extienden la mensajería simple. Si está evaluando el aspecto de mensajería del IMS, nuestra comparación de RCS versus SMS cubre dónde encaja cada uno.

Más allá de estos, los operadores ejecutan Application Servers para todo, desde tonos de ringback hasta grabación regulatoria. La estructura es siempre la misma: una entidad SIP que el S-CSCF invoca mediante iFC, comunicándose con el HSS a través de Sh para obtener los datos del suscriptor que la funcionalidad necesite.

Third-Party Registration: Cómo el AS sabe que usted está en línea

Una funcionalidad como el desvío de llamadas o la presencia solo es útil si el Application Server sabe si el suscriptor está registrado. El AS no ve el REGISTER original, porque este viaja entre el dispositivo y el S-CSCF, por lo que IMS utiliza un mecanismo llamado third-party registration para cerrar esa brecha.

Cuando un suscriptor se registra y el S-CSCF carga su perfil de servicio, el iFC puede incluir un disparador que se activa con el propio REGISTER. Cuando eso ocurre, el S-CSCF envía un REGISTER separado al Application Server indicado en nombre del suscriptor. Ese REGISTER de terceros le indica al AS que el usuario ahora está en línea y qué S-CSCF lo está sirviendo, de modo que el AS pueda suscribirse a eventos de registro, preparar su estado y estar listo en el momento en que llegue una sesión. Es el intercambio silencioso que permite a un servidor de funcionalidades mantenerse sincronizado con un suscriptor con el que nunca habla directamente durante el inicio de sesión.

Dónde encaja el SBC en relación con el Application Server

Para cualquier persona que compre, despliegue u opere session border controllers, la pregunta útil es cómo se relacionan el AS y el SBC. Son complementarios, no competidores. El Application Server se sitúa en el plano de aplicación y es dueño de la lógica de servicio. El SBC se sitúa en los bordes de la red y es dueño de la frontera, en el extremo de acceso hacia los dispositivos y en la interfaz red a red hacia otros operadores. Un SBC no aloja funcionalidades, y un AS no protege un perímetro.

Los dos aún interactúan, porque el tráfico moldeado por un Application Server tiene que cruzar las mismas fronteras que todo lo demás. Cuando un AS ancla medios, por ejemplo un anuncio o un puente de conferencia proporcionado por la función de recursos de medios, esos medios siguen entrando y saliendo de la red a través del SBC. Cuando sesiones que un AS ha procesado se entregan a otro operador, el SBC en la interfaz red a red realiza ocultamiento de topología para que las direcciones internas del núcleo y sus Application Servers nunca queden expuestas al otro extremo. Y dado que diferentes operadores ejecutan Application Servers de diferentes proveedores, el SBC normaliza el SIP entre los dialectos que habla cada lado, de modo que una sesión que salió del AS de una red sea comprendida por la siguiente. Esa normalización es el mismo trabajo de interoperabilidad multi-proveedor que un SBC realiza en cualquier interconexión, aquí aplicado a tráfico originado en IMS.

Hay un modo que vale la pena mencionar explícitamente. Tanto un AS rico en funcionalidades como un SBC de grado carrier operan como back-to-back user agents, pero con fines diferentes. El AS es un B2BUA en el núcleo para poder controlar ambos tramos de una llamada y así entregar un servicio. El SBC es un B2BUA en la frontera para poder terminar y re-originar completamente la señalización y los medios, que es lo que hace posible el ocultamiento de topología, la manipulación de encabezados y la seguridad de medios. Misma arquitectura, diferente lugar en la red, diferente función.

Preguntas frecuentes

Conclusión

El Application Server es donde IMS deja de enrutar y comienza a entregar. El S-CSCF lo alcanza a través de la interfaz ISC basada en SIP, decide cuándo invocarlo a partir de los Initial Filter Criteria en el perfil del suscriptor, y puede encadenar varios Application Servers en una misma sesión. El MMTel AS cubre las funcionalidades de telefonía, el SCC AS mantiene las llamadas vivas durante los traspasos, el IP-SM-GW transporta la mensajería, y el third-party registration mantiene a cada uno sincronizado con el suscriptor. Para un ingeniero de voz en la frontera, la conclusión clave es el límite: la lógica de servicio pertenece al Application Server en el núcleo, mientras que el borde controlado y seguro que este tráfico cruza pertenece al SBC.