Travesía de NAT con controladores de borde de sesión

Los traductores de direcciones de red (NAT) se utilizan para superar la falta de disponibilidad de direcciones IPv4 ocultando la red de una empresa o incluso de un operador tras una o pocas direcciones IP . Los dispositivos detrás del NAT utilizan direcciones IP privadas que no son enrutables en la Internet pública. El Protocolo de Inicio de Sesión (SIP) se ha establecido como el estándar de facto para la comunicación de voz sobre IP (VoIP). ^{[ 1 ]} Para establecer una llamada, quien llama envía un mensaje SIP que contiene su propia dirección IP. Se espera que quien recibe la llamada responda con un mensaje SIP dirigido a las direcciones IP incluidas en el mensaje SIP recibido. Obviamente, esto no funcionará si quien llama está detrás de un NAT y utiliza una dirección IP privada.

Probablemente el mayor error en el diseño de SIP fue ignorar la existencia de NAT. Este error surgió de la creencia en el liderazgo de IETF de que el espacio de direcciones IP se agotaría más rápidamente y requeriría una actualización global a IPv6 y eliminaría la necesidad de NAT. El estándar SIP asumió que las NAT no existían, una suposición que resultó ser un fracaso. SIP simplemente no funcionó para la mayoría de los usuarios de Internet que se encuentran detrás de NAT. Al mismo tiempo, se hizo evidente que el ciclo de vida de la estandarización es más lento que el ritmo del mercado: nacieron los controladores de borde de sesión (SBC) ^{[ 2 ]} y comenzaron a solucionar lo que los estándares no lograron hacer: el recorrido de NAT .

Si un agente de usuario se encuentra detrás de un NAT, utilizará una dirección IP privada como dirección de contacto en los encabezados de contacto y vía, así como en la parte SDP . Esta información resultaría inútil para cualquier persona que intente contactar con dicho agente de usuario desde Internet.

Existen diferentes soluciones para la superación de NAT, como STUN , TURN e ICE. ^{[ 3 ]} La solución a utilizar depende del comportamiento de NAT y del escenario de la llamada. Al usar un SBC para resolver los problemas de superación de NAT, el enfoque más común para el SBC es actuar como la interfaz pública de los agentes de usuario. ^{[ 4 ]} Esto se logra reemplazando la información de contacto del agente de usuario con la del SBC.

Para que un agente de usuario sea accesible a través de las interfaces públicas de un SBC, este manipula la información de registro del agente. El usuario incluye su dirección IP privada como información de contacto en las solicitudes REGISTER . Las llamadas a esta dirección fallarán, ya que no es públicamente enrutable. El SBC reemplaza la información del encabezado de contacto con su propia dirección IP. Esta es la información que se registra posteriormente en el registrador. Las llamadas dirigidas al usuario se redirigirán entonces al SBC.

Para que el SBC sepa qué agente de usuario se está contactando realmente, puede mantener una copia local del registro del agente de usuario. Esta copia local incluye la dirección IP privada y la URI SIP del usuario , así como la dirección IP pública incluida en el encabezado IP asignado al mensaje SIP por el NAT.

Alternativamente, el SBC puede almacenar esta información en los mensajes SIP reenviados. Esto se muestra en la figura. La información de contacto del usuario se combina en un formato especial y se agrega como un parámetro adicional al encabezado de contacto. Esta información incluye la dirección IP privada del usuario y la URI SIP, así como la dirección IP pública en el encabezado IP del mensaje SIP. Cuando el registrador recibe una solicitud del usuario, devuelve la información de contacto completa al proxy, que la incluye en el mensaje SIP. El SBC puede entonces recuperar esta información de la solicitud SIP y usarla para enrutar correctamente la solicitud al usuario.

Agregar la información de contacto del agente de usuario a la información de contacto registrada tiene muchas ventajas. Dado que el SBC no necesita almacenar información de registro local, esta solución es sencilla de implementar y no requiere memoria para guardar la información. Además, las solicitudes dirigidas al agente de usuario no necesariamente tienen que pasar por el SBC que procesó los mensajes de registro del agente de usuario. Cualquier SBC que pueda llegar al agente de usuario puede enrutar correctamente los mensajes dirigidos a este basándose en la información incluida en la solicitud SIP. Sin embargo, esta ventaja solo se aplica en algunos casos. Si el NAT utilizado delante del agente de usuario solo acepta tráfico de las direcciones IP con las que el agente de usuario se ha comunicado previamente, entonces solo el SBC que procesó las solicitudes REGISTER del agente de usuario podrá comunicarse con él.

