本备忘录的状态

本互联网草案的提交完全符合 BCP 78 和 BCP 79 的规定

Internet-Drafts 是 Internet 工程任务组 (IETF) 的工作文件。请注意，其他小组也可以将工作文档作为 Internet-Drafts 分发。当前 Internet-Drafts 列表位于https://datatracker.ietf.org/drafts/current/。

Internet-Drafts 是有效期最长为六个月的草稿文件，可以随时被其他文件更新、替换或作废。将 Internet-Drafts 用作参考材料或引用它们而不是“正在进行的工作”是不合适的。

本互联网草案将于 2022 年 4 月 28 日到期

版权声明

版权所有 (c) 2021 IETF Trust 和文件作者。版权所有。

本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 ( https://trustee.ietf.org/license-info ) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。

目录

一、简介

实时传输协议 (RTP) [ RFC3550 ]通常用于在 Internet 上传输会话媒体会话（例如视频会议）的实时媒体。由于 RTP 需要实时传输并且可以容忍数据包丢失，默认的底层传输协议是 UDP，最近在顶部使用 DTLS 来保护媒体交换，偶尔使用 TCP（可能还有 TLS）作为后备。随着 QUIC 的出现，尤其是其不可靠的 DATAGRAM 扩展，另一种安全传输协议变得可用。QUIC 及其 DATAGRAM 将实时流量的理想特性（例如，没有不必要的重传、避免线头阻塞）与安全的端到端传输相结合，该传输也有望通过 NAT 和防火墙很好地工作。

此外，借助 QUIC 的多路复用功能，可以建立可靠和不可靠的传输连接，例如，WebRTC 所需的传输连接，只要在连接的任一端使用一个端口即可。本文档定义了如何在 QUIC 上承载 RTP 的映射。重点是 RTP 和 RTCP 数据包映射，以及通过利用 QUIC 端点中随时可用的状态信息来减少 RTCP 流量。本文档还简要介绍了如何使用会话描述协议 (SDP) [ RFC8866 ]通过 QUIC 向媒体发送信号。

本文档的范围仅限于单播 RTP/RTCP。

请注意，该草案在精神上与[ QRT ]相似但在许多方面有所不同 。

2.术语和符号

关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时，本文档中的 " 将按照 BCP 14 [ RFC2119 ] [ RFC8174 ]中的描述进行解释 ，如此处所示。

使用以下术语：

拥塞控制器：

QUIC 在[ RFC9002 ]的第 7 节中指定了拥塞控制器，但是交互式实时媒体的特定要求导致了专用拥塞控制算法的开发。本文档中的术语拥塞控制器指的是专用于实时应用程序的这些算法，可以在[ RFC9002 ]中指定的拥塞控制器旁边或代替拥塞控制器使用。

数据报：

数据报存在于 UDP 以及 QUIC 的不可靠数据报扩展中。如果没有明确指出，本文档中的术语数据报是指 [ QUIC-DATAGRAM ]中定义的 QUIC 数据报。

端点：

参与 RTP over QUIC 会话的 QUIC 服务器或客户端。

框架：

[ RFC9000 ]中定义的 QUIC 帧。

媒体编码器：

应用程序用来生成编码媒体流的实体，可以将其打包成 RTP 数据包以通过 QUIC 传输。

接收者：

接收 RTP 数据包中的媒体并可以发送或接收 RTCP 数据包的端点。

发件人：

端点以 RTP 数据包的形式发送媒体，并且可以发送或接收 RTCP 数据包。

本文档中的数据包图使用[ RFC9000 ]的第 1.3 节中定义的格式来说明字段的顺序和大小。

3.协议概述

本文档介绍了实时传输协议 (RTP) 到 QUIC 传输协议的映射。QUIC 支持两种传输方法：可靠流和不可靠数据报 [ RFC9000 ]、[ QUIC-DATAGRAM ]。RTP over QUIC 使用不可靠的 QUIC 数据报来传输实时数据。

[ RFC3550 ]指定 RTP 会话需要在不同的传输地址上传输，以允许它们之间的多路复用。RTP over QUIC 使用不同的方法，以便利用 QUIC 连接的优势，而无需为每个 RTP 会话管理单独的 QUIC 连接。QUIC 不提供数据报上不同流之间的多路分解，但建议应用程序在需要时实现多路分解机制。这种机制的一个例子是附加到每个数据报帧的流标识符，如[ H3-DATAGRAM ]中所述。RTP over QUIC 使用流标识符作为网络地址和端口号的替代品，通过同一 QUIC 连接多路复用多个 RTP 会话。

可以插入拥塞控制器，以使媒体比特率适应可用带宽。本文档不强制要求任何拥塞控制算法，一些示例包括网络辅助动态自适应 (NADA) [ RFC8698 ]和多媒体自时钟速率自适应 (SCReAM) [ RFC8298 ]. 这些拥塞控制算法需要一些关于网络性能的反馈，以便计算目标比特率。传统上，此反馈在接收方生成并通过 RTCP 发送回发送方。由于 QUIC 还收集有关网络性能的一些指标，这些指标可用于在发送方生成所需的反馈并将其提供给拥塞控制器，以避免 RTCP 流的额外开销。

• 编者按：拥塞控制器是否应该独立于 QUIC 中使用的拥塞控制器工作，因为 QUIC 连接可以同时用于其他需要拥塞控制的数据流？

4.本地接口

RTP over QUIC 需要不同的组件（如 QUIC 实现、拥塞控制器和媒体编码器）协同工作。这些组件的接口必须满足本节中描述的某些要求。

5.数据包格式

所有 RTP 和 RTCP 数据包必须以 QUIC 数据报帧的形式发送，格式如下：

数据报负载 {
  流标识符 (i),
  RTP/RTCP 数据包 (..)
}

对于在同一 QUIC 连接上多路复用 RTP 会话，每个 RTP/RTCP 数据包都以流标识符为前缀。此流标识符可替代每个会话使用不同的传输地址。流标识符是一个 QUIC 可变长度整数，每个流必须是唯一的。

单个 RTP 会话的 RTP 和 RTCP 数据包可以使用相同的流标识符发送（遵循[ RFC5761 ]中定义的程序，或者它们可以使用不同的流标识符发送。必须使用适当的信令指示各自的操作模式，例如，当使用第 7 节中讨论的 SDP时

不同 RTP 会话的 RTP 和 RTCP 数据包必须使用不同的流标识符发送。

通过适当使用流标识符和相应的信令，将不同 RTP 会话的 RTP/RTCP 数据报与非 RTP/RTCP 数据报区分开来是应用程序的责任。

发送者应该考虑与 QUIC 数据报相关的报头开销，并确保 RTP/RTCP 数据包（包括其有效负载、QUIC 和 IP 报头）适合路径 MTU。

6.协议操作

本节介绍发送方和接收方如何使用 QUIC 交换 RTP 和 RTCP 数据包。虽然接收方非常简单，但发送方必须跟踪发送的数据包和相应的确认以实现拥塞控制。

提交给 RTP over QUIC 实现的 RTP/RTCP 数据包缓存在队列中。拥塞控制器定义下一个数据包出列并通过 QUIC 连接发送的速率。在发送数据包之前，它会以 第 5 节中描述的流标识符为前缀，并封装在 QUIC 数据报中。

实现必须跟踪发送的 RTP 数据包，以便为第 4.2 节中描述的拥塞控制器构建反馈。每个发送的 RTP 数据包都映射到通过 QUIC 发送它的数据报。当 QUIC 实现发出对特定数据报的确认信号时，在该数据报中发送的数据包被标记为已接收。与接收到的标记一起，可以存储对等点接收数据包的延迟估计。假设 RTT 在从发送方到接收方的链路和返回到发送方的链路之间平均分配，可以通过将latest_rtt除以 2 与发送 RTP 数据包的数据报的发送时间相加来计算该估计值。此映射稍后可用于创建pkt_status_list和pkt_delay_list如 第 4.2 节所述。

在一个固定的时间间隔内，pkt_status_list和pkt_delay_list必须与当前时间戳t_current和 RTT 统计信息 一起传递给拥塞控制器min_rtt，smoothed_rtt和rtt_var。如果可用，反馈也可以包含 ECN 标记。

反馈报告可以以所使用的算法指定的频率传递给拥塞控制器。

拥塞控制器定期输出，使用第 4.3 节target_bitrate中描述的接口将其转发给编码器。

+------------+ 媒体 +-------------+
| 编码器|------->| 应用 |
| | | |
+------------+ +-------------+
      ^ |
      | |
      | 设置 RTP/ |
      | 目标 RTCP |
      | 比特率 |
      | v 目标
      | +-------------+ 比特率 +-------------+
      +---------------| RTP 超过 |<----------| 拥堵 |
                      | 快速 | 反馈 | 控制器 |
                      +-------------+--------->+--------------+
                           | ^
                   流量 ID | | 数据报
                  前缀 | | 确认/丢失-
                  RTP/RTCP | | 通知
                   数据包| | +
                           | | RTT
                           v |
                      +--------------+
                      | 快速 |
                      | |
                      +--------------+

在接收到数据报时，RTP over QUIC 实现剥离并解析流标识符以识别接收到的 RTP 或 RTCP 数据包所属的流。然后将数据报的剩余内容传递给分配给定流标识符的 RTP 会话。

7. SDP 信令

QUIC 是一种基于连接的协议，支持在已建立的连接内无连接传输 DATAGRAM 帧。如上所述，为不同目的解复用 DATAGRAMS 取决于使用 QUIC 的应用程序。

有几个必要的步骤可以在通信对等方之间联合执行以启用 RTP over QUIC：

1. m= 行的协议标识符必须是“QUIC/RTP”，根据[ RFC8866 ] 与相应的视听配置文件组合：例如，“QUIC/RTP/AVP”。
2. 对等点需要决定是建立新的 QUIC 连接还是重用现有的连接。在建立新连接的情况下，需要确定发起者和响应者（客户端和服务器）。此步骤的信令必须遵循[ RFC8122 ] 关于面向连接媒体的 SDP 属性的 a=setup、a=connection 和 a=fingerprint 属性。他们必须按照 1 使用适当的协议标识。

3. 对等点必须提供一种方法来识别 QUIC DATAGRAMS 中携带的 RTP 会话。为了首先为一个、两个或多个媒体会话启用公共传输连接，必须使用 BUNDLE 分组框架[ RFC8843 ]。属于一个捆绑组的所有媒体部分，除了第一个，必须将 m= 行中的端口设置为零，并且必须包括 a=bundle-only 属性。

   为了区分不同的 RTP 会话，需要为每个 m= 行提供参考，以允许将此特定媒体会话与流标识符相关联。这可以通过不同的方法来实现：

   • 只需重用 a=extmap 属性[ RFC8285 ]并依靠 RTP 标头扩展来解复用 QUIC DATAGRAM 帧中携带的不同媒体数据包。
   • 定义 a=extmap 属性[ RFC8285 ]的变体或不同风格，将媒体会话绑定到 QUIC DATAGRAMS 中使用的流标识符。

   • 编者注：使用 QUIC DATAGRAM 流标识符的多路复用可能更可取，因为这种多路复用机制也适用于 RTP 和非 RTP 媒体流。

   在任何一种情况下，必须为每个传输方向独立处理相应的标识符，以便端点可以选择自己的标识符，并且只使用 SDP 通知其对等方哪些 RTP 会话使用哪些标识符。

   为此，必须使用 SDP 来指示不同 RTP 会话的 RTP 和 RTCP 各自的流标识符（我们从[ RFC3605 ]中汲取灵感）。

4. 对于每个 RTP 会话，对等点必须同意是否应用 RTP/RTCP 多路复用。如果复用 RTP 和 RTCP 将发生在相同的流标识符上，则必须使用属性 a=rtcp-mux 来指示。

一个示例会话设置报价（从[ RFC8843 ]和[ RFC8122 ]自由借用和扩展 可能如下所示：

v=0
o=爱丽丝 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=组：捆绑 abc xyz

m=音频 10000 QUIC/RTP/AVP 0 8 97
a=设置：actpass
a=连接：新
a=指纹：SHA-256 \
 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:\
 3E:5D:49:6B:19:E5:7C:AB:4A:AD
b=AS:200
a=中：abc
a=rtcp 多路复用器
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:<tbd>

m=视频 0 QUIC/RTP/AVP 31 32
b=AS:1000
a=仅捆绑
a=中：酒吧
a=rtcp 多路复用器
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:<tbd>

信号细节待制定。

8.使用的 RTP/RTCP 数据包类型

任何 RTP 数据包都可以通过 QUIC 发送，默认情况下不使用 RTCP 数据包。由于 QUIC 已经包含了一些通常由某些 RTCP 消息实现的特性，因此 RTP over QUIC 实现不需要实现以下 RTCP 消息：

• PT=205, FMT=1, Name=Generic NACK：提供否定确认[ RFC4585 ]。QUIC 连接已经提供了确认和丢失通知。
• PT=205，FMT=8，Name=RTCP-ECN-FB：提供 RTCP ECN 反馈[ RFC6679 ]。如果支持，ECN 可以直接被使用的 QUIC 实现公开。
• PT=205，FMT=11，Name=CCFB：RTP 拥塞控制反馈，其中包含每个接收到的数据包的接收标记、时间戳和 ECN 通知[ RFC8888 ]。这可以从 QUIC 中推断出来，如第 6 节所述。
• PT=210, FMT=all, Name=Token, [ RFC6284 ]指定了一种为 RTP 接收器动态分配端口的方法。由于 QUIC 连接自己管理端口，因此 RTP over QUIC 不需要这样做。

9.增强功能

QUIC 收集的 RTT 统计数据可能不是很精确，因为它可能会受到延迟 ACK 的影响。RTT 的替代方案是明确测量单向延迟。[ QUIC-TS ]建议对 QUIC 进行扩展，以使用特殊 QUIC 帧中携带的时间戳实现单向延迟测量。新帧携带发送数据包的时间。接收器可以使用此时间戳来估计单向延迟，即接收到数据包的时间与接收到的数据包中的时间戳之间的差异。然后可以使用单向延迟替代从 RTT 推导出的接收时间估计，如 第 6 节所述，以创建pkt_delay_list. 

• 编者注：即使使用单向延迟测量，仍然无法确定单个数据包的确切时间戳，因为时间戳可能与确认多个较早数据包的 ACK 一起发送。

10.讨论

11.安全注意事项

待定

12. IANA 注意事项

本文档没有 IANA 操作。

致谢

TODO 确认。

作者地址