The data plane: streams, RPC & state sync

In this chapter, you will learn how LiveKit moves far beyond audio and video. You will understand text streams, byte streams, RPC, participant attributes, and room metadata — five data primitives that all travel through the same WebRTC connection your media already uses. By the end, you will see LiveKit not as a media platform with some data features bolted on, but as a full realtime data platform that happens to be exceptional at media.

Beyond audio and video

In chapters 1 through 4, every example centered on media: microphone tracks, camera tracks, audio flowing between participants and agents. But real applications need more than media. A voice AI agent needs to send transcriptions as text. A collaborative app needs shared state. A file-sharing tool needs binary data transfer. A control interface needs request/response messaging.

Traditionally, developers bolt on a separate WebSocket connection, a REST API, or a third-party service to handle these needs. That means a second connection to manage, a second authentication flow, a second set of failure modes. LiveKit takes a different approach: it puts all of these data capabilities inside the same WebRTC connection that already carries your media.

Text streams

Text streams provide ordered, reliable delivery of text data between participants. Think of them as named channels for UTF-8 text that flow alongside your audio and video tracks.

Each text stream has a topic — a string identifier that lets you multiplex many independent text flows over a single connection. A participant can have multiple concurrent streams on different topics, and receivers can subscribe to exactly the topics they care about.

Use case	Topic example	Why text streams fit
Chat messages	chat	Ordered delivery ensures messages appear in sequence
LLM streaming output	agent.transcription	Token-by-token delivery as the model generates
Live transcription	transcription	Real-time speech-to-text results pushed to all participants
Status updates	agent.status	Lightweight signals like "thinking..." or "processing..."

Text streams are the backbone of how AI agents communicate non-audio information. When a voice agent transcribes what the user said, that transcription arrives as a text stream. When the agent streams its LLM-generated response before converting it to speech, that response arrives as a text stream. The agent does not need a separate API to push this data — it flows through the same room connection.

Byte streams

Byte streams handle binary data delivery. Where text streams carry UTF-8 strings, byte streams carry raw bytes — images, files, audio clips, serialized data structures, anything that is not plain text.

Byte streams are chunked for efficient transport. Large files are broken into manageable pieces and reassembled on the receiving end. This chunking also enables progress tracking: the receiver knows how many bytes have arrived versus how many are expected, making it straightforward to display upload or download progress.

Use case	Why byte streams fit
File transfer between participants	Chunked delivery with progress, no separate upload service needed
Image sharing	Send screenshots, photos, or generated images directly through the room
Audio clip delivery	Share pre-recorded audio without publishing it as a live track
Serialized data	Protocol buffers, MessagePack, or any binary format

RPC: Remote Procedure Calls

RPC lets one participant call a method on another participant and receive a response. This is a request/response pattern — fundamentally different from the one-way push of streams.

When participant A calls an RPC method on participant B, participant B's registered handler executes and returns a result. Participant A awaits that result. It is conceptually identical to calling a function on a remote machine, except the "remote machine" is another participant in the same LiveKit room.

Use case	What the RPC call does
Trigger an action	"Agent, start recording this conversation"
Query state	"Agent, what tools do you have available?"
Control flow	"Agent, switch to Spanish"
Confirmation	"Agent, did you successfully book that appointment?"

Participant attributes

Every participant in a LiveKit room carries a set of key-value attributes — string pairs that describe that participant. These attributes are visible to all other participants in the room and can be updated at any time. When an attribute changes, every participant receives a notification.

Participant attributes are ideal for state that is owned by one participant but observed by many:

• User profile information: display name, avatar URL, role
• Agent conversation state: current intent, language, session phase
• Preferences: volume level, subtitle language, UI mode
• Status indicators: muted, away, hand raised

Room metadata

While participant attributes belong to individual participants, room metadata is shared state that belongs to the room itself. It is a single key-value store visible to everyone in the room, and any participant with the appropriate permissions can update it.

Room metadata is the right choice for state that is not owned by any single participant:

• Room configuration: recording enabled, max participants, current mode
• Shared settings: language, topic, agenda
• Application state: current slide number, game state, workflow phase

The distinction between participant attributes and room metadata mirrors a common pattern in distributed systems: per-entity state versus shared global state. Both are necessary, and LiveKit provides both through the same connection.

One connection to rule them all

Here is the architectural insight that ties everything together:

Capability	Traditional approach	LiveKit approach
Audio/video	WebRTC connection	WebRTC connection
Chat messages	Separate WebSocket	Text stream (same connection)
File transfer	Separate upload API	Byte stream (same connection)
Remote actions	REST API calls	RPC (same connection)
User state	Database + polling	Participant attributes (same connection)
Shared state	Database + WebSocket	Room metadata (same connection)

LiveKit is a realtime data platform

By now, the framing of "LiveKit is a video conferencing tool" should feel inadequate. LiveKit provides six distinct communication primitives — audio tracks, video tracks, text streams, byte streams, RPC, and state synchronization — all unified under one connection, one authentication model, and one set of SDKs.

This is what makes it a realtime data platform. The room abstraction is not just a container for media — it is a container for any kind of realtime interaction between connected participants, whether those participants are humans, AI agents, phone callers, or IoT devices.