流媒体传输协议之 RTP （上篇）

介绍

RTP，即 real-time transport protocol（实时传输协议），为实时传输交互的音频和视频提供了端到端传输服务。其中包括载荷的类型确认，序列编码，时间戳和传输监控功能。一般应用都是基于 UDP 协议，来使用 RTP 的多路技术以及验和服务。然而，RTP 还可以与其它适合的协议并用，如果底层网络支持多路分发，RTP 还可以将数据传输给多个目标。

需要注意的是 RTP 不提供任何机制以保证数据的实时性和 QOS (quality-of-service)，而是依赖底层的服务来提供这些功能，RTP 既不保证传输的可靠性也不保证无序传输，同时也不假定底层网络是可信任的和有序的。接收端可以利用 RTP 中的序列号排序收到的报文。

RTP 与 RTCP

实时传输协议 (RTP)，传输具有实时特性的数据

RTP 控制协议 (RTCP)，监控 QOS 和传递会话中参与者的信息。它没有明确的成员控制功能和 Session 建立过程，但这些对一个相对宽松的 Session 控制来说已经足够了，它没有必要包含一个应用的所有控制功能。 RTP 代表了一种新型协议，它遵循 Application level framing 和 Integrated layer processing。即 RTP 可以比较容易的拓展以传递某些特定需要的内容，而且可以比较容易地集成进某个应用，而不是作为一个独立的补充层。RTP 协议被故意地设计成不完整的协议框架。

RTP 的使用场景

下面的例子描述了 RTP 的部分特性，选择的例子是用来阐明基于 RTP 的应用的基本操作，而不是说 RTP 仅能用于此类应用。 简单的多播音频会议

一个小组要通过网络开一个音频会议，他们用了 IP 多播服务。基于某种分配机制，小组得到了一个多播组地址和一对端口，其中一个端口是用来传输音频数据的，另一个是用来传输 RTCP 报文的。这个组播地址和端口发给了所有与会者。如果想要引入一些安全策略，可以对数据报文和控制报文加密，然后把加密时用到的密钥分发给与会者。

这个音频会议软件，可能会一直发送时长为 20ms 的音频数据包。每个实际音频数据包，都以 RTP 头数据开始，然后再以 UDP 协议封装并发送。RTP 包的头部标识了该包的数据类型，以便消息发送器来改变数据的编码。例如，针对低带宽的与会者进行一些调节，或者对网络拥堵作出反应。

像 UDP 这类包类型的网络，偶尔会丢包，乱序，延迟不定长时间。为了解决这类意外情况，RTP 包中包含了时间信息和序列号，这样接收者就可以通过它们重排数据包的时序。在这个例子中，我们就可以按顺序地播放每个 20ms 的音频数据。在会议中对每个数据源的 RTP 报文时序重排都是独立进行的。接收者也可以通过序列号来确定丢失了多少报文。

因为这个小组开会期间，会有一些人加入或退出这个网络会议，所以我们需要知道具体是谁加入了会议，以及他们有没有正常地接收到音频数据。出于这个目的，每个网络会议的客户端都会周期性的通过 RTCP 端口报告使用者的名字以及自己接收数据的情况，如果有人接收数据不正常，可能就需要对应的改变编码。而且，除了用户的名字之外，还会有一些别的信息，用来控制带宽限制。当有人从视频会议中退出时，还需要发送一个 RTCP BYE 报文。

音频和视频会议

如果这个会议既要传输音频又要传输视频的话，它们会以独立的 RTP Session 传输。也就是说，负责音频传输的部分和负责视频传输的部分会通过不同的组播地址（和端口对）分别传输各自的 RTP 报文和 RTCP 报文。在 RTP 协议这一层，音频和视频 Session 并没有被组合到一起。我们期望与会者用同一个名字来建立音频和视频 Session，这样这两个 Session 就能联系起来了。

RTP 协议之所以这样设计，一个原因是某些与会者可以选择只接收某一种类型的数据（只接收 Audio）。即便 Audio 数据和 Video 数据是独立分发的，但是我们仍然可以通过参考 RTCP 协议中时间信息来同步播放它们。

Mixers & Translators

