Overview
SmallWebRTCTransport enables peer-to-peer (“serverless”) WebRTC connections between clients and your Pipecat application. It implements bidirectional audio, video and data channels using WebRTC for real-time communication. This transport is open source and self-contained, with no dependencies on any other infrastructure. SmallWebRTCTransport is the default transport for the Pipecat examples and starter kits. It is heavily tested and can be used in production.For detailed notes on how to decide between using the SmallWebRTCTransport or
other WebRTC transports like the DailyTransport, see this
post.
SmallWebRTCTransport API
Transport methods and configuration options
SmallWebRTCConnection API
Connection management and signaling methods
Example Code
Working example with voice agent implementation
Official WebRTC Docs
Learn more about WebRTC!
Installation
To useSmallWebRTCTransport
, install the required dependencies:
For production deployments across different networks, you may need to
configure STUN/TURN servers for NAT traversal.
Frames
Input
InputAudioRawFrame
- Audio data from WebRTC peerUserImageRawFrame
- Video frames from peer’s cameraTransportMessageUrgentFrame
- Application messages from peer
Output
OutputAudioRawFrame
- Audio data to WebRTC peerOutputImageRawFrame
- Video frames to peerTransportMessageFrame
- Application messages to peerTransportMessageUrgentFrame
- Urgent messages to peer
Key Features
- Serverless Architecture: Direct peer-to-peer connections with no intermediate servers
- Bidirectional Media: Full-duplex audio and video streaming
- Data Channels: Application messaging and signaling support
- Production Ready: Heavily tested and used in Pipecat examples
- ICE Support: Configurable STUN/TURN servers for NAT traversal
Usage Example
SmallWebRTCTransport requires two components working together: a signaling server to handle the WebRTC handshake, and your Pipecat bot that processes the media streams. Unlike other transports, you cannot use SmallWebRTCTransport without implementing both parts.Using the Development Runner (Recommended)
The easiest way to get started is using Pipecat’s development runner, which handles all the server infrastructure automatically:- Creates a FastAPI server with WebRTC signaling endpoints
- Serves a built-in web interface for testing
- Handles WebRTC connection management and cleanup
- Spawns your bot for each new connection
The development runner is the recommended approach for development and can
also be used in production with Pipecat Cloud.
Manual Server Implementation
For advanced use cases or custom deployment requirements, you can implement the server infrastructure manually:1. Signaling Server (Required)
First, create a web server to handle WebRTC connection establishment. This server receives offers from clients and creates the WebRTC connections that your bot will use:2. Pipecat Bot Implementation
Next, implement your bot function that receives the WebRTC connection from the server and creates the transport:How It Works Together
- Client connects to your server at
/api/offer
with WebRTC offer - Server creates
SmallWebRTCConnection
and initializes it with the offer - Server starts
run_bot()
in background with the connection - Bot creates
SmallWebRTCTransport
using the connection - Media flows directly between client and bot via WebRTC peer connection
How to connect with SmallWebRTCTransport
For client connections, you have two options:- Pipecat Client SDK (Recommended): Use the JavaScript SDK for easy integration
- Custom WebRTC Client: Implement WebRTC signaling manually for advanced use cases
Examples
To see a complete implementation, check out the following examples:Video Transform
Demonstrates real-time video processing using WebRTC transport
Voice Agent
Implements a voice assistant using WebRTC for audio communication
Media Handling
Audio
Audio is processed in 20ms chunks by default. The transport handles audio format conversion and resampling as needed:- Input audio is processed at 16kHz (mono) to be compatible with speech recognition services
- Output audio can be configured to match your application’s requirements, but it must be mono, 16-bit PCM audio
Video
Video is streamed using RGB format by default. The transport provides:- Frame conversion between different color formats (RGB, YUV, etc.)
- Configurable resolution and framerate
WebRTC ICE Servers Configuration
When implementing WebRTC in your project, STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers are usually needed in cases where users are behind routers or firewalls. In local networks (e.g., testing within the same home or office network), you usually don’t need to configure STUN or TURN servers. In such cases, WebRTC can often directly establish peer-to-peer connections without needing to traverse NAT or firewalls.What are STUN and TURN Servers?
- STUN Server: Helps clients discover their public IP address and port when they’re behind a NAT (Network Address Translation) device (like a router). This allows WebRTC to attempt direct peer-to-peer communication by providing the public-facing IP and port.
- TURN Server: Used as a fallback when direct peer-to-peer communication isn’t possible due to strict NATs or firewalls blocking connections. The TURN server relays media traffic between peers.
Why are ICE Servers Important?
ICE (Interactive Connectivity Establishment) is a framework used by WebRTC to handle network traversal and NAT issues. TheiceServers
configuration provides a list of STUN and TURN servers that WebRTC uses to find the best way to connect two peers.
Advanced Configuration
ICE Servers
For better connectivity, especially when testing across different networks, you can provide STUN servers:ESP32 Compatibility
For ESP32 WebRTC connections, use the development runner with ESP32 mode:Troubleshooting
If clients have trouble connecting or streaming:- Check browser console for WebRTC errors
- Ensure you’re using HTTPS in production (required for WebRTC)
- For testing across networks, consider using Daily which provides TURN servers
- Verify browser permissions for camera and microphone
- Try the development runner first to isolate connection issues
Additional Notes
- HTTPS Requirement: WebRTC requires HTTPS in production environments
- Browser Compatibility: Modern browsers support WebRTC natively
- Firewall Considerations: May need TURN servers for restrictive network environments
- Latency: Direct peer-to-peer connections typically provide lower latency than server-mediated solutions
- Scalability: Each connection is independent; consider connection pooling for high-traffic applications
- Development: Use the development runner for rapid prototyping and testing