Desarrollo WebRTC en 2026: arquitectura, coste y alcance

WebRTC te da audio, vídeo y datos cifrados y de baja latencia entre navegadores y apps nativas, gratis y sin plugins. Lo que no te da es un producto: la señalización, la travesía de NAT (STUN/TURN), un servidor de medios para llamadas grupales, la autenticación, la grabación y la monitorización son cosas que tienes que construir o comprar. La mayor parte del coste y del riesgo en el desarrollo WebRTC está en esas piezas, no en la API en sí.

Qué resuelve WebRTC y qué queda para ti

La API WebRTC del navegador cubre cuatro cosas:

• Captura de medios (getUserMedia, getDisplayMedia), con selección de dispositivos y constraints.
• Códecs y transporte: Opus para audio; VP8, VP9, H.264 y cada vez más AV1 para vídeo; RTP sobre DTLS-SRTP con control de congestión integrado.
• Conectividad: ICE, que prueba rutas de red candidatas obtenidas mediante STUN y TURN.
• Data channels: SCTP sobre DTLS para mensajes arbitrarios, con entrega fiable o no fiable.

Todo lo demás queda sin especificar a propósito: señalización (intercambio de SDP y candidatos ICE), servidores STUN y TURN, un servidor de medios para llamadas grupales, identidad y permisos de sala, grabación, monitorización (getStats devuelve números en bruto, no un pipeline) e interoperabilidad SIP/PSTN. "La señalización es tuya" es lo primero que hay que interiorizar: el navegador no tiene opinión sobre cómo se encuentran dos peers, mala noticia para los equipos que asumen que la parte difícil está hecha cuando la demo funciona en localhost.

Opciones de arquitectura: mesh P2P vs SFU vs MCU

La decisión de arquitectura depende de un solo número: cuántos participantes envían vídeo al mismo tiempo.

Mesh P2P. Cada participante se conecta directamente con todos los demás. No hay servidor de medios, pero el ancho de banda de subida y la CPU crecen linealmente con los participantes; se degrada rápido en móvil por encima de tres o cuatro emisores de vídeo.

SFU (Selective Forwarding Unit). Cada participante envía un único upstream (con capas de simulcast) al servidor, que reenvía los streams a los que cada participante está suscrito sin decodificarlos. Poca CPU en el servidor, latencia cercana al P2P. Es el estándar para llamadas grupales en 2026.

MCU (Multipoint Control Unit). El servidor decodifica todos los streams, compone un layout y lo recodifica. Los clientes reciben un único stream sin importar el tamaño de la sala. Caro y más lento, pero adecuado para endpoints legacy, clientes limitados o cuando de todos modos necesitas una salida compuesta.

Criterio	Mesh P2P	SFU	MCU
Participantes en la práctica (vídeo)	2–4	Decenas a cientos por sala (con simulcast y paginación)	Decenas, limitado por la transcodificación del servidor
Coste de servidor	Ninguno (solo STUN/TURN)	Moderado: limitado por ancho de banda, poca CPU	Alto: limitado por CPU/GPU
Ancho de banda por cliente	Subida: N-1 streams; Bajada: N-1 streams	Subida: 1 stream (con capas); Bajada: streams suscritos	Subida: 1; Bajada: 1
Latencia añadida	La menor	Pequeña (solo reenvío)	La mayor (decodificar, mezclar, codificar)
Grabación	Solo en cliente, incómoda	Por track en el servidor, componer después	Nativa, el compuesto ya existe
Ideal para	Llamadas 1:1, consultas de telemedicina, reuniones pequeñas	Reuniones, aulas, webinars, salas de audio en directo	Interop con SIP/H.323 legacy, broadcast, clientes débiles

Los híbridos son habituales: P2P para 1:1 que pasa a un SFU cuando entra el tercer participante. Si tienes dudas, empieza con un SFU; cubre el rango más amplio de productos sin tener que rehacer la arquitectura más adelante. Sobre el transporte que va por debajo de la señalización, consulta WebSockets vs Server-Sent Events.

STUN, TURN y por qué TURN es obligatorio en producción

ICE recopila candidatos host, server-reflexive (IP pública descubierta vía STUN) y relay (TURN), y los peers prueban pares hasta que uno funciona. STUN es barato y funciona cuando ambos NATs cooperan. Falla detrás de NATs simétricos, de la mayoría de firewalls corporativos, de algunas operadoras móviles y de cualquier red que bloquee UDP. Entonces la única vía es un relay a través de TURN.

