Resumen

  • rport permite pedir que la respuesta SIP vuelva a la dirección y el puerto desde los que llegó realmente la solicitud. La recepción demuestra el recorrido de esa transacción sobre el mapeo vigente, no una vía futura.
  • Dirección observada, mapeo NAT, flujo, registro, transacción, diálogo y resultado tienen relojes distintos. Una plataforma que los reduce a «alcanzable» no podrá explicar por qué el siguiente nodo o la siguiente solicitud fallaron.

El primer nodo recibe un INVITE y ve como origen 192.0.2.1:9988. Responde desde el mismo socket, el NAT reconoce el flujo y el terminal obtiene el resultado. El segundo nodo consulta el mismo registro y envía una solicitud al mismo par público. No llega.

Desde la aplicación, ambos nodos pertenecen a un servicio. Desde un NAT simétrico, son pares remotos diferentes. La primera operación contaba con una abertura que acababa de crear el cliente; la segunda esperaba que una dirección observada funcionara como identidad y como autorización de entrada.

RFC 3581, publicada en agosto de 2003 en la vía Standards Track, resolvió el retorno de la primera transacción. Su análisis de IAB dejó escrito que reutilizar esa observación para registro o Record-Route era otra operación, frágil y necesitada de una salida técnica mejor.

La regla híbrida mezclaba paquete y declaración

SIP sobre UDP formaba originalmente el destino de respuesta con dos fuentes. Tomaba la dirección IP del paquete recibido y el puerto del sent-by del Via superior. Era útil para mantener un punto de escucha común, pero un NAT podía cambiar dirección y puerto. El resultado combinaba una dirección exterior verdadera con un puerto interior que ya no era alcanzable.

El cliente que soporta la extensión inserta rport vacío. No adivina su puerto público. Solicita que el receptor complete el dato. El servidor escribe el puerto fuente observado en rport y la dirección en received, incluso si coincide con la dirección anunciada.

Si el transporte es unicast no fiable, no hay maddr y están presentes ambos parámetros, la respuesta debe ir a received:rport. Además, debe salir de la misma dirección y puerto del servidor que recibieron la solicitud. Esa simetría de origen importa tanto como el destino cuando el traductor identifica el flujo por ambos extremos.

La autoridad del mecanismo termina ahí: una observación de red gobierna la respuesta asociada a esa solicitud.

Un valor correcto puede caducar sin volverse falso

El par público puede ser correcto al mediodía y no servir un minuto después. El puerto puede reasignarse, el equipo puede reiniciarse o la política del NAT puede cerrar el estado por silencio. Nada de eso cambia el Address-of-Record ni obliga a modificar Contact.

También hay grados de prueba. rport vacío prueba una petición de comportamiento. El valor numérico en una respuesta prueba lo que el servidor anotó. La recepción por el cliente prueba que esa respuesta terminó el recorrido. Ninguno de los tres hechos dice cuánto durará el mapeo o si otro origen será admitido.

Por eso el recibo mínimo incluye branch, Call-ID, CSeq, Via original y mutado, par fuente en el cable, instancia del proxy, interfaz de entrada, socket de salida, estado de respuesta y confirmación del cliente. «Último puerto» sin observador, momento y transacción es un dato sin jurisdicción.

La ausencia de estado no elimina la procedencia

Un servidor con varias interfaces debe recordar en cuál llegó la solicitud. Un proxy stateful guarda ese dato mientras vive la transacción. Uno stateless puede codificar la dirección y el puerto necesarios en el Via que añade y recuperarlos al volver la respuesta.

La diferencia es dónde reside el estado, no si existe evidencia. Cuando la telemetría conserva solo el nombre del clúster, borra el socket que el NAT reconoció. Un balanceador puede considerar intercambiables a dos miembros, mientras el camino exterior acepta solo uno.

El operador necesita separar tres afirmaciones: el clúster tiene capacidad, una instancia está sana y esta transacción conserva una ruta simétrica. La primera no demuestra la tercera.

La transacción puede durar más que el mapeo

RFC 3581 exige que el enlace NAT permanezca mientras dure la transacción. Las operaciones no INVITE parecían caber normalmente en los tiempos UDP de la época. Un INVITE, en cambio, puede esperar una respuesta final durante un periodo arbitrario. El texto aconseja seguir retransmitiéndolo incluso tras una respuesta provisional para refrescar el estado.