到目前为止，我们都是假设所有的与会者想要接收同一格式的媒体数据。但是这显然不太合适，考虑一下，可能某些与会者网速相对较慢，而其他人网速却比较快。对于这种情况，我们不应该强迫所有人都用低带宽并降低音频编码的质量，而是使用 RTP 级别的中继节点（Mixer）来给周围低带宽用户分发低带宽消耗的数据。

这个 Mixer 将接收到的不同与会者的音频数据同步，并将它们耦合到一个单一流中，然后将这个流用低带宽消耗的编码方案进行压缩，最后发送给那些低带宽的与会者。Mixer 可以在 RTP 头部写一些特殊内容，来表明该 Mixer 包具体耦合了哪些与会者，这样，接收到该 Mixer 包的人就能确定当前说话的人是谁了。

此外，有些与会者可能处于应用级防火墙的后面，无法仅通过 IP 组播访问。这种情况下 Mixer 就没有什么意义了，他们需要另一类 RTP 级别的中继（Translator）。我们需要两个 Translator，安装在防火墙的两面，外面的 Translator 将收到的所有组播报文，通过一个安全连接传输给防火墙里面的 Translator。然后，防火墙里的 Translator 再将这些报文分发给内网的与会者。

层编码

多媒体应用可以根据接收者的能力或者网络拥堵的情况调整传输速率。许多实现将码率控制的责任放在了发送端。这和组播模式不太兼容，因为各个不同的数据接收者会有不同的带宽情况，这就会产生木桶效应，即带宽最差的接收者会拖垮整个会议的通讯质量。

因此，带宽自适应的工作应该放到接收者这里，发送者需要拆分出面向不同带宽与会者的媒体流（500K，2M，5M），它们分别对应了不同的组播地址，数据的接收者根据自己的带宽情况，选择加入适合的组播。 定义

RTP payload：RTP 包中传输的数据，比如音频采样数据或者压缩过的视频数据。 RTP packet：由定长 RTP 头部，数据来源者的列表，RTP payload 组成的数据包。一些下层协议可能会自己定义 RTP 的封装格式。一般来说，一个下层协议包只包含一个 RTP 包，但是也有可能多个 RTP 包被合并到一起。 RTCP packet：RTP 控制报文，由定长的 RTC 头部开始，之后会跟着一些结构化的元素，它们在 RTCP 发挥不同功能时，会有不同的结构。通常多个 RTCP 包会被合在一起，通过一个下层协议包一起发送。 Port：传输层协议中用来区分某一主机下不同应用的抽象。RTP 协议依赖更底层网络提供端口机制，继而提供多播的 RTP 和 RTCP 报文。 Transport address：网络地址和端口的组合，用来定位传输层的节点。 RTC media type：一个 RTP Session 中所用到的所有 payload 类型的合集。 Multimedia Session：视频会议组中同时工作的一组 RTP Session。例如，视频会议中的 Audio Session 和 Video Session。 RTP Session：一组参与者利用 RTP 来通讯的组合。一个参与者可以同时加入到多个 RTP Session 中。在 Multimedia Session 中，除非特意将多媒体编码进同一数据流，否则，每个数据流会通过不同的 RTP Session 传输。与会者通过 Transport address 来区分不同的 RTP Session。同一 RTP Session 的不同与会者会共享同一个 Transport address，也可能每个与会者都有自己的 Transport address。在单播的情况时，一个与会者可能用同一对端口（RTP&RTCP）来接收所有其他与会者的数据，也可能对不同的与会者采用不同的端口对（RTP&RTCP）。 Synchronization source (SSRC)：RTP 报文流的一个 Source，由 RTP 头中定义的 32-bit 的 SSRC identifier 来标识，这样做是为了不依赖网络地址。同一个 SSRC 中发送的所有包都具有同一时序和序列号间隔，因此接收者可以通过 SSRC 将收到的数据包分组并排序。一个信号源（麦克风，摄像头，Mixer）的报文流会有由一个 SSRC 的发送器发送。一个 SSRC 可能会随着时间的变化，改变其数据格式，例如音频编码。SSRC 的身份识别码都是随机生成的，但是必须保证整个 RTP Session 中该身份识别码不会重复，这些工作是通过 RTCP 来完成的。如果一个与会者在一个 RTP Session 中发送不同的媒体数据流，那么每个流的 SSRC 必须不同。 Contributing source (CSRC)：RTP Mixer 所