RFC3550

RFC3550

 

RTP：實時應用程序傳輸協議

 

摘要

本文描述RTP（real-time transport protocol），實時傳輸協議。RTP在多點傳送（多播）或單點傳送（單播）的網絡服務上，提供端對端的網絡傳輸功能，適合應用程序傳輸實時數據，如：音頻，視頻或者仿真數據。RTP沒有爲實時服務提供資源預留的功能，也不能保證QoS（服務質量）。數據傳輸功能由一個控制協議（RTCP）來擴展，經過擴展，能夠用一種方式對數據傳輸進行監測控制，該協議（RTCP）能夠升級到大型的多點傳送（多播）網絡，並提供最小限度的控制和鑑別功能。RTP和RTCP被設計成和下面的傳輸層和網絡層無關。協議支持RTP標準的轉換器和混合器的使用。

本文的大多數內容和舊版的RFC1889相同。在線路里傳輸的數據包格式沒有改變，惟一的改變是使用協議的規則和控制算法。爲了最小化傳輸，發送RTCP數據包時超過了設定的速率，而在這時，不少的參與者同時加入了一個會話，在這樣的狀況下，一個新加入到（用於計算的可升級的）計時器算法中的元素是最大的改變。

 

目錄（Table of Contents）

   1.   引言 （Introduction）

       1 1  術語（Terminology） 

   2   RTP使用場景（RTP Use Scenarios） 

       2 1  簡單多播音頻會議（ Simple Multicast Audio Conference） 

       2 2  音頻和視頻會議（Audio and Video Conference） 

       2 3   混頻器和轉換器（Mixers and Translators） 

       2 4  分層編碼（Layered Encodings） 

   3   定義（Definitions） 

   4   字節序，校訂和時間格式（Byte Order, Alignment, and Time Format） 

   5   RTP數據傳輸協議（RTP Data Transfer Protocol） 

       5 1  RTP固定頭域（RTP Fixed Header Fields） 

       5 2  多路複用RTP會話（Multiplexing RTP Sessions） 

       5 3  RTP頭的配置文件詳細變動（Profile-Specific Modifications to the RTP Header） 

            5 3 1  RTP報頭擴展（RTP Header Extension）  

   6   RTP控制協議（RTP Control Protocol） -- RTCP     

       6 1  RTCP包格式（RTCP Packet Format）         

       6 2  RTCP傳輸間隔（RTCP Transmission Interval） 

            6 2 1  維護會話成員數目（Maintaining the number of session members） 

       6 3  RTCP包的發送與接收規則（RTCP Packet Send and Receive Rules） 

            6 3 1  計算RTCP傳輸間隔（Computing the RTCP Transmission Interval） 

            6 3 2  初始化（Initialization） 

            6 3 3  接收RTP或RTCP（非BYE)包（Receiving an RTP or Non-BYE RTCP Packet） 

            6 3 4  接收RTCP（BYE）包（Receiving an RTCP BYE Packet） 

            6 3 5  SSRC計時失效（Timing Out an SSRC）

            6 3 6  關於傳輸計時器的到期（Expiration of Transmission Timer） 

            6 3 7  傳輸一個 BYE 包（Transmitting a BYE Packet）

            6 3 8  更新we_sent（Updating we_sent）

            6 3 9  分配源描述帶寬（Allocation of Source Description Bandwidth）

       6 4  發送方和接收方報告（Sender and Receiver Reports） 

            6 4 1  SR：發送方報告的RTCP包（SR: Sender report RTCP packet）  

            6 4 2  RR：接收方報告的RTCP包（RR: Receiver Report RTCP Packet） 

            6 4 3  擴展發送方和接收方報告（Extending the Sender and Receiver Reports ）  

            6 4 4  分析發送方和接收方報告（Analyzing Sender and Receiver Reports ）  

       6 5  SDES：源描述RTCP包（SDES: Source description RTCP packet） 

            6 5 1  CNAME：規範終端標識符的SDES數據項(CNAME: Canonical End-Point Identifier SDES Item）                        

            6 5 2  NAME：用戶名的SDES數據項（NAME: User name SDES item)  

            6 5 3  EMAIL:電子郵件地址的SDES數據項（EMAIL: Electronic Mail Address SDES Item） 

            6 5 4  PHONE：電話號碼的SDES數據項（PHONE: Phone Number SDES Item）

            6 5 5  LOC:地理用戶地址的SDES數據項（LOC: Geographic User Location SDES Item）

            6 5 6  TOOL：應用程序或工具名字的SDES數據項（TOOL: Application or Tool Name SDES Item） 

            6 5 7  NOTE：通知/狀態的SDES數據項（NOTE: Notice/Status SDES Item） 

            6 5 8  PRIV:私有擴展的SDES數據項（PRIV: Private Extensions SDES Item） 

       6 6  BYE：Goodbye　RTCP包（BYE: Goodbye RTCP packet） 

       6 7  APP:定義應用程序的RTCP包（APP: Application-Defined RTCP Packet）

   7   RTP轉換器和混頻器（RTP Translators and Mixers） 

       7 1  概述（General Description ） 

       7 2  在轉換器中的RTCP數據處理（RTCP Processing in Translators） 

       7 3  在混頻器中的RTCP數據處理（RTCP Processing in Mixers ） 

       7 4  級聯混頻器（Cascaded Mixers） 

   8   SSRC標識符的分配和使用（SSRC Identifier Allocation and Use） 

       8 1  衝突機率（Probability of Collision ） 

       8 2  衝突解決和循環檢測（Collision Resolution and Loop Detection）

       8 3  在分層編碼中使用（Use with Layered Encodings） 

   9   安全（Security ） 

       9 1  機密性（Confidentiality） 

       9 2  身份驗證和消息完整性（Authentication and Message Integrity） 

   10  擁塞控制（Congestion Control） 

   11  網絡和傳輸協議之上的RTP（RTP over Network and Transport Protocols） 

   12  協議常量摘要（Summary of Protocol Constants） 

       12 1 RTCP 包類型（RTCP Packet Types） 

       12 2 SDES 類型（SDES Types） 

   13  RTP概況和負載格式詳細說明

　　　　（RTP Profiles and Payload Format Specifications） 

   14  安全考慮（Security Considerations） 

   15  IANA考慮（IANA Considerations） 

   16  知識產權聲明（Intellectual Property Rights Statement） 

   17  鳴謝（Acknowledgments） 

   附錄 A    算法（Algorithms） 

   附錄 A 1  RTP數據頭有效性檢查（RTP Data Header Validity Checks ） 

   附錄 A 2  RTCP數據頭有效性檢查（RTCP Header Validity Checks） 

   附錄 A 3  肯定RTP包預期數目和丟失數目（Determining Number of Packets Expected and Lost） 

   附錄 A 4  生成SDES　RTCP包（Generating RTCP SDES Packets） 

   附錄 A 5  解析RTCP　SDES包（Parsing RTCP SDES Packets） 

   附錄 A 6  生成32位隨機標識符（Generating a Random 32-bit Identifier 

   附錄 A 7  計算RTCP傳輸間隔（Computing the RTCP Transmission Interval） 

   附錄 A 8  估測兩次到達間隔的抖動（Estimating the Interarrival Jitter） 

   附錄 B    與RFC1889不一樣以外（Changes from RFC 1889）        

   參考書目（References）  

   標準化引用（Normative References ）  

   資料性引用（Informative References） 

   做者地址            

   完整的版權聲明      

 

1.緒論

本文詳細的介紹實時傳輸協議RTP，RTP提供帶有實時特性的端對端數據傳輸服務，傳輸的數據如：交互式的音頻和視頻。那些服務包括有效載荷類型定義，序列號，時間戳和傳輸監測控制。應用程序在UDP上運行RTP來使用它的多路技術和checksum服務。2種協議都提供傳輸協議的部分功能。不過，RTP可能被其餘適當的下層網絡和傳輸協議使用（見11節）。若是下層網絡支持，RTP支持數據使用多播分發機制轉發到多個目的地。

注意RTP自己沒有提供任何的機制來確保實時的傳輸或其餘的服務質量保證，而是由低層的服務來完成。它不保證傳輸或防止亂序傳輸，它不假定下層網絡是否可靠，是否按順序傳送數據包。RTP包含的序列號容許接受方重構發送方的數據包順序，但序列號也用來肯定一個數據包的正確位置，例如，在視頻解碼的時候不用按順序的對數據包進行解碼。

可是RTP原先的設計是用來知足多參與者的多媒體會議的須要，它沒有限定於專門的應用。連續數據的儲存，交互分佈式仿真，動態標記，以及控制和測量應用程序也可能會適合使用RTP。

該文檔定義RTP，由2個密切聯繫的部分組成：

○實時傳輸協議RTP，用於實時傳輸數據。

○RTP控制協議RTCP，用於監控服務質量和傳達關於在一個正在進行的會議中的參與者的信息。後者對「寬鬆控制」的會議可能已經足夠，可是並無必要去支持一個應用程序全部的通信控制條件。這個功能可能充分的或者部分的被一個單獨的會議控制協議所包含，這超過了本文檔的範圍。

RTP表現了協議的一種新的類型，該類型由Clark和Tennenhouse提出[10]，遵循應用級（framing）框架和（integrated layer processing）統一層處理的原則。就是說，RTP被規定爲可擴展的，用來提供一個專門的應用程序須要的信息，並將會常常性的被歸併到應用程序的處理中，而不是做爲一個單獨的層被實現。RTP只是一個故意不完成的協議框架。本文檔詳細說明那些功能，但願這些功能可以廣泛貫穿於全部適合使用RTP的應用程序。和常規的協議不一樣，額外的功能可能經過完善協議自己或者增長一個可能須要分析的選項機制來增長，RTP被規定爲能夠根據須要經過修改和/或增長操做，「剪裁」到報頭。具體的例子見5.3和6.4.3節。

