跳到主要内容

7. 速率悬殊的流的 RTCP 考虑

RTP 会话有一组用于配置会话带宽的参数. 这些参数是 RTCP 发送方和接收方份额 (例如 SDP 的 "b=RR:" 和 "b=RS:" 行 [RFC3556]) 以及 RTP/AVPF 配置文件 [RFC4585] 的参数 (例如 trr-int), 如果使用了该配置文件 (或其安全扩展 RTP/SAVPF [RFC5124]) 的话. 因此, 在随机化之前的基础 RTCP 报告间隔对于 RTP 会话中的每个发送 SSRC 都是相同的. 类似地, RTP 会话中的每个接收 SSRC 也将具有相同的基础报告间隔, 尽管这可能与发送 SSRC 所选择的报告间隔不同. 这种对所有 SSRC 都一致的 RTCP 报告间隔可能导致 RTCP 报告的发送频率高于或低于对某个 RTP 流而言理想的频率.

例如, 考虑一个以每秒几十千比特发送的音频流与一个多兆比特的高质量视频流复用到同一个 RTP 会话中的场景. 如果会话带宽是基于视频发送速率配置的, 并使用默认的 RTCP 带宽份额 (会话带宽的 5%), 那么 RTCP 带宽很可能超过音频发送速率. 如果在会话中随后使用 [RFC3550] 第 6.2 节所述的缩减最小 RTCP 间隔 (对于希望对受损 I 帧快速反馈的视频而言这是合适的), 那么所有发送方一致的报告间隔可能意味着音频源被要求发送 RTCP 包的频率高于它们发送音频数据包的频率. 这种带宽失配可以通过仔细调整 RTCP 参数 (尤其是在使用 RTP/AVPF 配置文件时的 trr_int) 来减小, 但无法完全避免, 因为它内在于 RTCP 定时规则的设计之中, 并影响所有包含带宽严重失配的流的 RTP 会话.

不同的媒体速率或期望的 RTCP 行为也可能出现在承载相同媒体类型的 SSRC 之间. 多方会议中一个常见的情况是, 少数视频流以高分辨率显示, 而其他视频流以低分辨率缩略图显示, 哪个以高分辨率显示由语音活动控制. 这里的差异既在于实际媒体速率, 也在于可能需要哪些反馈消息. 可能存在的其他差异示例源于媒体源的预期用途. 会议中承载发言者视频的媒体源与文档摄像头不同. 在这种情况下可能不同的基本参数包括帧率、可接受的端到端时延以及图像的信号噪声比 (Signal-to-Noise Ratio, SNR) 保真度. 这些差异不仅影响所需的比特率, 还影响可能的传输行为、可用的修复机制、控制与修复需要哪些反馈消息、对这些反馈消息的传输要求, 以及对 RTP 流传输的监测. 还可能存在其他类似的场景.

在单个 RTP 会话中发送多种媒体类型, 会使该会话包含比每种媒体类型在单独 RTP 会话中发送时更多的 SSRC. 例如, 如果两个参与者各自在单个 RTP 会话中发送一个音频和一个视频 RTP 流, 该会话将包含四个 SSRC; 但如果音频和视频使用了单独的 RTP 会话, 那么这两个 RTP 会话各自将只包含两个 SSRC. 因此, 在一个 RTP 会话中发送多个 RTP 流会增加 SSRC 之间的交叉报告量, 因为每个 SSRC 都会报告会话中的所有其他 SSRC. 这会增加 RTCP 报告的大小, 使其发送频率低于在给定 RTCP 带宽下使用单独 RTP 会话时的情形.

最后, 当 RTP 会话包含多种媒体类型时, 重要的是要注意所使用的 RTCP 接收质量报告、反馈消息和扩展报告块可能并不适用于所有媒体类型. 端点需要考虑每个 SSRC 的媒体类型, 并且只发送或处理适用于该特定 SSRC 及其媒体类型的报告和反馈. 在表明某组特定的 RTCP 报告或反馈消息仅适用于 RTP 会话中某种特定媒体类型方面, 信令方案可能存在不足.