Por qué obligatorio: no verás estos fallos en desarrollo. Las redes de tu oficina y tu casa conectan bien; una parte de los usuarios reales, y una parte mucho mayor de los usuarios corporativos, no. Sin TURN esas llamadas se quedan en "conectando" para siempre. Todo despliegue serio ejecuta TURN, normalmente con:

• coturn self-hosted, o un relay gestionado (Twilio Network Traversal, Cloudflare Calls TURN, Xirsys, Metered).
• TURN sobre TCP y TLS en el puerto 443 como fallback para redes que bloquean UDP por completo.
• Credenciales de corta duración generadas por sesión (el patrón REST API de la especificación TURN: username = expiry:userId, contraseña = HMAC de esa cadena con un secreto compartido). Nunca incluyas un usuario y contraseña TURN estáticos en el bundle del cliente; los extraerán y los usarán como proxy gratuito.
• Ubicación regional. Un único TURN en Frankfurt añade un round trip a los usuarios de São Paulo. Coloca los relays cerca de los usuarios.

Presupuéstalo: el tráfico de relay es el único coste WebRTC que escala con el uso incluso en arquitecturas P2P, y la proporción relayed es mayor en entornos corporativos.

Plataformas gestionadas vs servidores de medios self-hosted

Es la mayor decisión de build vs buy en un proyecto WebRTC. Las plataformas gestionadas venden un SDK, una flota global de SFUs, TURN y grabación, facturados por minuto. Self-hosting significa ejecutar un SFU open source y pagar cómputo y egress.

Opción	Tipo	Modelo	Puntos fuertes	Ojo con
LiveKit	SFU open source (Go) + LiveKit Cloud	Self-host o gestionado	SDKs modernos para web, iOS, Android, Flutter, React Native; simulcast, SVC, egress e ingress, framework de agentes para IA	Precio del Cloud a escala; el self-hosting sigue necesitando infra de TURN y egress
mediasoup	SFU open source (librería Node/C++)	Self-host	Rendimiento excelente, control fino, abstracción mínima	Es una librería, no un servidor: tú escribes señalización, salas, escalado y grabación
Janus	Servidor open source de propósito general (C)	Self-host	Maduro, arquitectura de plugins (video room, SIP, streaming), fuerte interop SIP	API más antigua; escalar entre instancias es problema tuyo
Jitsi	Stack open source completa de reuniones (Jitsi Videobridge, Prosody, cliente web)	Self-host o 8x8 JaaS	Producto completo listo para usar, bueno para herramientas internas de reunión	Personalizar la UI a fondo es más difícil que construir sobre un SFU puro
Twilio Video	Gestionado	Por participante-minuto	Buena documentación, PSTN y SIP en el mismo ecosistema	Coste a escala; roadmap de funcionalidades irregular
Daily	Gestionado	Por participante-minuto	UI prefabricada, primera llamada rápida, grabación y transcripción integradas	Lock-in a través del SDK; menos control sobre el pipeline de medios
Agora	Gestionado	Por minuto, por tramos de resolución	Red de borde global enorme, fuerte en móvil y regiones con poco ancho de banda	Dudas de residencia de datos para cargas en la UE; precios complejos

Una forma práctica de decidir:

• Elige gestionado cuando el time to market importa más que el coste unitario, el uso es incierto, no tienes a nadie para operar infraestructura de medios o el vídeo es secundario en el producto.
• Elige self-hosted cuando los minutos al mes son tan altos que la facturación por minuto domina tu margen, cuando la residencia de datos en la UE o el despliegue on-premise es un requisito contractual, o cuando necesitas control sobre el pipeline de medios (códecs personalizados, procesamiento en servidor, agentes de IA en la llamada).
• LiveKit es el término medio habitual: empieza en LiveKit Cloud y conserva la opción de alojar el mismo servidor más adelante sin reescribir los clientes.

Si haces self-hosting, recuerda que el servidor de medios es una carga stateful y pesada en ancho de banda: las salas quedan fijadas a instancias, el autoscaling sigue el ancho de banda y el número de tracks, los despliegues rolling cortan llamadas si no haces drain, y los pods necesitan host networking o un rango amplio de puertos UDP.

Seguridad: DTLS-SRTP es la parte fácil

El cifrado de medios está resuelto: WebRTC negocia DTLS entre peers, deriva de ahí las claves SRTP y se niega a enviar medios sin cifrar. La huella DTLS viaja en el SDP, así que la integridad de tu canal de señalización es lo que protege los medios de una sustitución. El resto es seguridad de aplicación ordinaria en tres superficies:

