The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (18)
SCTP multihoming provides only marginal benefits for SIP because SIP's existing SRV-based failover procedures can accomplish the same fault tolerance goal, even allowing failover to a separate host since SIP proxies can run statelessly.
SCTP's fast retransmit (via SACK) allows SIP message loss to be detected much faster than with UDP (which requires at least 500 ms), making SCTP's most significant advantage for SIP the improvement in call setup times under packet loss conditions.
Using stream zero with the unordered flag was chosen as the simplest mapping that avoids HOL blocking. A prior proposal to use SCTP stream IDs as lightweight SIP transaction identifiers was withdrawn because RFC 3261 already provides a transaction identifier in the Via branch parameter, making SCTP stream demultiplexing unnecessary.
When both sides follow the recommendation to use independent stream management, a server is free to return responses over a different stream than the one the request arrived on, avoiding undesirable collisions when seizing a particular stream.
RFC 3261 defines 'SCTP' as a Via transport value but does not define a value for TLS over SCTP; 'TLS' in RFC 3261 is intended for TLS over TCP only. This document fills that gap by defining 'TLS-SCTP'.
RFC 3263 defines the NAPTR service value 'SIP+D2S' for SCTP but omits a value for TLS over SCTP. This document defines 'SIPS+D2S' to complete that gap.
A SIP entity SHOULD send every SIP message (request or response) over stream zero with the unordered flag set to avoid Head Of the Line (HOL) blocking.
Any SIP use of an extra layer between the transport layer and SIP that requires ordered delivery of messages MUST NOT use the SCTP unordered delivery service.
On the receiving side, a SIP entity MUST be ready to receive SIP messages over any SCTP stream.
SIP applications requiring ordered delivery (e.g., TLS) SHOULD send SIP messages belonging to the same SIP transaction over the same SCTP stream, and SHOULD send messages from different transactions over different streams when enough streams are available.
The Payload Protocol Identifier in SCTP DATA chunks transporting SIP messages MUST be set to zero, as no SCTP identifier needs to be defined for SIP messages.
TLS running over SCTP MUST NOT use the SCTP unordered delivery service, as defined in RFC 3436.
When SIP runs on top of TLS and SCTP, the mechanisms described in RFC 3436 MUST be used.
SIP server discovery for SCTP follows normal SIP procedures per RFC 3263. For TLS over SCTP, the NAPTR service value 'SIPS+D2S' is defined to identify servers supporting TLS over SCTP.
SIP transactions are mapped to SCTP streams to avoid HOL blocking. The chosen mapping sends all SIP messages over stream zero with the unordered flag; each side manages its sending streams independently, allowing responses to arrive on different streams than requests.
The Via header transport parameter is extended to include 'TLS-SCTP' for requests sent over TLS over SCTP. The updated ABNF is: transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / other-transport.
This document registers the NAPTR service field value 'SIPS+D2S' for protocol SCTP under the 'Registry for the SIP SRV Resource Record Services Field'.
The security issues raised in RFC 3261 are not worsened by SCTP, provided the stream mapping advice in Section 5.1 is followed and TLS over SCTP (RFC 3436) is used wherever TLS would be required under RFC 3261 or RFC 3263.