概述
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报文的核心内容,用于封装实际要传输的多媒体数据(如音频、视频等)。