RTCP協議介紹
RTCP概要
實時傳輸控制協議(Real-time ControlProtocol，RTCP)與RTP共同定義在1996年提出的RFC 1889中，是和 RTP一起工作的控制協議。RTCP單獨運行在低層協議上，由低層協議提供數據與控制包的複用。在RTP會話期間，每個會話參與者週期性地向所有其他參與者發送RTCP控制信息包，如下圖所示。對於RTP會話或者廣播，通常使用單個多目標廣播地址，屬於這個會話的所有RTP和RTCP信息包都使用這個多目標廣播地址，通過使用不同的端口號可把RTP信息包和RTCP信息包區分開來。
圖 每個參與者週期性地發送RTCP控制信息包
RTCP功能
1、爲應用程序提供會話質量或者廣播性能質量的信息
RTCP的主要功能是爲應用程序提供會話質量或者廣播性能質量的信息。每個RTCP信息包不封裝聲音數據或者電視數據，而是封裝發送端（和 / 或者）接收端的統計報表。這些信息包括發送的信息包數目、丟失的信息包數目和信息包的抖動等情況，這些反饋信息反映了當前的網絡狀況，對發送端、接收端或者網絡管理員都非常有用。RTCP規格沒有指定應用程序應該使用這些反饋信息做什麼，這完全取決於應用程序開發人員。例如，發送端可以根據反饋信息來調整傳輸速率，接收端可以根據反饋信息判斷問題是本地的、區域性的還是全球性的，網絡管理員也可以使用RTCP信息包中的信息來評估網絡用於多目標廣播的性能。
2、確定 RTP用戶源
RTCP爲每個RTP用戶提供了一個全局唯一的規範名稱 (Canonical Name)標誌符 CNAME，接收者使用它來追蹤一個RTP進程的參加者。當發現衝突或程序重新啓動時，RTP中的同步源標識符SSRC可能發生改變，接收者可利用CNAME來跟蹤參加者。同時，接收者也需要利用CNAME在相關RTP連接中的幾個數據流之間建立聯繫。當 RTP需要進行音視頻同步的時候，接受者就需要使用 CNAME來使得同一發送者的音視頻數據相關聯，然後根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。
3、控制 RTCP傳輸間隔
由於每個對話成員定期發送RTCP信息包，隨着參加者不斷增加，RTCP信息包頻繁發送將佔用過多的網絡資源，爲了防止擁塞，必須限制RTCP信息包的流量，控制信息所佔帶寬一般不超過可用帶寬的 5%，因此就需要調整 RTCP包的發送速率。由於任意兩個RTP終端之間都互發 RTCP包，因此終端的總數很容易估計出來，應用程序根據參加者總數就可以調整RTCP包的發送速率。
4、傳輸最小進程控制信息
這項功能對於參加者可以任意進入和離開的鬆散會話進程十分有用，參加者可以自由進入或離開，沒有成員控制或參數協調。
RTCP信息包
RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。
類似於RTP信息包，每個RTCP信息包以固定部分開始，緊接着的是可變長結構單元，最後以一個32位邊界結束。
根據所攜帶的控制信息不同RTCP信息包可分爲RR（接收者報告包）、SR（源報告包）、SEDS（源描述包）、BYE（離開申明）和APP（特殊應用包）五類5類：
|
類型 |
縮寫表示 |
用途 |
|
200 |
SR（Sender Report） |
發送端報告 |
|
201 |
RR（Receiver Report） |
接收端報告 |
|
202 |
SDES（Source Description Items） |
源點描述 |
|
203 |
BYE |
結束傳輸 |
|
204 |
APP |
特定應用 |
| Type | Description | References |
|---|---|---|
| 0 - 191 |
||
| 192 | FIR, full INTRA-frame request. | RFC 2032 |
| 193 | NACK, negative acknowledgement. | RFC 2032 |
| 194 | SMPTETC, SMPTE time-code mapping. | RFC5484 |
| 195 | IJ, extended inter-arrival jitter report. | RFC 5450 |
| 196 - 199 |
||
| 200 | SR, sender report. | RFC 3550 |
| 201 | RR, receiver report. | RFC 3550 |
| 202 | SDES, source description. | RFC 3550 |
| 203 | BYE, goodbye. | RFC 3550 |
| 204 | APP, application defined. | RFC 3550 |
| 205 | RTPFB, Generic RTP Feedback. | |
| 206 | PSFB, Payload-specific Feedback. | |
| 207 | XR, RTCP extension. | RFC 3611 |
| 208 | AVB, AVB RTCP packet. | IEEE 1733 |
| 209 | RSI, Receiver Summary Information. | RFC 5760 |
| 210 - 255 |
1、SR：
發送端報告包，用於發送和接收活動源的統計信息；
發送端報告分組SR（Sender Report）用來使發送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的SSRC，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的字節數。SR包的封裝如下圖所示：
版本（V）：同RTP包頭域。
填充（P）：同RTP包頭域。
接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以爲零。
包類型（PT）：8比特，SR包是200。
長度域（Length）：16比特，其中存放的是該SR包以32比特爲單位的總長度減一。
同步源（SSRC of sender）：SR包發送者的同步源標識符。與對應RTP包中的SSRC一樣。
NTP Timestamp（Network time protocol）SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。
RTP Timestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值。
Sender’s packet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的RTP數據包的總數. SSRC改變時，這個域清零。
Sender`s octet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的淨荷數據的總字節數（不包括頭部和填充）。發送者改變其SSRC時，這個域要清零。
同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統計信息。
丟失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP數據包的丟失率。
累計的包丟失數目：從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP數據包的丟失總數。
收到的擴展最大序列號：從SSRC_n收到的RTP數據包中最大的序列號，
接收抖動（Interarrival jitter）：RTP數據包接受時間的統計方差估計
上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。
上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發送本報告的延時。
2、RR：
接收者報告包，用於接收非活動站的統計信息；
3、SDES：
源描述包，用於報告和站點相關的信息，包括CNAME；
4、BYE：
斷開RTCP包，是站點離開系統的報告，表示結束；
5、APP：
應用特定函數。
不同類型的RTCP信息包可堆疊，不需要插入任何分隔符就可以將多個RTCP包連接起來形成一個RTCP組合包，然後由低層協議用單一包發送出去。由於需要低層協議提供整體長度來決定組合包的結尾，在組合包中沒有單個RTCP包的顯式計數。
組合包中每個RTCP包可獨立處理，而不需要按照包組合的先後順序處理。在組合包中有以下幾條強制約束：
1、只要帶寬允許，在SR包或RR包中的接收統計應該經常發送，因此每個週期發送的組合RTCP 包中應包含報告包。
2、每個組合包中都應該包含SDES CNAME，因爲新接收者需要通過接收CNAME來識別源，並與媒體聯繫進行同步。
3、組合包前面是包類型數量，其增長應該受到限制。
所有RTCP包至少必須以兩個包組合形式發送，推薦格式如下：
加密前綴（Encryption prefix）：
僅當組合包被加密，才加上一個32位隨機數用於每個組合包發送。
SR或RR：
組合包中第一個RTCP包必須是一個報告包，以幫助分組頭的確認。即使沒有數據發送，也沒有接收到數據，也要發送一個空RR，那怕組合包中RTCP包爲BYE。
附加RR：
如報告統計源數目超過31，在初始報告包後應該有附加RR包。
SDES：
包含CNAME 項的SDES包必須包含在每個組合RTCP包中。SDES包可能包括其他源描述項，這要根據特別的應用需要，並同時考慮帶寬限制。
BYE或APP：
除了BYE應作爲最後一個包發送，其它RTCP包類型可以任意順序排列，包類型出現可不止一次。
混合器從多個源組合單個RTCP包，如組合包整體長度超過網絡路徑最大傳輸單元，可分成多個較短組合包用低層協議以單個包形式發送。注意，每個組合包必須以SR或RR包開始。附加RTCP包類型可在Internet Assigned NumbersAuthority (IANA)處註冊，以獲得合法的類型號。
RTCP傳輸間隔
由於RTP設計成允許應用自動擴展，可從幾個人的小規模系統擴展成上千人的大規模系統。而每個會話參與者週期性地向所有其他參與者發送RTCP控制信息包，如每個參與者以固定速率發送接收報告，控制流量將隨參與者數量線性增長。由於網絡資源有限，相應的數據包就要減少，直接影響用戶關心的數據傳輸。爲了限制控制信息的流量，RTCP控制信息包速率必須按比例下降。
一旦確認加入到RTP會話中，即使後來被標記成非活動站，地址的狀態仍會被保留，地址應繼續計入共享RTCP帶寬地址的總數中，時間要保證能掃描典型網絡分區，建議爲30分鐘。注意，這仍大於RTCP報告間隔最大值的五倍。
SR源報告包和RR接收者報告包
SR源報告包和RR接收者報告包用於提供接收質量反饋，除包類型代碼外，SR與RR間唯一的差別是源報告包含有一個20字節發送者信息段。RR針對每個信源都提供信息包丟失數、已收信息包最大序列號、到達時間抖動、接收最後一個SR的時間、接收最後一個SR的延遲等信息。SR不僅提供接收質量反饋信息（與RR相同），而且提供SSRC標識符、NTP時間戳、RTP時間戳、發送包數以及發送字節數等。根據接收者是否爲發送者來決定使用SR還是RR包，活動源在發出最後一個數據包之後或前一個數據包與下一個數據包間隔期間發送SR；否則，就發送RR；SR和RR包都可沒有接收報告塊也可以包括多個接收報告塊，其發佈報告表示的源不一定是在CSRC列表上的起作用的源，每個接收報告塊提供從特殊源接收數據的統計。最大可有31個接收報告塊嵌入在SR 或 RR包中，丟失包累計數差別給出間隔期間丟包的數量，而系列號的差別給出間隔期間希望發送的包數量，兩者之比等於經過間隔期間包丟失百分比。從發送者信息，第三方監控器可計算載荷平均數據速率與沒收到數據間隔的平均包速率，兩者比值給出平均載荷大小。如假設包丟失與包大小無關，那麼特殊接收者收到的包數量給出此接收者收到的表觀流量。
SDES源描述包
SDES源描述包提供了直觀的文本信息來描述會話的參加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述項，這些爲接收方獲取發送方的有關信息提供了方便。SDES 包由包頭與數據塊組成，數據塊可以沒有，也可有多個。包頭由版本（V）、填充（P）、長度指示、包類型（PT）和源計數（SC）組成。PT佔8位，用於識別RTCP的SDES包，SC佔5位，指示包含在SDES包中的SSRC/CSRC塊數量，零值有效，但沒有意義。數據塊由源描述項組成，源描述項的內容如下：
CNAME: 規範終端標識SDES項
類似SSRC標識，RTCP爲RTP連接中每一個參加者賦予唯一一個CNAME標識。在發生衝突或重啓程序時，由於隨機分配的SSRC標識可能發生變化，CNAME項可以提供從SSRC標識到仍爲常量的源標識的綁定。
爲方便第三方監控，CNAME應適合程序或人員定位源。
NAME：用戶名稱SDES項
這是用於描述源的真正的名稱，如"John Doe, Bit Recycler, Megacorp"，可以是用戶想要的任意形式。由於採用文本信息來描述，對諸如會議應用，可以對參加者直接列表顯示，NAME項是除CNAME項以外發送最頻繁的項目。NAME值在一次RTP會話期間應該保持爲常數，但它不該成爲連接的所有參加者中唯一依賴。
EMAIL：電子郵件地址SDES項
郵件地址格式由RFC822規定，如"[email protected]"。一次RTP會話期間，EMAIL項的內容希望保持不變。
PHONE：電話號碼SDES項
電話號碼應帶有加號，代替國際接入代碼，如"+1 908 555 1212"即爲美國電話號碼。
LOC：用戶地理位置SDES項
根據應用，此項具有不同程度的細節。對會議應用，字符串如"Murray Hill, New Jersey"就足夠了。然而，對活動標記系統，字符串如"Room 2A244, AT&T BL MH"也許就適用。細節留給實施或用戶，但格式和內容可用設置指示。在一次RTP會話期間，除移動主機外，LOC值期望保持不變。
TOOL：應用或工具名稱SDES項
TOOL項包含一個字符串，表示產生流的應用的名稱與版本，如"videotool 1.2"。這部分信息對調試很有用，類似於郵件或郵件系統版本SMTP頭。TOOL值在一次RTP會話期間保持不變。
NOTE: 通知/狀態SDES項
NOTE 項旨在描述源當前狀態的過渡信息，如"on the phone, can't talk"，或在講座期間用於傳送談話的題目，它的語法可在設置中顯式定義。NOTE項一般只用於攜帶例外信息，而不應包含在全部參加者中，因爲這將降低接收報告和CNAME發送的速度，損害協議的性能。一般NOTE 項不作爲用戶設置文件的項目，也不會自動產生。
由於NOTE項對顯示很重要，當會話的參加者處於活動狀態時，其它非CNAME項（如NAME）傳輸速率將會降低，結果使NOTE項佔用RTCP部分帶寬。若過渡信息不活躍，NOTE項繼續以同樣的速度重複發送幾次，並以一個串長爲零的字符串通知接收者。
PRIV: 專用擴展SDES項
PRIV項用於定義實驗或應用特定的SDES擴展，它由長字符串對組成的前綴，後跟填充該項其他部分和攜帶所需信息的字符串值組成。前綴長度段爲8位。前綴字符串是定義PRIV項人員選擇的名稱，唯一對應應用接收到的其它PRIV項。應用實現者可選擇使用應用名稱，如有必要，外加附加子類型標識。另外，推薦其它人根據其代表的實體選擇名稱，然後，在實體內部協調名稱的使用。
注意，前綴應儘可能的短。SDES的PRIV項前綴沒在IANA處註冊。如證實某些形式的PRIV項具有通用性， IANA應給它分配一個正式的SDES項類型，這樣就不再需要前綴，從而簡化應用，並提高傳輸的效率。
BYE斷開RTCP包
如混合器接收到一個BYE包，混合器轉發BYE包，而不改變SSRC/CSRC 標識。如混合器關閉，在關閉之前它應該發出一個BYE包，列出混合器處理的所有源，而不只是自己的SSRC標識。作爲可選項，BYE包可包括一個8位八進制計數，後跟文本信息，表示離開原因，如："cameramalfunction"或"RTPloop detected"。字符串的編碼與在SDES 項中所描述的相同。如字符串信息至BYE包下32位邊界結束處，字符串就不以空結尾；否則，BYE包以空八進制填充。
APP特殊應用包
APP包用於開發新應用和新特徵的實驗，不要求註冊包類型值。帶有不可識別名稱的APP包應被忽略掉。測試後，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA註冊子類型和名稱段。
RTP/ RTCP的不足之處
RTP與RTCP相結合雖然保證了實時數據的傳輸，但也有自己的缺點。最顯著的是當有許多用戶一起加入會話進程的時候，由於每個參與者都週期發送RTCP信息包，導致RTCP包氾濫(flooding)。