]> Tencent America LLC

United States of America spencerdawkins.ietf@gmail.com

applications AVTCORE/MMUSIC Working Groups Internet-Draft QUIC RTP SDP This document is a companion document to "SDP Offer/Answer for RTP using QUIC as Transport". That document focuses on the description and registration of SDP "proto" attribute parameters with IANA, to allow applications that rely on SDP Offer/Answer to negotiate the QUIC protocol as an encapsulation for RTP. In writing that document, it became obvious that decisions about an appropriate SDP description would depend on decisions about the way RTP would be encapsulated in QUIC, and different proposals for those encapsulations had made different assumptions. Given that none of these proposals have been adopted by an IETF working group yet, it's not appropriate to try to base a general-purpose set of "QUIC/RTP" IANA registrations on any one of them, so this document includes the questions that have come up, and (as discussions progress) suggested answers for those questions. Discussion Venues Discussion of this document takes place on the "Media Over QUIC" non-working group mailing list (MOQ), which is archived at . Subscription information is at . Source for this draft and an issue tracker can be found at .

Introduction This document is a companion document to "SDP Offer/Answer for RTP using QUIC as Transport" (). That document focuses on the description and registration of SDP () "proto" attribute parameters with IANA (), to allow applications that rely on SDP Offer/Answer () to negotiate the QUIC protocol() as an encapsulation for RTP (). In writing that document, it became obvious that decisions about an appropriate SDP description would depend on decisions about the way RTP would be encapsulated in QUIC, and different proposals for those encapsulations (, , and ) had made different assumptions. Given that none of these proposals have been adopted by an IETF working group yet, it's not appropriate to try to base a general-purpose set of "QUIC/RTP" IANA registrations on any one of them, so this document includes the questions that have come up, and (as discussions progress) suggested answers for those questions.

Notes for Readers (Note to RFC Editor - if this document ever reaches you, please remove this section) This document is intended to stimulate discussion about how proponents of "RTP over QUIC" expect that to work, recognizing that not everyone has the same goals in mind, but it understanding what the choices are will likely be helpful in making those choices, especially when the results of a choice provide direction that will allow implementers to agree on strategies and reuse as much code as possible.

Scope of this document will almost certainly reflect answers to the questions contained in this document, but the discussion material in this document will not be appropriate for inclusion in a draft that focuses on SDP description and IANA registration. This document might be worth publishing on its own, but is primarily intended to guide discussion that will feed into .

Questions (and, Eventually, Answers) This version of this document is still very much a starting point for discussion, and additional questions are welcomed, even as we converge on answers.

Useful AVP Profiles contains four classes of AVP profiles:

• RTP/AVP ("RTP Profile for Audio and Video Conferences with Minimal Control"), as defined in ,
• 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 , and
• RTP/SAVPF ("Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"), as defined in .

We could register all four over QUIC, but if we can cut down on the number of options for implementers, we might achieve better interoperability.

Can We Assume the Use of "Extended Audiovisual Profiles"? We could register both AVP and AVPF profiles, but do we need to register both?

Is "Secure RTP Encapsulated in UDP" Equivalent to "RTP Encapsulated in QUIC"? RTP that is encapsulated in QUIC payloads will always be encrypted . So we could register (for example)

• QUIC/RTP/AVPF, knowing that any RTP payload using the QUIC protocol is encrypted, but is not encrypted using SDES, or
• QUIC/RTP/SAVPF, because QUIC encryption provides at least an equivalent level of protection to SDES, or
• both QUIC/RTP/AVPF and QUIC/RTP/SAVPF, to minimize the changes necessary for existing RTP applications to add support for QUIC encapsulation?

Proposed Answer We note that it is possible, and perhaps likely, that RTP-over-QUIC would be used in "mixed" environments, where one of the functions of an RTP mixer/translator is to connect RTP endpoints that are RTP-over-QUIC-enabled with RTP endpoints that are not. In this case, the only way to ensure encryption over every hop between two endpoints is to use one of the RTP profiles that includes security.

