[zz]即時傳輸協議 RTCP

即時傳輸協議 RTCP【轉】

RTP（Real-timeTransportProtocol）是用於Internet上針對多媒體資料流的一種傳輸協議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間資訊和實現流同步。RTP通常使用UDP來傳送資料，但RTP也可以在TCP或ATM等其他協議之上工作。當應用程式開始一個RTP會話時將使用兩個連接埠：一個給RTP，一個給RTCP。RTP本身並不能為按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。通常RTP演算法並不作為一個獨立的網路層來實現，而是作為應用程式代碼的一部分。即時傳輸控制通訊協定RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的資料包的數量、丟失的資料包的數量等統計資料，因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的即時資料。 　 6.2.2 RTP控制協議-- RTCP 　 RTCP協議將控制包周期發送給所有串連者，應用與資料包相同的分布機制。低層協議提供資料與控制包的複用，如使用單獨的UDP連接埠號碼。RTCP執行下列四大功能： 　 主要是提供資料發布的品質反饋。是作為RTP傳輸協議的一部分，與其他傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用，但IP組播經驗表明，從寄件者收到反饋對診斷髮送錯誤是致關重要的。給所有參與者發送接收反饋報告允許問題觀察者估計那些問題是局部的，還是全域的。諸如IP組播等發布機制使網路服務供應商類團體可能接收反饋資訊，充當第三方監控者來診斷網路問題。反饋功能由RTCP寄件者和接收者報告執行。 　 RTCP帶有稱作規範名字（CNAME）的RTP源持久傳輸層標識。如發現衝突，或程式重新啟動，既然SSRC標識可改變，接收者需要CNAME跟蹤參與者。接收者也需要CNAME 與相關RTP串連中給定的幾個資料流聯絡 　 前兩種功能要求所有參與者發送RTCP包，因此，為了RTP擴充到大規模數量，速率必須受到控制。讓每個參與者給其它參與者發送控制包，就大獨立觀察參與者數量。該數量用語計算包發送的速率。 　 第四個可選功能是傳送最小串連控制資訊，如參與者辨識。最可能用在"鬆散控制"串連，那裡參與者自由進入或離開，沒有成員控制或參數協調，RTCP充當通往所有參與者的方便通道，但不必支援應用的所有控制通訊要求。進階串連控制協議超出本書範圍。 　 在IP組播場合應用RTP時，前3個功能是必須的，推薦用於所有情形。RTP應用設計人員必須避免使用僅在單播模式下工作的機制，那將導致無法擴充規模。 　 　 6.2.2.1 RTCP 包格式 　 下面定義幾個攜帶不同控制資訊的RTCP包類型： 　 SR： 　 發送報告，當前活動寄件者發送、接收統計。 　 RR： 　 接收報告，非活動寄件者接收統計。 　 SDES： 　 源描述項，包括CNAME。 　 BYE： 　 表示結束。 　 APP： 　 應用特定函數。 　 類似於RTP資料包，每個RTCP包以固定部分開始，緊接著的是可變長結構元素，但以一個32位邊界結束。包含安排要求和固定部分中長度段，使RTCP包可堆疊。不需要插入任何分隔字元將多哥RTCP包串連起來形成一個RTCP組合包，以低層協議用單一包發送出去。由於需要低層協議提供提供整體長度來決定組合包的結尾，在組合包中沒有單個RTCP包顯式計數。 　 組合包中每個RTCP包可獨立處理，不需要根據包組合順序。但未了執行協議功能，強加如下約束： 　 接收統計（在SR或RR中）應該經常發送，只要頻寬允許，因此每個周期發送的組合RTCP 包應包含報告包。 　 新接收者需要接收CNAME，並儘快識別源，開始聯絡媒介進行同步，因此每個包應該包含SDES CNAME。 　 出現在組合包前面的是包類型數量，其增長應該受到限制，以提高常數位元量，提高成功確認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包類型可在Internet Assigned Numbers Authority (IANA)處註冊。 　 　 6.2.2.2 RTCP傳輸間隔 　 RTP設計成允許應用自動擴充，串連數可從幾個到上千個。例如，音訊會議中，資料流量是內在限制的，因為同一時刻只有一兩個人說話；對組播，給定串連資料率仍是常數，獨立於串連數，但控制流程量不是內在限制的。如每個參與者以固定速率發送接收報告，控制流程量將隨參與者數量線性增長，因此，速率必須按比例下降。 　 一旦確認地址有效，如後來標記成未活動，地址的狀態應仍保留，地址應繼續計入共用RTCP頻寬地址的總數中，時間要保證能掃描典型網路磁碟分割，建議為30分鐘。注意，這仍大於RTCP報告間隔最大值的五倍。 　 這個規範定義了除必需的CNAME外的幾個源描述項，如NAME（人名）和EMAIL（電子郵件地址）。它也為定義新特定應用RTCP包類型的途徑。給附加資訊分配控制頻寬應引起注意，因為它將降低接收報告和CNAME發送的速率而損害協議的效能。建議分配給單個參與者用於攜帶附加資訊的RTCP頻寬不要超過20%。而且並沒有有意讓所有SDES項包含在每個應用中。 　 6.2.2.3 寄件者與接收者報告 　 RTP接收者使用RTCP報告包提供接收品質反饋，報告包根據接收者是否是寄件者而採用兩種格式中的一種。除包類型代碼外，寄件者報告與接收者報告間唯一的差別是寄件者報告包含一個20個位元組寄件者資訊段。如某地址在發出最後或前一個報告間隔期間發送資料包，就發布SR；否則，就發出RR；SR和RR都可沒有或包括多個接收報告塊。發布報告不是為列在CSRC列表上的起作用的源，每個接收報告塊提供從特殊源接收資料的統計。既然最大可有31個接收報告塊嵌入在SR 或 RR包中， 　 丟失包累計數差別給出間隔期間丟掉的數量，而所收到擴充的最後一個系列號的差別給出間隔期間希望發送的包數量，兩者之比等於經過間隔期間包丟失百分比。如兩報告連續，比值應該等於丟失段部分；否則，就不等。每秒包丟失綠可通過NTP時標差除以丟失部分得到。 　 從寄件者資訊，第三方監控器可計算載荷平均資料速率與沒收到資料間隔的平均包速率，兩者比值給出平均載荷大小。如假設包丟失與包大小無關，那麼特殊接收者收到的包數量給出此接收者收到的表觀流量。 　 　 6.2.2.4 SDES: 源描述RTCP包 　 SDES 包為三層結構，由頭與資料區塊組成，資料區塊可以沒有，也可有多個，組成項描述塊所表明的源。項描述如下： 　 版本（V）、填充（P）、長度： 　 如SR包中所描述。 　 包類型（PT）： 　 8位，包含常數202，識別RTCP SDES包。 　 源計數（SC）： 　 5位，包含在SDES包中的SSRC/CSRC塊數量，零值有效，但沒有意義。 　 源描述項內容如下： 　 CNAME: 規範終端標識SDES項 　 CNAME識別屬性如下： 　 如發生衝突或重啟程式，由於隨機分配的SSRC標識可能發生變化，需要CNAME項提供從SSRC標識到仍為常量的源標識的綁定。 　 象SSRC標識，CNAME標識在RTP串連的所有參與者中應是唯一的。 　 為了提供一套相關RTP串連中某個參與者所採用的跨多媒體工具間的綁定，CNAME應固定為那個參與者。 　 為方便第三方監控，CNAME應適合程式或人員定位源。 　 NAME：使用者名稱稱SDES項 　 這是用於描述源的真正的名稱，如"John Doe, Bit Recycler, Megacorp"，可是使用者想要的任意形式。對諸如會議應用，這種名稱也許是參與者列表顯示最適宜的形式，它將是除CNAME外發送最頻繁的項目。設定可建立這樣的優先順序別。NAME值至少在串連期間仍希望保持為常數。它不該成為串連的所有參與者中唯一依賴。 　 EMAIL：電子郵件地址SDES項 　 郵件地址格式由RFC822規定，如"John.Doe@megacorp.com"。串連期間，電子郵件仍希望保持為常數。 　 PHONE：電話號碼SDES項 　 電話號碼應帶有加號，代替國際接入代碼，如"+1 908 555 1212"即為美國電話號碼。 　 　 LOC：使用者地理位置SDES項 　 根據應用，此項具有不同程度的細節。對會議應用，字串如"Murray Hill, New Jersey"就足夠了。然而，對主動標記系統，字串如"Room 2A244, AT&T BL MH"也許就適用。細節留給實施或使用者，但格式和內容可用設定指示。在串連期間，除移動主機外，LOC值期望仍保留為常數。 　 TOOL：應用或工具名稱SDES項 　 是一個字串，表示產生流的應用的名稱與版本，如"videotool 1.2"。這部分資訊對調試很有用，類似於郵件或郵件系統版本SMTP頭。TOOL值在串連期間仍保持常數。 　 NOTE: 通知/狀態SDES項 　 該項的推薦文法如下所述，但這些或其它文法可在設定中顯式定義。NOTE 項旨在描述源目前狀態的過渡資訊，如"on the phone, can't talk"，或在講座期間用於傳送談話的題目。它應該只用於攜帶例外資訊，而不應包含在全部參與者中，因為這將降低接收報告和CNAME發送的速度，因此損害協議的效能。特殊情況下，它不應作為使用者佈建檔案的項目，也不是自動產生。 　 當其為活動時，由於NOTE項對顯示很重要，其它非CNAME項（如NAME）傳輸速率將會降低，結果使NOTE項佔用RTCP部分頻寬。若過渡資訊不活躍，NOTE項繼續以同樣的速度重複發送幾次，但以一個串長為零的字串通知接收者。然而，如對小倍數的重複或約20-30 RTCP間隔也沒有接收到，接收者也應該考慮NOTE項是不活躍的。 　 PRIV: 專用擴充SDES項 　 該項用於定義實驗或應用特定的SDES擴充，它包括由長字串對組成的首碼，後跟填充該項其他部分和攜帶所需資訊的字串值。前置長度段為8位。前置詞字元串是定義PRIV項人員選擇的名稱，唯一對應應用接收到的其它PRIV項。應用實現者可選擇使用應用程式名稱，如有必要，外加附加子類型標識。另外，推薦其它人根據其代表的實體選擇名稱，然後，在實體內部協調名稱的使用。 　 注意，首碼消耗了總長為255個八進位項的一些空間，因此，首碼應儘可能的短。這個裝置和受到約束的RTCP頻寬不應過載，其目的不在於滿足所有應用的全部控制通訊要求。SDES PRIV首碼沒在IANA處註冊。如證實某些形式的PRIV項具有通用性， IANA應給它分配一個正式的SDES項類型，這樣就不再需要首碼。這簡化了應用，並提高了傳輸的效率。 　 6.2.2.5 BYE：斷開RTCP包 　 如混合器接收到一個BYE包，混合器轉寄BYE包，而不改變SSRC/CSRC 標識。如混合器關閉，它也應該發出一個BYE包，列出它所處理的所有源，而不只是自己的SSRC標識。作為可選項，BYE包可包括一個8位八進位計數，後跟很多八進位文本，表示離開原因，如："camera malfunction"或"RTP loop detected"。字串具有同樣的編碼，如在SDES 中所描述的。如字串填充包至下32位邊界，字串就不以空結尾；否則，BYE包以空八進位填充。 　 6.2.2.6 APP：定義應用的RTCP包 　 APP包用於開發新應用和新特徵的實驗，不要求註冊包類型值。帶有不可識別名稱的APP包應被忽略掉。測試後，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA註冊子類型和名稱段。