Resumen

  • RFC 3136 definió los componentes lógicos para que un evento originado en la red telefónica llegara a un abonado conectado a Internet y para que su disposición pudiera regresar al control de la llamada.
  • El clic era una intención, no la acción telefónica. La pasarela y el cliente SPIRITS debían transportarlo, la función de control debía convertirlo en lógica de servicio y el conmutador debía reanudar el procesamiento.

Una decisión visible y una llamada invisible

Para quien usaba un módem en 2001, una llamada entrante planteaba un conflicto físico. La misma línea sostenía la sesión de Internet y debía recibir voz. Internet Call Waiting prometía presentar el evento en el ordenador sin obligar al abonado a abandonar de antemano la conexión.

La ventana podía ofrecer varias salidas: terminar la sesión y aceptar la llamada, desviarla a otro número, enviarla al buzón, reproducir un mensaje o rechazarla. El abonado veía las opciones y elegía una. La interfaz conocía esa elección con precisión.

Lo que no conocía por sí sola era el desenlace. El llamante estaba en la red telefónica. La llamada podía permanecer suspendida en un punto de procesamiento. Un botón pulsado en una máquina IP no modificaba directamente el estado del switch. Para que el gesto adquiriera efecto debía cruzar actores que no compartían ni el mismo protocolo ni la misma autoridad.

RFC 3136, publicado en junio de 2001 como Informational, describió esa arquitectura bajo el nombre SPIRITS. No era un estándar completo de protocolo ni una encuesta de adopción. Identificaba las funciones necesarias cuando un servicio empezaba en el PSTN y requería interacción con Internet. Su valor histórico reside tanto en las separaciones como en las conexiones.

La llamada comenzó antes de la notificación

En el lado telefónico, una Service Switching Function reconocía los triggers de la Intelligent Network. Normalmente residía en el switch. Una Service Control Function ejecutaba la lógica de servicio, recibía la interacción del SSF y podía indicarle cómo completar la llamada.

Por tanto, el primer recibo no era «ventana mostrada». Antes debían existir una llamada en cierto estado, un punto de detección relevante y una comunicación hacia el control. Que el switch detectara algo no probaba que el SCF lo procesara. Que el SCF generara un evento no probaba que llegara al abonado.

El SPIRITS Client ocupaba el borde telefónico de la arquitectura. Recibía solicitudes del SCF y enviaba respuestas. RFC 3136 permitía que estuviera junto al SCF o separado por la interfaz D. Esa libertad impide convertir cada caja del diagrama en un dispositivo real obligatorio.

El SPIRITS Gateway mediaba con el dominio IP y podía convivir con funciones PINT. El SPIRITS Server terminaba las solicitudes del PSTN y manejaba la interacción con el abonado: entregar la notificación y devolver el tratamiento elegido. Esas etiquetas describían papeles. No establecían que el Server tuviera poder directo sobre la conmutación.

A, B, C, D y E no eran cinco nombres para éxito

La interfaz A transportaba solicitudes PINT desde el host del abonado al PINT Server. En SPIRITS servía sobre todo para registrar la sesión y activar el servicio durante un tiempo; también podía participar en la suscripción. Una activación correcta decía que existía una relación de servicio. No decía que la siguiente llamada dispararía el evento apropiado.

La interfaz B unía el SPIRITS Server y el Gateway. Hacia el abonado llevaba la llamada entrante y el nombre o número disponibles. De vuelta llevaba la disposición elegida en ese momento. Era posible completar un sentido y perder el otro. Incluso un mensaje de retorno entregado al Gateway quedaba antes del dominio de control telefónico.

La interfaz C comunicaba el Gateway con el SPIRITS Client. El Gateway podía reenviar la solicitud al Server o comportarse como servidor virtual y terminarla. Por ello, una traza de terminación no explicaba automáticamente si otra aplicación había recibido el objeto. Había que conocer la realización concreta.

La interfaz D era el puente con el SCF. En una dirección viajaban los parámetros del trigger; en la otra, la disposición del abonado. RFC 3136 afirmaba que el SCF transformaba esa disposición en acciones apropiadas—por ejemplo, un anuncio al llamante—y reanudaba el procesamiento suspendido en el SSP.

La interfaz E llevaba solicitudes PINT al SCF para su ejecución. PINT empezaba en Internet y pedía una acción al PSTN; SPIRITS empezaba con un evento telefónico y pedía capacidad a Internet. La arquitectura podía reutilizar elementos sin confundir ambos sentidos.

Entre «rechazar» y el tono de rechazo

Cuando el abonado pulsa «rechazar», el software puede registrar el hecho de manera incontestable: identidad de sesión, hora, control seleccionado. El Server puede formar el mensaje. El Gateway puede verificarlo. El Client puede llevar la disposición al SCF. Todo eso puede funcionar y el llamante aún no haber oído nada.

El SCF interpreta la orden abstracta dentro de la política de servicio y del estado de la llamada. Decide qué anuncio o código necesita el switch y cuándo debe continuar. Después, el SSP o SSF actúa. Un timeout puede haber cambiado el estado. Una regla puede impedir la operación. Un componente puede haber aceptado el mensaje para procesarlo y fallar antes del efecto.

«Desviar» añade otra red y otro destino. La instrucción puede salir correctamente, el nuevo número puede ser válido y la segunda llamada puede no ser contestada. «Enviar al buzón» puede alcanzar una plataforma que responde pero no conserva un mensaje útil. «Aceptar» puede exigir cerrar la sesión de datos antes de entregar voz. La arquitectura mencionaba la aceptación mediante voz sobre IP como opción, pero declaraba que su diseño no la reflejaba.