因此, 从 RTCP 的角度来看, 可以看出为每个媒体源使用单独的 RTP 会话比在单个 RTP 会话中发送多个媒体源更有优势. 然而, 这些优势常常被减少端口使用、便于 NAT/防火墙穿越的需求所抵消, 而后者是通过将媒体源合并到单个 RTP 会话中实现的. 以下各节更详细地考虑在具有多个媒体源的会话中使用 RTCP 的一些问题.

7.1. 使 SSRC 超时​

在一个 RTP 会话中发送多个 RTP 流时, 已发现使 SSRC 值超时方面存在各种问题.

7.1.1. RTP/AVPF T_rr_interval 参数的问题​

RTP/AVPF 配置文件包含一种防止常规 RTCP 报告发送过于频繁的方法. 该机制描述于 [RFC4585] 第 3.5.3 节; 它由 T_rr_interval 参数控制. 其工作方式如下. 当发送一个常规 RTCP 报告时, 会生成一个新的随机值 T_rr_current_interval, 它在 T_rr_interval 的 0.5 到 1.5 倍范围内均匀抽取. 如果要发送的常规 RTCP 包早于上一个常规 RTCP 包之后 T_rr_current_interval 秒, 并且没有需要发送的反馈消息, 则该常规 RTCP 包被抑制, 并调度下一个常规 RTCP 包. T_rr_current_interval 在每次发送常规 RTCP 包时重新计算. 抑制的好处是, 在没有需要频繁 RTCP 传输的情况下避免浪费带宽, 同时在需要反馈时仍允许利用所配置的带宽.

遗憾的是, 与常规 RTCP 报告间隔相比, 这种抑制机制会使 RTCP 发送间隔的分布发生偏斜. 标准 RTCP 定时规则 (包括重新考虑和补偿因子) 使得发送 RTCP 包之间的间隔分布偏向区间 [0.5/1.21828, 1.5/1.21828]*Td 的上端, 其中 Td 是确定性计算出的 RTCP 报告间隔. 当 Td = 5 秒时, 该分布覆盖区间 [2.052 秒, 6.156 秒]. 相比之下, RTP/AVPF 抑制规则作用在 T_rr_interval 的 0.5 到 1.5 倍的区间内; 当 T_rr_interval = 5 秒时, 即 [2.5 秒, 7.5 秒].

其效果是, 使用 T_rr_interval 抑制时, 连续 RTCP 包之间的时间可能变得很大. 在使用 T_rr_interval 时, 发送一个常规 RTCP 包到下一个常规 RTCP 包之间的最大时间间隔出现在 T_rr_current_interval 取其最大值、且在抑制期结束时抑制了一个常规 RTCP 包、然后下一个常规 RTCP 包在其最大可能报告间隔之后被调度的情况下. 取两个间隔的最坏情况, 两个 RTCP 报告之间的最大时间为 1.5T_rr_interval + 1.5/1.21828Td.

当 Td 和 T_rr_interval 取值相同时, 这种行为可能令人意外. 也就是说, 当 T_rr_interval 被配置为与常规 RTCP 报告间隔相匹配时. 在这种情况下, 人们可能期望常规 RTCP 包按通常的时间表发送, 而反馈包可以提前发送. 然而, 上述问题导致 RTCP 包实际上以高度非均匀的分布发送在区间 [0.5Td, 2.731Td] 内, 而不是区间 [0.41Td, 1.23Td]. 这也许是出乎意料的, 但本身并不是问题. 然而, 当与丢包结合时, 它就引出了过早超时的问题.

7.1.2. 避免过早超时​

在 RTP/AVP [RFC3550] 中, 超时行为很简单; 它是 5 倍的 Td, 其中 Td 是使用 5 秒的 Tmin 值计算出来的. 换言之, 如果所配置的 RTCP 带宽允许平均 RTCP 报告间隔短于 5 秒, 则超时为该 SSRC 在 25 秒内没有活动 (RTP 或 RTCP); 否则, 超时为 5 个平均报告间隔.

RTP/AVPF [RFC4585] 引入了取决于 T_rr_interval 值的不同超时行为. 当 T_rr_interval 为 0 时, 它使用与 RTP/AVP 相同的超时计算. 然而, 当 T_rr_interval 非零时, 它在超时计算中替换 Tmin, 很可能是为了加快检测超时的 SSRC. 然而, 使用非零的 T_rr_interval 对 RTP 行为有两个后果.

