ICE Candidate: qué es, tipos de candidatos y cómo funciona

¿Qué es un ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) es una unidad fundamental en el proceso de establecimiento de una conexión P2P a través del protocolo WebRTC. Representa un par de dirección IP + puerto que puede utilizarse para la transmisión de datos entre dos pares. Cada candidato contiene información sobre el protocolo de transporte (UDP, TCP), el tipo de conexión y la prioridad.

Un ICE Candidate se genera en cada dispositivo individualmente. El dispositivo recopila todas las interfaces de red disponibles, solicita una dirección externa a través de un servidor STUN y añade una dirección de retransmisión de un servidor TURN. La lista resultante de candidatos se envía al par remoto a través de un canal de señalización en formato SDP (Session Description Protocol).

Según la especificación RFC 8445 (IETF, 2018), ICE utiliza un mecanismo de pares nominados: después de recopilar todos los candidatos, se prueban por pares mediante solicitudes STUN. El par que supera la verificación primero se declara nominado y se utiliza para la transmisión multimedia. Los pares restantes permanecen en reserva en caso de que la conexión se interrumpa.

El papel de ICE en el stack de WebRTC

WebRTC es un estándar abierto para comunicaciones P2P, pero una conexión directa entre dispositivos a menudo es imposible debido a NAT (Network Address Translation) y cortafuegos. ICE Candidate resuelve este problema ofreciendo varias rutas de conexión alternativas. El protocolo ICE (Interactive Connectivity Establishment) es un componente obligatorio de WebRTC y está descrito en la especificación W3C WebRTC (2025).

Muchos desarrolladores de aplicaciones móviles utilizan bibliotecas WebRTC como Google WebRTC (para Android) y envoltorios nativos para iOS. En cada una de ellas, el proceso ICE se gestiona automáticamente, pero comprender los tipos de candidatos permite al desarrollador configurar la infraestructura del servidor y optimizar la calidad de la conexión.

Formato SDP con candidatos ICE

Un ICE Candidate se transmite dentro de un mensaje SDP como atributos a=candidate. Cada línea contiene foundation, component ID, protocolo de transporte, prioridad, dirección IP, puerto y tipo de candidato. A continuación se muestra un ejemplo de un fragmento SDP con tres candidatos de diferentes tipos:

// Ejemplo SDP con candidatos ICE
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

El campo priority determina el orden de prueba de los candidatos. Cuanto mayor es la prioridad, antes se comprobará el candidato. Los candidatos host siempre tienen la prioridad más alta, los candidatos relay la más baja.

Tipos de ICE Candidates

La especificación RFC 8445 define cuatro tipos de candidatos ICE, cada uno correspondiente a una forma específica de alcanzar un par remoto. El tipo de candidato afecta a su prioridad, tiempo de establecimiento de la conexión y requisitos de infraestructura del servidor.

Candidatos Host

Un candidato host se forma a partir de la dirección IP de la interfaz de red local del dispositivo. Si el dispositivo está en la misma red local que un par, el candidato host proporciona una conexión directa con latencia mínima. Para dispositivos móviles, los candidatos host se generan para la interfaz WiFi, la conexión celular LTE/5G y, si es necesario, para túneles VPN.

Los candidatos host tienen la prioridad más alta (2130706431 para UDP) y se prueban primero. Si ambos pares están detrás de NAT, sus candidatos host serán direcciones privadas (192.168.x.x, 10.x.x.x) y una conexión directa a través de ellos es imposible. ICE entonces procede a probar los candidatos srflx y relay.

Candidatos SRFLX y PRFLX

Un candidato SRFLX (Server Reflexive) es una dirección IP externa y un puerto obtenidos de un servidor STUN. Cuando un dispositivo envía una solicitud STUN, el servidor ve su dirección pública después de NAT y la devuelve. Este candidato permite establecer una conexión directa entre pares detrás de diferentes NAT, si sus dispositivos NAT soportan Hairpinning.

Un candidato PRFLX (Peer Reflexive) se descubre dinámicamente cuando una solicitud STUN de un par llega a una dirección inesperada. Este tipo ocurre cuando ambos pares envían solicitudes simultáneamente y NAT crea un enlace temporal. Un candidato PRFLX tiene prioridad más alta que srflx pero menor que host.

