1. 引言 (Introduction)
在实时传输协议 (Real-Time Transport Protocol, RTP) [RFC3550] 最初设计时以及之后相当长一段时间内, RTP 会话中的端点通常只传输单个媒体源, 因而每个 RTP 会话使用单个 RTP 流和同步源 (synchronization source, SSRC), 并且通常为每种不同媒体类型使用独立 RTP 会话. 然而, 近来出现了一些场景, 端点希望在单个 RTP 会话中发送多个 RTP 流, 这些流由不同 RTP SSRC 标识符区分. 虽然 RTP 的初始设计确实考虑了这类场景, 但规范在撰写时并未始终以这些使用场景为目标, 因而在某些地方不够清晰.
本文更新 [RFC3550], 以澄清端点使用多个 SSRC 时的行为. 它还更新 [RFC4585], 以解决非活动 SSRC 超时相关问题, 并澄清包含反馈消息时的行为.
2. 术语 (Terminology)
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 RFC 2119 [RFC2119] 中的描述解释, 并表示合规实现的要求级别.
3. 多流端点的使用场景 (Use Cases for Multi-Stream Endpoints)
本节讨论若干使用场景, 这些场景推动了在单个 RTP 会话中使用多个 SSRC 发送 RTP 数据的端点的发展.
3.1. 具有多个采集设备的端点
端点在单个 RTP 会话中同时发送多个 RTP 流的最直接动机, 是该端点具有多个采集设备, 因而能够生成多个具有相同媒体类型和特征的媒体源. 例如, CLUE Telepresence Framework [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 节所述的多采集场景提供集中合成. 在这种情况下, 中心节点的行为很像多采集端点, 会生成若干相似且相关的源.
3.4. 单个媒体源的多个 SSRC
在若干情况下, 会在一个会话内使用多个 SSRC 发送来自单个媒体源的数据. 这些情况包括:
- 分层或多描述编解码器 (Layered or Multiple Description Codecs): 不同层或描述使用不同 SSRC 发送
- 传输鲁棒性机制 (Transport Robustness Mechanisms): 例如 RTP 重传 [RFC4588] 或前向纠错 [RFC5109]
- 联播 (Simulcast): 以不同质量或分辨率发送同一源的多个编码