Resumen

  • RFC 5368 permite que Refer-To apunte mediante cid: a una lista de destinos. El receptor del REFER crea una petición SIP por destino efectivo, pero la respuesta inicial sólo decide el REFER padre.
  • Para varias transacciones, el documento recomienda norefersub y Refer-Sub: false, porque la suscripción implícita de REFER y sus NOTIFY message/sipfrag no tienen un modelo para varios resultados.
  • La petición expresa una propuesta; la respuesta dice si se concedió. La prueba completa exige además no bifurcación, resolución exacta de Content-ID, normalización, operaciones hijas y observación específica de la aplicación.

Una propuesta no era el acuerdo obtenido

RFC 4488 introdujo una salida del comportamiento normal de REFER. El emisor puede pedir que no se cree la suscripción implícita colocando Refer-Sub: false. Si el receptor admite la extensión y concede la petición, debe devolver el mismo valor en la respuesta 2xx.

La simetría es operacionalmente crucial. Un registro que mira sólo el mensaje saliente sabe qué quería el cliente, no qué aceptó el servidor. Si la respuesta omite Refer-Sub o devuelve true, la suscripción aparece como en el caso ordinario. El sistema debe esperar NOTIFY y mantener el diálogo correspondiente.

RFC 5368 usa esa negociación para el REFER con varios destinos. Recomienda norefersub en Require y el valor falso porque el canal heredado no puede expresar varias transacciones de manera adecuada. El receptor debería confirmar la supresión en 200 y no crear la suscripción.

Por eso hay dos silencios muy diferentes. Uno fue negociado y es correcto. Otro significa que faltan mensajes de una suscripción que sí existe. Un monitor que no conserva la respuesta no puede diferenciarlos y terminará clasificando el mismo síntoma como éxito unas veces y como avería otras.

El padre fue aceptado; los hijos todavía no existían como resultados

El receptor del REFER desempeña dos papeles. Frente al emisor es UAS y responde a la orden. Frente a cada destino es UAC y crea una petición nueva. Cambiar de papel crea una frontera de autoridad y de tiempo.

En el ejemplo de la norma, el 202 aparece antes de los BYE. Sólo puede probar que el servidor aceptó intentar la operación. Cada BYE necesita su propio identificador de diálogo, secuencia, ruta, respuesta y terminación. Que uno tenga éxito no eleva a los demás.

La tentación de usar el estado del padre como agregado nace de una interfaz demasiado plana. Si una base de datos sólo tiene una fila, cualquier 2xx acaba convertido en success. El diseño correcto conserva una fila padre para la negociación y una fila hija por destino normalizado. La fila padre puede cerrarse mientras los hijos siguen abiertos, y los hijos pueden concluir de formas distintas.

Tampoco la ausencia de NOTIFY rellena las filas hijas. El documento dice expresamente que no ofrece un mecanismo para conocer los resultados de un REFER con múltiples destinos. La información debe proceder del servicio concreto.

La certeza de que no habría fork era un requisito

La suscripción implícita no sólo informa del progreso. También permite al emisor descubrir los diálogos que nacen cuando un REFER se bifurca. Suprimirla sin impedir el fork ocultaría ramas.

Por eso Refer-Sub falso sólo puede usarse cuando el emisor sabe que la solicitud no se bifurcará. El ejemplo usa una GRUU. La elección de la dirección forma parte del contrato de evidencia: identifica a un agente concreto y hace defendible que una única respuesta gobierna la supresión.

Una URL de servicio detrás de balanceo no demuestra por sí sola esta propiedad. Puede terminar en un trabajador único o crear entregas SIP independientes. El expediente debe conservar Request-URI, Route, fundamento de no bifurcación, rama de respuesta e identidad del receptor.

Si no se conoce la capacidad, exigir norefersub puede producir 420. Ese código demuestra que la extensión requerida no está disponible en ese destino. No dice nada sobre la voluntad o capacidad de los participantes finales. Reintentar sin Require cambia la observabilidad y necesita una decisión explícita, no una degradación ciega.

El puntero cid tenía un perímetro

Refer-To no contiene las URI finales. Contiene un URL Content-ID que señala la lista transportada en el cuerpo. La autoridad de la orden depende de que el puntero resuelva exactamente al objeto revisado.

Se deben registrar valor cid:, Content-ID, tipo, disposición, límites MIME, hash y cualquier transformación. Si un intermediario reempaqueta el mensaje, debe mantener la unión. Un identificador coincidente sin una frontera de objeto definida no basta.

RFC 8262 documentó un problema histórico. Ejemplos de RFC 5368 etiquetaban un cuerpo completo aunque la normativa disponible hablaba de partes. Muchos implementadores interpretaron el ejemplo como permiso. La actualización permite explícitamente que el puntero señale una parte o el cuerpo completo y que el identificador sea MIME o SIP.

Ese cambio no borra la ambigüedad de capturas antiguas. Para analizarlas hay que conocer la versión implementada, el contenedor y los bytes a los que realmente apuntó la cabecera.

La semántica dependía del método

Una lista RFC 4826 extendida por RFC 5364 puede incluir copyControl. El atributo puede afectar a una INVITE, donde el historial de receptores tiene papeles visibles. En un BYE dentro de un diálogo, to, cc o bcc no ofrecen el mismo significado.

El receptor no debe ser un motor ciego que replique cualquier método. RFC 5368 le exige entender la aplicación y rechazar métodos que no comprende. Antes de generar hijos, autentica al emisor, comprueba autorización, aplica opt-in y verifica que cada operación encaja en el contexto.

multiple-refer sólo coordina una capacidad. La fila de IANA no certifica que una instalación la active ni que el emisor tenga permiso. El análisis debe evitar la cadena falsa «nombre registrado → soporte → aceptación → ejecución → resultado».

Los duplicados añaden otra transformación legítima. La lista presentada, la lista efectiva y las peticiones creadas pueden tener cardinalidades diferentes. Cada fusión necesita una regla y un rastro.

El estado de conferencia respondía a otra pregunta

Para INVITE o BYE de conferencia, el paquete de estado puede mostrar quién figura como participante. Es el sustituto de observación sugerido por el RFC, pero no es un informe detallado del REFER.

Las notificaciones tienen versión, pueden ser parciales y sufrir huecos. Un miembro que desaparece no demuestra por sí solo que un BYE concreto causó la salida. La persona pudo abandonar, otro controlador pudo actuar o el observador pudo perder el evento intermedio.

La conciliación debe mantener solicitud, transacciones de red y estado de aplicación en columnas distintas. Precisamente las diferencias entre ellas revelan fallos de emisión, política o observación.

Límite probatorio

La frase segura es: el receptor identificado aceptó un REFER cuya referencia resolvió a esta lista efectiva y devolvió esta decisión sobre la suscripción. No se añade que todos los destinos recibieron o ejecutaron la acción.

El mínimo registro incluye identidad y permiso; prueba de no fork; petición y respuesta exactas; objeto Content-ID; lista original y normalizada; operaciones hijas; respuestas individuales; observación de servicio con versión y hora; y, por último, resultado humano o comercial separado.

La eficiencia se conserva. Lo que se elimina es la ficción de que un acuse del padre representa a todos sus hijos.