webRTC → Architectural overview: Peer-To-Peer in the Browser
Alright guys it is already the end of 2020 and our beloved Corona’s celebrating its 1st year anniversary and which has made us take the longest summer vacation in the history of mankind I guess.
Yuppp.. summer is over and “winter is coming” be prepared..!!! This has made us, use the two way live streaming a lot recently. We all have frequently started to use applications like Zoom calls, Google Meet, GoToMeeting and Discord etc.. (End of Thinking Capacity). Yeah we have used these guys a lot and are still gonna use a lot.
But have you ever wondered what really goes on behind this, i.e. how exactly this is working. What we should exactly do is to understand that we should open up our Google Browser and say Thanks Google, yuppp..
Google is responsible for the OpenSource Project, i.e. the Peer to Peer connection. Once again it is all thanks to “almighty Uncle Google.”
Before we go in detail, let’s see who all have actually made use of this OpenSource Project,
- Google Meet / Hangouts, yeah they are supposed to use their product.
- GoToMeeting
- Discord
- Amazon Chime
- Facebook → Messenger, Facebook Live
- Zoom (Yeah even these guys are using it, have a look at the tweet by the official creator of webRTC)
But you may also ask a question: is YouTube using webRTC ?
It’s a hypothetical question since they are only using it for VP9 video codec, i.e. Video Processor version 9 and currently everyone else is using VP8 and our beloved Uncle Google alone is testing out things with YouTube with the VP9. When it comes to Google something fishy always goes on.
Alright it’s webRTC which has been used by all these guys.
What is webRTC?
“webRTC” stands for Web Real Time Communication, which is plugin free and a networking technology introduced by Google → for the Googlers and rest of the world for real-time audio, video, and data transmission across the web and native browsers.
In webRTC there’s no need for servers to be involved in transferring real time data from one client to another client. Here the connections are peer to peer and so sending data is very simple with the help of webRTC API which is available for all the platforms without the use 3rd party app and support almost all the platforms.
Initially the servers are required for the client computers to get connected and once they’re connected they can communicate with each other without the server.
Note: Session Description Protocol (SDP):
SDP is a standard for describing the multimedia content of the connection such as resolution, formats, codecs, encryption, etc. so that both peers can understand each other once the data is transferring. This is, in essence, the metadata describing the content and not the media content itself.
Technically, then, SDP is not truly a protocol, but a data format used to describe connections that shares media between devices.
To understand this webRTC in simple way, let’s consider a scenario where,
Here for establishing a connection the client 1 has to create a offer i.e. SDP (Session Description Protocol) which is the media configuration of the client 1, i.e. with which he/she can send the Video / Audio / Both.
1st the C1 will send an offer (SDP) to the server / signaling server and that will forward it to c2 and c2 will store it in its local memory. Once this is done it has to offer the media configuration of c2 to c1 in the same way back.
Now these C1 and C2 has the details of each others “media configuration” and for the connection to be established between them, they are supposed to share their own Network Information i.e. Network Configuration.
Here just go with the flow as I haven’t given details about STUN and TURN Servers and will make another Blog on those stuffs.
What is Network Configuration ?
Network configuration is the process of assigning network settings, policies, flows, and controls.
Note: ICE→ Interactive Connectivity Establishment
Once the C1 connects with a Signalling server and an offer (SDP) has been shared, something known as the ICE Candidates will come from the webRTC i.e. which is generated from the STUN and TURN servers.
In order to get the ICE Candidate from the STUN and TURN servers for the C1, all it needs to do is provide the URL of STUN and TURN to webRTC API i.e.
Once the C1 creates the offer (SDP) with a signaling server, the webRTC will start to get ICE Candidates from the STUN and TURN servers.
Now the job for this c1 is to send the Network Configuration to c2 and this happens the same way.
This is the reason why a server is needed for the 1st time connection establishment. Since both c1 and c2 now have each other Network Configuration they establish a “Peer — Peer Connection”.
API of webRTC:
- getUserMedia
- RTCPeerConnection
- RTCDataChannel
Out of the 3 webRTC API, getUserMedia() is the one that allows the browser to capture streaming voice and video using JavaScript Commands.
In simple terms, getUserMedia() is the 1st Link in the chain.
Before RTCPeerConnection can route a browser’s real time data to another browser, users streaming data has to be captured by getUserMedia.
With the getUserMedia, the browser is able to capture data from the webcam & microphone and it’s turned into basic JavaScript Object.
In simple terms the getUserMedia, RTCPeerConnection and RTCDataChannel are HTML 5 API that gives JavaScript enhanced media capabilities.
Internet Engineering Task Force (IETF):
This Internet Engineering Task Force is the open standards organization, which develops and promotes voluntary Internet Standards, in particular the standards that comprise the Internet protocol suite (TCP/IP).
The IETF, decides what standard the webRTC is going to follow, whether vp8 / vp9 or H.264/H.265.
Both the audio codec ( Opus ) and video codec ( VP8 / VP9 ) are officially standardized by IETF.
Audio and Video Codec:
Codec:
A codec is a standard or tool for encoding and decoding multimedia files.
When comparing VP8 and x264, VP8 also shows 5–25 times lower encoding speed with 20–30% lower quality on average. For example x264 High-Speed preset is faster and has higher quality than any of VP8 presets on average.
Opus is a lossy audio codec that has some significant advantages over other lossy codecs such as MP3 or AAC. First, Opus is an open standard, and as such is royalty-free. Another advantage of Opus is its remarkable audio quality, especially at low bitrates. Moreover, this quality is achieved at very low latencies, which makes Opus a logical choice for interactive music and speech transmission. However, it is also very well suited for storage and streaming applications.
“Sharing some facts about the Audio and Video Bitrates”
Video Bitrates:
- VP8 with Chrome — it will take up 1.77 Mbps when the camera source is VGA.
- VP8 has no limit on frame rate or data rate.
- The WebRTC video codec is powered by libvpx, which is the only software library that can encode VP8 video streams.
Audio Bitrates:
- Opus isn’t in wide use yet, but it’s considered a next-generation codec.
- Opus provides 26.5 ms latency, when using its default settings (20 ms frame size), making it highly suitable for Voice over IP (VoIP) communications.
- Opus has a variable bitrate (VBR) mode that can range from 6 kbit/s to 510 kbit/s to help minimize bandwidth while maintaining consistent quality for applications that require that.
I have given the detail of the STUN and TURN Servers in another Blog and working on that as of now. Before leaving you all just like that have a look at the comparison based on my understanding.
Comparison of STUN & TURN
If you wish to stay connected,
you can just google “ narenltk / narendiran krishnan ” or just drop a mail to → narenltk@gmail.com → Happy to help..!!!
