用一句簡單的話總結：RTSP發起/終結流媒體、RTP傳輸流媒體資料 、RTCP對RTP進行控制，同步。
之所以以前對這幾個有點分不清，是因為CTC標準裡沒有對RTCP進行要求，因此在標準RTSP的程式碼中沒有看到相關的部分。而在私有RTSP的程式碼中，有關控制、同步等，是在RTP Header中做擴充套件定義實現的。
另外，RFC3550可以看作是RFC1889的升級文件，只看RFC3550即可。
RTP：實時傳輸協議（Real-time Transport Protocol）

RTP/RTCP是實際傳輸資料的協議
RTP傳輸音訊/視訊資料，如果是PLAY，Server傳送到Client端，如果是RECORD，可以由Client傳送到Server
整個RTP協議由兩個密切相關的部分組成：RTP資料協議和RTP控制協議（即RTCP）

RTSP：實時流協議（Real Time Streaming Protocol，RTSP）

RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對話和控制作用
RTSP的對話過程中SETUP可以確定RTP/RTCP使用的埠，PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的傳送，等等

RTCP：

RTP/RTCP是實際傳輸資料的協議
RTCP包括Sender Report和Receiver Report，用來進行音訊/視訊的同步以及其他用途，是一種控制協議

以下是每個協議的概要介紹：
一、RTP資料協議
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所示：

二、RTCP控制協議
RTCP控制協議需要與RTP資料協議一起配合使用，當應用程式啟動一個RTP會話時將同時佔用兩個埠，分別供RTP和RTCP使用。RTP本身並不能為按序傳輸資料包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制，向會話中的所有成員週期性地傳送控制資訊，應用程式通過接收這些資料，從中獲取會話參與者的相關資料，以及網路狀況、分組丟失概率等反饋資訊，從而能夠對服務質量進行控制或者對網路狀況進行診斷。
RTCP協議的功能是通過不同的RTCP資料報來實現的，主要有如下幾種型別：

SR：傳送端報告，所謂傳送端是指發出RTP資料報的應用程式或者終端，傳送端同時也可以是接收端。

RR：接收端報告，所謂接收端是指僅接收但不傳送RTP資料報的應用程式或者終端。

SDES：源描述，主要功能是作為會話成員有關標識資訊的載體，如使用者名稱、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制資訊的功能。

BYE：通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。

APP：由應用程式自己定義，解決了RTCP的擴充套件性問題，並且為協議的實現者提供了很大的靈活性。

RTCP資料報攜帶有服務質量監控的必要資訊，能夠對服務質量進行動態的調整，並能夠對網路擁塞進行有效的控制。由於RTCP資料報採用的是多播方式，因此會話中的所有成員都可以通過RTCP資料報返回的控制資訊，來了解其他參與者的當前情況。
在一個典型的應用場合下，傳送媒體流的應用程式將週期性地產生髮送端報告SR，該RTCP資料報含有不同媒體流間的同步資訊，以及已經發送的資料報和位元組的計數，接收端根據這些資訊可以估計出實際的資料傳輸速率。另一方面，接收端會向所有已知的傳送端傳送接收端報告RR，該RTCP資料報含有已接收資料報的最大序列號、丟失的資料報數目、延時抖動和時間戳等重要資訊，傳送端應用根據這些資訊可以估計出往返時延，並且可以根據資料報丟失概率和時延抖動情況動態調整發送速率，以改善網路擁塞狀況，或者根據網路狀況平滑地調整應用程式的服務質量。

三、RTSP實時流協議
作為一個應用層協議，RTSP提供了一個可供擴充套件的框架，它的意義在於使得實時流媒體資料的受控和點播變得可能。總的說來，RTSP是一個流媒體表示協議，主要用來控制具有實時特性的資料傳送，但它本身並不傳輸資料，而是必須依賴於下層傳輸協議所提供的某些服務。RTSP可以對流媒體提供諸如播放、暫停、快進等操作，它負責定義具體的控制訊息、操作方法、狀態碼等，此外還描述了與RTP間的互動操作（RFC2326）。

RTSP在制定時較多地參考了HTTP/1.1協議，甚至許多描述與HTTP/1.1完全相同。RTSP之所以特意使用與HTTP/1.1類似的語法和操作，在很大程度上是為了相容現有的Web基礎結構，正因如此，HTTP/1.1的擴充套件機制大都可以直接引入到RTSP中。
由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體伺服器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關資訊，如資料編碼/解碼演算法、網路地址、媒體流的內容等。
雖然RTSP伺服器同樣也使用識別符號來區別每一流連線會話（Session），但RTSP連線並沒有被繫結到傳輸層連線（如TCP等），也就是說在整個RTSP連線期間，RTSP使用者可開啟或者關閉多個對RTSP伺服器的可靠傳輸連線以發出RTSP 請求。此外，RTSP連線也可以基於面向無連線的傳輸協議（如UDP等）。

RTSP協議目前支援以下操作：

檢索媒體：允許使用者通過HTTP或者其它方法向媒體伺服器提交一個表示描述。如表示是組播的，則表示描述就包含用於該媒體流的組播地址和埠號；如果表示是單播的，為了安全在表示描述中應該只提供目的地址。

邀請加入：媒體伺服器可以被邀請參加正在進行的會議，或者在表示中回放媒體，或者在表示中錄製全部媒體或其子集，非常適合於分散式教學。

新增媒體：通知使用者新加入的可利用媒體流，這對現場講座來講顯得尤其有用。與HTTP/1.1類似，RTSP請求也可以交由代理、通道或者快取來進行處理。

   HTTP與RTSP傳輸的差別。概括的講，RTSP被許多公司防火牆拒絕，而HTTP可以作為一個普通的檔案通過；RTSP適合於大資料量、高可用性的流，如直播事件、長事件或大型檔案；HTTP更適合於較小的資料傳輸和互動；當終端使用者正在觀看時，RTSP允許使用者在伺服器有效的回放媒體，HTTP更象下載一段媒體並在客戶機上播放。從終端使用者觀點來看，RTSP看起來像是檔案從中心位置播放，有點象廣播，而HTTP感覺更象時從視訊庫中取視訊，並在家裡的機器上播放。從服務質量的觀點上看，對於流，RTSP有更好的體驗，RTSP提供類似於VCR的媒體控制，如暫停、快進、倒退和絕對定位。使用HTTP傳輸，只能在整個流下載完成後，播放器軟體再模擬該過程。雖然，RTSP能夠使用TCP或UDP，但是RTSP控制經常與RTP聯合使用，以最好的服務質量傳送實際的媒體資料。