Resumen

  • Un agente SIP podía iniciar tráfico hacia un servidor sin que este pudiera abrir una nueva conexión de regreso. Outbound permitió entregar nuevas peticiones mediante los flujos que había establecido el cliente.
  • La dirección del usuario, la identidad persistente de su dispositivo y el registro de cada flujo cumplen funciones distintas. Varias rutas de una misma instancia no deben convertirse en varios destinatarios simultáneos.
  • El código 430 señala un flujo fallido. Tras otras respuestas finales, salvo la excepción 408, no se puede volver a enviar la misma petición a esa instancia por otra ruta como si aún no hubiera contestado.

La tabla había crecido; el número de aparatos, no

Imaginemos dos registros válidos bajo la misma dirección de usuario. Ambos tienen un Contact y ambos prometen una forma de alcanzar un terminal. Sería fácil tratarlos como dos lugares a los que conviene enviar una llamada. Pero podrían pertenecer al mismo teléfono, conectado a través de dos proxies distintos para resistir la pérdida de uno.

El RFC 5626, publicado en octubre de 2009, convirtió esa diferencia en una regla de encaminamiento. Un proxy no debe incluir a la vez más de un Contact con la misma dirección de registro y el mismo identificador de instancia en su conjunto de destinos. Dos caminos hacia el mismo aparato no son dos aparatos.

La regla no impide que una persona tenga varios teléfonos ni elimina todas las formas de bifurcación de SIP. Impide algo más concreto: duplicar un destinatario porque su conectividad se ha hecho redundante. Para aplicarla, el sistema necesita identificar al dispositivo por algo más duradero que la dirección escrita en un registro.

El estado vivo tenía más de un reloj

Los registros vencen y se renuevan. Los NAT mantienen asociaciones que pueden desaparecer. Las conexiones pueden cerrarse. Un solo indicador de «conectado» no representa todos esos hechos.

El RFC 5626 permite conservar una conexión que sigue contestando a las comprobaciones de actividad aunque una renovación del registro haya encontrado un error recuperable. También exige considerar fallido un flujo UDP si cambia la dirección pública indicada en una respuesta STUN. Puede llegar una respuesta y, precisamente por su contenido, quedar demostrado que la asociación anterior ya no es la misma.

Las comprobaciones STUN se dirigen al siguiente salto SIP, no verifican por sí solas la llegada de una llamada al usuario ni el recorrido del audio. Requieren una indicación explícita de soporte; una opción ambigua de «usar NAT» no autoriza a enviar mensajes binarios a cualquier puerto SIP.

En 2011, el RFC 6223 introdujo el parámetro Via keep para negociar esas comprobaciones entre vecinos. Declara expresamente que no define un mecanismo de reutilización de conexiones. Mantener una asociación abierta y autorizar peticiones de vuelta son decisiones relacionadas, pero distintas.

La recuperación también tiene ritmo. Si queda otra ruta, reconstruir la redundancia no tiene la misma urgencia que recuperar todos los flujos perdidos. Outbound utiliza espera exponencial y aleatoria, con parámetros configurables, para limitar la avalancha de clientes que podrían reconectarse a la vez tras volver un servidor. No hay una garantía de disponibilidad escondida en esos temporizadores.

La evolución conservó las separaciones

El RFC 5923, de 2010, describe alias para reutilizar conexiones TLS entre vecinos que pueden iniciarlas en cualquiera de los dos sentidos. No sustituye a Outbound donde solo el cliente puede abrir el camino. La autenticación y la política del receptor siguen importando; una conexión persistente no implica automáticamente reutilización inversa.

El RFC 5627 trata otra necesidad: una URI globalmente utilizable que señale una instancia concreta. En una transferencia, utilizar el AOR podría dirigir la nueva llamada al buzón o a otro aparato. GRUU proporciona una forma de pedir aquel terminal, mientras Outbound aporta rutas para alcanzarlo. El nombre de la instancia y el token del flujo no son intercambiables.

La diferencia se hizo especialmente visible en el escenario de navegador del RFC 7118, de 2014. Su guía permite construir Contact con un nombre aleatorio bajo .invalid cuando el cliente ha solicitado y recibido soporte Outbound. El navegador no conoce necesariamente su dirección de transporte local; las peticiones llegan mediante el proxy WebSocket y el flujo existente. Es una condición de ese escenario, no una regla que vuelva alcanzable cualquier dirección inválida. El transporte del medio queda fuera del documento.

El registro de parámetros SIP de IANA conserva los nombres y las referencias de estas piezas. No acredita su adopción universal ni la independencia de los caminos de un operador. La lección histórica es más concreta: para añadir una segunda ruta sin añadir un segundo destinatario, el protocolo tuvo que aprender a contar la cosa correcta.

El problema comenzaba antes de la segunda ruta

En el modelo de registro del RFC 3261, de junio de 2002, una dirección de referencia, o AOR, se asocia con uno o más Contacts. Un proxy consulta el servicio de localización para decidir hacia dónde dirigir una petición. El registrador administra esas correspondencias; ambas funciones pueden estar en la misma máquina.

La asociación es útil, pero no abre por sí misma una entrada en un cortafuegos. Un terminal detrás de un NAT puede iniciar una conexión hacia fuera y, aun así, resultar inaccesible cuando el servidor intenta empezar otra en sentido inverso. Tampoco todos los teléfonos disponen de un nombre estable y de la identidad certificada que les permitirían actuar como servidores TLS.

