第十二章 多路复用和隧道技术

  • 多路复用的动机
  • 隧道复用压缩 RTP
  • 多路复用的其他方法

多路复用和隧道传输为包头压缩提供了一种替代方案，通过将多个流捆绑在一个传输连接中来提高 RTP 的效率。其目的是通过跨多个流来平摊头部的大小，减少每个流的开销。本章讨论了复用的动机，并概述了用于复用 RTP 流的机制。

多路复用的动机

包头压缩在逐跳的基础上减少单个 RTP 流的包头大小。虽然包头压缩提供了非常高效的传输，但是需要网络的协作（因为头压缩是逐跳进行的，而不是端到端的）。由于附加的计算和特定于流的状态，包头压缩增加了路由器上的负载，在必须同时支持数百甚至数千个 RTP 流的系统中，这两种情况都是不可接受的。

对网络内的计算和状态问题的传统解决方案是将复杂性推到边缘，简化网络的中心，但以边缘的额外复杂性为代价：端到端参数。这个解决方案的应用导表明：如果可能的话，应该减少端到端的包头。你可以通过端到端执行包头压缩来减少包头，从而减少每个包头的大小，或者通过在每个包中放置多个有效负载来减少包头的数量。

在整个端到端的通信中应用RTP头部压缩是可行的，但遗憾的是它并没有带来太大的好处。即使完全删除了RTP头部，UDP/IP头部仍然存在。因此，在典型的IPv4情况下仍然会有28个字节的开销，这显然是无法接受的，尤其是当负载是一个只有14个字节的音频帧时。因此，唯一可行的端到端解决方案是在每个数据包中放置多个负载，以分摊由UDP/IP头部引起的开销。

多个负载数据帧可以来自单个流或多个流，如图12.1所示。将来自单个流的多个负载数据帧放入每个RTP数据包中被称为“捆绑”。正如第4章中所解释的RTP数据传输协议，捆绑是RTP的固有特性，不需要任何特殊支持。它在减少头部开销方面非常有效，但会给媒体流带来额外的延迟，因为在所有捆绑的数据都准备好之前，无法发送数据包。

另一种方法是“多路复用”，即将来自不同流的多个负载数据帧放入一个数据包中进行传输。多路复用避免了捆绑所带来的延迟问题，并且在某些情况下可以显著提高效率。然而，多路复用也并非适用所有场景:

  • 多路复用需要在多路复用点上出现许多具有相似特性的流。如果帧的到达时间不一致，多路复用设备将不得不延迟一些帧，等待其他帧的到达。如果帧的大小不可预测，多路复用设备将无法提前确定可以多路复用多少帧。这可能意味着在帧的大小完全不适合于多路复用时，会发送部分多路复用包。结果是传输效率低下和延迟不稳定这两个问题都没有解决。

  • 为 IP 提出的 QoS 服务质量机制（区分服务和集成服务）在 IP 流的粒度上进行操作。多路复用在一个 IP 流中传输多个流，不可能给这些流提供不同的服务质量。这可能会限制多路复用在使用 QoS 的环境中的有效性，因为多路复用要求所有流具有相同的 QoS。另一方面，如果多路流需要相同 QoS，则多路复用可能会降低QoS的作用。

  • 类似地，多路复用意味着多路复用中的所有流都具有相同程度的错误恢复能力。但是者不一定对于所有流都是合适的 ，因为某些流可能被认为比其他流更重要，并且可以从额外的保护中受益。

尽管存在这些问题，在某些情况下，多路复用RTP流仍然是可取的。最常见的情况是在两个点之间传输大量基本相同的流时。当使用VoIP作为骨干“干线”来替代传统的电话线路时，这种情况经常发生。

RTP 不直接支持多路复用。如果需要在 RTP 中使用多路复用流，则必须使用本章中描述的RTP扩展。

隧道复用压缩 RTP

IETF音视频传输工作组收到了多个RTP多路复用解决方案的提案。这些提案往往是基于不同应用的特定需求。虽然其中一些可能满足了这些应用的需求，但通常没有提供全面的解决方案。然而，少数几个提案中，一种名为“隧道多路复用压缩RTP”（TCRTP）的方案成功保留了RTP的语义。TCRTP被采纳为推荐的“最佳当前实践”解决方案。

TCRTP 的基本概念

