第三章实时传输协议

RTP 的基本设计理念
RTP 的标准元素
相关标准
未来标准的开发

本章我们从设计的理念和背景出发，描述 RTP 协议的整体设计思路。并大致介绍了RTP标准协议适用的场景和协议是如何适配这些场景的，最后发散的讨论了RTP协议今后的发展方向。

RTP 的基本设计理念

在不可靠的传输层之上构建健壮的实时的媒体传输机制是RTP协议的设计者们面对的最大挑战。在兼顾了应用框架设计和端到端传输设计原则与规范的同时, 协议设计者们很好的完成了这个任务。

应用级框架

Clark 和 Tennenhouse 在 1990 年首次提出应用级框架思想，应用级框架的中心观点是：应用想要对数据传输作出正确的决策，必须对数据有足够的了解。这意味着传输协议应该理解数据中的元素，而且传输层需要尽可能向应用层公开传输细节，以便应用在出现传输异常时能够做出适当的决策。应用层与传输层合作，共同实现可靠的传输。

应用级框架源于这样一种认知，应用可以通过多种多样的方法从网络异常中恢复，场景决定那个方法是最合适的的。例如：某些情况下，需要重新传输丢包的精确副本。而另外一些情况下，可能会使用保真度较低的副本。又比如，那些时效性要求高的数据，我们可以忽略丢包。只有在应用层与传输紧密配合下，才能作出对合适的决策。

应用级框架的目标与 TCP 的设计思路有些不一致的地方，TCP 的设计隐藏了底层 IP 网络的有损特性，牺牲时效性来实现可靠的传输。但是，应用级框架非常适合基于 UDP 的传输和实时媒体的特性。如第二章所述，分组网络上的实时音视频通信通常是能够容错的，但是实时性要求高。使用基于 UDP 传输的应用级框架，我们可以在必要时接受丢包，也可以灵活地使用端到端的恢复技术，如在适当的情况下重传和错误恢复(PLC)。

这些恢复技术为应用提供了极大的灵活性，使其能够以适当的方式对网络异常作出处理，而不单一的受传输层的约束。

根据应用级框架原则设计的网络传输协议不应针对特定的应用。相反，它应该暴露通用传输层的局限性，以便应用能够与网络合作，实现尽可能最好的交付。应用级框架意味着对 OSI 参考模型严格层分层的弱化。这是一种务实的做法，既承认分层的重要性，也根据实际需要暴露底层的一些细节。

应用级框架的设计哲学就是对网络异常作出快速且正确的响应。

端到端原则

端到端原则是设计可靠网络通信系统的两种方法之一：

系统把正确交付数据的责任连同该数据一起传递，逐跳保证可靠性。
可靠传输的责任由端点负责。即使各跳不可靠，也可以由端点确保端到端的可靠性。

Internet 设计的采用了端到端保障方法，TCP 和 RTP 都遵循端到端原则。

如果使用端到端的方法，数据流逐级向上，直到协议栈的顶部。路径上的节点不负责数据保护，那么协议的实现就会简单化，而且没有健壮性的要求。如果丢弃了无法传输的数据，在没有中间节点的帮助下，端点也有能力恢复。端到端原则意味着信息是在端点上，而不是在网络中。

其结果是一个包含智能感知网络端点和哑网络（不智能的网络）的设计。这种设计非常适合 Internet（可能是最基本的哑网络）, 但是需要应用设计人员进行大量的工作。它的设计也不同于其他许多网络。以传统的电话网为例，它采用了智能网络和哑端点的模型，而 MPEG 传输模型允许哑接收端和智能发送端。这种设计上的差异改变了应用的风格，更加强调接收端的设计，使发送端和接收端在传输中更加平等。

实现灵活性

RTP 协议可以满足许多场景，而几乎不需要额外的协议支持。在很大程度上，这个设计是基于视频会议的轻量级会话模型。在这个场景中，RTCP 协议提供了所有必要的会话管理功能，连接会话所需的全部内容是 IP 地址和媒体类型映射（从媒体定义到 RTP 有效负载类型标识符）。这个模型也适用于一对多个场景例如：网络电台。RTCP 提供的反馈可以给信息源一个关于观众规模和接收质量的预估。

