"Introducción Hay muchos entornos para implementaciones SIP [RFC3261] en los que el agente de usuario (UA) puede formar una conexión con un registrador o proxy, pero en los que las conexiones en dirección inversa al UA no son posibles. Esto puede suceder por varias razones @ pero lo más probable es que sea un NAT o un firewall entre SIP UA y el proxy. Muchos de estos dispositivos solo permitirán conexiones salientes. Esta especificación permite que un agente de usuario SIP detrás de dicho firewall o NAT reciba tráfico entrante asociado con registros o diálogos que inicia. La mayoría de los teléfonos IP y computadoras personales obtienen sus configuraciones de red dinámicamente a través de un protocolo como el Protocolo de configuración dinámica de host (DHCP) [RFC2131]. Estos sistemas generalmente no tienen un nombre útil en el Sistema de nombres de dominio (DNS). [RFC1035]@ y casi nunca tienen un nombre DNS estable a largo plazo@ que sea apropiado para su uso en el sujetoAltName de un certificado@ como lo requiere [RFC3261]. Sin embargo@ estos sistemas aún pueden actuar como Seguridad de la capa de transporte (TLS). ) [RFC5246] cliente y formar conexiones salientes a un proxy o registrador que se autentica con un certificado de servidor. El servidor puede autenticar la UA utilizando un secreto compartido en un desafío de resumen (como se define en la Sección 22 de RFC 3261) a través de esa conexión TLS. Esta especificación permite que un agente de usuario SIP que tiene que iniciar la conexión TLS reciba tráfico entrante asociado con registros o diálogos que inicia. La idea clave de esta especificación es que cuando un UA envía una solicitud de REGISTRO o una solicitud de formación de diálogo, el proxy puede luego usar este mismo ""flujo"" de red, ya sea un flujo bidireccional de datagramas UDP o una conexión TCP. @ o un concepto análogo en otro protocolo de transporte: para reenviar cualquier solicitud entrante que deba ir a esta UA en el contexto del registro o diálogo. Para que una UA reciba solicitudes entrantes @ la UA debe conectarse a un servidor. Dado que el servidor no puede conectarse a la UA @, la UA debe asegurarse de que siempre haya un flujo activo. Esto requiere que la UA detecte cuando falla un flujo. Dado que dicha detección lleva tiempo y deja una ventana de oportunidad para solicitudes entrantes perdidas, este mecanismo permite que la UA se registre en múltiples flujos al mismo tiempo. Esta especificación también define dos esquemas de mantenimiento de actividad. El mecanismo de mantenimiento de actividad se utiliza para mantener actualizados los enlaces NAT y permitir que la UA detecte cuando un flujo ha fallado".
RFC 5626-2009 Historia
2009RFC 5626-2009 Gestión de conexiones iniciadas por el cliente en el protocolo de inicio de sesión (SIP) (Actualizaciones: 3261@ 3327)