TCRTP规范描述了如何将现有协议组合起来提供多路复用系统。它并未引入任何新的机制。TCRTP系统通过将RTP头部压缩、第二层隧道协议（L2TP）和PPP多路复用相结合实现。如图12.2所示，这个协议栈由多个层级组成。RTP头部压缩用于减少单个RTP负载的头部开销。隧道用于在多跳IP网络中传输压缩的头部和负载，而无需在每个链路上进行压缩和解压缩。多路复用用于通过在多个RTP负载间分摊单个隧道头部的方式来减少隧道头部的开销。

多路复用是通过在多个 RTP 有效负载共享一个隧道包头，从而来减少隧道包头的开销。

TCRTP的第一阶段是对头部进行压缩，这一步骤与通常的做法一样，通过在PPP链路上协商使用CRTP或ROHC来完成。但不同之处在于，PPP链路是代表隧道的虚拟接口，而不是真实链路。隧道本身对于头部压缩过程来说是不可见的，只有通过引入的丢包和延迟特性才能感知到其存在。这个概念类似于在虚拟私有网络（VPN）链路上运行RTP，不同之处在于其目的是提供更高效的传输，而不是更安全的传输。

与单个物理链路相比，隧道通常有更长的往返时间和更高的包丢失率，并可能重新排序包。如第 11 章包头压缩所讨论的，与这些属性对 CRTP 包头压缩有不利影响，并可能导致较差的性能。正在开发的 CRTP 的增强功能将减少这个问题。ROHC 不是一个很好的选择，因为它需要按顺序交付，而不能通过隧道来保证。

隧道是通过 L2TP 创建的，它为 IP 网络上的 PPP 会话提供了一个通用的封装。这是一个自然的选择，因为 CRTP 和 ROHC 通常都映射到 PPP 连接上，而 L2TP 允许透明地协商任何类型的 PPP 会话。如果 PPP 层的接口正确实现，CRTP/ROHC 实现将不知道 PPP 链接是一个虚拟通道。

不幸的是，当将隧道包头的开销添加到单个压缩 RTP 有效负载时，与未压缩的 RTP 流传输相比，节省的带宽非常少。需要多路复用来分摊 RTP 有效负载上的隧道头开销。因此，TCRTP 规范提案使用 PPP 多路复用。PPP 多路复用将连续的 PPP 帧组合成一个传输帧。它是在 PPP 连接设置过程中协商的一个选项，并且它支持可变大小和 PPP 帧类型的多路复用，如图 12.3 所示。

PPP在点对点比特流中添加帧结构，以便传输一系列的上层数据包。每个上层数据包至少添加了四个八位字节的帧结构：一个标志字节表示PPP帧的开始，接着是一个协议标识符，然后是作为有效数据的映射上层数据包，最后是一个两个八位字节的校验和（在通道建立期间协商的选项决定是否还有其他帧头）。通过将多个帧多路复用到一个帧中，PPP的开销从每个数据包的四个八位字节减少到两个。

当考虑到隧道开销时，TCRTP 多路复用的需求就变得很明显了。当PPP帧通过L2TP在IP上进行隧道传输时，每个帧会增加36个八位字节的开销（使用L2TP头部压缩HTPU46UTPH可以将这个数字降低到每个帧20个八位字节）。这样的开销增加会抵消头部压缩带来的好处，除非在进行隧道传输之前将帧进行多路复用。

实现 TCRTP

TCRTP 的优点是对上层协议不可见。生成 RTP 包的应用程序不能判断这些包是否被多路复用，而且应该可以在不更改现有应用程序的情况下将多路复用添加到现有应用程序中。

多路复用的通用性使 TCRTP 的使用具有很大的灵活性。例如，TCRTP 可以实现为主机上的虚拟网络接口，以多路复用本地生成的数据包，或者在路由器上实现为在两个公共中间点之间流动的多路复用数据包，或者作为独立网关的一部分，从 PSTN（公共交换电话网络）到 IP网络，在电话系统中多路复用语音呼叫。

根据不同的场景，可以以多种方式实现 TCRTP。一种可能的实现是将 TCRTP 协议栈作为标准的 PPP 网络接口呈现给系统的其余部分，该接口允许协商 RTP 包头压缩。在内部，它将实现 PPP 多路复用和 L2TP 隧道，这种实现对应用程序是透明的。

TCRTP 接口的透明性主要取决于操作系统。如果 IP 协议实现只是松散地耦合到第二层接口，那么应该可以相对容易和透明地添加一个新的接口—TCRTP。如果 IP 层与第二层接口紧密耦合，就像在嵌入式系统中 TCP/IP 实现根据特定链接的特性进行调优一样，那么这个过程可能会更加困难。

