It’s a technology of Real-Time Communication (RTC), such as Real time chat ,voice call, etc. WebRTC is available now used on Google Chrome, Safari, Firefox and Opera, on Desktops, Mobiles and Native Mobiles (IOS - Android). It is used on different apps as well, like WhatsApp, Facebook Messenger, Appear.in and platforms such as TokBox.
This technology uses three APIs that are supported on mobile and desktop browsers;
The MediaStream API provides a way to access device cameras and microphones using JavaScript. It controls the location multimedia stream data is consumed, and provides some control over the devices that produce the media, but it also exposes information about devices that are able to capture and render media.
RTCPeerConnection
The Peer Connection is the core of the WebRTC standard. It provides a way for participants to create direct connections with their peers without the need for an intermediary server. Each participant takes the media acquired from the media stream API and plugs it into the peer connection to create an audio or video feed. The PeerConnection API has a lot going on behind the scenes. It handles SDP negotiation, codec implementations, NAT Traversal, packet loss, bandwidth management, and media transfer.
RTCDataChannel
The RTCDataChannel API was set up to allow bi-directional data transfer of any type of data - media or otherwise - directly between peers. It was designed to mimic the WebSocket API, but rather than relying on a TCP connection, data channels use UDP-based streams with the configurability of the Stream Control Transmission Protocol (SCTP) protocol. This design allows the best of both worlds: reliable delivery like in TCP but with reduced congestion on the network like in UDP.
Before a peer-to-peer video call can begin, a connection between the two clients needs to be established. This is accomplished through signaling.
Signaling allows two endpoints (senders, receivers, or both) to exchange metadata for communication coordination in order to set up a call. For example, before two endpoints can start a video call, one side has to call the other, and the called side has to respond. This call-and-response message flow (also known as offer-answer message flow) contains critical details about the streaming that takes place - the number and types of streams, how the media will be encoded, etc. - and is often formatted using the Session Description Protocol (SDP), a standard format used by many real-world systems, including VoIP and WebRTC.
The peer-to-peer (mesh) topology is the only connection type that is covered in the WebRTC specification. However, there are many use cases where a mesh topology is insufficient. Server based topologies can help address these drawbacks and are often used within the world of WebRTC for transferring media. The best topology for any given application depends largely on the expected use cases, as each one has its own unique set of benefits and drawbacks.
In a peer-to-peer or mesh topology, each participant in a session directly connects to all other participants without the use of a server. This type of connection is perfect for small video conferences as it is the lowest cost and easiest to set up. However, when conferences grow, maintaining direct connections between all participants becomes unsustainable as it can become too CPU intensive. Since the connections are direct between peers, a mesh topology doesn’t lend itself well to recording.
There are several ways a real-time communication application or plugin could cause a compromise of security. For example:
Unencrypted media or data might be intercepted en route between browsers, or between a browser and a server.
An application might record and distribute video or audio without the user knowing.
Malware or viruses might be installed alongside an apparently innocuous plugin or application.
WebRTC implementations use secure protocols such as DTLS and SRTP.
Encryption is mandatory for all WebRTC components, including signaling mechanisms.
WebRTC is not a plugin: its components run in the browser sandbox and not in a separate process, components do not require separate installation, and are updated whenever the browser is updated.
Camera and microphone access must be granted explicitly and, when the camera or microphone are running, this is clearly shown by the user interface.
A full discussion of security for streaming media is out of scope for this article. For more information, see the WebRTC Security Architecture proposed by the IETF.
From our point of view, WebRTC is the best and easiest way to make Real-Time App for mobile and browsers apps as it uses three main APIs ( MediaStream - RTCPeerConnection - RTCDataChannel ). MediaStream provides a way to access device cameras and microphones using JavaScript, RTCPeerConnection provides the peer connection, RTCDataChannel is responsible for bi-directional data transfer.
References
https://www.youtube.com/watch?v=p2HzZkd2A40&t=1324s
https://www.html5rocks.com/en/tutorials/webrtc/basics/