Mastering WebRTC: Media Streams, Peer Connections, and Data Channels Explained

Introduction

Google's WebRTC enables fast real‑time communication directly between browsers without intermediate servers, allowing peer‑to‑peer (P2P) connections for video, audio, and arbitrary data streams without installing plugins.

It relies on three main data structures:

MediaStream: acquisition of audio/video streams.

RTCPeerConnection: transmission of audio/video data.

RTCDataChannel: transmission of non‑media data.

MediaStream

MediaStream is obtained via

navigator.mediaDevices.getUserMedia

and represents media data streams.

<code>navigator.mediaDevices.getUserMedia({
  audio: true,
  video: {
    width: {min: 1024, ideal: 1280, max: 1920},
    height: {min: 576, ideal: 720, max: 1080},
    frameRate: {max: 30}
  }
}).then(stream => {
  let video = document.createElement('video');
  document.body.append(video);
  video.srcObject = stream;
  video.onloadedmetadata = function() { video.play(); };
});
</code>

RTCPeerConnection

RTCPeerConnection acts like a powerful socket, with at least one instance on each call endpoint, handling connection establishment, media transmission, and quality assurance.

To ensure cross‑browser compatibility, an

adapter.js

script is often added:

<code>&lt;script src="https://WebRTC.github.io/adapter/adapter-latest.js"&gt;&lt;/script&gt;</code>

How RTCPeerConnection works:

Create an RTCPeerConnection object for each endpoint and add a local stream obtained from

getUserMedia

.

Obtain the local SDP (Session Description Protocol) and exchange it with the remote peer.

Gather ICE candidates (IP addresses and ports) and exchange them with the remote peer.

RTCDataChannel

RTCDataChannel transmits non‑media data such as strings, Blob, ArrayBuffer, and ArrayBufferView, supporting reliable or unreliable delivery.

Creation example:

<code>var pc = new RTCPeerConnection(); // create RTCPeerConnection
var dc = pc.createDataChannel("dc", options); // create RTCDataChannel
</code>

Options include:

ordered: whether messages are delivered in order.

maxPacketLifeTime: maximum time to retransmit a failed message.

maxRetransmits: maximum number of retransmission attempts.

protocol: custom sub‑protocol.

negotiated: if true, disables automatic negotiation.

id: custom ID when negotiated is true.

Media Negotiation

Media negotiation determines which codecs and media capabilities both peers support.

SDP

SDP (Session Description Protocol) describes multimedia sessions and is exchanged via signaling to convey media capabilities.

<code>v=0 // SDP version
o=- 3409821183230872764 2 IN IP4 127.0.0.1 // origin
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 // audio stream info
</code>

How SDP is exchanged

Each side gathers its media information (codecs, SSRC, transport protocol, IP, ports) in SDP format.

They exchange SDP via a signaling server.

After finding common capabilities, communication begins.

Network Negotiation

After media capabilities are known, peers must determine network connectivity using ICE candidates.

Connection scenarios:

P2P direct connection (A↔B).

Relay via TURN server (A↔C↔B) if direct fails.

ICE candidates are of three types:

host: local LAN IP and port.

srflx: NAT‑mapped public IP and port.

relay: TURN server IP and port.

ICE gathers candidates using STUN and TURN protocols:

STUN

discovers public IP/port;

TURN

relays traffic when NAT traversal fails.

NAT (Network Address Translation)

NAT translates internal addresses to external ones, enabling multiple hosts to share a public IP and providing a layer of security.

Types include full‑cone, restricted‑cone, port‑restricted, and symmetric NAT. Full‑cone NAT allows any external host that knows the mapping to communicate back.

STUN

STUN obtains the public IP and port of a host behind NAT.

TURN

TURN extends STUN (RFC5389) to relay traffic, allowing traversal of symmetric NATs.

Signaling

Signaling exchanges control information (SDP and ICE candidates) between peers, often via a signaling server that also handles room management.

WebRTC Practical Implementation

Flow Diagram

<code>// Create PeerConnection
let peer = new PeerConnection(iceServer);
peer.addStream(this.localStream);

// Create offer
peer.createOffer({offerToRecieveAudio:1, offerToReceiveVideo:1}).then(desc => {
  peer.setLocalDescription(desc, () => {
    socket.emit('offer', {sdp: peer.localDescription, roomid: this.$route.params.roomid, account});
  });
});

socket.on('offer', v => {
  this.peerList[v.account] && this.peerList[v.account].setRemoteDescription(v.sdp, () => {
    this.peerList[v.account].createAnswer().then(desc => {
      this.peerList[v.account].setLocalDescription(desc, () => {
        socket.emit('answer', {sdp: this.peerList[v.account].localDescription, roomid: this.$route.params.roomid, account: v.account});
      });
    });
  }, err => console.log(err));
});

socket.on('__ice_candidate', v => {
  if (v.candidate) {
    this.peerList[v.account] && this.peerList[v.account].addIceCandidate(v.candidate).catch(() => {});
  }
});

peer.onaddstream = function(event) {
  console.log(event.stream);
};

peer.onicecandidate = event => {
  if (event.candidate) {
    socket.emit('__ice_candidate', {candidate: event.candidate, roomid: this.$route.params.roomid, account: v.account});
  }
};
</code>

WebRTC Statistics

In Chrome, navigate to

chrome://WebRTC-internals

to view detailed statistics.

Notes

Local LAN testing does not require STUN/TURN servers, but external access needs a cloud host with HTTPS support.

Code Samples

Repository: https://github.com/xieyanxieyan/WebRTC-demo/tree/master

References

STUN/TURN setup: https://juejin.cn/post/6844903844904697864

WebRTC overview: https://hpbn.co/webrtc/

WebRTC API docs: https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API

Audio‑video system from 0 to 1: https://time.geekbang.org/column/article/107948