一些人认为，对于单播语音通话， RTP 提供了不多余的功能，且这些功能对于高度压缩的语音帧来说是冗余且低效的。而且 RTP 所提供的特性可以轻松地扩展到多媒体多方会话。还有一些人（例如数字电影社区）认为 RTP 没有充分满足他们的需求，应该包括更强的服务质量和安全支持，更详细的统计数据等等。

RTP 的优点是它提供了一个统一的实时音频/视频传输框架，可以直接满足大多数应用，但对于那些超出其限制的应用来说，它是可塑的。

RTP 的标准元素

IP 网络中音频/视频传输的主要标准是实时传输协议 (RTP)，以及相关的 Profile 和有效负载格式。RTP 是由互联网工程任务组 (IETF) 的音频/视频传输工作组开发的，它已经被国际电信联盟 (ITU) 作为其 H.323 系列建议的一部分，并被其他几个标准组织采用。

RTP 为实时媒体的传输提供了一个框架，在完成之前对 RTP 的特定用途进行概要说明。音频和视频会议的最小控制 RTP Profile 与 RTP 一起被标准化，另外一些 Profile 正在开发中。每个 Profile 都附有几个有效载荷格式规范，每个规范描述了特定媒体格式的传输

RTP 规范

RTP 于 1996 年 1 月 6 日作为 IETF 拟议标准 (RFC1889) 发布，其标准草案的修订已基本完成。国际电联建议 H.323 的第一次修订就包括了 RTP 规范的副本；后来的修订参考了当前的 IETF 标准。

在 IETF 标准过程中，规范经历了一个开发周期，在此期间，随着设计细节的确定，将生成多个互联网草案。当设计完成时，它作为一个建议的标准 RFC 发布。建议的标准通常被认为是稳定的，解决了所有已知的设计问题，适合实现。如果该标准被证明是有用的，并且该标准的每个特性都有独立的、可互操作的实现，那么它就可以被提升到标准草案的状态（可能包括修改以纠正在该标准中发现的任何问题）。最后，经过广泛的经验，它可以作为一个完整的标准 RFC 发布。超出所提议的标准状态的改进是造成许多协议从未实现的主要障碍。

RTP 通常位于 UDP/IP 传输之上，通过丢包检测和接收质量报告、时序恢复和同步、有效负载和源标识以及媒体流中重要事件的标记来增强传输。 RTP 的大多数实现是应用或库的一部分，该应用或库位于操作系统提供的 UDP/IP 套接字接口之上。但是，这不是唯一可能的设计，且 RTP 协议中的任何内容都涉及 UDP 或 IP。例如，某些实现基于 TCP/IP 之上的 RTP，而其他实现甚至在非 IP 网络（例如异步传输模式（Asynchronous Transfer Mode，ATM）网络）上使用 RTP。

RTP 包括两部分：数据传输协议和相关的控制协议。RTP 数据传输协议管理终端系统之间的实时数据传输，如音频和视频。它为媒体有效负载定义了额外的帧级别，包括用于丢包检测的序列号、用于恢复时序的时间戳、有效负载类型和源标识符，以及媒体流中重要事件的标记。还指定了使用时间戳和序列号的规则，尽管这些规则在某种程度上依赖于使用的配置文件和有效负载格式，以及在一个会话中多路复用多个流。第四章进一步讨论了 RTP 数据传输协议。

RTP 控制协议 (RTCP) 提供接收质量反馈、参与者识别和媒体流之间的同步。RTCP 与 RTP 一起运行，并定期报告这些信息。虽然数据包通常每隔几毫秒发送一次，但控制协议以秒为单位进行操作。RTCP 中发送的信息对于媒体流之间的同步是必要的——例如，对于音频和视频之间的同步，并且可以根据接收质量反馈调整传输和识别参与者。第五章进一步讨论了 RTP 控制协议。

