RTP協議
RFC3550定義實時傳輸協議RTP和它的控制協議RTCP。RTP協議是Internet上針對流媒體傳輸的基礎協議，該協議詳細說明在互聯網上傳輸音視頻的標準數據包格式。RTP本身只保證實時數據的傳輸，並不能提供可靠傳輸、流量控制和擁塞控制等服務質量保證，這需要RTCP協議提供這些服務。 IETF的RFC3550定義RTP/RTCP協議的基本內容，包括報文格式、傳輸規則等。除此之外，IETF還定義一系列擴展協議，包括RTP檔次擴展，RTCP報文類型擴展等。
RTP固定頭部
V ：RTP協議的版本號，佔2位，當前協議版本號爲2。
P ：填充標誌，佔1位，若P=1則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分，表示報文對齊。
X ：擴展標誌，佔1位，若X=1，則在RTP報頭後跟有一個擴展頭。
CC：CSRC計數器，佔4位，指示CSRC 標識符的個數。
M ：標記，佔1位，不同的有效載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。
PT ：有效載荷類型，佔7位，用於說明RTP報文中有效載荷的類型，如GSM音頻、JPEM圖像等。
序列號：16位，發送RTP報文的序列號，每發送一個報文序列號增1。接收者用序列號來檢測報文丟失，排序報文，恢復數據。
時間戳：32位，反映該RTP報文的第一個八位組的採樣時刻。接收者使用時戳來計算延遲和延遲抖動，並進行同步控制。
SSRC：32位，用於標識同步信源。該標識符是隨機選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC。
CSRC：每個CSRC標識符佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中的所有特約信源。在共流源標識並且沒有拓展頭部（X=0）的情況下，RTP頭部爲12個字節。
RTP拓展頭部
RTP提供拓展機制以允許實現個性化，某些與常規負載格式功能要求相獨立的附加信息在RTP 拓展頭的定義中實現。
若 RTP 固定頭中的擴展標誌位 X 置 1，則一個長度可變的擴展頭部分被加到 RTP 固定頭之後。擴展包含 16 比特的長度域，指示擴展項中 32 比特字的個數，不包括 4 個字節擴展頭(因此零是有效值)。RTP 固定頭之後只允許有一頭個頭擴展。爲了使拓展頭具有特定的含義,擴展頭的前 16 比特用來作爲特定含義的識別標識符或參數。這 16 比特的格式由具體實現的上層協議定義。基本的 RTP 說明並不定義任何頭擴展本身。
RTP規格級別(profile)
profile定義了一系列負載類型和對應的負載格式，也定義了特定於具體應用的RTP擴展和修改。典型地，某個應用僅基於一個規格級別運行。IETF針對RFC3550在檔次方面定義了一系列擴展協議。
RFC3551(RTP/AVP)在RFC3550的基礎上針對RTP檔次進行補充形成RTP/APVP檔次，被用在具有最小會話控制的音視頻會議中，是其它擴展檔次的基礎。該檔次在沒有參數協商和成員控制的會話中非常有用。該檔次也爲音視頻定義一系列編碼和負載格式。對於具體的流媒體負載格式，IETF也定義一系列協議詳細描述，如VP8視頻負載格式[6]和H264視頻負載格式[7]，等等。
RFC3711(SRTP，也即RTP/SAVP)是RTP/AVP在安全方面進行擴展形成的檔次，爲RTP/RTCP提供數據加密、消息認證、重放保護等功能。SRTP具有高吞吐量和低數據膨脹等特點，是異構環境下對RTP/RTCP數據的有效保護。
RFC4585(RTP/AVPF)是RTP/AVP在及時反饋方面進行擴展形成的檔次，使得接收端能夠向發送端提供及時反饋，實現短時調整和基於反饋的修復機制。該協議定義早期RTCP報文以實現及時反饋，並定義一系列通用RTCP反饋報文和特定於應用的反饋報文，如NACK、PLI、SLI、RPSI等。
RFC5124(RTP/SAVPF)則是RTP/SAVP和RTP/AVPF的綜合。SAVP和AVPF在使用時，需要參與者藉助於SDP協議[8]就檔次和參數信息達成一致。但是對一個RTP會話來說，這兩種檔次不能同時被協商。而實際應用中，我們有同時使用這兩種檔次的需要。因此，RTP/SAVPF檔次應運而生，它能夠使得RTP會話同時具有安全和及時反饋兩方面的特性。
RTCP協議
RTCP需要與RTP協議一起配合使用，當應用程序啓動一個RTP會話時將同時佔用兩個端口（複用情況下佔用同一個端口），分別供RTP和RTCP使用。RTP本身並不能爲數據包提供可靠傳輸的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制，向會話中的所有成員週期性地發送控制信息，應用程序通過接收這些數據，從中獲取會話參與者的相關資料，以及網絡狀況、分組丟失概率等反饋信息，從而能夠對服務質量進行控制或者對網絡狀況進行診斷。
RTCP功能概括
RTCP的主要功能可以概括爲3個方面，服務質量的監視與反饋、媒體間的同步、多播組中成員的標識。此外還可以進行丟包重傳或者 I 幀重傳的控制。下面是消息類型
| Type | Description | References |
|---|---|---|
| 0 - 191 |
||
| 192 | FIR, full INTRA-frame request. | RFC 2032 |
| 193 | NACK, negative acknowledgement. | RFC 2032 |
| 194 | SMPTETC, SMPTE time-code mapping. | RFC5484 |
| 195 | IJ, extended inter-arrival jitter report. | RFC 5450 |
| 196 - 199 |
||
| 200 | SR, sender report. | RFC 3550 |
| 201 | RR, receiver report. | RFC 3550 |
| 202 | SDES, source description. | RFC 3550 |
| 203 | BYE, goodbye. | RFC 3550 |
| 204 | APP, application defined. | RFC 3550 |
| 205 | RTPFB, Generic RTP Feedback. | |
| 206 | PSFB, Payload-specific Feedback. | |
| 207 | XR, RTCP extension. | RFC 3611 |
| 208 | AVB, AVB RTCP packet. | IEEE 1733 |
| 209 | RSI, Receiver Summary Information. | RFC 5760 |
| 210 - 255 |
其中以發送者報告舉例
版本(V)：同RTP包頭域.
填充(P)：同RTP包頭域.
接收報告計數器(RC)：5比特, 該SR包中的接收報告塊的數目, 可以爲零.
包類型(PT)：8比特, SR包是200.
長度域(Length)：16比特, 其中存放的是該SR包以32比特爲單位的總長度減一.
同步源(SSRC)：SR包發送者的同步源標識符, 對應RTP包中的SSRC一樣.
NTP timestamp：SR包發送時的絕對時間值, NTP的作用是同步不同的RTP媒體流, 一共8個字節，前4個字節代表
RTP timestamp：與NTP時間戳對應, 與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值.
Sender's packet count：從開始發送包到產生這個SR包這段時間裏, 發送者發送的RTP數據包的總數, SRC改變時這個域清零.
Sender's octet count：從開始發送包到產生這個SR包這段時間裏, 發送者發送的淨荷數據的總字節數(不包括頭部和填充), 發送者改變其SSRC時這個域要清零.
同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統計信息.
丟失率(Fraction Lost)：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP數據包的丟失率.
累計的包丟失數目：從開始接收到SSRC_n的包到發送SR, 從SSRC_n傳過來的RTP數據包的丟失總數.
收到的擴展最大序列號：從SSRC_n收到的RTP數據包中最大的序列號.
接收抖動(Interarrival jitter)：RTP數據包接受時間的統計方差估計.
上次SR時間戳(Last SR,LSR)：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特, 如果目前還沒收到SR包, 則該域清零.
上次SR以來的延時(Delay since last SR,DLSR)：上次從SSRC_n收到SR包到發送本報告的延時.