RTCP資料詳解

轉自：http://www.360doc.com/content/13/0606/10/1317564_290865866.shtml

 

RTCP

   RTCP協議將控制包周期發送給所有連接者，應用與數據包相同的分發機制。低層協議提供數據與控制包的復用，如使用單獨的UDP端口號。RTCP執行下列四大功能：

   (1) 主要是提供數據發布的質量反饋。RTCP是作為RTP傳輸協議的一部分，與其他傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用，但IP多播經驗表明，從發送者收到反饋對診斷發送錯誤是至關重要的。給所有參加者發送接收反饋報告允許問題觀察者估計那些問題是局部的，還是全局的。諸如IP多播等發布機制使網絡服務提供商之類的團體可能接收反饋信息，充當第三方監控者來診斷網絡問題。反饋功能由RTCP發送者和接收者報告執行。

    (2)RTCP帶有稱作規范名字(CNAME)的RTP源持久傳輸層標識。如發現沖突，或程序重新啟動，既然SSRC標識可改變，接收者需要CNAME跟蹤參加者。接收者也需要CNAME與相關RTP連接中給定的幾個數據流聯系。

   (3)前兩種功能要求所有參加者發送RTCP包，因此，為了RTP擴展到大規模數量，速率必須受到控制。讓每個參加者給其他參加者發送控制包，就加大獨立觀察參加者數量。該數量用於計算包發送的速率。

   (4)可選功能是傳送最小連接控制信息，如辨識參加者。最可能用在“松散控制”連接，那里參加者自由進入或離開，沒有成員控制或參數協調，RTCP充當通往所有參加者的方便通道，但不必支持應用的所有控制通訊要求。

在IP多播場合應用RTP時，前三個功能是必須的，推薦用於所有情形。RTP應用設計人員必須避免使用僅在單播模式下工作的機制，那將導致無法擴展規模。

 

（一）RTCP包格式

   下面定義幾個攜帶不同控制信息的RTCP包類型：

• SR（SenderReport）：發送者報告，當前活動發送者發送、接收統計。

• RR（ReceiverReport）：接收者報告，非活動發送者接收統計。

• SDES（SourceDescription）：源描述項，包括CNAME, NAME, EMAIL,PHONE等。

• BYE：表示結束。

• APP（application）：應用特定函數。

   類似於RTP數據包，每個RTCP包以固定部分開始，緊接着的是可變長結構元素，但以一個32位邊界結束。包含安排要求和固定部分中長度段，使RTCP包可堆疊。不需要插入任何分隔符將多個RTCP包連接起來形成一個RTCP組合包，以低層協議用單一包發送出去。由於需要低層協議提供整體長度來決定組合包的結尾，在組合包中沒有單個RTCP包顯式計數。

   組合包中每個RTCP包可獨立處理，不需要根據包組合順序。但為了執行協議功能，強加如下約束：

   (1) 接收統計(在SR或RR中)應該經常發送，只要帶寬允許，因此每個周期發送的組合RTCP包應包含報告包。

   (2) 新接收者需要接收CNAME，並盡快識別源，開始聯系媒介進行同步，因此每個包應該包含SDESCNAME。

   (3) 出現在組合包前面的是包類型數量，其增長應該受到限制，以提高常數位數量，提高成功確認RTCP包對錯誤地址RTP數據包或其他無關包的概率。

因此，所有RTCP包至少必須以兩個包組合形式發送，推薦格式如下：

   ①加密前輟(Encryption prefix)

       僅當組合包被加密，才加上一個32位隨機數用於每個組合包發送。

    ②SR或RR

       組合包中第一個RTCP包必須總為一個報告包，方便頭的確認。即使沒有數據發送，也沒有接收到數據，也要發送一個空RR，即避免組合包中RTCP包為BYE（終止標識）。

    ③附加RR

        如報告統計源數目超過31，在初始報告包后應該有附加RR包。

    ④SDES

       包含CNAME項的SDES包必須包含在每個組合RTCP包中。如應用要求，其他源描述項可選，但受到帶寬限制。

    ⑤BYE或APP

       其他RTCP包類型可以任意順序排列，除了BYE應作為最后一個包發送，包類型出現可不止一次。

   建議轉換器或混合器從多個源組合單個RTCP包。如組合包整體長度超過網絡路徑量最大傳輸單元，可分成多個較短組合包用低層協議以單個包形式發送。注意，每個組合包必須以SR或RR包開始。附加RTCP包類型可在因特網分配號碼機構（IANA，InternetAssighnedd Numbers Authority）處注冊。

 

