As the pandemic is making the world more virtual, the popularity of WebRTC is increasing in a great speed. The usage of WebRTC has been increased by 100x in past one year, since March 2020. This is creating a huge demand for WebRTC developers but there are not many good developers as of today. Here the demand is outstripping supply by a good margin for last one year and the trend is going to continue as it is difficult to become a good WebRTC developer. Why? Because it is not very easy to grasp the totality of this technology and also developers fall in to the trap of common myths and loose interest in the mid way. Here we will try to describe the common myths and also burst them so that it will help aspiring developers come out of the trap.
Myth 1: WebRTC is p2p!
WebRTC is NOT only P2P, it is N2N, where N is any number of your choice!
Thinking WebRTC is p2p is like thinking only bicycles can be made using wheels!! We all know the reality. Wheels can be used starting from bicycles till airliners like AirBus A320 and all kind of transportation vehicles in between. The thing that one need to understand is the amount of complexity involved in developing a bicycle and a modern airliner are in two completely different levels. Almost all the times, aspiring developers get an example of how to build a bicycle aka a p2p WebRTC based video conferencing example and think that this is what they can make at best using wheels aka WebRTC. We don't think any body in their wildest dream can think of getting an step by step example on how to build an modern airliner like Airbus A320. It is the same with WebRTC as well ! Here also you can't expect to get a github repo which is google meet grade video conferencing application. It is simply not possible for anyone to put an effort to build things like Gmeet by investing millions of Dollars and the give it for free in github. What generous people can give is a bare bone heavy duty media server to build a video conferencing application on top it.
The task of building a production grade video conferencing app can primarily be divided in to 4 categories.
The frontend part where one will deal with the UX/UI along with audio/video streams, screen sharing, moderator settings etc
The backend part where one will deal with things like user authentication, real time connection management using some thing like websocket or a 3rd party service like pusher. this can be called as a combination of application + signalling server
The media server part where one handles the audio video streams and forwards them to other user based on the signalling server logic. The job of media server aka SFU is to forward the audio video streams to other users.
The devops part where one manages the application load based on the number of users join the room and the number of rooms getting created.
How to build a production grade video conferencing application is a learning in itself and there are no shortcuts available for the same without doing the hard work.
Myth 2: Free STUN server by Google is just enough!
People who have built their first p2p application by following a github repo or a youtube tutorial, most probably have used the free STUN server provided by google for learning purposes. They tend to use the same while building their commercial grade applications after a couple of months or years as well because they remember that it worked well when they built their first demo application. The free STUN server by google is like the first computer / laptop gifted by your parents while you were still a student. That was capable enough to run the all the programming languages you studied in your school or college. But that is not sufficient enough for you when you join your first job. There you get a new desktop / laptop which is suitable for a production grade working environment. Both the laptops / computer may run on similar kind of hardware or even software. So, what really changes is the percentage of dependability on the device you use for your work is more than the 1st device gifted by your parents. It is exactly same here. A production grade STUN aka TURN server is far more dependable than the free STUN server by google.
A STUN server is server which helps the peer connection in detecting the public IP address of any device which is needed for transporting the audio/video stream over the internet. A commercial STUN server( aka TURN server) is essential for a production grade application for minimising call drops. People interested in knowing the reason can drop me a mail at hello@centedge.io and we will be happy the reply back with the explanation on why it is needed.
Myth 3: TURN servers are really not needed, STUN is just enough!
Many time developers developing their 1st commercial grade video application complains about both parties not able to see each others video in certain random scenarios. They find it hard to find out why is it happening. Majority of the calls are just working fine but 10% (approx.) are not working fine! Majority of the times in such scenarios, the culprit is the network where both parties are simply not able connect directly through each others public IP address provided by the STUN server. This happens because a demon blocks the network while both of devices try to connect using each others public IP address. A DEMON ??!! Yes a DEMON and the name of the demon is Symmetric NAT. A symmetric NAT is a technique used by enterprise network admins to block all kind of inbound access to their internal devices in their LAN. When this happens the Public IP is not capable enough to connect to a device behind a Symmetric NAT. In this case, a TURN server comes to the rescue and becomes a broker between both the peers and relays the media from each other in a bi-directional manner.
According to statistics, out of 100 calls made using WebRTC, 10 -15% of the calls happen to relayed through a TURN server. Using a TURN server, one can decrease their call drop percentage. The other good news is that A STUN and TURN server come bundled as one package and one can deploy one server to serve both the purposes. COTURN is a open source STUN and TURN server which can be deployed at your own datacenter or on cloud.
Once it is deployed, one can check if the server is working as expected or not using this WEBRTC trickle ice test page. If one gets both the reflex and relay candidates in this page, then the server configuration will be considered to be proper.
These are 3 most common myths among aspiring WebRTC developers as experienced by us. There may be more to this list. We will try to modify this post by adding other popular myths as and when we encounter them.
If you aspire to become a full stack WebRTC developer with at least 2 years work experience in MERN stack, we would love if you join our developer network to stay updated with all the latest changes in WebRTC and related technologies as well as get WebRTC related consulting / job opportunities, if available. Here is the link to fill up the form to show your interest in joining our developer community. Once we get your request, we will get in touch with you for on-boarding you to our developer community.
If you have any queries related to your own WebRTC implementation, feel free to drop us a email at hello@centedge.io.
Happy to help.