Tencent America LLC

United States of America spencerdawkins.ietf@gmail.com

applications AVTCORE/MMUSIC Working Groups Internet-Draft QUIC RTP SDP This document describes these new SDP "proto" attribute values: "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC as a transport protocol. These proto values are necessary to allow the use of QUIC as an underlying transport protocol for applications that commonly use SDP as a session signaling protocol to set up RTP connections with UDP as its underlying transport protocol, such as SIP and WebRTC.

Introduction This document describes these new SDP "proto" attribute values: "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and describes how SDP Offer/Answer () can be used to set up an RTP () connection using QUIC () as a transport protocol. These proto values are necessary to allow the use of QUIC as an underlying transport protocol for applications that commonly use SDP as a session signaling protocol to set up RTP connections with UDP as its underlying transport protocol, such as SIP () and WebRTC ().

Notes for Readers This document is intended for publiication as a standards-track RFC in the IETF stream, but has not been adopted by any IETF working group, and does not carry any special status within the IETF.

Terminology 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 () () when, and only when, they appear in all capitals, as shown here.

Contribution and Discussion Venues for this draft. (Note to RFC Editor - if this document ever reaches you, please remove this section) This document is under development in the Github repository at https://github.com/SpencerDawkins/sdp-rtp-quic. Readers are invited to open issues and send pull requests with contributed text for this document, or to send them to the author via email.

Scope of this document This document focuses on the IANA registration and description of the RTP sessions using SDP Offer/Answer, as would be the case for many current RTP applications in common use, such as SIP () and WebRTC (). This document is intended as complementary to , which largely focuses on RTP/RTCP encapsulation in QUIC datagrams, so that the SDP experts can focus on SDP offer/answer aspects, and the RTP experts can focus on RTP/RTCP encapsulation aspects.

Assumptions for this document This document assumes that for RTP-over-QUIC, it is useful to register these AVP profiles using QUIC, in order to allow existing SIP and RTCWEB RTP applications to migrate more easily to QUIC:

• RTP/SAVP ("The Secure Real-time Transport Protocol (SRTP)"), as defined in .
• RTP/AVPF ("Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"), as defined in .
• RTP/SAVPF ("Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"), as defined in .

This document assumes that any implementation adding support for RTP-over-QUIC could reasonably add support for BUNDLE (), "rtcp-mux" ().

Open Questions (probably not for this draft, but could have implications on SDP Offer/Answer)

• RTP (and RTCP) headers and payloads will be entirely encrypted using QUIC (), as secured by TLS 1.3 handshake (), between QUIC endpoints. It's worth thinking more about how that maps onto expected deployment scenarios like centralized multiparty conferencing, and also whether WebRTC really requires SAVPF with double encryption (i.e. SRTP encryption, and then QUIC encryption). No opinions here yet, just noting the question for now.
• When QUIC establishes connections, it uses IP addresses but then expects applications to use connection IDs to refer to connections, even if the underlying IP addresses change because of NAT binding, and even if the QUIC implementation performs QUIC connection migration itself, so the underlying IP addresses change. RTP applications expect to use IP addresses, not QUIC connection IDs. Must we specify an RTP/RTCP adaptation layer, similar to for HTTP/3?

Identifiers and Attributes As much as possible, these are reused from other specifications, with references to the original definitions.

Protocol Identifiers

The QUIC proto The 'QUIC' protocol identifier is similar to the 'UDP' and 'TCP' protocol identifiers in that it only describes the transport protocol, and not the upper-layer protocol. An 'm' line that specifies 'QUIC' MUST further qualify the application-layer protocol using an fmt identifier, such as "QUIC/RTP/AVPF". Media described using an 'm' line containing the 'QUIC' protocol identifier are carried using QUIC (). The following is an update to the ABNF for an 'm' line, as specified by , that defines a new value for the QUIC protocol. : (unchanged from {{RFC8866}}) : 'QUIC' : UDP port number : (unchanged from {{RFC8866}}) ]]>

