跳到主要内容

7. RTP 转换器与混合器 (RTP Translators and Mixers)

除了端系统外, RTP 还支持 "转换器 (translators)" 和 "混合器 (mixers)" 的概念, 它们可被视为 RTP 层面的 "中间系统 (intermediate systems)"。尽管这种支持为协议增加了一些复杂性, 但通过 Internet 中多播音频和视频应用的实验, 对这些功能的需求已得到明确确立。第 2.3 节给出的转换器与混合器的用例, 源于防火墙和低带宽连接的存在, 而这两者都 likely 会持续存在。

7.1 一般描述 (General Description)​

一个 RTP 转换器/混合器连接两个或多个传输层 "云 (clouds)"。通常, 每个云由一个共同的网络与传输协议 (如 IP/UDP) 外加一个多播地址和传输层目的端口, 或一对单播地址和端口来定义。(网络级协议转换器, 例如从 IP 版本 4 到 IP 版本 6, 可以在一个云内部透明地存在, 对 RTP 不可见。) 一个系统可以作为一个转换器或混合器服务于多个 RTP 会话, 但每一个都被视为一个逻辑上独立的实体。

为了避免在安装转换器或混合器时形成环路, MUST 遵守以下规则:

o 由参与同一个 RTP 会话的转换器与混合器所连接的各个云, 要么 MUST 在至少一个这些参数 (协议、地址、端口) 上彼此不同, 要么 MUST 在网络层上与其他云隔离。

o 第一条规则的一个衍生规则是: MUST NOT 存在多个并联连接的转换器或混合器, 除非通过某种安排, 它们对要转发的源集合进行了划分。

类似地, 所有能通过一个或多个 RTP 转换器或混合器相互通信的 RTP 端系统, 共享同一个 SSRC 空间, 也就是说, 这些 SSRC 标识符 MUST 在所有这些端系统之间唯一。第 8.2 节描述了用于保持 SSRC 标识符唯一并检测环路的冲突解决算法。

可能有很多为不同目的和应用而设计的各类转换器和混合器。一些例子是: 添加或移除加密、改变数据或下层协议的编码, 或者在多播地址与一个或多个单播地址之间进行复制。转换器与混合器的区别在于: 转换器将来自不同源的数据流分别透传, 而混合器将它们组合以形成一条新流:

转换器 (Translator): 透传 RTP 包, 其 SSRC 标识符保持不变; 这使得接收方能够识别各个源, 即使来自所有源的数据包都经过同一个转换器并携带该转换器的网络源地址。某些种类的转换器会原样透传数据, 但其他转换器 MAY 改变数据的编码, 从而改变 RTP 数据负载类型和时间戳。如果多个数据报被重新编码为一个, 或相反, 转换器 MUST 为出站包分配新的序列号。入站包流中的丢失可能在其出站序列号中引起相应的空缺。除非接收方通过其他手段得知原始源使用了何种负载类型或传输地址, 否则它们无法检测到转换器的存在。

混合器 (Mixer): 从一个或多个源接收 RTP 数据包流, 可能改变数据格式, 以某种方式组合这些流, 然后转发组合后的流。由于多个输入源之间的定时通常并不同步, 混合器会在各流之间进行定时调整, 并为组合流生成自己的定时, 因此它是同步源。因此, 一个混合器转发的所有数据报 MUST 标记为该混合器自己的 SSRC 标识符。为了保留对组合包有贡献的原始源的身份, 混合器 SHOULD 将这些源的 SSRC 标识符插入到该包固定 RTP 头部之后的 CSRC 标识符列表中。一个混合器如果自身也是某个包的参与源 (contributing source), SHOULD 在该包的 CSRC 列表中显式地包含它自己的 SSRC 标识符。

  对于某些应用, 混合器不在 CSRC 列表中标识源 MAY 是可接受的。然而, 这引入了这样一种危险: 涉及那些源的环路可能无法被检测到。

