4. 媒体优先级
在 WebRTC 优先级模型中, 应用程序通过 API 告知 WebRTC 端点其所控制的媒体和数据的优先级.
在此上下文中, "流 (flow)" 指通过 WebRTC API 被赋予特定优先级的单位.
对于媒体, "媒体流 (media flow)" 可以是 "音频流 (audio flow)" 或 "视频流 (video flow)", 对应 [RFC7656] 中称为 "媒体源 (media source)" 的概念, 它会产生一个 "源 RTP 流 (source RTP stream)" 以及一个或多个 "冗余 RTP 流 (redundancy RTP stream)". 本规范不描述来自同一媒体源的各 RTP 流之间的优先级排序.
如 [RFC4594] 所定义, WebRTC 中的所有媒体流都假定为交互式. 浏览器 API 不支持指示媒体是交互式还是非交互式.
"数据流 (data flow)" 是单个 WebRTC 数据通道上的出站数据.
与媒体流或数据流关联的优先级分为 "very-low", "low", "medium" 或 "high". API 中只有这四个优先级级别.
优先级设置会影响两类行为: 数据包发送顺序决策和数据包标记. 下文分别在独立小节中描述.
4.1. 本地优先级
本地优先级在本地节点上, 数据包发送之前应用. 这意味着优先级处理可以完整访问各个数据包的信息, 并可根据数据包所属的流选择不同处理方式.
当 WebRTC 端点在多个流上有数据包待发送, 且这些流在同一拥塞控制机制下进行拥塞控制时, WebRTC 端点 SHOULD 以如下方式发送数据: 每个优先级级别上的每条流获得的传输容量约为下一低级别的两倍. 传输容量以负载字节数衡量.
因此, 当发生拥塞且二者都有数据要发送时, 高优先级流能够发送的数据量将是 very-low 优先级流的 8 倍. 此优先级排序与媒体类型无关. 首先发送哪个数据包的细节由实现定义.
例如, 如果有一个发送 100 字节数据包的高优先级音频流, 以及一个发送 1000 字节数据包的低优先级视频流, 并且出站容量足以发送 > 5000 个负载字节, 那么一次发送决策的合理结果可以是发送 4000 字节音频数据 (40 个数据包) 和 1000 字节视频数据 (一个数据包).
反之, 如果音频流被标记为低优先级, 视频流被标记为高优先级, 当出站容量足以发送 > 2500 个负载字节时, 调度器可以决定发送 2 个视频数据包 (2000 字节) 和 5 个音频数据包 (500 字节).
如果存在两个高优先级音频流, 在低优先级视频流能够发送 1000 字节的同一时间段内, 每个高优先级音频流都能够发送 4000 字节.
以下是两种示例实现策略:
-
当拥塞控制算法已知可用带宽时, 为每个编解码器和每个数据通道配置目标发送速率, 使其与该对象在可用带宽中的份额相匹配.
-
当拥塞控制指示可以发送指定数量的数据包时, 在各连接之间使用加权轮询 (weighted round-robin) 方案发送可发送的数据包.
只要传输容量的分配大致正确, 这些策略的任意组合, 或具有相同效果的其他方案, 都是有效的.
对于媒体, 发送时通常不适合使用很深的队列. 例如, 为实现更低比特率, 跳过没有其他帧依赖它们的中间帧通常更有用. 对于可靠数据, 队列是有用的.
注意, 本规范不规定何时应将不同流置于 "同一拥塞控制机制下进行拥塞控制". [RFC8699] 对拥塞控制器耦合问题作了进一步探讨.
4.2. 服务质量的使用 -- DSCP 和复用
发送数据包时, 网络会决定如何对数据包排队和/或丢弃数据包, 这些决定可能影响通信质量. 发送方可以尝试设置数据包的 DSCP 字段来影响这些决定.
实现 SHOULD 按照 [RFC8837] 中的指南, 尝试为发送的数据包设置 QoS. 在未实现 QoS 标记的平台上运行时, 偏离此建议是合适的.
如果实现检测到优先级反转或带有某些 DSCP 标记的数据包被阻塞等异常行为迹象, MAY 关闭 DSCP 标记的使用. [ANRW16] 描述了此类行为的一些示例. 对这些条件的检测由实现决定.
一个特别困难的问题是, 同一个媒体传输使用多个 DSCP, 其中某个 DSCP 可能被阻塞, 另一个 DSCP 可能被允许. 在 [RFC8837] 中, 即使对单个视频媒体流也允许这样做. 实现需要诊断这种场景. 一种可能的实现方式是使用 DSCP 0 发送初始 ICE 探测, 并在候选对被选定后, 针对所有计划使用的 DSCP 发送 ICE 探测. 如果一个或多个带 DSCP 标记的探测失败, 发送方将把该媒体类型切换为使用 DSCP 0. 这可以与初始媒体流量同时进行. 发生失败时, 初始数据可能需要重发. 当然, 这种切换会使截至该时刻收集到的所有拥塞信息失效.
失败也可能在呼叫生命周期内开始发生. 这种情况预计较少见, 可以通过处理传输失败的常规机制来处理, 其中可能涉及 ICE 重启.
注意, 当某个 DSCP 导致无法交付时, 必须将整个媒体流切换到 DSCP 0, 因为出于拥塞控制目的, 单个媒体流的所有流量都需要位于同一队列上. 同一传输上使用不同 DSCP 的其他流不需要改变.
承载来自支持数据通道的 SCTP 关联的数据的所有数据包 MUST 使用单一 DSCP. 所使用的码点 SHOULD 是 [RFC8837] 针对所承载的最高优先级数据通道推荐的码点. 注意, 这意味着无论所有数据包的相对优先级如何, 网络都会以相同方式处理它们.
一条 TCP 连接上的所有数据包, 无论其承载什么内容, MUST 使用单一 DSCP.
[RFC7657] 给出了关于在 RTP 中使用 DSCP 的更多建议, 以及 DSCP 与拥塞控制之间关系的更多说明.
存在多种不完全依赖 DSCP 来实现服务质量的方案. 其中一些方案依赖于基于 5 元组 (源地址, 源端口, 协议, 目标地址, 目标端口) 或 6 元组 (5 元组 + DSCP) 将流量分类为不同流. 因此, 在不同条件下, 发送应用程序选择以下任一配置都可能是合理的:
- 每个媒体流承载在自己的 5 元组上
- 按媒体类型将媒体流分组到 5 元组中, 例如将所有音频承载在一个 5 元组上
- 所有媒体都通过单个 5 元组发送, 可以基于 DSCP 区分为 6 元组, 也可以不这样区分
在上述每种配置中, 数据通道可以承载在自己的 5 元组上, 也可以与某个媒体流复用在一起.
也可以设想更复杂的配置, 例如在一个 5 元组上发送高优先级视频流, 并在另一个 5 元组上复用发送所有其他视频流. 关于将媒体流映射到 5 元组的更多信息可见 [RFC8834].
发送实现 MUST 能够支持以下配置:
- 在单个 5 元组上复用所有媒体和数据 (完全捆绑)
- 在每个媒体流自己的 5 元组上发送该媒体流, 并在数据自己的 5 元组上发送数据 (完全非捆绑)
发送实现 MAY 选择支持其他配置, 例如将每种媒体类型 (音频, 视频或数据) 捆绑到其自己的 5 元组中 (按媒体类型捆绑).
不支持通过多个 5 元组发送数据通道数据.
接收实现 MUST 能够在所有这些配置中接收媒体和数据.