WebRTC
This section covers the core components that enable WebRTC (Web Real-Time Communication) to establish peer-to-peer connectivity, particularly across NAT/firewall environments.
Component |
Description |
Use Case |
|---|---|---|
ICE (Interactive Connectivity Establishment) |
Framework that tries multiple methods to connect peers. Combines STUN and TURN for NAT traversal. |
Establishing peer-to-peer connections. |
STUN (Session Traversal Utilities for NAT) |
Helps clients discover their public IP and NAT type. Enables direct peer-to-peer communication. |
Enables connections behind NAT/firewalls. |
TURN (Traversal Using Relays around NAT) |
Relays media when direct connection fails. Acts as a media proxy server. |
Ensures reliable communication fallback. |
RFC: RFC 8445
Main Features:
Connectivity framework for NAT/firewall traversal
Uses STUN and TURN as fallback mechanisms
Collects multiple candidates (IP addresses and ports)
Use Cases:
Peer-to-peer connection setup in WebRTC
Negotiating the best path between peers
Alternative Protocols:
None – ICE is the standard coordination mechanism for WebRTC
Let us learn more about ICE:
RFC: RFC 5389
Main Features:
Discovers public IP addresses of clients
Identifies NAT type and firewall behavior
Lightweight UDP-based protocol
Use Cases:
Peer discovery in WebRTC
Assisting direct P2P media path setup
Alternative Protocols:
TURN – Used when STUN fails
Let us learn more about STUN:
RFC: RFC 8656
Main Features:
Relays media through an intermediate server
Used when direct peer connection is not possible
Supports TCP and UDP relaying
Use Cases:
WebRTC calls behind symmetric NAT or strict firewalls
Reliable fallback for P2P media delivery
Alternative Protocols:
STUN – Preferred when NAT allows direct access
Let us learn more about TURN: