Internet-Draft SDP O/A for RTP over QUIC October 2021
Dawkins Expires 28 April 2022 [Page]
Workgroup:
AVTCORE/MMUSIC Working Groups
Internet-Draft:
draft-dawkins-sdp-rtp-quic-questions-01
Published:
Intended Status:
Informational
Expires:
Author:
S. Dawkins
Tencent America LLC

SDP Offer/Answer for RTP using QUIC as Transport - Design Questions

Abstract

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

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.

Status of This Memo

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 28 April 2022.

Table of Contents

1. Introduction

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.

1.1. 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.

1.2. Scope of this document

[I-D.dawkins-sdp-rtp-quic] 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 [I-D.dawkins-sdp-rtp-quic].

2. 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.

2.1. Useful AVP Profiles

[SDP-parameters] contains four classes of AVP profiles:

  • RTP/AVP ("RTP Profile for Audio and Video Conferences with Minimal Control"), as defined in [RFC3551],
  • RTP/SAVP ("The Secure Real-time Transport Protocol (SRTP)"), as defined in [RFC3711],
  • RTP/AVPF ("Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"), as defined in [RFC4585], and
  • RTP/SAVPF ("Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"), as defined in [RFC5124].

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.

2.1.1. Can We Assume the Use of "Extended Audiovisual Profiles"?

We could register both AVP and AVPF profiles, but do we need to register both?

2.1.2. Is "Secure RTP Encapsulated in UDP" Equivalent to "RTP Encapsulated in QUIC"?

RTP that is encapsulated in QUIC payloads will always be encrypted [RFC9000]. 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?
2.1.2.1. 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.

2.1.3. Encapsulations in Datagrams and Streams

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.

2.2. 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 [RFC5761].
  • It seems useful to confirm that we can assume support for Media Multiplexing ("BUNDLE"), as described in [RFC8843].

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 Section 2.4.2 below. This section should be read with Section 2.4.2 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?

2.3. 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 ([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?

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 [RIST-Simple-Prof] 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, [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.

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.

3. IANA Considerations

This document makes no requests of IANA.

4. 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.

5. 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:

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

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

6. References

6.1. Normative References

[I-D.engelbart-rtp-over-quic]
Ott, J. and M. Engelbart, "RTP over QUIC", Work in Progress, Internet-Draft, draft-engelbart-rtp-over-quic-00, , <https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic-00>.
[I-D.hurst-quic-rtp-tunnelling]
Hurst, S., "QRT: QUIC RTP Tunnelling", Work in Progress, Internet-Draft, draft-hurst-quic-rtp-tunnelling-01, , <https://datatracker.ietf.org/doc/html/draft-hurst-quic-rtp-tunnelling-01>.
[I-D.ietf-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-datagram-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram-06>.
[I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-quic-http-34, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34>.
[I-D.rtpfolks-quic-rtp-over-quic]
Ott, J., Even, R., Perkins, C., and V. Singh, "RTP over QUIC", Work in Progress, Internet-Draft, draft-rtpfolks-quic-rtp-over-quic-01, , <https://datatracker.ietf.org/doc/html/draft-rtpfolks-quic-rtp-over-quic-01>.
[RFC3264]
Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, , <https://www.rfc-editor.org/rfc/rfc3264>.
[RFC3550]
Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, , <https://www.rfc-editor.org/rfc/rfc3550>.
[RFC3551]
Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, , <https://www.rfc-editor.org/rfc/rfc3551>.
[RFC3711]
Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, , <https://www.rfc-editor.org/rfc/rfc3711>.
[RFC4585]
Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, , <https://www.rfc-editor.org/rfc/rfc4585>.
[RFC4961]
Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, , <https://www.rfc-editor.org/rfc/rfc4961>.
[RFC5104]
Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, , <https://www.rfc-editor.org/rfc/rfc5104>.
[RFC5124]
Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, , <https://www.rfc-editor.org/rfc/rfc5124>.
[RFC5761]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, , <https://www.rfc-editor.org/rfc/rfc5761>.
[RFC7301]
Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC7728]
Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, , <https://www.rfc-editor.org/rfc/rfc7728>.
[RFC8082]
Wenger, S., Lennox, J., Burman, B., and M. Westerlund, "Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs", RFC 8082, DOI 10.17487/RFC8082, , <https://www.rfc-editor.org/rfc/rfc8082>.
[RFC8843]
Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, , <https://www.rfc-editor.org/rfc/rfc8843>.
[RFC8866]
Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, , <https://www.rfc-editor.org/rfc/rfc8866>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/rfc/rfc9001>.
[RIST-Simple-Prof]
"Reliable Internet Stream Transport (RIST) Protocol Specification – Simple Profile", , <https://vsf.tv/download/technical_recommendations/VSF_TR-06-1_2020_06_25.pdf>.
[SDP-parameters]
"SDP Parameters - Proto", , <https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2>.

6.2. Informative References

[I-D.dawkins-sdp-rtp-quic]
Dawkins, S., "SDP Offer/Answer for RTP using QUIC as Transport", Work in Progress, Internet-Draft, draft-dawkins-sdp-rtp-quic-00, , <https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic-00>.

Author's Address

Spencer Dawkins
Tencent America LLC
United States of America