RTP-實時協議

RTP，實時協議被用來爲應用程序如音頻，視頻等的實時數據的傳輸提供端到端（end to end）的網絡傳輸功能。傳輸的模型能夠是單點傳送或是多點傳送。數據傳輸被一個姐妹協議——實時控制協議（RTCP）來監控，後者容許在一個大的多點傳送網絡上監視數據傳送，而且提供最小限度的控制和識別功能。

RTP是被IETF在RFC1889中提出來的。順帶說起，RTP已經被接受爲實時多媒體傳送的通用標準。ITU-T跟IETF都在各自的系統中將這一協議標準化。

1.1 爲什麼須要RTP?

TCP不能支持像交互視頻，會議等的實時服務，這一緣由是因爲TCP只是一個「慢」協議，須要三次握手。就此在IP層上UDP是一個比TCP更好的選擇。可是UDP是本質上是一個不可靠協議，不支持在包丟狀況下的重傳機制。誠然，UDP有一些特性，好比多路複用跟校驗和服務，這些都是對實時服務頗有利的。爲了消除UDP的缺點，RTP是做爲應用層而被提出來的。

RTP提供的各類服務包括有效負載識別，序列編號，時間戳和投遞監聽。RTP可以序列化包，當這些包在收端不是按順序到達的時。序列號也能被用來識別包丟失。時間戳被用於媒體有效的播放。到達的數據一直被RTCP監聽，以通知RTP層來校訂其編碼和傳輸的參數。例如，若是RTCP層檢測到包丟失，它會通知RTP層減緩發送速率。

儘管RTP有助於實時媒體的有效的播放 ，可是要注意的是RTP自身並不提供任何機制來確保及時傳遞或提供其餘服務質量（QoS）的保證，而是依靠低層服務來完成這些。一樣，RTP也不保證投遞或防止無序投遞。RTP被設計出來主要是爲了知足有多個參加者的多媒體會議的須要。RTP也一樣適合於象持續數據的儲存，分佈式交互仿真，主動標記以及應用程序的控制和測量。

1.2 RTP特性一覽

RTP提供有效負荷類型識別，亂序重排和利用時間戳的媒體有效播放。

RTCP監控服務質量，也提供在一個當前進行的會話中傳送關於參加者的信息做用。

RTP對於下層協議是獨立的，它可以工做在像TCP/IP，ATM，幀時延等類型的網絡上。

若是被下層網絡支持，RTP支持利用多路技術的對於多點的數據傳輸。

RTP序列號也能被用來肯定包的合適位置。例如在視頻解碼，包無需按序解碼。 

2.0 技術概覽

2.1 RTP

RTP頭具備以下的格式。開始的12個八位字節在每個RTP包中都會出現；而CSRC標識符列表只在經過混合器的包中出現。這些域含有如下意義：

 

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 |

| .... |

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

 

Version (V) （版本號）: 這個域長度爲2比特，標出了RTP的最近版本。當前的版本爲2.0

Padding (P) （填充）: 這個域長度爲1比特，若是P被置位，包在結尾處包含有一個或多個附加的填充字節，這些填充字節不是有效負荷的一部分。填充是一些須要固定塊大小的加密算法所要求的，或是爲了在低層PDU搬運RTP包。

Extension (X): 這個域長度爲1比特，若是被置位，固定的頭後面緊跟了一個頭的擴展。

CSRC count (CC): 這個域長度爲4比特。這個域表示了跟在固定頭後面的CSRC標識符的數目。 如前所述，這個域只有在經過一個混合器纔有非零值。

Marker bit (M): 這個域長度爲1比特，若是M被置位，表示一些重要的項目如幀邊界在包中被標記。例如，若是包中有幾個比特的當前幀，連同前一幀，那麼RTP的這一位就被置位。

Payload type (PT) （有效負荷類型）: 這個域長度爲7比特，PT指示的是有RTP包中的有效負荷的類型。RTP音頻視頻簡介(AVP)包含了一個默認的有效負荷類型碼到有效負荷格式的映射。附加的有效負荷類型能夠向IANA註冊。

Sequence number（序列號）： 這個域長度爲16個比特，每送一個RTP包數目就增長一，初始值被設爲一個隨機數。接收方不只能夠用這個序列號檢測包丟失，也能夠重組包序列。