与网络堆栈的其他部分相互作用可能是一个更严重的问题。TCRTP是一种隧道协议，它将压缩的RTP/UDP/IP层叠在多路复用的PPP和L2TP之上，然后再层叠在UDP/IP之上。如果操作系统不支持隧道接口的概念，这种IP-over-something-over-IP的层叠可能会带来问题，并需要进行大量的工作来解决。如果系统将隧道接口隐藏在普通网络接口的抽象中，那会很有帮助，否则隧道接口的不同API可能导致与TCRTP不兼容的应用程序。

在TCRTP接口中，必须精确控制多路复用的程度，以限制延迟，并确保在多路复用中包含足够的数据包，以使头部开销保持在可接受的范围内。如果将过少的数据包进行多路复用，每个数据包的头部会变得很大，从而抵消了多路复用的效果。为了避免这个问题，我们可以延迟发送多路复用的数据包，直到它们累积了足够的数据，使头部开销达到可接受的水平。然而，由于交互式应用程序需要总的端到端延迟小于约150毫秒，多路复用不能引入太多的延迟。

非RTP流量也可以通过TCRTP隧道发送，但会显著降低压缩效率，因此最好将其与RTP流量分开。如果不同数据源的发送者配合，确保只有RTP数据包发送到特定的目的地，目的地址可以用来区分这两种类型的流量；可以通过更详细地检查数据包头部（例如，检查数据包是否为UDP数据包且目的端口位于特定范围内）来进行区分。由于RTP不使用固定的端口，无法直接区分RTP流和非RTP流；因此，除非生成这些数据包的应用程序以某种方式与多路复用器配合，否则多路复用器不能确定只传输RTP数据包。

性能

使用TCRTP可以节省带宽，具体取决于多种因素，包括多路复用的增益、隧道内预期的数据包丢失率以及多路复用的RTP和IP头部字段的变化速率。

多路复用减少了由于 PPP 和 L2TP 包头而造成的开销，并且随着越来越多的流加入多路复用 PPP 帧中，这种节省的比例增加。当更多的流被复用在一起时，性能一定提高，尽管每个流的增量增益随着复用中的流总数的增加而减少。

丢包率和包头字段的变化率会对包头压缩效率产生不利影响。丢包会导致上下文失效，在刷新上下文时压缩方法切换到效率较低的操作模式。如果使用标准的CRTP，问题尤其严重；而使用增强的CRTP可以稍微改善。包头字段的更改也可能导致压缩转换为效率较低的操作模式，从而发送一阶增量而不是完全压缩的二阶增量。对于这些情况，我们无法做太多改善，只能参考第11章中关于“RTP应用程序注意事项”的部分，其中也涉及到包头压缩和TCRTP。

TCRTP规范包含一个简单的性能模型，旨在预测使用增强的CRTP压缩的语音流在IP上所需的带宽、数据包大小和持续时间、平均通话长度、可复用的数据包数量以及由于RTP和IP包头的压缩变化而导致的开销估计。根据该模型的预测，对于一个G.729流，TCRTP将达到14.4 Kbps的速率。该流的数据包大小为20毫秒，有三个多路复用的数据包，并且平均对话并发长度为1500毫秒。这与逐跳CRTP实现的12Kbps以及没有包头压缩或多路复用的标准RTP（所有数字都包括由于PPP-in-HDLC[高级数据链路控制]帧造成的第二层开销）的25.4 Kbps形成了鲜明的对比。

当然，性能将严重依赖于媒体和网络的特性，但在这个示例中所见到的性能差异并不是不切实际的。只要有足够的流量进行多路复用，TCRTP的性能将明显优于标准的RTP，但略逊于逐跳头部压缩。

多路复用的其他方法

在 IETF 内部，多路复用一直存在一些争议和大量需要讨论的领域。虽然 TCRTP 是当前推荐的最佳实践，但还有其他一些建议值得进一步讨论。这包括通用的 RTP 多路复用 (GeRM)，它是 TCRTP 的少数几个保持 RTP 语义的备选方案之一，以及几个特定于应用程序的多路复用。

GeRM

多路复用一直是IETF内部争议不断、讨论热烈的领域。尽管TCRTP被推荐为目前最佳实践，但还有其他值得进一步讨论的提案。其中包括通用RTP多路复用（GeRM），它是为数不多保持RTP语义的TCRTP替代方案之一，还有一些面向特定应用的多路复用方案。

概念和包格式

图12.4展示了GeRM的基本操作。首先创建一个单独的RTP数据包，然后在其中复用多个称为子数据包的RTP数据包。每个GeRM数据包都有一个外部的RTP头部，其中包含第一个子数据包的头部字段，但RTP有效载荷类型字段的值被设置为指示这是一个GeRM数据包的特定数值。

除了有效负载类型字段和长度外，第一个子包的包头将完全被压缩，因为完整的RTP包头和子包包头只在有效负载类型方面有所不同。然后，根据第二个子包的原始RTP包头与第一个子包的原始RTP包头之间预测的差异来对第二个子包的包头进行编码。接下来，第三个子包的包头基于其原始RTP包头与第二个子包的原始RTP包头的编码方式，以此类推。每个子包的包头由一个固定的8字节组成，后面跟着几个扩展的8字节，如图12.5所示。

强制八位中的位的含义如下：

B0: 0 表示原始 RTP 包头的第一个八位组与前一个子包中的原始 RTP 包头保持不变（如果此包中没有前一个子包，则为外 RTP 包头）。也就是说，V CC P 不变。1 表示原始 RTP 包头的第一个八位元紧接在 GeRM 包头之后。

B1: 这位包含子数据包 RTP 包头的标记位。 B2:0 表示负载类型保持不变。1 表示有效负载类型字段跟在 GeRM 头和任何可能出现的包头首字节之后。虽然 PT 是一个 7 位字段，但它是作为一个 8bit 字段添加的。这个字段的第 0 位总是 0。 B3:0 表示序列号保持不变。1 表示 16bit 序列号字段位于 GeRM 包头和可能存在的任何包头首字节或 PT 包头之后。 B4:0 表示时间戳保持不变。1 表示 32bit 的时间戳字段位于 GeRM 包头和可能存在的任何包头首字节、PT 或序列号包头之后。 B5:0 表示 SSRC 的最高有效的 24 位保持不变。1 表示 SSRC 最高有效的 24 位位于 GeRM 头和可能存在的PT、序列号或时间戳字段之后。 B6:0 表示 SSRC 的最低有效 8bit 比前一个 SSRC 高 1 位。1 表示 SSRC 的最低有效的 8bit 位于源包头和可能存在的首八位、PT、序列号、时间戳或 MSB SSRC 包头字段之后。 B7:0 表示以字节为单位的子包长度（忽略子包包头）与前面的子包相同。1 表示子包长度（忽略子包包头）遵循所有其他 GeRM 包头作为一个 8bit 无符号整数长度字段。一个 8bit 长度的字段就足够了，因为较大的数据包通过多路复用可以获得的增益很少。

原始 RTP 包头中存在的 CSRC 字段，跟随在原始包头。接下来的是 RTP 有效负载。

应用场景

由于 GeRM 而节省的带宽取决于多路复用包之间的包头的相似性。考虑两个场景：任意的包和协作应用程序生成的包。

如果要对任意的 RTP 包进行多路复用，则多路复用的增益很小。如果包之间没有相关性，那么所有可选字段都将出现，并且子包包头的长度为 14 字节。与非多路复用的 RTP 相比，仍然有优势，因为一个 14 字节的 RTP/UDP/IP 包头比 40 字节的 RTP/UDP/IP 包头要小，但是与标准包头压缩相比，节省的带宽相对较小。

如果要进行多路复用的包是通过协作应用程序产生的，则由 GeRM 节省的带宽可能要大得多。在最简单的情况下，所有要复用的包都具有相同的有效负载类型、长度和 CSRC 列表；除了第一个子数据包包头外，所有的字节都被删除了 3 个字节。如果生成包的应用程序相互协作，它们可以合作以确保子包中的序列号和时间戳匹配，从而节省额外的 6 个字节。如果应用生成具有连续同步源标识符的分组，也允许移除 SSRC，则可以节省更多带宽。

当然，这种相互协作扩展了RTP的应用范围。特别是，对于生成非随机SSRC标识符的应用程序，可能会在与使用标准RTP的发送端进行会话时引起严重问题。然而，在某些情况下，使用非随机SSRC是可以接受的：

  1. 当使用 RTP 和 GeRM 在两个网关之间传输媒体数据时。在这种情况下，数据的发送端和接收端意识不到 RTP 和 GeRM 被用来传输数据也算是一种幸运。例如，一个系统可以生成 ip 上的语音数据包，作为两个 PSTN 交换之间的网关的一部分。
  2. 当复用设备在被包含进 GeRM 之前重新映射 SSRC 时，用多路复用设备重新生成原始的 SSRC。在这种情况下，SSRC 标识符映射必须在带外发出信号，但这可以作为调用设置过程的一部分。

