Inside WebRTC RTCPeerConnection Signaling
This article is meant to serve as a quick look-up guide about signaling components of the RTCPeerConnection.
RTCPeerConnection facilitates the connection between parties who want to communicate with each other. This facilitation is done by handling the signaling, media transfer, and media performance management. All of these functions are crucial to successfully transfer media from one party to another and are encompassed in an easy-to-use API.
Signaling Basics
Signaling is the process of two devices discovering each other and negotiating how they will communicate with one another.
Imagine you are sending a package by mail to to your friend Mukund Iyengar. To do that, you need several things before you approach the post-office. You need to know Mukund’s address and details about the package such as weight, the box’s dimensions, if the contents are fragile, etc.,
This is just like the signaling for WebRTC. The two devices need to know information about what data is going to be sent. Just like how the Post Office needs to know information about what package you are sending. This includes items like the media format/codec being transported, method of transporting the data, channels, communication protocols, etc. In addition, just like how you can choose different Post Carriers to deliver your package, WebRTC does not have a fixed signaling process.
Signaling for WebRTC revolves around a few key steps. The first is that each peer creates an RTCPeerConnection. This is what each peer uses to represent their session. After an RTCPeerConnection is created the session initiator (caller) sends an offer to the receiver (callee). The callee then responds to the caller by sending an answer. Both the offer and the answer contain key codec information that needs to be exchanged between users, typically in SDP format. There is still another step though which is necessary though before the signaling process can be completed which is both peers establishing how they want to transmit media data to each other. This is done through Interactive Connectivity Establishment (ICE).
Each peer has ICE candidates, which are essentially different ways for other peers to connect with it. The peers then negotiate and eventually agree on a specific candidate which allows them to connect with each other. Once the peers mutually agree upon a candidate they then use the SDP from that candidate to initiate the transfer of data.
It is important to note, however, that just because the peers agreed upon an ICE candidate and started transferring data does not mean that the exchange is over. Each peer continues to send candidates until it has run out of ideas and if during this process a candidate is found to be more optimal than the existing candidate the data transfer format may change.
NATs and NAT Traversal
We have officially run out of IP addresses: more devices connect to the Internet today than the number of addresses available! NATs are used to manage this problem.
Network Address Translation, more commonly referred to as NAT, is the process of a network’s router/firewall assigning a single public IP address to a group of devices, typically in a home/office setting. This poses a unique problem for WebRTC because it needs to be able to locate and establish a session with the callee device hidden behind the NAT.
In order to counteract this problem, WebRTC has three tools in its toolbox: STUN, TURN, and ICE.
STUN
Session Traversal Utilities for NAT, more commonly called STUN, is a method for clients to find out more about themselves so that a direct peer-to-peer connection can be established.
TURN
Traversal Using Relays around NAT, more commonly referred to as TURN, not only helps WebRTC clients find each other but actually acts as a server in the middle relaying all media to and from each client. This is used as an option when a direct connection between the caller and callee is not possible.
ICE
Interactive Connectivity Establishment, more commonly called ICE, is the tool that wraps STUN & TURN together and helps the RTCPeerConnection establish sessions with a device behind a NAT. Just like how we discussed in the Signaling Basics section, ICE’s job is to find the most efficient method for peers to send data to each other and it repeatedly searches for that best method. ICE will try using STUN and TURN to establish sessions with a device behind a NAT and will eventually select which method is the best one for the specific session at hand.
Concluding Thoughts
The RTCPeerConnection is one of the three core APS that WebRTC has and signaling is a key component of the RTCPeerConnection. If you are interested in learning more about the RTCPeerConnection and WebRTC Signaling the open source book WebRTC for the Curious has a great chapter on it here: https://webrtcforthecurious.com/docs/02-signaling/
About SecureMeeting
SecureMeeting is a 501(c)(3) non-profit whose mission is to advance human rights and freedom of speech. We do this by designing, developing and deploying planetary-scale, privacy-preserving communications architectures for all of mankind.
