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

本文详细介绍了RTP(实时传输协议)及其在流媒体通信中的应用,包括协议头结构、填充数据、RTP包的创建和解析,以及RTCP(RTP控制协议)的功能、报文分类和协议头。同时讨论了如何通过RTCP解决包抖动问题,展示了这两种协议在多媒体数据传输中的重要性。
摘要由CSDN通过智能技术生成

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

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

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

3.1.1 RTP的协议头

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的扩展头

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的部分。

3.1.4 RTP的使用

1)创建/解析RTP包

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

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

WebRTC在接收RTP包时,会为之创建一个接收队列来消除包抖动。

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

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

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

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

3.2.1 RTCP的报文分类 

1)SR:发送信息报文。

2)RR:接收信息报文。

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

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

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

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

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

3.2.2 RTCP的协议头

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的报文类型

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的报文类型

1)PLI:在接收端解码器无法解码时发送的报文。

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

爱学习的程序媛

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值