Resumen

  • Replaces utiliza Call-ID, to-tag y from-tag para identificar un único diálogo creado mediante INVITE. Esa coincidencia no autentica al solicitante ni demuestra que tenga autoridad para desplazar a otro participante.
  • El receptor conserva la decisión local: autoriza, intenta admitir el nuevo INVITE y solo después de un 2xx envía BYE al diálogo confirmado o CANCEL a un early dialog elegible. Si falla la nueva admisión, el diálogo antiguo permanece sin cambios.
  • REFER, Referred-By, el resultado del INVITE de sustitución y la continuidad de medios, grabación y cobro son capas distintas. Un único estado de “transferido” no basta como evidencia ni como control.

La pregunta que el identificador no puede responder

En una mesa de ayuda, una agente consulta con un técnico y después pide al teléfono del cliente que se conecte con él. La petición REFER llega correctamente y el teléfono del cliente la acepta. El sistema de la agente recibe 200 y cambia el caso de propietario.

Pero el cliente aún no está con el técnico. Su terminal debe enviar otro INVITE. Dentro viaja un Replaces que señala el diálogo de consulta. El terminal del técnico puede localizarlo y, aun así, rechazar al cliente porque la política no reconoce su autoridad para sustituir a la agente. También puede autorizarlo y después rechazar la oferta por medios incompatibles o por no poder establecer las claves necesarias.

El triplete responde «¿qué diálogo?». No responde «¿quién puede disponer de él?», «¿puede entrar la nueva sesión?» ni «¿terminó la anterior?». RFC 3891 mantiene esas preguntas separadas, y un sistema operativo debería hacer lo mismo.

Una invitación nueva conserva el derecho a decir no

Replaces no altera el diálogo existente desde dentro. Se inserta en un INVITE nuevo, con un Call-ID nuevo. Es una elección de arquitectura: la sustitución propuesta atraviesa las reglas ordinarias de admisión de una sesión nueva.

El campo explícito evita que cada UA deduzca asociaciones ocultas a partir de otros datos. El nuevo Call-ID separa la identidad de la sesión candidata. Si el receptor no entiende la extensión, puede fallar de forma visible sin destruir la sesión que ya funciona.

Quien soporta el mecanismo anuncia Supported: replaces. Quien necesita un rechazo explícito cuando no exista soporte puede enviar Require: replaces. El registro IANA de parámetros SIP mantiene las dos asignaciones.

Soportar no es consentir. Un terminal puede comprender perfectamente Replaces y denegar una sustitución concreta por identidad, tenant, horario, relación entre participantes, riesgo, recursos o cualquier otra política válida.

Tampoco deben confundirse Replaces y REFER. REFER solicita que su destinatario contacte con el recurso indicado. Replaces comunica a la target UA qué diálogo se pretende sustituir. En una transferencia atendida suelen encadenarse; ninguno resume el resultado del otro.

Dos tags y una perspectiva que no se puede omitir

El valor Replaces contiene Call-ID, un to-tag y un from-tag. Para el UAS receptor, to-tag se compara con el tag local y from-tag con el remoto.

La orientación no es un detalle de interfaz. Las cabeceras To y From de una traza anterior reflejan la perspectiva de aquel mensaje, no una verdad universal sobre los extremos. Copiar nombres en vez de reconstruir local y remoto puede invertir el triplete.

El registro de erratas de RFC 3891 contiene una corrección editorial verificada que invierte los tags de un ejemplo de early dialog. Otra corrección semejante quedó Held for Document Update. No cambian la norma; muestran por qué un ejemplo no debe sustituir al modelo de estado.

Una coincidencia válida se refiere solo a un diálogo. RFC 3891 excluye múltiples diálogos, una llamada completa, una transacción completa y el árbol entero de forks. Si un INVITE original produjo varias ramas, Replaces puede apuntar a una, no heredarlas todas. Si un proxy redirige el INVITE nuevo a Contacts ajenos, la coincidencia falla.

