WebRTC i stor skala: Hur Mandraki hanterar massiva gruppvideosamtal

Gruppvideosamtal är en av de funktioner som verkar enkla för användarna men som kräver betydande teknisk komplexitet under ytan. Ett samtal mellan två personer är relativt enkelt — två parter utbyter media direkt. Men så snart du lägger till en tredje deltagare blir arkitekturbesluten fler, och när du når femtio deltagare över flera samtidiga sessioner hanterar du ett genuint svårt distribuerat systemproblem.

Den här artikeln förklarar hur Mandrakis realtidsarkitektur för media är utformad för stor skala — utan att kompromissa med kryptering eller datasuveränitet.

Varför inte peer-to-peer

I en peer-to-peer-meshtopologi skickar varje deltagare sin medieström direkt till varje annan deltagare. I ett samtal med N deltagare skickar varje person N-1 strömmar och tar emot N-1 strömmar. Det totala antalet anslutningar är N*(N-1), och kravet på uppladdningsbandbredd för varje deltagare ökar linjärt med antalet deltagare.

Detta fungerar tillräckligt bra för tre eller fyra deltagare med goda internetanslutningar. Därutöver fungerar det inte. En deltagare med en uppladdningshastighet på 5 Mbit/s som skickar en videoström på 1,5 Mbit/s kan bara betjäna tre andra deltagare innan uppladdningskapaciteten mättas. CPU-belastningen för att koda flera strömmar ökar snabbt. Och nätverksförhållandena mellan godtyckliga par av deltagare är oförutsägbara.

Meshtopologin är elegant i teorin och opraktisk i stor skala.

SFU-ansatsen

En Selective Forwarding Unit (SFU) sitter mitt i samtalets topologi. Varje deltagare skickar en enda uppladdningsström till SFU:n. SFU:n vidarebefordrar sedan den strömmen till alla andra deltagare. Deltagarens uppladdningsbandbredd är konstant oavsett antalet deltagare — de skickar alltid bara en ström. SFU:n hanterar distributionen.

Den “selektiva” delen är viktig. En SFU vidarebefordrar inte urskillningslöst varje ström till varje deltagare. Den fattar intelligenta vidarebefordringsbeslut utifrån nätverksförhållanden, deltagarnas synlighet och tillgänglig bandbredd. Om en deltagares nedladdningsanslutning är begränsad kan SFU:n vidarebefordra ett lager med lägre upplösning. Om en deltagare för tillfället inte är synlig i användargränssnittet (till exempel i ett stort samtal där endast den aktiva talaren visas i full storlek) kan SFU:n minska eller pausa vidarebefordringen av deras ström.

Detta skiljer sig i grunden från en Multipoint Control Unit (MCU), som avkodar alla inkommande strömmar, sätter samman dem till en enda blandad ström, omkodar den och skickar den sammansatta strömmen till varje deltagare. MCU-servrar är CPU-intensiva, lägger till kodningsfördröjning och — vilket är avgörande — kräver åtkomst till mediet i klartext, vilket gör dem oförenliga med end-to-end-kryptering.

En SFU vidarebefordrar krypterade paket utan att avkoda dem. Det är detta som gör SFrame-baserad end-to-end-kryptering möjlig i ett gruppsamtal. SFU:n dirigerar krypterad text.

Mandrakis SFU-arkitektur

Mandraki använder ett SFU-bibliotek med öppen källkod som integreras direkt i vår infrastruktur. Istället för att förlita oss på en monolitisk mediaserver från tredje part bygger vi in SFU:n som ett bibliotek i vår egen kodbas. Det ger oss full kontroll över hur den samverkar med vårt applikationslager, vårt signalprotokoll och vårt autentiseringssystem.

SFU:n använder en arkitektur med flera arbetarprocesser. Varje arbetarprocess är en separat nativ process som sköter själva medieroutingen med nära nativ prestanda. Koordineringslagret hanterar arbetarprocesser, transporter och gränssnittet mot vår applikationslogik. Den uppdelningen håller medievägarna snabba samtidigt som kontrollvägen förblir flexibel.

SFU:n stöder simulcast och SVC (skalbar videokodning), vilket är avgörande för bandbreddsadaptiv vidarebefordran. Deltagarnas webbläsare kodar sin video i flera kvalitetsnivåer samtidigt. SFU:n väljer den lämpligaste nivån för varje mottagare utifrån deras tillgängliga bandbredd och kontexten i användargränssnittet.

Skalning till hundratals sessioner

För stora driftsmiljöer är arkitekturen utformad kring horisontell skalning med intelligent dirigering av sessioner.

