SIP-over-QUIC: Session Initiation Protocol over QUIC Transport

1.1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the variable-length integer encoding from Section 16 of [QUIC-TRANSPORT].¶

Packet and frame diagrams in this document use the format described in Section 1.3 of [QUIC-TRANSPORT].¶

1.2. Definitions

The following terms are used:¶

abort:

An abrupt termination of a connection or stream, possibly due to an error condition.¶

endpoint:

Either the client or server of the connection.¶

connection:

A transport-layer connection between two endpoints using QUIC as the transport protocol.¶

connection error:

An error that affects the entire SIP-over-QUIC connection.¶

frame:

The smallest unit of communication on a stream in SIP-over-QUIC, consisting of a header and a variable-length sequence of bytes structured according to the frame type.¶

Protocol elements called "frames" exist in both this document and [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, the frame name will be prefaced with "QUIC". For example, "QUIC CONNECTION_CLOSE frames". References without this preface refer to frames defined in Section 7.2.¶

peer:

An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion.¶

receiver:

An endpoint that is receiving frames.¶

sender:

An endpoint that is transmitting frames.¶

SIP/2.0:

The SIP/2.0 specification as described in RFC3261 [SIP2.0].¶

SIP-over-QUIC connection:

A QUIC connection where the negotiated application protocol is SIP-over-QUIC.¶

stream:

A bidirectional or unidirectional bytestream provided by the QUIC transport. All streams within an SIP-over-QUIC connection can be considered "SIP-over-QUIC streams", but multiple stream types are defined within SIP-over-QUIC.¶

stream error:

An application-level error on the individual stream.¶

transport client:

The endpoint that initiates a SIP-over-QUIC connection.¶

transport server:

The endpoint that accepts a SIP-over-QUIC connection.¶

The terms "call", "dialog", "header", "header field", "header field value", "initiator", "invitee", "message", "method", "proxy server", "request", "(SIP) transaction", "user agent client" and "user agent server" are defined in Section 6 of [SIP2.0].¶

2.1. QUIC Transport

SIP-over-QUIC relies on QUIC version 1 as the underlying transport. The use of other QUIC transport versions with SIP-over-QUIC MAY be defined by future specifications.¶

QUIC connections are established as described in [RFC9000]. During connection establishment, SIP-over-QUIC support is indicated by selecting the ALPN token "sips/quic" in the TLS handshake. Support for other application-layer protocols MAY be offered in the same handshake.¶

• Author's Note: The original intention of this document was to define the next major version of SIP, i.e. SIPv3. Therefore, the future ALPN token could be sips/3 or s3 (similarly to h2/h3).¶

QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol. SIP-over-QUIC user agents MUST support a mechanism to indicate the target host to the server during the TLS handshake. If the target destination user agent server is identified by a domain name [RFC8499], clients MUST send the Server Name Indication ([SNI]) TLS extension unless an alternative mechanism to indicate the target host is used.¶

SIP-over-QUIC messages are carried in reliable QUIC streams; therefore, the SIP-over-QUIC protocol defined by this document is a reliable SIP transport. Thus, client and server transactions using SIP-over-QUIC for transport MUST follow the procedures and timer values for reliable transports as defined in [SIP2.0].¶

2.2. Connection Reuse

SIP-over-QUIC connections are persistent across multiple request-response transactions. A SIP-over-QUIC connection MAY also be shared by multiple concurrent dialogs, with each dialog individually identified by the Call-ID header and tag= parameters on the To and From headers.¶

3.1. QUIC Clients and Servers

This specification introduces two new terms: "transport client" to denote the host that initiates the QUIC transport connection for exchanging SIP-over-QUIC messages, and "transport server" as its peer. These terms are orthogonal to SIP's concepts of user agent client (UAC) and user agent server (UAS): transport clients and servers may take on either role in the SIP-over-QUIC connection.¶

3.2. SIP Transaction Framing

SIP-over-QUIC transactions begin with a request message sent by a UAC on a request stream, which is a bidirectional QUIC stream; see Section 5. If the user agent client making the request is accessing the transport connection from the transport client endpoint, then the request stream is carried on a client-initiated bidirectional QUIC stream. If the user agent client making the request is accessing the transport connection from the transport server endpoint, then the request stream is carried on a server-initiated bidirectional QUIC stream.¶

Each SIP-over-QUIC transaction has exclusive use of a request stream. Only one request is made per request stream. The UAS sends zero or more provisional responses on the same stream as the request, followed by one or more final responses. See Section 7.2 of [SIP2.0] for a description of provisional and final responses.¶

On a given request stream, receipt of multiple requests MUST be treated as malformed.¶

A SIP message (request or response) consists of:¶

1. the header section, including message control data, sent in SIP-over-QUIC as a single HEADERS frame,¶
2. optionally, the message body, if present, sent in SIP-over-QUIC as a series of DATA frames.¶

Headers are described in Section 7.3 of [SIP2.0]. Message bodies are described in Section 7.4 of [SIP2.0].¶

Receipt of an invalid sequence of frames MUST be treated as a connection error of type SIP_FRAME_UNEXPECTED. In particular, a DATA frame received before any HEADERS frame is considered invalid. Other frame types, especially unknown frame types, MAY be permitted, subject to their own rules, see Section 9.¶

The HEADERS frame might reference updates to the QPACK dynamic table. While these updates are not directly part of the message exchange, they MUST be received and processed before the message can be consumed.¶

After sending a request, the UAC MUST close the stream for sending (see Section 3.4 of [QUIC-TRANSPORT]). After sending the last final response, the UAS MUST close the stream for sending. At this point, the QUIC stream is fully closed.¶

When a stream is closed, this indicates the completion of the SIP-over-QUIC transaction. If a stream terminates without enough of the request to provide a complete response, the UAS SHOULD abort the stream with the error code SIP_REQUEST_INCOMPLETE.¶

3.3. SIP Header Fields

SIP messages carry metadata as a series of key-value pairs called "SIP header fields"; see Section 7.3 of [SIP2.0]. For a listing of registered SIP header fields, see the "Session Initiation Protocol (SIP) Parameters - Header Fields Registry" maintained at https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2.¶

transport  =/  "QUIC"

Via: SIP/2.0/QUIC wxp6O3dffes2.example.com;branch=z9hG4bKXG1gNkhgOiNR

transport-param  =/  "transport=" "quic"

3.4. Connection Keep-Alive

SIP-over-QUIC endpoints may keep their QUIC connection active and open by sending periodic PING frames to defer the QUIC idle timeout as described in Section 10.1.2 of [QUIC-TRANSPORT].¶

4.1. Transactions

In [SIP2.0], messages pertaining to a given SIP transaction are identified as such using the branch parameter on the Via: header fields carried in requests and responses. In SIP-over-QUIC, individual transactions are tracked using the QUIC streams that are used to carry them. SIP-over-QUIC endpoints MAY omit this parameter. For intermediaries converting between SIP-over-QUIC and SIP sessions running over other transport protocols, these endpoints SHOULD insert missing branch parameters. To avoid leaking details of the QUIC transport connection, these converted branch parameters MUST NOT be textual representations of the stream IDs used to carry a given transactions, or any other representation that could be used to infer stream IDs that have been used in a given QUIC transport connection.¶

4.2. Dialogs

In [SIP2.0], dialogs are tracked by use of the Call-ID: header field and the tag= parameter on the To: and From: header fields. The current document does not introduce any additional means for tracking dialogs, and as such the Call-ID: and tag= values MUST continue to be used in SIP-over-QUIC.¶

5.1. Bidirectional Streams

Bidirectional QUIC streams are used for SIP requests and responses. These streams are referred to as request streams.¶

5.2. Unidirectional Streams

SIP-over-QUIC makes use of unidirectional QUIC streams. The purpose of a given unidirectional stream is indicated by a stream type, which is sent as a variable-length integer at the start of the stream. The format and structure of data that follows this integer is determined by the stream type.¶

Unidirectional Stream Header {
  Stream Type (i),
}

One stream type is defined in this document: the control stream. In addition, the HTTP/3 stream types defined by Section 4.2 of [QPACK] are mapped to the same values in SIP-over-QUIC (0x2 for the encoder stream and 0x3 for the decoder stream).¶

In addition, the stream type value of 0x4 is reserved by this document for future use as the media stream.¶

Each SIP-over-QUIC user agent MUST create at least one unidirectional stream for the SIP-over-QUIC control stream. If the QPACK dynamic table is used, then each endpoint will open two additional unidirectional streams each. Other extensions might require further unidirectional streams. Therefore, the transport parameters sent by both endpoints MUST allow the peer to create at least three unidirectional streams. These transport parameters SHOULD also provide at least 1,024 bytes of flow-control credit to each unidirectional stream.¶

If the stream header indicates a stream type that is not supported by the recipient, the receiver MUST abort reading the stream, discard incoming data without further processing, and reset the stream with the SIP_STREAM_CREATION_ERROR error code. The recipient MUST NOT consider unknown stream types to be a connection error of any kind.¶

Since certain stream types can affect connection state, a recipient user agent SHOULD NOT discard data from incoming unidirectional streams prior to reading the stream type.¶

Implementations SHOULD wait for the reception of a SETTINGS frame describing what stream types their peer user agent supports before sending streams of that type. Implementations MAY send stream types that do not modify the state or semantics of existing protocol components before it is known whether the peer user agent supports them, but MUST NOT send stream types that do (such as QPACK).¶

A sender can close or reset a unidirectional stream unless otherwise specified. A receiver MUST tolerate unidirectional streams being closed or reset prior to the reception of the unidirectional stream header.¶

7.1. Frame Layout

All frames have the following format:¶

SIP-over-QUIC Frame Format {
  Type (i),
  Length (i),
  Frame Payload (...)
}

A frame includes the following fields:¶

• Type: A variable-length integer that identifies the frame type.¶
• Length: A variable-length integer that describes the length in bytes of the Frame Payload.¶
• Frame Payload: A payload, the semantics of which are determined by the Type field.¶

Each frame's payload MUST contain exactly the fields identified in its description. A frame payload that contains additional bytes after the identified fields of a frame payload that terminates before the end of the identified fields MUST be treated as a connection error of type SIP_FRAME_ERROR.¶

When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error of type SIP_FRAME_ERROR. Streams that terminate abruptly may be reset at any point in a frame.¶

7.2. Frame Definitions

DATA Frame {
  Type (i) = 0x00,
  Length (i),
  Data (..)
}

HEADERS Frame {
  Type (i) = 0x01,
  Length (i),
  Encoded Field Section (..)
}

CANCEL Frame {
  Type (i) = 0x02,
  Length (i),
  Stream ID (i)
}

Parameter {
  Identifier (i),
  Value (i)
}

SETTINGS Frame {
  Type (i) = 0x04,
  Length (i),
  Parameter (..) ...
}

8.1. SIP-over-QUIC Error Codes

The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing SIP-over-QUIC connections.¶

SIP_NO_ERROR (0x0300):

No error. This is used when the connection or stream needs to be closed, but there is no error to signal.¶

SIP_GENERAL_PROTOCOL_ERROR (0x0301):

Peer violated protocol requirements in a way that does not match a more specific error code or endpoint declines to use a more specific error code.¶

SIP_INTERNAL_ERROR (0x0302):

An internal error has occurred in the SIP-over-QUIC stack.¶

SIP_STREAM_CREATION_ERROR (0x0303):

The endpoint detected that its peer created a stream that it will not accept.¶

SIP_CLOSED_CRITICAL_STREAM (0x0304):

A stream required by the SIP-over-QUIC connection was closed or reset.¶

SIP_FRAME_ERROR (0x0305):

A frame that fails to satisfy layout requirements or with an invalid size was received.¶

SIP_FRAME_UNEXPECTED (0x0306):

A frame was received that was not permitted in the current state or on the current stream.¶

SIP_CANCEL_FRAME_CLOSED (0x0307):

A CANCEL frame was received that referenced an unknown stream ID.¶

SIP_SETTINGS_ERROR (0x0309):

An endpoint detected an error in the payload of a SETTINGS frame.¶

SIP_MISSING_SETTINGS (0x030a):

No SETTINGS frame was received at the beginning of the control stream.¶

SIP_REQUEST_INCOMPLETE (0x030d):

An endpoint's stream terminated without containing a fully formed request.¶

SIP_REQUEST_REJECTED (0x030b):

A server rejected a request without performing any application processing.¶

SIP_REQUEST_CANCELLED (0x030c):

The request or its response is cancelled.¶

SIP_MESSAGE_ERROR (0x030e):

A SIP message was malformed and cannot be processed.¶

SIP_HEADER_COMPRESSION_FAILED (0x0310):

The QPACK decoder failed to interpret an encoded field section and is not able to continue decoding that field. section¶

SIP_HEADER_TOO_LARGE (0x0311):

The received encoded field section was larger than the receiver has previously promised to accept. See Section 3.3.¶

10.1. Carriage Of RTP In A QUIC Transport Session

Both [QRT] and [RTP-over-QUIC] define ways to carry RTP and RTCP messages over QUIC DATAGRAM frames. With SIP and SDP already closely aligned with RTP media sessions, adapting SIP-over-QUIC to coexist within the same QUIC transport connection as RTP/RTCP would save at least one network round trip.¶

• QRT only defines a way to carry RTP and RTCP in QUIC DATAGRAM frames.¶
• RTP-over-QUIC defines a way to carry RTP and RTCP over unidirectional QUIC STREAM frames as well as QUIC DATAGRAM frames.¶

In addition, QRT attempts to define SDP attributes to allow the negotiation of QRT sessions in SIP. [SDP-QUIC] also describes a different set of SDP attributes to perform a similar task.¶

Future versions of this document or the above documents may specify a mechanism for signalling that a given media session will be carried in the same QUIC connection as the SIP-over-QUIC session.¶

10.2. Carriage Of Non-RTP Media Streaming Protocols In A QUIC Transport Session

[RUSH] does not specify a means to discover the presence of a RUSH streaming session, nor a mechanism for negotiating the encoding parameters of media that is being exchanged. RUSH has two modes of operation: Normal and Multi Stream modes. Normal mode, as described in Section 4.3.1 of [RUSH], uses a single bidirectional QUIC stream to send and receive media streams. Multi Stream mode, as described in Section 4.3.2 of [RUSH], uses a bidirectional QUIC stream for each individual media frame. Bidirectional streams appear to be used in order to give error feedback, as opposed to having a separate control stream for handling errors or using the QUIC transport error mechanism. If the stream type mechanism described in Section 5.2 is expanded to cover bidirectional streams as well, then SIP-over-QUIC could be used with RUSH.¶

[Warp] specifies that sessions are established using HTTP/3 WebTransport ([WebTransH3]). However, to the author's best knowledge WebTransport does not yet contain any signalling or media negotiation similar to how WebRTC would use SDP offer/answer exchanges, so some form of session establishment mechanism like SIP-over-QUIC could be useful in filling this gap. Warp uses QUIC unidirectional streams for sending media. Similar to MPEG-DASH, media is sent in ISO-BMFF "segments", with each stream carrying a single segment. This can easily be accommodated by the media stream type reserved in Section 5.2.¶

[QuicR-Arch] describes SDP as overly complicated, and [QuicR-Proto] defines the QuicR Manifest for advertising media sessions and endpoint capabilities and, as such, SIP-over-QUIC probably isn't required. However, it is possible that trying to design this manifest mechanism from scratch is likely to require extra time and effort to develop, while SDP is a perfectly usable solution.¶

12.1. Registration Of SIP Identification Strings

This document creates a new registration of SIP-over-QUIC in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301].¶

