Internet-Draft | SDP O/A for RTP over QUIC | September 2021 |
Dawkins | Expires 3 April 2022 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the "Media Over QUIC" non-working group mailing list (MOQ), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscription information is at https://www.ietf.org/mailman/listinfo/Moq/.¶
Source for this draft and an issue tracker can be found at https://github.com/SpencerDawkins/sdp-rtp-quic-questions.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 April 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document is a companion document to "SDP Offer/Answer for RTP using QUIC as Transport" ([I-D.dawkins-sdp-rtp-quic]). That document focuses on the description and registration of SDP ([RFC8866]) "proto" attribute parameters with IANA ([SDP-parameters]), to allow applications that rely on SDP Offer/Answer ([RFC3264]) to negotiate the QUIC protocol([RFC9000]) as an encapsulation for RTP ([RFC3550]).¶
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 ([I-D.engelbart-rtp-over-quic], [I-D.hurst-quic-rtp-tunnelling], and [I-D.rtpfolks-quic-rtp-over-quic]) 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.¶
(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.¶
[I-D.dawkins-sdp-rtp-quic] will necessarily reflect questions and answers contained in this document, but that discussion material 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, or some of its contents might might be included in one or more documents that describe RTP encapsulation in the QUIC protocol.¶
The -00 version of this document is very much a starting point for discussion, and this document will be updated as we converge on answers.¶
[SDP-parameters] contains four classes of AVP profiles:¶
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.¶
We could register both AVP and AVPF profiles, but do we need to register both?¶
RTP that is encapsulated in QUIC payloads will always be encrypted [RFC9000]. So, should we register (for example)¶
We note that [SDP-parameters] 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 ([I-D.ietf-quic-datagram]), and QUIC/STREAM/RTP, mapped onto QUIC streams ([RFC9000]), 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.¶
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,¶
Are there other RTP extensions that we can assume support for?¶
RTP has relied on RTCP as its feedback mechanism for decades, as that mechanism has evolved over time, with the addition of AVPF feedback ([RFC4585]), and subsequent extensions (for example, the codec control messages defined in [RFC5104] and extended in [RFC7728] and [RFC8082]).¶
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?¶
Perhaps some applications will do so.¶
However, [I-D.engelbart-rtp-over-quic] proposes that QUIC/RTP implementations may not need to support some RTCP messages, if QUIC itself provides equivalent functionality. Conversely, [RIST-Simple-Prof] extends the RTP/AVPF bitmasked-based retransmission request with its own range-based retransmission request.¶
If there's not one answer to that question, the choice among feedback mechanisms will need to be included in SDP Offer/Answer.¶
This document makes no requests of IANA.¶
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.¶
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:¶
Thanks to these folks for helping to improve this draft by commenting, proposing text, or correcting my confusion:¶
(Your name also could appear here. Please comment and contribute, as described in "Contribution and Discussion Venues for this draft".).¶