Esta granularidad suele chocar con el modelo del negocio. La ficha de una «llamada» puede unir piernas SIP, consulta, grabaciones, cola y cobro. Proyectar la sustitución de una pierna sobre todo el agregado requiere evidencia adicional.

El mismo objeto admite operaciones opuestas

La validación ocurre antes de conceder ningún efecto. Dos campos Replaces, Replaces fuera de INVITE o cabeceras con semántica de control contradictoria producen 400. Si una cabecera coincide con más de un diálogo, el UA actúa como si no existiera coincidencia.

RFC 3911 ofrece una comparación decisiva. Join también identifica un diálogo mediante Call-ID y tags, pero pide añadir el diálogo nuevo al espacio de conversación. Replaces pide cerrar el diálogo identificado y sustituirlo. Juntos son contradictorios.

El identificador no contiene la operación. La cabecera expresa la operación propuesta; la autenticación identifica al actor; la autorización fija su poder; la admisión comprueba la viabilidad; la ejecución deja el resultado.

Sin coincidencia, o ante un diálogo no creado con INVITE, la respuesta es 481. Si el diálogo ya terminó, la recomendación es 603 para evitar que una petición retrasada haga sonar un nuevo aviso sin sentido. Una coincidencia ambigua se trata como ninguna.

481 no equivale a fraude. Puede deberse a tags invertidos, estado obsoleto, pérdida en failover, entrega a otra instancia, retargeting o una carrera con la terminación. La telemetría debe registrar cuál de estas superficies falló.

Autenticar al iniciador no agota la autorización

Cuando el diálogo activo coincide, RFC 3891 exige verificar que el iniciador del nuevo INVITE está autorizado para reemplazarlo.

Una identidad autenticada como equivalente al usuario sustituido puede ser suficiente bajo cierta política. Un Referred-By asociado a un REFER del otro participante puede aportar procedencia. El UA puede aplicar otras reglas locales e incluso una política diferente para el diálogo nuevo y el antiguo.

Nada de esto convierte una credencial en mandato ilimitado. Las credenciales compartidas pueden representar legítimamente varios terminales de una misma identidad o una delegación funcional. También pueden permitir que una cuenta de servicio desplace llamadas de usuarios o tenants que nunca la autorizaron. La autenticación prueba control de una credencial, no intención humana actual, poder corporativo ni consentimiento regulatorio.

RFC 3892 limita expresamente el valor de Referred-By. El referee transporta la información del referrer a la target y puede observarla o modificarla. Una URI sin token protegido es información sospechosa si influye en la admisión o se muestra al usuario. La target puede exigir un token válido y rechazar uno inválido.

Un token válido tampoco responde todas las preguntas. Protege datos de la referencia, pero no acredita automáticamente autoridad médica, financiera, laboral o contractual. El alcance pertenece a la política local y debe quedar documentado.

Conocer el diálogo: evidencia, no propiedad

RFC 4538 usa Target-Dialog cuando la autorización puede depender de que el solicitante conozca un diálogo existente. Si se estableció con SIPS, sus identificadores son impredecibles y la confianza en el camino original está definida, ese conocimiento puede justificar una decisión.

Las condiciones son parte de la prueba. En un camino no protegido, un observador podría haber aprendido los identificadores. Incluso con SIPS, el receptor puede entender Target-Dialog y decidir que la relación demostrada no basta para la operación pedida.

Saber dónde está una conversación no concede el derecho de moverla. Puede demostrar acceso a un contexto protegido; solo una regla responsable decide qué autoridad nace de ese acceso.

Aquí encaja el criterio de Heng Lu: participación, presencia o conocimiento pueden ser evidencia sin convertirse en facultad de obligar a quien soporta la pérdida. En SIP, el terminal que conserva el diálogo es quien afronta la desconexión y mantiene el último control local.

El diálogo antiguo es el mecanismo de recuperación

Tras autorizar al iniciador, el UAS intenta aceptar el nuevo INVITE, reasignar la interfaz y otros recursos, y cerrar el diálogo coincidente. Todavía puede fallar.