Por eso, la secuencia probatoria debe conservar al menos: registro, trigger, notificación emitida, notificación recibida, elección manual o de perfil, recepción por Server/Gateway/Client, decisión SCF, acción del switch, resultado en el destino y lectura independiente. Un recibo anterior no obtiene retrospectivamente la autoridad del último.

Automatizar el tratamiento no eliminaba la cadena

SPIRITS no dependía siempre de una persona delante de la pantalla. El abonado podía definir un tratamiento general o reglas según el número de origen. Cuando llegaba la llamada, el sistema aplicaba el perfil y después ofrecía un log con fecha, hora, identidad disponible y disposición.

Ese registro podía documentar la política aplicada. También podía mostrar un resultado según la clasificación local. Sin una definición del punto de observación, «forwarded» no distinguía entre seleccionar la regla, enviar la instrucción, recibir un acuse telefónico o comprobar que alguien contestó en el destino.

RFC 2995 había descrito cuatro implementaciones previas. Las cuatro ofrecían Internet Call Waiting, la mayoría usaba SIP y todas usaban soluciones Intelligent Network en el PSTN. Pero el propio informe observó que no todas interoperaban y que ni siquiera las basadas en SIP compartían necesariamente la misma versión.

También avisó de que «SPIRITS server» no tenía una connotación universal. Los sistemas en funcionamiento aportaban evidencia valiosa de posibilidades y diferencias. No autorizaban a leer RFC 3136 como un inventario de funciones idénticas ya desplegadas.

Ser notificado no era gobernar la llamada

RFC 3298, publicado después, exigió que el protocolo mínimo pudiera ofrecer notificación básica sin depender de PINT ni de una interacción persistente con el PSTN. Eso separaba dos productos que una interfaz podía presentar juntos: saber que ocurre algo y tener capacidad para cambiar lo que ocurre.

Cuando se necesitaba control, el documento trazaba la secuencia completa: registro, notificación, disposición, Service Control y SSP. Consideraba la reacción al evento como la pieza restante para entregar el servicio SPIRITS. El vocabulario básico incluía aceptar, rechazar y redirigir; la aceptación por VoIP quedaba fuera del alcance.

Una interfaz honesta debería conservar esos estados. «Notificación recibida» no significa «llamada detenida para decidir». «Elección enviada» no significa «política aprobada». «Política aprobada» no significa «destino alcanzado».

RFC 3910 convirtió más tarde parte de la arquitectura en un protocolo SIP de suscripción y notificación con XML. Llamó subscriber al actor Internet que pedía eventos y notifier al actor telefónico que los comunicaba. Ese cambio de nombres corrigió una ambigüedad: el sentido del testimonio dependía de quién se suscribía y quién observaba.

El protocolo diferenció detection points de tipo Request y Notification. En un Request, el SSP suspendía la llamada hasta recibir respuesta del SCP. En un Notification, podía seguir procesando tras informar. Dos mensajes con información parecida podían participar en relaciones de autoridad opuestas.

La aceptación de una suscripción tampoco era instantáneamente igual a su preparación. Tras un 202, un NOTIFY indicaba que la solicitud había sido aceptada y estaba siendo atendida; otro informaba cuando los detection points estaban inicializados. Un evento posterior producía todavía otra notificación. La especificación preservaba tres tiempos que una barra de progreso podría ocultar.

El último puente seguía siendo política local

RFC 3910 especificó principalmente B y C. Dejó D, la relación con el SCF, a la política del operador PSTN. Podía ser una interfaz funcional o un intercambio de mensajes. Así, el contrato interoperable acababa antes del lugar donde la intención se convertía en mando telefónico.

Esta frontera evitaba que el esquema XML fingiera autoridad. El operador debía asociar la identidad con una línea, evaluar la suscripción, aceptar los eventos disponibles y aplicar la política al estado actual. El mismo mensaje podía ser válido en tránsito y no estar autorizado para esa llamada.

Un estándar mínimo podía hacer comunes los nombres, eventos y estructuras. El futuro local seguía en manos de la implementación. Eso hacía posible variar la integración sin que cada variación se presentara como una ruptura del protocolo.

La superficie de ataque seguía el recorrido de la decisión

RFC 3136 consideraba que B cruzaba normalmente Internet público y era especialmente vulnerable al robo y al denial of service. C podía residir en la intranet del proveedor, pero la pasarela conectada a Internet abría la red interna. El documento advertía que un firewall aislado podía ser insuficiente.

Una suscripción fraudulenta podía desviar datos de caller ID. Una modificación podía convertir «buzón» en «desviar». Una repetición tardía podía aplicarse al evento equivocado. Incluso una identidad auténtica podía haber perdido su asociación con la línea.

Autenticación, integridad, frescura, autorización de la disposición, aceptación por el SCF y efecto en el switch son controles diferentes. El usuario es una fuente de intención legítima; no por ello sustituye a todos los demás decisores.

El problema sobrevivió a la línea dial-up

Hoy otros botones repiten el patrón. Un panel solicita conmutar tráfico, revocar un acceso, cancelar una operación o mover una carga. El gesto ocurre cerca del usuario y el efecto en otra capa. Pasarelas, políticas, controladores y dispositivos siguen transformando el deseo en acción.

RFC 3136 fue valioso porque no confundió el pop-up con la central. El abonado podía escoger. El sistema aún debía demostrar que había ejecutado esa elección y que el mundo al otro lado había cambiado.