所以，除了本文檔，用於專門應用程序的RTP完整的說明將還須要一個或者更多的同類文檔（見13節）：

○ 一個框架（大體輪廓）的說明文檔，該文檔定義了一系列的有效載荷類型編碼和它們與有效載荷格式之間的映射（例如，媒體編碼）。一個框架可能也定義了應用程序對RTP的一些擴展和修改，詳細到一個專門的類。典型的狀況，一個應用程序將在一個框架下運行。一個用於音頻和視頻數據的框架能夠在同類RFC3551[1]文檔裏找到。

○有效載荷格式說明文檔，該文檔定義了一個像一個音頻或者視頻編碼的特殊載荷，在RTP裏是如何被傳輸的。

一個關於實時服務和算法如何實現的討論和關於一些RTP設計結果的後臺討論可以在[11]中找到。

1.1術語

在這個文檔裏的關鍵詞「必定要」，「必定不能」，「必需的」，「會」，「不會」，「應該」，「不該該」，「推薦」，「可能」和「可選」 將會像在BCP 14（Basic Control Program，基本控制程序），RFC2119[2]裏描述同樣的解釋。並指出適合RTP實現的須要的級別。

 

2.  RTP使用場景（RTP Use Scenarios）

      2.1  簡單多播音頻會議（ Simple Multicast Audio Conference）

      2.2  音頻和視頻會議（Audio and Video Conference）

      2.3  混頻器和轉換器（Mixers and Translators）

      2.4  分層編碼（Layered Encodings）

　　如下章節描述了用到RTP的一些方面。所舉例子用來講明RTP應用的基本操做，但RTP的用途不限於此。在這些例子中，RTP運行於IP和UDP之上，而且遵循RFC3551所描述的音頻和視頻的配置文件中的約定。

2.1 簡單多播音頻會議（Simple Multicast Audio Conference）

　　IETF的一個工做組開會討論最新協議草案時，使用Internet的IP多播服務來進行語音通信。工做組中心分配到一個多播的組地址和一對端口。一個端口用於音頻數據，另外一個端口用於控制（RTCP）數據包。該地址和端口信息發佈給預約的參與者。若是有私密性要求，則可用章節9.1中說明的方法，對數據和控制包進行加密，這時就須要生成和發佈加密密鑰。分配和發佈機制的精確細節不在RTP的討論範圍以內。

　　每一個與會者所使用的音頻會議應用程序，都以小塊形式（比方說持續２０秒時間）來發送音頻數據。每一個音頻數據塊都前導RTP報頭；RTP報頭和數據依次包含在UDP包裏。RTP報頭指明瞭各個包裏音頻編碼的類型（如PCM,ADPCM,LPC），這樣發送方能夠在會議過程當中改變編碼方式，以適應情況的變化，例如，要加進一個低帶寬接入的參與者，或是要應付網絡擁塞。

　　Internet，像其餘的報文分組網絡同樣，偶而會丟失和重排包，形成時長不等的延遲。爲彌補這個不足，RTP報頭裏包含計時信息和一個序列號，容許接收方重建來自源的計時信息，好比前文例子中音頻塊以20s的間隔在揚聲器中連續播放。會議中，對每一個RTP包的源,單獨地實施計時重建。序列號還被接收方用來評估丟失包數目。

　　因爲會議期間不斷有工做組成員加入或離開，所以有必要知道任一時刻的實際參與者及他們接收音頻數據的情況好壞。出於這個目的，會議中每一個音頻應用程序的實例，都在RTCP（控制）端口上週期性地多播一個附加用戶名的接收報告。接收報告指明瞭當前說話者被收聽到的情況，可用於控制自適應性編碼。除了用戶名外，經過控制帶寬限度，能夠包含其餘標識信息。一個站點在離開會議時發送RTCP BYE包（章節6.5）。

2.2　音頻和視頻會議（Audio and Video Conference）

　　一個會議若是同時使用音頻和視頻媒體，則兩者傳輸時使用不一樣的RTP會話。也就是說，兩種媒體中RTP包和RTCP包的傳輸，是使用兩個不一樣的UDP端口對和（或）多播地址。在RTP層次，音頻和視頻會話沒有直接的耦合，下面這種狀況除外：一個同時參加兩個會話的參與者，在兩個會話的RTCP包中，使用了相同的規範名，這樣兩個會話就發生關聯（耦合）了。

　　這樣區隔開來的目的之一，是容許一些會議參與者只接受本身選擇的單一媒體（或者音頻，或者視頻）。更進一步的說明在章節5.2給出。儘管兩種媒體區分開來了，但經過兩個會話RTCP包內載有的計時信息，同源的音頻與視頻仍是可以同步回放。

2.3　混頻器和轉換器（Mixers and Translators）

　　到目前爲止，咱們皆假設全部站點都收到相同格式的媒體數據。然而這並不老是行得通。考慮一下這種狀況，一個地方的參與者只能低速接入會議，而其餘大部分參與者都能享受高速鏈接。與其讓強迫你們都忍受低帶寬，不如在只能低速接入的地方，放置一個減質量音頻編碼的RTP層次的中繼（稱做混頻器）。混頻器將從新同步輸入的音頻包，重建發送方產生的20ms固定間隔，混頻已重建過的音頻流爲單一的流，轉換音頻編碼爲低帶寬格式，最後經過低帶寬鏈接轉發數據包流（package stream)。這些包可能被單播到一個接收方，也可能多播到另外一個的地址而發給多個接收方。RTP報頭爲混頻器提供了一種方法，使其能辨識出對混頻後的包有用的源，從而保證提供給接收方正確的說話者指示。

　　在音頻會議中，一些預約參與者儘管有高帶寬鏈接，但不能經過IP多播直接接入會議。例如，他們可能位於一個不容許任何IP包經過的應用層防火牆後面。對這些站點，可能就不須要混頻，而須要另外一種稱爲轉換器的RTP層次中繼。能夠在防火牆兩側分別安裝一個轉換器，外側轉換器將全部多播包經過安全鏈接轉入內側轉換器，內側轉換器再轉發給內部網的一個多播組（multicast group)。

　　混頻器和轉換器能夠設計成用於各類目的。好比，一個視頻混頻器在測量多個不一樣視頻流中各人的單獨影像後，將它們組合成一個單一視頻流來模擬羣組場景。又如，在只用IP/UDP和只用ST_II的兩個主機羣之間經過轉換創建鏈接。再如，在沒有從新同步或混頻時，用packet-by-packet編碼轉換來自各個獨立源的視頻流。混頻器和轉換器的操做細節見章節7。

2.4 分層編碼（Layered Encodings）

　　爲了匹配接收方的能力（容量）以及適應網絡擁塞，多媒體應用程序應當可以調整其傳輸速率。許多應用實現把調適傳輸速率的責任放在源端。這種作法在多播傳輸中並很差，由於不一樣接收方對帶寬存在着衝突性需求。這常常致使最小公分母的場景，網格中最小的管道支配了所有實況多媒體「廣播」的質量和保真度。

　　相反地，能夠把分層編碼和分層傳輸系統組合起來，從而把調適速率的責任放在接收端。在IP多播之上的RTP上下文中，對一個橫跨多個RTP會話（每一個會話在獨自多播組上開展）的分級表示信號(a hierarchically represented signal)，源可以把它的分層（layers)分割成條。 接收方僅需合併適當的多播組子集，就能適應異種網絡和控制接收帶寬。

RTP分層編碼的細節在章節6.3.9，8.3和11中給出。

 

3.　定義（definitions)

　　RTP負載（RTP payload）：經過RTP傳輸的包中的數據，例如，音頻樣本或壓縮好的視頻數據。負載格式與解釋不在本文討論範圍。

 　　RTP包（RTP packet）：一種數據包，其組成部分有：一個固定RTP報頭，一個可能爲空的做用源（contributing sources）列表（見下文），以及負載數據。一些下層協議可能要求對RTP包的封裝進行定義。通常地，下層協議的一個包包含一個RTP包，但若封裝方法容許，也可包含數個RTP包（見章節11）。

　　 RTCP包（RTCP packet）：一種控制包，其組成部分有：一個相似RTP包的固定報頭，後跟一個結構化的部分，該部分具體元素依不一樣RTCP包的類型而定。格式的定義見章節６。通常地，多個RTCP包將在一個下層協議的包中以合成RTCP包的形式傳輸；這依靠RTCP包的固定報頭中的長度字段來實現。

　　端口（Port）：「傳輸協議用來在同一主機中區分不一樣目的地的一種抽象。TCP/IP協議使用正整數來標識不一樣端口。」[12]　OSI傳輸層使用的傳輸選擇器（TSEL,the transport selectors）等同於這裏的端口。RTP需依靠低層協議提供的多種機制，如「端口」用以多路複用會話中的RTP和RTCP包。

　　傳輸地址(Transport address)：是網絡地址與端口的結合，用來標識一個傳輸層次的終端，例如一個IP地址與一個UDP端口。包是從源傳輸地址發送到目的傳輸地址。

　　RTP媒體類型（RTP media type）：一個RTP媒體類型是一個單獨RTP會話所載有的負載類型的集合。RTP配置文件把RTP媒體類型指派給RTP負載類型。

　　多媒體會話（Multimedia session）：在一個參與者公共組中，併發的RTP會話的集合。例如，一個視頻會議（爲多媒體會話）可能包含一個音頻RTP會話和一個視頻RTP會話。

