RTCP是RTP的控制協議.
那么RTCP能對RTP做哪些控制呢？其中最為大家熟知的就是 丟包控制。
發送端發送數據后，接收端如果發現有RTP包丟失了，可以使用RTCP的 NACK報文通知發送方，告訴對方具體是哪些包丟失了，然后讓發送方重發前面丟失的包。
此外，接收端還可以使用RTCP的 RR報文向發送端發送接收報告，報告中記錄著從上一次報告到本次報告之間丟失了多少包、丟包率是多少、延時是多少等一系列信息。
同理，發送端也可以向接收端發送 SR報文，報告一段時間內一共發送了多少包等。
RTCP支持的消息非常多，在此我們將一些最常見的RTCP報文消息整理了出來.
SR和RR報文。這兩個報文在WebRTC中至關重要，因為網絡質量評估與控制需要的大量參數都是從這兩個報文中獲得的。
下面介紹一下RTCP支持的其他的消息類型：

RTCP支持的消息類型

SDES報文是用來描述（音視頻）媒體源的。它可以描述的內容包括媒體源的名稱、Email地址，電話等。但實際上，這些描述項都沒太大價值。唯一有價值的是CNAME項，其作用是將不同的源（SSRC）綁定到同一個CNAME上。舉個例子，當SSRC有沖突時，可以通過CNAME將舊的SSRC更換成新的SSRC，從而保證在通信的每個SSRC都是唯一的。
BYE報文用于說明哪些（音視頻）媒體源現在不可用了。當WebRTC收到該報文后，應該將SSRC所對應的通道刪除。
APP報文是給應用預留的RTCP報文，應用可以根據自己的需要自定義一些應用層可以解析的報文。
RTPFB報文，即RTP的反饋報文，是指RTP傳輸層面的報文。該報文可以裝入不同類型的子報文。
與RTPFB對應的是PSFB，即RTP中與負載相關的反饋報文。同樣，該報文也可以裝入不同類型的子報文。

RTCP協議頭

RTCP協議頭如下：

Version即協議版本，固定值為2。P字段為填充位標識。PT字段即Payload Type，與RTP中的PT字段類似。
RTCP中的Count字段是RTP中所沒有的，該值針對RTCP中不同的報文有不同的含義：
對于RR/SR報文而言，Count表示它們所攜帶的接收報告的個數；
對SDES報文而言，Count表示SDES報文中item的個數；
對于BYE報文而言，Count表示BYE報文中SSRC/CSRC的個數；
而對于APP報文來說變化就比較大了，Count用于標識應用自定義的子消息類型。
Length字段表示整個RTCP包的大小，包括RTCP頭、RTCP負載以及填充字節。需要注意的是，Length字段是以4字節為單位的，即（N?1）個4字節。

WebRTC的反饋報文

已知PT為205和206的報文類型屬于反饋報文。報文中可以包含多個子報文，其中WebRTC使用到的報文只有某幾項。

RTPFB支持的報文類型：

第一項NACK，用于通知發送方在上次包發送周期內有哪些包丟失了：
NACK報文中包含兩個字段：PID和BLP。PID（Package ID）字段用于標識從哪個包開始統計丟包；
而BLP（16位）字段表示從PID包開始，接下來的16個RTP包的丟失情況。（BLP（Bitmask of Following Lost Packet），從丟失包開始的位掩碼）
第二項TMMBR和第三項TMMBN是一對報文，TMMBR表示臨時最大碼流請求報文，TMMBN是對臨時最大碼流請求的應答報文。這兩個報文雖然在WebRTC中實現了，但已被WebRTC廢棄，其功能由TFB和REMB報文所代替。
第四項TFB是WebRTC中TCC[插圖]算法的反饋報文，該報文會記錄包的延遲情況，然后交由發送端的TCC算法計算下行帶寬。(TCC（Transport-wide Congestion Control），基于發送端的帶寬評估算法)

PSFB支持的報文類型：

PSFB報文包括PLI報文、FIR報文以及REMB報文。
其中PLI報文與FIR報文很類似，當發送端收到這兩個報文時，都會觸發生成關鍵幀（IDR幀）。
PLI報文是在接收端解碼器無法解碼時發送的報文。
FIR報文主要應用于多方通信時后加入房間的參與者向已加入房間的共享者申請關鍵幀。通過這種方式，可以保障后加入房間的參與者不會因收到的第一幀不是關鍵幀而引起花屏或黑屏的問題。
REMB報文是WebRTC增加的反饋報文，用于將接收端評估出的帶寬值發給發送端。不過，由于最新的WebRTC已全面啟用基于發送端的帶寬估算方法，即TCC，因此目前REMB僅用于向后兼容，不再做進一步更新。

參考

李超《WebRTC音視頻實時互動技術:原理、實戰與源碼分析》
https://weread.qq.com/web/reader/377320f07260a55337761c1kc81322c012c81e728d9d180