本系列文章将整理各个流媒体传输协议，包括 RTP/RTCP，RTMP，希望通过深入梳理协议的设计细节，能够给流媒体领域的开发者带来一定的启发。
作者：逸殊
审核：泰一
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 包的人就能确定当前说话的人是谁了。