RTP, RTCP, RTSP 協議介紹

流媒體是邊下載邊播放的方式, 是視頻會議、IP電話等應用場合的技術基礎。

         

爲何TCP/IP協議就不能知足多媒體通訊的要求呢？
由於TCP有如下4個特色:
1.TCP重傳機制
2.TCP擁塞控制機制
3.TCP報文頭比UDP報文頭要大
4.TCP的啓動速度慢
對比：
IP:數據傳輸 RTP:多媒體數據實時傳輸
TCP:保證數據傳輸可靠 RTCP:保證多媒體數據傳輸的可靠

 

RTP提供時間標誌,序列號以及其餘可以保證在實時數據傳輸時處理時間的方法
RTCP是RTP的控制部分,是用來保證服務質量和成員管理的
RTSP具體數據傳輸交給RTP,提供對流的遠程控制
RSVP預留帶寬,提升QoS(Quality of Sever)

RTP一般使用UDP來傳送數據，但RTP也能夠在TCP或ATM等其餘協議之上工做。當應用程序開始一個RTP會話時將使用兩個端口：
一個給RTP，一個給RTCP(RTP port + 1). RTP自己並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，
它依靠RTCP提供這些服務。一般RTP算法並不做爲一個獨立的網絡層來實現，而是做爲應用程序代碼的一部分。

RTSP與RTP最大的區別在於：RTSP是一種雙向實時數據傳輸協議，它容許客戶端向服務器端發送請求，如回放、快進、倒退等操做。
RTSP可基於RTP來傳送數據，還能夠選擇TCP、UDP、組播UDP等通道來發送數據，具備很好的擴展性。
RTSP 默認使用554端口, 很是相似 HTTP 協議的流控制協議, rtsp 的命令老是按照順序來發送.

RTP/RTCP -------------------------RFC3550/RFC3551
RTSP --------------------------RFC2326

 

2.1 RTP數據協議 

 

 

 

RTP 爲實時應用提供端到端的運輸，但不提供任何服務質量的保證，服務質量由RTCP來提供。多媒體數據塊經壓縮編碼處理後，先送給 RTP 封裝成爲 RTP 分組，再裝入運輸層的 UDP 用戶數據報，而後再交給 IP 層。

 

RTP數據協議負責對流媒體數據進行封包並實現媒體流的實時傳輸，每個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節的含義是固定的，而負載則能夠是音頻或者視頻數據。RTP數據報的頭部格式如圖1所示：

 

      其中比較重要的幾個域及其意義以下： 
      CSRC記數（CC）　　表示CSRC標識的數目。CSRC標識緊跟在RTP固定頭部以後，用來表示RTP數據報的來源，RTP協議容許在同一個會話中存在多個數據源，它們能夠經過RTP混合器合併爲一個數據源。例如，能夠產生一個CSRC列表來表示一個電話會議，該會議經過一個RTP混合器將全部講話者的語音數據組合爲一個RTP數據源。 
      負載類型（PT）　　標明RTP負載的格式，包括所採用的編碼算法、採樣頻率、承載通道等。例如，類型2代表該RTP數據包中承載的是用ITU G.721算法編碼的語音數據，採樣頻率爲8000Hz，而且採用單聲道。 
      序列號　　用來爲接收方提供探測數據丟失的方法，但如何處理丟失的數據則是應用程序本身的事情，RTP協議自己並不負責數據的重傳。 
      時間戳　　記錄了負載中第一個字節的採樣時間，接收方可以時間戳可以肯定數據的到達是否受到了延遲抖動的影響，但具體如何來補償延遲抖動則是應用程序本身的事情。 從RTP數據報的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息，這些都爲實時的流媒體傳輸提供了相應的基礎。RTP協議的目的是提供實時數據（如交互式的音頻和視頻）的端到端傳輸服務，所以在RTP中沒有鏈接的概念，它能夠創建在底層的面向鏈接或面向非鏈接的傳輸協議之上；RTP也不依賴於特別的網絡地址格式，而僅僅只須要底層傳輸協議支持組幀（Framing）和分段（Segmentation）就足夠了；另外RTP自己還不提供任何可靠性機制，這些都要由傳輸協議或者應用程序本身來保證。在典型的應用場合下，RTP通常是在傳輸協議之上做爲應用程序的一部分加以實現的，如圖2所示：

 

 

 

 

 

在RTP分組的首部中，前12個字節是必須的，12字節之後的是可選的。完整的RTP數據包格式以下：

 

RTP是目前解決流媒體實時傳輸問題的最好辦法，存在一些開放源代碼的RTP庫，如LIBRTP、JRTPLIB等。JRTPLIB是一個面向對象的RTP庫，它徹底遵循RFC 3550（RFC 1889已過期）設計，是一個用C++語言實現的RTP庫