El matiz no consiste en que SIP careciera de respuestas por la conexión original. Ya las enviaba por ella, en transportes fiables, si seguía abierta. El problema era una petición posterior: una nueva llamada no es la respuesta a REGISTER. Haber recibido la confirmación del registro no explica cómo llegará el siguiente INVITE.

Outbound aprovecha el flujo iniciado por el terminal. En TCP, un flujo equivale a una conexión. En UDP es una asociación de direcciones, puertos y protocolo entre los dos extremos. Su denominador común no es la existencia de una sesión TCP, sino que el servidor conoce una asociación concreta por la cual puede enviar tráfico al agente.

La dirección pública no contaba toda la historia

Si el registro pasa por un proxy de borde, el servidor necesita recordar ese paso para las peticiones futuras. El RFC 3327, de diciembre de 2002, introdujo Path para acumular la secuencia pertinente de proxies durante el registro y conservarla con la asociación. Después, el proxy del dominio utiliza esa información como ruta precargada.

Path no es Record-Route con otro nombre. REGISTER no establece un diálogo, y la información Record-Route que pudiera contener no crea su ruta. Path sirve para llegar al terminal en peticiones futuras que pasan por el dominio de origen; el diálogo que llegue a establecerse necesita su propio encaminamiento posterior.

Outbound exige además que el primer proxy junto al cliente identifique el flujo correcto. Introduce un token en su URI de Path, junto con el parámetro ob correspondiente. Al regresar una petición, ese proxy puede pasar de «la solicitud debe atravesarme» a «debe salir por esta asociación con el terminal».

El token ha de permitir recuperar el flujo y resistir modificaciones maliciosas. El algoritmo ilustrativo del RFC no es la única implementación autorizada. Y el token no es una identidad universal del usuario: solo cobra sentido dentro de una cadena de registro y encaminamiento que conserva las relaciones necesarias.

Un identificador permanecía; el otro distinguía las salidas

Outbound separa instance-id y reg-id. El primero identifica una instancia de agente de usuario y permanece estable tras un reinicio o un cambio de red. El segundo distingue los flujos registrados simultáneamente por esa instancia.

El dispositivo vuelve a utilizar la misma secuencia de reg-id después de reiniciarse. La coincidencia es deliberada: permite que la nueva información sustituya al registro anterior de ese flujo. Inventar números nuevos en cada recuperación podría dejar atrás correspondencias caducas, como si cada reconexión hubiese añadido otro teléfono.

La clave de la asociación pasa a ser AOR, instance-id y reg-id. Contact continúa almacenado porque sigue haciendo falta al construir el conjunto de destinos; no se borra ni pierde toda función. Lo que deja de hacer es representar, por sí solo, todas las decisiones sobre identidad y sustitución.

Esta separación también tiene una condición de seguridad. El RFC advierte que guardar solo instance-id, sin relacionarlo con el AOR autenticado, permite que otro agente suplante ese identificador. Un nombre persistente no es una credencial para recibir las llamadas de una cuenta.

La llamada podía encontrar la avería antes que el teléfono

El ejemplo del RFC 5626 empieza con un terminal registrado mediante dos proxies de borde. Uno se cae y reinicia. Antes de que el teléfono descubra que ha perdido su flujo, llega una llamada nueva.

El proxy de borde ya no tiene la asociación a la que apunta el token y devuelve 430 Flow Failed. El proxy responsable del usuario puede probar otro registro de la misma instancia, con un reg-id distinto. En el ejemplo, el segundo borde entrega la petición y añade la información necesaria para que las peticiones del nuevo diálogo sigan esa ruta. La reparación del registro roto llega después, cuando el terminal detecta la pérdida.

Es una secuencia hipotética de la especificación, no un informe de una caída real. Enseña cómo recuperar una nueva petición mientras la detección del cliente aún está pendiente. No promete que cualquier diálogo ya establecido se traslade sin consecuencias: los procedimientos concretos de encaminamiento dentro del diálogo no quedan completamente definidos por esa extensión.

430 describe una avería de camino, no una decisión de quien iba a recibir la llamada. Está pensado para circular entre proxies, no para llegar al terminal; si lo recibe, este lo trata como 400. Un token alterado tiene otra respuesta recomendada, 403. Clasificar todos esos casos como «usuario no disponible» borraría la información que permite recuperarse correctamente.

La respuesta también debía cerrar posibilidades

La especificación permite buscar otra ruta cuando falla un flujo, pero pone un límite una vez obtenida una respuesta final. Si no es 408 ni 430, la misma petición no debe enviarse a otra dirección que represente el mismo AOR y la misma instancia. Esa instancia ya ha respondido.

No es una prohibición general de llamar otra vez en el futuro. Tampoco significa que todas las respuestas finales sean iguales para el resto de SIP. Es una regla sobre la misma petición y las rutas alternativas hacia el mismo dispositivo.

Su lógica evita que la redundancia se convierta en insistencia. Cuando una ruta no entrega, otra puede ayudar. Cuando el teléfono contesta, cambiar de ruta no convierte su contestación en un fallo de transporte. Un diseño que solo mida cuántas veces logra volver a enviar perdería esta distinción.