The important features of SCTP in the WebRTC context are the following:
Usage of TCP-friendly congestion control.
modifiable congestion control for integration with the
SRTP media stream congestion control.
Support of multiple unidirectional streams, each providing its own
notion of ordered message delivery.
Support of ordered and out-of-order message delivery.
Support of arbitrarily large user messages by providing fragmentation
and reassembly.
Support of PMTU discovery.
Support of reliable or partially reliable message transport.
The WebRTC data channel mechanism does not support SCTP multihoming.
The SCTP layer will simply act as if it were running on a single-homed host,
since that is the abstraction that the DTLS layer (a connection-oriented,
unreliable datagram service) exposes.
The encapsulation of SCTP over DTLS defined in
RFC8261
provides confidentiality,
source authentication, and integrity-protected transfers.
Using DTLS over UDP in combination with Interactive Connectivity Establishment
(ICE)
RFC8445
enables middlebox traversal
in IPv4- and IPv6-based networks.
SCTP as specified in
RFC4960
MUST
be used in
combination with the extension defined in
RFC3758
and
provides the following features for transporting non-media data between
browsers:
Support of multiple unidirectional streams.
Ordered and unordered delivery of user messages.
Reliable and partially reliable transport of user messages.
Each SCTP user message contains a Payload Protocol Identifier (PPID)
that is passed to SCTP by its upper layer on the sending side and
provided to its upper layer on the receiving side.
The PPID can be used to multiplex/demultiplex multiple upper layers over
a single SCTP association.
In the WebRTC context, the PPID is used to distinguish between
UTF-8 encoded user data,
binary-encoded user data, and
the Data Channel Establishment Protocol (DCEP) defined in
RFC8832
Please note that the PPID is not accessible via the JavaScript API.
The encapsulation of SCTP over DTLS, together with the SCTP features listed
above, satisfies all the requirements listed in
Section 4
The layering of protocols for WebRTC is shown in
Figure 2
+------+------+------+
| DCEP | UTF-8|Binary|
| | Data | Data |
+------+------+------+
| SCTP |
+----------------------------------+
| STUN | SRTP | DTLS |
+----------------------------------+
| ICE |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ... |
+----------------------------------+
Figure 2
WebRTC Protocol Layers
This stack (especially in contrast to DTLS over SCTP
RFC6083
and
in combination with SCTP over UDP
RFC6951
has been chosen for the following reasons:
supports the transmission of arbitrarily large user messages;
shares the DTLS connection with the SRTP media channels of the
PeerConnection; and
provides privacy for the SCTP control information.
Referring to the protocol stack shown in
Figure 2
the usage of DTLS 1.0 over UDP is specified in
RFC4347
the usage of DTLS 1.2 over UDP in specified in
RFC6347
the usage of DTLS 1.3 over UDP is specified in an upcoming document
TLS-DTLS13
; and
the usage of SCTP on top of DTLS is specified in
RFC8261
Please note that the demultiplexing Session Traversal Utilities for NAT (STUN)
RFC5389
vs. SRTP vs. DTLS is done
as described in
Section 5.1.2
of [
RFC5764
, and SCTP
is the only payload of DTLS.
Since DTLS is typically implemented in user application space, the SCTP
stack also needs to be a user application space stack.
The ICE/UDP layer can handle IP address changes during a session without
needing interaction with the DTLS and SCTP layers.
However, SCTP
SHOULD
be notified when an address change has happened.
In this case, SCTP
SHOULD
retest the Path MTU and reset the congestion
state to the initial state.
In the case of window-based congestion control like the one specified in
RFC4960
, this means setting the congestion window and
slow-start threshold to its initial values.
Incoming ICMP or ICMPv6 messages can't be processed by
the SCTP layer, since there is no way to identify the corresponding
association. Therefore, SCTP
MUST
support performing Path MTU discovery
without relying on ICMP or ICMPv6 as specified in
RFC4821
by using probing messages specified in
RFC4820
The initial Path MTU at the IP layer
SHOULD NOT
exceed 1200 bytes for IPv4
and 1280 bytes for IPv6.
In general, the lower-layer interface of an SCTP implementation should be
adapted to address the differences between IPv4 and IPv6 (being connectionless)
or DTLS (being connection oriented).
When the protocol stack shown in
Figure 2
is used, DTLS
protects the complete SCTP packet, so it provides confidentiality, integrity, and
source authentication of the complete SCTP packet.
SCTP provides congestion control on a per-association basis. This means
that all SCTP streams within a single SCTP association share the same
congestion window. Traffic not being sent over SCTP is not covered by
SCTP congestion control.
Using a congestion control different from the standard one might improve
the impact on the parallel SRTP media streams.
SCTP uses the same port number concept as TCP and UDP.
Therefore, an SCTP association uses two port numbers, one at each SCTP
endpoint.