第一, 由于抑制, 非活动 RTP 发送方所发送的 RTP 和 RTCP 包数量可能变得非常少, 这是因为第 7.1.1 节所讨论的问题. 由于 RTCP 包间隔可长达 2.73Td, 在 5Td 的时间段内, 端点实际上可能只发送一个 RTCP 包. 长间隔导致 RTCP 包更少, 以至于单个 RTCP 包丢失有时就可能导致某个 SSRC 超时.

第二, RTP/AVPF 对超时规则的修改降低了对错误配置的健壮性. 常见做法是配置 RTP/AVPF 使其能够频繁发送 RTCP 包以允许快速反馈; 然而, 这会使超时对 T_rr_interval 非常敏感. 例如, 如果配置了两个 SSRC, 一个 T_rr_interval = 0.1 秒, 另一个 T_rr_interval = 0.6 秒, 那么当后者停止发送 RTP 包时, 这一微小差异将导致 T_rr_interval 较短的 SSRC 将另一个判定为超时, 因为另一个的 RTCP 报告间隔超过其自身的五倍. 当使用 RTP/AVP 或 T_rr_interval = 0 的 RTP/AVPF 时, 这不是问题, 因为超时时间将为 25 秒, 并且所配置 RTCP 带宽之间的差异只有在报告间隔大于 5 秒且相差五倍时才会导致过早超时. 为限制此类有问题的错误配置的影响范围, 我们在第 7.1.4 节中定义了 RTP/AVPF 超时规则的更新.

7.1.3. RTP/AVP 与 RTP/AVPF 之间的互操作性​

如果在单个 RTP 会话中混合了实现 RTP/AVP 和 RTP/AVPF 配置文件 (或其安全变体) 的端点, 并且 RTP/AVPF 端点使用了明显低于 5 秒的非零 T_rr_interval, 那么由于它们不同的 RTCP 超时规则, RTP/AVPF 端点有可能过早地将 RTP/AVP 端点的 SSRC 判定为超时. 反之, 如果 RTP/AVPF 端点使用的 T_rr_interval 明显大于 5 秒, 那么 RTP/AVP 端点有可能将 RTP/AVPF 端点的 SSRC 判定为超时.

不建议 (NOT RECOMMENDED) 在单个 RTP 会话中混合使用两种不同 RTP 配置文件的端点. 然而, 如果混合使用了 RTP 配置文件, 并且 RTP/AVPF 端点未更新为遵循本备忘录第 7.1.4 节, 那么应当 (SHOULD) 将 RTP/AVPF 会话配置为使用 T_rr_interval = 4 秒, 以避免过早超时.

为互操作性而选择 T_rr_interval = 4 秒可能看起来奇怪. 直观上, 这个值应当是 5 秒, 以使 RTP/AVP 和 RTP/AVPF 都使用相同的超时时间. 然而, 第 7.1.1 节所述的行为表明, 实际的 RTP/AVPF 报告间隔可能比预期的更长. 将 T_rr_interval 设为 4 秒可使实际 RTCP 间隔接近 RTP/AVP 所期望的间隔, 从而确保互操作性.

7.1.4. 更新的 SSRC 超时规则​

为确保互操作性并避免过早超时, RTP 会话中的所有 SSRC 必须 (MUST) 使用相同的超时行为. 然而, 先前的规范在这方面并不一致. 为避免互操作性问题, 本备忘录按如下方式更新超时规则:

  • 对于 RTP/AVP、RTP/SAVP、RTP/AVPF 和 RTP/SAVPF 配置文件, 超时间隔应 (SHALL) 使用确定性 RTCP 报告间隔的五倍作为乘数来计算. 也就是说, 超时间隔应 (SHALL) 为 5*Td.
  • 对于 RTP/AVP、RTP/SAVP、RTP/AVPF 和 RTP/SAVPF 配置文件, 仅为计算参与者超时之目的, Td 的计算应 (SHALL) 使用 5 秒的 Tmin 值, 而不是缩减后的最小间隔, 即使计算 RTCP 包传输间隔时使用的是缩减最小间隔.

