]> Tencent America LLC

United States of America spencerdawkins.ietf@gmail.com

applications AVTCORE Working Group Internet-Draft QUIC RTP SDP This document is intended to capture SDP aspects of RTP over QUIC design issues that have arisen, been discussed by the AVTCORE working group, and have reached a resolution that can be included in "SDP Offer/Answer for RTP using QUIC as Transport". 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. "SDP Offer/Answer for RTP using QUIC as Transport" is itself a companion document to "RTP over QUIC", and follows the lead of the latter specification as it evolves.

Introduction This document is intended to capture SDP () aspects of RTP () over QUIC () design issues that have arisen, been discussed by one or more IETF working groups, and have reached a resolution that can be included in "SDP Offer/Answer for RTP using QUIC as Transport" . 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 (). "SDP Offer/Answer for RTP using QUIC as Transport" () is itself a companion document to "RTP over QUIC" (), and follows the lead of follows the lead of the latter specification as it evolves.

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. The author learned through some experience that it would be really good to collect questions and design issues about "RTP over QUIC", or even "Media Over QUIC", in one place, because trying to track what was being discussed in multiple and partially overlapping venues was a recipe for brain damange, especially when a topic would come up under the "Media Over QUIC" banner, and then seem to be useful for "RTP over QUIC", so potentially signaled in SDP. This document is intended to keep at least one person sane. If it keeps more than one person sane, I've made the world a slightly better place.

Relationship with other documents will reflect answers to the questions contained in this document, but the discussion material in this document would 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 .

Discussion and Contribution Venues for this draft. (Note to RFC Editor - if this document ever reaches you, something has gone terribly wrong. Please notify your local IESG for guidance) With the concurrence of the AVTCORE and MMUSIC working group co-chairs, SDP aspects of RTP over QUIC protoposals 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. Design issues relevant for may arise in a variety of venues. At this time, AVTCORE is actively considering adoption of "RTP over QUIC" (), so this document will reflect those issues, but protocol specifications adopted by any other IETF working group relying on RTP-over-QUIC connections that are established using SDP would also be a candidate to be tracked. Readers are 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-issues. The direct link to the list of issues is https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues.

Design Issues Resolutions Ready to be Reflected in These issues can be found in https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues, by looking for the label "Solution Proposed".

What AVP Profiles to Register This design issue was surprisingly difficult to resolve. The first design choice was between

• Registering only "insecure" AVP profiles, such as "QUIC/RTP/AVPF", because "secure AVP profiles, such as "QUIC/RTP/SAVPF", mean that the RTP payloads are encrypted using "Secure Real-time Transport Protocol (SRTP)" (), which isn't necessary because RTP over QUIC payloads will already be encrypted by QUIC, and
• Also registering "secure" AVP profiles, such as "QUIC/RTP/SAVPF", for various reasons, including
  • allowing endpoints to use "double encryption", using both SRTP and QUIC to encrypt the RTP payload, in use cases where that is valuable
  • giving RTP middleboxes () a hint, to middleboxes that they should use SRTP when they forward RTP-over-QUIC packets to non-RTP-over-QUIC endpoints.

Key points made during this discussion were

• We understand that it is possible to do double encyption using SRTP over QUIC, but we haven't found any use cases where that's required (yet).
• Double encyption increases processing overhead, and adds 10 bytes of overhead (since there are two HMACs)
• If use cases that require double encryption are identified in the future, the appropriate AVP profiles can be registered with IANA at that time, to address non-theoretical requirements.
• Using secure AVP profiles when the RTP-over-QUIC payloads are not, in fact, encrypted by SRTP, as a hack to signal intent that middleboxes forwarding RTP-over-QUIC payloads to non-RTP-over-QUIC endpoints should use SRTP encryption is bogus, and isn't likely to be sufficient to handle all of the multi-endpoint topologies described in .

Note:

After working group discussions at IETF 113, one more observation popped up - that if our goal is to register QUIC/RTP/AVPF, we should actually be registering UDP/QUIC/RTP/AVPF, registration of other QUIC/RTP AVP profiles that aren't running over UDP.

After investigation, I don't think this is necessary unless QUIC is also defined to run over TCP, and even then, only if (say) TCP/QUIC/RTP/AVPF is considered to be a viable protocol stack for RTP usage.

Proposal to be implemented in draft-dawkins-avtcore-sdp-rtp-quic We will register QUIC/RTP/AVPF, and await further non-theoretical requirements to register other profiles (But see ).

QUIC Streams, QUIC Datagrams, or both? Discussion of this issue centered on whether people were getting support for a model they plan to use, rather than preventing other people from using a model they did not plan to use. After that became clear, and after added support for both streams and datagrams, everything became clear.

Proposal to be implemented in draft-dawkins-avtcore-sdp-rtp-quic Registered QUIC/RTP proto values will contain parallel registrations that include "stream" and "dgram". For instance, if we intend to register QUIC/RTP/AVPF, we will actually register QUIC/stream/RTP/AVPF and QUIC/dgram/RTP/AVPF,

Design Issue Resolutions Under Discussion in IETF Working Groups These issues can be found in https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues, by looking for the label "Presented to Working Group" and/or "Mailing List".

Design Issue "Parking Lot", for Design Issues That Have Not Been Discussed These issues can be found in https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues, by looking for issues with no labels.

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 the following folks who have contributed interesting questions and even more interesting suggested text proposals. These folk include Bernard Aboba, Colin Perkins, Justin Uberti, Martin Thomson, Richard Bradbury, Roman Shpount, Ross Finlayson, Sergio Garcia Murillo, Suhas Nandakumar, Tolga Asveren (Your name also could appear here. You are invited to comment and contribute, as described in "Contribution and Discussion Venues for this draft" above)

References Normative References 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. Source for this draft and an issue tracker can be found at https://github.com/mengelbart/rtp-over-quic-draft. 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 such as SIP and WebRTC that commonly use SDP as a session signaling protocol to set up RTP connections. 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 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] 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 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 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.