RTCP傳輸間隔

   RTP設計成允許應用自動擴展，連接數可從幾個到上千個。例如，音頻會議中，數據流量是內在限制的，因為同一時刻只有一兩個人說話；對多播，給定連接數據率仍是常數，獨立於連接數。但控制流量不是內在限制的。如每個參加者以固定速率發送接收報告，控制流量將隨參加者數量線性增長，因此，速率必須按比例下降。

   對每個連接，假定數據流量受到“連接帶寬”的總量限制。選擇連接帶寬是根據費用或網絡帶寬的先驗知識，與媒體編碼無關，但編碼選擇會受到連接帶寬的限制。當調用一個媒體應用時，連接帶寬參數由連接管理應用提供，但媒體應用也可根據單個發送者數據帶寬設置缺省值。應用可根據多播范圍規則或其他標准強制限制帶寬。由於這是資源預訂系統需要知道的，對控制與數據流量的帶寬計算包括低層傳輸與網絡協議。應用也需要知道在使用哪個協議。在傳輸途中，因為包將包含不同連接層的包頭，所以連接層的包頭不計算在內。控制流量應限制為連接帶寬中已知的一小部分：小，傳遞數據的傳輸協議主要功能才不致受損；已知，控制流量才能包含在所給資源預訂協議的帶寬規范中，這樣，每個參加者就可單獨計算其共享量。建議分配給RTCP的連接帶寬固定為5％，而這個數值與間隔計算中其他常量並不重要，連接中所有參加者必須使用相同數值，因此，使用相同間隔計算。

計算RTCP包間隔依賴連接中地址加入數量的估計。當新地址被監聽到，就加到此計數，並在以SSRC或CSRC標識索引的表中為之建立一個條目，用來跟蹤它們。直到收到帶有多個新SSRC包，新條目才有效。當收到具有相應SSRC標識的RTCP的BYE包，條目可從表中刪除。如果對少量RTCP報告間隔沒有接收到RTP或RTCP包，參加者可能將另外一個地址標記成不活動，如還未生效就刪除掉。這為防止包丟失提供強大支持。為了“超時”正常工作，所有地址必須對RTCP報告間隔記入大致相同的數值。

一旦確認地址有效，如后來標記成不活動，地址的狀態應仍保留，地址應繼續計入共享RTCP帶寬地址的總數中，時間要保證能掃描典型網絡分區，建議為30分鍾。注意，這仍大於RTCP報告間隔最大值的五倍。

   這個規范定義了除必需的CNAME外的幾個源描述項，如NAME(人名)和E-mail(電子郵件地址)。它也是定義新特定應用RTCP包類型的途徑。給附加信息分配控制帶寬應引起注意，因為它將降低接收報告和CNAME發送的速率而損害協議的性能。建議分配給單個參加者用於攜帶附加信息的RTCP帶寬不要超過20％。而且並沒有有意讓所有SDES項包含在每個應用中。

 

發送者與接收者報告

   RTP接收者使用RTCP報告包提供接收質量反饋，報告包則根據接收者是否是發送者而采用兩種格式中的一種。除包類型代碼外，發送者報告與接收者報告間惟一的差別是發送者報告包含一個20個字節發送者信息段。如某地址在發出最后或前一個報告間隔期間發送數據包，就發布SR；否則，就發出RR。SR和RR都可沒有或包括多個接收報告塊。發布報告不是為列在CSRC列表上的起作用的源，每個接收報告塊提供從特殊源接收數據的統計。最大可有31個接收報告塊嵌入在SR或RR包中，附加RR包可堆疊在初始SR或RR包之后。

   發送者報告包由三部分組成，也可能還有第四個特定設置擴展部分

 

 

