Resumen

  • History-Info guarda los Request-URI que exponen los nodos compatibles cuando una petición inicial cambia de destino o se bifurca. hi-index forma un árbol ordenado y rc, mp y np clasifican cambios de contacto, de usuario objetivo o solo de siguiente salto.
  • La extensión es opcional. El árbol puede incluir entradas heredadas o suplidas, omitir ramas pendientes y anonimizar destinos por una política de privacidad legítima. TLS protege el transporte, no la honestidad de cada intermediario confiable.
  • Para justificar un redestino hacen falta además la regla aplicada, su propietario, los datos consultados, la identidad operativa, el estado de cada rama, la transformación de privacidad y el resultado observado. La ruta registrada no otorga el derecho a decidirla.

El destino correcto según una pantalla

Un banco publica un número único para bloquear tarjetas. Durante una revisión se descubre que algunas llamadas nocturnas terminaron en un proveedor externo. La consola del operador muestra un History-Info ordenado: número público, servicio de emergencias, aplicación del proveedor. No hay error de sintaxis y la última rama recibió una respuesta positiva. La pantalla etiqueta el recorrido como «válido».

La validez sintáctica no resuelve la cuestión de control. ¿Quién activó la regla nocturna? ¿Qué versión del directorio incluyó al proveedor? ¿Seguía vigente la delegación? ¿Hubo una rama interna que aún no había respondido? ¿Se ocultó una identidad por privacidad? ¿El intermediario que escribió la entrada era el que realmente ejecutó la decisión? ¿El cliente habló con un agente capaz de bloquear la tarjeta?

La cabecera puede responder a una pregunta más estrecha: qué objetivos declara el mensaje observado. Si se usa como respuesta a todas las demás, la consola se convierte en autoridad sin que el protocolo le haya dado ese cargo.

RFC 7044 define History-Info para conservar el historial de una petición inicial o fuera de diálogo. Una redirección normal sustituye el Request-URI; la cabecera evita que la dirección anterior desaparezca por completo. No define las reglas locales que justifican el cambio.

Decidir, escribir y registrar son actos distintos

Con RFC 3261, un proxy determina un objetivo mediante localización, configuración, una respuesta de redirección u otra lógica. Después envía la petición con el Request-URI resultante. El siguiente nodo sabe adónde va ahora, pero no necesariamente de dónde viene la elección.

RFC 7044 denomina retargeting al cambio de Request-URI conforme a reglas de determinación de objetivo, seguido del reenvío. La entidad que ejecuta esas reglas produce el hecho operativo. History-Info conserva una representación del resultado.

El estándar aporta una gramática común. El registro IANA de parámetros SIP confirma las asignaciones de History-Info, histinfo, history, rc, mp y np. El registro no demuestra que una red implemente la extensión, que clasifique bien las entradas ni que una organización haya aprobado el desvío.

El alcance tampoco cubre toda la vida de una llamada. La extensión se aplica a peticiones iniciales o fuera de diálogo. Señalización dentro del diálogo, flujo de audio, grabación, atención humana y facturación pertenecen a registros distintos.

Una topología numerada, no un cronómetro

Cada entrada incluye el URI objetivo y un hi-index. Una secuencia de enteros no negativos separados por puntos sitúa la entrada en el árbol. Los hijos extienden el índice del padre; un fork genera hermanos. El orden de salida sigue un recorrido en preorden para que el receptor pueda reconstruir la estructura.

Esto evita que una lista plana confunda dos ramas paralelas con dos redestinos consecutivos. Aun así, los índices no son marcas de tiempo. No indican duración, no sincronizan relojes y no prueban cuál de dos ramas terminó primero.

Los parámetros de mecanismo describen otra dimensión:

  • rc indica que cambió el Request-URI pero el nodo considera que sigue siendo el mismo usuario objetivo, por ejemplo al resolver una dirección a un Contact;
  • mp indica un mapeo a otro usuario objetivo o a otra dirección de registro;
  • np indica que cambió el siguiente salto sin cambiar el Request-URI.

La descripción pertenece al nodo que la inserta. rc no certifica que dos identidades sean la misma persona responsable. mp no contiene una autorización. np no avala al siguiente operador. La clasificación es un dato que debe poder contrastarse con el motor de decisión.

Cinco caminos hacia un historial parcial

Primero, el soporte es voluntario. histinfo se anuncia en Supported; no obliga a todos los saltos mediante Require o Proxy-Require. Un equipo que desconoce la extensión deja un hueco sin necesidad de comportarse mal.

Segundo, pueden circular entradas de RFC 4244, hoy obsoleto. RFC 7044 preserva la interoperabilidad, pero prohíbe inventar rc, mp o np para una operación anterior que el nodo no observó. Un parámetro ausente puede ser señal de legado, no de ausencia de redestino.

Tercero, un receptor puede detectar que el Request-URI actual no coincide con la última entrada. Entonces añade una entrada en nombre de la entidad anterior. Sabe que hubo cambio; no sabe qué mecanismo se usó. La entrada suplida carece deliberadamente de clasificación.

Cuarto, un fork hace que la vista dependa del momento. RFC 7044 presenta una rama que devuelve 200 mientras otra sigue pendiente. La respuesta ganadora no puede contener el resultado futuro de su hermana. El historial observado en el éxito puede ser correcto y no ser exhaustivo.