在最好的情况下，GeRM 可以生成每个多路复用数据包带有2字节标头的数据包，与非多路复用 RTP 相比，这可节省大量带宽。与非多路复用 RTP 相比，GeRM 将始终减少包头开销。

GeRM 的未来

GeRM 不是一个标准的协议，目前也没有计划完成它的规范。这样做有几个原因，其中最主要的原因是，如果在网络中应用了 GeRM，应用程序在生产 RTP 包头时协作的要求将限制协议的应用范围并影响互操作性。此外，带宽节省相对较小，除非这种协作发生，这可能使 GeRM 不那么有吸引力。

作为特定于应用程序的多路复用器，GeRM 的概念非常有用，它位于两个网关之间，这两个网关使用相同的编解码器对多个 RTP 流进行发送和接收，并且愿意为这些流协作生成 RTP 包头。典型的例子是 IP-PSTN 网关，其中 IP 网络充当两个 PSTN 交换机之间的长途中继链路。GeRM允许这样的系统保持大部分RTP语义，同时提供高效的多路复用，并且可以仅在应用层实现。

特定于应用程序的多路复用

除了 TCRTP 和 GeRM 等通用多路复用协议外，还提出了各种特定于应用的多路复用协议。这些多路复用的绝大多数都是针对 IP 到 PSTN 网关的，其中 IP 网络充当两个 PSTN 交换之间的长途中继。这些网关之间有许多并发的语音连接，可以通过多路复用来提高效率，支持使用低比特率的语音编解码器，提高可伸缩性。

这种网关通常使用 RTP 协议的一个非常有限的特性子集。所有要进行多路复用的流通常使用相同的有效负载格式和编解码器，它们可能不采用静音抑制。此外，每个流表示单个会话，因此不需要 RTP 的混流功能。所以 RTP 包头的 CC、CSRC、M、P 和 PT 字段是冗余的，序列号和时间戳之间有一个常量关系，可以省略其中一个。删除这些字段后，只剩下序列号/时间戳和同步源 (SSRC) 。鉴于 RTP 的使用如此有限，显然有必要在这些场景中使用特定于应用程序的多路复用。

将几个RTP流转换为具有减少头部的单个多路复用是一种特定于电话通信的多路复用操作。在最简单的情况下，这种多路复用可以将仅包含序列号和同步源的数据包组装成UDP数据包，并使用带外信令来定义这些减少的头部与完整RTP头部之间的映射关系。根据应用程序的不同，多路复用可以在真实的RTP数据包上进行操作，也可以是将PSTN数据包直接转换为多路复用数据包。目前还没有针对这种特定应用的多路复用的标准解决方案。

作为一种替代方案，可以为TDM（时分多路复用）有效负载定义一种RTP有效负载格式。这将允许直接传输PSTN语音，而无需首先将其映射到RTP。该格式可以被定义为一种"电路仿真"格式，旨在传输内容而不关心其内容。

在这种情况下，RTP头部将与链路相关联。同步源(SSRC)、序列号和时间戳与链路相关，和同意链路上的其他会话无关；有效载荷类型标识“T1仿真”；混音器功能相关字段未被使用，标记位和填充也未被使用。图12.6展示了该过程可能的工作方式，每个T1帧形成一个单独的RTP数据包。

当然，由于 RTP 开销很大，对 T1 线路的直接模拟收益很少。但是，在每个 RTP 包中包含几个连续的 T1 帧是完全合理的，或者模拟一个更高速率的链路，这两者都可以显著降低 RTP 开销。

IETF 有一个伪线边缘到边缘仿真工作组，该工作组正在开发电路仿真标准，包括 PSTN（公共交换电话网）、SONET（同步光网络）和 ATM（异步传输模式）电路。这些标准还没有完成，但 RTP 负载格式的电路仿真是一个建议的解决方案。

用于 ip-pstn 网关设计的电路仿真方法比特定于应用程序的多路复用解决方案更符合 RTP 原理。强烈建议将电路仿真作为此特定应用程序的解决方案。

总结

多路复用通常是不可取的。它强制所有媒体流使用单一传输，阻止接收端根据需要对其进行优先级排序，并使其难于应用错误纠正。在几乎所有情况下，包头压缩都提供了更合适、更高效的解决方案。

然而，在某些有限的情况下，多路复用可能是有用的，主要是当许多本质上相同的流在两个点之间传输时，这种情况经常发生在 ip 电话被用作取代传统电话线的主干“中继线”时。