En aplicaciones móviles, los candidatos srflx son especialmente importantes al cambiar entre WiFi y redes celulares. Cuando un dispositivo cambia de red, la dirección IP cambia e ICE debe recopilar nuevamente los candidatos. Este proceso se llama reinicio ICE y requiere enviar un nuevo SDP.

Candidatos Relay a través de TURN

Un candidato relay es una dirección en un servidor TURN a través del cual el tráfico se retransmite de un par a otro. Este tipo se utiliza como respaldo cuando una conexión P2P directa es imposible (NAT simétrico, cortafuegos corporativo). Un canal relay añade latencia y aumenta la carga del servidor, por lo que en configuraciones óptimas, el servidor TURN se utiliza solo para el 10–15% de todas las sesiones.

Implementaciones populares de servidores TURN: coturn (código abierto), Twilio Network Traversal, Metered TURN. La elección del proveedor TURN afecta a la calidad de la conexión multimedia en aplicaciones móviles — el servidor debe estar geográficamente cerca de los usuarios para minimizar la latencia adicional.

Cómo funciona el proceso ICE

El proceso ICE es un protocolo de múltiples etapas que garantiza el establecimiento de una conexión P2P confiable en condiciones de incertidumbre de la topología de red. El algoritmo se describe en RFC 8445 e incluye cuatro fases obligatorias: recopilación de candidatos, clasificación, prueba y nominación.

Fase 1: Recopilación de candidatos

Cada dispositivo recopila todas las direcciones de red disponibles. Para ello, el motor WebRTC enumera las interfaces locales (host), envía una solicitud a un servidor STUN (srflx) y solicita una dirección relay a un servidor TURN. Simultáneamente, el dispositivo puede descubrir un candidato prflx si recibe una solicitud STUN entrante de un par.

En el desarrollo móvil, esta etapa es crítica para el tiempo de establecimiento de la conexión. En iOS y Android, la recopilación de candidatos puede tomar de 200 ms a 2 segundos dependiendo de la velocidad de la red, la disponibilidad de servidores STUN/TURN y la cantidad de interfaces de red activas.

Fase 2: Formación de pares y clasificación

Después de recibir la lista de candidatos del par remoto a través del canal de señalización, el motor ICE local forma todos los pares de candidatos posibles (local + remoto). Cada par recibe una prioridad según la fórmula de RFC 8445, teniendo en cuenta las prioridades de ambos candidatos y la dirección (entrante/saliente).

Los pares se ordenan en orden descendente de prioridad. Los mejores pares se prueban primero. El algoritmo garantiza que un par host-host se comprobará antes que un par host-srflx, host-relay o relay-relay, minimizando el retraso de conexión en configuraciones de red simples.

Fase 3: Prueba y nominación

ICE envía solicitudes de enlace STUN para cada par de candidatos. Si se recibe una respuesta STUN, el par es válido. El primer par válido se nomina como principal. El motor WebRTC comienza a transmitir medios a través de este par, mientras que los pares restantes continúan verificándose en caso de que el principal falle.

El proceso de prueba puede tomar hasta varios segundos con un gran número de candidatos. WebRTC utiliza temporizadores: para pares host el temporizador es agresivo (20 ms), para pares relay — más conservador (200 ms). Los desarrolladores de aplicaciones móviles pueden acelerar la conexión limitando el número de servidores ICE o configurando iceTransportPolicy.

Reinicio ICE

ICE restart es un reinicio del proceso ICE sin recrear toda la RTCPeerConnection. Es necesario al cambiar de red, perder la conexión o alternar entre WiFi y redes móviles. Durante un reinicio, todos los candidatos actuales se descartan y el proceso comienza de nuevo generando nuevos ufrag y pwd.

En el desarrollo de iOS, el reinicio ICE se invoca mediante el método restartIce() en RTCPeerConnection. En Android, se utiliza un método similar en la clase PeerConnection de Google WebRTC. El manejo adecuado del reinicio ICE es un requisito crítico para aplicaciones que funcionan en dispositivos móviles con conexiones de red inestables.

Servidores STUN y TURN en ICE

STUN (Session Traversal Utilities for NAT) y TURN (Traversal Using Relays around NAT) son componentes de servidor clave sin los cuales ICE Candidate no puede garantizar una conectividad exitosa en condiciones reales de Internet. Su configuración adecuada afecta directamente a la calidad de la llamada en aplicaciones móviles.