Encapsulations in Datagrams and Streams We note that contains registrations for both RTP encapsulated in UDP datagrams and RTP encapsulated in TCP streams. If we wanted to allow the same level of flexibility for QUIC/RTP, we could register (for example) QUIC/DGRAM/RTP, mapped onto QUIC datagrams (), and QUIC/STREAM/RTP, mapped onto QUIC streams (), reusing terminology from the Berkeley Sockets API. Should we do that? If so, starting out that way would be better than starting out with QUIC/RTP and then adding QUIC/STREAM/RTP later.

Useful Support For Existing RTP Extensions included in SDP Offer/Answer At least one of the goals for QUIC/RTP encapsulation is that QUIC/RTP applications would not require more UDP ports than existing RTP applications. For this reason,

• It seems useful to confirm that we can assume support for "Multiplexing RTP Data and Control Packets on a Single Port", as described in .
• It seems useful to confirm that we can assume support for Media Multiplexing ("BUNDLE"), as described in .

Editor's Note We recognize that the usage of RTP/RTCP ports in (for example) RTP/SAVPF, which runs over UDP, will be more nuanced in (for example) QUIC/RTP/SAVPF, which can use UDP ports in the same way as RTP/SAVPF, but can also use mechanisms such as Application-Layer Protocol Negotiation (ALPN) Protocol IDs to multiplex multiple applications on a single port, as further discussed in below. This section should be read with in mind. One possibility is that this discussion turns out to be about minimizing the need for more QUIC connections, which does translate directly to minimizing UDP ports. Are there other RTP extensions that we should assume support for?

Feedback Mechanisms RTP has relied on RTCP as its feedback mechanism for decades, as that mechanism has evolved over time, with the addition of AVPF feedback (), and subsequent extensions (for example, the codec control messages defined in and extended in and ). Should we assume that RTP applications using QUIC as their transport encapsulation will continue to use AVPF as the basis for feedback mechanisms, largely unchanged? It seems likely that many implementations that already utilize (S)AVPF as their feedback mechanisms will continue to do so for QUIC/RTP/AVPF sessions. These implementations already work, and continuing to use the same feedback mechanism for QUC/RTP/AVPF sessions will minimize the amount of new development and testing required for these implementations to add support for QUIC/RTP/AVPF. We also recognize that extends the RTP/AVPF bitmasked-based retransmission request with its own range-based retransmission request, as an indication that this feedback mechanism remains in the mainstream of RTP/RTCP protocol usage. However, proposes that QUIC/RTP implementations may not need to support some RTCP messages, if QUIC itself provides equivalent functionality. If there's not one answer to the feedback mechanism question, the necessary feedback mechanism will need to be included in the SDP Offer/Answer exchange.

Potential Extensions To QUIC and QUIC-related Specifications Because the topics in this section are speculative, it's not clear whether they would have any impact on SDP description and IANA registration in . They are included in this document for completeness.