Time stamp（時間戳）: 這個域長度爲32個比特，時間戳反映了RTP數據包的頭一個字節的採樣時刻。 採樣時刻必須是由一個單調線性增長的時鐘產生，這樣作是爲了接收方的同步和抖動計算。初始值必須爲隨機數，這是爲了不對原碼的攻擊。例如，若是RTP源使用了一個編碼器， 緩衝20ms的音頻數據，那麼RTP時間戳必須每一個包增長160，不管包是被傳遞了仍是被丟失了。

SSRC: 這個域長度爲32比特，這個域表示了正在爲會話產生RTP包的源。這個標識符是隨機選中的，目的是爲了不同一個RTP會話中兩個源有相同的標識符。

CSRC list: 這個列表標識了在這個包中對有效負荷起做用的全部源。標識符的最大數目限定爲15，這是由CC域所限定的（全零在CC域中是被禁止的）。若是有超過15個的分配源，只有前15個被標識。

仔細觀察RTP能夠注意到它不像更低層的協議好比PDU同樣，包含一個「定邊界」的域。 這一緣由是RTP的有效負荷是跟IP的有效負荷相同，所以也就不須要了。

若是相同的用戶在一個會話中使用多個媒體，好比說視頻跟音頻，每一個媒體都會打開單獨的RTP會話。所以在RTP層面上不存在多路複用。多路複用由更低層來決定。可是RTCP保留了一個叫CNAME的標識符，這個標識符對於由同一用戶初始化的媒體是相同的。所以CNAME是在RTP層面上能識別從一個用戶產生的不一樣媒體的惟一的標識符。

從上能夠看出，RTP頭的開銷是至關大的，爲了減小這一開銷，RTP頭壓縮被提了出來。

2.2 RTCP

RTP接收者利用RTCP報告包，提供接收質量的反饋。這個報告包能夠是發送者類型也能夠是接收者類型。若是接收者主動參加到一個會話中，那麼它就送SR（sender report），不然它將送RR（receiver report）。除SR跟RR包之外，RTCP還有其餘的包類型：SDES （Source Description）, BYE 和APP（Application defined）,RTCP和SDES包的有效負荷類型值在表1和表2中相應給出。

PACKET TYPE                                               Payload Type

SR (發送者報告)                                                    200

RR (接收者報告)                                                    201

SDES (源描述)                                                       202

BYE                                                                203

APP (應用程序定義)                                               204

 

RTCP SDES ITEM                                            Value

END (SDES列表結尾)                                           0

CNAME (規範名)                                                   1

NAME (用戶名)                                                     2

EMAIL                                                                   3

PHONE                                                                  4

LOC                                                                      5

TOOL                                                                   6

NOTE                                                                   7

PRIV                                                                     8

 

2.2.1 RTCP SR 包

RTCP發送者報告包在圖2中顯示，各域含有下列意義。

Version (V): 與RTP中同

Padding (P): 與RTP中同

Reception report count (RC): 該域長度爲5比特，RC表示接收報告塊的大小。

Packet type (PT): 該域長度8比特，SR報告包的包類型是200。

SSRC: 與RTP中同

NTP Time stamp: 該域長度64比特，NTP表示了該包發送時的最大執行時間 (wall clock time)，這個信息是被用來測量鏈路網絡（round-trip）傳播延時。

RTP Time stamp: 與RTP中同，這些時間戳被用於媒體內／外的同步。

Sender’s packet count: 該域長度爲32比特，該域指示了從會話開始直到本SR被髮送過程當中發送者發出的RTP數據包的數目。

Sender’s octet count: 該域長度爲32比特，表示從會話開始發送的有效負荷字節的總數目。

SSRC_n (源標識符): 該域長度爲32比特，用於標識在這次阻塞報告中信息源

Fraction lost: 自前一個SR或RR包發送後丟失的RTP包的份額。

Cumulative number of packet lost: 該域長度爲24比特，表示從會話開始，丟失的RTP數據包的總數目。

Extended highest sequence number received: 該域長度32比特，低16位包含從SSRC_n收到的RTP包中的最高序列號，最高16位用於擴展相應的序列號的循環週期的計數值。

值得注意的是在同一會話的不一樣接收這來講，若是他們的起始時間差異比較大的話，接收者將產生不一樣的擴展位。

Inter-arrival jitter: 該域長度32比特，表示了以時間戳爲單位估計的RTP數據包到達時間的統計方差，用無符號的整數表示。

Last SR timestamp: 該域長度32比特，它把收到的NTP時間戳64位中間的32位做爲最近的RTCP SR的一部分。

