Resumen

  • RFC 3327 permitió que los proxies añadieran un Path ordenado durante REGISTER; tras una inscripción exitosa, el registrador asociaba ese vector al vínculo entre AOR y Contact y lo devolvía.
  • Más tarde, el proxy del dominio local podía copiar el vector guardado en un encabezado Route para solicitudes dirigidas a ese Contact. El vector no demostraba qué ruta había seguido el paquete REGISTER.

La respuesta de hoy prepara una llamada de mañana

Un registrador SIP puede guardar la dirección en la que se encuentra un agente de usuario, o UA. Ese vínculo responde una pregunta concreta: ¿qué Contact debe recibir una solicitud para esta dirección de registro, o AOR? No necesariamente responde otra: ¿qué proxies intermedios debe cruzar la solicitud para llegar al Contact?

La brecha aparece cuando REGISTER atraviesa proxies de borde que un proxy del dominio local no puede reconstruir a partir del DNS ni de sus propias tablas de enrutamiento. El UA puede registrarse desde una red visitada, el registrador estar en otro lugar y una futura solicitud entrante necesitar regresar por nodos que no aparecen en el URI de Contact. Publicada en diciembre de 2002, RFC 3327 permitió que esos nodos dejaran un vector de ruta en el intercambio de registro.

El nombre «Path» puede sonar a medición de recorrido. No era esa su función. Un proxy atravesado por REGISTER podía añadir un valor Path. El registrador conservaba los valores ordenados con el vínculo del Contact y la AOR, y después los reflejaba en una respuesta REGISTER exitosa. Más adelante, al recuperar ese vínculo, un proxy del dominio local podía poner el vector en un encabezado Route precargado y enviar la nueva solicitud por esos proxies. La memoria pertenecía al vínculo, no a una captura de paquetes de la transacción REGISTER.

Una ruta que sobrevive a la transacción

Path se parece a Record-Route, pero no dura lo mismo. Record-Route establece el enrutamiento de solicitudes dentro del diálogo que lo creó. Path aparece en REGISTER y en su respuesta exitosa para que una secuencia de proxies pueda servir a diálogos futuros. El enrutamiento ya definido por RFC 3261 ejecuta Route; RFC 3327 transporta esa secuencia más allá del registro.

El alcance era limitado. El mecanismo se aplicaba a solicitudes que atravesaban o se originaban en el dominio local del usuario. Los valores seguían la sintaxis de un elemento Route y usaban el parámetro de enrutamiento flexible ;lr. El UA podía anunciar compatibilidad con Supported: path; por regla general, los proxies no debían añadir Path si el UA no había indicado ese soporte. Si el registrador recibía Path sin esa indicación, RFC recomendaba rechazarlo, aunque dejaba margen para la política local.

El cambio histórico no fue que SIP empezara a saber por dónde había pasado cada paquete. El registro se convirtió en el punto donde los proxies podían asociar contexto de enrutamiento al vínculo que gobernaría futuras solicitudes entrantes. Además, la respuesta del registrador devolvía Path al UA: los proxies añadidos podían quedar a la vista, en lugar de convertirse silenciosamente en una base universal de topología.

El vector no es un testigo

RFC 3327 permite de forma explícita que un proxy con conocimiento de la topología añada un Path que haga referencia a otro nodo, aunque ese valor no coincida con la ruta que REGISTER tomó en realidad. Esto fija la interpretación: Path es una prescripción de enrutamiento ordenada, construida bajo políticas de proxies y del registrador, no una prueba forense del recorrido de los paquetes. Por sí solo no demuestra que un proxy transmitiera un mensaje anterior, que la ruta propuesta siga disponible ni que una llamada futura se entregue.

La decisión también abrió una frontera de seguridad. Un proxy insertado en el vector guardado podía quedar en la ruta de solicitudes futuras e interceptar llamadas. Por eso RFC 3327 analiza la integridad del transporte y la autenticación mutua, por ejemplo mediante TLS o IPsec, y describe copias S/MIME protegidas para que el UA detecte cambios en el Path devuelto. Que un URI sea válido sintácticamente no convierte al intermediario en autorizado.

El trabajo posterior reutilizó el mecanismo con un propósito más específico. RFC 5626 coloca un token de flujo único en Path para que un proxy de borde asocie una solicitud futura con una conexión iniciada por el cliente. Ese comportamiento por flujo pertenece a la extensión posterior; no debe atribuirse a todo vector de ruta de RFC 3327. En dirección opuesta, Service-Route de RFC 3608 entrega al UA una ruta para sus propias solicitudes salientes, no un camino para solicitudes entrantes dirigidas al UA.

Fuentes