一种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字段 | 对应的内容 |
| FEC Information | |
| 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）消息格式定义为：
| 字段 | 解释 |
| 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是可以降低冗余版本时，则要持续一段时间都是反馈低冗余版本时再降低冗余版本发送。
- 代码
暂不开源