圖1 發送者報告包

   1) 第一部分為頭，8個八位組長，內容如下。

       ① 版本（V）：2位，標識RTP版本。

       ② 填充(P)：1位，如設置於此位，RTCP包結尾包含一些附加填充八位組，它們不屬於控制信息。最后一個八位組填充表示應忽略多少個填充。有些加密算法需要填充，塊大小固定。在組合RTCP包內，填充僅在最后一個包中需要，因為組合包加密成一個整體。

       ③ 接收報告計數(RC)：5位，包含在包內的接收報告塊數目，0值為有效。

       ④ 包類型(PT)：8位，包含常數200標識此包為RTCP的SR包。

       ⑤ 長度：16位，32位字RTCP包長度的一半。

       ⑥ SSRC：32位，同步源標識。

   2) 第二部分為發送者信息，20個八位組，出現在每個發送者報告包中。含義如下。

       ① NTP時標：64位，表示報告發送時的時鍾時間，這樣它就可用於合並從其他發送者到那些接收者的接收報告返回的時標。

       ② RTP時標：32位，與上述NTP時標同一時間有關，但與RTP時標有着相同的時間單位和同樣的隨機偏移。

       ③ 發送者包計數：32位，自開始發送來，直到SR包產生時刻，發送者發送RTP數據包總數。如改變SSRC標識符，此計數重置。

       ④ 發送者八位組計數：32位，發送者在RTP數據包中發送的載荷八位組總數。從發送開始，直到產生SR包，如發送者改變SSRC標識，重置此計數。這部分可用於估計載荷數據平均速率。

   3) 第三部分包含接收報告塊，大小不固定。每個接收報告塊傳送單個同步源接收RTP包的統計。發生沖突，當源改變SSRC標識時，接收者並不繼續統計。這些統計包括：

       ① SSRC_n(源標識)：32位，接收報告塊中信息所屬源的SSRC標識。

       ② 丟失部分：8位，前一個SR或RR包發送以來所丟失的源SSRC_n的RTP數據包中一部分，定義成所丟失包的數目。

       ③ 丟失包累積數：24位，自接收以來所丟失的源SSRC_n的RTP數據包總數，定義成小於實際所接收包的數量，該數量包括遲到或復制的包。因此，遲到的包不計為丟失，如有復制，此數量可能為負數。

       ④ 收到已擴展的最高系列號：32位，低16位包含從SSRC_n源RTP數據包中收到的最高系列號，最重要的16位以系列號循環相應計數擴展系列號。如開始時間明顯不同，同一連接內不同接收者將對系列號產生不同擴展。

       ⑤ 間隔抖動：32位，RTP數據包間隔時間的統計估計，以時標為單位，是一個無符號整數。

       ⑥ 最后SR時標(LSR)：32位，NIP時標的中間32位，如還沒有收到SR，此段設為零。

       ⑦ 自最后一個SR來的延遲(DLSR)：32位，延遲以1／65536秒為單位，表示源SSRC_n收到的最后一個SR包與發送此接收塊之間的時間，如還沒有收到SR，此段設為零。

   接收報告包格式與SR包類似（圖14-02-5），但包類型包含常數201，並刪除發送者信息的五個字。當沒有數據傳輸或接收報告時，則將一個空RR包(RC=O)放在組合RTCP包的前頭。

 

圖2 接收報告包

   如接收者或發送者有附加信息要有規律地報告，應對接收報告與接收者定義設置或應用擴展。如需要附加發送者信息，應首先包含在發送者報告的擴展中，但不出現在接收者報告內。如要包括接收者信息，數據結構應設塊數組，與接收報告塊數組類似，即塊數量由RC段表征。

   人們總是希望接收質量反饋不僅對發送者有用，而且對其他接收者和第三方監控都有用。發送者可根據反饋改變發送，接收者決定問題是出現在本地、區域還是全局。網絡管理員可僅使用接收RTCP包、而不是RTP數據包的設置無關監控器來估計網絡多播的性能。

   累計計數用在發送信息與接收者報告塊中，可考慮長期和短期測量與提供報告丟失恢復能力之間的差別。后兩個接收到報告之間的差別可用來估計近來發送的質量。將NTP時標包含在內，從兩個報告間隔的差別考慮速率。由於時標獨立於數據編碼時鍾速率，很可能實現編碼與設置無關的質量監控器。