Señalización. Ejecútala sobre WSS. Autentica la conexión con un token de corta duración emitido por tu proveedor de identidad (consulta OAuth 2.0, JWT y zero trust). Limita el token a una sala y un rol (publisher, subscriber, moderador). Valida cada mensaje en el servidor; lo que el cliente afirma sobre la sala en la que está no es una prueba. Aplica rate limit a los joins y al vaivén de offer/answer.

TURN. Credenciales HMAC efímeras como se describe arriba, con un TTL de minutos, no de días. Restringe el relay al rango de IP de tu servidor de medios cuando el SFU sea el único peer con el que hablan los clientes. Monitoriza el número de asignaciones y los bytes relayed por usuario para detectar abusos.

Servidor de medios. Mantén la API de control del SFU fuera de internet y emite los tokens de sala desde tu backend, nunca desde el cliente. Donde el servidor no deba ver los medios (algunos casos sanitarios y legales), Insertable Streams / SFrame ofrecen cifrado de extremo a extremo a costa de la grabación y la transcripción en servidor.

El cumplimiento se deriva del mapa de datos: quién puede entrar, qué se graba, dónde y durante cuánto tiempo. La guía del RGPD para empresas europeas cubre la documentación; en el caso concreto de WebRTC, trata las direcciones IP de los candidatos ICE y de los logs de señalización como datos personales.

Calidad: simulcast, estimación de ancho de banda y móvil

La calidad de la llamada es sobre todo un problema de gestión del ancho de banda. Las herramientas:

• Simulcast. El emisor codifica dos o tres resoluciones; el SFU reenvía la capa que cada receptor puede manejar. Sin esto, un participante con una conexión lenta arrastra a todos. Actívalo en todos los publishers de las llamadas grupales.
• SVC con VP9 o AV1 hace lo mismo con un único stream codificado y capas temporales/espaciales. Más eficiencia, menor soporte de dispositivos.
• Estimación de ancho de banda. El controlador de congestión del navegador (TWCC) ajusta el bitrate del encoder continuamente y el SFU cambia de capa en el downstream. No luches contra él: un maxBitrate fijo demasiado alto produce pérdida de paquetes; demasiado bajo, vídeo borroso en redes buenas.
• Audio primero. Usa Opus con forward error correction y DTX. Una reunión sobrevive a un vídeo malo, no a un audio entrecortado.
• Móvil. Los encoders por hardware varían, la batería se agota rápido a 720p y los cambios de Wi-Fi a red móvil requieren manejar el ICE restart. Los SDKs nativos se encargan de casi todo esto; un WebView, no. Prueba en dispositivos Android de gama baja reales.
• Mide. Consulta getStats() periódicamente y envía round-trip time, jitter, pérdida de paquetes y capa seleccionada a tu analítica. Si no, no podrás distinguir "la red iba mal" de "la release iba mal".

Grabación y cumplimiento

La grabación suena a funcionalidad; es un componente de infraestructura. Grabación por track (el SFU escribe cada stream por separado) es barata y flexible. Grabación compuesta (un navegador headless o un MCU renderiza la sala) da un archivo listo para reproducir a costa de un worker de renderizado por sala. Grabación en cliente (MediaRecorder) es frágil y depende de una subida grande después.

El cumplimiento condiciona la elección: consentimiento mostrado antes de que empiece la grabación, retención aplicada por política, almacenamiento en la región que exigen tus contratos y acceso controlado igual que la propia llamada. Para sectores regulados, consulta regulaciones y seguridad en el desarrollo de aplicaciones sanitarias; el pipeline de grabación suele ser lo que entra en la DPIA.

Un flujo mínimo de señalización

El protocolo entre dos peers y tu servidor es pequeño. Lo que importa es el orden y la idempotencia. Un intercambio mínimo sobre WebSocket:

A -> server: join { room, token }
B -> server: join { room, token }
server -> A: peer-joined { peerId: B, iceServers: [...TURN with ephemeral creds] }
A -> server: offer  { to: B, sdp }
server -> B: offer  { from: A, sdp }
B -> server: answer { to: A, sdp }
server -> A: answer { from: B, sdp }
A <-> server <-> B: ice-candidate { to, candidate }   (many, in both directions)

En el cliente, la secuencia del lado que hace la offer:

const pc = new RTCPeerConnection({ iceServers });
stream.getTracks().forEach((t) => pc.addTrack(t, stream));

pc.onicecandidate = ({ candidate }) => {
  if (candidate) ws.send(JSON.stringify({ type: "ice-candidate", to: peerId, candidate }));
};
pc.ontrack = ({ streams }) => (remoteVideo.srcObject = streams[0]);

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
ws.send(JSON.stringify({ type: "offer", to: peerId, sdp: pc.localDescription }));

