WebRTC技术文档 -- 3.RTP和RTCP(笔记)

233 阅读5分钟

WebRTC.png

3.1 RTP(Real-time Transport Protocol,实时传输协议)

RTP通过IP网络实时传输音视频流,常用于流媒体服务的通信系统。音频和视频流使用单独的RTP会话,接收端可以选择性地接收媒体流。

RTP使用的端口号为偶数,每个关联的RTCP端口为下一个较高的奇数,端口号范围为1024~65535。

3.1.1 RTP的协议头

微信图片_20240119215624.jpg 1)版本号(占2位): 表示RTP的版本,目前都用2版本。

2)P(Padding,占1位): 表示RTP数据包是否有填充值。为1时表示有填充,填充以字节为单位。

3)X(eXtension,占1位): 表示RTP数据包是否有扩展头。如果有扩展头,放在CSRC之后,携带一些附加信息。

4)CC(CSRC Count,占4位): 表示RTP数据包中CSRC标识符的个数。

5)M(Marker,占1位): 表示在应用程序级别使用的信令,一般用于标识边界。对于视频标记一帧的结束,对于音频标记会话的开始。

6)PT(PayloadType,有效载荷类型,占7位): 表示有效载荷的格式。

7)序列号(占16位): 表示给每个发送的RTP数据包打上连续的编号。

8)时间戳(占32位): 表示RTP数据包的时间标识。用于记录该包产生的时间,主要用于组包和音视频同步。

9)SSRC(占32位): 表示RTP数据包的同步源,用于标识媒体源。

10)CSRC(占32位): 表示RTP数据包的贡献源。

3.1.2 RTP的扩展头

微信图片_20240119220025.jpg 1)profile: 用于区分不同的配置。RFC 5285中定义了两种profile:{0xBE, 0xDE}和{0x10, 0x0X},接收端通过profile区分header extension中的内容如何解析。

2)length: 表示扩展头所携带header extension的个数。

3)header extension: 扩展头信息,以4字节为单位,具体含义由profile决定。{0xBE, 0xDE}表示one-byte-header数据格式,{0x10, 0x0X}表示two-byte-header数据格式。

① one-byte-header格式: 由一个字节的Header(由4位的ID和4位的length组成)和N个字节的Body组成。

② two-byte-header格式: 由2个字节的Header(由1个字节的ID和1个字节的length组成)和N个字节的Body组成。

3.1.3 RTP的填充数据

最后一个字节记录填充字节个数(Padding Size),包含它自己。填充数据不属于RTP Payload的部分。 微信图片_20240119220029.jpg

3.1.4 RTP的使用

1)创建/解析RTP包

WebRTC源码中,通过RtpPacket类生成/解析RTP包。

2)根据RTP包进行逻辑处理(以消除RTP包抖动为例)

WebRTC在接收RTP包时,会为之创建一个接收队列来消除包抖动。 微信图片_20240119220351.jpg 一开始103包没有来可能是包丢了或者网络抖动导致包乱序了。如果缓冲队列满了就说明包丢了,否则包处于待定状态。103包来了后根据序列号将其插入队列中对应的空缺位置。104包有M标志,则将100~104包从缓冲队列中弹出组成一帧,空出的位置继续接收新包。

3.2 RTCP(RTP Control Protocol,RTP控制协议)

RTCP为RTP会话提供统计信息和控制信息,与RTP协作提供多媒体数据的传输和打包功能,其本身不传输任何媒体数据。

RTCP的主要功能是定期发送数据包计数、数据包丢失、数据包延迟变化以及往返延迟时间等统计信息,向媒体参与者提供媒体分发中的服务质量保障。

3.2.1 RTCP的报文分类

微信图片_20240119220034.jpg 1)SR: 发送信息报文。

2)RR: 接收信息报文。

3)SDES: 用来描述(音视频)媒体源的报文。

4)BYE: 用于说明哪些(音视频)媒体源不可用了。

5)APP: 给应用预留的报文,可自定义应用层解析的报文。

6)RTPFB: RTP的反馈报文,是RTP传输层面的报文。

7)PSFB: RTP中与负载相关的反馈报文。

3.2.2 RTCP的协议头

微信图片_20240119220038.jpg 1)V(Version,占2位): 表示RTCP的版本号,目前都用2版本。

2)P(Padding,占1位): 表示RTCP包是否有填充值。为1时表示有填充,填充以字节为单位。

3)PT(PayloadType,占8位): 区分同一端口中不同类型的数据。PT值是上面表中PT列的内容。

4)Count(占5位): 不同的RTCP报文有不同的含义。SR/RR报文,Count表示携带的接收报告的个数;SDES报文, Count表示item的个数;BYE报文,Count表示SSRC/CSRC的个数;APP报文,Count用于标识应用自定义的子消息类型。

5)Length(占32位): 表示整个RTCP包的大小,包括RTCP头、RTCP负载和填充字段。

6)Data: 存放的内容与PT相关,具体可查阅RFC3550。

3.2.3 RTPFB的报文类型

微信图片_20240119220044.jpg 1)NACK: 用于通知发送方在上次包发送周期内有哪些包丢失了。

在NACK中包含两个字段:

① PID(Package ID): 用于标识从哪个包开始统计丢包。

② BLP(Bitmask of Following Lost Packet): 从PID包开始,接下来的16个RTP包的丢失情况。

2)TMMBR: 表示临时最大码流请求报文。

3)TMMBN: 表示临时最大码流应答报文。

4)TFB: Transport-CC算法的反馈报文,记录包的延迟情况,交由TCC算法计算下行带宽。

3.2.4 PSFB的报文类型

微信图片_20240119220050.jpg 1)PLI: 在接收端解码器无法解码时发送的报文。

2)FIR: 主要应用于多方通信时后加入房间的参与者向已加入房间的共享者申请关键帧。

3)REMB: 用于将接收端评估出的带宽值发给发送端。