Delay since last SR (DLSR): 該域長度爲32比特，延遲的單位是65536分之1秒，表示最近的SR包和本RR包之間的時間。  

2.2.2 RTCP RR 包

RR包的結構與SR包相同，只是它沒有包含發送者相關項（NTP, RTP 時間戳， 包數目跟字節數目）。 只有被動參加者才發RR包。

2.2.3 RTCP SDES 包

SDES包在圖3中給出，不一樣類型的源描述包以下列出:

CNAME： 這是規範終端標識符。CNAME在SDES包中是必須出現的項目，其他的都是可選的。CNAME能夠被接收者用來識別同一個特定用戶產生的不一樣的媒體流。

其餘被支持的SDES項是NAME, EMAIL,PHONE, LOC, TOOL, NOTE 和 PRIV

涉及到大量的參加者時，在一個會話過程當中有可能RTCP的流量超過RTP的流量，這是因爲，在時間的任何一個點上，只有一我的在說而其餘的人都在聽。爲了減小RTCP的流量，RTCP的包傳輸率，做爲參加者數目，RTCP包大小，RTCP帶寬等的一個函數作動態變化。根據標準，會話帶寬的20％分配給RTCP而且RTCP帶寬的5％分配給CNAME。換句話說，每發送五個RTP包才發送一個RTCP的RR跟SR包。對於小型會話（參加者數目比較小），每5秒中會有一個RTCP的傳輸，每隔15秒鐘，一個附加項會被包括在SDES包中。

2.2.4 RTCP BYE 包

RTCP BYE包在RTP會話的結尾被送出，包的結構如圖4所示：

2.2.5 RTCP APP 包

APP包是爲了新的應用程序和新的特性的實驗用途，其結構如圖5所示

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| subtype | PT=APP=204 | length |

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

| SSRC/CSRC |

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

| name (ASCII) |

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

| application-dependent data ...

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

3.0 SIP中的RTP

IETF已經提議會話初始協議（SIP）做爲因特網上多媒體調用的創建，修改和終結。RTP/RTCP被媒體用來做爲在他們系統中傳輸的協議。SIP的流圖結構如圖6所示

4.0 H.323中的RTP

ITU-T已經提出了H.323，這是另外一個著名的多媒體通訊系統。RTP/RTCP再次被用做媒體傳輸。H.323的流圖結構在圖7中給出。

5.0 結論

RTP是應用層級別的協議，它提供了在單點傳送或多點傳送基礎上，適合媒體傳輸如視頻，音頻，仿真數據等實時數據的，端到端的網絡傳輸功能。RTP以序列化，有效負載識別和媒體實時播放爲目標。數據傳輸增長了一個控制協議RTCP，這個協議監聽了數據傳送而且提供了最小限度的控制和識別功能。RTP和RTCP被設計成獨立於下層網絡傳輸網絡，而且不提供源保留，也不保證明時服務的服務質量（QoS）。

RTP 術語表

RTP 有效負載： 在一個RTP包中被傳輸的數據。例如，音頻樣本或壓縮視頻數據。

RTP 媒體類型： RTP 媒體類型是有效負載類型的一個集合，這個集合在單一的RTP會話中被運載。有效負載類型是在音頻視頻協議（AVP）中被定義的【RFC 1890】。

RTP 會話：在一個使用RTP進行通信的參加者集合中的聯絡。

Synchronizing source（SSRC）：RTP包的源，由在RTP頭中的一個32位數值SSRC標識符來表示。爲了跟網絡地址區別開來。

Contributing source (CSRC)：RTP包的一個流的源，這個源是經過一個RTP混合器來產生一個混合的新流。

Mixer： 一個媒體間系統，它從一個或多個源發出的RTP包中提取內容，並把它們經過某種方式混合，而後從一個新的RTP包中送出。在此過程當中數據格式可能被改變。

Translator： 一個媒體間系統，它把RTP包向前傳送，並不改變它們的synchronizing source。Translator的例子包括編碼轉換而不混合的設備，從多點傳送到單一傳送的複製器，還有防火牆中應用級別的過濾器。

Monitor： 一個應用程序，它接收在一個RTP會話中參加者送出的RTCP包，併爲分配監聽，故障診斷，和長期統計估計當前的服務質量。

Non-RTP means：除了RTP之外，爲了提供一個可用的服務的協議和機制。例如，在媒體傳輸以前須要發信號，這在SIP或H.323中被提出來。