4. Media Prioritization (媒体优先级)
在WebRTC优先级模型中,应用程序通过API告知WebRTC端点关于媒体和数据的优先级.
在此上下文中,"流 (Flow)"用于通过WebRTC API赋予特定优先级的单元.
对于媒体,一个"媒体流 (Media Flow)"(可以是"音频流 (Audio Flow)"或"视频流 (Video Flow)")是 [RFC7656] 所称的"媒体源 (Media Source)",它产生一个"源RTP流 (Source RTP Stream)"和一个或多个"冗余RTP流 (Redundancy RTP Streams)". 本规范不描述来自单个媒体源的RTP流之间的优先级.
WebRTC中的所有媒体流都假定为交互式的,如 [RFC4594] 中定义; 没有浏览器API支持指示媒体是交互式还是非交互式.
"数据流 (Data Flow)"是单个WebRTC数据通道上的传出数据.
与媒体流或数据流相关联的优先级分类为"very-low (非常低)"、"low (低)"、"medium (中)"或"high (高)". API中只有四个优先级级别.
优先级设置影响两个行为部分: 数据包发送顺序决策和数据包标记. 每个都在下面的各自章节中描述.
4.1. Local Prioritization (本地优先级)
本地优先级在数据包发送之前应用于本地节点. 这意味着优先级可以完全访问有关各个数据包的数据,并可以根据数据包所属的流选择不同的处理方式.
当WebRTC端点有多个流上的数据包要发送,并且这些流在相同的拥塞控制机制下进行拥塞控制时,WebRTC端点应该 (SHOULD) 使数据以这样的方式发出: 每个优先级级别的每个流获得的传输容量(以有效负载字节衡量)大约是下一级别的两倍.
因此,当发生拥塞时,如果高优先级流和非常低优先级流都有数据要发送,则高优先级流将能够发送8倍于非常低优先级流的数据. 此优先级与媒体类型无关. 首先发送哪个数据包的详细信息由实现定义.
例如,如果有一个发送100字节数据包的高优先级音频流和一个发送1000字节数据包的低优先级视频流,并且存在发送 > 5000有效负载字节的传出容量,则适当的做法是发送4000字节(40个数据包)的音频和1000字节(一个数据包)的视频作为单次发送决策的结果.
相反,如果音频流标记为低优先级而视频流标记为高优先级,则当存在发送 > 2500有效负载字节的传出容量时,调度程序可能决定发送2个视频数据包(2000字节)和5个音频数据包(500字节).
如果有两个高优先级音频流,则在低优先级视频流能够发送1000字节的同一时期内,每个音频流将能够发送4000字节.
两个示例实现策略是:
-
当从拥塞控制算法得知可用带宽时,为每个编解码器和每个数据通道配置适合其可用带宽份额的目标发送速率.
-
当拥塞控制指示可以发送指定数量的数据包时,使用跨连接的加权轮询方案发送可用于发送的数据包.
这些的任何组合,或具有相同效果的其他方案,都是有效的,只要传输容量的分配大致正确.
对于媒体,通常不适合使用深队列进行发送; 更有用的是,例如,跳过对它们没有依赖关系的中间帧以实现较低的比特率. 对于可靠数据,队列是有用的.
请注意,本规范没有规定何时将不同的流"在相同的拥塞控制机制下进行拥塞控制". 在 [RFC8699] 中进一步探讨了耦合拥塞控制器的问题.
4.2. Usage of Quality of Service -- DSCP and Multiplexing (服务质量的使用 -- DSCP和复用)
当发送数据包时,网络将对数据包的排队和/或丢弃做出决策,这可能影响通信质量. 发送方可以尝试设置数据包的DSCP字段以影响这些决策.
实现应该 (SHOULD) 尝试根据 [RFC8837] 中的指南在发送的数据包上设置QoS. 当在未实现QoS标记的平台上运行时,偏离此建议是适当的.
如果实现检测到意外行为的症状,例如优先级反转或阻止具有特定DSCP标记的数据包,则可以 (MAY) 关闭DSCP标记的使用. [ANRW16] 中描述了此类行为的一些示例. 这些条件的检测取决于实现.
一个特别困难的问题是当一个媒体传输使用多个DSCP时,其中一个可能被阻止而另一个可能被允许. 根据 [RFC8837],即使在单个媒体流内的视频也允许这样做. 实现需要诊断这种情况; 一种可能的实现是使用DSCP 0发送初始ICE探测,并在选择候选对后在所有打算使用的DSCP上发送ICE探测. 如果一个或多个DSCP标记的探测失败,则发送方将切换媒体类型以使用DSCP 0. 这可以与初始媒体流量同时进行; 失败时,可能需要重新发送初始数据. 当然,此切换将使到那时为止收集的任何拥塞信息无效.
故障也可能在呼叫的生命周期内开始发生; 预计这种情况会更罕见,并且可以通过传输故障的正常机制来处理,这可能涉及ICE重启.
请注意,当DSCP导致无法传递时,必须将整个媒体流切换到DSCP 0,因为单个媒体流的所有流量都需要在同一队列上以进行拥塞控制. 使用不同DSCP的同一传输上的其他流不需要更改.
承载来自支持数据通道的SCTP关联的数据的所有数据包必须 (MUST) 使用单个DSCP. 使用的代码点应该 (SHOULD) 是 [RFC8837] 为承载的最高优先级数据通道推荐的代码点. 请注意,这意味着所有数据包,无论其相对优先级如何,都将被网络同等对待.
一个TCP连接上的所有数据包,无论它承载什么,都必须 (MUST) 使用单个DSCP.
[RFC7657] 中提供了关于将DSCP与RTP一起使用以及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) 能够在所有这些配置中接收媒体和数据.