Esa necesidad desmonta la idea de permanencia. El par observado no contiene una fecha de vencimiento. Una respuesta provisional no es un arrendamiento. El registro puede seguir válido cuando la única abertura de red ya se cerró.

La RFC citó el descubrimiento de vida del mapeo de RFC 3489 y avisó de su falta de fiabilidad. RFC 5389 hizo obsoleta a RFC 3489 y RFC 8489 reemplazó después a RFC 5389. No corresponde presentar un supuesto de 2003 como medida contemporánea. Hay que guardar tráfico observado, último éxito, frecuencia de refresco e incertidumbre.

Contact no adquiere las condiciones ocultas del NAT

Al leer received y rport, el cliente conoce el par que vio el servidor. Puede intentar publicarlo en Contact o emplearlo en Record-Route. RFC 3581 trata ese uso como UNSAF y enumera por qué no constituye una solución estable.

Mantener la abertura puede requerir re-registros casi cien veces más frecuentes que un registro normal. En NAT simétrico, solo el servidor original puede ser un origen aceptado. Si REGISTER llegó a un proxy que luego habló con el registrar, la solicitud futura debe pasar por ese proxy; Path, en RFC 3327, expresa esa dependencia.

El número de rport no incluye el remoto permitido, el vencimiento, la afinidad de clúster ni la identidad del proxy de borde. Publicarlo como dirección global convierte condiciones operativas en supuestos invisibles.

La salida propuesta por la propia RFC pedía recibir solicitudes sobre la conexión o flujo iniciado por el cliente, soportar clústeres y evitar una carga excesiva. RFC 5626 desarrolló SIP Outbound con flujos asociados al registro, varios caminos, keepalives y detección de fallo. RFC 6314 lo recomendó para la práctica cliente-servidor a través de NAT.

Las piezas posteriores no son sinónimos. RFC 6223 negocia keepalive pero niega que eso defina reutilización. RFC 5923 aborda solicitudes inversas sobre transportes orientados a conexión. RFC 5627 ofrece GRUU estables para una instancia. Un pong no selecciona un registro, un flow token no autoriza al usuario y una URI estable no prueba que el teléfono sonó o tuvo medios.

Seguridad de señalización no equivale a autoridad sobre el par

RFC 3581 reconoce que dirección y puerto observados pueden ser sensibles y propone SIP sobre TLS para proteger la señalización. En TCP/TLS, rport informa sobre el puerto visto; no es la causa de que una respuesta UDP atraviese el traductor.

Un intermediario que elimine rport puede negar servicio al cliente NAT. La integridad evita la manipulación, pero no identifica al dueño del puerto público ni conserva el mapeo. El registro IANA coordina el nombre del parámetro; no certifica soporte, procesamiento correcto ni disponibilidad.

Cada tramo requiere su recibo: autenticación para identidad, observación de cable para el par, socket e instancia para la respuesta, Path o flujo para el futuro, estado del registrar para elegir Contact, Route set para el diálogo y pruebas aparte para alerta, respuesta, medios y resultado de aplicación.

Límite de evidencia

Este Artículo no identifica operador, PBX, proveedor SIP, agente, proxy, registrar, fabricante NAT, clúster, usuario, llamada, incidente ni resultado de medios. Standards Track no demuestra cuota de adopción.

RFC 3261 da la base de Via y transacciones; RFC 3327, Path; RFC 3424, el marco UNSAF. RFC 3489 es contexto histórico, y RFC 5389 y RFC 8489 muestran la evolución de STUN. RFC 5626, RFC 6314, RFC 5923, RFC 6223 y RFC 5627 delimitan Outbound, práctica NAT, reutilización, keepalive y rutas estables. IANA no sustituye al comportamiento observado.

Running-Code Primacy y Minimum Initial Specification, de Heng Lu, son lentes editoriales declaradas. Sirven para verificar el camino que funcionó y mantener mínima la regla común. No prueban la intención de los autores ni un despliegue.

La conclusión es deliberadamente pequeña: una respuesta encontró un puerto en un instante. Conservar ese recibo permite aprender; llamarlo ruta futura impide saber qué falló después.

Fuentes