3. 多流端点的用例

本节讨论若干个用例, 它们推动了在一个 RTP 会话中使用多个 SSRC 发送 RTP 数据的端点的发展.

3.1. 具有多个采集设备的端点

端点在一个 RTP 会话中发送多个同时的 RTP 流, 最直接的动机是端点具有多个采集设备, 因而能够生成多个相同媒体类型和特征的媒体源. 例如, CLUE 远程呈现框架 [CLUE-FRAME] 所描述的那类远程呈现系统通常具有覆盖房间各个区域的多个摄像头或麦克风, 因而在单个 RTP 会话内发送每种类型的多个 RTP 流.

3.2. 单个 RTP 会话中的多种媒体类型

近期的工作更新了 RTP [MULTI-RTP] 和会话描述协议 (Session Description Protocol, SDP) [SDP-BUNDLE], 以移除 RTP 中的一个历史假设, 即不同媒体类型的媒体源总是会在不同的 RTP 会话上发送. 在这些工作中, 单个端点的音频和视频 RTP 流 (例如) 改为在单个 RTP 会话中发送, 以减少所使用的传输层流的数量.

3.3. 多流混音器

有若干种 RTP 拓扑会涉及一个自身在会话中生成多个 RTP 流的中心设备. 一个例子是为第 3.1 节所述的多采集场景提供集中合成的混音器. 在这种情况下, 该中心节点的行为很像一个多采集端点, 生成若干相似且相关的源.

更复杂的例子是 [RFC7667] 第 3.7 节所述的选择性转发中间盒. 这种中间盒从若干端点接收 RTP 流, 然后将其中一些 RTP 流的修改版本选择性地转发给与它相连的其他端点. 对于每个相连的端点, 会话中都会为连接到该中间盒的每一个其他源出现一个单独的媒体源, 它从原始流"投射"而来, 但在任意给定时刻其中许多可能表现为非活动状态 (因而在 RTP 中是接收方而非发送方). 这类设备更接近于 RTP 混音器而非 RTP 转换器: 它会终止关于混合流的 RTCP 报告; 它可以重写 SSRC、时间戳和序列号, 以及 RTP 载荷的内容; 并且它可以随意开启和关闭源, 而不表现为产生丢包. 每个投射流通常会保留其原始的 RTCP 源描述 (SDES) 信息.

3.4. 单个媒体源的多个 SSRC

还有若干情形会在单个 RTP 会话内使用多个 SSRC 来发送来自单个媒体源的数据. 这些情形包括但不限于传输健壮性工具, 例如 RTP 重传载荷格式 [RFC4588], 它要求一个 SSRC 用于媒体数据, 另一个 SSRC 用于修复数据. 类似地, 一些分层媒体编码方案, 例如 H.264 可伸缩视频编码 (Scalable Video Coding, SVC) [RFC6190], 可以用于在单个 RTP 会话内每一层使用不同的 SSRC 发送的配置.