使用wireshark检测RTP丢包问题

一、RTP协议简介

RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP 数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12 个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP 数据报的头部格式下图所示：

       RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP 数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12 个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP 数据报的头部格式下图所示：

其中比较重要的几个域及其意义如下：
CSRC 记数（CC） 表示CSRC 标识的数目。CSRC 标识紧跟在RTP 固定头部之后，用来表示RTP 数据报的来源，RTP 协议允许在同一个会话中存在多个数据源，它们可以 通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC 列表来表示一个电话会议，该会议通
过一个 RTP 混合器将所有讲话者的语音数据组合为一个RTP 数据源。
负载类型（PT） 标明RTP 负载的格式，包括所采用的编码算法、采样频率、承载通道等。接收方会检查负载类型，进而决定如何处理收到的数据，比如，把数据传递给专门的解压器。

序列号(Sequence Number) 用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP 协议本身并不负责数据的重传。
时间戳 记录了负载中第一个字节的采样时间，接收方根据时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。
      从RTP 数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP 协议 的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP 中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之 上；RTP 也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP 本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP 一般是在传输协议之上作为应用程序的一部分加以实现的.

由前文可见，我们可以抓取RTP包,解析它，并观察序列号的连续情况来确定是否丢包。

 

二、原理总结

RTP序列号可以用来区分和标识RTP报文，并为探测是否有丢包和是否有包的传输顺序错乱等问题提供了很好的线索。

序列号通常为一个16位的无符号二进制整数，并且以1个步长逐步递增。当序列号递增到最大值时，会自动恢复为0。在英文中，这种到达最大值后清0的行为被叫做：wrap-around.

注意：除了wrap-around.情况外，序列号永远遵循连续的原则，报文每发送一次，就递增1，而不会以其他步长往前或往后跳跃。

综上：

（1）序列号的一个主要用途是丢包检测。当接收方发现序列号出现以大于1的步长跳跃的情况，就可以认为是丢包。接收方应采取措施来规避或解决这个问题；

（2）在包的传输顺序被打乱的情况下，接收方可根据序列号，对包进行排序，进而重组。

三、实例：使用wireshark抓包并检查丢包现象

（1）使用wireshark抓取所有UDP报文（这里假定RTP是基于UDP之上的）

（2）将抓取到的报文解析为RTP,如下图所示：

 

(3)分析报文（在报文较多且杂的情况下，可用excel导出数据查看），发现丢包：

 

（此文待优化）