The "sips/quic" string identifies SIP-over-QUIC:¶

Protocol:

SIP-over-QUIC¶

Identification Sequence:

0x73 0x69 0x70 0x73 0x2F 0x71 0x75 0x69 0x63 ("sips/quic")¶

Specification:

This document¶

This document creates a new registration of SIP/2.0 over TLS in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301].¶

The "sips/2.0" string identifies SIP/2.0 over TLS:¶

Protocol:

SIP/2.0 over TLS¶

Identification Sequence:

0x73 0x69 0x70 0x73 0x2F 0x32 0x2E 0x30 ("sips/2.0")¶

Specification:

[SIP2.0]¶

This document creates a new registration of SIP/2.0 over UDP in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301].¶

The "sip/2.0" string identifies SIP/2.0 over UDP:¶

Protocol:

SIP/2.0 over UDP¶

Identification Sequence:

0x73 0x69 0x70 0x2F 0x32 0x2E 0x30 ("sip/2.0")¶

Specification:

[SIP2.0]¶

12.2. New Registries

New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of [QUIC-TRANSPORT]. These registries all include the common set of fields listed in Section 22.1.1 of [QUIC-TRANSPORT]. These registries are collected under the "Session Initiation Protocol over QUIC Transport (SIP-over-QUIC)" heading.¶

The initial allocations in these registries are all assigned permanent status and list a change controller of the IETF and a contact of the [TBC] working group.¶