Web Real-Time Communication (WebRTC) is a set of technologies that facilitates direct communication between web browsers, allowing features like video, audio, and metadata right inside your browser without needing to download additional software. In Elements, WebRTC is used to establish connections between the browser and the media server residing on the gateway and the recorder:

Concept: Enables real-time video streaming directly within web browsers, eliminating the need for additional software.
Connection: Relies on a peer-to-peer (P2P) connection whenever possible, offering lower latency and potentially better quality.
Signaling Server: Uses a separate server to facilitate communication between browsers, exchanging information to set up the connection.
ICE Candidates: Deals with firewalls and Network Address Translation (NATs) using ICE candidates. These are like connection proposals containing addresses that browsers exchange to find the most suitable path.
Benefits:
- Convenience: No downloads or plugins needed.
- Lower Latency: Direct P2P connection can provide faster response times.
- Security: WebRTC uses encryption to secure the communication channel.
Limitations:
- NAT Traversal: Firewalls and NATs can sometimes hinder P2P connections, requiring relay servers (TURN servers) which can add latency.
- Browser Support: While widely supported, some older browsers may not have full WebRTC functionality.

How Does WebRTC work

We want to establish a peer-to-peer connection between two hosts: the Elements client and the gateway or recorder. Both are behind NAT. They should know each other's public IP address and the type of media that is going to be sent.

Signaling: WebRTC itself cannot directly connect peers. It relies on a separate signaling server (like a matchmaker) to exchange information between browsers. This can be a simple server you set up or a service provided by a cloud platform.
Offers and Answers: The connection starts with an "offer" from one browser (Peer A) to another (Peer B). This offer describes how Peer A wants to connect, including media types ( for example, audio, video). Peer B responds with an "answer" stating their capabilities.
ICE Candidates: Firewalls and NAT (Network Address Translation) can complicate direct connections. WebRTC uses ICE (Interactive Connectivity Establishment) to overcome this. Each browser gathers potential connection paths (candidates) and sends them to the other through the signaling server.
Connection: Both browsers use ICE candidates to attempt connections. Once a compatible path is found, a direct peer-to-peer connection is established for real-time data exchange (audio, video, etc.).

This is a simplified explanation, but it captures the key steps of WebRTC connection establishment.

ICE Candidates

In WebRTC, ICE candidates are like connection proposals exchanged between browsers to find the most suitable way to establish a peer-to-peer connection. They act like addresses containing information needed to reach a device, but with the added complexity of dealing with firewalls and NATs.

Here's a deeper dive into ICE candidates:

Content: Each candidate includes details like:
- IP Addresses: Can be public or private depending on the network configuration.
- Port Numbers: Specific ports used for sending and receiving data.
- Transport Protocol: Typically UDP (User Datagram Protocol) for real-time communication.
- Candidate Type: Describes how the candidate was obtained (host, server-reflexive, relay).
Gathering: During the offer/answer exchange, browsers gather ICE candidates. This involves:
- Host Candidates: Using locally assigned IP addresses and ports of the device.
- Server Reflexive Candidates: Sending requests to STUN (Session Traversal Utilities for NAT) servers to discover the public IP and port behind a NAT.
- Relay Candidates: Involving a TURN (Traversal Using Relays around NAT) server to relay data if a direct connection fails.
Exchange: Each browser sends their list of candidates to the other through the signaling server.
Selection: Both browsers try connecting using the listed candidates. The first compatible pair establishes the connection. Preference is usually given to:
- Host Candidates: Most efficient as they avoid additional servers.
- Server Reflexive Candidates: Can establish peer-to-peer connections if not blocked by firewalls.
- Relay Candidates: Used as a last resort if a direct path is unavailable.

By exchanging and trying these ICE candidates, WebRTC can navigate firewalls and NATs to find the best possible connection path for your WebRTC session.