STUN, TURN, ICE: los tres mosqueteros de SIP
Existe la idea bastante extendida de que los términos que aparecen al principio del título significan lo mismo, igual que SIP y VoIP, o los dialers y los softphones, que a menudo se meten en el mismo saco. Pero no es así: STUN, TURN e ICE son protocolos diferentes que resuelven el mismo problema: permitir la comunicación entre dispositivos situados detrás de firewalls 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.
Veamos brevemente cada uno.
STUN
STUN (Session Traversal Utilities for NAT) es un protocolo cliente-servidor que permite a las aplicaciones detectar la presencia y el tipo de firewalls y NAT. Los clientes STUN envían solicitudes a un servidor STUN y reciben la dirección necesaria para enviar paquetes de voz a la otra parte de la conversación.
STUN se describe con detalle en RFC 3489, RFC 8489 y RFC 5780. Aquí nos quedaremos con lo esencial: en la práctica, es un mecanismo que permite determinar las direcciones correctas para transmitir datos de voz cuando los extremos se encuentran en distintas redes con NAT. Esto ayuda a resolver problemas de comunicación como la imposibilidad de registrar el softphone en la PBX, audio en un solo sentido, llamadas que se cortan o llamadas entrantes que no llegan.
El servidor STUN debe estar fuera de las redes donde se encuentran el softphone y la PBX, y eso no siempre es posible. Si alguna de las partes está detrás de un NAT simétrico, STUN no sirve. Ahí entra en escena TURN.
TURN
TURN (Traversal Using Relays around NAT; consulte RFC 8656 para una descripción detallada) ayuda a los dispositivos situados detrás de un NAT simétrico a comunicarse mediante un intermediario: un servidor TURN. En ese sentido, TURN complementa a STUN, y muchos servidores son compatibles con ambos protocolos.
TURN soluciona algunas limitaciones de STUN —por ejemplo, permite trabajar detrás de un NAT simétrico—, pero sigue siendo necesario conectarse a un servidor externo. Como los datos pasan por ese servidor intermediario, se introduce cierta latencia adicional.
Y para que los datos sigan el mejor camino disponible, entra en juego ICE.
ICE
ICE (Interactive Connectivity Establishment; descrito en RFC 8445, mientras que su uso en SIP se aborda en RFC 5768) complementa a STUN y TURN. Su principal función es determinar automáticamente cómo establecer la conexión:
- primero intenta establecer una conexión directa entre los dispositivos;
- si no es posible, ICE intenta conectarse mediante STUN;
- si tampoco funciona, utiliza TURN.
ICE tiene una ventaja evidente: la sencillez. El usuario no tiene que meterse en los entresijos de la configuración de NAT. La contrapartida es que la conexión puede tardar un poco más en establecerse, ya que ICE puede tener que comprobar uno tras otro los distintos métodos disponibles.
Softphone, firewall y DNS
A estas alturas, nuestros lectores más atentos seguramente ya tienen algunas preguntas. ¿Es necesario configurar un servidor STUN propio para llamar desde un softphone? Si es así, ¿cómo se configuran STUN e ICE en Softphone.Pro? ¿Qué pasa con el firewall? ¿Y qué registros DNS hacen falta?
Encontrará todas las respuestas en nuestra guía completa de la Base de conocimientos, STUN, TURN e ICE en Softphone.Pro. Allí hablamos de DNS, Linux y de cómo montar su propio servidor STUN tomando Ubuntu Server 24.04 LTS como ejemplo.
¡Que lo 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
