WebRTC för nybörjare

Written by: Eja Höglund

Published: 27 May, 2021

Updated: 09 Jun, 2021

Här kommer jag ge dig en inblick i vad WebRTC är och hur teknologin kan användas. Min förhoppning är att informationen ska hjälpa dig att komma igång med WebRTC för att kunna bygga något kul 😃

Vad är WebRTC?

WebRTC står för Web Real-Time Communication och är en teknologi som är inbyggd i moderna webbläsare.

Teknologin används bl.a för att ringa röst- och videosamtal över internet. Du kan även skicka filer och direktmeddelanden likt Messenger, Skype och Telegram. På WebRTC samples finns många exempel på vad som går att göra.

Tack vare WebRTC kan webbläsaren få direkt tillgång till enhetens kamera och mikrofon. Detta var (tydligen) otroligt krångligt (om inte omöjligt) att åstadkomma innan WebRTC fanns.

WebRTC möjliggör även direktkommunikation mellan två webbläsare (s.k. peer-to-peer) istället för att behöva skicka datan via en server. Trots detta är dock WebRTC fortfarande beroende av en server för att webbläsarna ska hitta varandra initialt. Jag kommer inte gå in på hur du sätter upp en sådan server för helt ärligt så vet jag inte 🤷🏻‍♀️. Troligtvis kommer du använda en befintlig lösning från någon leverantör, exempelvis 46elks.

Vänta, jag fattar inte. Vad är grejen med peer-to-peer? 🤔

Du kan se det lite som att du gräver en tunnel från ditt hus till din kompis hus. Det är bara ni två som använder tunneln och behöver därmed aldrig oroa er för trafikstockning.

Jämför detta med att du behöver ge dig ut i trafiken och trängas med andra människor och bilar för att komma fram till din kompis hus.

Hur kommer jag igång med WebRTC?

Jag rekommenderar dig att läsa Get Started with WebRTC. Där finns mycket nyttig information. Övergripande skulle jag säga att WebRTC bygger på tre olika API:er:

För att implementera WebRTC kan du antingen bygga din lösning från grunden baserat på dessa tre API:er, eller så kan du använda externa bibliotek som gör livet lite lättare för dig, t.ex. JsSIP och SIP.js.

Nedan förklarar jag kortfattat vad dessa tre API:er gör.

MediaStream

Detta API skapar ett javascript-objekt som du kan använda i din kod för att styra din kamera och din mikrofon (t.ex. pausa videon eller stänga av mikrofonen).

När en webbläsare ber om tillstånd att få använda enhetens kamera och mikrofon kommer detta API visa dig en notis där du explicit måste godkänna att webbläsaren får använda detta.

I kod kan det se ut så här när webbläsaren ber om tillgång till mikrofonen:

navigator.mediaDevices.getUserMedia({
    video: false,
    audio: true
})

Notisen i webbläsaren kan se ut så här:

När du har godkänt att webbläsaren får använda mikrofonen, kommer API:et hämta ljudet och lägga det i en MediaStream som du sedan kan använda i din applikation.

Du kan se MediaStream som en livesändning. Ljudet kommer kontinuerligt strömmas från din mikronfon och du kan förslagsvis skicka strömmen via RTCPeerConnection till klienten på andra sidan så att hen hör vad du säger under ett samtal.

Om både mikrofonen och kameran används kommer de läggas i samma Mediastream fast i olika tracks. Du kommer åt respektive track via MediaStream.getTracks().

Vänta, vadå livesändning? Kommer jag för all framtid ha godkänt att min webbläsare får spionera på mig och dela det med hela världen? 😱

Nej. Du godkänner att en specifik flik i webbläsaren får använda din kamera och mikrofon under en specifik session. När du stänger ner fliken så kommer webbläsaren inte längre ha åtkomst till kameran och mikrofonen.

Om du fortfarande är orolig kan du stänga av datorn, dra ut internetsladden och bostätta dig långt ute i skogen där din webbläsare aldrig hittar dig 😉

RTCPeerConnection

Detta API tar hand om kopplingen mellan din webbläsare och klienten på andra sida. Via detta API kan du t.ex. se när någon försöker ringa dig och du kan välja att svara på samtalet och/eller avluta samtalet. Det är även här du hämtar ut den MediaStream som skickas från klienten du pratar med.

Värt att notera att det krävs en del kommunikation i bakgrunden för att två klienter ska hitta varandra över internet. Detta är dock utanför vad RTCPeerConnection kan göra. I detta steg behöver därför WebRTC hjälp av en server som kan hantera denna kommunikation.

Följande är inget du behöver bryr dig om såvida du inte vill sätta upp en egen server. Det är dock bra att ha hört eftersom det nämns i sammanhang rörande WebRTC. På serversidan sker bl.a. detta:

  • Signaling: För att upptäcka den klient du vill prata med behövs ett s.k. signalprotokoll (t.ex SIP). Signalprotokollets uppgift är att vinka till klienten och säga ”Hallå! Jag vill prata med dig” och sedan invänta ett bekräftande svar.
  • STUN: Ett protokoll som används av servern för att ta reda på den publika IP-adressen bakom NAT. Tack vare STUN kan vi fortfarande kommunicera peer-to-peer trots att NAT ”ligger i vägen”.
  • TURN: Ett protokoll som används av servern som en fallback om STUN skulle misslyckas. Med TURN går kommunikationen via servern fram till klienten. Kommunikationen kommer förvisso inte längre vara peer-to-peer men klienterna kommer åtminstone kunna fortsätta kommunicera med varandra.
  • ICE: Ett ramverk som används av servern för att avgöra om STUN eller TURN ska användas.

Vad är NAT? NAT står för "Network Address Translation" och är en mekanism som mappar lokala och publika IP-adresser till varandra. Utan NAT skulle vi inte kunna koppla upp alla våra enheter till internet eftersom antalet publika IPv4-adresser inte skulle räcka till.

RTCDataChannel

Detta är kanalen där all data (förutom ljud och video) kan överföras, t.ex. om du vill skicka ett textmeddelanden eller en söt kattbild.

Jag har inte jobbat med detta API ännu och har därför inte så mycket att säga.

Nudå?

Jag uppmuntrar dig till att göra din egna research, testa dig fram och dela dina lärdomar med andra - Det är precis vad jag gjorde.

Från att knappt veta vad WebRTC var lyckades jag bygga en demo för att ringa och ta emot samtal mellan en webbläsare och en vanlig telefon. Du får gärna ta del av kodexemplet jag laddade upp på GitHub.

Gillar du utmaningar? Testa att modifiera koden från GitHub så att du även kan skicka textmeddelanden mellan en webbläsare och en telefon. Hör gärna av dig och berätta hur det går. Jag är nyfiken 😁