Room-based WebRTC peer-to-peer communication with pluggable signaling drivers.
The Room class manages peer connections, media streams, and data channels,
coordinating signaling through a driver backend (NATS, MQTT, SSE, etc.) and
supporting extendable add-ons for additional capabilities.
The following diagram provides a high-level overview of the Peerix
architecture and its components:
Signaling drivers extend Driver to bridge Peerix with a messaging
backend (MQTT, NATS, SSE, SocketIo, Centrifuge, Supabase, BroadcastChannel,
or in-memory). Drivers receive a pre-configured client via the constructor and
never import external libraries. Signaling messages are protobuf-encoded with
optional compression and AES-GCM encryption, exchanged over two namespaces —
one for broadcast peer discovery and one scoped to each peer ID.
Peer connections are represented by Peer instances that wrap
RTCPeerConnection. The Room creates them automatically on peer discovery,
handling SDP negotiation, ICE candidate exchange with configurable debouncing,
and offer-collision resolution using polite semantics. Connections transition
through states — new, connecting, connected, disconnected,
failed, closed — with an optional timeout for failure recovery.
Data channels provide reliable, ordered messaging over RTCDataChannel.
Large payloads are chunked (~16 KB MTU) and reassembled transparently. Four
payload types are supported — text, JSON, Blob/File, and raw bytes — with
back-pressure management, transfer progress tracking, and abort support via
AbortSignal. Channels are opened via Room.open and use string
labels for identification.
Media streams are published by label using Room.share. You can
configure encoding parameters (bitrate, framerate, scale factor, priority) and
control track lifecycle with the managed flag. Stream replacements trigger
re-negotiation so remote peers receive updated media seamlessly.
ICE servers (STUN/TURN) are used for NAT traversal and peer discovery.
STUN servers help peers discover their public address, while TURN servers
relay media when direct connections fail. Pass an array of server configs
via the iceServers option — without them, only local network connections
are possible. Use iceTransportPolicy: "relay" to force TURN usage.
Room-based WebRTC peer-to-peer communication with pluggable signaling drivers.
The Room class manages peer connections, media streams, and data channels, coordinating signaling through a driver backend (NATS, MQTT, SSE, etc.) and supporting extendable add-ons for additional capabilities.
The following diagram provides a high-level overview of the Peerix architecture and its components:
Signaling drivers extend Driver to bridge Peerix with a messaging backend (MQTT, NATS, SSE, SocketIo, Centrifuge, Supabase, BroadcastChannel, or in-memory). Drivers receive a pre-configured client via the constructor and never import external libraries. Signaling messages are protobuf-encoded with optional compression and AES-GCM encryption, exchanged over two namespaces — one for broadcast peer discovery and one scoped to each peer ID.
Peer connections are represented by Peer instances that wrap
RTCPeerConnection. The Room creates them automatically on peer discovery, handling SDP negotiation, ICE candidate exchange with configurable debouncing, and offer-collision resolution using polite semantics. Connections transition through states —new,connecting,connected,disconnected,failed,closed— with an optional timeout for failure recovery.Data channels provide reliable, ordered messaging over
RTCDataChannel. Large payloads are chunked (~16 KB MTU) and reassembled transparently. Four payload types are supported — text, JSON, Blob/File, and raw bytes — with back-pressure management, transfer progress tracking, and abort support viaAbortSignal. Channels are opened via Room.open and use string labels for identification.Media streams are published by label using Room.share. You can configure encoding parameters (bitrate, framerate, scale factor, priority) and control track lifecycle with the
managedflag. Stream replacements trigger re-negotiation so remote peers receive updated media seamlessly.Lifecycle events cover connection state changes (
connection:connected,connection:closed, etc.), data channel activity (channel:open,channel:message, etc.), stream modifications (stream:add,stream:remove), track changes (track:add,track:remove), and errors. Each event carries a Peer reference for easy correlation.ICE servers (STUN/TURN) are used for NAT traversal and peer discovery. STUN servers help peers discover their public address, while TURN servers relay media when direct connections fail. Pass an array of server configs via the
iceServersoption — without them, only local network connections are possible. UseiceTransportPolicy: "relay"to force TURN usage.