STUN: Descubrimiento de dirección externa

Un servidor STUN permite a un dispositivo descubrir su dirección IP pública y el puerto que NAT asignó para la conexión saliente. El protocolo STUN se define en RFC 8489 y funciona sobre UDP en el puerto 3478, también soportando TCP. Google proporciona servidores STUN públicos (stun.l.google.com:19302) que se pueden usar de forma gratuita.

En el desarrollo móvil, una solicitud STUN es una operación ligera que toma 50–200 ms. Sin embargo, algunas redes corporativas y móviles bloquean el tráfico UDP, lo que obliga a ICE a usar TCP para la comunicación STUN o recurrir directamente a TURN.

TURN: Retransmisión de tráfico

Un servidor TURN es un retransmisor de tráfico multimedia. Cuando una conexión P2P directa es imposible (NAT simétrico, cortafuegos), el dispositivo envía datos a TURN, que los reenvía al otro par. TURN es un mecanismo confiable pero costoso: añade latencia (30–100 ms) y requiere un ancho de banda del servidor igual a la suma de todas las sesiones multimedia.

Según el WebRTC Stats Report (2025), aproximadamente el 8–15% de las sesiones WebRTC en redes móviles requieren TURN. Para optimizar los costos de tráfico TURN, los desarrolladores utilizan pruebas de conexión preliminares y activan el canal TURN solo si falla P2P.

Elección de STUN/TURN para una aplicación móvil

Al elegir la infraestructura para ICE en un proyecto móvil, se consideran los siguientes factores: ubicación geográfica de los servidores para minimizar la latencia, soporte de UDP y TCP, costo del tráfico TURN y SLA. Las soluciones populares incluyen: coturn para auto-alojamiento, Twilio, Agora y LiveKit para uso en la nube.

ICE Candidate en el desarrollo móvil

Para los desarrolladores móviles, entender ICE Candidate va más allá de la teoría — es una necesidad práctica al crear aplicaciones con llamadas de voz y video. Las plataformas iOS y Android proporcionan API nativas de WebRTC que automatizan el manejo de ICE, pero el desarrollador es responsable de configurar los servidores ICE y manejar los eventos de cambio de red.

Configuración de ICE en iOS

En iOS, WebRTC está disponible a través del framework WebRTC.framework o la biblioteca GoogleWebRTC mediante CocoaPods. Los servidores ICE se configuran a través de un array de RTCIceServer en RTCConfiguration:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

Después de crear un RTCPeerConnection y llamar a offer() o answer(), el motor recopila automáticamente los candidatos ICE. El evento iceGatheringStateChange notifica sobre cambios en el estado de recopilación, mientras que iceConnectionState informa sobre el estado de la conexión.

Configuración de ICE en Android

Android utiliza la misma biblioteca Google WebRTC. Los servidores ICE se configuran mediante PeerConnection.RTCConfiguration. El desarrollador puede gestionar la política ICE a través de iceTransportsType — el modo relay usa forzosamente solo TURN, lo que aumenta la fiabilidad pero añade latencia:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

El parámetro bundlePolicy afecta a la cantidad de candidatos ICE — el modo MAXBUNDLE combina todos los flujos multimedia en un solo transporte, reduciendo el número total de candidatos y acelerando la conexión.

Manejo de eventos ICE en aplicaciones móviles

Los eventos ICE clave que un desarrollador debe manejar incluyen: estado de la conexión ICE, estado de recopilación ICE y descubrimiento de nuevos candidatos. Después de que ICE completa la recopilación y las pruebas, su estado pasa a connected o completed.

En las redes móviles, son frecuentes los cambios entre WiFi y conectividad celular. Cuando la red cambia, ICE debe realizar un reinicio, de lo contrario el flujo multimedia se interrumpe. Los desarrolladores implementan la monitorización de NetworkManager (iOS) o ConnectivityManager (Android) para llamar automáticamente a restartIce().

Una implementación exitosa de ICE en una aplicación móvil incluye: elección de servidores STUN/TURN confiables, manejo adecuado del reinicio ICE al cambiar de red, configuración de iceConnectionState para mostrar el estado de la conexión en la UI y monitoreo de estadísticas a través de RTCStatsReport.