Si estàs muntant un side project en JavaScript i necessites videotrucades, és normal que t'entrin dubtes: tir de WebRTC pur, faig servir un SDK com Agora, Twilio, Mux o ZEGOCLOUD, o m'emboco la manta al capdavant amb RN-WebRTC a React Native? La mala notícia és que no hi ha una recepta única. La bona és que entens temps real a JS i això et col·loca en una posició ideal per prendre una decisió informada i no “cagar-la” amb l'arquitectura.
A les següents línies veuràs, pas a pas, com funciona WebRTC per dins, quin paper juga Agora (i altres proveïdors similars), què implica muntar la teva pròpia infraestructura (STUN/TURN, senyalització, SFU, media servers…), i quins trade-offs reals hi ha entre cost, complexitat i escalabilitat per a videotrucades i streaming en temps real.
Què és WebRTC i per què és la base de tot?
WebRTC (Web Real-Time Communication) és un conjunt d'estàndards, APIs i protocols de codi obert que permeten àudio, vídeo i dades en temps real directament des del navegador o una app nativa, sense connectors ni aplicacions externes. Està estandarditzat per W3C i IETF i ho suporten tots els navegadors moderns: Chrome, Firefox, Safari, Edge, Opera i molts navegadors mòbils.
La seva filosofia és clara: habilitar comunicació punt a punt (P2P) entre usuaris amb latències molt baixes, gestionant per sota tots els temes incòmodes de xarxes, còdecs, jitter, ressò, pèrdua de paquets, xifrat, etc. Això inclou des d'una videotrucada un per un fins a un sistema de streaming interactiu amb centenars o milers despectadors si ho combines amb la infraestructura adequada.
APIs clau de WebRTC: getUserMedia, RTCPeerConnection i RTCDataChannel
WebRTC es recolza en tres APIs principals del costat del navegador que utilitzaràs sí o sí, tant si muntes la teva solució pròpia com si fas servir un SDK tipus Agora:
- MediaStream / getUserMedia: per capturar vídeo i àudio (càmera, micròfon, i fins i tot pantalla o pestanyes).
- RTCPeerConnection: per negociar i transportar fluxos d'àudio i vídeo entre parells.
- RTCDataChannel: per enviar dades arbitràries (text, binari, arxius) amb baixa latència entre clients.
Amb getUserMedia pots demanar al navegador accés a càmera i micro i rebre'n un MediaStream que després associes a un element <video> amb video.srcObject = stream. Pots aplicar restriccions (resolució, framerate, càmera frontal/darrere, etc.) i, si no es compleixen, obtindràs errors del tipus OverconstrainedError, que has de manejar per oferir alternatives (per exemple baixar de 1080p a 720p i aplicar ajustaments per millorar l'àudio del micròfon).
L'API de RTCPeerConnection és el cor de les trucades: s'encarrega de la negociació SDP (oferta/resposta), la recopilació de candidats ICE (STUN/TURN), l'establiment de la connexió i la transmissió segura mitjançant SRTP. Des del teu codi només crees la connexió, afegeixes les pistes de mitjana, reacciones a esdeveniments com onicecandidate u ontrack i t'ocupes de la senyalització.
Finalment, RTCDataChannel us permet muntar canals de dades similars a un WebSocket, però punt a punt i amb control fi de fiabilitat i ordre. És útil per a xat integrat a la trucada de vídeo, intercanvi d'arxius, sincronització d'estat en jocs o col·laboració en temps real. La sintaxi és familiar: dataChannel.send() y onmessage al receptor.
Senyalització: la “cola” que WebRTC no defineix
Un malentès típic: WebRTC no inclou la senyalització. RTCPeerConnection necessita intercanviar informació, però no imposa com. Això et toca definir-ho a tu o t'ho abstrau un SDK de tercers.
Mitjançant senyalització els parells s'envien:
- Missatges de control de sessió: iniciar trucada, penjar, errors.
- Informació de xarxa: candidats ICE (adreces IP/ports descoberts).
- Metadades de mitjans: ofertes i respostes SDP amb còdecs, resolucions, etc.
Aquesta senyalització sol implementar-se amb endolls web, Socket.IO, HTTP (polling/long-polling), MQTT o altres mecanismes bidireccionals. Un patró molt típic és un servidor Node.js amb Socket.IO que gestiona “sales” i reenvia missatges tipus text/JSON entre clients:
servidor: rep create or join, crea una sala si no existeix, admet fins a dos clients (per a una videotrucada bàsica) i reenvia missatges message als altres sockets de la sala. Tu t'encarregues de no superar el nombre màxim d'usuaris o dissenyar la teva pròpia lògica de rooms.
Client: en carregar la pàgina, demana un nom de sala (o l'infereix de la URL), emet create or join, escolta esdeveniments com created, joined, full, ready i es posa d'acord amb l'altre extrem per arrencar o rebutjar la trucada.
Aquest patró és perfecte per a un prototip o side project: et dóna un servidor lleuger de senyalització que pots escalar amb clusters i balancejadors si ho necessites.
STUN, TURN, ICE: travessar NATs i tallafocs sense tornar-te boig
En un món ideal, dos usuaris estarien sempre a xarxes accessibles i es connectarien directament. Al món real hi ha NATs, firewalls, CGNAT de l'ISP i xarxes corporatives paranoiques. Aquí entra en joc ICE, que combina STUN i TURN.
- ESTUFA (Session Traversal Utilities for NAT) permet que un client esbrini la seva IP i port públics. El servidor STUN només respon amb aquesta informació.
- TORNAR (Traversal Using Relays around NAT) actua com servidor de retransmissió de mitjans quan no hi ha manera dobrir un canal directe P2P. El trànsit dàudio/vídeo passa per ell, així que consumeix ample de banda de servidor i diners.
- ICE (Interactive Connectivity Establishment) s'encarrega de provar tots els candidats possibles (adreces locals, reflectides per STUN, relays TURN) fins a trobar una ruta viable.
A la pràctica, al teu objecte de configuració de RTCPeerConnection afegeixes un array de iceServers amb URIs STUN/TURN, i el navegador s'encarrega de la màgia. Si muntes la teva pròpia infra, hauràs de desplegar i mantenir els teus servers STUN/TURN; si uses un SDK com Agora, Twilio o ZEGOCLOUD, ells ja tenen això resolt i llest per a producció.
Streaming en temps real de baixa latència: WebRTC vs HLS/DASH
Quan parlem de streaming en directe hi ha dos mons ben diferenciats: protocols basats en HTTP (HLS, DASH) i WebRTC. HLS/DASH funcionen a base de segments de vídeo que el client va descarregant i reproduint; això és perfecte per a escalabilitat via CDN, però introdueix latències de diversos segons (5-30 s fàcilment).
WebRTC, en canvi, utilitza UDP + RTP i lliura el vídeo en mode “empenta” des de l'origen al reproductor, amb temps d'inici molt curts i latències típiques per sota de 500 ms (sovint ~250 ms) si la xarxa acompanya. Ho aconsegueix gràcies a:
- Control de congestió integrat, que ajusta bitrate i resolució en temps real segons la pèrdua de paquets, jitter o RTT.
- Ús de còdecs eficients (VP8, VP9, H.264; cada vegada més AV1) amb acceleració maquinari quan està disponible.
- Possibilitat de fer servir SVC (Scalable Video Coding) perquè el receptor rebi només les capes que pot suportar la seva xarxa/dispositiu.
Per això WebRTC és l'opció natural per subhastes en temps real, apostes esportives live, trading, gaming interactiu, suport remot, telemedicina, aules virtuals participatives o dashboards financers que no es poden permetre diversos segons de retard.
El problema és que WebRTC pur P2P no escala bé milers d'espectadors; per això necessites SFUs, mitja servers o plataformes híbrides, que és just on entren solucions com Flussonic, Agora o similars.
Escalar més enllà del P2P: SFU, media servers i arquitectures híbrides
En una videotrucada tu a tu, WebRTC es comporta de luxe. Però si comences a ficar 10, 20 o 100 usuaris, la cosa canvia: cada client ha d'enviar/rebre múltiples fluxos, la CPU s'escalfa i la xarxa s'enfonsa. Aquí apareixen tres patrons clàssics:
- MCU (Multipoint Control Unit): el servidor rep tots els fluxos, els barreja i n'envia un de sol a cada client. Avantatge: poc consum al client. Inconvenients: càrrega brutal al servidor, menys control individual de qualitat.
- SFU (Selective Forwarding Unit): el servidor rep fluxos i els reenvia selectivament, sense barrejar. Cada espectador rep els streams que necessita, possiblement en diferents qualitats. És el patró més usat avui per videoconferències multiusuari i streaming interactiu escalable.
- Arquitectures híbrides WebRTC + HLS/DASH: WebRTC s'usa per a la ingesta i la interacció, mentre que HLS/DASH distribueix grans audiències que no necessiten interacció en temps real. És un equilibri entre latència ultra baixa per als “actors” i escalabilitat massiva per a “espectadors”.
Mitjana servers com Flussònic o altres proporcionen el backend necessari: reben el flux WebRTC, el transcodifiquen si cal, reenvien mitjançant WebRTC a altres clients o el converteixen a protocols tipus HLS per a distribució massiva. Aquest tipus d'infraestructura és el que, a la pràctica, fa viable anar més enllà de les trucades un a un sense haver de reinventar tota la roda.
Casos d'ús típics: videotrucades, streaming, IoT i molt més
WebRTC s'ha tornat omnipresent i probablement el facis servir cada dia sense adonar-te'n. Alguns exemples on encaixa especialment bé són les videotrucades i videoconferències:
- Videotrucades i videoconferències: Google Meet, Jitsi, Slack, Microsoft Teams i moltes altres eines es recolzen en WebRTC (en part o totalment) per al vídeo, àudio i compartir pantalla.
- Serveis de streaming en temps real: plataformes tipus Twitch, Meta Live, Vimeo Livestream o eines com Streamyard combinen WebRTC per a la ingesta i altres tecnologies per a distribució massiva.
- Xat i missatgeria amb intercanvi d'arxius: gràcies a RTCDataChannel pots tenir xat en temps real, enviament de fitxers, sincronització d'estat, etc., sense servidors centrals de mitjana.
- Gaming al núvol i multijugador: serveis com GeForce NOW o Xbox Cloud Gaming aprofiten tecnologies similars per a vídeo interactiu; molts jocs P2P utilitzen WebRTC per sincronitzar partides.
- IoT i vigilància: càmeres intel·ligents, monitors de nadó, timbres amb vídeo o drones poden enviar vídeo en temps real a mòbils i navegadors usant WebRTC.
- Educació i telemedicina: aules virtuals amb pissarres, qüestionaris i vídeo bidireccional, o consultes mèdiques en línia on la latència i la seguretat són crucials.
Seguretat a WebRTC: xifrat, permisos i bones pràctiques
La seguretat a WebRTC no és un extra: està integrada des del disseny. Tots els components de mitjana van xifrats i les API només funcionen des d'orígens segurs (HTTPS o localhost), encara que convé estar alerta davant estafes mitjançant videotrucades.
- DTLS (Datagram Transport Layer Security) xifra les dades en trànsit.
- SRTP (Secure Real-time Transport Protocol) protegeix àudio i vídeo perquè no es puguin manipular o interceptar fàcilment.
- L'accés a càmera i micròfon requereix permís explícit de lusuari, amb indicadors visuals visibles (icones, punts de color, etc.).
- En no haver-hi plugins per instal·lar, es redueix el risc de programari maliciós camuflat en extensions o binaris de tercers.
Tot i així, has de cuidar la teva pròpia capa: fer servir HTTPS a tot, revisar els permisos que demanes, mantenir navegadors i llibreries actualitzades, i no descuidar la seguretat del teu servidor de senyalització o dels teus APIs REST.
WebRTC vs altres tecnologies: VoIP, WebSockets i plataformes propietàries
Si veniu del món VoIP clàssic, us sonaran SIP, PBX, softphones i servidors cars. WebRTC canvia el paradigma: no necessites requerir cap usuari client d'escriptori ni un maquinari específic, només cal el navegador i un servidor de senyalització relativament senzill.
davant VoIP tradicional, WebRTC redueix el pes en infraestructura central i obre la porta a aplicacions directament integrades a la web. En molts casos pots reutilitzar el teu backend SIP a través de passarel·les que tradueixin senyalització a WebRTC.
Respecte endolls web, cal veure'ls més com a complementaris: són ideals per a notificacions, xat lleuger o canvis d'estat, però no per a mitjana intensiu. WebRTC està optimitzat per àudio/vídeo en temps real, amb control de congestió, còdecs, jitter buffer, etc. A la pràctica, molts projectes usen WebSockets per a la senyalització i WebRTC per al transport de mitjans.
Si els compares amb plataformes tipus Zoom, GoToMeeting o WebEx, la diferència és de model: aquestes eines són solucions tancades, moltes vegades amb apps descriptori obligatòries i backend propietari. WebRTC, en canvi, és una tecnologia base; sobre ella pots construir la teva pròpia “mini-Meet” o integrar-te amb serveis que ja la usen (com fa Google Meet o Microsoft Teams).
Desenvolupar amb WebRTC: complexitat real i trampes habituals
Encara que les APIs semblen senzilles sobre el paper, implementar WebRTC des de zero té la seva molla. Hauràs de bregar amb:
- Senyalització a mida: dissenyar missatges, rooms, gestió de reconnexions, reintents, errors.
- Gestió d'ICE/STUN/TURN: desplegar servidors, monitoritzar ús de TURN (que consumeix ample de banda), ajustar timeouts.
- Qualitat de servei (QoS): adaptar bitrats, manejar xarxes inestables, negociar còdecs, detectar quan una connexió es degrada i reaccionar.
- Escalat: passar d'un simple P2P a grups, després centenars d'usuaris, introduir SFUs o mitja servers sense trencar el disseny original.
- Compatibilitat entre navegadors: encara que la situació és bona, seguiràs trobant matisos. Usar adapter.js segueix sent molt recomanable.
En un side project petit, muntar un servidor Node amb Socket.IO i un STUN públic pot ser suficient per trucades 1:1 o grups molt reduïts. Però si la teva idea creix i necessites molta concurrència, control de qualitat fi, enregistraments, anàlisis, transcripcions o monetització, aviat hauràs de plantejar-te o bé incorporar un mitjana server propi, o passar-te a un proveïdor especialitzat.
CDN en temps real amb SDKs: Agora, Twilio, Mux, ZEGOCLOUD…
serveis com Agora, Twili, Mux, ZEGOCLOUD o similars construeixen sobre WebRTC una capa de valor que t'estalvia mesos de treball i infinitat de mals de cap:
- T'ofereixen una xarxa global de mitjana amb SFU repartits pel món, optimitzats per baixa latència.
- Abstreuen STUN/TURN, senyalització, reintents, reconnexions i gestió de xarxa complicada.
- Inclouen SDKs ben mantinguts per web, iOS, Android, React Native i altres frameworks.
- Aporten extres com enregistrament, broadcasting a RTMP/HLS, moderació, estadístiques en temps real, controls de qualitat, rols d'usuari (host, audience, speaker), etc.
El cost, com ja sospites, és el principal problema: per poc que tinguis molts minuts de vídeo o força usuaris concurrents, la factura es dispara. A més, et tornes dependent de la plataforma i dels canvis de preu o d'API.
En la teva situació concreta, amb experiència forta a JS en temps real, una opció força assenyada és començar amb un SDK per accelerar el desenvolupament, validar el producte i aprendre del seu model de rooms, rols, cicle de vida de streams i gestió d'estat. Més endavant, si el projecte s'enlaira i el cost es converteix en un problema, pots migrar gradualment parts de la solució a una infraestructura WebRTC pròpia o recolzar-te en un media server tipus Flussonic per controlar la capa de distribució.
Bones pràctiques i eines per depurar WebRTC
Perquè no et perdis a la caixa negra de WebRTC, convé que et donis suport a les eines que ja existeixen als navegadors ia l'ecosistema:
- chrome: // WebRTC-internals (o sobre:webrtc a Firefox): panell amb estadístiques detallades de connexions, bitrats, pèrdua de paquets, còdecs actius, etc.
- adapter.js: shim mantingut per la comunitat que suavitza diferències entre navegadors i versions.
- test.webrtc.org: per comprovar càmera, micro, xarxa i compatibilitat general en una màquina.
- Samples oficials a webrtc.github.io/samples: exemples de constraints, peer connections, data channels, screen sharing… molt útil per copiar patrons.
També és bona idea estructurar el codi separant clarament la capa de senyalització (sockets, rooms, missatges) de la capa de WebRTC pur (creació de connexions, gestió de streams, handlers d'esdeveniments). Així podràs substituir un backend de senyalització o un mitjà server sense reescriure tota la lògica del client.
Amb tot això sobre la taula, per a un side project que comença i on valores tant el temps de desenvolupament com cost a mitjà termini, l'estratègia més equilibrada sol ser arrencar amb un SDK en temps real basat en WebRTC que et permeti iterar ràpid a React/React Native, interioritzar bé com gestionen rols, sessions, cicle de vida de streams i estats en viu, i en paral·lel anar aprofundint en WebRTC “a pèl” (getUserMedia, Node+Socket.IO, STUN/TURN, SFU) per no quedar-te lligat per sempre a una sola plataforma i poder fer el salt a una solució més custom quan el producte ho justifiqui.