SFU-distribution över flera instanser. Flera SFU-instanser körs över olika tillgänglighetszoner. Varje instans registrerar sin kapacitet hos ett koordineringslager. När ett nytt samtal skapas väljer systemet den SFU-instans som har mest ledig kapacitet. Deltagare i samma samtal dirigeras alltid till samma SFU-instans för optimal medierouting.

Parallellism på arbetarprocessnivå. Varje SFU-process startar flera nativa arbetarprocesser — vanligtvis lika många som antalet tillgängliga CPU-kärnor. Varje arbetarprocess kan hantera flera samtalsrum oberoende av varandra. Det innebär att en enda SFU-server med 16 kärnor effektivt kan hantera dussintals samtidiga samtal, vart och ett med upp till 50 deltagare.

Bandbreddsadaptiv vidarebefordran. I samtal med många deltagare träder flera optimeringar in automatiskt. Detektering av aktiv talare minskar antalet högkvalitetsströmmar som behöver vidarebefordras. Urvalet av simulcast-lager blir mer aggressivt och föredrar lägre lager för deltagare som inte syns. För deltagare med kraftigt begränsad bandbredd finns möjligheten att falla tillbaka på enbart ljud.

Distribution över flera zoner i Europa. Mandrakis infrastruktur körs över flera tillgänglighetszoner inom EU på hyperscale-infrastruktur som driftas i Europa. SFU-instanser placeras nära användarna, vilket minskar tur-och-retur-fördröjningen för mediapaket. All medierouting hålls inom Europas gränser — inga medier dirigeras genom infrastruktur utanför EU.

NAT-traversal

WebRTC:s största styrka — direkt peer-to-peer-anslutning — är också dess största utmaning. De flesta enheter sitter bakom NAT-brandväggar (Network Address Translation) som förhindrar direkta inkommande anslutningar. WebRTC använder ICE (Interactive Connectivity Establishment) för att hitta en fungerande nätverksväg och prövar i tur och ordning direkt anslutning, STUN-medierad anslutning och TURN-relä.

Mandraki kör dedikerade TURN-servrar bredvid SFU-infrastrukturen. TURN fungerar som ett relä i sista hand — när en deltagare inte kan etablera en direkt anslutning till SFU:n (på grund av restriktiva brandväggar, symmetrisk NAT eller företagsproxyservrar) flödar mediet genom TURN-servern. Det lägger till viss fördröjning men säkerställer att anslutningen kommer till stånd.

TURN-servrarna stöder både UDP och TCP, plus TLS för miljöer som bara tillåter HTTPS-trafik. Liksom allt annat i vår stack körs de helt inom EU.

End-to-end-kryptering i stor skala

SFU-arkitekturen är specifikt vald för att den bevarar kompatibiliteten med end-to-end-kryptering. Med hjälp av WebRTC Encoded Transforms och SFrame-protokollet (RFC 9605) krypteras medieramarna på avsändarens enhet innan de når SFU:n. SFU:n vidarebefordrar de krypterade ramarna till mottagarna, som dekrypterar dem lokalt.

SFU:n har aldrig åtkomst till media i klartext. Den dirigerar krypterad text. Det innebär att krypteringsgarantierna består även i stor skala — med dussintals deltagare och flera samtidiga samtal. Ingen server i vår infrastruktur ser eller behandlar okrypterat ljud eller okrypterad video.

Detta är ett grundläggande arkitekturval. Många plattformar hävdar att de använder kryptering men bygger på en MCU-baserad arkitektur som kräver avkodning på serversidan. Mandrakis SFU-tillvägagångssätt innebär att kryptering inte bara är en funktion — det är en strukturell garanti.

Övervakning och tillförlitlighet

WebRTC-problem är notoriskt svåra att diagnostisera. Vi samlar in telemetri från klientsidan, inklusive tillståndsövergångar i ICE-anslutningen, typer av valda kandidatpar, uppskattningar av tur-och-retur-fördröjning, paketförlustfrekvenser och bandbreddsuppskattningar. Dessa mätvärden buntas ihop och skickas till vår telemetriändpunkt för aggregering.

På serversidan loggar SFU:n transporthändelser, livscykeln för producenter och konsumenter samt bandbreddsuppskattningar. Kombinerat med telemetrin från klientsidan ger detta en heltäckande bild av samtalskvaliteten som låter oss identifiera och åtgärda problem systematiskt.

Realtidskommunikation i stor skala är en djup teknisk utmaning. Vi fortsätter att investera i den mediainfrastruktur som gör Mandrakis samtal tillförlitliga, krypterade från slut till slut och med låg latens — allt på suverän infrastruktur som driftas i Europa.