d

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore.

15 St Margarets, NY 10033
(+381) 11 123 4567
ouroffice@aware.com

 

KMF

What Is WebRTC and How It Works

The world of web-based communication is changing at a speed you might not even imagine Now, for making a video conferencing call, sharing a file—all that you need is a URL, thanks to the power of WebRTC for opening the door of infinite possibilities for developers and businesses.     

Developed by Google in 2011 as an open-source framework comprising standards, protocols, and JavaScript APIs, WebRTC or Web Real-Time Communications facilitates the peer-to-peer transfer of audio, video, and data without plugins, native applications, or any third-party proprietary software 

Supported by major browsers including Chrome, Safari, Mozilla, and Opera, the scope of new standard Web Real-Time Communication goes beyond the realms of web browsers.   

It’s indeed an exciting and disruptive technology built on top of free JavaScript APIs. All it requires is a few lines of JavaScript code, and you can enjoy a rich video calling with peer-to-peer data transfers.   

But wait! it’s not that simple: it leverages a variety of protocols and standards including SDP (Session Development Protocol), SIP (Session Initiation Protocols), NAT, ICE, and UDP/TCP, and many more to provide secure, interoperable (between browsers), real-time browser-based peer-to-peer communication.  

How WebRTC Works 

Similar to any genuinely disruptive technology, WebRTC may initially sound cool and magical! IT folks can be lured by the promises of building the next Zoom application only to discover how complicated it can be to gain an idea of the multiple moving components and understand how all of them fit into the overall piece of the puzzle—called WebRTC 

You can, however, get into the skin of things once you understand the basic concept. To enable WebRTC communication, the following four steps are required 

Step 1: Access to media streams through webcam or microphone (carried out via GetUserMedia JavaScript API) 

Step 2: Basic networkrelated information such as ports and IP addresses and this information needs to be shared with another browser through signalling (carried out via RTCPeerConnection JavaScript API) 

Step 3: Info about the parameters of media data (carried out via RTCPeerConnection JavaScript API)  

Step 4: Transfer media data (carried out via RTCDataChannel JavaScript API) 

Broadly, These Objectives Are Achieved With The Following Three Main JavaScript Groups: 

1. GetUserMedia (or MediaStream API) 

The API is used to access a webcam or microphone of the device and enables developers to receive access to the video/audio stream objects 

It assists in selecting the desired input user device out of multiple media capture devices. Whether it’s taking profile picture of a user, collecting audio samples, or recording audio/video—getUserMedia API performs these tasks.  

For instance, to open a default media device, it works the following way:  

  • A call to getUserMedia () instantly triggers a permission request that needs to be accepted by the user to get access to MediaStream.  
  • In case the permission is denied, it throws PermissionDeniedError 
  • If it doesn’t find any matching device, it throws NotFoundError.   

Source: webrtc.org

2. RTCPeerConnection 

It is the heart and soul of WebRTC, and the most complicated one. It almost performs all tasks taking place inside peer-to-peer communication.    

It performs the following functions:   

  • Settingup and creating a peer-to-peer connection 
  • Taking care of session management 
  • Managing all Session Description Protocol (SDP) message exchanges and handling negotiations through ICE candidates (uses STUN and Turn if required) 
  • Encoding and decoding media streams (audio/video/text) in real-time 
  • Handling all network-related issues such as bandwidth estimation, packet loss etc.  

Once a peer connection between browsers is established, multimedia streams can be sent to the remote browser. This, however, is not that easy as it sounds because of the following three distinct possible scenarios  

  • It is likely that both peers might reside within their private networks or behind multiple layers of NAT. Consequently, neither of them is approachable. 
  • They do not have the basic network information, such as IPport, and location about the other which are vital to establishing communication. 
  • And finallyboth will require traversing the NAT.  

A proper understanding of why these scenarios arise in the first place is important. The simple reason is Internet has moved beyond the client-server paradigm long ago.  

WebRTC Signalling NAT Traversal

Before starting communication between browsers, it needs three things:  

  • Identify peers 
  • Exchange session descriptions to setup media ports and IPs 
  • Information about media data which is imparted through SDP (Session Description Protocol) 

Nowadays, people prefer accessing the web behind firewalls or NAT that masks your original IP address by dynamically changing it. What the public at large see as the IP can be very different from the original IP of the user hidden behind a firewall, and there are some devices that block the unsolicited traffic toward the users’ network. Some enterprises don’t allow any traffic to their network without vetting it. As a result, it is not always possible to communicate with the peer browser located in the private network.  

That’s where the roles of STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers come into the picture.   

This is how the process goes:  

  • A request for public IP address is sent to STUN/TURN servers.  
  • Now, this server responds with the IP address that it perceives correct.   
  • It creates a set of Interactive Connectivity Establishment (ICE) that contains IP address, port, and transport protocols.   
  • With this information about the public IP and port, it easily connects with the peer   
  • The peer browser, on the other hand, does the same thing while using the STUN or TURN server. 

Here it is to be noted that signalling is not a part of the WebRTC frameworkit was left out for valid reasons. Different applications might need different protocols and the working group for WebRTC did not want to limit the choices for developers 

3. RTCDataChannel

Apart from audio and video, WebRTC manages the bidirectional transmission of arbitrary data including text chats, games, and other files through RTC DataChannel API. Every data channel is connected through this API.   

Summing Up

The importance of WebRTC in peer-to-peer communication is obvious, but multiple factors like Multiple Conferencing Unit (MCU), multitenancy, SIP integration need to be taken into account while building a reliable, robust, and scalable video calling solution. For developers, there is a better way to build a video calling solution—they can opt for a CPaaS service provider that offers all features, building blocks, and SDKs to build exciting and scalable video calling solutions.   

Credit: Source link

Previous Next
Close
Test Caption
Test Description goes like this