一种RTP传输信道质量控制的方法

本文主要是介绍一种RTP传输信道质量控制的方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前面博文已经详细介绍了在实时通话中通过FEC实现丢包恢复的方法，但在实现上还有很多地方需要规范起来的，如：收发双方如何协商FEC参数？编码组长度应该为多长最合适？当前信道质量下应该使用几阶的冗余最合适？等等。本文就是制定了一个规范格式，解决上述问题的。有读者可能会问，收发双方都使用固定的FEC参数就好了（编码组大小固定为16、冗余固定为2阶），这会带来一个问题，信道质量好时不存在丢包，则发送方还是发送冗余包，这会浪费很多的带宽流量；因此需要一个反馈机制，发送端实时动态根据其接收的丢包率和时延等给发送端反馈推荐的FEC参数，发送端收到反馈后采用新的FEC参数进行编码发送。

另外，本方案还考虑到，对于一个已经实现了或商用的系统，如何引入FEC算法对当前的实现架构改变最小，编码数据包可变长（也就是一个编码组内的这些数据包长度不要求都是相同长度的）。本方案不需要通过额外的信令进行FEC参数协商，直接在冗余包中携带FEC参数和信道质量反馈（双工业务时），发送端根据实时信道质量动态调整FEC参数。

RTP打包—发送—接收—RTP解包流程

上图展示了音频或者视频的打包发送、以及接收解包过程，如果在传输有丢包，则接收端是无法恢复出丢包的，所以对应的音视频包就会缺失或者不完整了，声音就会不流畅或者视频花屏。

引入FEC功能后的处理流程

引入FEC功能后，1）发送端打包RTP时需要RTP的padding标志位设置为1，padding字段值为1，要求必须打padding的原因是：变长的数据进行FEC解码时需要这个非0的padding作为RTP数据包边界，因为FEC解码出来的数据长度可能会大于实际RTP数据包的长度，但多出来的数据都是0，有了这个非0的padding后，FEC解码出来的数据就可以将最右边所有填充0删除后就得到原始的RTP包。2）原始的RTP包经过FEC编码器后数据不变，只是会被插入一些冗余包，冗余包携带的内容有：a)冗余数据、b)FEC参数、c)信道质量反馈。3）从这个流程图可以看出来，在现有RTP实时音视频项目中引入本方案的对原有的流程修改非常小，也就是打包RTP时需要多打一个padding位而已，如果现有项目已经设置了padding位则就更简单了。

冗余包的格式

RTP Header：各个字段取值固定如下

V：0

P：1

X：0

CC ：0

M：1

PT：0

SN：0

Redundant Data：冗余数据，其由前博文《FEC算法》计算出来

PiggyMsg：Piggy消息，用于携带FEC参数和信道质量反馈，格式如下，

采用TLV格式封装数据，T长度为4bits，L的长度为4bits。

Magic Number：为特殊标记，其固定为0xA5。

Length：为整个消息的长度，包括所有的TLV、Magic Number、Length、CRC8等所有字段。

CRC8：CRC校验字段，采用0x31多项式。

T字段取值表
T字段	对应的内容
$(0000)_{2}$	FEC Information
$(0001)_{2}$	CQI（信道质量指示）
其它值	保留

FEC Information格式定义如下：

GDLI	RV	RI
GroupID
GroupID

GDLI: 2bits，编码组长度指示（每个编码组内数据包的数量）：

GDLI	编码内数据包个数
0	8
1	16
2	32
3	64

RV: 3bits，冗余版本，表示本编码组所使用的冗余版本：

RV	冗余版本
0	0阶冗余，无冗余
1	1阶冗余
2	2阶冗余
3	3阶冗余
other	保留

RI: 3bits，本冗余包的阶数，表示本冗余包是哪阶的冗余数据；例如，当前编码组使用三阶冗余(RV=3)，则一个编码组内有三个冗余包（一阶冗余包、二阶冗余包、三阶冗余包），那么这个RI就表示当前冗余包是哪阶的冗余包。

RI	冗余阶数
0	0阶冗余，无冗余
1	1阶冗余
2	2阶冗余
3	3阶冗余
other	保留

GroupID: 2bytes，编码组ID，网络字节序；GroupID=RTP_SN/GroupLen。

编码组的起始包必须满足条件：

RTP_SN% GroupLen = 0；

接收端解码时，先收到FEC information后，再下一个编码组FEC解码生效，收到FEC information之前的数据包若有丢失是不会进行恢复的，如果FEC的编码组长度发生变化，则当前编码组数据不会进行恢复，下个编码组才生效。

信道质量指示（CQI）消息格式定义为：

CQI参数定义
字段	解释
r	保留位，当前不使用
a	关联信道CQI是否存在。 0: 不存在 1:存在
GDLI	2bits，接收端反馈推荐使用的编码组长度指示；
RV	3bits，接收端反馈推荐使用的冗余版本
RFR	音频或者视频的接收帧率
aGDLI	2bits，关联信道的接收端反馈推荐使用的编码组长度指示
aRV	3bits，关联信道的接收端反馈推荐使用的冗余版本
aRFR	关联信道的接收帧率

由于Btrunc标准里面规定的集群业务，语音几乎都是双工的(除了组合和半双工单呼)，一般网络下都会配置为优先保障语音，因此选择语音和视频的信道质量都通过语音信道反馈。对于组呼和半双工单呼，采用固定FEC参数的方式，其它业务采用根据接收端反馈的信道质量动态调整FEC参数的方式。

接收端反馈CQI的RV和GDLI取值应该遵守一个核心原则，也就所选择反馈的RV必须不小于一个编解码组的丢包数；一个简单可行的算法是统计每个编码组的丢包数，取最近一段时间（比如3秒）的最大丢包数作为反馈的RV值；发送端收到CQI后进行RV调整时应该遵守的一个基本原则是“快升慢降”；所谓“快升慢降”，就是发送端收到接收端反馈的CQI是要提升冗余版本时，则在下个编码组开始立刻提升冗余版本，如果接收端反馈CQI是可以降低冗余版本时，则要持续一段时间都是反馈低冗余版本时再降低冗余版本发送。