RTP协议分析
“ 音视频通话内容传输承载协议RTP介绍。”
RTP协议详细说明了互联网上传递音视频的标准数据包格式。常用于流媒体系统、视频会议、VOIP中，通常要配合SIP、H.323等传输控制协议使用，在互联网中，还会配合私有的传输控制协议使用。它由UDP承载。
对传输控制协议中的SIP协议，此前已有文章进行介绍：SIP协议分析，可点击查阅。
在RTP协议中，通常提供的信息包括时间戳、序列号以及负载格式等。
RTP协议作为UDP承载的内容传输协议，本身并不能为数据包提供排序等可靠性机制，也不提供流量及拥塞控制，在协议还原过程中，会发现有很多的重传报文和乱序报文的存在，这需要上层对RTP协议数据进行排序和重传处理，以提升还原效果，另外，像音视频数据流，如果乱序和重传情况在一定限度内，则只会稍微降低播放效果，而不会使数据流完全无法播放。
01
—
数据格式
一次RTP承载的音视频通话过程中，会有很多的RTP报文，每个报文为一个RTP分组，上下行的RTP流互不干扰，各自组成对应的语音或者视频流，对RTP的还原而言，只需要对一个四元组对应的RTP流的上下行各自还原即可。
一个RTP分组数据包由RTP头部和RTP数据两部分组成，而RTP头之后，可能会有扩展头的存在，RTP数据之后，可能会有填充数据的存在。
RTP头部格式如下所示：
各字段含义如下：
V：版本号，2比特，用来标志使用的RTP版本，当前版本为2。
P：填充位，1比特，如果该位被置位，则RTP包的尾部会包含填充字节。
X：扩展位，1比特，如果该位被置位，则RTP头部后会有一个扩展头部。
CC：CSRC计数器，4比特，头部之后的CSRC的数目。
M：标记位，1比特，如果被置位，则意味着数据与应用程序有特殊相关性。
PT：负载类型，7比特，标识了RTP负载的类型，即语音视频的编码号。
sequence number：序列号，16比特，一条流中一个方向的RTP数据包，序列号递增，一般可根据此字段进行乱序及重传的处理。
timestamp：时间戳，32比特，该RTP数据包中第一个字节的采样时间，一次会话开始时，时间戳会被初始化成一个初始值。 SSRC：同步源标识符，32比特，指RTP包的来源。在同一个RTP会话中不能有两个相同的SSRC值。CSRC list：贡献源列表，共0～15项，每项32比特，数量由CC字段说明，用来标志RTP包中有效数据的贡献源。当扩展位X为1时，则在RTP头部之后，有RTP扩展头：
各字段含义如下：
defined by profile：在应用程序中由描述文件定义的内容，16比特。length：扩展的长度字节数，16比特，不包含前4个字节。header extension：扩展的具体内容，长度不定。在RTP头之后，就是RTP承载的具体音视频流内容了，一般而言，一个RTP包内的数据为一帧。对语音流而言，根据语音编码的不同，每帧的长度情况各不相同，部分编码如G.711，G.723，GSM等通常每帧长度相等为定长编码，而iSAC，speex，opus，SILK等，则为变长的编码。
在RTP标准中，对语音视频的编码号即负载类型，部分进行了定义，在网页https://en.wikipedia.org/wiki/RTP_audio_video_profile中，描述了大部分音视频的负载类型情况，包括编码号。
RTP流的解析还原需要流媒体控制协议的配合，如SIP，H.323等协议，以提供解析的基础数据，如编码等信息。
但我们也可以根据编码长度，编码号等特性，在缺少流媒体控制协议的情况下，反推RTP内数据的存在形式，从而有助于RTP流的还原。
02
—
RTP示例
一次通话的RTP流示例如下：
此RTP流使用的是定长编码G.711，在Wireshark中，已经对G.711这个语音编码进行了支持，因此可直接使用Wireshark的RTP流分析功能进行播放或导出：
实际的还原过程中，可从Wireshark源码中进行借鉴。
RTP协议的分析就到这里了，如果需要，请加我：
长按进行关注。
