Resumen

  • Una respuesta satisfactoria a REGISTER puede contener un vector Service-Route ordenado. El agente de usuario puede guardarlo y usarlo más tarde como Route precargado.
  • Ese vector pertenece al libro de la intención. Para afirmar tránsito, ejecución de servicio o éxito de sesión hacen falta observaciones posteriores y separadas.

Publicado en la vía de estándares en octubre de 2003, RFC 3608 define una extensión de SIP y su ciclo de vida; no es una medición de la red actual de ningún operador.

Las operaciones de red se equivocan a menudo por falta de contabilidad conceptual. Guardan una lista de proxies, ven un registro SIP en verde y concluyen que la comunicación cruzó la infraestructura prevista. Pero hay al menos tres libros. Uno anota lo que el registrador propuso. Otro anota por dónde avanzó una transacción concreta. El tercero anota qué servicio se ejecutó y con qué resultado. RFC 3608 solo crea la primera anotación.

El mecanismo tiene una finalidad acotada. Tras un REGISTER exitoso, el registrador puede incluir Service-Route. El agente de usuario puede asociar la lista a una dirección de registro y, en una solicitud inicial futura originada por él, copiarla a Route conservando el orden. Así descubre proxies del dominio de origen sin una configuración previa idéntica en cada terminal.

La palabra “puede” impide convertir posibilidad en historia. El terminal puede no enviar ninguna solicitud. Puede elegir no ejercer la ruta. Puede combinarla con una ruta local necesaria para salir de la red visitada. Puede tener varias identidades y seleccionar otro contexto. Una base de datos que conserva el vector no observa ninguna de esas decisiones.

El tiempo también cambia el significado. RFC 3608 indica que un nuevo registro exitoso actualiza el valor; si la respuesta no trae Service-Route, el terminal elimina el anterior. Un rechazo o la expiración sin renovación deben invalidarlo. Por tanto, no existe “la ruta” en abstracto. Existe la ruta de una respuesta concreta, con Call-ID, CSeq, identidad, contacto, hora, expiración y sucesores.

Service-Route tampoco debe mezclarse con Path. RFC 3327 permite que proxies anoten Path durante el REGISTER para que, más adelante, solicitudes del dominio de origen puedan alcanzar el contacto registrado. RFC 3608 comunica al terminal una ruta para las solicitudes que salen de ese terminal. Una mira hacia el contacto; la otra ofrece acceso a servicios de origen. La similitud sintáctica no autoriza a borrar la dirección funcional.

El segundo libro comienza cuando existe una solicitud real. El Route que sale del terminal muestra una intención procesable. Cada proxy puede consumir o modificar la ruta conforme a SIP, y añade Via al reenviar la transacción. Via aporta observación del reenvío y la vía de retorno de respuestas. Aun así, ni una lista Route original ni una cadena Via aislada demuestran por sí solas que un servicio interno del proxy se haya ejecutado.

Entre ambas aparece DNS. RFC 3263 define cómo localizar servidores SIP mediante registros y reglas de transporte. Una misma URI puede resolverse a destinos diferentes a medida que vencen TTL, cambian prioridades o fallan endpoints. El nombre del proxy es una referencia; no es una identidad física eterna. Si no se conserva la respuesta DNS y la selección efectiva, la ruta nominal no explica qué nodo recibió el tráfico.

Los flujos de RFC 5626 y la reutilización de conexiones de RFC 5923 agregan datos operativos valiosos. Permiten hablar de una relación de transporte mantenida o reutilizada. No prueban automáticamente que la solicitud investigada viajó por ella. Igual que un puente abierto no prueba qué automóvil lo cruzó, una conexión activa no identifica todas las transacciones que se le atribuyen.

La integridad del Service-Route es otro libro, no un atajo. RFC 3608 advierte que un intermediario podría insertar o alterar valores y recomienda autenticación e integridad. Verificar la respuesta permite afirmar con más fuerza qué propuso el registrador. No puede garantizar que, minutos después, la resolución, la política local y la disponibilidad del transporte sigan siendo iguales.

Una cadena probatoria útil empieza con el recibo de configuración: mensaje REGISTER completo, vector ordenado, identidad del registrador, resultado criptográfico, dirección de registro, contacto, hora y expiración. Continúa con el recibo de intención: la solicitud realmente construida después de aplicar reglas locales. Sigue con el recibo de resolución: respuestas DNS, TTL, endpoint, transporte y reintentos.

Después vienen observaciones de tránsito correlacionadas por transacción y tiempo. Un Session-ID conforme a RFC 7989 puede ayudar a relacionar piezas entre elementos, pero no sustituye el registro que falta. El componente de servicio debe dejar su propio recibo: política aplicada, versión, decisión y error. El resultado final necesita otra evidencia: código SIP, diálogo y, si corresponde, media o efecto de aplicación.

La separación revela fallos que un único indicador ocultaría. El registrador puede proponer una ruta equivocada. El cliente puede conservar una generación caducada. DNS puede dirigir a una instancia indisponible. El proxy puede reenviar correctamente y omitir el servicio. La señalización puede completarse y la media fallar. Todos esos escenarios pueden coexistir con un REGISTER 200.

No se exige almacenar cada paquete para siempre. Se exige decir la verdad sobre lo que se conserva. Una organización puede limitar plazos, muestrear, anonimizar y aplicar controles de acceso. Si decide guardar solo la respuesta del registrador, podrá demostrar solo la propuesta del registrador.

RFC 3608 funciona bien como especificación mínima: define cómo expresar y renovar una sugerencia de ruta común. Las decisiones futuras permanecen donde deben, en el código del terminal y de la red. La gobernanza se degrada cuando el registro administrativo reclama autoridad sobre un recorrido que solo los sistemas en ejecución podían producir.