对于像音频这样的应用, 混合器相对于转换器的优势在于, 即使输入端有多个源处于活动状态, 输出带宽也仅限于单个源的水平。这对于低带宽链路可能很重要。缺点在于, 输出端的接收方对哪些源被透传或静音没有任何控制权, 除非实现了某种用于远程控制混合器的机制。混合器重新生成同步信息也意味着接收方无法对原始流进行媒体间同步。一个多媒体混合器可以做到这一点。

     [E1]                                    [E6]
      |                                       |
E1:17 |                                 E6:15 |
      |                                       |   E6:15
      V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
     (M1)-------------><T1>-----------------><T2>-------------->[E7]
      ^                 ^     E4:47           ^   E4:47
 E2:1 |           E4:47 |                     |   M3:89 (64,45)
      |                 |                     |
     [E2]              [E4]     M3:89 (64,45) |
                                              |        legend:

[E3] --------->(M2)----------->(M3)------------| [End system] E3:64 M2:12 (64) ^ (Mixer) | E5:45 | [E5] source: SSRC (CSRCs) ------------------->

Figure 3: Sample RTP network with end systems, mixers and translators

图 3 展示了一组混合器和转换器, 以说明它们对 SSRC 和 CSRC 标识符的影响。在图中, 端系统显示为矩形 (命名为 E), 转换器显示为三角形 (命名为 T), 混合器显示为椭圆 (命名为 M)。记号 "M1:48(1,17)" 表示发自混合器 M1 的一个包, 由 M1 的 (随机) SSRC 值 48 以及两个 CSRC 标识符 1 和 17 标识, 这两个 CSRC 是从 E1 和 E2 的包的 SSRC 标识符复制而来。

7.2 转换器中的 RTCP 处理 (RTCP Processing in Translators)​

除了可能经过修改地转发数据报之外, 转换器和混合器 MUST 也处理 RTCP 包。在许多情况下, 它们会拆开从端系统接收到的复合 RTCP 包, 以聚合 SDES 信息并修改 SR 或 RR 包。这些信息的重传可由包的到达或转换器/混合器自身的 RTCP 间隔定时器触发。

一个不修改数据报的转换器 (例如仅在多播地址和单播地址之间复制的转换器) MAY 简单地原样转发 RTCP 包。一个以某种方式转换负载的转换器 MUST 在 SR 和 RR 信息中进行相应的转换, 以使它们仍然反映数据特征和接收质量。这些转换器 MUST NOT 简单地透传 RTCP 包。通常, 转换器 SHOULD NOT 将来自不同源的 SR 和 RR 包聚合到一个包中, 因为那会降低基于 LSR 和 DLSR 字段的传播时延测量的精度。

SR 发送方信息: 转换器不生成它自己的发送方信息, 而是将从某一个云接收到的 SR 包转发给其他云。SSRC 保持不变, 但如果转换有要求, 发送方信息 MUST 被修改。如果转换器改变了数据编码, 它 MUST 改变 "发送方字节计数 (sender's byte count)" 字段。如果它还将多个数据报组合为一个输出包, 它 MUST 改变 "发送方包计数 (sender's packet count)" 字段。如果它改变了时间戳频率, 它 MUST 改变 SR 包中的 "RTP 时间戳" 字段。

SR/RR 接收报告块: 转换器将从某一个云接收到的接收报告转发给其他云。注意, 这些报告流向与数据相反的方向。SSRC 保持不变。如果转换器将多个数据报组合为一个输出包, 从而改变了序列号, 它 MUST 对丢包字段和 "扩展最后序列号 (extended last sequence number)" 字段做逆向处理。这可能很复杂。在极端情况下, 可能没有任何有意义的方法来转换接收报告, 因此转换器 MAY 完全不转发任何接收报告, 或者转发一份基于它自身接收情况的合成报告。通用的规则是: 为特定的转换做合理的处理。

  转换器不需要它自己的 SSRC 标识符, 但 MAY 选择分配一个, 用于发送关于它所接收内容的报告。这些报告将被发送给所有相连的云, 每个云对应于发送给该云的数据流的转换, 因为接收报告通常会被多播给所有参与者。