ws.onmessage = async ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.type === "answer") await pc.setRemoteDescription(msg.sdp);
  if (msg.type === "ice-candidate") await pc.addIceCandidate(msg.candidate);
};

Dos detalles causan la mayoría de los bugs reales: candidatos ICE que llegan antes de fijar la remote description (encólalos) y ambos lados haciendo offer a la vez (glare; usa el patrón perfect negotiation de la especificación WebRTC). Con un SFU no escribes nada de esto: el SDK habla con el servidor y tu backend solo emite tokens de sala.

Alcance de un proyecto WebRTC: qué determina coste y plazo

Los equipos que buscan desarrollo WebRTC suelen pedir presupuesto antes de tener una arquitectura. Un puñado de variables determina la estimación, y pesan mucho más que el tamaño de la UI.

Variable	Extremo bajo	Extremo alto
Tamaño de sala	1:1	Salas grandes con paginación, active speaker, salas paralelas
Plataforma de medios	SDK gestionado	SFU self-hosted con autoscaling y flota de TURN
Clientes	Solo web	Web + iOS + Android nativos, más escritorio
Grabación	Ninguna	Grabación compuesta, transcripción, políticas de retención
Interop	Ninguna	Marcación SIP/PSTN, equipos de conferencia legacy
Cumplimiento	RGPD estándar	DPIA sanitaria/financiera, datos solo en la UE, cifrado de extremo a extremo
Observabilidad	Logs básicos	Dashboards de calidad por llamada, alertas sobre la tasa de conexión exitosa
Extras	Chat por data channel	Compartir pantalla con anotaciones, pizarra, agentes de IA en la llamada

Orden aproximado de esfuerzo:

1. Llamadas 1:1 o en grupo pequeño en plataforma gestionada, solo web. Semanas. La mayor parte del trabajo es auth, ciclo de vida de la sala y UI.
2. Llamadas grupales con grabación en plataforma gestionada, web y móvil. Unos meses, con las pruebas en móvil como cuello de botella.
3. SFU self-hosted con TURN, grabación, observabilidad y cumplimiento. Varios meses con un equipo dedicado, más operación tras el lanzamiento. Haz pruebas de carga con participantes sintéticos antes del go-live; ahí es donde aflora la capacidad infradimensionada de TURN y SFU.

El coste operativo lo domina el ancho de banda (egress del SFU, relay TURN), después el cómputo del servidor de medios y después el almacenamiento de grabaciones. En una plataforma gestionada, modela la factura por minuto frente a los minutos mensuales esperados; el punto en que el self-hosting gana queda claro en cuanto tienes datos reales de uso. Para supuestos de equipo y tarifas, consulta cuánto cuesta desarrollar software personalizado en Europa. Nuestro servicio de desarrollo de aplicaciones en tiempo real cubre el alcance y la entrega de este tipo de sistemas.

Checklist de decisión

Antes de escribir código, responde a esto:

• ¿Máximo de emisores de vídeo simultáneos por sala? Si son más de cuatro, planifica un SFU.
• ¿Plataforma gestionada o self-hosted? Decide según minutos al mes, residencia de datos y capacidad del equipo.
• TURN: ¿qué proveedor, qué regiones, credenciales efímeras emitidas desde tu backend?
• Señalización: ¿transporte, duración del token de auth, alcance de sala y rol, manejo de glare?
• ¿Simulcast o SVC activado en todos los publishers?
• Dispositivos objetivo: ¿qué navegadores, móvil nativo o WebView, cuál es el Android más básico que soportas?
• Grabación: ¿por track, compuesta o ninguna; UI de consentimiento; retención; región de almacenamiento?
• ¿Cifrado de extremo a extremo obligatorio? Si es así, acepta perder grabación y transcripción en servidor.
• Métricas: ¿recogida de getStats, tasa de conexión exitosa, tiempo hasta el primer frame, proporción de relay?
• Interop: ¿SIP/PSTN necesario ahora o más adelante?
• ¿Plan de pruebas de carga con participantes sintéticos antes del lanzamiento?

Recomendación

Para un producto nuevo en 2026: construye sobre un SFU desde el primer día, activa simulcast y empieza en gestionado (o LiveKit Cloud) salvo que ya sepas que tus minutos hacen más barato el self-hosting. Ejecuta TURN con credenciales efímeras desde el primer despliegue. Emite cada token de sala desde tu backend y mantén privada la API de control del SFU. Instrumenta getStats antes de tener usuarios. En Arvucore solemos recomendar LiveKit a los equipos que quieren un inicio gestionado con una vía creíble hacia el self-hosting, y mediasoup o Janus puros solo cuando el equipo tiene capacidad interna de ingeniería de medios.