　　RTP會話（RTP session）：一羣參與者經過RTP進行通訊時所產生的關聯。一個參與者可能同時參與多個RTP會話。在一個多媒體會話中，除非編碼方式把多種媒體多路複用到一個單一數據流中，不然每種媒體都將使用各自的RTCP包，經過單獨的RTP會話來傳送。經過使用不一樣的目的傳輸地址對（一個網絡地址加上一對分別用於RTP和RTCP的端口，構成了一個傳輸地址對）來接收不一樣的會話，參與者能把多個RTP會話區隔開來。單個RTP會話中的全部參與者，可能共享一個公用目的傳輸地址對，好比IP多播的狀況；也可能各自使用不一樣的目的傳輸地址對，好比個體單播網絡地址加上一個端口對。對於單播的狀況，參與者可能使用相同端口對來收聽其餘全部參與者，也可能對來其餘每一個參與者使用不一樣的端口對來收聽。

　　RTP會話間相互區別的特徵，在於每一個RTP會話都維護一個用於SSRC標識符的獨立完整的空間。RTP會話所包含的參與者組，由能接收SSRC標識符的參與者組成，這些SSRC標識符由RTP（同步源或做用源）或RTCP中的任意參與者傳遞。例如，考慮下述狀況，用單播UDP實現的三方會議，每方都用不一樣的端口對來收聽其餘兩方。若是收到一方的數據，就只把RTCP反饋發送給那一方，則會議就至關於由三個單獨的點到點RTP會話構成；若是收到一方的數據，卻把RTCP反饋發送另兩方，則會議就是由一個多方（multi-party)RTP會話構成。後者模擬了三方間進行IP多播通訊時的行爲。

　　RTP框架容許上述規定發生變化，但一個特定的控制協議或者應用程序在設計時經常對變化做出約束。

　　同步源(SSRC，Synchronization source)：RTP包流的源，用RTP報頭中32位數值的SSRC標識符進行標識，使其不依賴於網絡地址。一個同步源的全部包構成了相同計時和序列號空間的一部分，這樣接收方就能夠把一個同步源的包放在一塊兒，來進行重放。舉些同步源的例子，像來自同一信號源的包流的發送方，如麥克風、攝影機、RTP混頻器（見下文）就是同步源。一個同步源可能隨着時間變化而改變其數據格式，如音頻編碼。SSRC標識符是一個隨機選取的值，它在特定的RTP會話中是全局惟一（globally unique）的（見章節8）。參與者並不須要在一個多媒體會議的全部RTP會話中，使用相同的SSRC標識符；SSRC標識符的綁定經過RTCP（見章節6.5.1）。若是參與者在一個RTP會話中生成了多個流，例如來自多個攝影機，則每一個攝影機都必須標識成單獨的同步源。

做用源（CSRC，Contributing source )：若一個RTP包流的源，對由RTP混頻器生成的組合流起了做用，則它就是一個做用源。對特定包的生成起做用的源，其SSRC標識符組成的列表，被混頻器插入到包的RTP報頭中。這個列表叫作CSRC表。相關應用的例子如，在音頻會議中，混頻器向全部的說話人（talker)指出，誰的話語（speech)將被組合到即將發出的包中，即使全部的包都包含在同一個（混頻器的）SSRC標識符中，也可以讓聽者（接收者）能夠清楚誰是當前說話人。 　
　　終端系統（End system)：一種應用程序，它產生髮送出的RTP包中內容，或者使用接收到的RTP包中內容。在一個特定的RTP會話中，一個終端系統能夠扮演一個或多個同步源角色，但一般是一個。

混頻器（Mixer)：一種中間系統，它從一個或多個源中接收RTP包，可能改變其數據格式，再按某種方式把這些包組合成一個新的包，而後轉發出去。因爲多個輸入源的計時通常不會同步，因此混頻器會對各個流的計時做出調整，併爲組合流生成一個新的計時。所以，混頻器將被標識成它所產生全部數據包的同步源。

轉換器（Translator)：一種中間系統，它轉發RTP包而不改變各包的同步源標識符。轉換器的例子以下：不做混頻地轉變編碼的設備，把多播複製到單播的重複裝置，以及防火牆裏應用層次的過濾器。

監視器(Monitor)：一種應用程序，它接收RTP會話參與者所發送的RTCP包，特別是接收報告（reception report)，並且對當前服務質量進行評估，評估結果用於分配監視任務，故障診斷和長期統計。監視器經常被內建到參與會話的應用程序中，但也能夠是一個的獨立的應用程序——不參加會話、也不發送或接收RTP數據包（由於它們在不一樣的端口上）。這些被稱做第三方監視器。還有一種狀況也是能夠接受的，第三方監視器只接收但不發送數據包，或者另外地算入到會話中。

　　非RTP途徑（Non-RTP means)：爲提供一個可用的服務，可能還須要其餘的協議和機制。特別地，對多媒體會議來講，一個控制協議能夠發佈多播地址，發佈加密密鑰，協商所用的加密算法，以及爲沒有預約義負載類型值的格式，創建負載類型值和其所表明的負載格式之間的動態映射。其餘協議的例子以下：會話初始化協議（SIRFC3261[13]），ITU推薦的H.323[14]，還有使用SDP(RFC2327[15])的應用程序，如RTSP(RFC 2326[16]).  對於簡單的應用程序，電子郵件或者會議數據庫也可能用到。對這些協議和機制的詳細說明已經超出了本文檔的討論範圍。

 

5　RTP數據傳輸協議

5.1 RTP固定頭中的各字段

RTP頭有如下格式:   

 

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X| CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

       RTP包頭格式     

 　前12個字節出如今每一個RTP包中，僅僅在被混合器插入時，纔出現CSRC識別符列表。這些域有如下意義：     

 　版本(V)：2比特 此域定義了RTP的版本。此協議定義的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"語音工具使用的協議中。)     

 　填充(P)：1比特 若填料比特被設置，則此包包含一到多個附加在末端的填充比特，填充比特不算做負載的一部分。填充的最後一個字節指明能夠忽略多少個填充比特。填充可能用於某些具備固定長度的加密算法，或者用於在底層數據單元中傳輸多個RTP包。     

 　擴展(X)：1比特 若設置擴展比特，固定頭(僅)後面跟隨一個頭擴展。     

 　CSRC計數(CC)：4比特   CSRC計數包含了跟在固定頭後面CSRC識別符的數目。     

 　標誌(M)：1比特 標誌的解釋由具體協議規定。它用來容許在比特流中標記重要的事件，如幀邊界。

 　負載類型(PT)：7比特 此域定義了負載的格式，由具體應用決定其解釋。協議能夠規定負載類型碼和負載格式之間一個默認的匹配。其餘的負載類型碼能夠經過非RTP方法動態定義。RTP發送端在任意給定時間發出一個單獨的RTP負載類型；此域不用來複用不一樣的媒體流。     

 　序列號（sequence number）：16比特 每發送一個RTP數據包，序列號加1，接收端能夠據此檢測丟包和重建包序列。序列號的初始值是隨機的(不可預測)，以使即使在源自己不加密時(有時包要經過翻譯器，它會這樣作)，對加密算法泛知的普通文本攻擊也會更加困難。     

 時間戳（timestamp） 32比特時間戳反映了RTP數據包中第一個字節的採樣時間。時鐘頻率依賴於負載數據格式，並在描述文件（profile）中進行描述。也能夠經過RTP方法對負載格式動態描述。

若是RTP包是週期性產生的，那麼將使用由採樣時鐘決定的名義上的採樣時刻，而不是讀取系統時間。例如，對一個固定速率的音頻，採樣時鐘將在每一個週期內增長1。若是一個音頻從輸入設備中讀取含有160個採樣週期的塊，那麼對每一個塊，時間戳的值增長160。

時間戳的初始值應當是隨機的，就像序號同樣。幾個連續的RTP包若是是同時產生的。如：屬於同一個視頻幀的RTP包，將有相同的序列號。

不一樣媒體流的RTP時間戳可能以不一樣的速率增加。並且會有獨立的隨機偏移量。所以，雖然這些時間戳足以重構一個單獨的流的時間，但直接比較不一樣的媒體流的時間戳不能進行同步。對於每個媒體，咱們把與採樣時刻相關聯的RTP時間戳與來自於參考時鐘上的時間戳（NTP）相關聯。所以參考時鐘的時間戳就了數據的採樣時間。（即：RTP時間戳可用來實現不一樣媒體流的同步，NTP時間戳解決了RTP時間戳有隨機偏移量的問題。）參考時鐘用於同步全部媒體的共同時間。這一時間戳對（RTP時間戳和NTP時間戳），用於判斷RTP時間戳和NTP時間戳的對應關係，以進行媒體流的同步。它們不是在每個數據包中都被髮送，而在發送速率更低的RTCP的SR（發送者報告）中。

若是傳輸的數據是存貯好的，而不是實時採樣等到的，那麼會使用從參考時鐘獲得的虛的表示時間線（virtual presentation timeline）。以肯定存貯數據中的每一個媒體下一幀或下一個單元應該呈現的時間。此種狀況下RTP時間戳反映了每個單元應當回放的時間。真正的回放將由接收者決定。

SSRC：32比特 用以識別同步源。標識符被隨機生成，以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符。儘管多個源選擇同一個SSRC識別符的機率很低，全部RTP實現工具都必須準備檢測和解決衝突。若一個源改變自己的源傳輸地址，必須選擇新的SSRC識別符，以免被看成一個環路源。

    CSRC列表：0到15項，每項32比特   CSRC列表識別在此包中負載的全部貢獻源。識別符的數目在CC域中給定。如有貢獻源多於15個，僅識別15個。CSRC識別符由混合器插入，並列出全部貢獻源的SSRC識別符。例如語音包，混合產生新包的全部源的SSRC標識符都被列出，以在接收端處正確指示參與者。     

 5.3.1 RTP頭擴展     

   RTP提供擴展機制以容許實現個性化：某些新的與負載格式獨立的功能要求的附加信息在RTP數據包頭中傳輸。設計此方法能夠使其它沒有擴展的交互忽略此頭擴展。RTP頭擴展的格式以下圖所示。     

