轉自：http://blog.chinaunix.net/uid-7396260-id-2056682.html
對應英文版：https://tools.ietf.org/html/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 ![編譯vlc-android[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)