QUIC Datagram Multiplexing does not provide support for a standardized datagram multiplexing identifier, for reasons described in Section 5.1, and at greater length in the Github issue about this (at https://github.com/quicwg/datagram/issues/6). The high-level explanation is that there was considerable support for adding a datagram multiplexing identifier to the datagram frame type, but much less agreement about what effect that identifier would have, and whether the QUIC transport layer would be responsible for any particular processing, or whether this processing would necessarily be performed by the application. For example, some proponents of adding datagram multiplexing expected to use multiplexing identifiers as ways of distinguishing between datagrams of different priorities, and other propoents expected to used multiplexing identifiers to distinquish between datagrams that were part of multi-datagram conversations (more like streams, but using the datagram frame types). Given that there was no agreement on the functionality that datagram multiplexer identifiers would be used for, or what requirements this addition to the protocol would place to QUIC transport processing, the best decision for the QUIC protocol seemed to be that any application that needed this capability could trivially add its own multiplexing identifiers at the beginning of the Datagram Data field (). In general, that's a fine plan. The question for this document is whether there is enough similarity among various applications using QUIC/RTP that specifying an RTP-specific datagram multiplier would provide better predictability and ability to multiplex datagrams from different applications without modifying those applications when they encounter each other for the first time.

RTP Destination Transport Addresses, Bundles, and QUIC Connection-IDs RTP has more than one way to identify endpoints, whether -style destination three-tuples, or -style Symmetric RTP and RTCP, or -style BUNDLE transport, but all are based on IP addresses and port addresses. The QUIC protocol also starts out with five-tuple awareness as it establishes a connection and performs TLS 1.3 handshake between the client and server, as described in , and performs path validation, as described in , but can also create multiple connection identifiers using different transport addresses that will be associated with the same connection, and when another path has been validated and associated with a known connection identifier, the QUIC endpoint can begin receiving packets for the same connection from an entirely different transport address, with no other signaling. This change of transport addresses might be the result of QUIC-level "connection migration", but might also be the result of NAT rebinding. Applications using QUIC/RTP will need some way of managing QUIC connection identifiers, rather than transport addresses. This points to at least one potential need for a mapping of RTP semantics over QUIC, equivalent to . If QUIC/RTP applications will be making use of something like Application Layer Protocol Negotiation (ALPN) () identifiers to select QUIC/RTP processing, as HTTP/3 does, this may point to another potential need for a mapping.

Support for NAT Traversal It's worth noting that the driving use cases for the first version of the IETF QUIC protocol have been for HTTP-based web access, where the capability described in Section 8.2 of was sufficient:

• Path validation is not designed as a NAT traversal mechanism. Though the mechanism described here might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one endpoint is able to receive packets without first having sent a packet on that path. Effective NAT traversal needs additional synchronization mechanisms that are not provided here.

Some existing RTP applications share this characteristic - at least one RTP endpoint can receive a packet without having previously sent packet on that path. For these applications, current QUIC functionality will be sufficient. For other RTP applications, we may need a QUIC extension that provides NAT traversal, and we may need to include information about NAT traversal in SDP Offer/Answer to enable QUIC/RTP communication.

IANA Considerations This document makes no requests of IANA.

Security Considerations This document is intended as the basis for discussion about protocol mechanisms that will be described in other documents. As a discussion paper, this document introduces no new security considerations, and any new security considerations resulting from those discussions should be included in the documents that actually describe protocol mechanisms.

Acknowledgments Thanks to these folks, for authoring various "QUIC over RTP" drafts for specific use cases, which included their understanding of SDP aspects of their proposals:

• Joerg Ott, Roni Even, Colin Perkins, and Varun Singh, authors of
• Sam Hurst, author of
• Joerg Ott and Mathis Engelbart, authors of

Thanks to these folks for helping to improve this draft by commenting, proposing text, or correcting confusion:

• Colin Perkins
• Richard Bradbury
• Stephan Wegner

(Your name also could appear here. Please comment and contribute, as described in "Contribution and Discussion Venues for this draft" above)

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 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] 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 document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] 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 describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found. 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. Apple Inc. Apple Inc. Google LLC This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/quicwg/ datagram (https://github.com/quicwg/datagram). 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. 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. QUIC is a UDP-based transport protocol for stream-orientated, congestion-controlled, secure, multiplexed data transfer. RTP carries real-time data between endpoints, and the accompanying control protocol RTCP allows monitoring and control of the transfer of such data. With RTP and RTCP being agnostic to the underlying transport protocol, it is possible to multiplex both the RTP and associated RTCP flows into a single QUIC connection to take advantage of QUIC features such as low-latency setup and strong TLS-based security. Technische Universitaet Muenchen Huawei University of Glasgow CALLSTATS I/O Oy QUIC is a UDP-based protocol for congestion controlled reliable data transfer, while RTP serves carrying (conversational) real-time media over UDP. This draft discusses design aspects and issues of carrying RTP over QUIC. Informative References Tencent America LLC 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.