0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |      defined by profile       |           length              |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                        header extension                       |

   |                             ....                              |

 

 若RTP頭中的擴展比特位置1，則一個長度可變的頭擴展部分被加到RTP固定頭以後。頭擴展包含16比特的長度域，指示擴展項中32比特字的個數，不包括4個字節擴展頭(所以零是有效值)。RTP固定頭以後只容許有一個頭擴展。爲容許多個互操做實現獨立生成不一樣的頭擴展，或某種特定實現有多種不一樣的頭擴展，擴展項的前16比特用以識別標識符或參數。這16比特的格式由具體實現的上層協議定義。基本的RTP說明並不定義任何頭擴展自己。     

 

 6 RTP控制協議RTCP     

   RTP控制協議(RTCP)向會議中全部成員週期性發送控制包。它使用與數據包相同的傳輸機制。底層協議必須提供數據包和控制包的複用，例如用不一樣的UDP端口。RTCP提供如下四個功能：     

○基本功能是提供數據傳輸質量的反饋。這是RTP做爲一種傳輸協議的主要做用，它與其餘協議的流量和擁塞控制相關。反饋可能對自適應編碼有直接做用，而且IP組播的實驗代表它對於從接收端獲得反饋信息以診斷傳輸故障也有決定性做用。向全部成員發送接收反饋能夠使"觀察員"評估這些問題是局部的仍是全局的。利用相似多點廣播的傳輸機制，能夠使某些實體，諸如沒有加入會議的網絡業務觀察員，接收到反饋信息並做爲第三方監視員來診斷網絡故障。反饋功能經過RTCP發送者和接收者報告實現。     

   ○RTCP爲每一個RTP源傳輸一個固定的識別符，稱爲規範名（CNAME）。因爲當發生衝突或程序重啓時SSRC可能改變，接收者要用CNAME來跟蹤每一個成員。接收者還要用CNAME來關聯一系列相關RTP會話中來自同一個成員的多個數據流，例如同步語音和圖像。

   ○前兩個功能要求全部成員都發送RTCP包，所以必須控制速率以使RTP成員數能夠逐級增加。經過讓每一個成員向全部成員發送控制包，各個成員均可以獨立地觀察會議中全部成員的數目。此數目能夠用來估計發包速率。

   ○第四個可選的功能是傳輸最少的會議控制信息，例如在用戶接口中顯示參與的成員。這最可能在"鬆散控制"的會議中起做用，在"鬆散控制"會議裏，成員能夠不通過資格控制和參數協商而加入或退出會議。RTCP做爲一個延伸到全部成員的方便通路，必需要支持具體應用所需的全部控制信息通訊。

   ○在RTP用於IP多點廣播時，功能1-3是強制的，在全部狀況下都推薦使用。建議RTP應用開發商避免使用只能用於單向廣播而不能擴充到多用戶的方法。

6.1 RTCP包格式     

這部分定義了幾個RTCP包類型，能夠傳送不一樣的控制信息：

   ○SR：發送者報告，描述做爲活躍發送者成員的發送和接收統計數字； 

○RR：接收者報告，描述非活躍發送者成員的接收統計數字；

○SDES：源描述項，其中包括規範名CNAME。

○BYE：代表參與者將結束會話。

○APP：應用描述功能。

   在本文中將詳細介紹SR和RR。     

   每一個RTCP包的開始部分是與RTP數據包相相似的固定部分，隨後是一塊結構化單元，它隨負載類型不一樣長度發生變化，可是總以32比特終止。對齊要求和長度域使RTCP包可"堆棧"，便可以將多個RTCP包造成一個複合RTCP包，在底層協議(如UDP)中，一般都是將複合包做爲一個包傳輸的。     

複合包中的每一個RTCP單包能夠單獨處理，而無需考慮包複合的順序。然而，爲了實現某些協議功能，添加如下限制：

○接收數據的統計信息(在SR或RR中)。只要帶寬容許應儘量常常的發送，以達到統計數字的最大分辨率。所以每一個週期發送的RTCP包必須包含一個報告包。

○新的參與者須要儘快接收一個源的規範名以識別數據源並與媒體創建會話。所以，每一個包中必須包含源描述項中的規範名。除非複合包進行了分割以進行部分加密（見9.1節的描述）。

   ○必須限制首次在複合包中出現的包類型的數目，以增長在第一個字中常數比特的數目，這樣能夠增長RTCP包的有效性，以區分誤傳的RTP包和其餘無關的包。所以，全部RTCP包必須以複合包的形式發送。複合包中至少有兩個單個的RTCP包。具備如下格式： 

   　　○加密前綴：當且僅當複合包被加密時，對每一個RTCP複合包加32比特的前綴。     

       ○SR或RR：複合包中的第一個RTCP包必須是一個報告包。即便沒有數據發送和接收，此時發送空的RR包，或者複合包中其餘的惟一包是BYE包，也必須發送報告包。 

 　　 ○附加的RR：若被報告的接收統計源數目超過SR/RR包中最大容許的31個，附加的RR必須跟在最初的報告包後面。

　　   ○源描述SDES

       ○BYE或APP包

    每一個RTP參與者在一個報告間隔內應只發送一個RTCP複合包，以便正確估計每一個參與者的RTCP帶寬。除非像9.1節描述的狀況——把一個RTCP複合包分割以進行加密。若是數據源的個數太多，以致於不能把全部的RR包都放到同一個RTCP包中而不超過網絡路徑的最大傳輸單元（maximum transport unit　MTU），那麼可在每一個間隔中發送其中的一部分包。在多個發送間隔中，全部的包應該被等機率的選中。這樣就能夠報告全部數據源的接收數據的狀況。若是一個RTCP複合包的長度超過了網絡路徑的MTU，則它應當被分割爲多個更短的RTCP包來傳輸。這不會影響對RTCP帶寬的估計，由於每個複合包至少表明了一個參與者。要注意的是每一個RTCP複合包必須以SR或RR包開頭。

|

   |[--------- packet --------][---------- packet ----------][-packet-]

   |

   |                receiver            chunk        chunk

   V                reports           item item   item item

   --------------------------------------------------------------------

   R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]

   --------------------------------------------------------------------

   |                           |

   |<----------------------- compound packet ----------------------->|

   |<-------------------------- UDP packet ------------------------->|

 

   #: SSRC/CSRC identifier

 

             圖1: RTCP複合包舉例

 

6.2 RTCP傳輸時間間隔

RTP被設計爲容許應用自動適應不一樣的規模的會話――從幾個參與者到幾千個參與者的會話。

對每個會話，咱們假定數據傳輸受到一個上限――會話帶寬的限制。會話帶寬分配給全部的參與者。這個帶寬會被預留，並由網絡所限制。若是沒有預留，基於環境的其餘約束將會肯定合理的最大帶寬供會話使用，這就是會話帶寬。會話帶寬在必定程度上獨立於媒體編碼，但媒體編碼卻依賴於會話帶寬。

在涉及媒體應用時，會話帶寬參數最好由一個會話控制應用提供。但媒體應用可能設置一個默認參數。此參數由單個發送者選擇的編碼方式的數據帶寬算出。會話管理可能會基於多播範圍的規則或其餘標準肯定帶寬限制。全部的參與者應使用相同的會話帶寬值以保證計算出相同的RTCP間隔。

控制傳輸帶寬應當是會話帶寬的一小部分，這部分所佔總的會話帶寬的百分比應是已知的。一小部分：傳輸協議的首要功能是傳輸數據；已知：控制傳輸帶寬能夠被放進帶寬描述中提供給資源預留協議，而且使每一個參與者均可以獨立的計算出他所佔有的帶寬份額。

控制傳輸帶寬做爲額外的一部分加入到會話帶寬中。建議RTCP控制傳輸帶寬爲RTCP會話帶寬的5%。其中的1/4分配給發送者；當發送者的比例超過全部參與者的1/4時，其RTCP控制帶寬相應增長。全部的會話參與者必須使用相同的常數（以上提到的百分比），以便計算出相同的發送時間間隔。這些常數應在一個特殊的描述文件中肯定。

計算出的RTCP複合包的發送時間間隔應該有一個下限，以避免參與者數量較少時大量發送RTCP包。這也使網絡暫時斷開時，發送間隔不會過小。在應用開始時，一個延遲應加到第一個的TCP複合包發送以前，以便從其餘參與者接收RTCP複合包。這樣，發送時間間隔能更快的收斂到正確的值。這個延遲能夠設爲最小時間間隔的一半。固定的時間間隔建議爲5秒。

一個實現可能使RTCP最小發送時間間隔與會話帶寬參數成比例。則應知足下列約束：

○對多播會話，只有活動的數據發送者使用減少的最小化的值計算RTCP複合包的發送時間間隔。

○對單播會話，減少的值也可能被不是活動的數據發送者使用，發送初始的RTCP複合包以前的延遲多是0。

○對全部會話，在計算參與者的離開時間時，這個固定最小值會被用到。所以，不使用減少的值進行RTCP包的發送，就不會被其餘參與者提早宣佈超時。

○減少的最小時間間隔建議爲：360/sb(秒)，其中sb：會話帶寬（千字節/秒）。當sb>72kb/s時，最小時間間隔將小於5s。