丟失包累計數差別給出間隔期間丟掉的數量，而所收到擴展的最后一個系列號的差別則給出間隔期間希望發送的包數量，兩者之比等於間隔期間包丟失百分比。如兩報告連續，比值應該等於丟失段部分；否則，就不等。每秒包丟失率可通過NTP時標差除以丟失部分得到。

   根據發送者信息，第三方監控器可計算出載荷平均數據速率與沒收到數據間隔的平均包速率，兩者比值給出平均載荷大小。如假設包丟失與包大小無關，那么特殊接收者收到的包數量給出此接收者收到的表觀流量。

 

源描述RTCP包

   源描述RTCP包（SDES）為三層結構，由頭與數據塊組成，數據塊可以沒有，也可有多個，組成項描述塊所表明的源（圖3）。

 

圖3 SDES包

   1) 項描述如下：

      （1）版本(V)、填充(P)、長度：如SR包中所描述。

      （2）包類型(PT)：8位，包含常數202，標識RTCP SDES包。

      （3）源計數(X)：1位，包含在SDES包中的SSRC／CSRC塊數量，零值有效，但沒有意義。

   2) 源描述項

      源描述項內容如圖4所示。

 

 

圖4 源描述項

    ①CNAME

       規范終端標識SDES項。CNAME標識屬性如下：

• 如發生沖突或重啟程序，由於隨機分配的SSRC標識可能發生變化，需要CNAME項提供從SSRC標識到仍為常量的源標識的綁定。

• 像SSRC標識，CNAME標識在RTP連接的所有參加者中應是惟一的。

• 為了提供一套相關RTP連接中某個參加者所采用的跨多媒體工具間的綁定，CNAME應固定為那個參加者。

• 為方便第三方監控，CNAME應適合程序或人員定位源。

    ② NAME

       用戶名稱SDES項，這是用於描述源的真正的名稱，如"John Doe，BitRecycler，Megacorp"，可以是用戶想要的任意形式（圖14-02-8）。對諸如會議應用，這種名稱也許是參加者列表顯示所最適宜的形式，它將是除CNAME外發送最頻繁的項目。設置可建立這樣的優先級別。NAME值至少在連接期間仍希望保持為常數。它不該成為連接的所有參加者中惟一依賴。

 

圖5 NAME

    ③ E-mail

         電子郵件地址SDES項。郵件地址格式由RFC822規定，如“[e-mail]"。連接期間，電子郵件仍希望保持為常數。

 

 

圖6 EMAIL

    ④ PHONE

        電話號碼SDES項。電話號碼應帶有加號，代替國際接入代碼，如“[phone]"即為中國電話號碼。

 

 

圖7 PHONE

    ⑤LOC

        用戶地理位置SDES項。根據不同應用，此項具有不同的詳細程度。對會議應用，字符串如"MurrayHill，New Jersey"就足夠了。然而，對活動標記系統，字符串如“Room2A244，AT&T BLMH"也許就適用。細節留給實施或用戶，但格式和內容可用設置指示。在連接期間，除移動主機外，LOC值期望仍保留為常數。

 

 

圖8 LOC

    ⑥TOOL

      應用或工具名稱SDES項，是一個字符串，表示產生流的應用的名稱與版本，如“videotool1.2”。這部分信息對調試很有用，類似於郵件或郵件系統版本SMTP頭。TOOL值在連接期間仍保持常數。

 

 

