WebRTC Deep Dive: How Front‑End Developers Build Real‑Time Communication

Introduction

Following the previous overview of basic WebRTC concepts, this article dives into the core technologies that enable real‑time communication from a front‑end perspective, covering connection mechanisms, APIs, and a practical signaling server implementation.

Core Concepts

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

SDP : describes media parameters exchanged between peers.

ICE : Interactive Connectivity Establishment, used to gather and test network candidates for NAT traversal.

Candidate : a possible network path (IP address, port, etc.) generated by each RTCPeerConnection.

Offer / Answer : SDP messages created by the initiating and responding peers to negotiate media capabilities.

PeerConnection Methods and Events

addIceCandidate()

: add ICE candidate information during connection setup. addTrack(): add audio or video tracks. createAnswer(): generate an SDP answer. createDataChannel(): create a data channel for P2P text messages. createOffer(): generate an SDP offer. setRemoteDescription(): set the remote SDP. setLocalDescription(): set the local SDP.

Key events include ondatachannel, ontrack, and onicecandidate, which notify the application of data‑channel creation, remote media tracks, and ICE candidate generation respectively.

Connection Types

WebRTC can establish connections in three ways:

1. Direct LAN connection

When both devices are on the same local network, they communicate directly without intermediate servers, leveraging low latency.

2. Public‑IP direct connection via STUN

Devices outside a LAN use a STUN server to discover their public IP address, enabling direct P2P connections.

STUN helps discover the public IP and assists NAT traversal.

However, NAT and firewalls can still restrict connectivity.

NAT may modify the public IP, affecting stability.

Firewall may block certain traffic.

3. Relay via TURN

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

Relay data : TURN forwards media when P2P is unavailable.

Signaling Server and STUN/TURN Collaboration

The signaling server exchanges SDP and ICE candidates, while STUN discovers public IPs and TURN provides a fallback relay path, together handling various network conditions.

WebRTC P2P Call Flow

Both peers connect to the signaling server.

Peer A creates an RTCPeerConnection object.

Peer A calls createOffer, sets the local description, and sends the SDP offer via the signaling server.

Peer B receives the offer, sets it as the remote description, creates its own RTCPeerConnection, generates an SDP answer, sets the local description, and sends the answer back.

Peer A receives the answer and sets it as the remote description, completing the session setup.

Both peers gather ICE candidates, exchange them through the signaling server, and add them via addIceCandidate.

After ICE exchange, the peers attempt to establish a direct P2P connection; on success, media streams flow directly.

This flow involves signaling exchange, SDP negotiation, ICE candidate collection, and finally a secure P2P media channel.

Simple Signaling Server Implementation

The server uses Node.js and WebSocket to forward SDP and ICE messages between peers.

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)
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 candidates
  socket.on('ice-candidate', (data) => {
    const { to, candidate } = data;
    socket.to(to).emit('ice-candidate', { candidate, from: socket.id });
  });

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

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

Signaling Server Functions

User management : tracks client connections and disconnections.

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

The implementation provides a basic yet extensible foundation for real‑time WebRTC communication.

Conclusion

The article walked through WebRTC core concepts, the full P2P call workflow, and built a minimal signaling server, giving front‑end developers both theoretical understanding and practical code to create real‑time communication services.