Resumen

  • RFC 3327 permitió que proxies seleccionados añadieran valores Path a REGISTER, de modo que el registrador guardara un vector ordenado con la asociación entre dirección pública y Contact y el proxy doméstico lo convirtiera en Route para solicitudes futuras.
  • Path expresaba una condición de entrega, no una historia completa: podía omitir nodos recorridos, incluir un nodo distinto, sufrir transformaciones y combinarse después con otras políticas de ruta.

Registrar el destino no resolvía el regreso

Un dispositivo podía registrar su identidad SIP pública desde una red visitada. El Contact identificaba el punto actual y el registrador aceptaba la asociación. Sin embargo, ese punto podía estar detrás de un proxy de borde, una frontera de seguridad o una cadena exigida por la red de acceso. Enviar directamente al Contact podía saltarse una función obligatoria o llegar a una dirección que solo tenía sentido a través de aquellos intermediarios.

REGISTER ya había recorrido la cadena necesaria. El problema era que la semántica ordinaria de registro no obligaba a convertir ese recorrido en estado reutilizable. Cuando terminaba la transacción, la red doméstica conservaba la ubicación y perdía el plan de entrega. Era posible saber el destino y no saber llegar.

El campo Path convirtió ese plan en un objeto explícito. Cada proxy interesado podía introducir una URI durante REGISTER. El orden de esas URI formaba un vector. El registrador lo almacenaba junto con la dirección del usuario y ese Contact concreto, y lo reflejaba en la respuesta satisfactoria. Cuando el proxy doméstico seleccionaba más tarde el Contact, precargaba el conjunto Route con el vector antes de reenviar la solicitud.

La asociación debía ser específica. Una misma identidad podía registrar varios dispositivos desde accesos distintos. El camino de un teléfono no pertenecía a un portátil ni a una pasarela. Una renovación podía cambiar el vector, y la expiración debía retirar tanto el Contact como su ruta. Separar sus ciclos de vida habría permitido aplicar una política antigua al destino equivocado.

RFC 3263 resolvía otra etapa: localizar servidores SIP por medio de DNS. Encontrar el servicio de un dominio no revelaba la cadena efímera desde el dominio doméstico hasta un endpoint registrado. Path empezó donde terminaba aquel descubrimiento.

El vector describía una intención futura

El término Path invita a dibujar el trayecto de REGISTER y copiarlo hacia el futuro. La norma fue más cuidadosa. Un proxy atravesado podía no insertar ninguna URI. Un proxy podía insertar la URI de otro nodo que debía atender solicitudes posteriores. El registrador podía transformar el vector al almacenarlo. El proxy doméstico podía añadir una ruta predeterminada o conservar elementos previos de Route.

Por eso, el vector no era la lista forense de saltos. Era una declaración ordenada sobre cómo debía encaminarse el tráfico posterior. Una captura acredita los valores presentes en el punto observado, pero no acredita que todos los proxies recorridos aparezcan, que todos los listados hubieran sido recorridos o que la solicitud futura reproduzca esa geometría.

Un registro operativo serio conserva cuatro objetos: el recorrido observado de REGISTER, el Path declarado, el estado finalmente almacenado y la Route materializada en una solicitud posterior. Entre ellos puede haber omisiones, sustituciones, reordenamientos y política local. La diferencia es información, no ruido que deba normalizarse.

Via conserva el retorno de respuestas dentro de una transacción. Record-Route crea el conjunto de ruta del diálogo que está naciendo. Path se aprende durante el registro para diálogos futuros. Service-Route, en RFC 3608, comunica al agente de usuario el camino que debe emplear para solicitudes salientes de servicio; Path comunica al lado doméstico el camino hacia un Contact. Ninguno es un alias del otro.

Ver el Path aceptado no equivalía a confiar en él

El registrador devolvía el vector en la respuesta satisfactoria. El agente de usuario normalmente no construía su ruta con ese campo y podía ignorarlo, pero tenía la oportunidad de inspeccionarlo. Si aparecía un proxy inesperado, podía detectar que alguien pretendía permanecer en todas las solicitudes futuras hacia ese registro.

La amenaza era persistente. Un proxy malicioso que lograra insertarse no solo observaba REGISTER; adquiría una posición para interceptar tráfico mientras viviera la asociación. Eliminar una URI podía evitar un control de acceso. Alterar el orden podía cambiar quién veía primero una llamada. Aceptar una transformación sin recibo podía convertir una avería de política en un hecho invisible.

RFC 3327 recomendó mecanismos apropiados de integridad y autenticación mutua. No eran una garantía universal. La integridad validada puede demostrar que ciertos bytes no cambiaron entre pares identificados. No demuestra que el nodo sea honrado, que estuviera en el recorrido anterior, que siga disponible o que la ruta se ejecute después. La reflexión permite comparar; no bendice el contenido.

La norma también desaconsejó que el propio agente de usuario generara Path. Otros proxies podían creer que aquella URI procedía de un proxy y esperar luego que el dispositivo actuara como tal. El origen de una afirmación forma parte de su significado. Copiar solo el valor y perder al autor cambia la autoridad que los demás le atribuyen.

Las especificaciones posteriores delimitaron el mismo terreno

RFC 3327 se publicó en diciembre de 2002 y RFC 5626 lo actualizó. SIP Outbound añadió una arquitectura para flujos mantenidos por agentes detrás de fronteras de red y para proxies de borde. La actualización relacionó mejor el registro con el flujo utilizable; no convirtió Path en un historial exhaustivo.

RFC 5627 definió GRUU para identificar de manera enrutable una instancia de agente. RFC 3680 creó notificaciones de eventos de registro. RFC 5922 trató certificados de dominio SIP. El registro de parámetros SIP de IANA conserva los nombres protocolarios. Estas fuentes prueban contratos y evolución documental, no adopción, despliegue ni disponibilidad efectiva.

La lección histórica es más amplia que la telefonía. Identidad, localizador, ruta obligatoria e historia observada son estados distintos. Mezclarlos produce bases de datos convincentes y decisiones incorrectas. RFC 3327 hizo almacenable el estado que faltaba. Su precisión depende de seguir llamándolo ruta declarada para el futuro, no prueba del pasado.

Fuentes