6.3節所描述的算法和附錄A.7將實現本節列出的目標：

○計算出的RTCP包的時間間隔與組中參與者的人數成正比。（參與者越多，發送時間間隔越長，每一個參與者佔有的RTCP帶寬越小）。

○RTCP包的（真實）時間間隔是計算出的時間間隔的0.5～1.5倍之間某個隨機的值，以免全部的參與者意外的同步。

○RTCP複合包的平均大小將會被動態估計，包括全部發送的包和接收的包。以自動適應攜帶的控制信息數量的變化。

○因爲計算出的時間間隔依賴於組中的人數。所以，當一個的用戶加入一個已經存在的會話或者大量的用戶幾乎同時加入一個新的會話時，就會有意外的初始化效應。這些新用戶將在開始時錯誤的估計組中的人數（估計過小）。所以他們的RTCP包的發送時間間隔就會過短。若是許多用戶同時加入一個會話，這個問題就很重要了。爲了處理這處問題考慮了一種叫「時間重估」的算法。這個算法使得組中人數增長時，用戶可以支持RTCP包的傳輸。

當有用戶離開會話，無論是發送BYE包仍是超時，組中的人數會減小。計算出的時間間隔也應當減小。所以，應用「逆向重估」算法，使組中的成員更快的減小他們的時間間隔，以對組中的人數減小作出響應。

○BYE包的處理和其餘RTCP包的處理不一樣。BYE包的發送用到一個「放棄支持」算法。以免大量的BYE包同時發送，使大量參與者同時離開會話。

這個算法適用於全部參與者都容許RTCP包的狀況。此時，會話帶寬＝每一個發送者的帶寬×會話中參與者的總人數。詳細算法見隨後小節，附錄A.7給出了算法的一個實現。

6.2.1維持會話成員的人數

當偵聽到新的站點的時候，應當把他們加入計數。每個登陸都應在表中建立一條記錄，並以SSRC或CSRC進行索引。新的登陸直到接收到含有SSRC的包或含有與此SSRC相聯繫的規範名的SDES包才視爲有效（見附錄A.1）。當一個與SSRC標識符相對RTCP　BYE包收到時，登陸會被從表中刪除。除非一個「掉隊」的數據包到達，使登陸從新建立。

若是在幾個RTCP報告時間間隔內沒有RTP或RTCP包收到，一個參與者可能標記另一個站點靜止，並刪除它。這是針對丟包提供的一個很強健的機制。全部站點對這個超時時間間隔乘子應大致相同，以使這種超時機制正常工做。所以這個乘子應在特別的描述文件中肯定。

對於一個有大量參與者的會話，維持並存貯一個有全部參與者的SSRC及各項信息的表幾乎是不可能的所以，只能夠只存貯SSRC。其餘算法相似。關鍵的問題就是，任何算法都不該當低估組的規模，雖然它有可能被高估。

6.3　RTCP包的發送和接收規則

下面列出瞭如何發送RTCP包，當接收到的TCP包時該幹什麼的規則。

爲執行規則，一個會話參與者就維持下列變量：

tp:　RTCP包發送的最後時間。

tc: 當前時間。

tn: 估計的下一個RTCP包要發送的時間。

pmembers: tn最後被從新計算時，會計的會話成員的人數。

members: 會話成員人數的當前估計。

senders: 會話成員中發送者人數的估計。

rtcp_bw: 目標RTCP帶寬。例如用於會話中全部成員的RTCP帶寬。單位bit/s。這將是程序開始時，指定給「會話帶寬」參數的一部分。

we_sent: 自當前第二個前面的RTCP發送後，應用程序又發送了數據，則此項爲true。

avg_rtcp_size: 此參與者收到的和發送的RTCP複合包的平均大小。單位：bit。按6.2節，此大小包括底層傳輸層和網絡層協議頭。

initial: 若是應用程序還未發送RTCP包，則標記爲true。

許多規則都用到了RTCP包傳輸的「計算時間間隔」。此時間間隔將在隨後的小節描述。

6.3.1計算RTCP傳輸時間間隔

    一個會話參與者包的平均發送時間間隔應當和所在會話組中人數成正比。這個間隔稱爲計算時間間隔。它由上面提到的各個狀態參量結合起來計算得出。計算時間間隔T的計算以下：

    1．（1）若是發送者人數≤會話總人數×25%。則T取決於此參與者是不是發送者（we_sent的值）；不然，發送者和接收者將統一處理。

senders<=25%*members

 

we_sent

 

c=avg_rtcp_size/(0.25*rtcp_bw); n=senders;

 

c=avg_rtcp_size/(0.75*rtcp_bw); n=members-senders;

 

c=avg_rtcp_size/rtcp_bw; n=members;

 

not

 

yes

 

yes

 

not

 

圖：肯定c ，n

如6.2節所述，RTP描述文件可能用兩個獨立的參數（S，R）肯定發送者與非發送者。此時，25%和75%只要相應的換成S/(S+R),R/(S+R)便可。注意R＝0的狀況。

2．若是initial爲true(則未發送過RTCP包)，則設Tmin=2.5s;不然設Tmin=5s。

3．決定性的計算時間間隔（deterministic calculated interval）Td=max(Tmin ,n*c)。

4. T=Td*λ；其中λ~U(0.5,1.5)。即λ服從0.5到1.5之間的均勻分佈。

5. T=T/(e-0.5)≈T/1.21828，補償時間重估算法，使之收斂到比計算出的平均RTCP帶寬小的一個值。

這個算法產生了一個隨機的計算時間間隔，並把至少25%的RTCP帶寬分配給發送者，其他的分給接收者。若發送者超過會話總人數的25%，此算法將把帶寬平均分給全部的參與者。

6.3.2初始化

    一加入會話，參與者的各狀態參量初始化爲：tp=0； tc=0； senders=0； pmembers=1； members=1； vw_sent=false； rtcp_bw:由會話帶寬參數的相應部分獲得；initial=true；avg_rtcp_size:初始化爲應用程序稍後將發送的RTCP包的可能大小；T：如6.3.1節；tn=T（這意味着，一個計時器將經T時間後被喚醒）；應用程序能夠用任何它須要的方式實現計時器。

參與者把它本身的SSRC加到成員列表中。

6.3.3接收到的TP包或一個非BYE的RTCP包

當收到一個參與者的RTP或RTCP包時，若其SSRC不在成員列表中，將其SSRC加入列表；若此參與者被確認有效（如6.2.1節描述），就把列表中成員的值更新。對每一個有效的RTP包中的CSRC執行相同的過程。

當收到一個參與者的RTP包時，若其SSRC不在發送者列表中，則將其SSRC加入發送者列表，更新相應的值。

每收到一個RTCP複合包，avg_rtcp_size更新爲avg_rtcp_size　=　1/16　*　packet_size　+　15/16　*　avg_rtcp_size　；其中packet_size是剛收到的RTCP複合包的大小。

6.3.4接收RTCP　BYE包

   除6.3.7小節描述的發送RTCP BYE包以外，若是收到一個RTCP　BYE包，則檢測成員列表。若SSRC存在；先移除之，並更新成員的值。

另外，爲使RTCP包的發送速率與組中人數變化更加協調，當收到一個BYE包使得members的值pmembers時，下面的逆向重估算法應當執行：

（1）tn的更新：tn = tc + ( members / pmembers ) * ( tn –tc )；

（2）tp的更新：tp = tc – ( members / pmembers ) * ( tc – tp )；下一個RTCP包將在時刻tn 被髮送，比更新前更早一些。 

（3）pmembers的更新：pmembers=members；

這個算法並無防止組的大小被錯誤的在短期內估計爲0的狀況。如：在一個較多人數的會話中，多數參與者幾乎同時離開而少數幾個參與者沒有離開的狀況。這個算法並無使估計迅速返回正確的值。由於這種狀況較罕見，且影響不大。

6.3.5 SSRC超時

在隨機的時間間隔中，一個參與者必須檢測其餘參與者是否已經超時。爲此，對接收者（we_sent爲false），要計算決定性時間間隔Td，若是從時刻Tc-M*Td(M爲超時因子，默認爲5秒)開始，未發送過RTP或RTCP包，則超時。其SSRC將被從列表中移除，成員被更新。在發送者列表中也要進行相似的檢測。發送者列表中，任何從時間tc-2T(在最後兩個RTCP報告時間間隔內)未發送RTP包的發送者，其SSRC從發送者列表中移除，列表更新。

若是有成員超時，應該執行6.3.4節中的逆向檢測算法。每一個參與者在一個RTCP包發送時間間隔內至少要進行一次這樣的檢測。

6.3.6發送時鐘到時了

當包傳輸的發送時鐘到時，參與者執行下列操做：

（1）按6.3.1節的辦法計算T。

（2）更新發送時鐘的定時時間，判斷是否發送RTCP包，更新pmembers。如圖：

tp+T<=tc

 

發送RTCP包

 

tp=tc; tn=tc+T; initial=false;

 

avg_rtcp_size=1/16　*　packet_size　+　15/16　*　avg_rtcp_size

 

tn=tp+T

 

Pmemvers=members

 

yes

 

no

 

//不發送RTCP包

 

圖：發送時鐘到時的操做

6.3.7發送一個BTE包

    當一個參與者離開會話時，應發送BYE包，通知其餘參與者。爲避免大量參與者同時離開系統時，大量BYE包的發送，若會話人數超過50，則參與者在要離開會話時，應執行下面的算法。這個算法實際上「篡奪」了通常可變成員的角色來統計BYE包。

