Unity WebRTC is Unity's official package that wraps the native libwebrtc library so Unity developers can send and receive real-time audio, video, and data over peer-to-peer connections. It exposes WebRTC concepts like RTCPeerConnection, MediaStreamTrack, and DataChannel through a C# API. For teams that want managed infrastructure instead of raw peer connections, VideoSDK offers a Unity SDK with rooms, tokens, and adaptive streaming built in.
Real-time video and audio are no longer optional in modern games and interactive applications. Players expect in-game voice chat, coaches expect live video in fitness apps, and AR collaboration tools need to stream camera feeds between devices with sub-second latency. Building all of that from scratch on top of raw sockets is a losing battle, which is why Unity shipped an official WebRTC package.
Unity WebRTC gives you a native-grade WebRTC stack inside the Unity editor and runtime. This guide walks through what it is, how its architecture fits together, how to install and use it, and where the sharp edges are. By the end, you'll know whether the raw package or a managed solution like VideoSDK's Unity SDK is the right fit for your project.
What Is Unity WebRTC?
Unity WebRTC is defined as an official Unity package that provides C# bindings to the native WebRTC library (libwebrtc), enabling real-time peer-to-peer audio, video, and data exchange inside Unity applications. It works by wrapping the native library in a plugin layer and exposing its functionality through Unity-friendly classes, so you can create peer connections, negotiate media, and stream textures without leaving C#.
The package powers several Unity ecosystem projects, most notably Unity Render Streaming, which streams rendered camera output from a Unity application to a browser over WebRTC. Beyond rendering, developers use it for in-game voice chat, video call features, and low-latency data exchange between players.
It's worth separating two layers clearly. The Unity WebRTC package is the low-level binding: you manage signaling, peer connections, and media tracks yourself. Higher-level services, like VideoSDK's Unity SDK, sit on top of a similar transport but add rooms, token-based authentication, recording, and network-adaptive streaming so you spend your time on gameplay rather than ICE negotiation. Both approaches share the same underlying WebRTC foundation, so the concepts in this guide apply to either path.
Unity WebRTC Architecture Overview
Unity WebRTC's architecture is a three-layer stack: your Unity application, the C# wrapper, and the native libwebrtc plugin that does the heavy lifting. Understanding this layering matters because it explains most of the package's behavior, from threading quirks to platform limitations.
At the top sits your Unity code. It interacts with classes like RTCPeerConnection, MediaStreamTrack, and DataChannel. The C# wrapper translates your calls into native invocations and marshals data, including video frames, across the managed-to-native boundary. At the bottom, the native libwebrtc build handles peer connection state, ICE candidate gathering, codec negotiation, encryption, and media transport.
Signaling, the process of exchanging connection offers and answers between peers, is deliberately not part of the package. You supply your own signaling channel, whether that's a WebSocket server, a game relay, or a matchmaking backend. The package gives you the session descriptions and ICE candidates to exchange; getting them to the other peer is your job.
The key takeaway from the diagram: media flows peer-to-peer through the native layer, while signaling flows through your own server. Confusing the two is the most common conceptual mistake developers make when starting with Unity WebRTC.
Installing the Unity WebRTC Package
Installation is straightforward, but a few constraints catch people off guard. Here's the process in natural language.
First, open the Package Manager from the Window menu in the Unity editor. Unity distributes the WebRTC package through its own registry rather than the default asset store flow, so you add it by registering the package's git URL as a new package source, or by adding the package by name through the Package Manager's add-from-git-URL option. Once registered, the package appears in your package list and can be installed like any other.
Second, let Unity resolve dependencies. The package pulls in its native plugin binaries for the platforms it supports, and the editor will recompile your scripts. If you see compilation errors after installation, check that your Unity version meets the package's minimum requirement. The package targets recent Unity LTS releases, and each package version declares which editor versions it supports, so verify the compatibility table in the official Unity WebRTC documentation before committing to a version.
Third, verify the installation. The package ships with sample scenes that demonstrate peer connections, video streaming, and data channels. Opening a sample scene and entering play mode confirms the native plugin loaded correctly. If the samples fail, the usual culprit is a platform mismatch: the native plugin doesn't cover every Unity build target, and WebGL in particular is not supported, a limitation covered later in this guide.
Platform support is the biggest pre-installation decision. Desktop targets (Windows, macOS, Linux) and mobile (Android, iOS) are the supported surface. If your product must run in a browser, Unity WebRTC in its current form won't get you there, and you'll need an alternative architecture, such as running the Unity player as a native client or using a streaming approach like Unity Render Streaming server-side.
Core API Components
Unity WebRTC RTCPeerConnection
RTCPeerConnection is the heart of the API: it represents a single peer-to-peer connection and manages everything from ICE negotiation to media transport. You create one per remote peer, configure it with STUN and TURN servers for NAT traversal, and drive it through the offer-answer handshake.
The connection exposes state properties you'll rely on heavily. ConnectionState tells you whether the peer connection is new, connecting, connected, disconnected, or closed. IceConnectionState reports the health of the underlying ICE transport, which is often the first place you notice network trouble. Both fire change events, so the standard pattern is to subscribe to the events and surface connection status in your UI.
A practical note from teams shipping with the package: treat the Disconnected state as recoverable, not fatal. WebRTC connections routinely drop and re-establish ICE connectivity, especially on mobile networks. Give the connection time to recover before tearing down the session, and design your game logic around transient disconnects.
Unity WebRTC MediaStreamTrack and VideoStreamTrack
MediaStreamTrack is the base abstraction for a single media source, and VideoStreamTrack is its video specialization. A video track in Unity wraps a texture: you create a track from a camera's render output, a raw texture, or screen capture, and the native layer encodes those frames and sends them to the remote peer.
On the receiving side, the pattern inverts. When a remote track arrives, you get a texture you can assign to a material or a RawImage in your UI. The texture updates each frame as new encoded frames arrive and are decoded, which leads to one of the most common misconceptions in the package, covered in the troubleshooting section.
Audio tracks follow the same model, sourced from microphone input or audio rendered inside Unity. Tracks are added to the peer connection before negotiation so they're included in the session description, or added later with an explicit renegotiation.
Unity WebRTC DataChannel
The DataChannel carries arbitrary binary and text messages over the same peer connection, with the same encryption and NAT traversal but no media pipeline. In Unity games it's the natural fit for gameplay-critical state that must arrive quickly: position updates, hit confirmation, or custom protocol messages.
Because it shares the connection's transport, a congested video stream can affect DataChannel delivery. If you're sending both gameplay data and video, keep gameplay messages small and consider whether unreliable, unordered delivery suits your use case better than guaranteed ordering.
Capturing and Sending Audio and Video
Capturing media in Unity WebRTC follows a consistent pattern: create a track from a source, add it to the peer connection, and keep the WebRTC update loop running.
For camera capture, you render a camera to a texture and wrap that texture in a video track. This is the same mechanism Unity Render Streaming uses to stream gameplay to browsers. Multi-camera setups work by creating one track per camera, which is useful for spectator views, picture-in-picture layouts, or streaming different perspectives to different peers.
Screen capture follows the same shape: capture the screen (or a region of it) into a texture and expose it as a track. Microphone input becomes an audio track through the package's audio capture integration, which routes Unity audio into the WebRTC pipeline.
One detail that trips up nearly every newcomer: the package requires a per-frame update call. The WebRTC internals, including texture uploads and frame processing, are driven by an explicit update method that you must invoke every frame from your game loop. If you forget it, tracks appear to connect but no video flows, and the symptom looks like a network failure when it's actually a lifecycle bug. The samples demonstrate the correct call placement; follow their structure.
Once tracks are added and the offer-answer exchange completes, media flows automatically. The native layer handles encoding, packetization, and retransmission without further per-frame attention from your code beyond the update call.
Common Pitfalls and Troubleshooting
OnTrack Fires Only Once
The most frequently reported confusion in the Unity WebRTC community: the event that delivers remote tracks appears to fire only once, and developers expect it to fire per frame. It doesn't, and it shouldn't.
The event fires once per incoming track, when the track is first negotiated. After that, the track's associated texture updates internally every frame as new frames arrive from the remote peer. You don't receive repeated events; you receive one track and a continuously refreshing texture. If video appears frozen, the problem is almost never the event. Check that the per-frame update call is happening, that the texture is actually assigned to something visible in your scene, and that the connection state is Connected rather than Disconnected.
WebGL Compatibility Issues
Unity WebRTC does not currently support the WebGL build target. The native libwebrtc plugin has no WebGL build, so the package simply isn't available in browser builds. This is the single biggest constraint for teams targeting web delivery.
Community workarounds exist but all involve architecture changes rather than package fixes. The common pattern is to keep the Unity app out of the browser and stream to it: run the Unity player on a server or native client and deliver video to browsers through a streaming layer, which is essentially what Unity Render Streaming does. Another pattern is splitting the product, with the browser front end built in a web framework and the Unity portion delivered as a native app.
The official roadmap has signaled WebGL support as a long-term goal, but as of 2026 there is no shipped timeline. If browser delivery is a hard requirement for your product today, evaluate managed alternatives: VideoSDK's Unity SDK covers native platforms while its JavaScript SDK handles the browser side, letting both join the same room through a shared room-based architecture.
ICE Candidate Problems
Missing or delayed ICE candidates produce connections that never complete. The symptoms are a peer connection stuck in the Connecting state, or a session that works on the same network but fails across the internet.
The usual causes: forgetting to exchange candidates through your signaling channel (the package gathers them; it does not send them), gathering finishing after the remote answer was already applied, or restrictive NATs requiring a TURN server that you didn't configure. The fixes in order: make sure every candidate your local peer generates is relayed to the remote peer and added there, handle candidates that arrive after the connection is established (late candidates are normal), and always configure a TURN server for production, because a meaningful fraction of real-world networks cannot complete direct peer-to-peer connectivity without one.
Performance Optimization
Performance tuning in Unity WebRTC is mostly about encoder configuration and frame discipline.
Bitrate control is your primary lever. Setting a sensible target bitrate per track, based on resolution and frame rate, prevents the encoder from saturating the network and starving your gameplay traffic. For live video from a game camera, teams typically start around a few megabits per second for 1080p and adjust downward based on observed network conditions. Codec selection matters too: the native library supports H.264 and VP8 among others, and hardware encoder availability varies by platform, with H.264 hardware encoding widely available on desktop and mobile GPUs.
Multi-camera setups multiply cost linearly: each track is a separate encode. If you're streaming several perspectives, budget bitrates per track and consider whether all cameras need full frame rate. Profiling is essential; the Unity profiler shows the managed-side cost, and encode time on the native side shows up as frame time pressure. Watch for the pattern where video encoding pushes your frame budget past 16 milliseconds and the game itself starts dropping frames.
One advantage of managed platforms here: VideoSDK's network-adaptive streaming adjusts bitrate and resolution automatically as bandwidth fluctuates, which removes a class of tuning work the raw package leaves to you.
Real-World Use Cases
Unity WebRTC shows up in production across several patterns.
Multiplayer voice chat is the most common. Each player's microphone becomes an audio track on a peer connection, giving low-latency in-game communication without a separate voice service. For larger sessions, mesh peer connections scale poorly, which is where room-based architectures like VideoSDK's Unity SDK win: a media server fans out tracks so each client uploads once.
Live streaming from a Unity game covers spectator views, esports overlays, and remote play. A camera renders to a track, and remote viewers watch in a browser or native client. Unity Render Streaming is the reference implementation of this pattern.
AR and VR collaboration tools use it to share device camera feeds and spatial data between participants, with the DataChannel carrying synchronization state alongside video. In-app video support, such as a coach reviewing a player's form live, or a support agent joining a customer inside a Unity-built product, rounds out the list. Each of these maps directly onto VideoSDK use cases like fitness coaching and remote support, where the Unity SDK provides the room, recording, and chat infrastructure around the media.
Roadmap and Future Features
The official Unity WebRTC roadmap has historically pointed at three priorities: WebGL support, simulcast (sending multiple quality levels of the same track so receivers with different bandwidth can each get a suitable stream), and expanded encoder backends such as Vulkan-based encoding. As of 2026, WebGL remains the most requested item and the least committed to a date.
The package is developed in the open, with the repository on GitHub accepting issues and community discussion. If your product depends on a roadmap item, file your use case; the team prioritizes based on reported demand. For anything blocking shipping today, the pragmatic answer is the same as throughout this guide: use the raw package where it fits, and bridge gaps with managed infrastructure where it doesn't.
Definitions Glossary
RTCPeerConnection: The core WebRTC class representing a single peer-to-peer connection, managing ICE negotiation, media transport, and connection state. In Unity WebRTC you create one per remote peer and subscribe to its state-change events.
MediaStreamTrack: The abstraction for a single media source, audio or video, attached to a peer connection. In Unity, video tracks wrap textures such as camera render output or screen captures.
DataChannel: An ordered, reliable message channel carried over the same peer connection as media, useful for gameplay data and custom protocols in Unity games.
ICE Candidates: Network address candidates gathered during connection setup and exchanged through your signaling channel. Missing or late candidates are the leading cause of connections that never complete.
Signaling: The process of exchanging offers, answers, and ICE candidates between peers. Unity WebRTC deliberately excludes signaling; you provide your own server, such as a WebSocket backend.
Room: In managed platforms like VideoSDK, a server-managed session that participants join with tokens, where a media server handles track distribution so each client uploads once instead of maintaining a mesh of peer connections.
Key Takeaways
- Unity WebRTC is the official package wrapping native libwebrtc for real-time audio, video, and data in Unity, with C# classes like RTCPeerConnection and MediaStreamTrack exposed to your game code.
- Signaling is not included: you must build or integrate your own channel to exchange offers, answers, and ICE candidates.
- The per-frame update call is mandatory; forgetting it produces connected-but-frozen video that looks like a network failure.
- WebGL is not supported, so browser delivery requires an architectural workaround such as server-side streaming or a split product.
- For larger sessions or faster shipping, VideoSDK's Unity SDK provides rooms, token authentication, recording, and network-adaptive streaming on top of the same real-time foundation.
Conclusion
Unity WebRTC gives Unity developers a legitimate path to real-time video, audio, and data without leaving the engine, and for peer-to-peer scenarios on supported platforms it does the job well. Its costs are real though: you own signaling, TURN infrastructure, reconnection logic, and performance tuning, and WebGL remains out of reach.
If you want the same real-time capabilities with the infrastructure handled for you, try VideoSDK's Unity SDK, sign up free at app.videosdk.live, and explore the code samples to see rooms, recording, and adaptive streaming working in minutes. What are you building with Unity WebRTC? Drop a comment, I'd love to hear what kind of real-time use case you're working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