RFC 3891 cita QoS, keying y medios incompatibles. La falta de recursos o cualquier rechazo ordinario de admisión también puede impedir el nuevo diálogo. En ese caso se devuelve el error apropiado y el diálogo antiguo debe quedar intacto.

No es una formalidad. Si se cierra al encontrar el triplete, un identificador filtrado puede derribar una conversación. Si se cierra al autenticar al actor, una oferta técnicamente imposible produce el mismo corte. Mantener la sesión conocida hasta admitir la nueva limita el fallo.

Ante un diálogo confirmado y sin early-only, el UAS responde 2xx al nuevo INVITE y luego envía BYE al antiguo. Si se trata de un early dialog iniciado por ese mismo UA, acepta el nuevo y envía CANCEL al INVITE anterior.

early-only protege la intención de sustituir solo una rama que aún está sonando. Si ya está confirmada, se responde 486. Si el early dialog no fue iniciado por el UA receptor, se responde 481 y se conserva: el mecanismo de un solo diálogo no puede reconstruir el forking iniciado por otro extremo.

El 2xx de sustitución demuestra admisión del diálogo nuevo. No demuestra por sí solo que BYE llegó, que un B2BUA eliminó sus piernas internas, que no quedan forks, que RTP continúa, que la grabación cambió bien de leg o que cesó el cobro anterior.

REFER conserva una aprobación anterior y una prueba posterior

RFC 3515 indica que el UA que acepta un REFER bien formado debería obtener aprobación del usuario, mediante una pregunta interactiva o una política configurada. Después accede al recurso de Refer-To con las reglas normales del método correspondiente.

En transferencia atendida, Refer-To suele contener una URI con Replaces escapado. El transferee genera el INVITE y la transfer target evalúa de nuevo identidad, autoridad y admisión. La persona que envió REFER no hereda la decisión de la target.

La transacción REFER y la acción referenciada tienen estados separados. NOTIFY informa del progreso y del resultado final. RFC 7647 actualiza la aceptación para usar 200 en lugar de 202 y obliga a usar Target-Dialog cuando se desea identificar un diálogo existente en este contexto. El 200 continúa siendo la respuesta a REFER, no a toda la transferencia.

RFC 5589 añade una regla operativa fundamental: una transacción REFER satisfactoria no termina la sesión entre transferor y transferee. Hace falta un BYE posterior. Sus flujos de fallo reanudan la sesión original cuando la target está ocupada, no responde o rechaza Replaces.

La evidencia completa separa aprobación de REFER, aceptación de REFER, resultado del INVITE disparado, cierre del diálogo anterior y resultado para el usuario.

Qué conservar para poder decidir después

Guarde la identidad del INVITE nuevo y el triplete Replaces como campos diferentes. Añada la perspectiva local/remota del receptor, estado del diálogo al coincidir, Contact, ruta, rama y early-only.

Registre la base de autoridad: identidad autenticada, Referred-By, validación del token, versión de política, regla de usuario o tenant, origen de la aprobación y motivo. Un authorized=true sin procedencia no explica quién decidió.

Para la admisión, conserve código de respuesta, fingerprint de SDP, codecs, direcciones, keying, QoS, instancia y ACK. Después de 2xx, enlace BYE o CANCEL del diálogo anterior, su respuesta, retransmisiones y último tráfico y medio observados.

REFER entra en la misma cronología con Call-ID, CSeq, Target-Dialog, fingerprint de Refer-To, aprobación, respuesta y NOTIFY. El resultado anunciado debe contrastarse con la transacción de destino y con las piernas reales.

Pruebe tags invertidos, coincidencias ambiguas, diálogos terminados, carreras de early-only, ausencia de soporte, denegación tras match correcto, token Referred-By inválido, fallo de medios/keying/QoS, busy/no-answer, pérdida de BYE tras 2xx, forks residuales, retargeting, pérdida de estado en failover y mapeos B2BUA irreconstruibles.

El objetivo es una cronología que responda por separado qué se pidió, qué diálogo se nombró, quién tenía autoridad, qué sesión fue admitida, qué se terminó y qué servicio recibió realmente la persona.

Fuentes