　　（1）tp=tc ； members=1； pmembers=1； sinitial=1； we_sent=false； senders=0； rtcp_size:設置爲將要發送的RTCP包大小；計算「計算時間間隔」T；tn=tc+T；(BYE包預計在時刻tn被髮送)。

    (2)每當從另一個參與者接收到BYE包時，成員人數加1。無論此成員是否存在於成員列表中，也無論SSRC採樣什麼時候使用及BYE包的SSRC是否包含在採樣之中。若是收到RTP包或甚的RTCP包（除BYE包以外的RTCP包），成員人數不增長。相似，只有在收到BYE包時，avg_rtcp_size才更新。當RTP包到達時，發送者人數senders不更新，保持爲0。

    （3）在此基礎上，BYE包的傳輸服從上面規定的通常的RTCP包的傳輸。

（BYE包的傳輸，是專一於統計會話中發送BYE包的人數的。）

這容許BYE包被當即發送，並控制總的帶寬使用。在最壞狀況下上，這可能會使RTCP控制包使用兩倍於正常水平的帶寬，達到10%――其中5%給BYE包的RTCP包，其他5%給BYE包。

一個參與者若不想用上面的機制進行RTCP包的發送，能夠直接離開會話，而根本不發送BYE包。他會被其餘參與者因超時而刪除。

一個參與者想離開會話時，若是組中的人數會計數目小於50，則參與者能夠直接發送BYE包。

另外，一個從未發送過RTP或RTCP包的參與者，在離開會話時，不能發送BYE包。

6.3.8更新we_sent變量

    若是一個參與者最近發過RTP包，則變量we_sent值爲true,不然爲false。相同的機制能夠管理髮送者中的其餘參與者。若是參與者發送了TPT包而此時，其對應的we_sent變量值爲false,則就把它本身加到發送者列表中，並設置其we_sent變量爲true。6.3.4節中描述的逆向重估算法（reverse reconsideration algorithm）應當被執行。以可能減小發送SR包前的延遲。每次發送一個RTP包，其相應的傳輸時間都會記錄在表中。通常發送者的超時算法應用到參與者自身：從tc-2T時開始，一直沒有發送RTP包，則此參與者就從發送者列表中將其自身移除，減小發送者總數，並設置we_sent變量值爲false。

6.3.9源描述帶寬的分配

    這裏定義了幾種源描述項，強制性的規範名（CNAME）除外。例如，我的姓名（NAME）和電子郵件地址（EMAIL）。它也提供了方法定義新的RTCP包的類型。應用程序在給這些額外信息分配帶寬時應額外當心。由於這會下降接收報告及CNAME的發送速率，可能破壞協議發揮做用。建議分配給一個參與者用於傳輸這些額外信息的帶寬不超過總的RTCP帶寬的20%。另外，並不是全部的源描述項都將包含進每個應用程序中。包含進應用程序的源描述項應根據其用途分配給相應的帶寬百分比。建議不要動態會計這些百分比，而應根據一個源描述項的典型長度將所佔帶寬的百分比的轉化爲報告間隔。

    例如，一個應用程序可能僅發送CNAME，NAME和EMAIL，而不須要其餘項。NAME可能會比EMAIL給予更高的優先級。由於NAME可能會在應用程序的用戶界面上持續顯示，但EMAIL可能僅僅在須要時纔會顯示。在每個RTCP時間間隔內，一個包含CNAME項的SDES包和一個RR包將會被髮送。最小的會話時間間隔平均爲5秒。每通過3個時間間隔（15秒），一個額外的項將會包含進這個SDES包中。7/8的時間是NAME項，每通過8個這樣的間隔（15s*8=2min）,將會是EMAIL項。

    當多個會話考慮使用一個通用的規範名爲每一個參與者進行綁定時，如在一個RTP會話組成的多媒體會議中，額外的SDES信息可能只在一次RTP會話中被髮送。其他的會話將只發送CNAME。特別，這個辦法也應該用在分層編碼的多個會話中。

6.4　發送者和接收者報告

    RTP接收者利用RTCP報告包提供接收質量反饋。根據接收者是否同時仍是發送者，RTCP包採起兩種不一樣的形式。發送者報告(SR)和接收者報告(RR)格式中惟一的不一樣，除包類型碼以外，在於發送者報告包括20字節的發送者信息。     

   SR包和RR包都包括零到多個接收報告塊。針對該接收者發出上一個報告塊後接收到RTP包的起始同步源，每一個源一個塊。報告不發送給CSRC列表中的貢獻源。每一個接收報告塊提供從特定數據源接收到數據的統計信息。因爲SR/RR包最多容許31個接收報告塊，故能夠在最初的SR或RR包以後附加RR包，以包含從上一個報告以來的間隔內收聽到的全部源的接收報告。若是數據源太多，導致若把全部的RR包放到同一個RTCP複合包中會超出網絡的MTU。那麼就在一個週期內選擇上面RR包的一部分以不超過MTU。這些RR包的選取應讓各個包都有同等的概率被取到。這樣在幾個發送週期間隔中，對全部的數據源就都發送接收報告了。

   如下部分定義了兩種報告的格式。若是應用程序須要其餘信息，他們能夠被擴展。 

6.4.1 SR：發送者報告RTCP包     

         0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header |V=2|P|    RC   |   PT=SR=200   |             length            |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                         SSRC of sender                        |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

sender |              NTP timestamp, most significant word             |

info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |             NTP timestamp, least significant word             |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                         RTP timestamp                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                     sender's packet count                     |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                      sender's octet count                     |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |                 SSRC_1 (SSRC of first source)                 |

block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 1    | fraction lost |       cumulative number of packets lost       |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |           extended highest sequence number received           |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                      interarrival jitter                      |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                         last SR (LSR)                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                   delay since last SR (DLSR)                  |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |                 SSRC_2 (SSRC of second source)                |

block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 2    :                               ...                             :

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

       |                  profile-specific extensions                  |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 發送者報告包由3部分組成，若定義，可能跟隨第4個面向協議的擴展部分。     

 第一部分，頭部，8字節長。該域有如下意義：     

 版本(V)：2比特   RTP版本識別符，在RTCP包內的意義與RTP包中的相同。此協議中定義的版本號爲2。     

 填充(P)：1比特 若設置填充比特，該RTCP包在末端包含一些附加填充比特，並非控制信息的基本部分。填充的最後一個比特統計了多少個字節必須被忽略。填充可能會用於須要固定長度塊的加密算法。在複合RTCP包中，複合包做爲一個總體加密，填料比特只能加在最後一個單個RTCP包的後面。     

 接收報告塊計數(RC)：5比特 該包中所含接收報告塊的數目。零值有效。     

 包類型(PT)：8比特 包含常數200，用以識別這個爲SR包。     

 長度：16比特 該RTCP包的長度減1。其單位是32比特字，包括頭和任何填充字節。(偏移量1保證零值有效，避免了在掃描RTCP包長度時可能發生的無限循環，同時以32比特爲單位避免了對以4爲倍數的有效性檢測。)     

  SSRC：32比特   SR包發送者的同步源標識符。

 第二部分，發送者信息，20字節長。在每一個發送者報告包中出現。它歸納了今後發送者發出的數據傳輸狀況。此域有如下意義：     

  NTP時間戳：64比特 指示了此報告發送時的背景時鐘（wallclock）時刻，它能夠與從其它接收者返回的接收報告塊中的時間標誌結合起來，計算往返每一個接收者所花的時間。接收者應讓NTP時間戳的精度遠大於其餘時間戳的精度。時間戳測量的不肯定性不可知，所以也無需指示。一個系統可能沒有背景時鐘的概念，而只有系統指定的時鐘，如系統時間（system uptime）。在這樣的系統中，此時鐘能夠做爲參考計算相對NTP時間戳。選擇一個公用的時名是很是重要的。這樣多個獨立的應用均可以使用相同的時鐘。到2036年，相對和絕對NTP時間戳會產生大的差別。到那時，咱們但願再也不須要相對時鐘。一個發送者，若是不用背景時鐘時間或逝去時間，能夠設置此項爲零。     

  RTP時間戳：32比特 與以上的NTP時間標誌對應同一時刻。與數據包中的RTP時間戳具備相同的單位和偏移量。這個一致性能夠用來讓NTP時間標誌已經同步的源之間進行媒體內/間同步，還可讓與媒體無關的接收者估計名義RTP時鐘頻率。注意在大多數狀況下此時間戳不等於任何臨近的RTP包中的時間戳。RTP時間戳能夠由相應的NTP時間戳計算獲得。依據的是「RTP時間戳計數器」和「在採樣時經過週期性檢測背景時鐘時間獲得的實際時間」二者之間的關係。

