支持流媒體的協議 多媒體應用的一個顯著特點是數據量大,並且許多應用對實時性要求比較高。傳統的TCP 協議是一個面向連接的協議,它的重傳機制和擁塞控制機制都是不適用於實時多媒體傳輸的。RTP 是一個應用型的傳輸層協議,它並不提供任何傳輸可靠性的保證和流量的擁塞控制機制。RTP 位於UDP(User Datagram Protocol) 之上。UDP 雖然沒有TCP 那么可靠,並且無法保證實時業務的服務質量,需要RTCP 實時監控數據傳輸和服務質量。但是,由於UDP 的傳輸時延低於TCP ,能與音頻和視頻很好地配合。因此,在實際應用中,RTP/ RTCP/ UDP 用於音頻/ 視頻媒體,而TCP 用於數據和控制信令的傳輸。目前,支持流媒體傳輸的協議主要有實時傳輸協議RTP( Real-Time Transport Protocol) 、實時傳輸控制協議RTCP(Real-Time Transport Control Protocol) 和實時流協議RTSP(Real-Time Streaming Protocol) 等。下面分別對這三種協議作簡要介紹。流媒體協議棧如圖1 所示。
圖1 流媒體協議棧
2．實時傳輸協議RTP（Real-Time Transport Protocol）：
RTP是針對Internet上多媒體數據流的一個傳輸協議, 由IETF(Internet工程任務組)作為RFC1889發布。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證實時數據的傳輸，並不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。
2.1 RTP工作機制
威脅多媒體數據傳輸的一個尖銳的問題就是不可預料數據到達時間。但是流媒體的傳輸是需要數據的適時的到達用以播放和回放。rtp協議就是提供了時間標簽,序列號以及其它的結構用於控制適時數據的流放。在流的概念中”時間標簽”是最重要的信息。發送端依照即時的采樣在數據包里隱蔽的設置了時間標簽。在接受端收到數據包后,就依照時間標簽按照正確的速率恢復成原始的適時的數據。不同的媒體格式調時屬性是不一樣的。但是rtp本身並不負責同步，rtp只是傳輸層協議，為了簡化運輸層處理，提高該層的效率。將部分運輸層協議功能（比如流量控制）上移到應用層完成。同步就是屬於應用層協議完成的。它沒有運輸層協議的完整功能，不提供任何機制來保證實時地傳輸數據，不支持資源預留，也不保證服務質量。rtp報文甚至不包括長度和報文邊界的描述。同時rtp協議的數據報文和控制報文的使用相鄰的不同端口，這樣大大提高了協議的靈活性和處理的簡單性。
rtp協議和udp二者共同完成運輸層協議功能。udp協議只是傳輸數據包，不管數據包傳輸的時間順序。 rtp的協議數據單元是用udp分組來承載的。在承載rtp數據包的時候，有時候一幀數據被分割成幾個包具有相同的時間標簽，則可以知道時間標簽並不是必須的。而udp的多路復用讓rtp協議利用支持顯式的多點投遞，可以滿足多媒體會話的需求。
rtp協議雖然是傳輸層協議但是它沒有作為osi體系結構中單獨的一層來實現。rtp協議通常根據一個具體的應用來提供服務，rtp只提供協議框架，開發者可以根據應用的具體要求對協議進行充分的擴展。
2.2 RTP協議的報文結構
RTP頭格式如圖2所示：
開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。各段含義如下：
①版本（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標識。
見http://zhangjunhd.blog.51cto.com/113473/25481/
RTP是一種提供端對端傳輸服務的實時傳輸協議，用來支持在單目標廣播和多目標廣播網絡服務中傳輸實時數據，而實時數據的傳輸則由RTCP協議來監視和控制。
RTP定義在RFC
使用RTP協議的應用程序運行在RTP之上，而執行RTP的程序運行在UDP的上層，目的是為了使用UDP的端口號 和檢查和。如圖16-12所示，RTP可以看成是傳輸層的子層。由多媒體應用程序生成的聲音和電視數據塊被封裝在RTP信息包中，每個RTP信息包被封裝 在UDP消息段中，然后再封裝在IP數據包中。
1889中。 信息包的結構包含廣泛用於多媒體的若干個域，包括聲音點播(audio-on-demand)、影視點播(video on demand)、因特網電話(Internet telephony)和電視會議(videoconferencing)。RTP的規格沒有對聲音和電視的壓縮格式制定標准，它可以被用來傳輸普通格式的 文件。例如，WAV或者GSM(Global System for Mobile communications)格式的聲音、MPEG-1和MPEG-2的電視，也可以用來傳輸專有格式存儲的聲音和電視文件。
| TCP/IP模型 |
|
| 應用層(application) |
|
| 傳輸層 |
RTP |
| UDP |
|
| IP |
|
| 數據鏈路層(data link) |
|
| 物理層(physical) |
圖16-12 RTP是傳輸層上的協議
從應用開發人員的角度來看，可把RTP執行程序看成是應用程序的一部分，因為開發人員必需把RTP集成到應用程序 中。在發送端，開發人員必需把執行RTP協議的程序寫入到創建RTP信息包的應用程序中，然后應用程序把RTP信息包發送到UDP的套接接口 (socket interface)，如圖16-13所示；同樣，在接收端，RTP信息包通過UDP套接接口輸入到應用程序，因此開發人員必需把執行RTP協議的程序寫 入到從RTP信息包中抽出媒體數據的應用程序。
| TCP/IP模型 |
|
| 應用層(application) |
|
| RTP |
|
|
|
套接接口 |
| UDP |
|
| IP |
|
| 數據鏈路層(data link) |
|
| 物理層(physical) |
圖16-13 RTP和UDP之間的接口
現以用RTP傳輸聲音為例來說明它的工作過程。假設音源的聲音是64 kb/s的PCM編碼聲音，並假設應用程序取20毫秒的編碼數據為一個數據塊(chunk)，即在一個數據塊中有160個字節的聲音數據。應用程序需要為 這塊聲音數據添加RTP標題生成RTP信息包，這個標題包括聲音數據的類型、順序號和時間戳。然后RTP信息包被送到UDP套接接口，在那里再被封裝在 UDP信息包中。在接收端，應用程序從套接接口處接收RTP信息包，並從RTP信息包中抽出聲音數據塊，然后使用RTP信息包的標題域中的信息正確地譯碼 和播放聲音。
如果應用程序不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳，而是使用標准的RTP協議，應用程序就更容易與其他的網絡應用程序配合運行，這是大家都希望的事情。例如，如果有兩個不同 的公司都在開發因特網電話軟件，他們都把RTP合並到他們的產品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進行通信。
這里需要強調的是，RTP本身不提供任何機制來確保把數據及時遞送到接收端或者確保其他的服務質量，它也不擔保在遞送過程中不丟失信息包或者防止信息包的次序不被打亂。的確，RTP的封裝只是在系統端才能看到，中間的路由器並不區分那個IP數據報是運載RTP信息包的。
RTP允許給每個媒體源分配一個單獨的RTP信息包流，例如，攝像機或者麥克風。例如，有兩個團體參與的電視會議， 這就可能打開4個信息包流：兩台攝像機傳送電視流和兩個麥克風傳送聲音流。然而，許多流行的編碼技術，包括MPEG-1和MPEG-2在編碼過程中都把聲 音和電視圖像捆綁在一起以形成單一的數據流，一個方向就生成一個RTP信息包流。
RTP信息包沒有被限制只可應用於單目標廣播，它們也可以在一對多(one-to-many)的多目標廣播樹或者在 多對多(many-to-many)的多目標廣播樹上傳送。例如，多對多的多目標廣播，在這種應用場合下，所有發送端通常都把他們的RTP信息包流發送到 具有相同多目標廣播地址的多目標廣播樹上。
16.6.2 RTP信息包標題域
RTP標題由4個信息包標題域和其他域組成：有效載荷類型(payload type)域，順序號(sequence number)域，時間戳(timestamp)域和同步源標識符(Synchronization Source Identifier)域等。RTP信息包的標題域的結構如下圖所示：
| Payload Type |
Sequence Number |
Timestamp |
Synchronization Source Identifier |
Miscellaneous Fields |
1. 有效載荷類型
RTP信息包中的有效載荷域(Payload Type Field)的長度為7位，因此RTP可支持128種不同的有效載荷類型。對於聲音流，這個域用來指示聲音使用的編碼類型，例如PCM、自適應增量調制或 線性預測編碼等等。如果發送端在會話或者廣播的中途決定改變編碼方法，發送端可通過這個域來通知接收端。表16-01列出了目前RTP所能支持的聲音有效 載荷類型。
表16-01 目前RTP所能支持的聲音有效載荷類型
| 有效載荷號 |
聲音類型 |
采樣率(kHz) |
數據率(kb/s) |
| 0 |
PCM mu-law |
8 |
64 |
| 1 |
1016 |
8 |
4.8 |
| 2 |
G.721 |
8 |
32 |
| 3 |
GSM |
8 |
32 |
| 6 |
DVI |
16 |
64 |
| 7 |
LPC |
8 |
2.4 |
| 9 |
G.722 |
8 |
48～64 |
| 14 |
MPEG Audio |
90 |
- |
| 15 |
G.728 |
8 |
16 |
對電視流，有效載荷類型可以用來指示電視編碼的類型，例如motion JPEG, MPEG-1，MPEG-2或者H.231等等。發送端也可以在會話或者期間隨時改變電視的編碼方法。表16-02列出了目前RTP所能支持的某些電視有效載荷類型。
表16-02 目前RTP所能支持的聲音有效載荷類型
| 有效載荷號 |
電視格式 |
| 26 |
Motion JPEG |
| 28 |
- |
| 31 |
H.261 |
| 32 |
MPEG-1 video |
| 33 |
MPEG-2 video |
2. 順序號
順序號(Sequence Number Field)域的長度為16位。每發送一個RTP信息包順序號就加1，接收端可以用它來檢查信息包是否有丟失以及按順序號處理信息包。例如，接收端的應用 程序接收到一個RTP信息包流，這個RTP信息包在順序號86和89之間有一個間隔，接收端就知道信息包87和88已經丟失，並且采取措施來處理丟失的數 據。
3. 時間戳
時間戳(Timestamp)域的長度為32字節。它反映RTP數據信息包中第一個字節的采樣時刻(時間)。接收端可以利用這個時間戳來去除由網絡引起的信息包的抖動，並且在接收端為播放提供同步功能。
4. 同步源標識符
同步源標識符(Synchronization Source Identifier，SSRC)域的長度為32位。它用來標識RTP信息包流的起源，在RTP會話或者期間的每個信息包流都有一個清楚的SSRC。 SSRC不是發送端的IP地址，而是在新的信息包流開始時源端隨機分配的一個號碼。
16.6.3 實時傳輸控制協議
實時傳輸控制協議(Real-time Control Protocol，RTCP) 也定義在1996年提出的RFC 1889中。多媒體網絡應用把RTCP和RTP一起使用，尤其是在多目標廣播中更具吸引力。當從一個或者多個發送端向多個接收端廣播聲音或者電視時，也就 是在RTP會話期間，每個參與者周期性地向所有其他參與者發送RTCP控制信息包，如圖16-14所示。RTCP用來監視服務質量和傳送有關與會者的信 息。對於RTP會話或者廣播，通常使用單個多目標廣播地址，屬於這個會話的所有RTP和RTCP信息包都使用這個多目標廣播地址，通過使用不同的端口號可 把RTP信息包和RTCP信息包區分開來。
RTCP的主要功能是為應用程序提供會話質量或者廣播性能質量的信息。每個RTCP信息包不封裝聲音數據或者電視數 據，而是封裝發送端和/或者接收端的統計報表。這些信息包括發送的信息包數目、丟失的信息包數目和信息包的抖動等情況，這些反饋信息對發送端、接收端或者 網絡管理員都是很有用的。RTCP規格沒有指定應用程序應該使用這個反饋信息做什么，這完全取決於應用程序開發人員。例如，發送端可以根據反饋信息來修改 傳輸速率，接收端可以根據反饋信息判斷問題是本地的、區域性的還是全球性的，網絡管理員也可以使用RTCP信息包中的信息來評估網絡用於多目標廣播的性 能。
16.6.4 實時流放協議
實時流放協議(Real-Time Streaming Protocol，RTSP)是一個剛開始開發的協議，它的設想描述在RFC
播放的數據流被分成許多信息包，信息包的大小很適用於客戶機和服務器之間的帶寬。當客戶機已經接收到足夠多的信息包 之后，用戶軟件就可開始播放一個信息包，同時對另一個信息包解壓縮和接收第三個信息包。這樣用戶就不需要把整個媒體文件從服務器上下載之后就可立即播放。 廣播源可以是現場的數據流也可以是存儲的數據流。
RTSP協議想要提供控制多種應用數據傳送的功能，提供一種選擇傳送通道的方法，例如UDP, TCP, IP多目標廣播通道，以及提供一種基於RTP協議的遞送方法。正在設計的RTSP將工作在RTP的上層，用來控制和傳送實時的內容。
RTSP能夠與資源保留協議一起使用，用來設置和管理保留帶寬的流式會話或者廣播。
2326文件中。RTSP是應用級的實時流放協議，它主要目標是為單目標廣播和多目標廣播上的流式多媒體應用提供牢靠的播放性能，以及支持不同廠家提供的客戶機和服務機之間的協同工作能力。