RTCP协议

AGoodrMe
460 阅读5分钟

RTCP：RTP 控制协议 （RTCP：RTP Control Protocol）

RTCP包在协议栈中位置

  • 最底层为网络层, 包含一个14字节的Mac Header和一个4字节的Mac Tailer, 这是每一个数据包必须要有的

  • 以太网中数据包最大长度为1500字节

RTCP Header

  • Version : 协议的版本

  • P : 1位, 是否有填充位, 最后一个字节是填充字节的个数(包含该字节本身)

  • Count : 5位, RTCP协议中包含的report block的个数

  • Type : 8位, 类似RTP协议中的payload type, 这里代表不同的功能

  • Length : 16位, RTCP数据包的长度 , 包括包头, 数值为(N-1)个4字节

  • Data : 数据

RTCP Type

  • 200 : 发送报告, 例如: 发送包的数量、丢包个数、...
  • 201 : 接收报告, 例如: 接收包的数量、丢包个数、...
  • 202 : 媒体源描述
  • 203 : 当不需要传输数据时, 发送bye类型消息, 结束传输
  • 204 : 应用自定义消息类型, 还可以定义子类型消息

  • 192 : 向对方请求一个关键帧

  • 193 : 当接受的数据包发送丢失的情况下, 向发送端发送此消息, 发送端会检查是否超时, 如果没有超时 则会根据nack中的消息将丢失的包重新发送, FB的nack报文较这里的nack更加常用

  • 205 : 一般性的关于RTP的Feedback, 内部有多个子类型

  • 206 : 根据负载情况返回的信息

RTCP FB Type

RTCP RTPFB Type

  • FMT : feedback message type, 即消息类型的id

  • TMMBR : 发送最大码流的请求

  • TMMBN : 发送最大码流的请求的响应

  • TFB : 传输层的拥塞控制报文

RTCP PSFB Type

RTCP FB Header

RTCP SR

  • RTCP中可以包含多个report block, 每一个SSRC都会对应一个report block, 接收的每一路流对应一个SSRC

  • SR中包含接收数据的信息可以用一个包就把发送和接收的数据发给对端, 避免浪费一个包的资源

RTCP SR --- Sender Info block

  • NTP timestamp : 64位, 网络时间戳, 真实世界中的真实时间, 用来做音视频同步

  • RTP timestamp : 32位, 针对该路流的一个相对时间,  与RTP包时间戳(发送时间)一致,多路流之间该属性是没有联系的

  • packet count : 32位, 总发包数

  • octet count : 32位, 总共发送的数据量是多少字节

RTCP SR --- Receiver Report block

  • SSRC_n : 32位, 接收到的每一个数据源, 即该block中的数据都是根据该数据源为基础

  • fraction lost : 8位, 上一次报告之后从SSRC_n来包的丢包比例

  • packets lost : 24位, 自接收开始丢包总数, 迟到包不算丢包, 重传会导致负数

  • hightest seq nun : 低16位表示收到的最大seq, 高16位表示seq循环次数

  • jitter : RTP包到达时间间隔统计方差, 判断是否发送网络拥塞, 如果包到达时间间隔不断增加, 则表明发送了网络拥塞

  • last SR : 32位, NTP时间戳的中间32位

  • delay LSR : 记录上一个接收SR的时间与上一个发送SR的时间差

RTCP RR

  • 相较于SR , RR中没有sender info block, 

  • RR与SR的payload type不同

  • SR是在一端同时具有发送和接收的功能的时候使用

  • RR是在一端只有接收功能的时候使用

RTCP SDES

  • SC 表示SSRC/CSRC的个数

  • 每一个item对应一个SSRC

  • item采用TLV格式(type、length、value)存放数据

  • CNAME : SSRC的规范名, 例如: SSRC是“123”, CNAME就会命名为一个字母数字混合的长字符串, 此时ssrc和cname是唯一绑定的, webrtc中是通过cname标识每一路流的, 具体该路流的SSRC是通过SDES协商的. 当多个流中出现SSRC冲突的时候, 就需要重新命名SSRC并且和对应的CNAME重新绑定

RTCP SDES item

  • TLV格式

  • T : type 位CNAME 用“1”表示

  • L : length

  • V : CNAME的值

type 除了CNAME 还有其他的类型, 如下图

  • CNAME ID为1, 其他type的ID依次按顺序递增

WebRTC中使用SDES

  • 媒体协商时, 为每个源(SSRC)设置了一个CNAME

  • 通过RTCP SDES报文确认CNAME与SSRC的关系

Compound RTCP

  • 多个RTCP包放在同一个UDP包中发送

  • 它们像栈一样存放, 一个放在另一个后面, 串联在一起

  • 每个RTCP包之间, 不需要明确的分割, 要解析里面的报文, 就需要通过将UDP包的headed中的length与内部报文的header中的length属性进行计算逐步找到每一个报文

  • 需要周期性的发送

  • 通过SR / RR可以周期性的知道发送和接收状况, 进而判断带宽状况

  • 当作探测包, 探测网络状况

  • 在Compound RTCP中, 一般是以SR/RR 开头, 后面跟SDES

Compound RTCP 规则

  • 必须包含SR / RR报文

  • 必须包含SDES报文, SDES中可以只有一项CNAME Item

  • 可以包含一个或多个FB报文

  • 如果RTCP加密了, Compound RTCP中必须包含加密前缀(可选)

Compound RTCP 两种类型

  • 最小Compound RTCP, 只包括规则的必选项, WebRTC使用这种类型.
  • 完整的Compound RTCP, 可以包含任意数据的RTCP报文
avatar
文章
阅读
粉丝