RTP 支持混合器和翻译器的概念，即相当于中间盒，当它在媒体端点之间流动时可以进行操作。它们可以用于在不同的底层协议之间转换 RTP 会话—例如，在 IPv4 和 IPv6 网络上的参与者之间进行桥接，或者将单播参与者引入多播组。它们还可以以某种方式调整媒体流——例如，转换数据格式以减少带宽，或者将多个流混合在一起。

很难将 RTP 放在 OSI 的参考模型中。它执行许多通常分配给传输层协议的任务，但它本身并不构成一个完整的传输层。RTP 还执行会话层（跨越不同的传输连接并以与传输无关的方式管理参与者标识）和表示层（为媒体数据定义标准表示）的一些任务。

RTP Profile

了解 RTP 协议规范的限制非常重要，因为它在两方面刻意不完整。首先，该标准没有指定用于媒体播放和时序、媒体流之间的同步、错误隐藏和纠正或拥塞控制的算法。这完全是应用设计人员的职责范围，因为不同的应用有不同的需求，所以如果标准要求使用单一的行为，那就太愚蠢了。当然，它确实为这些算法提供了必要的信息，以供它们实现。后面的章节将讨论应用设计和提供这些特性必要性的权衡。

其次，传输的一些细节可以通过配置文件和有效负载格式定义进行修改。这些特性包括时间戳的解析、媒体流中感兴趣事件的标记和有效负载类型字段的使用。可以通过 RTP 配置文件指定的功能包括：

RTP 报头中的有效负载类型标识符与有效负载格式规范之间的映射（有效负载格式规范描述了如何在 RTP 中使用单个媒体编解码器）。每个配置文件将引用多个有效负载格式并可能指示如何使用特定的信令协议（例如 SDP) 来描述映射。
RTP 报头中的有效负载类型标识符字段的大小，以及用于标记媒体流中感兴趣的事件的位数。
固定的 RTP 数据传输协议报头的补充部分，如果该报头被证明不足以用于特定的应用类。
RTP 控制协议的报告间隔——例如，以牺牲额外的开销为代价使反馈更及时。
如果 RTCP 所提供的某些信息对应用没有用处，则对所使用的 RTCP 包类型进行限制。此外，配置文件可以定义 RTCP 的扩展以报告额外信息。
附加的安全机制——例如，新的加密和认证算法。
将 RTP 和 RTCP 映射到底层传输协议。

在撰写本文时，只有一个 RTP Profile: 用于音频和视频会议的 RTP Profile，只有很少的控制。这个配置文件在 1996 年 1 月作为一个标准的提按 (RFC 1890) 和 RTP 规范一起发布，当时其标准状态草案的修订几乎已经完成。一些新的 Profile 正在开发中。安全性的配置文件，以及反馈和修复机制，这些内容可能很快就会提供。

RTP 有效负载格式

RTP 框架的最后一部分是有效负载格式，它定义了在 RTP 中如何传输特定的媒体类型。有效负载格式由 RTP 配置文件引用，它们还可以定义 RTP 数据传输协议的某些属性。

尽管配置文件也可以为有效负载格式指定一些常规行为，但是 RTP 有效负载格式和配置文件之间的关系主要是一个名称空间。名称空间将 RTP 包中的有效负载类型标识符与有效负载格式规范联系起来，从而允许应用将数据与特定的媒体编解码器联系起来。在某些情况下，有效负载类型和有效负载格式之间的映射是静态的；在其他情况下，通过带外控制协议，映射是动态的。例如，具有最小控制的音频和视频会议的 RTP 配置文件定义了一组静态负载类型分配，以及一种机制，用于在标识负载格式的 MIME 类型和使用会话描述协议 (SDP) 的负载类型标识之间进行映射。

有效负载格式和 RTP 数据传输协议之间的关系是双重的：有效负载格式将指定某些 RTP 头字段的使用，并且可以定义附加的有效负载头。媒体编解码器产生的输出被转换成一系列的 RTP 数据包—一些部分映射到 RTP 报头，一些映射到有效负载报头，大部分映射到有效负载数据。这种映射过程的复杂性取决于编解码器的设计和所需的错误恢复程度。在某些情况下，映射很简单；而另一些情况则更为复杂。