　（在RTCP　SR包中有NTP時間戳、RTP時間戳，它們能夠計算背景時鐘和RTP時鐘之間的對應關係，經過這個關係，能夠由RTP數據包中的RTP時間戳計算也相應的回放時刻。這樣就能夠進行多個流的同步了。之因此要有NTP時間戳，是由於不一樣流的RTP時間戳有不一樣的隨機偏移量，沒法直接進行同步：筆者注。） 

 發送的報文數：32比特 從開始傳輸到此SR包產生時該發送者發送的RTP數據包總數。若發送者改變SSRC識別符，該計數器重設。

 發送的字節文數：32比特 從開始傳輸到此SR包產生時該發送者在RTP數據包發送的字節總數(不包括頭和填充)。若發送者改變SSRC識別符，該計數器重設。此域能夠用來估計平均的負載數據發送速率。     

 第三部分：零到多個接收報告塊。塊數等於從上一個報告以來該發送者偵聽到的其它源（不包括自身）的數目。每一個接收報告塊傳輸從某個同步源來的數據包的接收統計信息。若數據源因衝突而改變其SSRC標識符，接收者從新設置統計信息。這些統計信息有：     

  SSRC_n(同步源標識符)：32比特 在此接收報告塊中信息所屬源的SSRC標識符。     

 丟包率：8比特 自從前一SR包或RR包發送以來，從SSRC_n傳來的RTP數據包的丟失比例。以定點小數的形式表示。該值定義爲損失包數／指望接收的包數。若因爲包重複而致使包丟失數爲負值，丟包率設爲零。注意在收到上一個包後，接收者沒法知道之後的包是否丟失。如：若在上一個接收報告間隔內從某個源發出的全部數據包都丟失，那麼將不爲此數據源發送接收報告塊。 

 累計包丟失數：24比特 從開始接收到如今，從源SSRC_n發到本源的RTP數據包的丟包總數。該值定義爲：指望接收的包數－實際接收的包數。接收的包括複製的或遲到的。因爲遲到的包不算做損失，在發生複製時丟包數可能爲負值。指望接收的包數定義爲：擴展的上一接收序號(隨後定義)減去最初接收序號。     

 接收到的擴展的最高序列號：32比特 低16比特包含從源SSRC_n來的最高接收序列號，高16比特用相應的序列號週期計數器擴展該序列號。注意在同一會議中的不一樣接收者，若啓動時間明顯不一樣，將產生不一樣的擴展項。     

 到達間隔抖動：32比特   RTP數據包到達時刻統計方差的估計值。測量單位同時間戳單位，用無符號整數表達。到達時間抖動定義爲一對包中接收者相對發送者的時間間隔差值的平均誤差(平滑後的絕對值)。如如下等式所示，該值等於兩個包相對傳輸時間的差值。相對傳輸時間是指：包的RTP時間戳和到達時刻接收者時鐘時間的差值。若Si是包i中的RTP時間戳，Ri是包i到達時刻（單位爲：RTP時間戳單位）。對於兩個包i和j，D能夠表示爲  D(i，j)=(Rj-Sj)-(Ri-Si)；

 到達時刻抖動能夠在收到從源SSRC_n來的每一個數據包i後連續計算。利用該包和前一包i-1的誤差D(按到達順序，而非序號順序)，根據公式J=J+(|D(i-1，i)|-J)/16計算。不管什麼時候發送接收報告，都用當前的J值。

 此處描述的抖動計算容許與協議獨立的監視器對來自不一樣實現的報告進行有效的解釋。     

 上一SR報文   (LSR)：32比特 接收到的來自源SSRC_n的最新RTCP發送者報告(SR)的64位NTP時間標誌的中間32位。若尚未接收到SR，該域值爲零。

 自上一SR的時間(DLSR)：32比特 是從收到來自SSRC_n的SR包到發送此接收報告塊之間的延時，以1/65536秒爲單位。若還未收到來自SSRC_n的SR包，該域值爲零。     

 假設SSRC_r爲發出此接收報告塊的接收者。源SSRC_n能夠經過記錄收到此接收報告塊的時刻A來計算到SSRC_r的環路傳輸時延。能夠利用最新的SR時間標誌(LSR)計算整個環路時間A-LSR，而後減去此DLSR域獲得環路傳輸的時延。 

　以下圖所示。

   [10 Nov 1995 11:33:25.125 UTC]       [10 Nov 1995 11:33:36.5 UTC]

   n                 SR(n)              A=b710:8000 (46864.500 s)

   ---------------------------------------------------------------->

                      v                 ^

   ntp_sec =0xb44db705 v               ^ dlsr=0x0005:4000 (    5.250s)

   ntp_frac=0x20000000 v             ^ lsr =0xb705:2000 (46853.125s)

     (3024992005.125 s) v           ^

   r                      v         ^ RR(n)

   ---------------------------------------------------------------->

                          |<-DLSR->|

                           (5.250 s)

 

   A     0xb710:8000 (46864.500 s)

   DLSR -0x0005:4000 (    5.250 s)

   LSR -0xb705:2000 (46853.125 s)

   -------------------------------

   delay 0x0006:2000 (    6.125 s)

 

           圖2: 往返路程時間的計算舉例

 

 能夠用此來近似測量到一組接收者的距離，儘管有些鏈接可能有很是不對稱的時延。

6.4.2  RR：接收者報告包     

        0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header |V=2|P|    RC   |   PT=RR=201   |             length            |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                     SSRC of packet sender                     |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |                 SSRC_1 (SSRC of first source)                 |

block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 1    | fraction lost |       cumulative number of packets lost       |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |           extended highest sequence number received           |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                      interarrival jitter                      |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                         last SR (LSR)                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                   delay since last SR (DLSR)                  |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |                 SSRC_2 (SSRC of second source)                |

block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 2    :                               ...                             :

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

       |                  profile-specific extensions                  |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

   接收者報告包(RR)與發送者報告包基本相同，除了包類型域包含常數201和沒有發送者信息的5個字(NTP和RTP時間標誌和發送者包和字節計數)。餘下區域與SR包意義相同。若沒有發送和接收據報告，在RTCP複合包頭部加入空的RR包(RC=0)。

6.4.3發送者和接收者報告擴展

    若是有額外的關於發送者和接收者的信息要週期性的，描述文件（profile）應該定義接收者報告和發送者報告描述文件擴展。此時，應採用這裏的辦法，而不是定義另外的RTCP包。由於這種辦法須要的頭部信息更少。

    擴展部分是發送報告包和接收報告包的第四部分。若是有的話，應緊跟在接收報告塊的後面。若是須要更多的發送者信息，它應當跟在發送者報告的開關，而不該在報告中出現。若是要包含進接收者的信息，它應該以塊數組的方式放到接收報告塊的後面。即這些塊也應被計入RC字段中。

6.4.4分析發送者和接收者報告 

   接收質量反饋不只對發送者有用，並且對於其它接收者和第三方監視器也有做用。發送者能夠基於反饋修正發送信息量；接收者能夠判斷問題是本地的，區域內的仍是全局的；網絡管理者能夠利用與協議無關的監視器(只接收RTCP包而不接收相應的RTP包)去評估多點傳送網絡的性能。

    在發送者信息和接收者報告塊中都連續統計丟包數，所以能夠計算任何兩個報告塊中的差異。在短期和長時間內均可以進行測算。最近收到的兩個包之間差值能夠評估當前傳輸質量。包中有NTP時間戳，能夠用兩個報告間隔的差值計算傳輸速率。因爲此時間間隔與數據編碼速率獨立，所以能夠實現與編碼及協議獨立的質量監視。

    一個例子是計算兩個報告間隔時間內的丟包率。丟包率＝此間隔內丟失的包／此間隔內指望收到的包。若是此值與「丟失比例」字段中的值相同，說明包是連續的；若否，說明包不是連續的。間隔時間內的丟包率／間隔時間＝每秒的丟包率。

    從發送者信息中，第三方監視器能夠在一個時間間隔內計算平均負載數據發送速率和平均發包速率，而無需考慮數據接收。兩個值的比就是平均負載大小（平均每一個包的負載大小）。（即：平均負載大小＝平均負載數據發送速率／平均發包率。）若能假定丟包與包的大小無關，那麼某個特定接收者收到的包數乘以平均負載大小(或相應的包大小)就得出接收者可獲得的外在吞吐量。

除了累計計數容許利用報告間差值進行長期包損測量外，單個報告的「丟包比例」字段提供一個短時測量數據。當會話規模增長到沒法爲全部接收者保存接收狀態信息，或者報告間隔變得足夠長以致於從一個特定接收者只能收到一個報告時，短時測量數據變得更重要。

到達間隔抖動字段提供另外一個有關網絡阻塞的短時測量量。丟包反映了長期阻塞，抖動測量反映出短期的阻塞。抖動測量能夠在致使丟包前預示阻塞。因爲到達間隔抖動字段僅僅是發送報告時刻抖動的一個快照，所以須要在一個網絡內在一段時間內分析來自某個接收者的報告，或者分析來自多個接收者的報告。

6.5源描述RTCP包

    源描述（SDES）包由一個頭及0個或多個塊組成。每一個塊都由塊中所標識的數據源的標識符及其後的各個描述構成。

        0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header |V=2|P|    SC   | PT=SDES=202 |             length            |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

chunk |                          SSRC/CSRC_1                          |

 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                           SDES items                          |

       |                              ...                              |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

chunk |                          SSRC/CSRC_2                          |

 2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                           SDES items                          |

       |                              ...                              |

       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

6.6 BYE（BYE包）

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |V=2|P|    SC   |   PT=BYE=203 |             length            |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                           SSRC/CSRC                           |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      :                              ...                              :

      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

(opt) |     length    |               reason for leaving            ...

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    BYE包代表一個或多個源將要離開。若是混合器收到BYE包，混合器應當發送這個BYE包，並保持SSRC/CSRC不變。若是混合器關閉，應向貢獻源列表中的全部SSRC，包括它本身的SSRC發送BYE包。BYE包可能會有選擇的包含8個字節的統計字段，其後跟上幾個字節的文本代表離開的緣由。文本字符串編碼格式和SDES中描述的相同。

 

9安全性

    底層協議將最終提供由RTP應用要求的全部安全服務，包括真實性、完整性、保密性。這些服務在參考文獻[27]中的IP協議有詳細描述。因爲使用RTP的初始音頻和視頻應用在IP層可用以前就要求保密性服務，所以，隨後的一小節描述了使用RTP和RTCP的保密性服務。新的RTP應用能夠實現這裏描述的RTP保密性服務，以用於向後兼容，也能夠實現替代這裏的安全服務。這種安全服務的RTP開銷是比較小的。所以，若是這項服務被未來的某種服務所替代，代價也是比較小的。

    另外一方面，RTP的其餘服務，服務的其餘實現及其餘的算法可能會在未來定義。特別是爲RTP負載提供可靠性的實時安全傳輸協議（ Secure Real-time Transport, SRTP）正在制定中。它能夠使RTP頭部不被加密。這樣，鏈路層的頭部壓縮算法能夠繼續使用。SRTP基於高級企業標準（Advanced Encryption Standard, AES）制定。它比這裏描述的服務提供更強健的安全性。

    密鑰和證書分配超出了本文的範圍。

