RFC3550 - RTP: A Transport Protocol for Real-Time Applications
http://www.ietf.org/rfc/rfc3550.txt?number=3550
RFC3551 - RTP Profile for Audio and Video Conferences with Minimal Control
http://www.ietf.org/rfc/rfc3551.txt?number=3551
RFC2198 - RTP Payload for Redundant Audio Data
http://www.ietf.org/rfc/rfc2198.txt?number=2198
RFC2205 - Resource ReSerVation Protocol (RSVP)
http://www.ietf.org/rfc/rfc2205.txt?number=2205
RFC2750 - RSVP Extensions for Policy Control
http://www.ietf.org/rfc/rfc2750.txt?number=2750
RFC3936 - Procedures for Modifying the Resource reSerVation Protocol (RSVP)
http://www.ietf.org/rfc/rfc3936.txt?number=3936
RFC4495 - A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
http://www.ietf.org/rfc/rfc4495.txt?number=4495
RFC2748 - The COPS (Common Open Policy Service) Protocol
http://www.ietf.org/rfc/rfc2748.txt?number=2748
RFC2749 - COPS usage for RSVP
http://www.ietf.org/rfc/rfc2749.txt?number=2749
RFC4261 - Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
http://www.ietf.org/rfc/rfc4261.txt?number=4261
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
因爲IP互聯網不是等時系統，所以在發送實時數字數據時需要額外的協議支持。除了允許檢測複製或重新排序的分組的基本次序信息之外，每個分組還必須傳送單獨的時間戳，告訴接收方應該播放分組中的數據的準確時間。
如果網絡中有抖動，接收方需要實現回放緩衝區來準確地重建信號。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
在IP互聯網上傳輸數字音頻或視頻信號所使用的協議是實時傳輸協議 (Real-Time Transport Protocol, RTP)。RTP不包含確保及時交付的機制，必須由底層系統來保證。
RTP提供兩個關鍵的特性：每個分組中的序號以及時間戳。序號允許接收方檢測不按順序的交付或數據丟失，時間戳允許接收方控制回放。
設計RTP是爲了傳送包括音頻和視頻等廣泛的實時數據，所以RTP不強制統一的語義解釋，而是每個分組以固定的首部開頭，首部中的字段指定如何解釋其餘的首部字段以及如何解釋有效載荷。
********************************************************************************
The RTP header has the following format:
0 1 2 3開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。各段含義如下：<?XML:NAMESPACE PREFIX = O />
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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (audio, video....) |
| +-+-+-+-+-+-+-+-+-+-+-+-+
| ....| padding | count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
①版本（V）
2位，標識RTP版本。
②填充標識（P）
1位，如設置填充位，在包尾將包含附加填充字，它不屬於有效載荷。填充的最後一個八進制包含應該忽略的八進制計數。某些加密算法需要固定大小的填充字，或爲在底層協議數據單元中攜帶幾個RTP包。
③擴展（X）
1位，如設置擴展位，固定頭後跟一個頭擴展。
④CSRC計數（CC）
4位，CSRC計數包括緊接在固定頭後CSRC標識符個數。
⑤標記（M）
1位，標記解釋由設置定義，目的在於允許重要事件在包流中標記出來。設置可定義其他標示位，或通過改變位數量來指定沒有標記位。
⑥載荷類型（PT）
7位，記錄後面資料使用哪種 Codec ， receiver 端找出相應的 decoder 解碼出來。
常用 types：
|
Payload Type |
Codec |
|
0 |
PCM μ -Law |
|
8 |
PCM-A Law |
|
9 |
G..722 audio codec |
|
4 |
G..723 audio codec |
|
15 |
G..728 audio codec |
|
18 |
G..729 audio codec |
|
34 |
G..763 audio codec |
|
31 |
G..761 audio codec |
⑦系列號
16位，系列號隨每個RTP數據包而增加1，由接收者用來探測包損失。系列號初值是隨機的，使對加密的文本攻擊更加困難。
⑧時標
32位，時標反映RTP數據包中第一個八進制數的採樣時刻，採樣時刻必須從單調、線性增加的時鐘導出，以允許同步與抖動計算。時標可以讓receiver端知道在正確的時間將資料播放出來。
由上圖可知，如果只有系列號，並不能完整按照順序的將data播放出來，因爲如果data中間有一段是沒有資料的，只有系列號的話會造成錯誤，需搭配上讓它知道在哪個時間將data正確播放出來，如此我們才能播放出正確無誤的信息。
⑨SSRC
32位，SSRC段標識同步源。此標識不是隨機選擇的，目的在於使同一RTP包連接中沒有兩個同步源有相同的SSRC標識。儘管多個源選擇同一個標識的概率很低，所有RTP實現都必須探測並解決衝突。如源改變源傳輸地址，也必須選擇一個新SSRC標識以避免插入成環行源。
⑩CSRC列表
0到15項，每項32位。CSRC列表表示包內的對載荷起作用的源。標識數量由CC段給出。如超出15個作用源，也僅標識15個。CSRC標識由混合器插入，採用作用源的SSRC標識。********************************************************************************
RTP的關鍵部分是對變換 (也就是在中間位置改變數據流的編碼)或混合 (也就是從多個源接收數據流，把它們組合成一個數據流，然後發送結果)的支持。混合和組播技術的結合能使交付給每個參與主機的數據報減少。
RTP首部中的字段標識發送方，指示是否發生混合。同步源標識符字段指定數據流的源站。每個源站必須選擇一個惟一的32位標識符，如果發生衝突，則協議包括解決衝突的機制。當混合器組合多個數據流時，混合器就變成新的數據流的同步源。但是有關初始源的信息沒有丟失，這是因爲混合器使用大小可變的參與源ID字段提供正在混合的數據流的同步ID。4位CC字段給出參與源的數目，最多可以列出15個源。
傳統的TCP 協議是一個面向連接的協議,它的重傳機制和擁塞控制機制都是不適用於實時多媒體傳輸的。RTP 是一個應用型的傳輸層協議,它並不提供任何傳輸可靠性的保證和流量的擁塞控制機制。RTP不像傳輸協議那樣發揮作用，在實際應用中不會在IP中直接封裝，而是RTP在UDP上運行，這意味着把每條RTP報文封裝到UDP數據報中。使用UDP的主要優點是併發性 -- 單個計算機可以有多個使用RTP的應用程序，而不會互相干擾。RTP不使用保留的UDP端口號，而是爲每個會話分配一個端口，因此必須把端口號通知給遠程的應用程序。通常情況下RTP選擇偶數UDP端口號。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RTP控制協議 (RTCP)，是RTP的一個完整部分，提供需要的控制功能。RTCP允許發送方和接收方相互傳輸一系列報告，這些報告包含有關正在傳輸的數據以及網絡性能的額外信息。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時數據。
當應用程序開始一個rtp會話時將使用兩個端口：一個給rtp，一個給rtcp。rtp本身並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠rtcp提供這些服務。RTCP報文封裝在UDP中，以便進行傳輸，發送時使用比它們所屬的RTP流的端口號大1的協議號。
RTCP使用5個基本報文類型允許發送方和接收方交換有關會話的信息。
類型 含義
-------------------------------------------------------------
200 發送方報告 (SR)
201 接收方報告 (RR)
202 源描述報文 (SDES)
203 結束報文 (BYE)
204 應用程序特定報文 (APP)
1. 發送方在停止發送數據流時傳輸一條結束報文。
2. 應用程序特定報文提供了基本功能的擴展，以允許應用程序定義報文類型。
3. 接收方週期性地傳輸接收方報告報文，向源通知接收的條件。
4. 發送方週期性地傳輸發送方報告報文，提供絕對的時間戳。而絕對時間戳爲接收方提供了使多個數據流同步的機制。
5. 發送方還傳輸源站描述報文，提供有關擁有對源站控制權的用戶的常規信息。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
H.323不是單個協議，而是制定如何把多個協議組合起來，形成一個實用的IP電話技術系統。
H.323爲IP電話技術使用的協議：
協議 目的
-----------------------------------------------
H.225.0 建立通話所使用的信令
H.245 在通話中控制和返回
RTP 實時數據傳輸（序列和時限）
T.120 交換和通話有關的數據
SIP只涵蓋信令，不推薦特殊的編碼，也不要求對實時傳輸使用RTP。SIP使用C/S交互方式。爲了提供有關通話的信息，SIP要依靠一個伴生的協議，即會話說明協議 (SDP)。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IETF提供的在IP環境中的QoS方案：
資源預留協議 (Resource Reservation Protocol, RSVP)
通用開放策略服務 (Common Open Policy Services, COPS)
RSVP處理預留請求並進行應答，它不是路由協議，也不強制在建立數據流時就啓用策略，而是在發送任何數據之前運轉。每個RSVP流是單工的 (simplex)，也就是單向傳輸的。
端點使用RSVP在指定了QoS界限的IP互聯網上請求單工數據流。如果路徑上的路由器同意請求，則認可數據流，否則拒絕數據流。如果應用程序需要兩個方向上的QoS，則每個端點必須使用RSVP請求單獨的數據流。
當RSVP請求抵達時，路由器必須對兩個方面進行評估：可行性（也就是路由器是否具有滿足請求的資源）和策略（也就是請求是否符合策略約束）。可行性是本地決策，而策略強制要求全局合作。
要實現全局策略，IETF使用兩級模型，用C/S模式在兩級之間交互作用。當路由器接收到RSVP請求時，它就變成客戶，與服務器協商以確定請求是否符合策略約束，該服務器稱爲策略確定點（Policy Decision Point, PDP）。PDP不處理通信量，只對請求進行評估，檢查它是否符合全局策略。如果PDP認可請求，則路由器必須作爲策略執行點（Policy Enforcement Point, PEP）進行操作，確保通信量不會超過認可的策略。
COPS協議定義在路由器和PDP之間的C/S交互作用，或者如果組織有多級策略服務器，就定義路由器和本地PDP之間的C/S交互作用。雖然COPS定義它自己的報文首部，但是底層格式和RSVP共享許多具體字段。而且，對於請求報文中的單個數據項，COPS使用和RSVP一樣的格式。這樣，當路由器接收到RSVP請求時，它可以提取和策略相關的數據項，把它們放在COPS報文中，把結果發送給PDP。