在VoIP音视频通话中，接收者可以依赖rtcp机制向发送者报告RTP数据接收的统计情况，以便发送者根据接收情况（丢包数量等）调整传输行为（发送速率等）。由于基本的RTCP统计报告是定期发送的，通过该机制来调整发送端行为会有一定的滞后性，比如视频因丢包解码出现花屏时，急需新的I帧来刷新图像。为了解决以上问题，定义了AVPF机制，即RFC4585(RTP/AVPF)：基于RTCP反馈的扩展机制，同时在RFC5104[Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)]中进一步定义了相关的反馈消息。
一、传输层反馈消息（Transport Layer Feedback Messages）
使用RTCP包类型为205，子类消息有如下几种：
RFC4585中定义：
1： NACK（negative acknowledgement） 未确认，丢包请求
31：保留
RFC5104中定义：
2: 保留
3: Temporary Maximum Media Stream Bit Rate Request (TMMBR) 临时最大媒体流码率请求
4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN) 临时最大媒体流码率通知
二、有效数据反馈消息（Payload-Specific Feedback Messages）
使用RTCP包类型为206，子类消息有如下几种：
RFC4585定义:
1: Picture Loss Indication (PLI) 图像丢失指示
2: Slice Lost Indication (SLI) 片丢失指示
3: Reference Picture Selection Indication (RPSI) 参考图像选择指示
15: Application layer FB message 应用层反馈消息
31: 保留
RFC5104定义:
4: Full Intra Request (FIR) Command 完整帧请求
5: Temporal-Spatial Trade-off Request (TSTR) 时空交换请求
6: Temporal-Spatial Trade-off Notifica 时空交换响应
三、关键说明
- a=rtcp-fb用在媒体行层面，可能有多行
- feedback消息简称FB
- SDP中使用RTP/AVPF表明是支持扩展,也有使用RTP/AVP并依赖SDP中的属性表明支持FB功能的
- 在视频会议中，通常使用FB(fir等）消息请求I帧
- 如果SDP中有一个或多个a=rtcp-fb，需要忽略不认识的属性