9.1 保密性

    保密性意味着只有特定的接收者纔可以對收到的包進行解碼；對其餘人，包裏含有的都是無用信息。內容的保密性經過加密來實現。

當用這節指定的方法RTP、RTCP加密時，爲了傳輸而封裝的全部字節將在底層的包中做爲一個單元加密。對RTCP，每一個單元在加密以前必須在前面附加一個32字節的隨機數。對RTP，沒必要在前面加前綴，而是讓序列號和時間戳字段都用隨機偏移量初始化。因爲較差的隨機性質。這實際上是一個弱的初始化向量（initialization vector, IV）。另外，若是其後的SSRC字段被攻擊者獲得，則加密算法將出現新的薄弱點。

對RTCP，一個應用程序可能將RTCP複合包中的一個RTCP包分割成兩個RTCP複合包。其中，一個在發送時加密，另外一個發送時不加密。例如，SDES信息可能會被加密，但接收者報告卻不加密，以適用於沒有密鑰的第三方監視者。如圖4所示。源描述信息後必須附加沒有報告的空RR包，以知足全部RTCP複合包必須以SR或RR包開頭的要求。SDES的CNAME字段包含在加密或未加密的包中之一便可，但並不都須要包含。相同的源描述信息不該在兩個包中都攜帶。不然會使加密算法不安全。

             UDP packet                     UDP packet

   ----------------------------- ------------------------------

   [random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]

   ----------------------------- ------------------------------

             encrypted                     not encrypted

 

   #: SSRC identifier

       圖4: 加密的和未加密的RTCP包

接收者加密的使用和正確密鑰的使用經過頭或負載的有效性檢查進行確認。RTP和RTCP頭的有效性檢查由附錄A.1和A.2給出。

爲和RFC1889中RTP初始描述中的實現相一致。默認的算法是鏈式加密塊模式（cipher block chaining (CBC) mode）下的數據加密算法，見RFC1423中1.1節的描述。除非出現由5.1節描述指明的填充多個字節的狀況，不然，初始的隨機向量是0，由於隨機值由RTP頭或RTCP複合包的隨機前綴提供。CBC初始向量的細節見參考文獻[30]。支持本節的加密算法的實現也應當支持CBC下的DES算法。由於此算法可實現最大程度的交互可操做性。採用這種方法的緣由是，因特網上經過音頻、視頻工具作實驗證實它簡便且有效。但DES被發現很容易被破解。建議用更強健的加密算法，例如三層DES加密算法來代替默認的加密算法。另外，安全CBC模式要求每一個包的第一個塊和一個隨機數求異或。對於RTCP，這經過在每一個包前附加一個32位的隨機數實現。每一個包的隨機數相互獨立。對RTP，時間戳和序列號將從附加的數值開始，但對連續的包，它們並非被獨立的隨機化的。應該注意到對RTP和RTCP，這種隨機性都受到了限制。高安全性的應用應當考慮其餘更加簡捷安全的方法。其餘加密算法應經過非RTP方法對一個會話動態指定。特別是基於AES的SRTP描述文件（見參考文獻[23]）將會是將來的一個不錯的選擇。以上描述了IP層或RTP層加密。做爲它的替代，描述文件能夠定義另外的負載類型以用於加密、編碼。這些編碼必須描述如何填充，以及編碼的其餘方面如何控制。這種方法能夠按照應用的要求，只加密數據，不加密頭部。這可能對同時處理解密和解碼的硬件服務特別重要。這也可能對RTP和底層頭部的鏈路層的應用頗有用。既然頭部的加密已經進行了壓縮，負載（而不是地址）的保密性就足夠了。

9.2　真實性和信息完整性

    真實性和信息完整性沒有在RTP層定義，由於這些服務離不開密鑰管理體系。能夠指望真實性和信息完整性將由底層協議完成。

 

10　擁塞控制

    因特網上的全部傳輸協議都須要經過一些方法進行地址擁塞控制（見參考文獻[31]），RTP也不例外。但因爲RTP數據傳輸常常缺乏彈性（以固定的或控制好的速率產生包）。所以，RTP的擁塞控制方法和其餘的傳輸協議，如TCP很不相同。在某種程度上，缺少彈性意味着下降了擁塞的風險。由於RTP流不會像TCP流那樣增加到消耗掉全部可用的帶寬程度。可是，缺少彈性也意味着RTP流不能任意減少它在網絡上的負載量，以在出現擁塞時消除之。

    因爲RTP可能會在許多不一樣的狀況下用於至關廣的。所以就沒有一個全都通用一個擁塞控制機制。所以，擁塞控制應當在描述文件中定義。對於某些描述，可能加上可應用性陳述以限制描述應用在已設計消除擁塞的環境中。對其它描述，可能須要特別的方法，如基於RTCP反饋的自適應數據傳輸速率。

參考文獻：

正式參考文獻

[1] Schulzrinne, H. and S. Casner, "音頻和視頻會議最小控制的RTP描述", RFC 3551, 2003.6

    [2] Bradner, S., "表示需求層的RFC關鍵字", BCP 14, RFC 2119, 1997.3

    [3] Postel, J., "網絡協議", STD 5, RFC 791, 1981.9

    [4] Mills, D., "網絡時間協議（第三版）描述、實現和分析", RFC 1305,1992.3

    [5] Yergeau, F., "UTF-8, 一個ISO 10646傳輸格式", RFC 2279,1998.1

    [6] Mockapetris, P., "域名――概念和工具", STD 13, RFC 1034,1987.11

    [7] Mockapetris, P., "域名――實現和描述", STD 13, RFC 1035,1987.1

    [8] Braden, R., "因特網主機需求――應用和支持", STD 3, RFC 1123,1989.10

    [9] Resnick, P., "因特網信息格式", RFC 2822,2001.4

非正式參考文獻

    [10] Clark, D. and D. Tennenhouse, "新一代協議的建構考慮," 關於通訊體系結構和協議的數據通訊專業組討論班, (賓夕法尼亞州，費城), IEEE 計算機通訊回顧　卷. 20(4), 200－208頁,1990.9

    [11] Schulzrinne, H., "關於設計音頻、視頻會話傳輸協議及其它多參與者實時應用的討論", 1993.10

    [12] Comer, D., TCP/IP網絡協議 ,卷1. Englewood　 Cliffs, New Jersey: Prentice Hall, 1991.

    [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:會話初始協議", RFC 3261,2002.6

    [14] International Telecommunication Union, "對不保證質量的局域網的可視電話系統和設備", Recommendation H.323,ITU的無線電通信標準一節, Geneva,        Switzerland, 2003.7

    [15] Handley, M. and V. Jacobson, "SDP: 會話描述協議", RFC 2327,1998.4

    [16] Schulzrinne, H., Rao, A. and R. Lanphier, "實時流協議(RTSP)", RFC 2326,1998.4

    [17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "關於安全性的隨機化建議", RFC 1750, 1994.12

    [18] Bolot, J.-C., Turletti, T. and I. Wakeman, "因特網多播視頻分佈的可升級的反饋控制",關於通訊體系結構和協議的數據通訊專業組討論班（英國，倫敦）, ACM,58—67頁, 1994.8

    [19] Busse, I., Deffner, B. and H. Schulzrinne, "基於RTP的多媒體應用的動態　QoS控制", 計算機通信,卷19,49—58頁,1996.1

    [20] Floyd, S. and V. Jacobson, "週期性路由信息的同步",關於通訊體系結構和協議的數據通訊專業組討論班 (舊金山,加利福尼亞), 33—44頁, ACM,1993.9 並參見[34].

    [21] Rosenberg, J. and H. Schulzrinne, "RTP中成員組的採樣", RFC 2762,2000.2

    [22] Cadzow, J., "紐約數字信號處理和數據分析基礎"　紐約: Macmillan, 1987.

    [23] Hinden, R. and S. Deering, "IPv6地址結構", RFC 3513,2003.4

    [24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.Lear, "保密因特網中的地址分配", RFC 1918,1996.2

    [25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "考慮可能有害的網絡10 (一些實現不該成爲標準)", RFC 1627,1994.7

    [26] Feller, W.,機率論及其應用入門,卷1. 紐約: John Wiley and Sons , 1968.

    [27] Kent, S. and R. Atkinson, "因特網協議的安全體系", RFC 2401,1998.11

    [28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M.,Norrman, K. and D. Oran, "安全實時傳輸協議",2003.4

    [29] Balenson, D., "加強因特網電子郵件的保密性:第三部分", RFC 1423,1993.2

    [30] Voydock, V. and S. Kent, "高層網絡協議的安全機制", ACM 計算調查,卷15,135-171頁,1983.6

    [31] Floyd, S., "擁塞控制原理", BCP 41, RFC 2914,2000.9

    [32] Rivest, R., "MD5通信――算法摘要", RFC 1321,1992.4

    [33] Stubblebine, S., "多媒體會話的安全服務", 第16屆國際安全會議，(巴爾的摩,馬里蘭州),391—395頁,1993.9

    [34] Floyd, S. and V. Jacobson, "週期路由信息同步", IEEE/ACM 網絡傳輸,卷2,122—136頁,1994.4

 

來自爲知筆記(Wiz)

附件列表