流媒体传输协议之 RTP (上篇)

本系列文章将整理各个流媒体传输协议,包括 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 包的人就能确定当前说话的人是谁了。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zygwjz.html