How WebRTC Uses SCTP Protocol
This article explores how the Stream Control Transmission Protocol (SCTP) is utilized internally within WebRTC to power non-media data transfers. It explains the integration of SCTP within the WebRTC protocol stack, its encapsulation over DTLS and UDP, and how it enables the highly flexible and configurable features of WebRTC Data Channels.
The WebRTC Protocol Stack and SCTP Encapsulation
In WebRTC, real-time media (audio and video) is transmitted using the
Secure Real-time Transport Protocol (SRTP). However, arbitrary
application data—such as chat messages, game states, or file
transfers—is handled by the RTCDataChannel API, which
relies entirely on SCTP.
SCTP does not run directly over the IP layer in WebRTC. Instead, to navigate residential firewalls, traverse symmetric NATs, and ensure secure transmission, it is encapsulated within other protocols:
- SCTP sits at the top of this sub-stack, handling connection multiplexing, reliability, and congestion control.
- DTLS (Datagram Transport Layer Security) encrypts the SCTP traffic, securing the data channel.
- UDP (User Datagram Protocol) encapsulates the DTLS packets, allowing the traffic to easily pass through NATs and firewalls using ICE (Interactive Connectivity Establishment) candidates.
This encapsulation stack is represented as: SCTP over DTLS over UDP.
Key Functions of SCTP in WebRTC
1. Powering RTCDataChannel
SCTP provides the transport layer engine for the
RTCDataChannel. While TCP is strictly reliable and ordered,
and UDP is strictly unreliable and unordered, SCTP combines the
capabilities of both. It allows developers to customize the delivery
properties of each individual data channel.
2. Flexible Reliability Models
SCTP allows WebRTC to support three distinct reliability modes on a per-channel basis:
- Fully Reliable: Guarantees that all messages are delivered in the correct order, mimicking TCP behavior. This is ideal for file transfers or text chat.
- Partially Reliable: Attempts to deliver messages but gives up after a specified number of retransmissions or after a certain time budget expires. This is ideal for real-time multiplayer gaming where old data quickly becomes obsolete.
- Unreliable: Sends messages with no guarantee of delivery or ordering, mimicking UDP behavior. This is ideal for high-frequency, disposable sensor or telemetry updates.
3. Multi-streaming and Avoiding Head-of-Line Blocking
A single SCTP association (connection) can contain multiple independent unidirectional or bidirectional streams. In TCP, if a single packet is lost, the entire connection stalls until that packet is retransmitted (Head-of-Line blocking). SCTP avoids this by isolating streams; a lost packet on Stream A does not block the delivery of packets on Stream B.
4. Message-Oriented Delivery
Unlike TCP, which is a stream-oriented protocol that sends a continuous flow of bytes, SCTP is message-oriented. It preserves message boundaries. When a sender transmits a message of a specific size, the receiver gets that exact same message block, simplifying application-level parsing.
5. Congestion and Flow Control
SCTP includes built-in congestion control mechanisms similar to TCP. It monitors network capacity, detects congestion, and adjusts the transmission rate dynamically to prevent network overload, ensuring fair bandwidth sharing with other network traffic.