轉(zhuǎn)載地址：http://blog.chinaunix.net/u2/82249/showart_1951833.html
RTP：實(shí)時應(yīng)用程序傳輸協(xié)議
摘要
本文描述RTP（real-time transport protocol），實(shí)時傳輸協(xié)議。RTP在多點(diǎn)傳送（多播）或單點(diǎn)傳送（單播）的網(wǎng)絡(luò)服務(wù)上，提供端對端的網(wǎng)絡(luò)傳輸功能，適合應(yīng)用程序傳輸實(shí)時數(shù)據(jù)，如：音頻，視頻或者仿真數(shù)據(jù)。RTP沒有為實(shí)時服務(wù)提供資源預(yù)留的功能，也不能保證QoS（服務(wù)質(zhì)量）。數(shù)據(jù)傳輸功能由一個控制協(xié)議（RTCP）來擴(kuò)展，通過擴(kuò)展，可以用一種方式對數(shù)據(jù)傳輸進(jìn)行監(jiān)測控制，該協(xié)議（RTCP）可以升級到大型的多點(diǎn)傳送（多播）網(wǎng)絡(luò)，并提供最小限度的控制和鑒別功能。RTP和RTCP被設(shè)計成和下面的傳輸層和網(wǎng)絡(luò)層無關(guān)。協(xié)議支持RTP標(biāo)準(zhǔn)的轉(zhuǎn)換器和混合器的使用。
本文的大多數(shù)內(nèi)容和舊版的RFC1889相同。在線路里傳輸?shù)臄?shù)據(jù)包格式?jīng)]有改變，唯一的改變是使用協(xié)議的規(guī)則和控制算法。為了最小化傳輸，發(fā)送RTCP數(shù)據(jù)包時超過了設(shè)定的速率，而在這時，很多的參與者同時加入了一個會話，在這樣的情況下，一個新加入到（用于計算的可升級的）計時器算法中的元素是最大的改變。
目錄（Table of Contents）
1. 引言 （Introduction）
1. 1 術(shù)語（Terminology）
2 RTP使用場景（RTP Use Scenarios）
2.1 簡單多播音頻會議（ Simple Multicast Audio Conference）
2.2 音頻和視頻會議（Audio and Video Conference）
2.3 混頻器和轉(zhuǎn)換器（Mixers and Translators）
2.4 分層編碼（Layered Encodings）
3 定義（Definitions）
4 字節(jié)序，校正和時間格式（Byte Order, Alignment, and Time Format）
5 RTP數(shù)據(jù)傳輸協(xié)議（RTP Data Transfer Protocol）
5.1 RTP固定頭域（RTP Fixed Header Fields）
5.2 多路復(fù)用RTP會話（Multiplexing RTP Sessions）
5.3 RTP頭的配置文件詳細(xì)變更（Profile-Specific Modifications to the RTP Header）
5.3.1 RTP報頭擴(kuò)展（RTP Header Extension）
6 RTP控制協(xié)議（RTP Control Protocol） -- RTCP
6.1 RTCP包格式（RTCP Packet Format）
6.2 RTCP傳輸間隔（RTCP Transmission Interval）
6.2.1 維護(hù)會話成員數(shù)目（Maintaining the number of session members）
6.3 RTCP包的發(fā)送與接收規(guī)則（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 關(guān)于傳輸計時器的到期（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 發(fā)送方和接收方報告（Sender and Receiver Reports）
6.4.1 SR：發(fā)送方報告的RTCP包（SR: Sender report RTCP packet）
6.4.2 RR：接收方報告的RTCP包（RR: Receiver Report RTCP Packet）
6.4.3 擴(kuò)展發(fā)送方和接收方報告（Extending the Sender and Receiver Reports ）
6.4.4 分析發(fā)送方和接收方報告（Analyzing Sender and Receiver Reports ）
6 5 SDES：源描述RTCP包（SDES: Source description RTCP packet）
6 5 1 CNAME：規(guī)范終端標(biāo)識符的SDES數(shù)據(jù)項(CNAME: Canonical End-Point Identifier SDES Item）
6 5 2 NAME：用戶名的SDES數(shù)據(jù)項（NAME: User name SDES item)
6 5 3 EMAIL:電子郵件地址的SDES數(shù)據(jù)項（EMAIL: Electronic Mail Address SDES Item）
6 5 4 PHONE：電話號碼的SDES數(shù)據(jù)項（PHONE: Phone Number SDES Item）
6 5 5 LOC:地理用戶地址的SDES數(shù)據(jù)項（LOC: Geographic User Location SDES Item）
6 5 6 TOOL：應(yīng)用程序或工具名字的SDES數(shù)據(jù)項（TOOL: Application or Tool Name SDES Item）
6 5 7 NOTE：通知/狀態(tài)的SDES數(shù)據(jù)項（NOTE: Notice/Status SDES Item）
6 5 8 PRIV:私有擴(kuò)展的SDES數(shù)據(jù)項（PRIV: Private Extensions SDES Item）
6 6 BYE：Goodbye RTCP包（BYE: Goodbye RTCP packet）
6 7 APP:定義應(yīng)用程序的RTCP包（APP: Application-Defined RTCP Packet）
7 RTP轉(zhuǎn)換器和混頻器（RTP Translators and Mixers）
7 1 概述（General Description ）
7 2 在轉(zhuǎn)換器中的RTCP數(shù)據(jù)處理（RTCP Processing in Translators）
7 3 在混頻器中的RTCP數(shù)據(jù)處理（RTCP Processing in Mixers ）
7 4 級聯(lián)混頻器（Cascaded Mixers）
8 SSRC標(biāo)識符的分配和使用（SSRC Identifier Allocation and Use）
8 1 沖突概率（Probability of Collision ）
8 2 沖突解決和循環(huán)檢測（Collision Resolution and Loop Detection）
8 3 在分層編碼中使用（Use with Layered Encodings）
9 安全（Security ）
9 1 機(jī)密性（Confidentiality）
9 2 身份驗證和消息完整性（Authentication and Message Integrity）
10 擁塞控制（Congestion Control）
11 網(wǎng)絡(luò)和傳輸協(xié)議之上的RTP（RTP over Network and Transport Protocols）
12 協(xié)議常量摘要（Summary of Protocol Constants）
12 1 RTCP 包類型（RTCP Packet Types）
12 2 SDES 類型（SDES Types）
13 RTP概況和負(fù)載格式詳細(xì)說明
（RTP Profiles and Payload Format Specifications）
14 安全考慮（Security Considerations）
15 IANA考慮（IANA Considerations）
16 知識產(chǎn)權(quán)聲明（Intellectual Property Rights Statement）
17 鳴謝（Acknowledgments）
附錄 A 算法（Algorithms）
附錄 A 1 RTP數(shù)據(jù)頭有效性檢查（RTP Data Header Validity Checks ）
附錄 A 2 RTCP數(shù)據(jù)頭有效性檢查（RTCP Header Validity Checks）
附錄 A 3 確定RTP包預(yù)期數(shù)目和丟失數(shù)目（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位隨機(jī)標(biāo)識符（Generating a Random 32-bit Identifier
附錄 A 7 計算RTCP傳輸間隔（Computing the RTCP Transmission Interval）
附錄 A 8 估測兩次到達(dá)間隔的抖動（Estimating the Interarrival Jitter）
附錄 B 與RFC1889不同之外（Changes from RFC 1889）
參考書目（References）
標(biāo)準(zhǔn)化引用（Normative References ）
資料性引用（Informative References）
作者地址
完整的版權(quán)聲明
1.緒論
本文詳細(xì)的介紹實(shí)時傳輸協(xié)議RTP，RTP提供帶有實(shí)時特性的端對端數(shù)據(jù)傳輸服務(wù)，傳輸?shù)臄?shù)據(jù)如：交互式的音頻和視頻。那些服務(wù)包括有效載荷類型定義，序列號，時間戳和傳輸監(jiān)測控制。應(yīng)用程序在UDP上運(yùn)行RTP來使用它的多路技術(shù)和checksum服務(wù)。2種協(xié)議都提供傳輸協(xié)議的部分功能。不過，RTP可能被其他適當(dāng)?shù)南聦泳W(wǎng)絡(luò)和傳輸協(xié)議使用（見11節(jié)）。如果下層網(wǎng)絡(luò)支持，RTP支持?jǐn)?shù)據(jù)使用多播分發(fā)機(jī)制轉(zhuǎn)發(fā)到多個目的地。
注意RTP本身沒有提供任何的機(jī)制來確保實(shí)時的傳輸或其他的服務(wù)質(zhì)量保證，而是由低層的服務(wù)來完成。它不保證傳輸或防止亂序傳輸，它不假定下層網(wǎng)絡(luò)是否可靠，是否按順序傳送數(shù)據(jù)包。RTP包含的序列號允許接受方重構(gòu)發(fā)送方的數(shù)據(jù)包順序，但序列號也用來確定一個數(shù)據(jù)包的正確位置，例如，在視頻解碼的時候不用按順序的對數(shù)據(jù)包進(jìn)行解碼。
但是RTP原先的設(shè)計是用來滿足多參與者的多媒體會議的需要，它沒有限定于專門的應(yīng)用。連續(xù)數(shù)據(jù)的儲存，交互分布式仿真，動態(tài)標(biāo)記，以及控制和測量應(yīng)用程序也可能會適合使用RTP。
該文檔定義RTP，由2個密切聯(lián)系的部分組成：
○實(shí)時傳輸協(xié)議RTP，用于實(shí)時傳輸數(shù)據(jù)。
○RTP控制協(xié)議RTCP，用于監(jiān)控服務(wù)質(zhì)量和傳達(dá)關(guān)于在一個正在進(jìn)行的會議中的參與者的信息。后者對“寬松控制”的會議可能已經(jīng)足夠，但是并沒有必要去支持一個應(yīng)用程序所有的通訊控制條件。這個功能可能充分的或者部分的被一個單獨(dú)的會議控制協(xié)議所包含，這超過了本文檔的范圍。
RTP表現(xiàn)了協(xié)議的一種新的類型，該類型由Clark和Tennenhouse提出[10]，遵循應(yīng)用級（framing）框架和（integrated layer processing）統(tǒng)一層處理的原則。就是說，RTP被規(guī)定為可擴(kuò)展的，用來提供一個專門的應(yīng)用程序需要的信息，并將會經(jīng)常性的被歸并到應(yīng)用程序的處理中，而不是作為一個單獨(dú)的層被實(shí)現(xiàn)。RTP只是一個故意不完成的協(xié)議框架。本文檔詳細(xì)說明那些功能，希望這些功能能夠普遍貫穿于所有適合使用RTP的應(yīng)用程序。和常規(guī)的協(xié)議不同，額外的功能可能通過完善協(xié)議本身或者增加一個可能需要分析的選項機(jī)制來增加，RTP被規(guī)定為可以根據(jù)需要通過修改和/或增加操作，“剪裁”到報頭。具體的例子見5.3和6.4.3節(jié)。
因此，除了本文檔，用于專門應(yīng)用程序的RTP完整的說明將還需要一個或者更多的同類文檔（見13節(jié)）：
○ 一個框架（大致輪廓）的說明文檔，該文檔定義了一系列的有效載荷類型編碼和它們與有效載荷格式之間的映射（例如，媒體編碼）。一個框架可能也定義了應(yīng)用程序?qū)TP的一些擴(kuò)展和修改，詳細(xì)到一個專門的類。典型的情況，一個應(yīng)用程序?qū)⒃谝粋€框架下運(yùn)行。一個用于音頻和視頻數(shù)據(jù)的框架可以在同類RFC3551[1]文檔里找到。
○有效載荷格式說明文檔，該文檔定義了一個像一個音頻或者視頻編碼的特殊載荷，在RTP里是如何被傳輸?shù)摹?/font>
一個關(guān)于實(shí)時服務(wù)和算法如何實(shí)現(xiàn)的討論和關(guān)于一些RTP設(shè)計結(jié)果的后臺討論能夠在[11]中找到。
1.1術(shù)語
在這個文檔里的關(guān)鍵詞“一定要”，“一定不能”，“必需的”，“會”，“不會”，“應(yīng)該”，“不應(yīng)該”，“推薦”，“可能”和“可選” 將會像在BCP 14（Basic Control Program，基本控制程序），RFC2119[2]里描述一樣的解釋。并指出適合RTP實(shí)現(xiàn)的需要的級別。
2. RTP使用場景（RTP Use Scenarios）
2.1 簡單多播音頻會議（ Simple Multicast Audio Conference）
2.2 音頻和視頻會議（Audio and Video Conference）
2.3 混頻器和轉(zhuǎn)換器（Mixers and Translators）
2.4 分層編碼（Layered Encodings）
以下章節(jié)描述了用到RTP的一些方面。所舉例子用來說明RTP應(yīng)用的基本操作，但RTP的用途不限于此。在這些例子中，RTP運(yùn)行于IP和UDP之上，并且遵循RFC3551所描述的音頻和視頻的配置文件中的約定。
2.1 簡單多播音頻會議（Simple Multicast Audio Conference）
IETF的一個工作組開會討論最新協(xié)議草案時，使用Internet的IP多播服務(wù)來進(jìn)行語音通訊。工作組中心分配到一個多播的組地址和一對端口。一個端口用于音頻數(shù)據(jù)，另一個端口用于控制（RTCP）數(shù)據(jù)包。該地址和端口信息發(fā)布給預(yù)定的參與者。如果有私密性要求，則可用章節(jié)9.1中說明的方法，對數(shù)據(jù)和控制包進(jìn)行加密，這時就需要生成和發(fā)布加密密鑰。分配和發(fā)布機(jī)制的精確細(xì)節(jié)不在RTP的討論范圍之內(nèi)。
每個與會者所使用的音頻會議應(yīng)用程序，都以小塊形式（比方說持續(xù)２０秒時間）來發(fā)送音頻數(shù)據(jù)。每個音頻數(shù)據(jù)塊都前導(dǎo)RTP報頭；RTP報頭和數(shù)據(jù)依次包含在UDP包里。RTP報頭指明了各個包里音頻編碼的類型（如PCM,ADPCM,LPC），這樣發(fā)送方可以在會議過程中改變編碼方式，以適應(yīng)狀況的變化，例如，要加進(jìn)一個低帶寬接入的參與者，或是要應(yīng)付網(wǎng)絡(luò)擁塞。
Internet，像其他的報文分組網(wǎng)絡(luò)一樣，偶而會丟失和重排包，造成時長不等的延遲。為彌補(bǔ)這個不足，RTP報頭里包含計時信息和一個序列號，允許接收方重建來自源的計時信息，比如前文例子中音頻塊以20s的間隔在揚(yáng)聲器中連續(xù)播放。會議中，對每個RTP包的源,單獨(dú)地實(shí)施計時重建。序列號還被接收方用來評估丟失包數(shù)目。
由于會議期間不斷有工作組成員加入或離開，因此有必要知道任一時刻的實(shí)際參與者及他們接收音頻數(shù)據(jù)的狀況好壞。出于這個目的，會議中每個音頻應(yīng)用程序的實(shí)例，都在RTCP（控制）端口上周期性地多播一個附加用戶名的接收報告。接收報告指明了當(dāng)前說話者被收聽到的狀況，可用于控制自適應(yīng)性編碼。除了用戶名外，通過控制帶寬限度，可以包含其他標(biāo)識信息。一個站點(diǎn)在離開會議時發(fā)送RTCP BYE包（章節(jié)6.5）。
2.2 音頻和視頻會議（Audio and Video Conference）
一個會議如果同時使用音頻和視頻媒體，則二者傳輸時使用不同的RTP會話。也就是說，兩種媒體中RTP包和RTCP包的傳輸，是使用兩個不同的UDP端口對和（或）多播地址。在RTP層次，音頻和視頻會話沒有直接的耦合，下面這種情況除外：一個同時參加兩個會話的參與者，在兩個會話的RTCP包中，使用了相同的規(guī)范名，這樣兩個會話就發(fā)生關(guān)聯(lián)（耦合）了。
這樣區(qū)隔開來的目的之一，是允許一些會議參與者只接受自己選擇的單一媒體（或者音頻，或者視頻）。更進(jìn)一步的說明在章節(jié)5.2給出。盡管兩種媒體區(qū)分開來了，但通過兩個會話RTCP包內(nèi)載有的計時信息，同源的音頻與視頻還是能夠同步回放。
2.3 混頻器和轉(zhuǎn)換器（Mixers and Translators）
到目前為止，我們皆假設(shè)所有站點(diǎn)都收到相同格式的媒體數(shù)據(jù)。然而這并不總是行得通?？紤]一下這種情況，一個地方的參與者只能低速接入會議，而其他大部分參與者都能享受高速連接。與其讓強(qiáng)迫大家都忍受低帶寬，不如在只能低速接入的地方，放置一個減質(zhì)量音頻編碼的RTP層次的中繼（稱作混頻器）?；祛l器將重新同步輸入的音頻包，重建發(fā)送方產(chǎn)生的20ms固定間隔，混頻已重建過的音頻流為單一的流，轉(zhuǎn)換音頻編碼為低帶寬格式，最后通過低帶寬連接轉(zhuǎn)發(fā)數(shù)據(jù)包流（package stream)。這些包可能被單播到一個接收方，也可能多播到另一個的地址而發(fā)給多個接收方。RTP報頭為混頻器提供了一種方法，使其能辨識出對混頻后的包有用的源，從而保證提供給接收方正確的說話者指示。
在音頻會議中，一些預(yù)定參與者盡管有高帶寬連接，但不能通過IP多播直接接入會議。例如，他們可能位于一個不允許任何IP包通過的應(yīng)用層防火墻后面。對這些站點(diǎn)，可能就不需要混頻，而需要另一種稱為轉(zhuǎn)換器的RTP層次中繼?？梢栽诜阑饓蓚?cè)分別安裝一個轉(zhuǎn)換器，外側(cè)轉(zhuǎn)換器將所有多播包通過安全連接轉(zhuǎn)入內(nèi)側(cè)轉(zhuǎn)換器，內(nèi)側(cè)轉(zhuǎn)換器再轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)的一個多播組（multicast group)。
混頻器和轉(zhuǎn)換器可以設(shè)計成用于各種目的。比如，一個視頻混頻器在測量多個不同視頻流中各人的單獨(dú)影像后，將它們組合成一個單一視頻流來模擬群組場景。又如，在只用IP/UDP和只用ST_II的兩個主機(jī)群之間通過轉(zhuǎn)換建立連接。再如，在沒有重新同步或混頻時，用packet-by-packet編碼轉(zhuǎn)換來自各個獨(dú)立源的視頻流?；祛l器和轉(zhuǎn)換器的操作細(xì)節(jié)見章節(jié)7。
2.4 分層編碼（Layered Encodings）
為了匹配接收方的能力（容量）以及適應(yīng)網(wǎng)絡(luò)擁塞，多媒體應(yīng)用程序應(yīng)當(dāng)能夠調(diào)整其傳輸速率。許多應(yīng)用實(shí)現(xiàn)把調(diào)適傳輸速率的責(zé)任放在源端。這種做法在多播傳輸中并不好，因為不同接收方對帶寬存在著沖突性需求。這經(jīng)常導(dǎo)致最小公分母的場景，網(wǎng)格中最小的管道支配了全部實(shí)況多媒體“廣播”的質(zhì)量和保真度。
相反地，可以把分層編碼和分層傳輸系統(tǒng)組合起來，從而把調(diào)適速率的責(zé)任放在接收端。在IP多播之上的RTP上下文中，對一個橫跨多個RTP會話（每個會話在獨(dú)自多播組上開展）的分級表示信號(a hierarchically represented signal)，源能夠把它的分層（layers)分割成條。 接收方僅需合并適當(dāng)?shù)亩嗖ソM子集，就能適應(yīng)異種網(wǎng)絡(luò)和控制接收帶寬。
RTP分層編碼的細(xì)節(jié)在章節(jié)6.3.9，8.3和11中給出。
3. 定義（definitions)
RTP負(fù)載（RTP payload）：通過RTP傳輸?shù)陌械臄?shù)據(jù)，例如，音頻樣本或壓縮好的視頻數(shù)據(jù)。負(fù)載格式與解釋不在本文討論范圍。
RTP包（RTP packet）：一種數(shù)據(jù)包，其組成部分有：一個固定RTP報頭，一個可能為空的作用源（contributing sources）列表（見下文），以及負(fù)載數(shù)據(jù)。一些下層協(xié)議可能要求對RTP包的封裝進(jìn)行定義。一般地，下層協(xié)議的一個包包含一個RTP包，但若封裝方法允許，也可包含數(shù)個RTP包（見章節(jié)11）。
RTCP包（RTCP packet）：一種控制包，其組成部分有：一個類似RTP包的固定報頭，后跟一個結(jié)構(gòu)化的部分，該部分具體元素依不同RTCP包的類型而定。格式的定義見章節(jié)６。一般地，多個RTCP包將在一個下層協(xié)議的包中以合成RTCP包的形式傳輸；這依靠RTCP包的固定報頭中的長度字段來實(shí)現(xiàn)。
端口（Port）：“傳輸協(xié)議用來在同一主機(jī)中區(qū)分不同目的地的一種抽象。TCP/IP協(xié)議使用正整數(shù)來標(biāo)識不同端口。”[12] OSI傳輸層使用的傳輸選擇器（TSEL,the transport selectors）等同于這里的端口。RTP需依靠低層協(xié)議提供的多種機(jī)制，如“端口”用以多路復(fù)用會話中的RTP和RTCP包。
傳輸?shù)刂?span>(Transport address)：是網(wǎng)絡(luò)地址與端口的結(jié)合，用來標(biāo)識一個傳輸層次的終端，例如一個IP地址與一個UDP端口。包是從源傳輸?shù)刂钒l(fā)送到目的傳輸?shù)刂贰?/font>
RTP媒體類型（RTP media type）：一個RTP媒體類型是一個單獨(dú)RTP會話所載有的負(fù)載類型的集合。RTP配置文件把RTP媒體類型指派給RTP負(fù)載類型。
多媒體會話（Multimedia session）：在一個參與者公共組中，并發(fā)的RTP會話的集合。例如，一個視頻會議（為多媒體會話）可能包含一個音頻RTP會話和一個視頻RTP會話。
RTP會話（RTP session）：一群參與者通過RTP進(jìn)行通信時所產(chǎn)生的關(guān)聯(lián)。一個參與者可能同時參與多個RTP會話。在一個多媒體會話中，除非編碼方式把多種媒體多路復(fù)用到一個單一數(shù)據(jù)流中，否則每種媒體都將使用各自的RTCP包，通過單獨(dú)的RTP會話來傳送。通過使用不同的目的傳輸?shù)刂穼Γㄒ粋€網(wǎng)絡(luò)地址加上一對分別用于RTP和RTCP的端口，構(gòu)成了一個傳輸?shù)刂穼Γ﹣斫邮詹煌臅挘瑓⑴c者能把多個RTP會話區(qū)隔開來。單個RTP會話中的所有參與者，可能共享一個公用目的傳輸?shù)刂穼?，比如IP多播的情況；也可能各自使用不同的目的傳輸?shù)刂穼Γ热鐐€體單播網(wǎng)絡(luò)地址加上一個端口對。對于單播的情況，參與者可能使用相同端口對來收聽其他所有參與者，也可能對來其他每個參與者使用不同的端口對來收聽。
RTP會話間相互區(qū)別的特征，在于每個RTP會話都維護(hù)一個用于SSRC標(biāo)識符的獨(dú)立完整的空間。RTP會話所包含的參與者組，由能接收SSRC標(biāo)識符的參與者組成，這些SSRC標(biāo)識符由RTP（同步源或作用源）或RTCP中的任意參與者傳遞。例如，考慮下述情況，用單播UDP實(shí)現(xiàn)的三方會議，每方都用不同的端口對來收聽其他兩方。如果收到一方的數(shù)據(jù)，就只把RTCP反饋發(fā)送給那一方，則會議就相當(dāng)于由三個單獨(dú)的點(diǎn)到點(diǎn)RTP會話構(gòu)成；如果收到一方的數(shù)據(jù)，卻把RTCP反饋發(fā)送另兩方，則會議就是由一個多方（multi-party)RTP會話構(gòu)成。后者模擬了三方間進(jìn)行IP多播通信時的行為。
RTP框架允許上述規(guī)定發(fā)生變化，但一個特定的控制協(xié)議或者應(yīng)用程序在設(shè)計時常常對變化作出約束。
同步源(SSRC，Synchronization source)：RTP包流的源，用RTP報頭中32位數(shù)值的SSRC標(biāo)識符進(jìn)行標(biāo)識，使其不依賴于網(wǎng)絡(luò)地址。一個同步源的所有包構(gòu)成了相同計時和序列號空間的一部分，這樣接收方就可以把一個同步源的包放在一起，來進(jìn)行重放。舉些同步源的例子，像來自同一信號源的包流的發(fā)送方，如麥克風(fēng)、攝影機(jī)、RTP混頻器（見下文）就是同步源。一個同步源可能隨著時間變化而改變其數(shù)據(jù)格式，如音頻編碼。SSRC標(biāo)識符是一個隨機(jī)選取的值，它在特定的RTP會話中是全局唯一（globally unique）的（見章節(jié)8）。參與者并不需要在一個多媒體會議的所有RTP會話中，使用相同的SSRC標(biāo)識符；SSRC標(biāo)識符的綁定通過RTCP（見章節(jié)6.5.1）。如果參與者在一個RTP會話中生成了多個流，例如來自多個攝影機(jī)，則每個攝影機(jī)都必須標(biāo)識成單獨(dú)的同步源。
作用源（CSRC，Contributing source )：若一個RTP包流的源，對由RTP混頻器生成的組合流起了作用，則它就是一個作用源。對特定包的生成起作用的源，其SSRC標(biāo)識符組成的列表，被混頻器插入到包的RTP報頭中。這個列表叫做CSRC表。相關(guān)應(yīng)用的例子如，在音頻會議中，混頻器向所有的說話人（talker)指出，誰的話語（speech)將被組合到即將發(fā)出的包中，即便所有的包都包含在同一個（混頻器的）SSRC標(biāo)識符中，也可讓聽者（接收者）可以清楚誰是當(dāng)前說話人。
終端系統(tǒng)（End system)：一種應(yīng)用程序，它產(chǎn)生發(fā)送出的RTP包中內(nèi)容，或者使用接收到的RTP包中內(nèi)容。在一個特定的RTP會話中，一個終端系統(tǒng)可以扮演一個或多個同步源角色，但通常是一個。
混頻器（Mixer)：一種中間系統(tǒng)，它從一個或多個源中接收RTP包，可能改變其數(shù)據(jù)格式，再按某種方式把這些包組合成一個新的包，然后轉(zhuǎn)發(fā)出去。由于多個輸入源的計時一般不會同步，所以混頻器會對各個流的計時作出調(diào)整，并為組合流生成一個新的計時。因此，混頻器將被標(biāo)識成它所產(chǎn)生所有數(shù)據(jù)包的同步源。
轉(zhuǎn)換器（Translator)：一種中間系統(tǒng)，它轉(zhuǎn)發(fā)RTP包而不改變各包的同步源標(biāo)識符。轉(zhuǎn)換器的例子如下：不作混頻地轉(zhuǎn)變編碼的設(shè)備，把多播復(fù)制到單播的重復(fù)裝置，以及防火墻里應(yīng)用層次的過濾器。
監(jiān)視器(Monitor)：一種應(yīng)用程序，它接收RTP會話參與者所發(fā)送的RTCP包，特別是接收報告（reception report)，而且對當(dāng)前服務(wù)質(zhì)量進(jìn)行評估，評估結(jié)果用于分配監(jiān)視任務(wù)，故障診斷和長期統(tǒng)計。監(jiān)視器常常被內(nèi)建到參與會話的應(yīng)用程序中，但也可以是一個的獨(dú)立的應(yīng)用程序——不參加會話、也不發(fā)送或接收RTP數(shù)據(jù)包（因為它們在不同的端口上）。這些被稱作第三方監(jiān)視器。還有一種情況也是可以接受的，第三方監(jiān)視器只接收但不發(fā)送數(shù)據(jù)包，或者另外地算入到會話中。
非RTP途徑（Non-RTP means)：為提供一個可用的服務(wù)，可能還需要其他的協(xié)議和機(jī)制。特別地，對多媒體會議來說，一個控制協(xié)議可以發(fā)布多播地址，發(fā)布加密密鑰，協(xié)商所用的加密算法，以及為沒有預(yù)定義負(fù)載類型值的格式，建立負(fù)載類型值和其所代表的負(fù)載格式之間的動態(tài)映射。其他協(xié)議的例子如下：會話初始化協(xié)議（SIRFC3261[13]），ITU推薦的H.323[14]，還有使用SDP(RFC2327[15])的應(yīng)用程序，如RTSP(RFC 2326[16]). 對于簡單的應(yīng)用程序，電子郵件或者會議數(shù)據(jù)庫也可能用到。對這些協(xié)議和機(jī)制的詳細(xì)說明已經(jīng)超出了本文檔的討論范圍。
5 RTP數(shù)據(jù)傳輸協(xié)議
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個字節(jié)出現(xiàn)在每個RTP包中，僅僅在被混合器插入時，才出現(xiàn)CSRC識別符列表。這些域有以下意義：
版本(V)：2比特 此域定義了RTP的版本。此協(xié)議定義的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"語音工具使用的協(xié)議中。)
填充(P)：1比特 若填料比特被設(shè)置，則此包包含一到多個附加在末端的填充比特，填充比特不算作負(fù)載的一部分。填充的最后一個字節(jié)指明可以忽略多少個填充比特。填充可能用于某些具有固定長度的加密算法，或者用于在底層數(shù)據(jù)單元中傳輸多個RTP包。
擴(kuò)展(X)：1比特 若設(shè)置擴(kuò)展比特，固定頭(僅)后面跟隨一個頭擴(kuò)展。
CSRC計數(shù)(CC)：4比特 CSRC計數(shù)包含了跟在固定頭后面CSRC識別符的數(shù)目。
標(biāo)志(M)：1比特 標(biāo)志的解釋由具體協(xié)議規(guī)定。它用來允許在比特流中標(biāo)記重要的事件，如幀邊界。
負(fù)載類型(PT)：7比特 此域定義了負(fù)載的格式，由具體應(yīng)用決定其解釋。協(xié)議可以規(guī)定負(fù)載類型碼和負(fù)載格式之間一個默認(rèn)的匹配。其他的負(fù)載類型碼可以通過非RTP方法動態(tài)定義。RTP發(fā)送端在任意給定時間發(fā)出一個單獨(dú)的RTP負(fù)載類型；此域不用來復(fù)用不同的媒體流。
序列號（sequence number）：16比特 每發(fā)送一個RTP數(shù)據(jù)包，序列號加1，接收端可以據(jù)此檢測丟包和重建包序列。序列號的初始值是隨機(jī)的(不可預(yù)測)，以使即便在源本身不加密時(有時包要通過翻譯器，它會這樣做)，對加密算法泛知的普通文本攻擊也會更加困難。
時間戳（timestamp） 32比特時間戳反映了RTP數(shù)據(jù)包中第一個字節(jié)的采樣時間。時鐘頻率依賴于負(fù)載數(shù)據(jù)格式，并在描述文件（profile）中進(jìn)行描述。也可以通過RTP方法對負(fù)載格式動態(tài)描述。
如果RTP包是周期性產(chǎn)生的，那么將使用由采樣時鐘決定的名義上的采樣時刻，而不是讀取系統(tǒng)時間。例如，對一個固定速率的音頻，采樣時鐘將在每個周期內(nèi)增加1。如果一個音頻從輸入設(shè)備中讀取含有160個采樣周期的塊，那么對每個塊，時間戳的值增加160。
時間戳的初始值應(yīng)當(dāng)是隨機(jī)的，就像序號一樣。幾個連續(xù)的RTP包如果是同時產(chǎn)生的。如：屬于同一個視頻幀的RTP包，將有相同的序列號。
不同媒體流的RTP時間戳可能以不同的速率增長。而且會有獨(dú)立的隨機(jī)偏移量。因此，雖然這些時間戳足以重構(gòu)一個單獨(dú)的流的時間，但直接比較不同的媒體流的時間戳不能進(jìn)行同步。對于每一個媒體，我們把與采樣時刻相關(guān)聯(lián)的RTP時間戳與來自于參考時鐘上的時間戳（NTP）相關(guān)聯(lián)。因此參考時鐘的時間戳就了數(shù)據(jù)的采樣時間。（即：RTP時間戳可用來實(shí)現(xiàn)不同媒體流的同步，NTP時間戳解決了RTP時間戳有隨機(jī)偏移量的問題。）參考時鐘用于同步所有媒體的共同時間。這一時間戳對（RTP時間戳和NTP時間戳），用于判斷RTP時間戳和NTP時間戳的對應(yīng)關(guān)系，以進(jìn)行媒體流的同步。它們不是在每一個數(shù)據(jù)包中都被發(fā)送，而在發(fā)送速率更低的RTCP的SR（發(fā)送者報告）中。
如果傳輸?shù)臄?shù)據(jù)是存貯好的，而不是實(shí)時采樣等到的，那么會使用從參考時鐘得到的虛的表示時間線（virtual presentation timeline）。以確定存貯數(shù)據(jù)中的每個媒體下一幀或下一個單元應(yīng)該呈現(xiàn)的時間。此種情況下RTP時間戳反映了每一個單元應(yīng)當(dāng)回放的時間。真正的回放將由接收者決定。
SSRC：32比特 用以識別同步源。標(biāo)識符被隨機(jī)生成，以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符。盡管多個源選擇同一個SSRC識別符的概率很低，所有RTP實(shí)現(xiàn)工具都必須準(zhǔn)備檢測和解決沖突。若一個源改變本身的源傳輸?shù)刂?，必須選擇新的SSRC識別符，以避免被當(dāng)作一個環(huán)路源。
CSRC列表：0到15項，每項32比特 CSRC列表識別在此包中負(fù)載的所有貢獻(xiàn)源。識別符的數(shù)目在CC域中給定。若有貢獻(xiàn)源多于15個，僅識別15個。CSRC識別符由混合器插入，并列出所有貢獻(xiàn)源的SSRC識別符。例如語音包，混合產(chǎn)生新包的所有源的SSRC標(biāo)識符都被列出，以在接收端處正確指示參與者。
5.3.1 RTP頭擴(kuò)展
RTP提供擴(kuò)展機(jī)制以允許實(shí)現(xiàn)個性化：某些新的與負(fù)載格式獨(dú)立的功能要求的附加信息在RTP數(shù)據(jù)包頭中傳輸。設(shè)計此方法可以使其它沒有擴(kuò)展的交互忽略此頭擴(kuò)展。RTP頭擴(kuò)展的格式如下圖所示。
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頭中的擴(kuò)展比特位置1，則一個長度可變的頭擴(kuò)展部分被加到RTP固定頭之后。頭擴(kuò)展包含16比特的長度域，指示擴(kuò)展項中32比特字的個數(shù)，不包括4個字節(jié)擴(kuò)展頭(因此零是有效值)。RTP固定頭之后只允許有一個頭擴(kuò)展。為允許多個互操作實(shí)現(xiàn)獨(dú)立生成不同的頭擴(kuò)展，或某種特定實(shí)現(xiàn)有多種不同的頭擴(kuò)展，擴(kuò)展項的前16比特用以識別標(biāo)識符或參數(shù)。這16比特的格式由具體實(shí)現(xiàn)的上層協(xié)議定義。基本的RTP說明并不定義任何頭擴(kuò)展本身。
6 RTP控制協(xié)議RTCP
RTP控制協(xié)議(RTCP)向會議中所有成員周期性發(fā)送控制包。它使用與數(shù)據(jù)包相同的傳輸機(jī)制。底層協(xié)議必須提供數(shù)據(jù)包和控制包的復(fù)用，例如用不同的UDP端口。RTCP提供以下四個功能：
○基本功能是提供數(shù)據(jù)傳輸質(zhì)量的反饋。這是RTP作為一種傳輸協(xié)議的主要作用，它與其他協(xié)議的流量和擁塞控制相關(guān)。反饋可能對自適應(yīng)編碼有直接作用，并且IP組播的實(shí)驗表明它對于從接收端得到反饋信息以診斷傳輸故障也有決定性作用。向所有成員發(fā)送接收反饋可以使"觀察員"評估這些問題是局部的還是全局的。利用類似多點(diǎn)廣播的傳輸機(jī)制，可以使某些實(shí)體，諸如沒有加入會議的網(wǎng)絡(luò)業(yè)務(wù)觀察員，接收到反饋信息并作為第三方監(jiān)視員來診斷網(wǎng)絡(luò)故障。反饋功能通過RTCP發(fā)送者和接收者報告實(shí)現(xiàn)。
○RTCP為每個RTP源傳輸一個固定的識別符，稱為規(guī)范名（CNAME）。由于當(dāng)發(fā)生沖突或程序重啟時SSRC可能改變，接收者要用CNAME來跟蹤每個成員。接收者還要用CNAME來關(guān)聯(lián)一系列相關(guān)RTP會話中來自同一個成員的多個數(shù)據(jù)流，例如同步語音和圖像。
○前兩個功能要求所有成員都發(fā)送RTCP包，因此必須控制速率以使RTP成員數(shù)可以逐級增長。通過讓每個成員向所有成員發(fā)送控制包，各個成員都可以獨(dú)立地觀察會議中所有成員的數(shù)目。此數(shù)目可以用來估計發(fā)包速率。
○第四個可選的功能是傳輸最少的會議控制信息，例如在用戶接口中顯示參與的成員。這最可能在"松散控制"的會議中起作用，在"松散控制"會議里，成員可以不經(jīng)過資格控制和參數(shù)協(xié)商而加入或退出會議。RTCP作為一個延伸到所有成員的方便通路，必須要支持具體應(yīng)用所需的所有控制信息通信。
○在RTP用于IP多點(diǎn)廣播時，功能1-3是強(qiáng)制的，在所有情況下都推薦使用。建議RTP應(yīng)用開發(fā)商避免使用只能用于單向廣播而不能擴(kuò)充到多用戶的方法。
6.1 RTCP包格式
這部分定義了幾個RTCP包類型，可以傳送不同的控制信息：
○SR：發(fā)送者報告，描述作為活躍發(fā)送者成員的發(fā)送和接收統(tǒng)計數(shù)字；
○RR：接收者報告，描述非活躍發(fā)送者成員的接收統(tǒng)計數(shù)字；
○SDES：源描述項，其中包括規(guī)范名CNAME。
○BYE：表明參與者將結(jié)束會話。
○APP：應(yīng)用描述功能。
在本文中將詳細(xì)介紹SR和RR。
每個RTCP包的開始部分是與RTP數(shù)據(jù)包相類似的固定部分，隨后是一塊結(jié)構(gòu)化單元，它隨負(fù)載類型不同長度發(fā)生變化，但是總以32比特終止。對齊要求和長度域使RTCP包可"堆棧"，即可以將多個RTCP包形成一個復(fù)合RTCP包，在底層協(xié)議(如UDP)中，通常都是將復(fù)合包作為一個包傳輸?shù)摹?
復(fù)合包中的每個RTCP單包可以單獨(dú)處理，而無需考慮包復(fù)合的順序。然而，為了實(shí)現(xiàn)某些協(xié)議功能，添加以下限制：
○接收數(shù)據(jù)的統(tǒng)計信息(在SR或RR中)。只要帶寬允許應(yīng)盡可能經(jīng)常的發(fā)送，以達(dá)到統(tǒng)計數(shù)字的最大分辨率。因此每個周期發(fā)送的RTCP包必須包含一個報告包。
○新的參與者需要盡快接收一個源的規(guī)范名以識別數(shù)據(jù)源并與媒體建立會話。因此，每個包中必須包含源描述項中的規(guī)范名。除非復(fù)合包進(jìn)行了分割以進(jìn)行部分加密（見9.1節(jié)的描述）。
○必須限制首次在復(fù)合包中出現(xiàn)的包類型的數(shù)目，以增加在第一個字中常數(shù)比特的數(shù)目，這樣可以增加RTCP包的有效性，以區(qū)分誤傳的RTP包和其他無關(guān)的包。因此，所有RTCP包必須以復(fù)合包的形式發(fā)送。復(fù)合包中至少有兩個單個的RTCP包。具有以下格式：
○加密前綴：當(dāng)且僅當(dāng)復(fù)合包被加密時，對每個RTCP復(fù)合包加32比特的前綴。
○SR或RR：復(fù)合包中的第一個RTCP包必須是一個報告包。即使沒有數(shù)據(jù)發(fā)送和接收，此時發(fā)送空的RR包，或者復(fù)合包中其他的唯一包是BYE包，也必須發(fā)送報告包。
○附加的RR：若被報告的接收統(tǒng)計源數(shù)目超過SR/RR包中最大允許的31個，附加的RR必須跟在最初的報告包后面。
○源描述SDES
○BYE或APP包
每個RTP參與者在一個報告間隔內(nèi)應(yīng)只發(fā)送一個RTCP復(fù)合包，以便正確估計每個參與者的RTCP帶寬。除非像9.1節(jié)描述的情況——把一個RTCP復(fù)合包分割以進(jìn)行加密。如果數(shù)據(jù)源的個數(shù)太多，以至于不能把所有的RR包都放到同一個RTCP包中而不超過網(wǎng)絡(luò)路徑的最大傳輸單元（maximum transport unit MTU），那么可在每個間隔中發(fā)送其中的一部分包。在多個發(fā)送間隔中，所有的包應(yīng)該被等概率的選中。這樣就可以報告所有數(shù)據(jù)源的接收數(shù)據(jù)的情況。如果一個RTCP復(fù)合包的長度超過了網(wǎng)絡(luò)路徑的MTU，則它應(yīng)當(dāng)被分割為多個更短的RTCP包來傳輸。這不會影響對RTCP帶寬的估計，因為每一個復(fù)合包至少代表了一個參與者。要注意的是每個RTCP復(fù)合包必須以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復(fù)合包舉例
6.2 RTCP傳輸時間間隔
RTP被設(shè)計為允許應(yīng)用自動適應(yīng)不同的規(guī)模的會話――從幾個參與者到幾千個參與者的會話。
對每一個會話，我們假定數(shù)據(jù)傳輸受到一個上限――會話帶寬的限制。會話帶寬分配給所有的參與者。這個帶寬會被預(yù)留，并由網(wǎng)絡(luò)所限制。如果沒有預(yù)留，基于環(huán)境的其他約束將會確定合理的最大帶寬供會話使用，這就是會話帶寬。會話帶寬在一定程度上獨(dú)立于媒體編碼，但媒體編碼卻依賴于會話帶寬。
在涉及媒體應(yīng)用時，會話帶寬參數(shù)最好由一個會話控制應(yīng)用提供。但媒體應(yīng)用可能設(shè)置一個默認(rèn)參數(shù)。此參數(shù)由單個發(fā)送者選擇的編碼方式的數(shù)據(jù)帶寬算出。會話管理可能會基于多播范圍的規(guī)則或其他標(biāo)準(zhǔn)確定帶寬限制。所有的參與者應(yīng)使用相同的會話帶寬值以保證計算出相同的RTCP間隔。
控制傳輸帶寬應(yīng)當(dāng)是會話帶寬的一小部分，這部分所占總的會話帶寬的百分比應(yīng)是已知的。一小部分：傳輸協(xié)議的首要功能是傳輸數(shù)據(jù)；已知：控制傳輸帶寬可以被放進(jìn)帶寬描述中提供給資源預(yù)留協(xié)議，并且使每個參與者都可以獨(dú)立的計算出他所占有的帶寬份額。
控制傳輸帶寬作為額外的一部分加入到會話帶寬中。建議RTCP控制傳輸帶寬為RTCP會話帶寬的5%。其中的1/4分配給發(fā)送者；當(dāng)發(fā)送者的比例超過所有參與者的1/4時，其RTCP控制帶寬相應(yīng)增加。所有的會話參與者必須使用相同的常數(shù)（以上提到的百分比），以便計算出相同的發(fā)送時間間隔。這些常數(shù)應(yīng)在一個特殊的描述文件中確定。
計算出的RTCP復(fù)合包的發(fā)送時間間隔應(yīng)該有一個下限，以免參與者數(shù)量較少時大量發(fā)送RTCP包。這也使網(wǎng)絡(luò)暫時斷開時，發(fā)送間隔不會太小。在應(yīng)用開始時，一個延遲應(yīng)加到第一個的TCP復(fù)合包發(fā)送之前，以便從其他參與者接收RTCP復(fù)合包。這樣，發(fā)送時間間隔能更快的收斂到正確的值。這個延遲可以設(shè)為最小時間間隔的一半。固定的時間間隔建議為5秒。
一個實(shí)現(xiàn)可能使RTCP最小發(fā)送時間間隔與會話帶寬參數(shù)成比例。則應(yīng)滿足下列約束：
○對多播會話，只有活動的數(shù)據(jù)發(fā)送者使用減小的最小化的值計算RTCP復(fù)合包的發(fā)送時間間隔。
○對單播會話，減小的值也可能被不是活動的數(shù)據(jù)發(fā)送者使用，發(fā)送初始的RTCP復(fù)合包之前的延遲可能是0。
○對所有會話，在計算參與者的離開時間時，這個固定最小值會被用到。因此，不使用減小的值進(jìn)行RTCP包的發(fā)送，就不會被其他參與者提前宣布超時。
○減小的最小時間間隔建議為：360/sb(秒)，其中sb：會話帶寬（千字節(jié)/秒）。當(dāng)sb>72kb/s時，最小時間間隔將小于5s。
6.3節(jié)所描述的算法和附錄A.7將實(shí)現(xiàn)本節(jié)列出的目標(biāo)：
○計算出的RTCP包的時間間隔與組中參與者的人數(shù)成正比。（參與者越多，發(fā)送時間間隔越長，每個參與者占有的RTCP帶寬越小）。
○RTCP包的（真實(shí)）時間間隔是計算出的時間間隔的0.5～1.5倍之間某個隨機(jī)的值，以避免所有的參與者意外的同步。
○RTCP復(fù)合包的平均大小將會被動態(tài)估計，包括所有發(fā)送的包和接收的包。以自動適應(yīng)攜帶的控制信息數(shù)量的變化。
○由于計算出的時間間隔依賴于組中的人數(shù)。因此，當(dāng)一個的用戶加入一個已經(jīng)存在的會話或者大量的用戶幾乎同時加入一個新的會話時，就會有意外的初始化效應(yīng)。這些新用戶將在開始時錯誤的估計組中的人數(shù)（估計太小）。因此他們的RTCP包的發(fā)送時間間隔就會太短。如果許多用戶同時加入一個會話，這個問題就很重要了。為了處理這處問題考慮了一種叫“時間重估”的算法。這個算法使得組中人數(shù)增加時，用戶能夠支持RTCP包的傳輸。
當(dāng)有用戶離開會話，不管是發(fā)送BYE包還是超時，組中的人數(shù)會減少。計算出的時間間隔也應(yīng)當(dāng)減少。因此，應(yīng)用“逆向重估”算法，使組中的成員更快的減少他們的時間間隔，以對組中的人數(shù)減少做出響應(yīng)。
○BYE包的處理和其他RTCP包的處理不同。BYE包的發(fā)送用到一個“放棄支持”算法。以避免大量的BYE包同時發(fā)送，使大量參與者同時離開會話。
這個算法適用于所有參與者都允許RTCP包的情況。此時，會話帶寬＝每個發(fā)送者的帶寬×會話中參與者的總?cè)藬?shù)。詳細(xì)算法見隨后小節(jié)，附錄A.7給出了算法的一個實(shí)現(xiàn)。
6.2.1維持會話成員的人數(shù)
當(dāng)偵聽到新的站點(diǎn)的時候，應(yīng)當(dāng)把他們加入計數(shù)。每一個登錄都應(yīng)在表中創(chuàng)建一條記錄，并以SSRC或CSRC進(jìn)行索引。新的登錄直到接收到含有SSRC的包或含有與此SSRC相聯(lián)系的規(guī)范名的SDES包才視為有效（見附錄A.1）。當(dāng)一個與SSRC標(biāo)識符相對RTCP BYE包收到時，登錄會被從表中刪除。除非一個“掉隊”的數(shù)據(jù)包到達(dá)，使登錄重新創(chuàng)建。
如果在幾個RTCP報告時間間隔內(nèi)沒有RTP或RTCP包收到，一個參與者可能標(biāo)記另外一個站點(diǎn)靜止，并刪除它。這是針對丟包提供的一個很強(qiáng)健的機(jī)制。所有站點(diǎn)對這個超時時間間隔乘子應(yīng)大體相同，以使這種超時機(jī)制正常工作。因此這個乘子應(yīng)在特別的描述文件中確定。
對于一個有大量參與者的會話，維持并存貯一個有所有參與者的SSRC及各項信息的表幾乎是不可能的因此，只可以只存貯SSRC。其他算法類似。關(guān)鍵的問題就是，任何算法都不應(yīng)當(dāng)?shù)凸澜M的規(guī)模，雖然它有可能被高估。
6.3 RTCP包的發(fā)送和接收規(guī)則
下面列出了如何發(fā)送RTCP包，當(dāng)接收到的TCP包時該干什么的規(guī)則。
為執(zhí)行規(guī)則，一個會話參與者就維持下列變量：
tp: RTCP包發(fā)送的最后時間。
tc: 當(dāng)前時間。
tn: 估計的下一個RTCP包要發(fā)送的時間。
pmembers: tn最后被重新計算時，會計的會話成員的人數(shù)。
members: 會話成員人數(shù)的當(dāng)前估計。
senders: 會話成員中發(fā)送者人數(shù)的估計。
rtcp_bw: 目標(biāo)RTCP帶寬。例如用于會話中所有成員的RTCP帶寬。單位bit/s。這將是程序開始時，指定給“會話帶寬”參數(shù)的一部分。
we_sent: 自當(dāng)前第二個前面的RTCP發(fā)送后，應(yīng)用程序又發(fā)送了數(shù)據(jù)，則此項為true。
avg_rtcp_size: 此參與者收到的和發(fā)送的RTCP復(fù)合包的平均大小。單位：bit。按6.2節(jié)，此大小包括底層傳輸層和網(wǎng)絡(luò)層協(xié)議頭。
initial: 如果應(yīng)用程序還未發(fā)送RTCP包，則標(biāo)記為true。
許多規(guī)則都用到了RTCP包傳輸?shù)?#8220;計算時間間隔”。此時間間隔將在隨后的小節(jié)描述。
6.3.1計算RTCP傳輸時間間隔
一個會話參與者包的平均發(fā)送時間間隔應(yīng)當(dāng)和所在會話組中人數(shù)成正比。這個間隔稱為計算時間間隔。它由上面提到的各個狀態(tài)參量結(jié)合起來計算得出。計算時間間隔T的計算如下：
1．（1）如果發(fā)送者人數(shù)≤會話總?cè)藬?shù)×25%。則T取決于此參與者是否是發(fā)送者（we_sent的值）；否則，發(fā)送者和接收者將統(tǒng)一處理。
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節(jié)所述，RTP描述文件可能用兩個獨(dú)立的參數(shù)（S，R）確定發(fā)送者與非發(fā)送者。此時，25%和75%只要相應(yīng)的換成S/(S+R),R/(S+R)即可。注意R＝0的情況。
2．如果initial為true(則未發(fā)送過RTCP包)，則設(shè)Tmin=2.5s;否則設(shè)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，補(bǔ)償時間重估算法，使之收斂到比計算出的平均RTCP帶寬小的一個值。
這個算法產(chǎn)生了一個隨機(jī)的計算時間間隔，并把至少25%的RTCP帶寬分配給發(fā)送者，其余的分給接收者。若發(fā)送者超過會話總?cè)藬?shù)的25%，此算法將把帶寬平均分給所有的參與者。
6.3.2初始化
一加入會話，參與者的各狀態(tài)參量初始化為：tp=0； tc=0； senders=0； pmembers=1； members=1； vw_sent=false； rtcp_bw:由會話帶寬參數(shù)的相應(yīng)部分得到；initial=true；avg_rtcp_size:初始化為應(yīng)用程序稍后將發(fā)送的RTCP包的可能大??；T：如6.3.1節(jié)；tn=T（這意味著，一個計時器將經(jīng)T時間后被喚醒）；應(yīng)用程序可以用任何它需要的方式實(shí)現(xiàn)計時器。
參與者把它自己的SSRC加到成員列表中。
6.3.3接收到的TP包或一個非BYE的RTCP包
當(dāng)收到一個參與者的RTP或RTCP包時，若其SSRC不在成員列表中，將其SSRC加入列表；若此參與者被確認(rèn)有效（如6.2.1節(jié)描述），就把列表中成員的值更新。對每個有效的RTP包中的CSRC執(zhí)行相同的過程。
當(dāng)收到一個參與者的RTP包時，若其SSRC不在發(fā)送者列表中，則將其SSRC加入發(fā)送者列表，更新相應(yīng)的值。
每收到一個RTCP復(fù)合包，avg_rtcp_size更新為avg_rtcp_size = 1/16 * packet_size + 15/16 * avg_rtcp_size??；其中packet_size是剛收到的RTCP復(fù)合包的大小。
6.3.4接收RTCP BYE包
除6.3.7小節(jié)描述的發(fā)送RTCP BYE包之外，如果收到一個RTCP BYE包，則檢測成員列表。若SSRC存在；先移除之，并更新成員的值。
另外，為使RTCP包的發(fā)送速率與組中人數(shù)變化更加協(xié)調(diào)，當(dāng)收到一個BYE包使得members的值pmembers時，下面的逆向重估算法應(yīng)當(dāng)執(zhí)行：
（1）tn的更新：tn = tc + ( members / pmembers ) * ( tn –tc )；
（2）tp的更新：tp = tc – ( members / pmembers ) * ( tc – tp )；下一個RTCP包將在時刻tn 被發(fā)送，比更新前更早一些。
（3）pmembers的更新：pmembers=members；
這個算法并沒有防止組的大小被錯誤的在短時間內(nèi)估計為0的情況。如：在一個較多人數(shù)的會話中，多數(shù)參與者幾乎同時離開而少數(shù)幾個參與者沒有離開的情況。這個算法并沒有使估計迅速返回正確的值。因為這種情況較罕見，且影響不大。
6.3.5 SSRC超時
在隨機(jī)的時間間隔中，一個參與者必須檢測其他參與者是否已經(jīng)超時。為此，對接收者（we_sent為false），要計算決定性時間間隔Td，如果從時刻Tc-M*Td(M為超時因子，默認(rèn)為5秒)開始，未發(fā)送過RTP或RTCP包，則超時。其SSRC將被從列表中移除，成員被更新。在發(fā)送者列表中也要進(jìn)行類似的檢測。發(fā)送者列表中，任何從時間tc-2T(在最后兩個RTCP報告時間間隔內(nèi))未發(fā)送RTP包的發(fā)送者，其SSRC從發(fā)送者列表中移除，列表更新。
如果有成員超時，應(yīng)該執(zhí)行6.3.4節(jié)中的逆向檢測算法。每個參與者在一個RTCP包發(fā)送時間間隔內(nèi)至少要進(jìn)行一次這樣的檢測。
6.3.6發(fā)送時鐘到時了
當(dāng)包傳輸?shù)陌l(fā)送時鐘到時，參與者執(zhí)行下列操作：
（1）按6.3.1節(jié)的辦法計算T。
（2）更新發(fā)送時鐘的定時時間，判斷是否發(fā)送RTCP包，更新pmembers。如圖：
tp=tc; tn=tc+T; initial=false;
|
avg_rtcp_size=1/16 * packet_size + 15/16 * avg_rtcp_size
|
6.3.7發(fā)送一個BTE包
當(dāng)一個參與者離開會話時，應(yīng)發(fā)送BYE包，通知其他參與者。為避免大量參與者同時離開系統(tǒng)時，大量BYE包的發(fā)送，若會話人數(shù)超過50，則參與者在要離開會話時，應(yīng)執(zhí)行下面的算法。這個算法實(shí)際上“篡奪”了一般可變成員的角色來統(tǒng)計BYE包。
?。?span>1）tp=tc ； members=1； pmembers=1； sinitial=1； we_sent=false； senders=0； rtcp_size:設(shè)置為將要發(fā)送的RTCP包大?。挥嬎?#8220;計算時間間隔”T；tn=tc+T；(BYE包預(yù)計在時刻tn被發(fā)送)。
(2)每當(dāng)從另外一個參與者接收到BYE包時，成員人數(shù)加1。不管此成員是否存在于成員列表中，也不管SSRC采樣何時使用及BYE包的SSRC是否包含在采樣之中。如果收到RTP包或甚的RTCP包（除BYE包之外的RTCP包），成員人數(shù)不增加。類似，只有在收到BYE包時，avg_rtcp_size才更新。當(dāng)RTP包到達(dá)時，發(fā)送者人數(shù)senders不更新，保持為0。
（3）在此基礎(chǔ)上，BYE包的傳輸服從上面規(guī)定的一般的RTCP包的傳輸。
（BYE包的傳輸，是專注于統(tǒng)計會話中發(fā)送BYE包的人數(shù)的。）
這允許BYE包被立即發(fā)送，并控制總的帶寬使用。在最壞情況下上，這可能會使RTCP控制包使用兩倍于正常水平的帶寬，達(dá)到10%――其中5%給BYE包的RTCP包，其余5%給BYE包。
一個參與者若不想用上面的機(jī)制進(jìn)行RTCP包的發(fā)送，可以直接離開會話，而根本不發(fā)送BYE包。他會被其他參與者因超時而刪除。
一個參與者想離開會話時，如果組中的人數(shù)會計數(shù)目小于50，則參與者可以直接發(fā)送BYE包。
另外，一個從未發(fā)送過RTP或RTCP包的參與者，在離開會話時，不能發(fā)送BYE包。
6.3.8更新we_sent變量
如果一個參與者最近發(fā)過RTP包，則變量we_sent值為true,否則為false。相同的機(jī)制可以管理發(fā)送者中的其他參與者。如果參與者發(fā)送了TPT包而此時，其對應(yīng)的we_sent變量值為false,則就把它自己加到發(fā)送者列表中，并設(shè)置其we_sent變量為true。6.3.4節(jié)中描述的逆向重估算法（reverse reconsideration algorithm）應(yīng)當(dāng)被執(zhí)行。以可能減少發(fā)送SR包前的延遲。每次發(fā)送一個RTP包，其相應(yīng)的傳輸時間都會記錄在表中。一般發(fā)送者的超時算法應(yīng)用到參與者自身：從tc-2T時開始，一直沒有發(fā)送RTP包，則此參與者就從發(fā)送者列表中將其自身移除，減少發(fā)送者總數(shù)，并設(shè)置we_sent變量值為false。
6.3.9源描述帶寬的分配
這里定義了幾種源描述項，強(qiáng)制性的規(guī)范名（CNAME）除外。例如，個人姓名（NAME）和電子郵件地址（EMAIL）。它也提供了方法定義新的RTCP包的類型。應(yīng)用程序在給這些額外信息分配帶寬時應(yīng)額外小心。因為這會降低接收報告及CNAME的發(fā)送速率，可能破壞協(xié)議發(fā)揮作用。建議分配給一個參與者用于傳輸這些額外信息的帶寬不超過總的RTCP帶寬的20%。另外，并非所有的源描述項都將包含進(jìn)每一個應(yīng)用程序中。包含進(jìn)應(yīng)用程序的源描述項應(yīng)根據(jù)其用途分配給相應(yīng)的帶寬百分比。建議不要動態(tài)會計這些百分比，而應(yīng)根據(jù)一個源描述項的典型長度將所占帶寬的百分比的轉(zhuǎn)化為報告間隔。
例如，一個應(yīng)用程序可能僅發(fā)送CNAME，NAME和EMAIL，而不需要其他項。NAME可能會比EMAIL給予更高的優(yōu)先級。因為NAME可能會在應(yīng)用程序的用戶界面上持續(xù)顯示，但EMAIL可能僅僅在需要時才會顯示。在每一個RTCP時間間隔內(nèi)，一個包含CNAME項的SDES包和一個RR包將會被發(fā)送。最小的會話時間間隔平均為5秒。每經(jīng)過3個時間間隔（15秒），一個額外的項將會包含進(jìn)這個SDES包中。7/8的時間是NAME項，每經(jīng)過8個這樣的間隔（15s*8=2min）,將會是EMAIL項。
當(dāng)多個會話考慮使用一個通用的規(guī)范名為每個參與者進(jìn)行綁定時，如在一個RTP會話組成的多媒體會議中，額外的SDES信息可能只在一次RTP會話中被發(fā)送。其余的會話將只發(fā)送CNAME。特別，這個辦法也應(yīng)該用在分層編碼的多個會話中。
6.4 發(fā)送者和接收者報告
RTP接收者利用RTCP報告包提供接收質(zhì)量反饋。根據(jù)接收者是否同時還是發(fā)送者，RTCP包采取兩種不同的形式。發(fā)送者報告(SR)和接收者報告(RR)格式中唯一的不同，除包類型碼之外，在于發(fā)送者報告包括20字節(jié)的發(fā)送者信息。
SR包和RR包都包括零到多個接收報告塊。針對該接收者發(fā)出上一個報告塊后接收到RTP包的起始同步源，每個源一個塊。報告不發(fā)送給CSRC列表中的貢獻(xiàn)源。每個接收報告塊提供從特定數(shù)據(jù)源接收到數(shù)據(jù)的統(tǒng)計信息。由于SR/RR包最多允許31個接收報告塊，故可以在最初的SR或RR包之后附加RR包，以包含從上一個報告以來的間隔內(nèi)收聽到的所有源的接收報告。如果數(shù)據(jù)源太多，致使若把所有的RR包放到同一個RTCP復(fù)合包中會超出網(wǎng)絡(luò)的MTU。那么就在一個周期內(nèi)選擇上面RR包的一部分以不超過MTU。這些RR包的選取應(yīng)讓各個包都有同等的幾率被取到。這樣在幾個發(fā)送周期間隔中，對所有的數(shù)據(jù)源就都發(fā)送接收報告了。
以下部分定義了兩種報告的格式。如果應(yīng)用程序需要其他信息，他們可以被擴(kuò)展。
6.4.1 SR：發(fā)送者報告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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
發(fā)送者報告包由3部分組成，若定義，可能跟隨第4個面向協(xié)議的擴(kuò)展部分。
第一部分，頭部，8字節(jié)長。該域有以下意義：
版本(V)：2比特 RTP版本識別符，在RTCP包內(nèi)的意義與RTP包中的相同。此協(xié)議中定義的版本號為2。
填充(P)：1比特 若設(shè)置填充比特，該RTCP包在末端包含一些附加填充比特，并不是控制信息的基本部分。填充的最后一個比特統(tǒng)計了多少個字節(jié)必須被忽略。填充可能會用于需要固定長度塊的加密算法。在復(fù)合RTCP包中，復(fù)合包作為一個整體加密，填料比特只能加在最后一個單個RTCP包的后面。
接收報告塊計數(shù)(RC)：5比特 該包中所含接收報告塊的數(shù)目。零值有效。
包類型(PT)：8比特 包含常數(shù)200，用以識別這個為SR包。
長度：16比特 該RTCP包的長度減1。其單位是32比特字，包括頭和任何填充字節(jié)。(偏移量1保證零值有效，避免了在掃描RTCP包長度時可能發(fā)生的無限循環(huán)，同時以32比特為單位避免了對以4為倍數(shù)的有效性檢測。)
SSRC：32比特 SR包發(fā)送者的同步源標(biāo)識符。
第二部分，發(fā)送者信息，20字節(jié)長。在每個發(fā)送者報告包中出現(xiàn)。它概括了從此發(fā)送者發(fā)出的數(shù)據(jù)傳輸情況。此域有以下意義：
NTP時間戳：64比特 指示了此報告發(fā)送時的背景時鐘（wallclock）時刻，它可以與從其它接收者返回的接收報告塊中的時間標(biāo)志結(jié)合起來，計算往返每個接收者所花的時間。接收者應(yīng)讓NTP時間戳的精度遠(yuǎn)大于其他時間戳的精度。時間戳測量的不確定性不可知，因此也無需指示。一個系統(tǒng)可能沒有背景時鐘的概念，而只有系統(tǒng)指定的時鐘，如系統(tǒng)時間（system uptime）。在這樣的系統(tǒng)中，此時鐘可以作為參考計算相對NTP時間戳。選擇一個公用的時名是非常重要的。這樣多個獨(dú)立的應(yīng)用都可以使用相同的時鐘。到2036年，相對和絕對NTP時間戳?xí)a(chǎn)生大的差異。到那時，我們希望不再需要相對時鐘。一個發(fā)送者，如果不用背景時鐘時間或逝去時間，可以設(shè)置此項為零。
RTP時間戳：32比特 與以上的NTP時間標(biāo)志對應(yīng)同一時刻。與數(shù)據(jù)包中的RTP時間戳具有相同的單位和偏移量。這個一致性可以用來讓NTP時間標(biāo)志已經(jīng)同步的源之間進(jìn)行媒體內(nèi)/間同步，還可以讓與媒體無關(guān)的接收者估計名義RTP時鐘頻率。注意在大多數(shù)情況下此時間戳不等于任何臨近的RTP包中的時間戳。RTP時間戳可以由相應(yīng)的NTP時間戳計算得到。依據(jù)的是“RTP時間戳計數(shù)器”和“在采樣時通過周期性檢測背景時鐘時間得到的實(shí)際時間”兩者之間的關(guān)系。
?。ㄔ?span>RTCP SR包中有NTP時間戳、RTP時間戳，它們可以計算背景時鐘和RTP時鐘之間的對應(yīng)關(guān)系，通過這個關(guān)系，可以由RTP數(shù)據(jù)包中的RTP時間戳計算也相應(yīng)的回放時刻。這樣就可以進(jìn)行多個流的同步了。之所以要有NTP時間戳，是因為不同流的RTP時間戳有不同的隨機(jī)偏移量，無法直接進(jìn)行同步：筆者注。）
發(fā)送的報文數(shù)：32比特 從開始傳輸?shù)酱薙R包產(chǎn)生時該發(fā)送者發(fā)送的RTP數(shù)據(jù)包總數(shù)。若發(fā)送者改變SSRC識別符，該計數(shù)器重設(shè)。
發(fā)送的字節(jié)文數(shù)：32比特 從開始傳輸?shù)酱薙R包產(chǎn)生時該發(fā)送者在RTP數(shù)據(jù)包發(fā)送的字節(jié)總數(shù)(不包括頭和填充)。若發(fā)送者改變SSRC識別符，該計數(shù)器重設(shè)。此域可以用來估計平均的負(fù)載數(shù)據(jù)發(fā)送速率。
第三部分：零到多個接收報告塊。塊數(shù)等于從上一個報告以來該發(fā)送者偵聽到的其它源（不包括自身）的數(shù)目。每個接收報告塊傳輸從某個同步源來的數(shù)據(jù)包的接收統(tǒng)計信息。若數(shù)據(jù)源因沖突而改變其SSRC標(biāo)識符，接收者重新設(shè)置統(tǒng)計信息。這些統(tǒng)計信息有：
SSRC_n(同步源標(biāo)識符)：32比特 在此接收報告塊中信息所屬源的SSRC標(biāo)識符。
丟包率：8比特 自從前一SR包或RR包發(fā)送以來，從SSRC_n傳來的RTP數(shù)據(jù)包的丟失比例。以定點(diǎn)小數(shù)的形式表示。該值定義為損失包數(shù)／期望接收的包數(shù)。若由于包重復(fù)而導(dǎo)致包丟失數(shù)為負(fù)值，丟包率設(shè)為零。注意在收到上一個包后，接收者無法知道以后的包是否丟失。如：若在上一個接收報告間隔內(nèi)從某個源發(fā)出的所有數(shù)據(jù)包都丟失，那么將不為此數(shù)據(jù)源發(fā)送接收報告塊。
累計包丟失數(shù)：24比特 從開始接收到現(xiàn)在，從源SSRC_n發(fā)到本源的RTP數(shù)據(jù)包的丟包總數(shù)。該值定義為：期望接收的包數(shù)－實(shí)際接收的包數(shù)。接收的包括復(fù)制的或遲到的。由于遲到的包不算作損失，在發(fā)生復(fù)制時丟包數(shù)可能為負(fù)值。期望接收的包數(shù)定義為：擴(kuò)展的上一接收序號(隨后定義)減去最初接收序號。
接收到的擴(kuò)展的最高序列號：32比特 低16比特包含從源SSRC_n來的最高接收序列號，高16比特用相應(yīng)的序列號周期計數(shù)器擴(kuò)展該序列號。注意在同一會議中的不同接收者，若啟動時間明顯不同，將產(chǎn)生不同的擴(kuò)展項。
到達(dá)間隔抖動：32比特 RTP數(shù)據(jù)包到達(dá)時刻統(tǒng)計方差的估計值。測量單位同時間戳單位，用無符號整數(shù)表達(dá)。到達(dá)時間抖動定義為一對包中接收者相對發(fā)送者的時間間隔差值的平均偏差(平滑后的絕對值)。如以下等式所示，該值等于兩個包相對傳輸時間的差值。相對傳輸時間是指：包的RTP時間戳和到達(dá)時刻接收者時鐘時間的差值。若Si是包i中的RTP時間戳，Ri是包i到達(dá)時刻（單位為：RTP時間戳單位）。對于兩個包i和j，D可以表示為 D(i，j)=(Rj-Sj)-(Ri-Si)；
到達(dá)時刻抖動可以在收到從源SSRC_n來的每個數(shù)據(jù)包i后連續(xù)計算。利用該包和前一包i-1的偏差D(按到達(dá)順序，而非序號順序)，根據(jù)公式J=J+(|D(i-1，i)|-J)/16計算。無論何時發(fā)送接收報告，都用當(dāng)前的J值。
此處描述的抖動計算允許與協(xié)議獨(dú)立的監(jiān)視器對來自不同實(shí)現(xiàn)的報告進(jìn)行有效的解釋。
上一SR報文 (LSR)：32比特 接收到的來自源SSRC_n的最新RTCP發(fā)送者報告(SR)的64位NTP時間標(biāo)志的中間32位。若還沒有接收到SR，該域值為零。
自上一SR的時間(DLSR)：32比特 是從收到來自SSRC_n的SR包到發(fā)送此接收報告塊之間的延時，以1/65536秒為單位。若還未收到來自SSRC_n的SR包，該域值為零。
假設(shè)SSRC_r為發(fā)出此接收報告塊的接收者。源SSRC_n可以通過記錄收到此接收報告塊的時刻A來計算到SSRC_r的環(huán)路傳輸時延。可以利用最新的SR時間標(biāo)志(LSR)計算整個環(huán)路時間A-LSR，然后減去此DLSR域得到環(huán)路傳輸?shù)臅r延。
如下圖所示。
[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)與發(fā)送者報告包基本相同，除了包類型域包含常數(shù)201和沒有發(fā)送者信息的5個字(NTP和RTP時間標(biāo)志和發(fā)送者包和字節(jié)計數(shù))。余下區(qū)域與SR包意義相同。若沒有發(fā)送和接收據(jù)報告，在RTCP復(fù)合包頭部加入空的RR包(RC=0)。
6.4.3發(fā)送者和接收者報告擴(kuò)展
如果有額外的關(guān)于發(fā)送者和接收者的信息要周期性的，描述文件（profile）應(yīng)該定義接收者報告和發(fā)送者報告描述文件擴(kuò)展。此時，應(yīng)采用這里的辦法，而不是定義另外的RTCP包。因為這種辦法需要的頭部信息更少。
擴(kuò)展部分是發(fā)送報告包和接收報告包的第四部分。如果有的話，應(yīng)緊跟在接收報告塊的后面。如果需要更多的發(fā)送者信息，它應(yīng)當(dāng)跟在發(fā)送者報告的開關(guān)，而不應(yīng)在報告中出現(xiàn)。如果要包含進(jìn)接收者的信息，它應(yīng)該以塊數(shù)組的方式放到接收報告塊的后面。即這些塊也應(yīng)被計入RC字段中。
6.4.4分析發(fā)送者和接收者報告
接收質(zhì)量反饋不僅對發(fā)送者有用，而且對于其它接收者和第三方監(jiān)視器也有作用。發(fā)送者可以基于反饋修正發(fā)送信息量；接收者可以判斷問題是本地的，區(qū)域內(nèi)的還是全局的；網(wǎng)絡(luò)管理者可以利用與協(xié)議無關(guān)的監(jiān)視器(只接收RTCP包而不接收相應(yīng)的RTP包)去評估多點(diǎn)傳送網(wǎng)絡(luò)的性能。
在發(fā)送者信息和接收者報告塊中都連續(xù)統(tǒng)計丟包數(shù)，因此可以計算任何兩個報告塊中的差別。在短時間和長時間內(nèi)都可以進(jìn)行測算。最近收到的兩個包之間差值可以評估當(dāng)前傳輸質(zhì)量。包中有NTP時間戳，可以用兩個報告間隔的差值計算傳輸速率。由于此時間間隔與數(shù)據(jù)編碼速率獨(dú)立，因此可以實(shí)現(xiàn)與編碼及協(xié)議獨(dú)立的質(zhì)量監(jiān)視。
一個例子是計算兩個報告間隔時間內(nèi)的丟包率。丟包率＝此間隔內(nèi)丟失的包／此間隔內(nèi)期望收到的包。如果此值與“丟失比例”字段中的值相同，說明包是連續(xù)的；若否，說明包不是連續(xù)的。間隔時間內(nèi)的丟包率／間隔時間＝每秒的丟包率。
從發(fā)送者信息中，第三方監(jiān)視器可以在一個時間間隔內(nèi)計算平均負(fù)載數(shù)據(jù)發(fā)送速率和平均發(fā)包速率，而無需考慮數(shù)據(jù)接收。兩個值的比就是平均負(fù)載大?。ㄆ骄總€包的負(fù)載大?。?。（即：平均負(fù)載大?。狡骄?fù)載數(shù)據(jù)發(fā)送速率／平均發(fā)包率。）若能假定丟包與包的大小無關(guān)，那么某個特定接收者收到的包數(shù)乘以平均負(fù)載大小(或相應(yīng)的包大小)就得出接收者可得到的外在吞吐量。
除了累計計數(shù)允許利用報告間差值進(jìn)行長期包損測量外，單個報告的“丟包比例”字段提供一個短時測量數(shù)據(jù)。當(dāng)會話規(guī)模增加到無法為所有接收者保存接收狀態(tài)信息，或者報告間隔變得足夠長以至于從一個特定接收者只能收到一個報告時，短時測量數(shù)據(jù)變得更重要。
到達(dá)間隔抖動字段提供另一個有關(guān)網(wǎng)絡(luò)阻塞的短時測量量。丟包反映了長期阻塞，抖動測量反映出短時間的阻塞。抖動測量可以在導(dǎo)致丟包前預(yù)示阻塞。由于到達(dá)間隔抖動字段僅僅是發(fā)送報告時刻抖動的一個快照，因此需要在一個網(wǎng)絡(luò)內(nèi)在一段時間內(nèi)分析來自某個接收者的報告，或者分析來自多個接收者的報告。
6.5源描述RTCP包
源描述（SDES）包由一個頭及0個或多個塊組成。每個塊都由塊中所標(biāo)識的數(shù)據(jù)源的標(biāo)識符及其后的各個描述構(gòu)成。
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包，混合器應(yīng)當(dāng)發(fā)送這個BYE包，并保持SSRC/CSRC不變。如果混合器關(guān)閉，應(yīng)向貢獻(xiàn)源列表中的所有SSRC，包括它自己的SSRC發(fā)送BYE包。BYE包可能會有選擇的包含8個字節(jié)的統(tǒng)計字段，其后跟上幾個字節(jié)的文本表明離開的原因。文本字符串編碼格式和SDES中描述的相同。
9安全性
底層協(xié)議將最終提供由RTP應(yīng)用要求的所有安全服務(wù)，包括真實(shí)性、完整性、保密性。這些服務(wù)在參考文獻(xiàn)[27]中的IP協(xié)議有詳細(xì)描述。由于使用RTP的初始音頻和視頻應(yīng)用在IP層可用之前就要求保密性服務(wù)，因此，隨后的一小節(jié)描述了使用RTP和RTCP的保密性服務(wù)。新的RTP應(yīng)用可以實(shí)現(xiàn)這里描述的RTP保密性服務(wù)，以用于向后兼容，也可以實(shí)現(xiàn)替代這里的安全服務(wù)。這種安全服務(wù)的RTP開銷是比較小的。因此，如果這項服務(wù)被將來的某種服務(wù)所替代，代價也是比較小的。
另一方面，RTP的其他服務(wù)，服務(wù)的其他實(shí)現(xiàn)及其他的算法可能會在將來定義。特別是為RTP負(fù)載提供可靠性的實(shí)時安全傳輸協(xié)議（ Secure Real-time Transport, SRTP）正在制定中。它可以使RTP頭部不被加密。這樣，鏈路層的頭部壓縮算法可以繼續(xù)使用。SRTP基于高級企業(yè)標(biāo)準(zhǔn)（Advanced Encryption Standard, AES）制定。它比這里描述的服務(wù)提供更強(qiáng)健的安全性。
密鑰和證書分配超出了本文的范圍。
9.1 保密性
保密性意味著只有特定的接收者才能夠?qū)κ盏降陌M(jìn)行解碼；對其他人，包里含有的都是無用信息。內(nèi)容的保密性通過加密來實(shí)現(xiàn)。
當(dāng)用這節(jié)指定的方法RTP、RTCP加密時，為了傳輸而封裝的所有字節(jié)將在底層的包中作為一個單元加密。對RTCP，每個單元在加密之前必須在前面附加一個32字節(jié)的隨機(jī)數(shù)。對RTP，不必在前面加前綴，而是讓序列號和時間戳字段都用隨機(jī)偏移量初始化。由于較差的隨機(jī)性質(zhì)。這其實(shí)是一個弱的初始化向量（initialization vector, IV）。另外，如果其后的SSRC字段被攻擊者得到，則加密算法將出現(xiàn)新的薄弱點(diǎn)。
對RTCP，一個應(yīng)用程序可能將RTCP復(fù)合包中的一個RTCP包分割成兩個RTCP復(fù)合包。其中，一個在發(fā)送時加密，另一個發(fā)送時不加密。例如，SDES信息可能會被加密，但接收者報告卻不加密，以適用于沒有密鑰的第三方監(jiān)視者。如圖4所示。源描述信息后必須附加沒有報告的空RR包，以滿足所有RTCP復(fù)合包必須以SR或RR包開頭的要求。SDES的CNAME字段包含在加密或未加密的包中之一即可，但并不都需要包含。相同的源描述信息不應(yīng)在兩個包中都攜帶。否則會使加密算法不安全。
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
#: SSRC identifier
圖4: 加密的和未加密的RTCP包
接收者加密的使用和正確密鑰的使用通過頭或負(fù)載的有效性檢查進(jìn)行確認(rèn)。RTP和RTCP頭的有效性檢查由附錄A.1和A.2給出。
為和RFC1889中RTP初始描述中的實(shí)現(xiàn)相一致。默認(rèn)的算法是鏈?zhǔn)郊用軌K模式（cipher block chaining (CBC) mode）下的數(shù)據(jù)加密算法，見RFC1423中1.1節(jié)的描述。除非出現(xiàn)由5.1節(jié)描述指明的填充多個字節(jié)的情況，否則，初始的隨機(jī)向量是0，因為隨機(jī)值由RTP頭或RTCP復(fù)合包的隨機(jī)前綴提供。CBC初始向量的細(xì)節(jié)見參考文獻(xiàn)[30]。支持本節(jié)的加密算法的實(shí)現(xiàn)也應(yīng)當(dāng)支持CBC下的DES算法。因為此算法可實(shí)現(xiàn)最大程度的交互可操作性。采用這種方法的原因是，因特網(wǎng)上通過音頻、視頻工具做實(shí)驗證明它簡便且有效。但DES被發(fā)現(xiàn)很容易被破解。建議用更強(qiáng)健的加密算法，例如三層DES加密算法來代替默認(rèn)的加密算法。另外，安全CBC模式要求每個包的第一個塊和一個隨機(jī)數(shù)求異或。對于RTCP，這通過在每個包前附加一個32位的隨機(jī)數(shù)實(shí)現(xiàn)。每個包的隨機(jī)數(shù)相互獨(dú)立。對RTP，時間戳和序列號將從附加的數(shù)值開始，但對連續(xù)的包，它們并不是被獨(dú)立的隨機(jī)化的。應(yīng)該注意到對RTP和RTCP，這種隨機(jī)性都受到了限制。高安全性的應(yīng)用應(yīng)當(dāng)考慮其他更加簡捷安全的方法。其他加密算法應(yīng)通過非RTP方法對一個會話動態(tài)指定。特別是基于AES的SRTP描述文件（見參考文獻(xiàn)[23]）將會是未來的一個不錯的選擇。以上描述了IP層或RTP層加密。作為它的替代，描述文件可以定義另外的負(fù)載類型以用于加密、編碼。這些編碼必須描述如何填充，以及編碼的其他方面如何控制。這種方法可以按照應(yīng)用的要求，只加密數(shù)據(jù)，不加密頭部。這可能對同時處理解密和解碼的硬件服務(wù)特別重要。這也可能對RTP和底層頭部的鏈路層的應(yīng)用很有用。既然頭部的加密已經(jīng)進(jìn)行了壓縮，負(fù)載（而不是地址）的保密性就足夠了。
9.2 真實(shí)性和信息完整性
真實(shí)性和信息完整性沒有在RTP層定義，因為這些服務(wù)離不開密鑰管理體系?？梢云谕鎸?shí)性和信息完整性將由底層協(xié)議完成。
10 擁塞控制
因特網(wǎng)上的所有傳輸協(xié)議都需要通過一些方法進(jìn)行地址擁塞控制（見參考文獻(xiàn)[31]），RTP也不例外。但由于RTP數(shù)據(jù)傳輸經(jīng)常缺少彈性（以固定的或控制好的速率產(chǎn)生包）。因此，RTP的擁塞控制方法和其他的傳輸協(xié)議，如TCP很不相同。在某種程度上，缺乏彈性意味著降低了擁塞的風(fēng)險。因為RTP流不會像TCP流那樣增長到消耗掉所有可用的帶寬程度。但是，缺乏彈性也意味著RTP流不能任意減小它在網(wǎng)絡(luò)上的負(fù)載量，以在出現(xiàn)擁塞時消除之。
由于RTP可能會在許多不同的情況下用于相當(dāng)廣的。因此就沒有一個全都通用一個擁塞控制機(jī)制。因此，擁塞控制應(yīng)當(dāng)在描述文件中定義。對于某些描述，可能加上可應(yīng)用性陳述以限制描述應(yīng)用在已設(shè)計消除擁塞的環(huán)境中。對其它描述，可能需要特別的方法，如基于RTCP反饋的自適應(yīng)數(shù)據(jù)傳輸速率。
參考文獻(xiàn)：
正式參考文獻(xiàn)
[1] Schulzrinne, H. and S. Casner, "音頻和視頻會議最小控制的RTP描述", RFC 3551, 2003.6
[2] Bradner, S., "表示需求層的RFC關(guān)鍵字", BCP 14, RFC 2119, 1997.3
[3] Postel, J., "網(wǎng)絡(luò)協(xié)議", STD 5, RFC 791, 1981.9
[4] Mills, D., "網(wǎng)絡(luò)時間協(xié)議（第三版）描述、實(shí)現(xiàn)和分析", 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., "域名――實(shí)現(xiàn)和描述", STD 13, RFC 1035,1987.1
[8] Braden, R., "因特網(wǎng)主機(jī)需求――應(yīng)用和支持", STD 3, RFC 1123,1989.10
[9] Resnick, P., "因特網(wǎng)信息格式", RFC 2822,2001.4
非正式參考文獻(xiàn)
[10] Clark, D. and D. Tennenhouse, "新一代協(xié)議的建構(gòu)考慮," 關(guān)于通信體系結(jié)構(gòu)和協(xié)議的數(shù)據(jù)通信專業(yè)組討論班, (賓夕法尼亞州，費(fèi)城), IEEE 計算機(jī)通信回顧 卷. 20(4), 200－208頁,1990.9
[11] Schulzrinne, H., "關(guān)于設(shè)計音頻、視頻會話傳輸協(xié)議及其它多參與者實(shí)時應(yīng)用的討論", 1993.10
[12] Comer, D., TCP/IP網(wǎng)絡(luò)協(xié)議 ,卷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:會話初始協(xié)議", RFC 3261,2002.6
[14] International Telecommunication Union, "對不保證質(zhì)量的局域網(wǎng)的可視電話系統(tǒng)和設(shè)備", Recommendation H.323,ITU的無線電通訊標(biāo)準(zhǔn)一節(jié), Geneva, Switzerland, 2003.7
[15] Handley, M. and V. Jacobson, "SDP: 會話描述協(xié)議", RFC 2327,1998.4
[16] Schulzrinne, H., Rao, A. and R. Lanphier, "實(shí)時流協(xié)議(RTSP)", RFC 2326,1998.4
[17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "關(guān)于安全性的隨機(jī)化建議", RFC 1750, 1994.12
[18] Bolot, J.-C., Turletti, T. and I. Wakeman, "因特網(wǎng)多播視頻分布的可升級的反饋控制",關(guān)于通信體系結(jié)構(gòu)和協(xié)議的數(shù)據(jù)通信專業(yè)組討論班（英國，倫敦）, ACM,58—67頁, 1994.8
[19] Busse, I., Deffner, B. and H. Schulzrinne, "基于RTP的多媒體應(yīng)用的動態(tài) QoS控制", 計算機(jī)通訊,卷19,49—58頁,1996.1
[20] Floyd, S. and V. Jacobson, "周期性路由信息的同步",關(guān)于通信體系結(jié)構(gòu)和協(xié)議的數(shù)據(jù)通信專業(yè)組討論班 (舊金山,加利福尼亞), 33—44頁, ACM,1993.9 并參見[34].
[21] Rosenberg, J. and H. Schulzrinne, "RTP中成員組的采樣", RFC 2762,2000.2
[22] Cadzow, J., "紐約數(shù)字信號處理和數(shù)據(jù)分析基礎(chǔ)" 紐約: Macmillan, 1987.
[23] Hinden, R. and S. Deering, "IPv6地址結(jié)構(gòu)", RFC 3513,2003.4
[24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.Lear, "保密因特網(wǎng)中的地址分配", RFC 1918,1996.2
[25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "考慮可能有害的網(wǎng)絡(luò)10 (一些實(shí)現(xiàn)不應(yīng)成為標(biāo)準(zhǔn))", RFC 1627,1994.7
[26] Feller, W.,概率論及其應(yīng)用入門,卷1. 紐約: John Wiley and Sons , 1968.
[27] Kent, S. and R. Atkinson, "因特網(wǎng)協(xié)議的安全體系", RFC 2401,1998.11
[28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M.,Norrman, K. and D. Oran, "安全實(shí)時傳輸協(xié)議",2003.4
[29] Balenson, D., "增強(qiáng)因特網(wǎng)電子郵件的保密性:第三部分", RFC 1423,1993.2
[30] Voydock, V. and S. Kent, "高層網(wǎng)絡(luò)協(xié)議的安全機(jī)制", ACM 計算調(diào)查,卷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., "多媒體會話的安全服務(wù)", 第16屆國際安全會議，(巴爾的摩,馬里蘭州),391—395頁,1993.9
[34] Floyd, S. and V. Jacobson, "周期路由信息同步", IEEE/ACM 網(wǎng)絡(luò)傳輸,卷2,122—136頁,1994.4
posted on 2009-08-04 17:14
阿蜜果 閱讀(2488)
評論(3) 編輯 收藏 所屬分類:
協(xié)議