The QUIC/RTP/SAVP proto The following is an update to the ABNF for an 'm' line, as specified by , that defines a new value for the QUIC/RTP/SAVP protocol. : (unchanged from {{RFC8866}}) : 'QUIC/RTP/SAVP' : UDP port number : (unchanged from {{RFC8866}}) ]]>

The QUIC/RTP/AVPF proto The following is an update to the ABNF for an 'm' line, as specified by , that defines a new value for the QUIC/RTP/AVPF protocol. : (unchanged from {{RFC8866}}) : 'QUIC/RTP/AVPF' : UDP port number : (unchanged from {{RFC8866}}) ]]>

The QUIC/RTP/SAVPF proto The following is an update to the ABNF for an 'm' line, as specified by , that defines a new value for the QUIC/RTP/SAVPF protocol. : (unchanged from {{RFC8866}}) : 'QUIC/RTP/SAVPF' : UDP port number : (unchanged from {{RFC8866}}) ]]>

A QUIC/RTP/AVPF Offer A complete example of an SDP offer using QUIC/RTP/AVPF might look like:

SDP line	Notes
v=0	Same as
o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1	Same as
s=Call to John Smith	Same as
i=SDP Offer #1	Same as
u=http://www.jdoe.example.com/home.html	Same as
e=Jane Doe jane@jdoe.example.com	Same as
p=+1 617 555-6011	Same as
c=IN IP4 198.51.100.1	Same as
t=0 0	Same as
m=audio 49170 RTP/AVP 0	Same as
m=audio 49180 RTP/AVP 0	Same as
m=video 51372 QUIC/RTP/AVPF 99	QUIC transport
a=setup:passive	will wait for QUIC handshake (setup attribute from )
a=connection:new	don't want to reuse an existing QUIC connection (connection attribute from )
c=IN IP6 2001:db8::2	Same as
a=rtpmap:99 h266/90000	H.266 VVC codec

This example is largely based on an example appearing in , Section 5, but is using QUIC/RTP/AVPF to support a newer codec. Because QUIC uses connections for both streams and datagrams, we are reusing two session- and media-level SDP attributes from that were defined in for use with TCP: setup and connection. This example SDP offer might be included in a SIP Invite.

IANA Considerations This document registers these protocols in the proto registry ().

• QUIC ()
• QUIC/RTP/SAVP ()
• QUIC/RTP/AVPF ()
• QUIC/RTP/SAVPF ()

Proto Registrations IANA is requested to add these protocols to the Session Description Protocol (SDP) Parameters proto registry ().

Type	SDP Name	Reference
proto	QUIC	RFCXXXX
proto	QUIC/RTP/SAVP	RFCXXXX
proto	QUIC/RTP/AVPF	RFCXXXX
proto	QUIC/RTP/SAVPF	RFCXXXX

Note to the RFC Editor Please replace "RFCXXXX" with the assigned RFC number, when that is available, and remove this note.

Security Considerations Security considerations for the QUIC protocol are described in the corresponding section in . Security considerations for the TLS handshake used to secure QUIC are described in . Security considerations for SDP are described in the corresponding section in . Security considerations for SDP offer/answer are described in the cooresponding section in .

Acknowledgments My appreciation to the authors of , which served as a model for the initial structure of this document. Your name could appear here. Please comment and contribute, as per .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK] This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK] An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension. This specification updates RFCs 3264, 5888, and 7941. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. Informative References Tencent Tencent Fraunhofer HHI Bytedance Inc. This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3, both also known as Versatile Video Coding (VVC) and developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. Technical University Munich Technical University Munich This document specifies a minimal mapping for encapsulating RTP and RTCP packets within QUIC. It also discusses how to leverage state from the QUIC implementation in the endpoints to reduce the exchange of RTCP packets. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/mengelbart/rtp-over-quic-draft. Akamai The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http. This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]