平時看的視頻流是靠什麼做支撐的？是實時傳輸協議，英文是Real time transport protocol，簡寫爲RTP協議。
RTP協議的定義：RTP爲實時應用提供端到端的運輸，但不提供任何服務質量的保障。服務質量由專門的協議提供，比如在IP層面上的QOS提供該服務。需要發送的多媒體數據塊（包括視頻流數據塊、音頻流數據塊）經過壓縮編碼處理後，先送到RTP封裝成RTP分組（RTP數據報），RTP分組裝入運輸層的UDP用戶數據報之後，再向下傳遞給IP層。
對RTP協議的理解：實際上介於應用層和傳輸層之間。同時具有應用層和傳輸層的各種特點。這個特點需要仔細甄別。
從應用開發者的角度看，RTP應該是應用層的一個部分。在應用程序的發送端，開發者必須編寫用RTP封裝分組（數據包）的程序代碼，然後把該RTP分組交給UDP套接字接口。在接收端設備，RTP分組通過UDP套接字接口進入應用層程序後，會利用開發者編寫的程序代碼把RTP分組從應用數據塊提取出來。RTP實際上爲視頻程序的開發者提供了一個開發平臺。
RTP也可以理解爲運輸層協議，實際上RTP協議偏重於傳輸層，是UDP協議（用戶數據報）上邊的一層協議。因爲RTP封裝了多媒體應用（包括視頻流、音頻流）的數據塊，關鍵是提供運輸層的服務（時間戳，序號、同步源標識符等），因此可以把RTP看成一共UDP上的運輸層子層協議，特別要注意是子層協議。
綜合來看，RTP協議實際上是一個介於傳輸層和應用層之間的協議，作用是在UDP協議之上完成一次對媒體流的封裝。
RTP分組僅僅包含RTP數據，RTP流由另一個控制協議RTCP協議來完成。RTP協議端口號由1025到65535之間選擇一個沒有使用的端口號，1025以下的端口號一般都是有用的。一般情況下RTP是偶數的端口號。控制協議RTCP使用奇數的端口號碼。這個奇數端口偶數端口是不確定的，但是約定一般都這麼“配置端口號”。
關於RTP在整個數據包裏邊的位置。RTP數據放入RTP分組裏面，會加入RTP首部信息。這個首部信息是關鍵。RTP分組放入UDP用戶數據報裏面，或者說UDP封裝RTP數據分組。（爲什麼用UDP？RTP一般承載音頻流，或者承載視頻流，這個對編碼效率要求比較高，對實時性要求比較高，所以利用UDP傳輸比較合適）UDP數據報放入IP包裏邊（三網合一之後基本都是IP去承載其它協議了）。
詳細分析RTP數據包。RTP協議裏邊都包括哪些內容，具體涉及到哪些信息詳細分析如下。按照從上到下，從左到右的順序逐一分析梳理：
- 版本號，佔兩位。版本號有兩個，v1和v2。現在v1已經被淘汰了，大家使用的都是v2。
- 填充P。佔位1位。在某些情況下需要對應用數據塊加密，這個結合CCIE security(CCIE安全)理解。往往要求每一個數據塊（媒體流數據塊）做填充。填充時P位“置1”就可以了。表示這個RTP分組的數據有若干個字節時填充字節。這些所謂的填充字節沒有實際意義，只是爲了佔位，目的是給加密提高操作的基礎。在數據部分的最後一個字節用來表示所填充的字節數。
- 擴展x。佔位一位。擴展首部很少使用，幾乎不用。表示在RTP首部後邊還有一個首部。這容易引起混亂，所以一般不用。
- 參與源數。佔位4位。這個字段給出後邊的參與源標識符的數目。
- 標記M。佔位1位。M位“置1”，表示這個RTP分組具有特殊意義。例如，在傳送視頻流中用來表示每一個幀的開始。
- 有效載荷類型（payload type）這個有效載荷類型是非常關鍵的內容。有效載荷類型共佔位7位。有效載荷類型字段指出後邊的RTP數據屬於何種格式的應用。收到RTP分組的應用層可以根據這個字段指出的類型進行處理，音頻字段按照音頻字段處理，視頻字段按照視頻字段處理。比如說，
對於音頻有效載荷（每一種格式後邊的括號的數字表示有效載荷類型）：u律PCM編碼（0），GSM編碼（3），LPC編碼（7），A律PCM編碼（8），G.722協議編碼（9），G.728協議編碼（15）。
對於視頻的有效載荷編碼包括：H.261編碼（31），MPEG1編碼（32），MPEG2編碼（33），這些都是關鍵數據。關鍵是理解括號內的數字等於理解有效載荷類型的編號。 - 序號。序號是關鍵點，數據包的亂序問題就是靠“序號”來解決的。因爲國際互聯網本身是不可靠傳輸，所以說出現序號問題是一個非常正常的問題，錯序問題靠序號來解決，序號共佔位16位。對於每一個發送出的RTP分組，其序號會自動加1.在一次RTP會話開始時的初始序號是隨機選擇的（序號選擇算法）。序號最主要的目的是使得接收端能夠發現丟失的分組，同時也能夠將失去順序的分組重新排序。這個重新排序是重點，其實很多時候失去的分組需要啓動重傳協議。比如在收到序號爲60的RTP分組之後又收到了序號爲65的RTP分組。這個時候可以形成推理，中間還缺少4個關鍵的RTP分組，序號分別爲61，62，65，64.這個時候RTP協議會自動啓動重傳協議。
- 時間戳。這個時間戳是RTP裏邊非常關鍵的部分。時間戳的佔位32位。時間戳反映了RTP分組中數據的第一個字節的採樣時刻。在一次會話開始時，時間戳的初始值也是隨機選擇的，這個時間戳不是時間的完全控制系統，需要和其他的時間控制系統共同完成對時間的控制。即使是沒有信號發送時，時間戳的數值也隨時間的增加而不斷增加。接收端（接受端子）使用時間戳可以準確知道應該在什麼時間點還原哪一個數據塊，這個時間點和數據塊是一一對應的，這樣設計目的是消除時間抖動。時間還可以用來使得視頻應用的圖像和聲音同步，這個也就是所謂的脣音同步。在RTP協議裏邊並沒有規定時間戳的顆粒度，因爲這樣做沒有必要。顆粒度的大小取決於有效載荷的類型。因此RTP的時間戳又稱爲媒體時間戳，目的是強調這種時間戳的顆粒度取決於信號的類型。比如說，對於8kHz採用頻率的話音信號，20毫秒發送一個數據塊。因此每一次發送RTP分組，時間戳的數值會增加160。時間戳是一個非常關鍵的數據，媒體數據的延遲問題和抖動問題都是靠時間戳來搞定的。
- 同步源標識符（synchronize source identifier），這個同步源標識符非常關鍵。用來標識RTP的源頭，用來標識RTP數據流的來源。SSRC與IP地址沒有什麼關係，這個在新的RTP流開始的時候是隨機產生的。由於RTP使用UDP協議作爲下一級封裝協議，因此可以出現多個RTP數據流。比如，使用幾個攝像機從不同的拍攝角度拍攝同一個節目，這個時候會產生多個RTP數據流，這些RTP數據流會複用到同一個UDP數據報裏面。在接收端，會根據RTP數據流不同的同步源標識符分流到不同的接受端子，也就是說RTP流一點也不會混亂，每一個接受端子都會接受自己的RTP數據流。兩個RTP數據流同時選擇一個同步源的概率非常低，如果這種小概率事件出現，兩個RTP數據流也會選擇不同的同步源標識符。