Overview
ORTC is an alternative API to WebRTC that provides explicit control over the underlying transport layers. This example shows how to establish a DataChannel connection using the ORTC API, manually managing ICE gathering, DTLS handshake, and SCTP transport.Key Features
- Manual ICE transport management
- Explicit DTLS and SCTP transport control
- ICE role negotiation (controlling vs controlled)
- Low-level signaling structure
- DataChannel creation and handling via ORTC
- HTTP server for easy SDP exchange (when acting as offerer)
ORTC vs WebRTC API
| Aspect | WebRTC API | ORTC API |
|---|---|---|
| Abstraction | High-level, automatic | Low-level, explicit |
| ICE | Automatic | Manual gathering/control |
| DTLS | Automatic | Manual start/configuration |
| Control | Limited | Full access to transports |
| Complexity | Simple | Advanced |
| Use Case | Standard applications | Custom protocols, debugging |
How It Works
Complete Source Code
Important Implementation Details
ICE Role Negotiation
ICE Role Negotiation
ORTC requires explicit ICE role assignment:Roles:
- Controlling: Acts as offerer, initiates connectivity checks
- Controlled: Acts as answerer, responds to checks
Signal Structure
Signal Structure
The ORTC doesn’t define a signaling format - you’re free to exchange this information however you want:
Signal struct is NOT part of the ORTC specification:- JSON over WebSocket
- Protocol Buffers
- Custom binary format
- HTTP POST (as shown in example)
Transport Ordering
Transport Ordering
Transports must be started in order:
- ICE Transport - Network connectivity
- DTLS Transport - Security/encryption
- SCTP Transport - DataChannel support
DataChannel Creation
DataChannel Creation
Only the offerer should create DataChannels initially:The answerer handles channels via the
OnDataChannel callback.Running the Example
Two Terminal Setup
Exchange signals
- Paste offerer’s signal into answerer’s terminal
- Paste answerer’s signal via curl to offerer:
When to Use ORTC
Custom Protocols
Building custom signaling or connection protocols that don’t fit WebRTC’s model
Debugging
Deep debugging of connection issues with fine-grained control over each layer
Research
Academic research or experimentation with transport protocols
Optimization
Performance optimization requiring precise control over network behavior
For most applications, the standard WebRTC PeerConnection API is recommended. Use ORTC only when you need the additional control and complexity it provides.
Advantages & Trade-offs
Advantages:- Full control over transport layers
- Custom signaling formats
- Better debugging visibility
- Fine-grained configuration
- More complex code
- More error-prone
- Requires deeper protocol knowledge
- Limited browser support (mostly Chromium)
Related Examples
- Data Channels - Standard WebRTC DataChannel API
- Pion to Pion - Two Pion instances communicating
- Data Channels Detach - Lower-level DataChannel access