设计的网站,免费网站推广产品,青之峰做网站,求职seo推荐一、前言#xff1a;
RTCP#xff08;RTP Control Protocol#xff09;是一种控制协议#xff0c;与RTP#xff08;Real-time Transport Protocol#xff09;一起用于实时通信中的控制和反馈。RTCP负责监控和调节实时媒体流。通过不断交换RTCP信息#xff0c;WebRTC应用…一、前言
RTCPRTP Control Protocol是一种控制协议与RTPReal-time Transport Protocol一起用于实时通信中的控制和反馈。RTCP负责监控和调节实时媒体流。通过不断交换RTCP信息WebRTC应用能够调整比特率、编码方式等适应网络条件确保音视频通话的质量。同时RTCP与RTP共同工作使得数据传输不仅准确而且高效。
二、RTCP Header
RTCP有很多格式常见的有SRSender Report、RRReceiver Report、SDESSource Description、BYEGoodbye。他们格式各不相同
但是他们的Header的共同部分为
Version (V)占两位表示RTCP版本当前版本是2Padding §占1位表示是否有填充字节。如果该字段为1则表示有填充字节Reception Report Count (RC)占5位表示报告块的数量。每个RTCP报文可以包含多个报告块Packet Type (PT)表示该RTCP报文的类型例如 SRSender Report发送者报告RRReceiver Report接收者报告SDESSource Description源描述BYE结束会话APP应用层自定义信息 Length占16位表示此 RTCP 数据包包括报头本身的长度以 32 位为单位减一。比如一个 RTCP 报文的总长度包括头部是 80 个字节那么我们需要将这个长度转换成 32 位单位然后减去 1 来填写在 RTCP 头部的长度字段中。 首先将总长度转换成 32 位单位 80 字节 80 * 8 640 位640 位 / 32 20 个 32 位字 接下来根据文档的描述需要减去 1即 20 个 32 位字 - 1 19 SSRC of sender: 占用32位表示发送该RTCP报文的源的同步源标识符SSRC。用来唯一标识一个媒体发送者。
三、RTCP Packet Type
常见的有
SRSender Report 发送者报告包含有关发送者的统计信息如发送的总包数、发送时的时间等。它提供了性能监控的关键指标例如丢包率和延迟。 RRReceiver Report 接收者报告包含有关接收的数据包的统计信息如接收的总包数、丢失的包数等。接收者使用此报告来向发送者反馈接收状态。 SDESSource Description 源描述提供有关媒体源的附加信息例如源的名称、电子邮件地址、电话等。这有助于会话中的参与者识别彼此。 BYE 结束报告表示一个或多个参与者离开会话。当参与者不再发送数据时它会向其他参与者发送 BYE 消息以通知他们。 APP 自定义的RTCP报告允许应用程序定义自己所需的反馈和信息。 FIRFull Intra Request 向对方请求发送关键帧全内编码帧主要用于视频流媒体的情况以便重新同步流。 NACK当接收端收到的数据有丢失的情况下给发送端发送一个NACK发送端收到NACK之后首先看这个包有没有超时如果没有超时那么重新将这个包发送给接收端RTPFBRTP Feedback 一般性RTP反馈能够携带多种反馈信息包括质量、丢包、抖动等。它通常是用于更详细的动态反馈机制。 PSFBPayload Specific Feedback 根据负载的特殊情况返回的反馈通常用于特定编解码器的附加功能例如流量控制和优化。
下面详细看看每一中Type当然重点还是SR/RR。
3.1、SR
RTCP SRSender Report是实时传输控制协议RTCP中的一种报文类型用于发送端向接收端提供有关发送者的信息。RTCP SR 报文包含了发送端的时间戳信息以及关于发送端发送媒体流的统计数据。
格式如下 0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1--------------------------------
header |V2|P| RC | PTSR200 | length |--------------------------------| SSRC of sender |
sender | NTP timestamp, most significant word |
info --------------------------------| NTP timestamp, least significant word |--------------------------------| RTP timestamp |--------------------------------| senders packet count |--------------------------------| senders octet count |
report | SSRC_1 (SSRC of first source) |
block --------------------------------1 | fraction lost | cumulative number of packets lost |--------------------------------| extended highest sequence number received |--------------------------------| interarrival jitter |--------------------------------| last SR (LSR) |--------------------------------| delay since last SR (DLSR) |
report | SSRC_2 (SSRC of second source) |
block --------------------------------2 : ... :| profile-specific extensions |--------------------------------SR由以下部分组成 Header标准的RTCP头部包括基础的控制信息前面已经说明过了。 Sender Info发送者信息包括 NTP Timestamp64位表示真实世界的时间可以用来进行音视频同步因为不同的源真实世界的时间是一样的。RTP timestamp32位相对时间只真针对这一路流和RTP里面的时间戳一致Packet Count32位表示在统计期间内成功发送的RTP数据包总数。这有助于接收者了解发送者在给定时间窗口内的活动量。Octet Count32位总共发送的数据量因为我们知道了总发包数不一定知道总发送数据量因为一个包大小有可能是50字节也有可能是100字节。 n个Report block每个报告块提供有关接收流的统计信息。每个接收的流SSRC都可能对应一个Report block因此如果您接收了5路流则可能会有5个Report block。每个Report block提供了关于特定源的接收信息。 SR中包含RR: 标准允许在SR中含有RR这样可以节省带宽就是我不光告诉你我发送的情况我还会把我之前接收的报告顺便发给你。然而在WebRTC中通常情况下发送者报告SR并不会包含接收者报告RR而是单独发送RR来避免复杂性和规模问题。这种设计使得每种报告可以专注于其主要作用提高了传输效率。 SSRC_1 (SSRC of first source) 描述这一字段指定了发送者的同步源标识符SSRC它是发送方在RTCP中的唯一标识符有助于接收方识别信息源。 Fraction lost (丢包比例) 描述表示自上次报告以来丢失的数据包的比例。它是一个8位字段具体计算为丢包数与接收总数的比例。范围在0到255之间值越低表示丢失的包越少。 Cumulative number of packets lost (丢失的包总量) 描述这个字段是一个32位的计数器从会话开始到当前报告时已经丢失的所有包的累计数量。这有助于发送方评估网络的稳定性。 Extended highest sequence number received (扩展的最高序列号) 描述该字段的意义在于记录接收方所接收到的最高序列号。这是一个32位的值能够帮助发送方了解接收方的接收情况。这也有助于分析包的顺序判断是否发生了重传。 Interarrival jitter (到达抖动) 描述表示数据包到达时间的变化抖动是一个32位的值用于衡量数据包传输的延迟变化。这对于实时应用如音频和视频至关重要因为抖动会影响用户体验。 Last SR (LSR) (上一个发送报告时间) 描述该字段表示上一次发送报告的时间戳通常以NTPNetwork Time Protocol时间格式表示。通过了解最近的发送时间可以更好地评估当前的网络状况。 Delay since last SR (DLSR) (自上次发送报告以来的延迟) 描述表示当前报告时与上一次报告之间的延迟。这有助于发送方评估发送响应的时效性确定网络延迟是否在可接受范围内。 示例场景: 假设在一个视频会议中有一个发送者和多个接收者发送者使用RTCP Sender Report来反馈其数据包的发送情况。我们来看一份具体的Sender Report
Sender Report (SR)SSRC: 123456789Fraction lost: 5Cumulative number of packets lost: 20Extended highest sequence number received: 500Interarrival jitter: 100Last SR (LSR): 1618848000 (NTP timestamp)Delay since last SR (DLSR): 50字段分析: 1. SSRC (123456789)发送者的唯一识别标识符。接收方可以在多方通话中通过这个值确认哪个发送者发送了该报告。 2. Fraction lost (5)值为5表示自上次报告以来丢失的包占接收到总包数的比例。假设接收方共接收到100个包即接收到的包总数可能是100 5 105那么丢包率为5%。这表明网络传输不是很好需要关注。 3. Cumulative number of packets lost (20)自会话开始到当前时刻已经丢失的包总数为20。这可帮助发送方了解其发送的稳定性若持续增加则可能需调整发送策略或改善网络条件。 4. Extended highest sequence number received (500)该字段表示接收方接受到的最高序列号为500意味着它已经成功收到的包的一个连续编号。这有助于检测出是否有包丢失以及是否以正确的顺序到达。 5. Interarrival jitter (100)100毫秒的抖动值表明数据包到达的时间不稳定这可能会导致视频或音频播放时的延迟和不流畅感。较高的抖动值意味着网络不稳定需要优化网络。 6. Last SR (LSR) (1618848000)这是NTP时间戳表示上一个发送报告的时间。假设该时间戳对应于某个特定的时刻如2021年4月1日这使得接收方能够判断报告的时效性。 7. Delay since last SR (DLSR) (50)值50表示自上次发送SR报告以来经过的延迟为50毫秒。这表明数据传输的延迟相对较低发送方能够及时得到反馈。
3.2、RR
RRReceiver Report接收者报告消息包含多个报告单元分别反映不同的接收者关于接收数据的质量。 和SR相比没有Sender Info字段其他和SR相同
3.3、SDES
SDES (Source Description) 格式用于传递与媒体源相关的描述信息例如用户名、邮箱地址、流的名称等。
报文格式
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P| SC | PTSDES202 | length |
--------------------------------
| SSRC/CSRC_1 |
--------------------------------
| SDES items |
--------------------------------
| ... |
--------------------------------
| SDES items |
--------------------------------SDES 报文由一个 RTCP 头部和一个或多个SDES项组成。
SC表示seds item count就是后面带了多少itemPT202length表示这个包有多大item由两部分组成SSRC和具体SDES items
后面的每个SDES items
--------------------------------
| SDES type | length | SDES text |
--------------------------------SDES type: 8 bits表示SDES项的类型指示该项包含的是何种信息如参与者的名称、邮箱地址等。我们一般都是使用CNAME除了CNAME还有其他类型如下 0会话名称CNAME1邮箱EMAIL2用户名NAME3流名称RID4工具Tool5网址LOCATION length: 8 bits表示SDES项值的长度以字节为单位。SDES text: 包含SDES项的实际值可以是参与者的名称、邮箱地址、电话号码等描述信息。
可以看出是一种TLV格式如果作为服务器接收到多路客户端一起推流那么有可能ssrc会冲突服务器就会告诉客户端使用原来的CNAME来重新计算一个SSRC这个过程的协商就是SDES完成的 示例 在媒体协商时候为每一个源都设置好了一个CNAME假如抓到如下报文 那么 PT为202表示SDESlength为6计算长度为61*4 28字节SDES中每一项都叫做一个ChunkChunk中包含SSRC Sdes item每一个SSR对应多个itemText就是这个SDES item具体内容
3.4、BYE
主要用于告知其他参与者某个源通常是发送者已经结束通信或不再发送媒体流。
报文格式如下
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P| SC | PTBYE203 | length |
--------------------------------
| SSRC/CSRC |
--------------------------------
| ... |
--------------------------------
| SSRC/CSRC |
--------------------------------
| length | reason for leaving ...
--------------------------------RTCP 头部 Version (2 bits): 表示 RTCP 的版本当前版本为 2。Padding (1 bit): 指示报文是否有填充部分。Reception Report Count (RC) (5 bits): 在 BYE 报文中通常为 0。Packet Type (8 bits): 对于 BYE 报文其值为 203。Length (16 bits): 表示后续负载的长度以 32 位字4 字节为单位计算。 SSRC 列表 该部分包含一个或多个发送源的同步源标识符SSRC。这些 SSRC 表示已结束的媒体流的发送者。 原因代码 (可选): BYE 报文中还可以包含一个可选的原因字段以指示发送者停止原因如正常停止、错误等。 其他信息 (可选): 可包含文本信息如告别消息等长度取决于具体情况。
3.5、APP
RTCP APPApplication-Defined RTP Control Protocol报文是一种可扩展的 RTCP 控制消息允许应用程序在 RTCP 报文中插入自定义信息。RTCP APP 报文灵活能够提供应用特定的反馈、信息或统计数据适用于多种场景比如流媒体传输、实时会议和在线游戏。
报文格式如下
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P| subtype | PTAPP204 | length |
--------------------------------
| SSRC/CSRC |
--------------------------------
| name (ASCII) |
--------------------------------
| application-dependent data ...
--------------------------------前面都是xxx count这儿变成了SubType我们可以定义多个APP使用这个ST区分。body部分第一个是ssrc表示这个包所有操作都是针对这个ssrc进行的name和data名字和具体数据
3.6、FIR
用于请求发送者发送一个关键全帧帧。
报文格式如下
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P| FMT4 | PTFIR192 | length |
--------------------------------
| SSRC of packet sender |
--------------------------------
| SSRC of media source |
--------------------------------
| ... |
--------------------------------V (Version): 2 bits固定为 2表示 RTCP 协议的版本。 P (Padding): 1 bit指示是否存在填充字节。 FMT (Format): 5 bits这里值为 4表示 FIR 报文的特定格式。 PT (Packet Type): 8 bits值为 192指示这是一个 FIR 报文。 length: 16 bits表示整个 RTCP 报文的长度单位为 4 字节即报文中包含的字的数量减去 1。 SSRC of packet sender: 32 bits表示发送 RTCP FIR 报文的发送者的同步源标识符SSRC。就是接收者自己SSRC。 SSRC of media source: 32 bits表示希望请求关键帧的媒体源的 SSRC。接收者请求的发送者SSRC。
3.7NACK
RTCP NACKNegative Acknowledgement报文用于指示丢失的媒体包以便发送端重传这些包。以下是RTCP NACK报文的格式
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P| FMT1 | PTNACK205 | length |
--------------------------------
| SSRC of packet sender |
--------------------------------
| SSRC of media source for which NACK is sent |
--------------------------------
| NACK PID PID PID PID ... |
--------------------------------V (Version): 2 bits表示 RTCP 协议的版本固定为 2。 P (Padding): 1 bit指示报文是否包含填充字节。 FMT (Format): 5 bits指定报文的格式类型。NACK 报文的格式为 1。 PT (Packet Type): 8 bits指示报文类型。NACK 报文的类型值为 205。 length: 16 bits表示整个 RTCP 报文的长度以 32 位字4 字节为单位计算。 SSRC of packet sender: 32 bits指示发送 RTCP NACK 报文的发送者的同步源标识符SSRC。 SSRC of media source: 32 bits表示请求重传丢失媒体包的源的 SSRC。 NACK PID: 32 bits后续字段用于列出丢失的媒体包的序列号Packet IDs以便发送方进行重传。
3.8、FB信息
RTCP RTPFBRTP Feedback报文用于提供有关RTP数据流的反馈信息。
报文格式如下
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1--------------------------------|V2|P| FMT15 | PT | length |--------------------------------| SSRC of packet sender |--------------------------------| SSRC of media source |--------------------------------| FCI |--------------------------------FMTfeedback message type返回报文的消息类型就可以区分比如前面的PLI、FIR、REMBPTpayload type205或者206SSRC of packet sender这个报文由谁发送的SSRC of media source表示我们这个报文是针对哪个媒体源反馈的报文FCI这个值就需要根据前面的FMT来确定了不同FMT有不同的格式
按照PT分类
主要分为传输层的FB、负载层的FB和应用层的FB。这些不同类型的反馈报文通过FB Type字段来区分以便接收端和发送端能够正确解释和处理反馈信息。
传输层的FBRTPFB 传输层的FB主要关注RTP流的传输和接收情况通常用于网络拥塞控制、丢包恢复等。传输层的FB主要涉及网络传输方面的问题如丢包、网络延迟等。传输层的FB Type一般在范围0-191。 负载层的FBPSFB 负载层的FB关注RTP载荷的内容例如视频编解码方面的信息如图像质量、分辨率等。负载层的FB主要针对RTP载荷内容的质量和特征进行反馈。负载层的FB Type一般在范围192-254。 应用层的FB 应用层的FB与应用层的特定需求和协议相关用于传递应用层特定的反馈信息。应用层的FB主要用于特定应用场景下的反馈需求例如实时协作应用、多媒体通信应用等。应用层的FB Type一般在范围256-383。
3.9、RTPFB
传输层的FB报文头就是3.8、FB信息那样PT为205
payload type为205的时候传输层的RTPFB主要传输下面几种包
NACK就是一般的重传型TMMBR表示发送一个最大码流请求TMMBN最大码流请求的响应TFB最重要传输层的拥塞控制报文
具体如下
1NACKNegative Acknowledgement
定义: 用于通知发送方哪些 RTP 数据包未被成功接收。功能: 请求重传丢失的数据包确保接收方能够获得完整的媒体流。示例: 接收方发送 NACK 报文指出包 123 和 124 丢失请求发送方重传。
2TMMBRTemp Maximum Media Bit Rate
定义: 临时最大媒体比特率请求通知发送方在当前网络条件下建议的最大比特率。功能: 当检测到网络拥塞或带宽不足时接收方可以请求发送方降低比特率以保证媒体流的稳定。示例: 接收方通过 TMMBR 报文请求将发送比特率降低到 920 kbps适应网络带宽。
3TMMBNTemp Maximum Media Bit Rate Notification
定义: 对 TMMBR 请求的确认指示接收方接受的最大媒体比特率。功能: 确保发送方了解当前网络状况并进行相应调整。示例: 接收方确认发送方可以按照 920 kbps 的比特率发送数据流。
4TFBTransport Feedback
定义: 传输反馈报文专用于传输层的拥塞控制。功能: 提供实时的网络状态反馈包括丢包率、延迟和带宽利用率帮助发送方优化其流量控制策略。示例: 接收方发送 TFB 报文通知发送方当前丢包率为 2%建议减少发送速率以避免拥塞。
3.10、PSFB
PSFBPayload-Specific Feedback是一种 RTCPReal-time Control Protocol反馈机制用于针对特定负载类型提供反馈信息报文头就是3.8、FB信息那样PT为206。下面是三种常见的 PSFB 报文类型及其作用
PLIPicture Loss Indication PLI 用于指示接收端在视频通话中丢失了整个关键帧I-frame请求发送端发送下一个关键帧以确保视频解码器能够正确重建视频帧序列。PLI 的接收端将其发送给发送端发送端收到后会尽快发送下一个关键帧。 FIRFull Intra Request FIR 用于请求发送端发送一个完整的关键帧I-frame通常用于视频通话中的图像清晰度恢复或者加入新的参与者时需要一个完整的起始点。FIR 报文的接收端发送给发送端发送端收到后会立即发送一个完整的关键帧。 REMBReceiver Estimated Maximum Bitrate REMB 用于接收端向发送端报告其估计的最大比特率以便发送端可以根据接收端的带宽情况调整视频编码参数以最大程度地利用可用的带宽。REMB 报文能够帮助发送端动态调整编码比特率以优化视频传输并避免网络拥塞。
四、Compound RTCP
Compound RTCP 是指将多个 RTCPReal-time Control Protocol包合并到一个复合包中一起发送以减少网络传输开销和提高效率。
1、报文结构
一般情况下一个 Compound RTCP 数据包的结构如下
--------------------------------
| RTCP SR/RR |
--------------------------------
| RTCP SDES |
--------------------------------
| Other RTCP |
--------------------------------可以看出规定了必须先以SR/RR开头然后紧接着SDES后面是其他的信息。Compound RTCP 需要周期发送。
2、规则
如果RTCP加密了Compound RTCP 中必须包含加密前缀可选必须包含SR 或 RR报文必须包含SDES报文并且SDES当中只可以有一项CNAME Item可以包含一个或者多个FB报文
3、具体例子
下面是一个SR和SDES组成的Compound RTCP UDP总长为64个字节UDP载荷是56个字节也就是整个Compound RTCP占56个字节这56个字节中有两个RTCP报文一个SR和一个SDES header中也有length为6长度为(61)*4 28字节56-2828就是剩下其他RTCP报文长度
五、总结
本文主要介绍了RTCP协议它配合RTP完成了WebRtc强大的流控策略。
欢迎学习交流