SDES: 转换器通常原样转发它们从一个云接收到的 SDES 信息到其他云, 但 MAY, 例如, 在带宽有限时决定过滤非 CNAME 的 SDES 信息。CNAME MUST 被转发, 以使 SSRC 标识符冲突检测能够工作。一个生成它自己的 RR 包的转换器 MUST 向它发送那些 RR 包的相同云, 发送关于它自己的 SDES CNAME 信息。

BYE: 转换器原样转发 BYE 包。一个即将停止转发包的转换器 SHOULD 向每个相连的云发送一个 BYE 包, 其中包含之前正被转发到该云的所有 SSRC 标识符, 包括该转换器自己的 SSRC 标识符 (如果它发送过它自己的报告)。

APP: 转换器原样转发 APP 包。

7.3 混合器中的 RTCP 处理 (RTCP Processing in Mixers)​

由于混合器生成它自己的新数据流, 它根本不透明地透传 SR 或 RR 包, 而是为双方生成新的信息。

SR 发送方信息: 混合器不透传来自它所混合的源发送方信息, 因为源流的特征在混合过程中丢失了。作为一个同步源, 混合器 SHOULD 生成它自己的 SR 包, 其中包含关于混合数据流的发送方信息, 并将它们沿与混合流相同的方向发送。

SR/RR 接收报告块: 混合器为每一个云中的源生成它自己的接收报告, 并只将它们发送给同一个云。它 MUST NOT 将这些接收报告发送给其他云, 也 MUST NOT 将一个云的接收报告转发给其他云, 因为那些源在那里不会是 SSRC (只会是 CSRC)。

SDES: 混合器通常原样转发它们从一个云接收到的 SDES 信息到其他云, 但 MAY, 例如, 在带宽有限时决定过滤非 CNAME 的 SDES 信息。CNAME MUST 被转发, 以使 SSRC 标识符冲突检测能够工作。(由混合器生成的 CSRC 列表中的标识符可能与某个端系统生成的 SSRC 标识符冲突。) 混合器 MUST 向它发送 SR 或 RR 包的相同云, 发送关于它自己的 SDES CNAME 信息。

  由于混合器不透传 SR 或 RR 包, 它们通常会从一个复合 RTCP 包中提取 SDES 包。为了最小化开销, SDES 包中的块 MAY 被聚合到一个单独的 SDES 包中, 然后堆叠在源自该混合器的 SR 或 RR 包之上。一个聚合 SDES 包的混合器将比单个源使用更多的 RTCP 带宽, 因为复合包会更长, 但这是恰当的, 因为该混合器代表了多个源。类似地, 一个按接收原样透传 SDES 包的混合器, 将以高于单个源速率的方式发送 RTCP 包, 但这同样是正确的, 因为这些包来自多个源。RTCP 包速率在混合器的每一侧可能不同。

  一个不插入 CSRC 标识符的混合器 MAY 也避免转发 SDES CNAME。在这种情况下, 两个云中的 SSRC 标识符空间是独立的。正如前面提到的, 这种运作模式造成了环路无法被检测到的危险。

BYE: 混合器 MUST 转发 BYE 包。一个即将停止转发包的混合器 SHOULD 向每个相连的云发送一个 BYE 包, 其中包含之前正被转发到该云的所有 SSRC 标识符, 包括该混合器自己的 SSRC 标识符 (如果它发送过它自己的报告)。

APP: 混合器对 APP 包的处理是应用特定的。

7.4 级联混合器 (Cascaded Mixers)​

一个 RTP 会话可能涉及一组混合器和转换器, 如图 3 所示。如果两个混合器级联, 如图中的 M2 和 M3, 一个混合器接收到的包可能已经被混合过, 并可能包含一个带有多个标识符的 CSRC 列表。第二个混合器 SHOULD 使用来自已被混合的输入包的 CSRC 标识符, 以及来自未被混合的输入包的 SSRC 标识符, 为出站包构建 CSRC 列表。这如图中来自混合器 M3、标记为 M3:89(64,45) 的输出弧所示。与未级联的混合器情况一样, 如果最终的 CSRC 列表包含超过 15 个标识符, 剩余部分无法被包含。