当 T_rr_interval != 0 时, 这改变了 RTP/AVPF 或 RTP/SAVPF 配置文件的行为. 具体而言, [RFC4585] 第 3.5.4 节的第一段被更新为: 对 RTP/AVPF 实体的超时计算使用 Tmin 而不是 T_rr_interval.

7.2. 调整 RTCP 传输​

本小节讨论可以做哪些调整来减少共享 RTCP 包间隔的缺点. 首先列出 RTP/AVP [RFC3551] 配置文件有哪些可能性, 然后列出 RTP/AVPF [RFC4585] 提供的额外工具.

7.2.1. RTP/AVP 和 RTP/SAVP​

在使用 RTP/AVP 或 RTP/SAVP 配置文件时, 调整 RTCP 报告间隔的选项仅限于 RTCP 发送方和接收方带宽, 以及是否根据带宽对最小 RTCP 间隔进行缩放. 由于调度算法同时包含随机化和重新考虑, 人们不能简单地用 [RFC3550] 第 6.3.1 节给出的 Td 公式来计算期望的平均传输间隔. 然而, 通过考察该表达式的输入以及随机化和重新考虑规则, 我们可以开始理解 RTCP 传输间隔的行为.

让我们从一些基本观察开始:

  1. 除非使用缩放后的最小 RTCP 间隔, 否则在随机化和重新考虑之前, Td 永远不会小于 Tmin. Tmin 的默认值是 5 秒.
  2. 如果使用缩放后的最小 RTCP 间隔, Td 可以低至 360 除以以千比特每秒计的 RTP 会话带宽. 在 SDP 中, RTP 会话带宽使用 "b=AS" 行来通告. RTP 会话带宽为 72 kbps 时, Tmin 为 5 秒. RTP 会话带宽为 360 kbps 当然会使 Tmin 为 1 秒, 而对于每秒 25 帧的视频流要实现每帧一次那样的 Tmin, 则需要 9 Mbps 的 RTP 会话带宽. 如下所述, 使用 RTP/AVPF 或 RTP/SAVPF 配置文件可以在相同带宽下实现更频繁的 RTCP 报告.
  3. Td 的值随 SSRC 数量和 RTCP 报告的平均大小而缩放, 以保持整体 RTCP 带宽恒定.
  4. 对于某个 Td 值, 实际传输间隔在区间 [0.5Td/1.21828, 1.5Td/1.21828] 内, 并且由于重新考虑, 分布发生偏斜, 大部分概率质量位于 Td 之上. 这意味着, 例如, 对于 Td = 5 秒, 实际传输间隔将分布在区间 [2.052 秒, 6.156 秒] 内, 并趋向该区间的上半部分. 注意 Tmin 参数在应用随机化和重新考虑之前限制 Td 的值, 因此实际传输间隔将覆盖一个延伸到 Tmin 以下的区间.

基于以上, 我们可以计算出一个将 5% 的会话带宽分配给 RTCP 的 RTP 会话在保持 Td 等于 Tmin 的情况下能够支持多少个 SSRC, 即 n. 这将告诉我们能够在保持 RTCP 开销在可接受范围内的前提下报告多少个 RTP 流. 我们做两个简化计算的假设: 所有 SSRC 都是发送方, 并且它们都发送包含一个带有 n-1 个报告块的 SR 包、后跟一个包含 16 字节 CNAME 值 [RFC7022] 的 SDES 包的复合 RTCP 包 (这类 RTCP 包的大小将根据 n 在 54 到 798 字节之间变化, 直至 SR 包中可包含的最大 31 个报告块). 如果我们把这个包大小和 5% 的 RTCP 带宽份额代入 [RFC3550] 第 6.3.1 节的 RTCP 间隔计算, 并计算为使缩放最小间隔下 Td = Tmin 所需的 n 值, 我们会发现可以支持 n=9 个 SSRC (与间隔无关, 因为报告间隔随会话带宽缩放的方式所致). 我们看到, 要在不改变缩放最小间隔的情况下支持更多 SSRC, 需要将 RTCP 带宽份额从 5% 提高; 将会话带宽改为更高的值会减小 Tmin. 然而, 如果使用默认的 5% RTCP 带宽分配, 在固定的 Td 目标下, 增加它会支持更多的 SSRC.

