WebRTC Deep Dive: Core Concepts, Connection Flow, and a Simple Signaling Server

Introduction

Following the introductory article on WebRTC basics, this guide delves deeper into the core technologies that enable real‑time communication in browsers. It explains the essential concepts, APIs, and practical implementation steps required to build a functional WebRTC solution.

1.1 Core Concepts

Signaling : The pre‑connection exchange of control information, primarily the SDP (Session Description Protocol) messages.

SDP : A text‑based format that describes media capabilities, codecs, bandwidth, and other session parameters.

ICE : Interactive Connectivity Establishment, a protocol that gathers and tests network candidates to traverse NATs and firewalls.

Candidate : A possible network path (IP address, port, and transport) generated by each PeerConnection.

Offer and Answer : SDP messages where the caller creates an offer describing its media capabilities and the callee responds with an answer.

1.2 PeerConnection Core Methods and Events

Key Methods addIceCandidate(): Adds a remote ICE candidate during the connection establishment. addTrack(): Adds an audio or video track to the connection. createAnswer(): Generates an SDP answer in response to an offer. createDataChannel(): Creates a bidirectional data channel for arbitrary data transfer. createOffer(): Generates the initial SDP offer. setRemoteDescription(): Sets the remote SDP description. setLocalDescription(): Sets the local SDP description.

Key Events ondatachannel: Fires when a data channel is created or receives data. ontrack: Fires when a remote media track is added. onicecandidate: Fires each time a new ICE candidate is discovered.

1.3 Connection Strategies

1.3.1 Direct LAN Connection

When both peers are on the same local network, they can communicate directly without any intermediate server, leveraging low latency and high bandwidth.

1.3.2 Public‑IP Direct Connection (STUN)

Peers outside a LAN use their public IP addresses. Because devices often do not know their public IP, a STUN server is used to discover it and facilitate NAT traversal.

STUN purpose : Discover the public IP and assist in NAT traversal.

Even with STUN, connections may still be blocked by NAT or firewalls.

NAT : May modify the public IP, affecting stability.

Firewall : May block certain traffic types.

1.3.3 TURN Relay Connection

If direct P2P fails, a TURN server relays media streams, ensuring communication continuity at the cost of additional bandwidth.

Relay data : TURN receives and forwards media when a direct path is unavailable.

1.4 Collaboration of Signaling, STUN, and TURN

The signaling server exchanges SDP and ICE candidates, while STUN discovers public addresses and TURN provides a fallback relay. Understanding their interplay helps handle diverse network conditions and optimizes real‑time communication.

2. WebRTC P2P Session Flow

Connect to the signaling server – Both Peer A and Peer B establish a WebSocket (or similar) link to the signaling server.

Create RTCPeerConnection objects – Peer A creates its connection object.

Generate and send SDP Offer

Peer A calls createOffer(), then setLocalDescription().

The SDP offer is sent to Peer B via the signaling server.

Peer B processes the offer

Peer B sets the remote description with setRemoteDescription().

Peer B creates its own RTCPeerConnection, generates an SDP answer, and calls setLocalDescription().

The answer is sent back to Peer A.

Peer A processes the answer

Peer A sets the remote description with setRemoteDescription(), completing the SDP negotiation.

Exchange ICE candidates

Both peers gather ICE candidates and send them through the signaling server.

Each side adds received candidates via addIceCandidate().

Establish P2P connection

After candidate exchange, the peers attempt to form a direct connection.

If successful, a media‑carrying P2P channel is created.

The entire flow involves signaling exchange, SDP negotiation, ICE candidate collection, and finally the establishment of a secure P2P media stream.

3. Building a Simple Signaling Server

3.1 Server Design

The server’s responsibilities are:

User connection management : Track when clients connect or disconnect.

Message forwarding : Relay SDP offers/answers and ICE candidates between peers.

WebSocket is used for real‑time bidirectional communication.

3.2 Example Code (Node.js + WebSocket)

const express = require('express');
const http = require('http');
const socketIo = require('socket.io');

// Create Express app
const app = express();
const server = http.createServer(app);
const io = socketIo(server);

// Serve static files (e.g., HTML page)
app.use(express.static('public'));

app.get('/', (req, res) => {
  res.sendFile(__dirname + '/index.html');
});

// Handle WebSocket connections
io.on('connection', (socket) => {
  console.log('A user connected');

  // Forward SDP Offer
  socket.on('offer', (data) => {
    const { to, offer } = data;
    socket.to(to).emit('offer', { offer, from: socket.id });
  });

  // Forward SDP Answer
  socket.on('answer', (data) => {
    const { to, answer } = data;
    socket.to(to).emit('answer', { answer, from: socket.id });
  });

  // Forward ICE candidate
  socket.on('ice-candidate', (data) => {
    const { to, candidate } = data;
    socket.to(to).emit('ice-candidate', { candidate, from: socket.id });
  });

  // Handle disconnect
  socket.on('disconnect', () => {
    console.log('A user disconnected');
  });
});

// Start server on port 3000
server.listen(3000, () => {
  console.log('Server is running on port 3000');
});

3.3 Server Functionality Explained

User Management

Connection tracking logs each client’s status for monitoring.

Disconnection handling records lifecycle events.

Signaling Forwarding offer: Relays the initial SDP offer from the caller to the callee. answer: Relays the SDP answer back to the caller. ice-candidate: Exchanges ICE candidates to find the optimal network path.

This minimal server provides the essential backbone for WebRTC P2P communication and can be extended for more complex scenarios.

4. Conclusion

The article has taken you through WebRTC’s core principles, the complete P2P session establishment process, and the practical steps to build a lightweight signaling server. Armed with this knowledge, you can now create real‑time audio/video applications and further explore advanced features in future tutorials.