轉載地址：http://blog.chinaunix.net/u2/82249/showart_1951833.html
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的值）；否則，發送者和接收者將統一處理。
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;
|
如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=tc; tn=tc+T; initial=false;
|
avg_rtcp_size=1/16 * packet_size + 15/16 * avg_rtcp_size
|
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
posted on 2009-08-04 17:14
阿蜜果 閱讀(2487)
評論(3) 編輯 收藏 所屬分類:
協議