流媒體是邊下載邊播放的方式, 是視頻會議、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數據包格式如下：