Skip to main content
The ORTC (Object Real-Time Communications) example demonstrates Pion WebRTC’s ORTC capabilities, providing fine-grained control over the WebRTC stack. Instead of using the high-level PeerConnection API, ORTC gives you direct access to ICE, DTLS, and SCTP transports for maximum flexibility.

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

How It Works

1

Create ICE Gatherer

Manually create and configure ICE gathering:
2

Construct Transport Stack

Build ICE, DTLS, and SCTP transports:
3

Gather Local Parameters

Collect all parameters needed for signaling:
4

Exchange Signaling

Exchange ORTC parameters with remote peer:
5

Start Transports

Manually start each transport layer:
6

Create DataChannel

Create DataChannel using ORTC API:

Complete Source Code

Important Implementation Details

ORTC requires explicit ICE role assignment:
Roles:
  • Controlling: Acts as offerer, initiates connectivity checks
  • Controlled: Acts as answerer, responds to checks
Both sides must agree on roles or connection will fail.
The Signal struct is NOT part of the ORTC specification:
ORTC doesn’t define a signaling format - you’re free to exchange this information however you want:
  • JSON over WebSocket
  • Protocol Buffers
  • Custom binary format
  • HTTP POST (as shown in example)
Transports must be started in order:
  1. ICE Transport - Network connectivity
  2. DTLS Transport - Security/encryption
  3. SCTP Transport - DataChannel support
Starting out of order will cause connection failures.
Only the offerer should create DataChannels initially:
The answerer handles channels via the OnDataChannel callback.

Running the Example

Two Terminal Setup

1

Start as answerer (Terminal 1)

Copy the base64 encoded signal that appears
2

Start as offerer (Terminal 2)

Copy the base64 encoded signal
3

Exchange signals

  • Paste offerer’s signal into answerer’s terminal
  • Paste answerer’s signal via curl to offerer:
4

Watch messages

Both terminals will show random messages being exchanged every 5 seconds

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
Trade-offs:
  • More complex code
  • More error-prone
  • Requires deeper protocol knowledge
  • Limited browser support (mostly Chromium)