最简单的情况下，有效负载格式只定义了媒体时钟和 RTP 时间戳之间的映射，并要求将每一帧的编解码器输出直接放到一个 RTP 包中进行传输。这方面的一个例子是 G.722.1 音频的有效负载格式。不幸的是，这在许多情况下是不够的，因为许多编解码器的开发没有参考包传输系统的需要，因此需要调整以适应这种环境。其他的是为分组网络设计的，但是需要额外的头信息。在这些情况下，有效负载格式规范定义了一个附加的有效负载包头以及该包头的生成规则，其中有效负载包头放置在主 RTP 包头之后。

许多有效负载格式已经被定义，与目前使用的多种编解码器相匹配，还有许多正在开发中。在撰写本文时，以下音频有效负载格式是常用的，尽管这不是一个详尽的列表：G.711, G.723.1, G.726, G.728, G.729, GSM, QCELP, MP3，和 DTMF。常用的视频有效负载格式包括 H.261、H.263 和 MPEG。

还有指定错误恢复方案的有效负载格式。例如，RFC 2198 定义了一个音频冗余编码方案，RFC 2733 定义了一种通用的基于奇偶校验编码的前向纠错方案。在这些有效负载格式中有一个额外的间接层，编解码器输出被映射到 RTP 包，这些包本身被映射来产生一个带容错的传输。误差校正将在第 9 章《错误恢复》中详细讨论。

可选的元素

RTP 框架的两个可选部分在这个阶段值得一提：头压缩和多路复用。

报头压缩是一种方法，通过这种方法可以在每个链接的基础上减少 RTP 和 UDP/IP 报头的开销。它用于带宽受限的链路（例如蜂窝链路和拨号链路），可以将 RTP/UDP/IP 报头的 40 字节组合减少到 2 字节，代价是压缩链路两端的系统需要额外处理。包头压缩将在第 11 章进一步讨论。

多路复用是将多个相关的 RTP 会话组合成一个的方法。同样，这样做的动机也是为了减少包头的开销，只不过这次是端到端的操作。多路复用将在第 12 章《多路复用和隧道》中讨论。

包头压缩和多路复用都可以被认为是 RTP 框架的一部分。与配置文件和有效负载格式不同，它们显然是系统的用于特殊用途的可选部分，而且许多实现都不使用这两个特性。

调用设置和控制

根据应用场景，可以使用各种呼叫设置、控制和广告协议来启动 RTP 会话：

为了启动交互式会话，无论是语音电话呼叫还是视频会议，有两个标准。这方面的最初标准是 ITU 建议 H.323，最近 IETF 定义了会话发起协议 (SIP)。
为了开始一个非交互式会话，例如视频点播，主要的标准是实时流协议 (RTSP)。
RTP 最初的用途是与 IP 组播和轻量级会议模型一起使用。本设计采用了会话通知协议 (SAP) 和 IP 多播通知正在进行的会议，如向公众开放的研讨会和电视广播。

就会话中的参与者数量和这些参与者之间的耦合而言，这些协议的需求非常不同。有些会话是松耦合的，只有有限的成员控制和参与者的知识。其他的则是严格管理的，需要明确的许可才能加入、交谈、聆听和观看。

这些不同的需求导致为每个场景设计了非常不同的协议，并且在这个领域中正在进行大量的工作。RTP 故意不包含会话发起和控制功能，这使得它适用于广泛的应用。

作为应用设计人员，除了 RTP 提供的媒体传输之外，还必须实现某种形式的会话发起、调用设置或调用控制。

会话描述

所有设置和通知协议都需要一种描述会话的方法。在这个领域中一个常用的协议是会话描述协议 (SDP)，尽管也可能使用其他机制。

不管会话描述的格式如何，始终需要某些信息。媒体流所在的传输地址、媒体的格式、要使用的 RTP 有效负载格式和配置文件、会话活动的时间以及会话的目的等必须传递。

SDP 将这些信息打包成一种文本文件格式，这种格式是人类可读的，并且易于解析。在某些情况下，该文件直接传递给 RTP 应用，从而提供足够的信息来直接加入会话。在另一些情况下，会话描述是协商的基础，是呼叫设置协议的一部分，然后参与者才能进入严格控制的电话会议。

