Resumen

  • Una respuesta 2xx aceptaba el procesamiento de REFER y, en el diseño original, abría una suscripción implícita; no demostraba que la solicitud indicada hubiera triunfado.
  • La suscripción, los NOTIFY y la acción tenían vidas distintas. Dejar de recibir informes no cancelaba la acción, y las ramas de un REFER bifurcado debían conservarse por separado.

El relato de transferencia telefónica parece lineal: Alice indica a Bob que llame a Carol, Bob acepta y Carol contesta. RFC 3515 solo garantizaba el primer enlace al responder REFER. Los demás pertenecían a una solicitud nueva, a una corriente de eventos y, finalmente, a una observación fuera de la transacción inicial.

El documento, publicado en abril de 2003 en el Standards Track, definió la método REFER, el encabezado Refer-To y el paquete de eventos refer. Una solicitud válida lleva exactamente un valor Refer-To. El receptor intenta acceder al recurso por el mecanismo normal de su URI. Si es SIP puede emitir INVITE; si es otro esquema, interviene otro protocolo.

REFER podía incluir un cuerpo, pero RFC 3515 no le asignó semántica. El receptor podía procesarlo según Content-Type. Así, la presencia de datos adicionales no convertía esos datos en una orden estándar ni ampliaba silenciosamente el contrato.

Antes de actuar, el receptor evaluaba sintaxis, capacidad, autenticación, política y aprobación del usuario. Una solicitud bien formada podía ser negada de inmediato. Si ninguna regla producía otra respuesta final, la especificación original obligaba a devolver 202 Accepted antes de que expirara la transacción REFER.

Ese 202 decía que el receptor aceptaba encargarse de REFER. No decía que la nueva INVITE ya existiera, que el objetivo hubiera respondido, que un recurso HTTP fuera accesible, que hubiera media ni que dos personas hablaran. Incluso podía faltar la aprobación final para iniciar la acción.

Al aceptar con 2xx, el contrato de 2003 también creaba una suscripción implícita al evento refer. El canal NOTIFY existía porque el resultado no podía caber honestamente en la respuesta de aceptación. Instrucción y observación eran protocolos relacionados, no el mismo hecho.

La suscripción producía un NOTIFY inmediato, capaz de llegar antes de que concluyera la propia transacción REFER. El emisor debía soportar ese orden. Si el estado seguía pending, el cuerpo podía limitarse a SIP/2.0 100 Trying. Era un informe de estado presente, no prueba de contacto ni progreso físico.

Cada NOTIFY llevaba Event: refer y un cuerpo message/sipfrag que comenzaba con una línea de estado SIP. La clase de respuesta representaba el estado de la acción referida. El cuerpo era una declaración completa para ese instante, no un delta cuya interpretación exigía fusionar mensajes previos.

Una implementación mínima podía enviar 100 para pending, 200 para éxito, 503 para fallo o 603 si el usuario negaba después la aprobación. Ese 603 tardío es importante: el sistema podía aceptar REFER antes de saber si la acción se autorizaría. Por diseño, aceptación y resultado podían contradecir la intuición de una interfaz.

Además había dos 200 diferentes. El agente que recibía NOTIFY contestaba 200 OK a la transacción NOTIFY. Ese acuse no confirmaba el código incrustado en el sipfrag ni el éxito de la acción. Un registro que solo muestra “200 OK” sin capa, CSeq y cuerpo confunde recibo del informe con contenido del informe.

El notifier podía insertar más partes de la respuesta SIP referida, algo útil para depurar. RFC 3515 advertía que exponerla podía tener graves consecuencias de seguridad. Encabezados, rutas y detalles del objetivo no pertenecían automáticamente al referrer. Observabilidad y autorización de la observabilidad eran decisiones distintas.

Cuando la URI no era SIP, el estado aún se expresaba mediante códigos SIP. La traducción uniformaba el paquete de eventos, pero perdía riqueza del protocolo nativo. Un 200 sintetizado por el adaptador no era necesariamente el recibo original de un objeto, efecto o resultado material.

La duración de la suscripción tampoco venía en REFER. El receptor la elegía y la comunicaba en el primer NOTIFY, normalmente con margen suficiente para completar la acción. El emisor podía refrescarla o terminarla.

Terminar la observación no era cancelar la ejecución. El RFC lo dice de forma explícita: desuscribirse o rechazar NOTIFY no indica que la solicitud referida deba retirarse. El receptor no debía enviar CANCEL solo porque el emisor dejó de seguir los eventos. Silencio, cancelación y finalización eran estados diferentes.

Un REFER dentro de un diálogo no se bifurcaba bajo estas reglas. Fuera del diálogo podía ser aceptado por varios agentes y crear varias suscripciones. El emisor debía administrarlas por separado y no fusionar su estado. Cada rama representaba una acción propia, con identidad y resultado propios.

La autorización protegía el control más peligroso: hacer que un agente contactara una tercera parte. Una política amplia podía abrir recursos SIP, HTTP u otros desde una ubicación confiable. El Refer-To debía restringirse si la meta estaba protegida, y la identidad del referrer no podía separarse de la decisión.

RFC 4488 permitió después pedir REFER sin suscripción implícita. RFC 7614 definió suscripciones explícitas y RFC 7647 aclaró la interacción con el marco de eventos de RFC 6665. Otras actualizaciones refinaron sintaxis y prácticas de transferencia. Ninguna convirtió el 2xx inicial en resultado de la acción; solo cambió cómo se observaría.

La separación de capas de Heng Lu evita la extrapolación. 202 es un recibo simbólico de una responsabilidad. NOTIFY es un reporte de un notifier dentro de un estado de suscripción. La solicitud referida tiene su propia ejecución. Media, conversación y fin comercial están más lejos. Un mensaje correcto no puede producir la evidencia de otra capa.

La gran aportación histórica de RFC 3515 fue admitir que una delegación necesita más de un reloj. La instrucción termina, la observación vive, la acción corre y el resultado se verifica. REFER fue aceptado; la historia no había terminado.

Sources