WebRTC: qué es, arquitectura y principio de funcionamiento

Qué es WebRTC

WebRTC (Web Real-Time Communication) es un proyecto de código abierto iniciado por Google en 2011 y estandarizado por W3C (JavaScript API) e IETF (protocolos). Su objetivo principal es proporcionar comunicación de baja latencia entre navegadores y aplicaciones sin instalar complementos ni software de terceros.

A diferencia de las soluciones tradicionales (RTMP, HLS) donde el video pasa por un servidor, WebRTC utiliza arquitectura peer-to-peer: los datos se transmiten directamente entre los participantes. Esto proporciona una latencia de 200-500 ms frente a 3-10 segundos de HLS, una diferencia crítica para llamadas de voz y video, transmisión de juegos y cirugía remota.

Según Google WebRTC Team (2025), la tecnología se utiliza en aplicaciones con una audiencia total de más de 5 mil millones de instalaciones: Google Meet, WhatsApp, Discord, Telegram, Zoom (parcialmente). Más del 85% de las startups de capital riesgo en telesalud y tecnología educativa eligen WebRTC como transporte base en tiempo real.

El desarrollo móvil recibió soporte completo de WebRTC en 2013 con el lanzamiento de libjingle_peerconnection, una implementación nativa para Android e iOS. Hoy ambas plataformas tienen SDK estables con soporte para codificación hardware de H.264 y VP8, cámara, micrófono y altavoces del dispositivo.

Arquitectura y protocolos de WebRTC

La arquitectura de WebRTC consta de tres capas. La capa superior es JavaScript API (o API nativa para plataformas móviles), la intermedia son los protocolos de transporte, la inferior son los códecs y la seguridad. Cada capa resuelve su propia tarea, pero todas son necesarias para establecer la conexión.

API principales de WebRTC

MediaStream (getUserMedia) — captura audio y video del micrófono y la cámara del dispositivo. RTCPeerConnection — gestiona la conexión P2P: codificación, transporte, adaptación de tasa de bits. RTCDataChannel — transmite datos arbitrarios (texto, archivos, mensajes binarios) por el mismo canal.

// API JavaScript de WebRTC (ejemplo de navegador)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Protocolos en tiempo real

WebRTC utiliza SRTP (Secure Real-Time Transport Protocol) para audio y video, una versión segura de RTP con cifrado AES-128. La gestión de sesión se realiza mediante SCTP (Stream Control Transmission Protocol) sobre DTLS. Cada flujo de datos se cifra obligatoriamente: WebRTC no tiene modo no seguro.

• SRTP/SRTCP — transmisión cifrada de flujos de medios con protección contra ataques de repetición
• DTLS-SRTP — establecimiento de claves de cifrado mediante Datagram TLS sobre UDP
• SCTP — entrega de datos confiable o parcialmente confiable para DataChannel
• ICE (Interactive Connectivity Establishment) — framework para encontrar una ruta de red entre pares
• Trickle ICE — versión incremental de ICE donde los candidatos se envían a medida que se descubren, acelerando el establecimiento de la conexión

NAT traversal: ICE, STUN y TURN

El principal desafío técnico de WebRTC es establecer una conexión P2P entre dispositivos que están detrás de NAT (Network Address Translation). Sin mecanismos especiales, los dispositivos no pueden alcanzarse directamente porque sus direcciones IP locales no son visibles desde internet.

STUN — determinación de la dirección pública

STUN (Session Traversal Utilities for NAT) — un servidor que responde a la pregunta “¿ul es mi IP y puerto públicos?”. El cliente envía una solicitud al servidor STUN, el servidor ve su dirección pública y la devuelve al cliente. Google mantiene públicamente el servidor STUN stun:stun.l.google.com:19302.

// WebRTC en iOS — configuración de servidores ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — conexión de retransmisión

TURN (Traversal Using Relays around NAT) — un servidor de retransmisión para casos en que STUN no ayuda (NAT simétrico o cortafuegos corporativos). En este modo todos los datos pasan por el servidor TURN, lo que reduce la velocidad y aumenta la latencia, pero garantiza conexión en el 99% de los casos.

