跳到主要内容

2. RTP 使用场景 (RTP Use Scenarios)

以下各节描述 RTP 使用的一些方面。选择这些示例是为了说明使用 RTP 的应用的基本运作方式, 而不是为了限制 RTP 的用途。在这些示例中, RTP 承载于 IP 和 UDP 之上, 并遵循配套文档 RFC 3551 中为音频和视频所规定的配置文件所建立的约定。

2.1 简单的多播音频会议 (Simple Multicast Audio Conference)​

IETF 的一个工作组开会讨论最新的协议文档, 使用 Internet 的 IP 多播服务进行语音通信。通过某种分配机制, 工作组主席获得一个多播组地址和一对端口。一个端口用于音频数据, 另一个用于控制 (RTCP) 包。该地址和端口信息被分发给预期的参与者。如果需要保密, 数据和控制包可以按照第 9.1 节的规定进行加密, 在这种情况下, 还必须生成并分发一个加密密钥。这些分配和分发机制的具体细节不在 RTP 范围内。

每位会议参与者所使用的音频会议应用, 以较小的块 (例如 20 毫秒时长) 发送音频数据。每块音频数据之前都有一个 RTP 头部; RTP 头部和数据又依次包含在一个 UDP 报文中。RTP 头部指示每个包中包含何种类型的音频编码 (如 PCM、ADPCM 或 LPC), 以便发送方可以在会议期间更改编码, 例如, 以适应通过低带宽链路连接的新参与者, 或响应网络拥塞的指示。

Internet 与其他分组网络一样, 偶尔会丢失、重排报文, 并以可变的时延将其延迟。为了应对这些损害, RTP 头部包含定时信息和序列号, 使接收方能够重建源所产生的定时, 从而在本例中, 音频块每隔 20 毫秒连续不断地从扬声器播放出来。这种定时重建对会议中每个 RTP 包源单独进行。序列号也可以被接收方用来估计正在丢失多少包。

由于工作组成员在会议期间加入和离开, 了解任何时刻谁在参与以及他们接收音频数据的状况如何是有用的。为此, 会议中每个音频应用的实例定期在多播上发送一个接收报告, 以及其用户的名字, 发送于 RTCP (控制) 端口。该接收报告指示当前发言者的接收状况如何, 并可用于控制自适应编码。除用户名外, 在其他标识信息受控制带宽限制的前提下, 也可以包含它们。一个站点在离开会议时发送 RTCP BYE 包 (第 6.6 节)。

2.2 音频与视频会议 (Audio and Video Conference)​

如果会议中同时使用音频和视频媒体, 它们作为独立的 RTP 会话传输。也就是说, 为每种媒体使用两个不同的 UDP 端口对和/或多播地址传输独立的 RTP 和 RTCP 包。在 RTP 层面, 音频会话和视频会话之间没有直接耦合, 除了同时参与两个会话的用户应当在两个会话的 RTCP 包中使用相同的可区分 (规范, canonical) 名称, 以便将这俩会话关联起来。

这种分离的动机之一是允许会议中某些参与者如果愿意, 只接收其中一种媒体。进一步的解释见第 5.2 节。尽管存在分离, 但利用两个会话的 RTCP 包中所携带的定时信息, 可以实现对一个源的音频和视频的同步回放。

2.3 混合器与转换器 (Mixers and Translators)​

到目前为止, 我们假定所有站点都希望以相同的格式接收媒体数据。然而, 这并不总是合适的。考虑这样一种情况: 某一区域的参与者通过低速链路连接到会议的大多数参与者, 而后者享有高速网络访问。与其强迫每个人都使用较低带宽、质量下降的音频编码, 不如在低速区域附近放置一个称为混合器 (mixer) 的 RTP 级中继。该混合器重新同步 (resynchronizes) 传入的音频包以重建由发送方产生的恒定 20 毫秒间隔, 将这些重建后的音频流混合成单一流, 将音频编码转换为较低带宽的编码, 并跨低速链路转发该较低带宽的包流。这些包可以是单播给单个接收者, 也可以在不同地址上多播给多个接收者。RTP 头部包含了让混合器标识那些对混合包有贡献的源的手段, 以便在接收方处提供正确的发言者指示。

音频会议中某些预期的参与者可能连接着高带宽链路, 但可能无法通过 IP 多播直接到达。例如, 他们可能位于不允许任何 IP 包通过的应用层防火墙之后。对于这些站点, 混合可能是不必要的, 在这种情况下, 可以使用另一种称为转换器 (translator) 的 RTP 级中继。安装两个转换器, 分别位于防火墙两侧, 外侧的那个通过安全连接将多播包转发给防火墙内的转换器。防火墙内的转换器再次将这些包作为多播包发送给限制在该站点内部网络的多播组。

混合器和转换器可以为了各种各样的目的而设计。一个例子是视频混合器, 它将单独视频流中各个人的图像缩放并合成到一路视频流中, 以模拟一个群组场景。转换的其他例子包括: 将一组只懂 IP/UDP 的主机连接到一组只懂 ST-II 的主机, 或者在不重新同步或混合的情况下, 对来自各个源的视步流进行逐包的编码转换。混合器和转换器的操作细节在第 7 节中给出。

2.4 分层编码 (Layered Encodings)​

多媒体应用应当能够调整传输速率, 以匹配接收方的容量或适应网络拥塞。许多实现将速率自适应 (rate-adaptivity) 的责任放在源端。这在多播传输中效果不佳, 因为异构接收方的带宽需求相互冲突。结果往往是最低公共分母 (least-common denominator) 场景, 即网络网格中最小的管道决定了整体实时多媒体 "广播" 的质量和保真度。

相反, 通过将分层编码 (layered encoding) 与分层传输系统相结合, 可以将速率自适应的责任放在接收方。在 RTP over IP 多播的语境下, 源可以将分层表示的信号 (hierarchically represented signal) 的渐进层分条 (stripe) 到多个 RTP 会话上, 每个会话承载于其自己的多播组。接收方于是可以通过仅加入多播组的适当子集来适应网络异构性并控制其接收带宽。

RTP 与分层编码一起使用的细节见第 6.3.9 节、第 8.3 节和第 11 节。