圖9 TOOL

    ⑦ NOTE

       通知／狀態SDES項。推薦的該項語法如下所述，但這些或其他語法可在設置中顯式定義。NOTE項旨在描述源當前狀態的過渡信息，如"onthe phone，can'ttalk"，或在講座期間用於傳送談話的題目。它應該只用於攜帶例外信息，而不應包含在全部參加者中，因為這將降低接收報告和CNAME發送的速度，因此損害協議的性能。特殊情況下，它不應作為用戶設置文件的項目，也不是自動產生。

當其為活動時，由於NOTE項對顯示很重要，其他非CNAME項(如NAME)傳輸速率將會降低，結果使NOTE項占用RTCP部分帶寬。若過渡信息不活躍，NOTE項繼續以同樣的速度重復發送幾次，但以一個串長為零的字符串通知接收者。然而，如對小倍數的重復或約20~30倍RTCP間隔也沒有接收到，接收者也應該考慮NOTE項是不活躍的。

 

 

圖10 NOTE

    ⑧PRIV

      專用擴展SDES項。該項用於定義實驗或應用特定的SDES擴展，它包括由長字符串對組成的前綴，后跟填充該項其他部分和攜帶所需信息的字符串值。前組長度段為8位。前綴字符中是定義PRIV項人員選擇的名稱，惟一對應應用接收到的其他PRIV項。應用實現者可選擇使用應用名稱，如有必要，外加附加子類型標識。另外，推薦其他人根據其代表的實體選擇名稱，然后，在實體內部協調名稱的使用。

注意，前綴消耗了總長為255個八位組項的一些空間，因此，前綴應盡可能的短。這個設備和受到約束的RTCP帶寬不應過載，其目的不在於滿足所有應用的全部控制通訊要求。SDESPRIV前綴沒在IANA處注冊。如證實某些形式的PRIV項具有通用性，IANA應給它分配一個正式的SDES項類型，這樣就不再需要前綴。這簡化了應用，並提高了傳輸的效率。

 

斷開RTCP包（BYE）

   如混合器接收到一個BYE包，混合器轉發BYE包，而不改變SSRC／CSRC標識。如混合器關閉，它也應該發出一個BYE包，列出它所處理的所有源，而不只是自己的SSRC標識。作為可選項，BYE包可包括一個八位組計數，后跟表示離開原因的很多八位組文本，如：“cameramalfunction"或"RTP loopdetected"。字符串具有同樣的編碼，如在SDES中所描述的。如字符串填充包至下32位邊界，字符中就不以空結尾；否則，BYE包以空八位組填充。

 

 

圖11 BYE

定義應用的RTCP包（APP）

   APP包用於開發新應用和新特征的實驗，不要求注冊包類型值。帶有不可識別名稱的APP包應被忽略掉。測試后，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA注冊子類型和名稱段。

 

 

圖12 APP

   圖12給出了一個速率控制例。在理想情況下，使用RTP/RTCP可以使源速率與傳輸能力達到匹配（最小丟失）。

 

圖13 速率控制例

基於網絡和傳輸協議的RTP

   這部分講述特殊網絡和傳輸協議內與攜帶RTP包相關的內容。如果沒有規范外特定協議定義替代，下列規則可適用。

   RTP依賴低層協議提供RTP數據和RTCP控制流的多路分解。對UDP和類似協議，RTP使用一個偶數端口號，而相應RTCP流使用下一個(奇數，遞增)端口號。如應用使用一個奇數RTP端口，就應該用下一個小偶數端口代替。RTP數據包不包含長度段或其他描述，因此RTP依賴低層協議提供長度指示，RTP包最大長度僅受低層協議限制。如RTP包包含在提供連續八位組流的低層協議而不是信息(包)中，必須定義RTP包的封裝以提供幀機制。如低層協議包含填充，也需要幀機制，否則結果無法決定RIP負載程度。這里沒有定義幀機制。

   當RTP包含在提供幀的協議中時，為了允許在一個低層協議數據單元(UDP包)包括幾個RTP包，設置可指定所使用的幀方法。在網絡或傳輸包中攜帶幾個RTP包可減少頭部，並可能簡化不同流之間的同步。