WebRTC is an open source project currently under development to provide real-time, peer-to-peer communication between web applications.
To establish a WebRTC connection, we must perform the following two steps:
- Locate a peer.
- Inform a spouse to establish a WebRTC connection.
Step 1: Find a mate
Think of it as making a phone call, when you need to talk to someone on the phone, you dial the other person's phone number and contact that person. The same thing happens when someone wants to call you. In the case of mobile communication, we use mobile phone /phone numbers as a user's ID. This definition is also used by telecommunication systems to locate a user.
However, web apps can't 'search and search' each other. There is no unique ID (such as a phone number) assigned to each of the millions of browsers around the world. However, the system where these applications are located is assigned a unique IP address that can be used to locate a peer.
But this process is not as easy as it seems. Because most of these systems are Network Address Translation (NAT) device sits behind . Nat devices are required for security and IPv4 limitations on the public IP addresses available. A NAT device assigns private IP addresses to systems within a local network. These private IP addresses are valid and visible only within the local network, and cannot be used to accept communication from the outside world because systems outside the network are not aware of the public IP of devices within the network.
Because of the involvement of NAT devices, a peer does not know their public IP address because it is masked by a private IP address assigned by NAT. And therefore, it cannot share the public IP address with another peer to accept connections. More clearly, if you want someone to phone you, you need to give your phone number to the other person. However, in the presence of NAT, calls to the hotel are handled at reception and also directed to your room upon request, such as staying in a hotel where your room's phone number is hidden from the outside world. This type of indirect connection format is not intended in end-to-end connectivity technology.
To get over it Interactive Connectivity (ICE) we use a protocol called . ICE's job is to find the best possible way to connect the two peers. ICE can make a direct connection, that is, in the absence of NAT, as well as indirect connections, that is, in the presence of a NAT. The ICE framework provides us with 'ICE candidates'. 'ICE candidates' are nothing more than objects that contain our own public IP address, port number, and other information about the connection.
In the absence of NAT, ICE is quite simple, as the public IP address of the spouse is ready. However, in the presence of NAT, ICE Session Migration Utilities (STUN) for and / or Using Relays around NAT (TURN) transition based on so-called entities.
An STUN server basically allows a peer to find their public IP address. Peers who need to know their public IP address send a request to the STUN server. The STUN server responds with that peer's public IP address. This public address can now be shared with other colleagues so they can find you. However, if the peer is behind a complex NAT and/or firewall, even STUN cannot find the requesting peer and provide the IP address. In such cases, ICE relies on TURN to establish the connection. TURN, as its name suggests, is a transfer server and acts as an intermediary for data, audio, video transfer when a direct connection between two peers is not possible.
The STUN server is only involved in the global IP discovery process. After the WebRTC connection is established, all other communication occurs through WebRTC. However, in the case of TURN, it is required throughout the TURN server even after the WebRTC connection is established.
A TURN server is something that is not intended, but due to STUN limitations we have to trust it. An STUN server succeeds only about 86% of the time.
"ICE is complicated because we live in a complicated world."
Step 2: Inform a spouse to establish a WebRTC connection
Now that we have ice candidates, the next step is to send them to a peer we want to connect with. Session Descriptions such as session information, time description, media description are sent with candidates. ICE candidates and session description are collected in an object and Session Disclosure Protocol (SDP) transmitted using . In some cases, ICE candidates are not collected in the same object as the Session Description and sent separately, which is called Trickle ICE (this is a completely new concept, let's not go in depth for now!).
I wrote that we should 'send' the information to the other peer. However, how to transfer candidates and session description only when we know the IP address of the sender and do not know the IP address of the receiving spouse? Since the WebRTC connection has not yet been established, through which medium is this information transmitted?
The answer to all these questions is, Signal Mechanism lies in a concept called . Before a WebRTC connection is established, we need an environment to transfer the above information between peers and to let them know how to find and connect to each other for a WebRTC connection. That's where the signaling mechanism kicks in. As the name suggests, a signaling mechanism allows connection signals (ICE candidates, Session description, etc.) between two peers aiming to connect. Changes.
WebRTC does not define any standards for the implementation of such a signaling mechanism and leaves it to the developer to create a mechanism according to its preference. To exchange information, the signaling mechanism can be used either by copying and pasting information to the relevant peers, or by using WebSockets, Socket.io, Server Side Events, and so on. It can be performed using a communication channel such as. In short, a signaling mechanism it's just a mode. the exchange of information about the connection between peers occurs so that the peers can identify each other and start communicating more using WebRTC.