STUN, TURN, ICE: los tres mosqueteros de SIP
Existe la opinión de que las palabras que aparecen al principio del encabezado significan lo mismo (como si SIP y VoIP, así como dialers y softphones, se fusionaran en la conciencia de las masas). Sin embargo, no es así: STUN, TURN e ICE son protocolos diferentes que resuelven la misma tarea de enrutamiento más allá de los cortafuegos y NAT (Network Address Translation). La elección del protocolo adecuado depende de la configuración de la red, los requisitos de seguridad y otros factores.
Centrémonos brevemente en estas tecnologías.
STUN
STUN (Session Traversal Utilities for NAT) es un protocolo cliente-servidor que proporciona una herramienta para que los hosts detecten la presencia de un traductor de direcciones de red y cortafuegos. Los STUN-clientes envían solicitudes de enlace a un STUN-servidor, que responde con una respuesta que contiene la dirección IP y el número de puerto del cliente, tal como se observa desde la perspectiva del servidor, para enviar paquetes de voz a la parte correspondiente.
STUN se describe en detalle en RFC 3489, RFC 8489 y RFC 5780; aquí sólo señalamos lo principal: de hecho, es un mecanismo de detección de direcciones adecuadas para la transmisión de datos de voz sí implica diferentes redes construidas sobre NAT. Esto resuelve problemas como la falta de registro en PBX, o llamadas sin sonido, o llamadas canceladas, o problemas de no recibir llamadas entrantes.
En este caso, un servidor STUN debe estar más allá de una red en la que se encuentra un PBX o un softphone, pero esto no siempre es posible. Si alguna parte se encuentra fuera de una NAT simétrica, STUN no es aplicable — luego se concede la palabra a TURN.
TURN
El protocolo conocido como Traversal Using Relays around NAT (se proporciona una descripción detallada en RFC 8656) tiene como objetivo ayudar a los dispositivos a interactuar más allá de un NAT simétrico a través de un “mediador”, es decir, un servidor TURN. En cierto sentido, TURN completa STUN; a menudo, un servidor STUN también es un servidor TURN.
TURN es bueno en lo que respecta a solucionar las deficiencias de STUN, por ejemplo, se puede trabajar fuera de NAT simétrico, pero sigue siendo necesaria una conexión con un servidor externo. Dado que los datos se transmiten a través de un servidor "mediador", esto provoca cierta demora.
Para que esos datos se transmitan por el mejor camino, está ICE.
ICE
ICE (Interactive Connectivity Establishment; consulte RFC 8445 y RFC 5768) es, a su vez, un complemento a STUN y TURN. Su objetivo principal es definir la manera de conexión:
- en primer lugar, intenta establecer una conexión directa;
- si eso no es posible, ICE intenta conectarse a través de STUN;
- de lo contrario, utiliza TURN
Una ventaja indudable de ICE es la simplicidad: los usuarios no tienen que profundizar en los entresijos de NAT. Por otro lado, requiere más tiempo para la conexión, ya que puede ser necesario comprobar secuencialmente todas las maneras posibles.
Softphone, firewall, DNS y otros
Estamos seguros de que nuestros atentos lectores ya tienen preguntas adicionales: ¿es necesario tener sus propios servidores STUN para llamar a través de un softphone? Si es así, ¿cómo configurarlo en Softphone.Pro? ¿Qué pasa con el bypass del firewall? Registros DNS, una vez más.
Encontrará todas las respuestas en el nuevo artículo STUN, TURN e ICE en Softphone.Pro en nuestra base de conocimientos. DNS, Linux (en el ejemplo Ubuntu Server 24.04 LTS), servidor propio, todo está ahí.
¡Disfrute!
TAMBIÉN TE PUEDE INTERESAR
Help STUN, TURN, and ICE in Softphone.Pro
Blog Audio entrecortado en VoIP: encontrar rápidamente grabaciones con mala calidad de sonido
Blog VoIP vs SIP, dialers VS softphones: diferencias y similitudes
Blog Llamadas y “sip:”, “tel:”, “callto:”
Blog Recibiendo llamadas al móvil cuando la aplicación de softphone está en segundo plano o cerrada