TURN es el componente más caro de la infraestructura de WebRTC, ya que el servidor pasa todo el tráfico de medios a través de sí mismo. Según Coturn Project (2025), un servidor TURN típico con 8 vCPU y 16 GB de RAM maneja aproximadamente 200 llamadas de audio simultáneas o 40 videollamadas en HD.

Proceso ICE

ICE recopila todos los candidatos posibles (IP local, IP pública mediante STUN, retransmisión mediante TURN) e intenta establecer una conexión en orden de prioridad. Tan pronto como al menos un par de candidatos (local-remoto) pasa la verificación de conectividad, la conexión se considera establecida.

• Host candidates — dirección IP local del dispositivo en la subred (más rápida, pero no funciona detrás de NAT)
• Server Reflexive candidates — IP pública obtenida a través de un servidor STUN
• Relay candidates — dirección del servidor TURN a través del cual se realiza la retransmisión (más lenta, más confiable)

WebRTC en aplicaciones móviles

Para el desarrollo móvil, Google mantiene libWebRTC, una biblioteca nativa para Android (AAR) e iOS (XCFramework). La biblioteca incluye toda la pila de protocolos, códecs (VP8, VP9, H.264, AV1) y aceleración hardware para codificación/descodificación.

WebRTC en Android

El SDK de Android proporciona las clases PeerConnectionFactory, PeerConnection, MediaStream. La aplicación crea una fábrica, configura los códecs de video, captura el flujo de la cámara mediante VideoCapturer y establece la conexión entre pares mediante SDP offer/answer.

// WebRTC en Android — inicialización
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC en iOS

El SDK de iOS utiliza una API Objective-C con envoltorios RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. La codificación hardware H.264 está disponible mediante VideoToolbox. Para la visualización de video se utiliza RTCMTLVideoView (Metal) o RTCVideoRenderer.

// WebRTC en iOS — captura de video desde la cámara
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Selección de cámara (frontal/trasera)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Iniciar captura con FPS máximo
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Para videollamadas en producción, las aplicaciones móviles suelen utilizar envoltorios SDK sobre libWebRTC: Twilio Video, Agora, Daily.co. Estos SDK simplifican la señalización, la gestión de salas y proporcionan componentes de interfaz listos para mostrar la cuadrícula de video de los participantes.

Señalización y establecimiento de conexión

WebRTC no especifica un protocolo de señalización: el intercambio de mensajes SDP (Session Description Protocol) entre pares. El desarrollador elige el transporte para la señalización: WebSocket, MQTT, SIP, XMPP o REST API. La señalización entrega oferta, respuesta y candidatos ICE de un par a otro.

Intercambio SDP Offer/Answer

El proceso comienza con la creación de una oferta (el iniciador describe sus capacidades de medios), se transmite mediante señalización al segundo par, que responde con una respuesta. Después del intercambio SDP, cada par inicia ICE y lanza DTLS-SRTP para el cifrado del flujo.

// Android — creación y envío de offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Enviar sdp.description al servidor de señalización
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protocolos de señalización

Para aplicaciones móviles, la señalización más popular es mediante WebSocket, un canal bidireccional sobre TCP que mantiene una conexión persistente con el servidor. El servidor de señalización suele ser un microservicio independiente (Node.js, Golang, Elixir) que enruta mensajes entre los participantes de la sala.

• WebSocket — conexión bidireccional persistente, overhead mínimo, elección estándar para señalización
• SIP sobre WebSocket — protocolo VoIP estándar, se integra con infraestructura telefónica existente
• MQTT — protocolo pub/sub ligero para IoT y redes débiles, pero con mayor latencia
• Matrix / XMPP — protocolos descentralizados para aplicaciones centradas en la privacidad

Una vez completados ICE y DTLS-SRTP, la señalización ya no participa en la transmisión de datos: todo el tráfico de medios fluye directamente P2P (o mediante un relé TURN). El servidor de señalización puede apagarse sin interrumpir las llamadas activas. Esta es la ventaja clave de la arquitectura descentralizada de WebRTC.