RTP协议基础

概述

1. 基本概念

        RTP协议，全称为Real-time Transport Protocol（实时传输协议）是一种用于在IP网络上传输音频、视频等实时数据的网络协议。

        在流媒体（流媒体就是指可在线/实时观看音视频的互联网产品）数据传输过程中，为保障音视频流的实时传输，需采用RTP和RTCP协议。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务，但本身无法保证服务质量，因此，需要配合实时传输控制协议（RTCP）一起使用。

        RTP使用的端口是系统端口（即1024~65535）除外选一个未被使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个奇数UDP端口号，端口号5004和5005分别用作RTP和RTCP的默认端口号。

        实际上，RTP只是一个协议框架，它只包含了实时应用的一些共用功能，RTP自己并不对多媒体数据块做任何处理，而只是向应用层提供一些附加信息，让应用层知道应当如何进行处理。（比如wireshark工具可以分析处理rtp流）。

2. 工作层级

        RTP协议可以归为应用层，因为从开发者的角度看，在应用程序的发送端和接收端，开发者必须编写用RTP封装分组和获取数据块的程序代码。RTP也可以认为是运输层协议，因为RTP封装了多媒体应用的数据块，并且向多媒体应用程序提供了服务（时间戳和序号），因此也可以把RTP看成是在UDP之上的一个运输层子层的协议。

二. rtp消息体

        当我们说“RTP协议”时，我们指的是一个包含了报头结构和有效载荷（Payload）封装规则的完整协议。报头显示了一些基本信息和定义了一些基本规则；有效载荷作为RTP报文的一部分，是实际传输的多媒体数据，这些数据在发送前被封装在RTP报文中，并在接收端被解封装出来，以便进行后续的解码和播放处理。

        更准确的说法是：有效载荷是RTP报文中的一个重要组成部分，它承载了实际要传输的多媒体数据，而RTP协议则定义了包括有效载荷在内的整个RTP报文的结构和封装规则。

1. 固定头部字段

• 版本号（V）：2比特，当前协议版本号为2，标识使用的RTP版本。

        重要性：版本号字段的唯一有意义的用途是作为数据包有效性检查的一部分。如果丢失，机器无法判断该数据包是否有效，可能会丢弃该数据包。

• 填充标志（P）：1比特，如果设置（P=1），表明数据包尾部有一些额外的填充字节，这些字节不是有效载荷的一部分。填充主要用于某些特定场景，如使用特定块大小的加密方案，或使有效载荷格式适应固定容量信道。

        重要性：如果填充部分丢失，可能会导致加密失效，有效载荷格式与信道不匹配。

• 扩展标志（X）：1比特，如果设置（X=1），表明在固定头部之后还有一个扩展头部。扩展报头允许各个实现尝试新的与有效负载格式无关的功能。

        重要性：如果置1的情况下，头部扩展内容将变得无法识别，影响数据包的解析。

• CSRC计数（CC）：4比特，表示CSRC（贡献源）标识符的数量
• 标记（M）：1比特，用于特定类型的应用程序，如标识关键帧。

        重要性：丢失此字段可能会影响帧完整性的检测，但音频流可以通过序列号和时间戳的变化来检测帧的开始。 

•  有效载荷类型Payload Type（PT）（7bit）

        这个字段指出后面的RTP数据属于何种格式的应用。收到RTP分组的应用层就根据此字段指出的类型进行处理。Payload Type 的具体含义取决于具体的音视频编码格式，即在sdp交互的过程中发送方和接收方需要约定相应的编码器和解码器，该编码器/解码器的编号即为负载类型。该值不但说明了rtp包传输的数据是音频还是视频，害指明了应该使用什么解码器解码。

对于视频有效载荷：H.261（31）、MPEG1（32）、MPEG1（33）等。

对于音频有效载荷：G.711U, G.711A, G.729, G.723, G.722等。

重要性：如果丢失，接收端将无法解码该RTP包，该RTP包将被丢弃

• 序号Sequence number（16bit）

        用于标识发送者发送的RTP报文序列号。对每一个发送的RTP分组，其序号加1。当达到最大值（65535）后，重新从0开【1】。在一次RTP会话开始时的初始序号是随机选择的。

注解【1】：2的16次方=65536，从0开始标记：0-65535

重要性：序号使接收端能够发现丢失的分组，同时也能将失序的RTP分组重新按序排列好。如果丢失，则无法进行排序，可能会导致数据包被丢弃。

• 时间戳（32bit）

        反映了RTP分组中数据的第一个字节的采样时刻。在一次会话开始时间戳的初始值也是随机选择的。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加。

重要性：时间戳可以用来消除抖动以及同步音视频。如果丢失，接收端可能无法正确排序和播放媒体。

• 同步信源(SSRC)（32bit）

        用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。这里的同步信源是指产生媒体流的信源，例如麦克风、摄像机等，它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。

重要性：如果丢失，接收端将无法确认RTP包的来源，可能无法进行分组和播放。

拓展：[Extended sequence number: 65538] 头部字段

        在RTP（实时传输协议）协议中，并没有直接称为“Extended sequence number”的字段。然而，在处理RTP报文的序列号（Sequence Number）时，确实存在一种机制来扩展序列号的范围，以便在序列号翻转时仍能准确计算丢包率和网络性能指标。

1）序列号的限制与翻转

• RTP报文中的序列号是一个16位的字段，其取值范围从0到65535。
• 当序列号达到65535后，会翻转回0，这是由序列号的位数限制所决定的。

2）处理序列号翻转的方法

        由于它在达到65535后会翻转回0，（在同一个SSRC中，出现相同序列号的rtp报文）这可能导致在计算丢包率时出现混淆。

• 为了在序列号翻转时仍能准确计算丢包率和网络性能指标，接收端需要维护一个额外的计数器（如wrap-around counter），用于记录序列号翻转的次数。
• 通过将接收到的序列号与翻转次数相结合，可以计算出所谓的“扩展序列号”（Extended sequence number），尽管在RTP协议本身中并没有直接定义这个字段。

3）扩展序列号的计算

        假设seq_num是当前接收到的RTP报文的序列号，wrap_around_count是序列号翻转的次数。则扩展序列号（Extended sequence number）可以通过以下公式计算：

extended_seq_num = seq_num + (65536 * wrap_around_count)。

2. Rtp数据部分：Payload字段（有效载荷）

        有效载荷是RTP报文的核心内容，用于封装实际要传输的多媒体数据（如音频、视频等）。