]> Wonder Hamster Internetworking LLC

United States of America spencerdawkins.ietf@gmail.com

Nokia

Barcelona Spain victor.pascual_avila@nokia.com

RTP over QUIC RoQ SDP This document is intended to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP and WebRTC. The document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry that can be used to describe QUIC transport for RTP and RTCP packets, and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC. This document also contains non-normative guidance for implementers. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This document is intended to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP () and WebRTC (). The document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry ( and ) that can be used to describe QUIC transport for RTP and RTCP packets (hereafter abbreviated as "RoQ"), and describes how SDP Offer/Answer () can be used to set up an RTP () connection using QUIC ( and related specifications), as defined in . The normative descriptions and requirements for RoQ SDP appear in , , and . Non-normative guidance for implementers appears in . A sample SDP offer appears in .

Notes for Readers (Note to RFC Editor - if this document ever reaches you, please remove this section) This document has not yet been adopted by any IETF working group, so does not carry any special status within the IETF.

Conventions and Definitions 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. Because the use of SDP to describe RTP over QUIC transport relies heavily on terminology introduced in , the definitions in that document are prerequisite for understanding this document, and those terms are included here by reference.

New SDP Protocol identifiers This document reuses AVP profiles from , in order to allow existing SIP and RTCWEB RTP applications to migrate more easily to RTP over QUIC.

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 streams, as defined in , or in QUIC DATAGRAMs, as defined in .

RoQ RTP Protos As much as possible, attributes used in this section are reused from other specifications, with references to the original definitions.

The QUIC/RTP/AVP proto The QUIC/RTP/AVP transport describes RTP media with minimal RTCP-based feedback ("RTP Profile for Audio and Video Conferences with Minimal Control"), as defined in . The QUIC/RTP/AVP transport is realized using the framing method described in .

The QUIC/RTP/AVPF proto The QUIC/RTP/AVPF transport describes RTP media with extended RTCP-based feedback RTP/AVPF ("Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"), as defined in . The QUIC/RTP/AVPF transport is realized using the framing method described in .

The QUIC/RTP/SAVP proto The QUIC/RTP/SAVP transport describes RTP media with RTP/SAVP ("The Secure Real-time Transport Protocol (SRTP)"), as defined in . The QUIC/RTP/SAVP transport is realized using the framing method described in .

The QUIC/RTP/SAVPF proto The QUIC/RTP/SAVPF transport describes RTP media with RTP/SAVPF ("Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"), as defined in . The QUIC/RTP/SAVPF transport is realized using the framing method described in .

AV Profile-related Security Considerations This document currently defines the QUIC/RTP/SAVP and QUIC/RTP/SAVPF secure profiles, although this might seem unnecessary, because RoQ already uses QUIC security mechanisms. That choice is made for two reasons:

• If an implementer wishes to adapt an existing RTP application to use RoQ, and that application uses a secure AVP profile (for example, SAVPF), providing support for legacy secure AVP profiles minimizes the changes required to the implementations at each end.
• While an RoQ RTP endpoint might wish to communicate with other RoQ RTP endpoints using an AVP profile that does not include media-level security (for example, AVPF) when communicating with a non-RoQ RTP endpoint, this communication must by definition use a Topo-PtP-Translator RTP middlebox (as described in , and the RoQ endpoint has no way to know whether the RTP middlebox has negotiated a secure AVP profile with the non-RoQ endpoint. In this situation, a RoQ implementation can use some approach like SFRAME, as described in , to achieve end-to-end media security, at the price of disallowing some types of translating middleboxes (for example, Topo-Media-Translator middleboxes, as described in ).

• NOTE: Any PtP Translator middlebox that negotiates an RTP/AVP(F) AVP profile to both RTP endpoints, rather than an RTP/SAVP(F) profile, introduces a security risk. This is the case no matter which transport protocols are being translated, and the introduction of RoQ as an RTP transport protocol does nothing to change this risk.

New SDP Attribute-Names for RoQ This section describes new SDP attributes that are created for use with RoQ.

RoQ Flow Identifiers Section 5.1 of introduces a multiplexing identifier for RTP flows carried over a QUIC connection called "Flow Identifiers". This section defines a new SDP media-level attribute, "roq-flow-id". The attribute can be associated with an SDP media description ("m=" line) with any of the QUIC proto values defined in . In that case, the "m=" line port value indicates the port of the underlying QUIC transport UDP port, and the "roq-flow-id" value indicates the RoQ Flow Identifier. No default value is defined for the SDP "roq-flow-id" attribute. Therefore, if the attribute is not present, the associated "m=" line MUST be considered invalid. The definition of the SDP "roq-flow-id" attribute is: Attribute name: roq-flow-id Type of attribute: session or media Mux category: CAUTION

• NOTE: This specification sets the mux category (as discussed in Section 4 of ) as CAUTION, as an RTP mixer which is multiplexing several incoming streams onto one connection needs to ensure that RoQ Flow Identifiers do not overlap, and might need to rewrite the Flow Identifiers in received streams when further multiplexing them.

Subject to charset: No Purpose: This attribute indicates the RoQ Flow Idenfitier associated with the SDP media description. Contact name: Spencer Dawkins Contact e-mail: spencerdawkins.ietf@gmail.com Reference: (This document) Syntax: The RoQ flow identifier range is between 0 and 4611686018427387903 (2^62 - 1) (both included). Leading zeroes MUST NOT be used.

Special Considerations for Selected SDP Attributes When Using RoQ Transport This section does not introduce new SDP attribute extensions, but describes how some existing SDP attribute extensions are reused to describe RoQ media flows. We have two goals for this section:

• To describe how existing SDP attributes are used differently in order to support RoQ, and
• To be able to make the statement that other existing SDP attribute extensions can be reused with RoQ, with no special considerations.

This document assumes that an authenticated QUIC connection will be opened using a "roq" ALPN or some other ALPN, as described in Section 4.1 of .

The SDP "setup" Attribute The SDP "setup" attribute, defined for media over TCP in , is reused to indicate which endpoint initiates a QUIC connection (whether the endpoint actively opens a QUIC connection, or accepts an incoming QUIC connection. This attribute MUST be present in SDP offers and answers for RoQ.

The SDP "tls-id" Attribute The SDP "tls-id" attribute is reused as described in to allow either endpoint to decide whether to open a new QUIC connection, rather than reusing an existing QUIC connection. This attribute MUST be present in SDP offers and answers for RoQ.

The SDP "fingerprint" Attribute Because QUIC itself uses the TLS handshake as described in , the parties to a RoQ session MUST also provide authentication certificates as part of the TLS handshake procedure, as described in . When self-signed certificates are used, certificate fingerprint is represented in SDP using the fingerprint SDP attribute, as illustrated in , in order to allow mutual authentication, and provide assurance that two endpoints with no prior relationship are not being subjected to a person-in-the-middle attack, unless the signaling channel is also subjected to a person-in-the-middle attack.

The SDP "rtcp-mux" Attribute A RoQ application MUST include the "rtcp-mux" attribute defined in in its SDP signaling.

Implementation Topics Note: contains no normative requirements. , , and of this document provide normative requirements for RoQ endpoints that use SDP for signaling. Beyond those normative requirements, there are topics that are worth considering as part of implementation work, because we have been asked, "but what about the grommet SDP extension?" These topics are not part of the normative "SDP for RoQ" specification, but are gathered here for now. These topics might better appear in an appendix, a separate "SDP for RoQ Implementation Guide", or even best included in the GitHub repository Wiki for this document, because that would allow us to maintain this material on an ongoing basis.

Bundling Considerations describes a 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). The authors believe that no special considerations apply when using BUNDLE with a single QUIC connection carrying RoQ. If an application uses multiple 5-tuples in order to allow QUIC Connection Migration as described in , it is assumed that only one QUIC path will be active at any given time. If an application uses multiple 5-tuples in order to make use of the Multipath Extension for QUIC as described in , this would allow multiple QUIC paths to be active simultaneously, and this assumption will need revisiting when is approved.

Implications of Replacing RTCP Feedback with QUIC Feedback describes how some RTCP feedback can be replaced by equivalent statistics that are already collected by QUIC. The exact RTCP feedback that can be replaced depends on the QUIC statistics exposed by the underlying QUIC implementation, and these QUIC statistics might depend in turn on QUIC extensions supported in the underlying QUIC implementation. The set of possible relevant QUIC extensions is not fixed, but some discussion appears in . For these reasons, decisions about what RTCP feedback can be replaced will always be media-dependent and implementation-dependent. It is assumed that an implementer will review the application requirements, the RTP proto in use, the available RTCP feedback for the media types being transferred, and available QUIC statistics, and will do the right thing. More information about what RTCP feedback might be replaced by QUIC statistics, and what is possible, appears in .

Implications of Congestion Control A significant distinction between QUIC transport and UDP transport is that QUIC transport is always congestion-controlled at the QUIC layer. For RTP media, this ought to be a distinction without a difference. RoQ applications, like any other RTP applications, ought to perform flow control and congestion control using a control mechanism that is appropriate for the media being transferred. Having said this, it is worth saying that RoQ applications can use any RTCP mechanisms such as Codec Control Messages that can affect variables such as the Maximum Media Stream Bit Rate, as long as the RTP application respects the relevant congestion control considerations (in the case of Codec Control Messages, these considerations appear in ). RoQ applications can also use bandwidth modifiers ("b="), as described in , to control bandwidth at the media level, as is the case with any other RTP applications. RoQ applications can also use RTP Control Protocol (RTCP) Feedback for Congestion Control, as described in . Because RoQ applications are always congestion controlled at the QUIC connection level, QUIC congestion control also acts as an RTP Circuit Breaker , with no special considerations for RoQ.

Implications of using ICE with RoQ The profiles defined in assume that if an application needs to perform NAT traversal, the endpoints will perform ICE procedures as described in to gather and prioritize candidate pairs, and will then select candidate pairs that can be included in SDP media lines, as described in . Editors' Note: Other ways of performing NAT traversal for QUIC are possible, and this specification might be modified to support one or more of those methods in the future, given sufficient requirements. The modifications would likely include additional protos being defined in . The editors encourage feedback on this point. Because a peer address is validated during QUIC connection establishment as described in , when a RoQ endpoint uses ICE to communicate with another RoQ endpoint, an ICE agent will have already performed ICE candidate pair connectivity checking before a QUIC connection can be opened for use with RoQ. An implementer should be aware that it is possible for a RoQ connection to be subject to "ping"/liveness checks at several different levels:

• QUIC PING frames, as described in
• ICE keepalives, as described in and in
• ICE consent freshness, as described in
• RTCP packets, as described in

The following considerations are worth reviewing for implementers.

• QUIC PING frames are entirely under the control of an implementation. If a QUIC connection carries RTP/RTCP traffic, the RTCP transmission interval is likely to suffice for RTP liveness detection, but a wise implementer will look at this in their environment and proceed accordingly.
• ICE consent freshness, as described in , also serves the ICE keepalive function, so ICE keepalives are no longer necessary.
• At least some RTCP feedback might be unnecessary, as described in , so a wise implementer will look at what RTCP feedback can be replaced with QUIC feedback.

A QUIC/RTP/AVPF Offer Example Editor's Note: Spencer has been updating this example while working on the document, but we will need to review it carefully, before requesting Working Group Last Call. Note: contains no normative requirements. A complete example of an SDP offer using QUIC/RTP/AVPF might look like:

SDP line	Notes
Session Description
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
a=tls-id:abc3de65cddef001be82	As defined in
a=setup:passive	Will wait for QUIC handshake (setup attribute from
t=0 0	Same as
a=fingerprint:sha-1 47:5D:A9:48:E4:BA:44:D9:B5:BC:31:AB:4B:80:06:11:3F:D5:F5:38
Media Description
m=video 51372 QUIC/RTP/AVPF 99	As defined in
a=rtcp-mux	Will multiplex RTP and RTCP on the same port
a=roq-flow-id:4	RoQ Flow Identifier shall be 4 for streams described by this SDP media description
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 includes the necessary protos and attribute-names for RoQ SDP. This SDP offer might be included in a SIP INVITE, for example.

Security Considerations The security considerations sections of the Normative References used in this document are incorporated by reference. The reader is especially directed to the discussion of AV profile security considerations in .

IANA Considerations This document defines new IANA values in the and registries.

QUIC and QUIC-related protos This document defines these new SDP proto names.

Type	SDP Name	Reference
proto	QUIC	of this specification
proto	QUIC/RTP/AVP	of this specification
proto	QUIC/RTP/AVPF	of this specification
proto	QUIC/RTP/SAVP	of this specification
proto	QUIC/RTP/SAVPF	of this specification

roq-flow-id This document defines a new SDP attribute, "roq-flow-id".

Type	SDP Name	Usage Level	Mux Category	Reference
attribute	roq-flow-id	session, media	CAUTION	of this specification

References Normative References 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 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. Technical University of Munich Technical University of Munich Tencent America LLC This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). This document also discusses how to leverage state that is already available from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and describes different options for implementing congestion control and rate adaptation for RTP without relying on RTCP feedback. 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. 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 defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [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 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] 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. This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. Wonder Hamster Internetworking LLC Nokia This document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry that can be used to describe QUIC transport for RTP and RTCP packets, and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC as a transport protocol. These new values are necessary to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP and WebRTC. This document also contains non-normative guidance for implementers. 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] This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, "tls-id". This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. 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] This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. 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. Informative References 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 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). The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. 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. Alibaba Inc. Uber Technologies Inc. University of Mons (UMONS) UCLouvain and Tessares Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK] An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK] This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK] To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. Intel Tencent Fraunhofer HHI Bytedance Inc. Nokia Technologies This memo describes an RTP payload format for the Versatile Video Coding (VVC) specification, which was published as both ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3. VVC was 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.

Acknowledgments The authors thank Sam Hurst for sharing his thoughts about the challenges of developing SDP for RoQ, and for providing specific comments and draft text. The authors thank Mathis Engelbart for his feedback on this specification, and for helping to keep this this specification aligned with . The authors thank Bernard Aboba and Mathis Westerlund for comments on various previous versions of this specification, under a variety of draft names. The authors thank Jonathan Lennox and Harald Alvestrand for their feedback on this version of the specification. The authors thank Roman Shpount for helping us get the specification of "connection" and "tls-id" correct in our specification. A significant amount of work on this draft happened while Spencer was affiliated with Tencent America LLC. Spencer still appreciates that support.