基于以上, 当使用 RTP/AVP 配置文件或 RTP/SAVP 配置文件时, 小型单播会话中快速 RTCP 报告的关键限制将是 Tmin 值. 在 RTCP 中配置的 RTP 会话带宽必须足够高, 以在遵循缩放最小 RTCP 间隔规则的情况下达到应用所需的报告目标.

7.2.2. RTP/AVPF 和 RTP/SAVPF​

当使用 RTP/AVPF 或 RTP/SAVPF 时, 我们有一个用于调整 RTCP 传输的强大额外工具: T_rr_interval 参数. 使用该参数允许较短的 RTCP 报告间隔; 或者, 它提供了在不发送频繁常规 RTCP 报告的情况下发送频繁 RTCP 反馈的能力.

在给定的 RTCP 带宽下, 使用 T_rr_interval 设为大于零但小于 Tmin 的值的 RTP/AVPF 或 RTP/SAVPF 配置文件, 可以比 RTP/AVP 或 RTP/SAVP 配置文件实现更频繁的 RTCP 反馈. 这是因为在传输初始 RTCP 报告之后 Tmin 被设为零, 使得后续包的报告间隔由通常基于 RTCP 带宽的计算 (Tmin=0) 和 T_rr_interval 决定. 其效果是我们不再受最小间隔 (无论是默认的 5 秒最小值还是缩减最小间隔) 的限制. 相反, RTCP 带宽和 T_rr_interval 成为主导因素, 从而允许更快的反馈. 关心快速常规 RTCP 反馈的应用应当考虑使用 RTP/AVPF 或 RTP/SAVPF 配置文件, 即使它们不使用该配置文件的反馈特性.

使用 RTP/AVPF 或 RTP/SAVPF 配置文件允许频繁发送 RTCP 反馈包, 而不必同时要求频繁发送常规 RTCP 报告, 因为 T_rr_interval 限制了常规 RTCP 包的发送速率, 同时仍允许发送 RTCP 反馈包. 可以对某些 RTP 流 (例如视频流) 使用反馈包、但不想对其他 RTP 流进行频繁常规报告的应用, 可以将 T_rr_interval 配置为一个值, 使得音频和视频的常规报告都处于对音频而言可接受的水平. 然后它们可以使用反馈包 (除非使用缩减大小 RTCP 反馈包 [RFC5506], 这些反馈包将包含 RTCP SR/RR 包) 来进行视频报告. 这使可用的 RTCP 带宽能够投入到为应用提供最大效用的反馈上.

使用 T_rr_interval 仍然需要确定合适的 RTCP 带宽值. 事实上, 这可能使这一选择更加重要, 因为与使用 RTP/AVP 或 RTP/SAVP 配置文件时相比, 这更可能影响 RTCP 行为和性能, 因为影响 RTCP 传输的限制更少.

当 T_rr_interval 非零时, 有些配置需要避免. 如果所选的 RTCP 带宽使得 Td 值小于但接近 T_rr_interval, 那么实际的常规 RTCP 包传输间隔可能变得非常大, 如第 7.1.1 节所讨论. 因此, 对于打算使 Td 小于 T_rr_interval 的配置, 建议 (RECOMMENDED) 将 Td 的目标设为小于 T_rr_interval 的 1/4, 这会使区间变为 [0.5T_rr_interval, 1.81T_rr_interval].

对于 RTP/AVPF 或 RTP/SAVPF 配置文件, 使用 T_rr_interval = 0 是有用的, 它导致 RTCP 传输仅受带宽限制, 即完全没有 Tmin 限制. 这允许比使用 RTP/AVP 配置文件更频繁的常规 RTCP 报告. 许多 RTCP 配置不会用尽它们被配置使用的全部带宽, 但这种配置会用尽分配给它的带宽. 注意只要 T_rr_interval 小于 Td 的 1/3, 就会实现相同的行为, 因为这可以防止 T_rr_interval 影响传输.

除了为每种类型或每个流使用单独的 RTP 会话之外, 不存在根据媒体类型或单个 RTP 流使用不同常规 RTCP 报告间隔的方法.