RTP协议浅析

平时看的视频流是靠什么做支撑的？是实时传输协议，英文是Real time transport protocol，简写为RTP协议。

RTP协议的定义：RTP为实时应用提供端到端的运输，但不提供任何服务质量的保障。服务质量由专门的协议提供，比如在IP层面上的QOS提供该服务。需要发送的多媒体数据块（包括视频流数据块、音频流数据块）经过压缩编码处理后，先送到RTP封装成RTP分组（RTP数据报），RTP分组装入运输层的UDP用户数据报之后，再向下传递给IP层。

对RTP协议的理解：实际上介于应用层和传输层之间。同时具有应用层和传输层的各种特点。这个特点需要仔细甄别。

从应用开发者的角度看，RTP应该是应用层的一个部分。在应用程序的发送端，开发者必须编写用RTP封装分组（数据包）的程序代码，然后把该RTP分组交给UDP套接字接口。在接收端设备，RTP分组通过UDP套接字接口进入应用层程序后，会利用开发者编写的程序代码把RTP分组从应用数据块提取出来。RTP实际上为视频程序的开发者提供了一个开发平台。

RTP也可以理解为运输层协议，实际上RTP协议偏重于传输层，是UDP协议（用户数据报）上边的一层协议。因为RTP封装了多媒体应用（包括视频流、音频流）的数据块，关键是提供运输层的服务（时间戳，序号、同步源标识符等），因此可以把RTP看成一共UDP上的运输层子层协议，特别要注意是子层协议。

综合来看，RTP协议实际上是一个介于传输层和应用层之间的协议，作用是在UDP协议之上完成一次对媒体流的封装。

RTP分组仅仅包含RTP数据，RTP流由另一个控制协议RTCP协议来完成。RTP协议端口号由1025到65535之间选择一个没有使用的端口号，1025以下的端口号一般都是有用的。一般情况下RTP是偶数的端口号。控制协议RTCP使用奇数的端口号码。这个奇数端口偶数端口是不确定的，但是约定一般都这么“配置端口号”。

关于RTP在整个数据包里边的位置。RTP数据放入RTP分组里面，会加入RTP首部信息。这个首部信息是关键。RTP分组放入UDP用户数据报里面，或者说UDP封装RTP数据分组。（为什么用UDP？RTP一般承载音频流，或者承载视频流，这个对编码效率要求比较高，对实时性要求比较高，所以利用UDP传输比较合适）UDP数据报放入IP包里边（三网合一之后基本都是IP去承载其它协议了）。

详细分析RTP数据包。RTP协议里边都包括哪些内容，具体涉及到哪些信息详细分析如下。按照从上到下，从左到右的顺序逐一分析梳理：

1. 版本号，占两位。版本号有两个，v1和v2。现在v1已经被淘汰了，大家使用的都是v2。
2. 填充P。占位1位。在某些情况下需要对应用数据块加密，这个结合CCIE security(CCIE安全)理解。往往要求每一个数据块（媒体流数据块）做填充。填充时P位“置1”就可以了。表示这个RTP分组的数据有若干个字节时填充字节。这些所谓的填充字节没有实际意义，只是为了占位，目的是给加密提高操作的基础。在数据部分的最后一个字节用来表示所填充的字节数。
3. 扩展x。占位一位。扩展首部很少使用，几乎不用。表示在RTP首部后边还有一个首部。这容易引起混乱，所以一般不用。
4. 参与源数。占位4位。这个字段给出后边的参与源标识符的数目。
5. 标记M。占位1位。M位“置1”，表示这个RTP分组具有特殊意义。例如，在传送视频流中用来表示每一个帧的开始。
6. 有效载荷类型（payload type）这个有效载荷类型是非常关键的内容。有效载荷类型共占位7位。有效载荷类型字段指出后边的RTP数据属于何种格式的应用。收到RTP分组的应用层可以根据这个字段指出的类型进行处理，音频字段按照音频字段处理，视频字段按照视频字段处理。比如说，
   对于音频有效载荷（每一种格式后边的括号的数字表示有效载荷类型）：u律PCM编码（0），GSM编码（3），LPC编码（7），A律PCM编码（8），G.722协议编码（9），G.728协议编码（15）。
   对于视频的有效载荷编码包括：H.261编码（31），MPEG1编码（32），MPEG2编码（33），这些都是关键数据。关键是理解括号内的数字等于理解有效载荷类型的编号。
7. 序号。序号是关键点，数据包的乱序问题就是靠“序号”来解决的。因为国际互联网本身是不可靠传输，所以说出现序号问题是一个非常正常的问题，错序问题靠序号来解决，序号共占位16位。对于每一个发送出的RTP分组，其序号会自动加1.在一次RTP会话开始时的初始序号是随机选择的（序号选择算法）。序号最主要的目的是使得接收端能够发现丢失的分组，同时也能够将失去顺序的分组重新排序。这个重新排序是重点，其实很多时候失去的分组需要启动重传协议。比如在收到序号为60的RTP分组之后又收到了序号为65的RTP分组。这个时候可以形成推理，中间还缺少4个关键的RTP分组，序号分别为61，62，65，64.这个时候RTP协议会自动启动重传协议。
8. 时间戳。这个时间戳是RTP里边非常关键的部分。时间戳的占位32位。时间戳反映了RTP分组中数据的第一个字节的采样时刻。在一次会话开始时，时间戳的初始值也是随机选择的，这个时间戳不是时间的完全控制系统，需要和其他的时间控制系统共同完成对时间的控制。即使是没有信号发送时，时间戳的数值也随时间的增加而不断增加。接收端（接受端子）使用时间戳可以准确知道应该在什么时间点还原哪一个数据块，这个时间点和数据块是一一对应的，这样设计目的是消除时间抖动。时间还可以用来使得视频应用的图像和声音同步，这个也就是所谓的唇音同步。在RTP协议里边并没有规定时间戳的颗粒度，因为这样做没有必要。颗粒度的大小取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳，目的是强调这种时间戳的颗粒度取决于信号的类型。比如说，对于8kHz采用频率的话音信号，20毫秒发送一个数据块。因此每一次发送RTP分组，时间戳的数值会增加160。时间戳是一个非常关键的数据，媒体数据的延迟问题和抖动问题都是靠时间戳来搞定的。
9. 同步源标识符（synchronize source identifier），这个同步源标识符非常关键。用来标识RTP的源头，用来标识RTP数据流的来源。SSRC与IP地址没有什么关系，这个在新的RTP流开始的时候是随机产生的。由于RTP使用UDP协议作为下一级封装协议，因此可以出现多个RTP数据流。比如，使用几个摄像机从不同的拍摄角度拍摄同一个节目，这个时候会产生多个RTP数据流，这些RTP数据流会复用到同一个UDP数据报里面。在接收端，会根据RTP数据流不同的同步源标识符分流到不同的接受端子，也就是说RTP流一点也不会混乱，每一个接受端子都会接受自己的RTP数据流。两个RTP数据流同时选择一个同步源的概率非常低，如果这种小概率事件出现，两个RTP数据流也会选择不同的同步源标识符。