Quinto, la privacidad puede ocultar objetivos. Los ejemplos de RFC 4244 muestran que un nodo aguas arriba, al no conocer una rama privada ya intentada, puede repetirla. Es una tensión real entre minimización y optimización. La aplicación debe diseñarse para información parcial, no declarar que el conjunto visible es universal.

La afirmación auditable siempre incluye el punto de observación: «este mensaje llevaba estas entradas». Quitar ese contexto transforma evidencia local en una pretensión global.

Reason conserva contexto, no la causa última

History-Info puede llevar información Reason dentro del componente headers del URI. RFC 3326 define causas SIP y Q.850, entre otras posibilidades, y permite más de un espacio de protocolo. RFC 7044 usa esos valores para ciertos fallos y timeouts.

El dato ayuda: una rama informó ocupado, otra agotó su plazo. No demuestra por qué una persona configuró el desvío, si la política era válida, si la respuesta era verdadera o cuál fue la causa económica del incidente. Sin protección de integridad también puede eliminarse o alterarse. Debe guardarse junto al mensaje, la entidad y el punto donde se observó.

El registro de erratas de RFC 7044 contiene tres observaciones Reported —sobre indexación de huecos, clases de respuesta para Reason y una referencia editorial— y dos Rejected. Reported no significa Verified. Es una advertencia para probar implementaciones, no una sustitución normativa.

Una ocultación puede ser el resultado correcto

El historial puede revelar dispositivos personales, alias, departamentos internos, buzones y topología. RFC 3323 explica que la privacidad SIP necesita a menudo intermediarios porque son ellos quienes añaden datos de ruta.

RFC 7044 incorpora el valor de privacidad history. La protección puede cubrir las entradas relevantes o una entrada concreta. Un dominio puede ocultar su encaminamiento interno aunque la petición entrante no pida privacidad. El receptor puede impedir que el originador conozca el destino final. Un servicio de frontera puede sustituir un URI por una dirección bajo anonymous.invalid.

Esa transformación no es por sí misma una falsificación hostil. Puede cumplir exactamente la política. Pero limita lo que el receptor aguas abajo puede demostrar. El expediente debe conservar quién transformó, bajo qué norma y qué correspondencia protegida existe para un revisor autorizado.

La facultad de elegir un objetivo y la facultad de ocultarlo tienen propietarios distintos. Si ambas desaparecen bajo «normalización de ruta», nadie puede rendir cuentas por ninguna.

SIPS no convierte la cadena en una atestación

RFC 7044 recomienda firmemente TLS o un entorno seguro. SIPS reduce la manipulación por terceros fuera del camino según su modelo de confianza. Los intermediarios del camino, sin embargo, necesitan leer y añadir History-Info.

Un intermediario malicioso o comprometido puede borrar, reordenar o modificar entradas. El propio RFC declara que el mecanismo no impide ni detecta esa acción. La cabecera goza de la misma seguridad que las demás cabeceras SIP del trayecto, no de una garantía superior.

Por eso conviene registrar el par TLS, el resultado del certificado, el dominio de confianza, la huella del mensaje y el punto de captura. «Usó SIPS» describe el transporte. «Todos los narradores dijeron la verdad» sería otra prueba.

La aplicación necesita una regla explícita de lectura

RFC 7044 obliga a prever historiales ausentes o incompletos. También acepta que servicios distintos extraigan entradas distintas.

Un PBX empresarial y un buzón de consumo pueden escoger posiciones rc diferentes para determinar a quién se llamó. Si el reenvío ocurrió antes de entrar en la empresa, elegir siempre el primer rc puede identificar a una persona ajena al servicio. RFC 4458 muestra que, para correo de voz, los datos target y cause pueden aparecer en el Request-URI actual o en History-Info según el soporte y el recorrido.

No hay selector universal escondido en el árbol. La aplicación debe publicar su finalidad, los dominios que confía, su reacción ante huecos y privacidad y su criterio ante conflictos.

Es la separación defendida por Heng Lu entre una especificación inicial mínima y las decisiones futuras localizadas. La capa común coordina; quien tiene el contexto decide. Para que esa autonomía no se convierta en arbitrariedad, la regla local debe ser exportable, versionada y discutible.

El expediente mínimo de una decisión de destino

Conserve el mensaje: método, Request-URI recibido y emitido, Call-ID, CSeq, rama Via, hora, punto de observación y huella controlada.

Conserve por separado los árboles recibido y emitido: orden, índice, URI, referencia rc/mp/np, Reason, privacidad, legado, resultado de análisis y hueco suplido. No rellene un mecanismo desconocido.

Conserve la decisión: ID y versión de regla, consulta o redirección de entrada, conjunto candidato, selección, orden de fallback, creación de ramas, identidad de servicio, tenant, propietario, aprobación y vigencia.

Conserve confianza y privacidad: dominio de entrada y salida, par TLS, política aplicada, transformación, mapa protegido, permisos y retención.

Finalmente, correlacione transacciones, respuestas, timeout, CANCEL, rama ganadora, mapa de patas B2BUA, diálogo, medios, aplicación, grabación, cobro y reclamación.

No elimine contradicciones: un ganador sin la rama hermana conocida; un rc que cruza una frontera de tenant; un Reason contrario al registro de aplicación; un B2BUA con árbol correcto y mapa perdido; un 200 sin audio. Cada discrepancia ubica una frontera de realidad. Resumirlas como «ruta válida» entrega autoridad al agregador.

Fuentes