通過IP多播方式建立的一個會議，每個參與者通過某些分配機制（不在本協議討論範圍中）得到一個組地址和2個端口號，一個端口號用來傳送RTP數據，即音頻數據，另一個用來傳輸RTCP控制數據。如果需要加密，可根據本協議生成密鑰。
會議的每個參與者每隔20ms發送一段音頻數據，放在RTP包中。RTP包又通過UDP包傳輸。RTP包頭中定義了音頻文件的編碼方式，以便參與者改變自己的編碼方式以適應網絡傳輸（如編碼質量低以適應低帶寬傳輸）。
INTERNET會產生丟包和延遲，所以RTP包頭中包含了時間信息和一個序號，序號可以用來使接受方預測丟包的情況。
在本例中，由於會議不時有成員加入或離開，所以每個接受方會每隔一段時間報告一次接受情況。這個信息有可能被用來控制編碼方式以適應帶寬。當某個成員發出BYE的RTCP包時，該成員離開該會議。
音頻、視頻信息通過不同的RTP會話（session）傳輸，即二者是分開傳輸的。同時對於每一個傳輸，都有2個端口用來傳送RTP數據和RTCP控制信息。
這樣做的目的是因爲接受者可能由於帶寬限制，只夠接受音頻數據，或他只想接受一種數據。
RTP會話 （RTP SESSION):
多個參與者通過RTP協議通信，這就形成了一個RTP會話。對於每個參與者來說，RTP會話被一個地址和一對端口號定義。在多媒體會話中，不同的流建立不同的RTP會話（如：音頻的會話，視頻的會話）。每種不同的會話都有自己的RTCP包。不同的會話靠不同的傳輸地址來區分
同步化源（SYNCHRONIZATION SOURCE）：
即SSRC，可理解爲信號的源頭，如一個麥克風輸入或一個攝像頭輸入，在整個會話中有一個獨一無二的標識符。從它輸出的信號都經過它的同步處理，以使接受方能實現對源的控制，如回放功能。若一個服務器有多個輸入，如多個攝像頭信號，那麼每個攝像頭都有一個SSRC。SSRC標識符靠RTCP綁定。
供流源（CONTRIBUTING SOURCE ）：
即CSRC，經由混流服務器（MIXER)輸出的一個流通常由多個分流匯成，每個分流都有一個供流源。（詳見第8章）
，CSRC字段只有當MIXER插入時才產生。
RTP協議中，多路傳輸的目標地址由定義RTP會話的網絡地址＋端口號確定。
音視頻傳輸不能定義在同一個RTP會話中，因爲負載類型不同而SSRC標識符相同會引起一系列的問題。
SSRC: 32 bits
同步化源標識符，即此RTP包的發出者（個人理解）。因爲一個RTP會話中不能有2個相同的SSRC ，所以當發送者傳輸地址改變時此值需重新生成，以防止形成循環
CSRC list: 0 to 15 items, 32 bits each
字段頭中CSRC COUNT項給出了該項中ITEM的數量。
當包通過MIXER時由MIXER將原來包中的SSRC標識符作爲CSRC插入，而將MIXER自己的SSRC作爲新的SSRC項。
RTCP協議基於每隔一段時間給會話的所有參與者發送一些控制包的機制。下層協議必須支持數據和控制包的多路傳輸。比如通過UDP協議發送數據到多個端口。
提供數據分佈服務質量的反饋。這是RTP作爲傳輸協議必不可少的部分。同時也與別的協議中擁塞和流量控制功能有關。反饋功能主要通過“接受者報告”和“發送者報告”實現。在某些時候，第三方也可以通過RTCP包實現對網絡的監控
RTCP包中攜帶着RTP源的永久標識符信息存放爲CNAME（canonical name）項。在會話中的RTP源有可能因爲SSRC衝突或者因爲程序重啓而重新生成一個SSRC，但它的CNAME是不變的，這樣就可以追蹤會話的每個參與者
前2個功能均要求會議的參與者發送RTCP包。所以，發送速率應該得到控制以適應有大規模參與者的RTP會話。每個參與者必須可以獨立地知道會話的參與者數量，來決定發包的速率
第四個，同時也是一個可選功能項，通過RTCP協議傳遞最少的會話控制信息，比如用戶界面上顯示的參與者身份。這個功能在參與者可隨時加入或離開的會話時非常有用，因爲可以傳遞控制信息到每個參與者。該功能用於IP多播環境
以下是RTCP包的5種類型：
SR: Sender report 會話中頻繁發送包的參與者的報告
RR: Receiver report 非頻繁發包的參與者發送的接受方統計數據
SDES: Source description items 發送源描述項，包括CNAME信息
BYE: 終止參與會議信息的包
APP: 用於特定進程的包
每個RTCP包都有一個包頭，然後根據包的類型的不同，包頭後跟着不同長度的結構化的數據項，但這些數據項都有一個32位的包的邊界。
RTCP包通過下層協議傳輸時，相鄰的包之間沒有分隔符。比如用UDP傳輸時，並沒有給出UDP包中RTCP包的數量，而僅有一個總長度
幾個RTCP包在通過下層協議傳輸時，對包的排列次序和組合方式沒有要求，但有以下限制：
接受方數據統計（包含於SR和RR內）必須在帶寬允許下儘可能多地發送，以使統計更加精確。因此，每個RTCP包集合必須有一個SR或RR的包。
新的接收者必須儘快得到源的CNAME並聯系媒體求得同步。每個RTCP包集合必須包含SDES CNAME。
綜上所述，每個RTCP包都必須以混合包的形式傳輸，每個混合包中必須至少包含2個獨立的包，包的形式按下列推薦：
Encryption prefix: 混合包如果需要加密，前面必須有個32位加密前綴。
SR or RR: 混合包的第一個包必須爲其中之一。
Additional RRs: 如果接受方數據中的源的數目超過了31，就需在正常的RR或SR後添加發送超出部分的信息
SDES: 每個混合包中必須包含的包類型，除了CNAME項，可視帶寬情況在SDES包中加入更多源的信息。
BYE or APP: BYE類型的RTCP包必須是SSRC/CSRC發送的最後一個包，APP包爲其他類型的RTCP包。
綜上所述，每個RTCP包都必須以混合包的形式傳輸，每個混合包中必須至少包含2個獨立的包，包的形式按下列推薦：
Encryption prefix: 混合包如果需要加密，前面必須有個32位加密前綴。
SR or RR: 混合包的第一個包必須爲其中之一。
Additional RRs: 如果接受方數據中的源的數目超過了31，就需在正常的RR或SR後添加發送超出部分的信息
SDES: 每個混合包中必須包含的包類型，除了CNAME項，可視帶寬情況在SDES包中加入更多源的信息。
BYE or APP: BYE類型的RTCP包必須是SSRC/CSRC發送的最後一個包，APP包爲其他類型的RTCP包。
RTP包的接受者發送REPORT的RTCP包來反饋服務質量。REPORT包分爲2種，RR和SR。兩者的唯一區別是，發送後者的站點不僅是包的接受者同時也是活躍的包發送者。所以SR比RR要多20字節，用來攜帶發送者信息
sdes ：
包頭後的每一項都是對一個SSRC/CSRC的描述，其中包含一系列子項。每個子項都具有下列格式：
8位子項類型標識
8位該子項的描述文本長度，不包括子項頭這2個字節
描述文本，以UTF-8方式編碼，最大長度255字節
同SSRC一樣，在一個RTP會話中，CNAME也是全局唯一的，用來綁定應用程序與該站點的連接，通常具有以下形式："[email protected]" "[email protected]"