An open-source project released by Google in 2011, WebRTC provides API-based communication between web browsers and mobile applications, including transmissions of audio, video, and data. Eliminating the need for native plugins and app installations makes these connections user-friendly and supported by all the major browsers and mobile operating systems.
The adoption of WebRTC in the tech community has grown dramatically in the past few years. Facebook, Amazon, and Google are among the significant technology companies that implemented WebRTC to make their web applications faster, reliable, and more secure.
WebRTC features are also provided in off-the-shelf solutions that can be easily integrated with other software. A good example is OpenTok, a PaaS for live communications, courtesy of our business partners at former TokBox (now Vonage). We successfully used it in many solutions for our clients, including an advanced authentication service based on biometric techniques.
As was already mentioned in the Summary, the key characteristic of WebRTC is that it is simple yet complex technology. The essence of simplicity comes down to the ease of implementation. It’s enough to use five to ten lines of code to organize peer-to-peer video communication between two browsers. The complexity of the technology is related to the specificity of WebRTC, which must be adapted to different browsers, and to the fact that it is hard to configure if it doesn’t work correctly. Also, to obtain the desired result, you should be aware of STUN, TURN, and NAT.
Now, that you know what WebRTC is, let’s plunge into history to understand when and how the technology appeared, and in which cases it can be used. Also, we’ll overview the pros and cons of the technology, examples of WebRTC solutions, and high-demanded WebRTC apps. By default, these applications are based on peer-to-peer communication. If we need to organize group calls and live streaming, it’s mandatory to use a server that operates as a protocol client.
The primary focus of WebRTC is to provide real-time audio and video communication between participants, who use web browsers to start conversations, locating each other, and bypassing firewalls.
To send and receive streams of data, WebRTC provides the following APIs that can be used in web applications:
A set of standards for the use of WebRTC in software is currently being developed by the Internet Engineering Task Force and the Web Real-Time Communications Working Group.
WebRTC is primarily just a way to send and receive UDP packages inside browsers. Also, WebRTC knows about the transfer of media—both audio and video, and it can connect two clients directly— peer-to-peer. Developers admit that under the hood, WebRTC is a fairly simple thing: open the UDP port, know the partner’s IP port, wrap the traffic in RTP.
Let’s talk about what happens between the capture from the camera and the video playback on the screen. This process consists of 7 basic steps:
The browser has an API that allows us to ask users for access to the camera or microphone—navigator.getUserMedia => MediaStream. The main difficulty is that we can’t immediately send media streams to the interlocutor because they weigh a lot without compression. For example, one image 640×480 in format BMP weights 1.2 Mb. The number of such pictures per second is 30. It means that one second of the video weighs 36 Mb. Therefore, the bit rate will be 288 Mbps. Data must be compressed for transfer. So the next step—coding—is mandatory.
In simple terms, codecs allow the compression of audio and video streams. There is a broad set of such codecs, and part of them are available in WebRTC. Let’s take VP9 as an example. This codec is being used for coding images in WebRTC. It can transmit images with resolution 1280×720, compressing them so that 30 frames weigh 1.5 Mbps. How can VP9 do this?
Instead of constantly sending information about the images, VP9 differentiates between the two images. We get the mainframe at the output, while other interframes represent differences from the mainframe. More actions in the frame mean more image weight.
On the basis stage, the keyframe with information about all pixels is determined, and interframes represent the differentiation in comparison with previous states. If we lose in the chain of interframes at least once, we cannot draw other interframes.
Data is packed in RTP—Real-time Transport Protocol, which contains information about the order of the packages. It’s a mandatory step because packages can come in a different order or even be lost. We need the number of packages to reproduce them in the correct order. Also, RTP stores information about the time that allows synchronization of audio and video tracks. Additional details of RTP have a small overhead of about 5%.
There is an extension of the primary protocol named RTCP. It serves to exchange information about lost packages and statistics of their receiving.
Data is being sent as a formed UDP package. If we compare UDP and TCP, the main advantage will be a minimal interval between packages. UDP has a few disadvantages: packages are being lost, arrive late, and end up in the wrong order.
The order of packages is restored at this stage. The video traffic is received and transmitted to the decoder.
Data is being sent in the correct order, and at the output, we get a pure video stream—MediaStream.
We attach the stream to the video element and get the image. During peer-to-peer communication between two browsers, sometimes you will notice that the video is covered with squares or freezes. The reason is the loss of the packages caused by different problems:
To achieve stable video communication, we need to bypass package loss. Four main solutions help to implement it:
We render one RTT later. We may request the missing package. In the case of a massive loss, the frieze is shorter because there is more time to request a keyframe. The main minus of such an approach is the additional constant delay.
Bitrate = FPS * quality * resolution
We can manipulate bitrate by changing any of these parameters.
The codec duplicates some data. When the data is sent to the client, there are certain duplicates. These can exacerbate network congestion, but we have a higher chance of delivering content the first time.
The conditional disadvantage of WebRTC is the high price of its maintenance, which is connected to the need for powerful servers.
As was already mentioned in the article, the basis for Web Real-Time Communication is video chat. Services with audio and video calls, data sharing are the primary types of applications involving WebRTC technologies, the most famous examples being WhatsApp, Google Hangouts, and Facebook Messenger. But if we piece all business cases and examples of WebRTC together, we can find out that there are many areas of use.
The technology is highly demanded in telehealth, surveillance and remote monitoring, online education, Internet of Things, virtual reality gaming, streaming, online games with voice communications, betting, emergency response, etc.
MobiDev has repeatedly faced the need to apply WebRTC in different niches. One of the most notable use cases is remote assistance via shared AR and WebRTC. The two-way connection is organized here thanks to WebRTC. It is being used for peer-to-peer communication and helps to avoid server overload. The essence of the case itself boils down to the fact that two-way communication in real-time with AR helps to solve tasks with assistance in many areas.
The simplest example is the repair and maintenance of any equipment. In this case, WebRTC app development is combined with our experience working with Augmented Reality.
According to Market Study Report, the global WebRTC market’s size is predicted to reach $16,570.5 million in 2026. Let us recall that in 2016 the worldwide market value of products using WebRTC was $10.7 billion. The turning point for WebRTC came in 2017 when Microsoft Edge and iOS Safari 11 began supporting it.
In terms of global coverage, the WebRTC market spans North America, Europe, Asia, the Middle East, South America, and Africa. It is expected to remain the dominant region, owing to easy access to high-speed internet and the massive number of mobile device owners.
Nowadays, Google puts great efforts into the development of Web Real-Time Communication. Therefore, the future of WebRTC can be cloudless. It is easy to verify this by evaluating Google’s investments in the technology. All of them are directed to the code optimization and expansion or improvement of the feature set.
The future of WebRTC is associated with the emergence of technology in new markets. Furthermore, as long as WebRTC is a W3C standard, anybody can influence its development, which implies great prospects.
Источник: DZone Web Devwebrtc webrtc application development webrtc development webrtc mobile app development webrtc applications webrtc application development company webrtc software development webrtc software developers