2. RTP 使用场景 (RTP Use Scenarios)
以下各节描述 RTP 使用中的若干方面. 这些示例旨在说明使用 RTP 的应用程序的基本操作, 而不是限制 RTP 的用途. 在这些示例中, RTP 承载于 IP 和 UDP 之上, 并遵循配套 RFC 3551 中规定的音频和视频配置文件所建立的约定.
2.1 简单组播音频会议 (Simple Multicast Audio Conference)
IETF 的一个工作组使用互联网的 IP 组播服务进行语音通信, 以讨论最新的协议文档. 工作组主席通过某种分配机制获得一个组播组地址和一对端口. 一个端口用于音频数据, 另一个端口用于控制 (RTCP) 数据包. 该地址和端口信息会分发给预期参与者. 如果需要隐私保护, 数据和控制数据包可以按第 9.1 节的规定加密, 在这种情况下还必须生成并分发加密密钥. 这些分配和分发机制的具体细节超出 RTP 范围.
每个会议参与者使用的音频会议应用程序会以小块形式发送音频数据, 例如每块持续 20 ms. 每个音频数据块前面都有一个 RTP 头部; RTP 头部和数据随后一起包含在 UDP 数据包中. RTP 头部指示每个数据包中包含哪种音频编码类型 (如 PCM, ADPCM 或 LPC), 因此发送者可以在会议期间改变编码, 例如为了适应通过低带宽链路连接的新参与者, 或响应网络拥塞的指示.
与其他分组网络一样, 互联网偶尔会丢失数据包, 对数据包重排序, 并产生可变时延. 为应对这些损伤, RTP 头部包含定时信息和序列号, 使接收者能够重建源产生的定时; 因此在本示例中, 音频块会每隔 20 ms 连续从扬声器播放. 这种定时重建会针对会议中每个 RTP 数据包源分别执行. 接收者也可以使用序列号估计丢包数量.
由于工作组成员会在会议期间加入和离开, 了解任意时刻哪些人正在参与以及他们接收音频数据的效果如何是有用的. 为此, 会议中的每个音频应用实例会周期性地在 RTCP (控制) 端口上组播一份接收报告以及其用户名称. 接收报告指示当前说话者的接收效果, 并可用于控制自适应编码. 除用户名之外, 还可以在控制带宽限制允许的范围内包含其他标识信息. 站点离开会议时会发送 RTCP BYE 数据包 (第 6.6 节).
2.2 音频和视频会议 (Audio and Video Conference)
如果会议同时使用音频和视频媒体, 它们会作为单独的 RTP 会话传输. 也就是说, 每种媒体使用两个不同的 UDP 端口对和/或组播地址分别传输 RTP 和 RTCP 数据包. 在 RTP 层面, 音频和视频会话之间没有直接耦合, 但同时参与两个会话的用户应在两个会话的 RTCP 数据包中使用相同的规范名称 (canonical name), 以便关联这些会话.
这种分离的一个动机是允许会议中的某些参与者按自己的选择只接收一种媒体. 第 5.2 节给出了进一步说明. 尽管会话分离, 仍可以使用两个会话的 RTCP 数据包中携带的定时信息, 实现某个源的音频和视频同步回放.
2.3 混音器和转换器 (Mixers and Translators)
到目前为止, 我们假定所有站点都希望以同一种格式接收媒体数据. 但这并不总是合适. 考虑这样一种情况: 某一区域内的参与者通过低速链路连接到大多数拥有高速网络接入的会议参与者. 与其强迫所有人使用较低带宽, 较低质量的音频编码, 不如在低带宽区域附近放置一个称为混音器的 RTP 层中继. 该混音器会重新同步传入的音频数据包, 以重建发送者产生的恒定 20 ms 间隔, 将这些重建后的音频流混合为单个流, 将音频编码转换为较低带宽的编码, 并通过低速链路转发较低带宽的数据包流. 这些数据包可以单播给单个接收者, 也可以在不同地址上组播给多个接收者. RTP 头部包含一种机制, 供混音器标识对混合数据包做出贡献的源, 以便接收者能够正确指示说话者.
音频会议中的一些预期参与者可能连接在高带宽链路上, 但不能通过 IP 组播直接到达. 例如, 他们可能位于应用层防火墙之后, 防火墙不允许任何 IP 数据包通过. 对这些站点而言, 可能不需要混音, 这时可以使用另一种称为转换器的 RTP 层中继. 部署两个转换器, 防火墙两侧各一个, 外侧转换器通过安全连接把所有收到的组播数据包汇集到防火墙内侧的转换器. 防火墙内侧的转换器再将这些数据包作为组播数据包发送到仅限该站点内部网络的组播组.
混音器和转换器可以为多种目的而设计. 一个示例是视频混音器, 它缩放不同视频流中各个参与者的图像, 并将其合成为一个视频流, 以模拟群组场景. 其他转换示例包括连接一组只使用 IP/UDP 的主机和一组只理解 ST-II 的主机, 或者在不重新同步或混音的情况下逐包转换来自各个源的视频流编码. 混音器和转换器操作的细节见第 7 节.
2.4 分层编码 (Layered Encodings)
多媒体应用应能够调整传输速率, 以匹配接收者能力或适应网络拥塞. 许多实现把速率自适应的责任放在源端. 这在组播传输中效果不佳, 因为异构接收者的带宽需求相互冲突. 结果往往是一种最低共同能力场景, 即网络网格中最小的管道决定整个实时多媒体"广播"的质量和保真度.
相反, 可以通过把分层编码与分层传输系统结合, 将速率自适应责任放在接收者端. 在基于 IP 组播的 RTP 上下文中, 源可以把按层次表示的信号的渐进层分条到多个 RTP 会话中, 每个会话承载在自己的组播组上. 接收者随后可以只加入适当的组播组子集, 以适应网络异构性并控制自身接收带宽.
RTP 与分层编码一起使用的细节见第 6.3.9 节, 第 8.3 节和第 11 节.