第四章 RTP《数据传输协议》对 SDP 进行了详细的讨论。

服务质量

虽然 RTP 的设计是通过 IP 提供的最佳服务进行操作，但有时能够保留网络资源是有用的，从而提高了 RTP 流的服务质量。再说一遍，这不是 RTP 提供的服务，需要另一个协议的帮助。在撰写本文时，还没有普遍接受的在互联网上保留资源的“最佳实践”。存在两个标准框架，集成服务和差异化服务，每个框架的部署都很有限。

通过使用资源保留协议 (RSVP)，集成服务框架提供了严格的服务质量保证。路由器需要将可用容量划分为服务类，并考虑流量使用的容量。在开始传输之前，主机必须向路由器发出它的需求信号，只有在所需的服务类中有足够的容量时，路由器才允许保留成功。只要所有的路由器都尊重服务类，并且不过度承诺资源，这个需求就可以防止链接超载，从而提供有保证的服务质量。可用的服务类别包括有保证的服务（提供有保证的带宽水平、严格的端到端延迟限制、无阻塞性数据包丢失）和可控负载（提供与少量负载的最佳工作网络相当的服务）。

集成服务框架和 RSVP 需要对每个流程进行预订，并且难以聚合这些预订。因此，将 RSVP 扩展到大量的异类保留是有问题的，因为路由器必须保持大量的状态，而这个约束限制了它的部署。

差异化服务框架对服务质量采取了一种稍微不同的方法。它没有提供端到端资源保留和严格的性能保证，而是定义了几个每跳排队行为，通过在每个包的 IP 报头中设置服务类型字段来选择这些行为。这些单跳行为使路由器能够优先处理某些类型的流量，从而降低包或延迟的概率，但是由于路由器无法控制允许进入网络的流量数量，因此无法绝对保证满足性能限制。差别化服务框架的优点是它不需要复杂的信令，并且状态需求比 RSVP 小得多。缺点是它只提供统计上的保证。

集成和差异化服务框架的组合非常强大，未来的网络可能会将它们组合在一起。RSVP 可用于向边缘路由器发出应用需求的信号，然后这些路由器将这些需求映射到不同的服务流量类。这种组合允许边缘路由器拒绝过多的流量，提高了差异化服务网络所能提供的保障，同时将 RSVP 所需的状态保持在网络核心之外。

这两个框架都占据一席之地，但在撰写本文时，它们都没有达到临界量。未来的网络可能会采用某种形式的服务质量，但这一点也不确定。在此之前，我们的任务是使应用在当前部署的最佳网络中运行良好。

未来的标准开发

随着 RTP 标准草案状态的修订，协议规范中已没有已知的未解决的问题，并且 RTP 本身在可预见的将来也不会改变。但是，这并不意味着标准工作已经完成。新的有效负载格式一直在开发中，新的配置文件将扩展 RTP 以包含新的功能（例如，用于安全 RTP 和增强反馈的配置文件）。

从长期来看，我们期望 RTP 框架与网络本身一起发展。网络中未来的变化也可能影响 RTP，我们希望利用任何变化，来开发新的配置文件。我们还期待一系列新的有效负载格式规范，以跟上编解码器技术的变化，并提供新的错误恢复方案。

最后，我们可以预期在呼叫设置和控制、资源保留和服务质量方面的相关协议会有相当大的变化。这些协议比 RTP 更新，而且目前正在快速发展，这意味着这里的更改可能比 RTP、其配置文件和有效负载格式的更改更重要。

总结

RTP 提供了一个灵活的框架，用于通过 IP 网络传输实时媒体，如音频和视频。它的核心哲学——应用级框架和端到端原则——使其非常适合 IP 网络的独特环境。本章概述了 RTP 规范、配置文件和有效负载格式。相关标准包括呼叫设置、控制和广告，以及资源保留。本章介绍的 RTP 的两部分——数据传输协议和控制协议——将在接下来的两章中详细讨论。

RTP-Audio-and-Video-for-the-Internet