La otra opción es mantener una copia local de la información de registro, lo que, sin embargo, puede aumentar los requisitos de procesamiento en la SBC. La SBC tendrá que gestionar una base de datos de registro local. Además de los requisitos de memoria, la SBC tendrá que replicar esta información en un sistema de respaldo para garantizar una alta disponibilidad. Esto incrementará aún más los requisitos de procesamiento en la SBC y el consumo de ancho de banda.

Sin embargo, conservar una copia local de la información de registro también tiene sus ventajas. Al recibir un mensaje de un agente de usuario, un traductor de direcciones de red (NAT) vincula la dirección IP privada del agente de usuario a una dirección IP pública. Esta vinculación permanece activa durante un período de tiempo determinado. Si el agente de usuario no envía ni recibe mensajes durante un período superior al de la vinculación, el NAT elimina la vinculación y el agente de usuario deja de ser accesible desde el exterior. Para mantener la vinculación activa, el agente de usuario debe actualizarla periódicamente. Esto se consigue enviando solicitudes REGISTER a intervalos de tiempo inferiores al período de vinculación. Dado que los mensajes REGISTER suelen requerir autenticación, gestionar su envío frecuente supondría una importante carga para el rendimiento de la infraestructura del operador. Los SBC pueden ayudar a aliviar esta carga. Cuando un agente de usuario envía la primera solicitud REGISTER, el SBC la reenvía a los servidores de registro del operador. Una vez que el registro se ha autenticado y aceptado correctamente por el operador, el SBC conserva una copia local de la información de registro. En lugar de reenviar cada solicitud REGIETER entrante a los servidores de registro del operador, el SBC solo enviará solicitudes REGISTER a dichos servidores a intervalos de tiempo bastante amplios (del orden de horas). Las solicitudes de registro provenientes del agente de usuario que no modifiquen la información de registro de contenido serán respondidas por el propio SBC. El SBC también informará al servidor de registro cuando el registro local caduque o cambie.

De forma similar al caso de registro, el SBC también se incluirá en la ruta de los mensajes INVITE y otras solicitudes. Al recibir un INVITE de un agente de usuario detrás de un NAT, el SBC incluirá una cabecera "via" con su propia dirección, reemplazará la información de la cabecera "contact" con su propia dirección y también reemplazará la información de la dirección en el cuerpo SDP con su propia dirección. De este modo, todos los mensajes SIP y paquetes multimedia pasarán por el SBC.

Después de establecer una llamada usando SIP, se intercambian paquetes de medios, es decir, voz, video o datos, generalmente usando el Protocolo de Transporte en Tiempo Real (RTP). Si bien el recorrido de NAT de los mensajes SIP puede parecer complicado, la tarea aún más compleja es permitir que los medios atraviesen NAT. El planteamiento inicial del problema es el mismo. Si los dispositivos SIP detrás de NAT anuncian sus direcciones IP, sus pares al otro lado de NAT no pueden enrutar el tráfico hacia ellos. La solución que surgieron con los SBC simplemente ignora la forma en que funciona SIP. En lugar de enviar medios a la dirección IP y número de puerto anunciados en los cuerpos SDP de SIP, los SBC envían medios para un agente de usuario simétricamente de vuelta a donde el agente ha enviado sus propios medios. Esta comunicación simétrica generalmente funciona porque es el patrón de tráfico al que los fabricantes de NAT estaban acostumbrados antes de la llegada de VoIP .

Es importante saber que, si bien esto funciona en la mayoría de los casos, tiene varias limitaciones. En primer lugar, solo funciona con clientes configurados de forma simétrica, es decir, que utilizan el mismo puerto para enviar y recibir contenido multimedia. Afortunadamente, hoy en día esto representa la mayoría de los equipos disponibles.

Otra desventaja notable es el enrutamiento triangular : un SBC debe retransmitir todo el tráfico VoIP de una llamada para que las rutas entre el emisor y el SBC, y entre el SBC y el receptor, sean simétricas. Esto supone una sobrecarga considerable para un operador de VoIP. Con el códec más común, G.711 , una llamada retransmitida consume cuatro  flujos de 87,2 kbit/s: dos de salida y dos de entrada.

También pueden presentarse otras limitaciones preocupantes. Por ejemplo, si un dispositivo SIP utiliza la detección de actividad de voz (VAD) y no envía ningún paquete de voz inicialmente, el SBC no aprenderá su dirección y tampoco le reenviará los medios entrantes.