在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消息简称FBSDP中使用RTP/AVPF表明是支持扩展,也有使用RTP/AVP并依赖SDP中的属性表明支持FB功能的在视频会议中，通常使用FB(fir等）消息请求I帧如果SDP中有一个或多个a=rtcp-fb，需要忽略不认识的属性

文章来源

评论可见，请评论后查看内容，谢谢！！！
 您阅读本篇文章共花了：