Did you know that the first video call dates back to the 1960s by the well-known service provider of the USA, AT&T (earlier known as Bell)? What's more fascinating is that it was not an internet-based service!
But today, video calling is an important aspect as companies are adjusting their infrastructures in order to accommodate more and more remote work.
Some important statistics about video calls are:
• According to 87% of users, they prefer face-to-face meetings, where distance is an issue. (Lifesize)
• In the USA alone, business people make around 11 million video calls per day. (Highfive)
• An average video call lasts 31 minutes to 60 minutes. (Highfive)
• Businesses that have used video calls have increased their productivity to 94%. (Wainhouse Research)
• 87% of remote workers claim that they feel more connected to their teams and company because of the video calls. Also, they feel reliable and clean video is the reason behind their increased productivity.
• PGI claims that companies that use video calls for sales and customer support can save 30% from traveling.
So, you see video calls are becoming an important part of virtually everyone’s life. But do you know how you can implement video chat using WebRTC?
If your answer is no, you have come to the right place. In this article, you will get all the information like what WebRTC is and the steps to implement it.
Without any further adieu, let’s get started.
What is WebRTC?
First things first, WebRTC is an open-source framework that can be paired with Angular to build a simple video call app. In short, WebRTC allows the browser to send data like audio and video in real-time. In the meantime, it will use the system’s features like a webcam and microphone for audio/video streaming. And can even transmit that stream peer-to-peer, without having to download any external plugins or software.
Components of WebRTC
WebRTC is made up of mainly 3 components:
MediaStream
MediaStream is basically an API that gains access to webcams, mics, and screens. Moreover, it can even control where the stream is consumed and also allows control of the device that is producing the audio/video stream.
RTCPeerConnection
RTCPeerConnection can be said as the main component of WebRTC as it allows participants (peers) to connect directly without any intermediaries. Every participant (peer) transmits his stream, acquired through MediaStream API, creating an audio/video feed that other participants (peer) can subscribe to.
RTCPeerConnection is also an API and its main function is to handle audio/video codecs, NAT traversal, packet loss management, and more.
RTCDataChannel
Alike the below two, RTCDataChannel is also an API that is made to get bi-directional data transfer. RTCDataChannel might look similar to WebSocket as it is inspired by it, but it uses UDP instead of TCP in order to reduce congestion and overhead typical of TCP connections.
Here’s how WebRTC call is established
Part 1: SDP
Firstly, SDP (Session Description Protocol) is generated which contains information about the participant like what codecs they are able to understand, what kind of media they want to transmit, and stuff like that.
Also, the SDP offer generated should contain a list of IP addresses and ports the participants have prepared to receive the incoming data. But, how do participants generate the list of IP addresses from the participants? That’s where the ICE (Interactive Connectivity Establishment) comes in.
Part 2: ICE
If participants want to connect with each other, they will have to go through a process called ICE candidates gathering. ICE or Interactive Connectivity Establishment is a method of NAT traversal that deals with the process of connecting media through NATs by managing connectivity checks.
To collect candidates, ICE uses either a STUN or a TURN server. But what exactly are STUN and TURN:
STUN
STUN stands for Session Traversal Utilities for NAT which is a server that allows the participants to find out their public IP address along with the type of NAT that they are behind and the internet side port associated with the NAT device with a particular local port.
TURN
On the other hand, there’s a TURN server which stands for Traversal Using Relays around NAT. TURN is used when the participant’s server cannot establish a connection with the peer to act as a media relay.
Here the TURN server will provide its public IP address and port which then will forward the packets received to and from both peers. And after that, the relay address is added to the ICE candidate list. Although, when you use the TURN server, the call won’t be peer-to-peer as all the data exchanged between the participants goes through the TURN server.
Part 3: Signaling
Signaling takes place when the participants have gathered some audio/video files to send and create an offer to share with another peer. Signaling is basically the process of discovery and negotiation to establish the network session connection with other peers.
However, the best thing about WebRTC is that it doesn’t execute any particular signaling protocol. That means you can use anything like SIP or Web Sockets or XMPP or more. The main idea here is that each peer connects a signaling server which acts as an intermediary to interchange important information like:
Network data
Network data is something where peers are located on the internet so they can detect each other.
Session control information data
Session control information data control when and how to open, close, and modify the session.
Media data
Media data is the information of understanding of audio/video codecs that peers understand.
Implementing WebRTC with Angular
To get started, first, a project is created with AngularCLI and then the ngx-socket.io library is added to the dependencies to communicate via WebSockets with the server.
In the app.module.ts the SocketIo module is imported and passed through the server configuration.
npm install ngx-socket-io
Now the communication has been established with the WebSocket and it is ready to emit events from Angular or the events can be subscribed with the fromEvent method.
After that, a simple interface needs to be created that contains a video element and a button, which will be used to make the call.
The flow of the application will be like this:
- A call event is made by creating an offer and sending it to the user via the signaling service.
- Afterwards, when the receiver receives the offer, the answer is created and sent back to the sender.
- Lastly, the search for the icecandidates starts and they are shared, again, through WebSockets.
To apply this flow in the app.components.ts, you will need to subscribe to the WebSockets service and then check the type of message that arrives to perform the appropriate action.
Make a call
When the participants click on the call button, the service login starts:
1) Essentially an RTCPeerConnection is created by passing it through servers for configuration and then it will carry out the negotiation (STUN) and register connection events.
With this _registerConnectionListeners() method, all the events will be provided by the RTCPeerConnection. The most crucial in them, onicecandidates.
Through the signaling channel, a candidate is received by one end and sent back to the other end. The candidate is added to the connection when this event is received.
2) Capture audio or video streams to assign the video element
You can even access media like audio and video in WebRTC with Angular. And this is done using the MediaDevices interface that is provided by Javascript, through its getUserMedia method.
With the help of that, the device’s resources like a video camera and microphone can be accessed to create a stream that can be shared between two browsers.
3) The third step is to create an offer and add that to the connection by configuring the localDescription and then the offer is sent via the signaling service with the type ‘offer’.
Send the answer
After the offer is sent, the signaling service receives the event and processes the response with the help of the handleoffer method.
On the other hand, the receiver of the offer will follow a similar process to the sender:
a) Create a connection, capture the audio and video media, create a response, add it to the connection configuration as localDescription and at last, send it to the signaling service.
b) Furthermore, it also performs one more action, configuring the received offer as remoteDescription.
Receiving the answer
When it comes to the answering part, the sender who got the response from the recipient by receiving the event of type ‘answer’ and the handleAnswer is triggered.
After that, when the sender also configures the remote description with the received response, the audio/video data flow is configured at both ends.
And that’s how you can implement WebRTC video calls in Angular!
Top comments (0)