]> Tencent America LLC

United States of America spencerdawkins.ietf@gmail.com

applications AVTCORE Working Group 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 such as SIP and WebRTC that commonly use SDP as a session signaling protocol to set up RTP connections.

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 ( and related specifications) as a transport protocol. These proto values are necessary to allow the use of QUIC as an underlying transport protocol for applications such as SIP () and WebRTC () that commonly use SDP as a session signaling protocol to set up RTP connections.

Notes for Readers (Note to RFC Editor - if this document ever reaches you, please remove this section) This document is intended for publication 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.

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 drafts such as , which largely focus on RTP/RTCP encapsulation in QUIC, so that the SDP experts can focus on SDP offer/answer aspects, and the RTP experts can focus on RTP/RTCP encapsulation aspects.

Contribution and Discussion Venues for this draft. (Note to RFC Editor - if this document ever reaches you, please remove this section) With the concurrence of the AVTCORE and MMUSIC working group co-chairs, this document should be discussed in the AVTCORE working group, in the same venue where RTP over QUIC proposals are being discussed. When proposals for RTP over SIP have stablized in AVTCORE, this document will be sent to the MMUSIC working group for review by SDP experts, but SDP-specific comments are welcomed at any time. Readers are also invited to open issues and send pull requests with contributed text for this document in the GitHub repository at https://github.com/SpencerDawkins/sdp-rtp-quic. The direct link to the list of issues is https://github.com/SpencerDawkins/sdp-rtp-quic/issues.

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 also add support for BUNDLE () and "rtcp-mux" (), so these capabiilities are not mentioned further in this document.

An Aside on Secure AVP Profiles in an RTP Over QUIC Context Existing RTP implementations have the choice for any given RTP connection to exchange either unencrypted RTP streams (using AVP profiles such as RTP/AVPF) or encrypted RTP streams (using AVP profiles such as RTP/SAVPF). An RTP implementation that uses QUIC as its underlying transport protocol will always send an RTP stream that is encrypted between the two QUIC endpoints, so some RTP implementations may be tempted to exchange unencrypted RTP as an encrypted QUIC payload, reasoning that QUIC protection will be sufficient. One nuance here is that QUIC is heavily encrypted between two QUIC endpoints, with the very minimal exception of the invariant header fields described in , but as described in , many RTP applications use middleboxes for a variety of reasons, and some of these topologies (for example, media translation) require that the middlebox understand the RTP payload. These middleboxes are explictly addressed, and the QUIC cryptographic handshake described in takes place between the RTP endpoint and the RTP middlebox. After the QUIC cryptographic handshake has succeeded, the RTP middlebox has access to the RTP in the QUIC payload, and can perform whatever translations are appropriate before forwarding the RTP steam to another RTP endpoint. However, if the RTP sender uses one of the "insecure" AVPs, the middlebox does not have any indication that the RTP sender wants the translated RTP stream to be protected by encryption when the middlebox forwards it. That might be fine if the middlebox and RTP endpoint are both using RTP over QUIC, but if the middlebox is performing transport translation as well, the middlebox may also be translating an RTP-over-QUIC stream to RTP-over-UDP. This specification tries to provide that indication by supporting both "secure" and "insecure" AVPs for RTP over QUIC, so the middlebox that is providing back-to-back RTP sessions as described in can be aware of the sender's desire that a translated RTP stream is encypted regardless of the underlying transport protocol, without always requiring both SRTP and QUIC encryption between each pair of QUIC endpoints for all RTP traffic. That's one strategy, and it's certainly possible that other strategies might be safer, cleaner, and/or more useful.

Open Questions The current contents of and would allow an existing RTP/RTCP implementation to make a relatively straightforward transition from "RTP over UDP" to "RTP over QUIC datagrams over UDP", and likewise from "RTCP over UDP" to "RTCP over QUIC datagrams over UDP". Although it is still early days for RTP over QUIC, things may not be that straightforward. Just limiting our attention to various proposals for "RTP over QUIC" that have already been discussed on the Media Over QUIC IETF mailing list and in various IETF side meetings, we have seen

• a desire to make use of QUIC connection migration in case of path failure between two endpoints
• a desire to replace RTP Round Trip Time (RTT) measurement with something like a proposed QUIC extension for timestamps () that could be used to measure one-way delays
• a desire to make use of QUIC streams, potentially with QUIC datagrams in the same QUIC connection
• a desire to decouple the RTP state machine and the QUIC state machine, which currently assume they are solely responsible for managing sending rates, without any knowledge of what the other plans to do
• a desire to select a media-focused congestion control mechanism such as "Self-Clocked Rate Adaptation for Multimedia", or SCReAM (), that can be included in QUIC implementations
• a desire to use RTP over QUIC in peer-to-peer applications, which likely would require extensions to the QUIC protocol for NAT traversal, at a bare minimum

Changes to the SDP signaling in and may be (and likely would be) needed in order to support any of these desires (or other desires that may surface in the future).

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. Thanks to these folks for helping to improve this draft:

• Colin Perkins

(Your name also 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] This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. 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 memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. 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 properties of the QUIC transport protocol that are common to all versions of the protocol. 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. n.d. Informative References Tencent Tencent Fraunhofer HHI Bytedance Inc. Nokia Technologies 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. Private Octopus Inc. The TIMESTAMP frame can be added to Quic packets when one way delay measurements are useful. The timestamp is set to the number of microseconds from the beginning of the node's epoch to the time at which the packet is sent. The draft defines the "enable_timestamp" transport parameter for negotiating the use of this extension frame, and the TIMESTAMP frame. 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]