協定概況
RTCP：RTP 控制協定 （RTCP：RTP Control Protocol）
RTCP 提供數據分發質量反饋信息，這是 RTP 作為傳輸協定的部分功能並且它涉及到了其它傳輸協定的流控制和擁塞控制。
RTCP 為 RTP 源攜帶一個持久性傳輸層標識符，稱為規範名或 CNAME。由於一旦發現衝突或程式重啟時， SSRC 標識符會隨之改變，所以接收方需要 CNAME 來跟蹤每一個參與者。同時接收方還要求 CNAME 能夠與一組相關 RTP 會話中來自於給定參與者的多重數據流相關聯，例如同步視頻和音頻。
上述前兩個功能要求所有的參與者都要傳送 RTCP 包，因此必須控制速率以便 RTP 按比例增加大量的參與者。通過每一個參與者傳送各自的控制包給其它所有參與者，每一個參與者能夠獨立觀察到參與者數量，該數量可用來計算控制包的傳送速率。
OPTIONAL 功能用於傳送最少會話控制信息，例如在用戶界面顯示參與者標識。這對於“鬆散受控”會話（在沒有成員控制或闡述協商的情況下，參與者可以加入或退出該會話）是非常有用的。
上述功能 1 － 3 適用於所有環境，尤其是 IP 組播環境。RTP 應用程式設計者應該避免設計只能工作於單播模式並且不能增加到大量數量的機制。在某些情況下如單向連結中，不可能有來自接收方的反饋，所以 RTCP 的傳輸就可能由傳送方和接收方分別獨立控制。
協定結構
定義
單位（bit）
| version | p | rc | packet |
| 2 | 3 | 8 | 16 |
Length
Version ― 識別 RTP 版本。RTP 數據包中的該值與 RTCP 數據包中的一樣。當前規範定義的版本值為 2。
P ― 間隙（Padding）。設定時， RTCP 數據包包含一些其它 padding 八位位組，它們不屬於控制信息。Padding 的最後八位是用於計算應該忽略多少間隙八位位組。一些加密算法中需要計算固定塊大小時也可能需要使用 Padding 欄位。在一個複合 RTCP 數據包中，只有最後的個別數據包中才需要使用 padding ，這是因為複合數據包是作為一個整體來加密的。
RC ― 接收方報告計數。包含在該數據包中的接收方報告塊的數量，有效值為 0。
Packet type ― 包括常量 200 ，識別這是一個 RTCP SR 數據包。
Length ― RTCP 數據包的大小（32 位字減去 1），包含頭和任意間隙 （偏移量的引入使得 0 成為有效值，並避免了掃描複合 RTCP 數據包過程中的無限循環現象，而採用 32 位字計數方法則避免了對 4 的倍數的有效性校驗）。
RTCP的分組類型
下表為RTCP的五種分組類型
| 類型 | 縮寫表示 | 意義 |
| 200 | SR（Sender Report） | 傳送端報告 |
| 201 | RR（Receiver Roport） | 接收端報告 |
| 202 | SDES（Source Descripition Items） | 源點 |
| 203 | BYE | 結束 |
| 204 | APP（Application） | 特定套用 |
結束分組BYE表示關閉一個數據流。
特定套用分組APP使應用程式能夠定義新的分組類型、。
接收端報告分組R R用來使接收端周期性地向所有的點用多播方式進行報告。接收端每收到一個RTP流（一次會話包含多個RTP流）就產生一個接收端報告分組RR。RR分組的內容有：所收到的RTP流的SSRC；該RTP流的分組丟失率（若分組丟失率太高，傳送端就應該適當地降低傳送分組的速率）；在該RTP流中的最後一個RTP分組的序號；分組到達時間間隔的抖動等；
傳送RR分組有兩個目的。第一，可以使所有的接收端和傳送端了解當前網路的狀態。第二，可以使所有傳送RTCP分組的站點自適應地調整自己傳送RTCP分組的速率，使得起控制作用的RTCP分組不要過多地影響傳送套用數據的RTP分組在網路中的傳輸。通常是使RTCP分組的通信量不超過網路中工大數據分組的數據量的5%，而接收端的通信量又應小於所有RTCP分組的通信量的75%。
傳送端報告分組SR用來使傳送端周期性地向所有接收端用多播方式進行報告。傳送端每傳送一個RTP流就要傳送一個傳送端報告分組SR。SR分組的內容有：該RTP流的SSRC；該RTP流中最新產生的RTP分組的時間戳和絕對時鐘時間（或牆上時鐘時間wall clock time）；該RTP流包含的分組數；該RTP流包含的位元組數。
絕對時鐘時間是必要的。因為RTP要求每一種媒體使用一個流。例如，要傳送視頻圖像和相應的聲音就需要傳送兩個流。有了絕對時鐘時間就可以進行圖像和聲音的同步。
源點描述分組SDES給出會話中參加者的描述，它包含參加者的規範名CNAME（Canonical NAME）。規範名是參加者的電子郵件地址的字元串。
其他相關協定
RTCP的實現
Introduction
An RTCP implementation has three parts: the packet formats,the timing rules,and the participant database
Packet Formats:
Timing Rules:
所有的RTCP複合包被周期性送出，這個周期稱為reporting interval，所有的RTCP活動都是以這個間隔發生的，除了update of source description 和lip synchronization information，以及在這個interval內發生的reception quality statistics.
Participant Database:
基於收到的RTCP包建立的.
⒈根據這個db可以填充Reception Report，並傳送給對方
⒉可以維護Participant Information
⒊可以用於進行lip synchronization.
RTCP的傳輸
⒈必須傳送RTCP compound包，
⒉odd ports，是RTP port + 1（最近不要求必須是奇數，也不要求必須大1了）
⒊所有的參與者應當送出compound packets，也接收所有其他的participants傳送的compound packets,
Note that feedback is sent to all participants in a multiparty session: either unicast to a translator,which then redistributes the data,or directly via multicast. The peer-to-peer nature of RTCP gives each participant in a session knowledge of all other participants: their presence,reception quality,and—optionally—personal details such as name,e-mail address,location,and phone number.
RTCP的包格式
SR,RR,SDES,BYE,APP
通用頭（固定頭）：4 octets
v p ic pt length(be measured in units of 32-bits word)
2 1 5 8 16
---------- p c⑻
⒈RR(Receiver Report)
Reception quality reporting：所有傳送RTP數據的Sender的信息，每個block包含一個SSRC的RTP接受質量報告
PT = 201
Format:
Reporter SSRC
*{//一個Reporter Block
固定頭
24 octets的內容
包括以下部分：
reportee SSRC:
cumulative number of packets lost :24bit的有符號數，從會話開始到現在期望收到-實際收到（可為負）
extended highest sequence number :per session
loss fraction :per interval，取整 [丟包/期望收到數目 * 256]（如果丟包為負值，則結果設為0)
interarrival jitter :
last sender report timestamp(LSR) ：從reportee端最後收到的Sender Report中NTP timestamp的中32bits.（無則為0)
delay since last sender report(DLSR) ：最後收到SR和傳送RR之間的間隔，以1/65536為單位（否則為0)
}
RR的解釋
這是一個接收質量的反饋，對Sender和其他的第三方如網路的monitor等都有意義
如：
1）可以計算Round-trip Time (RR收到時間-LSR - DLSR),round-trip time的估計是很重要的
2）Lost fraction：短期內，對媒體格式的選擇有參考
3）Jitter：突然增大的Jitter通常意味著丟包的開始
SR(Sender Report)
Sender Report 提供了有關Sender所傳送的媒體的信息，主要用於進行多個媒體流同步等.
PT = 200
Format:
固定頭
Reporter SSRC
NTP Timestamp（2 octets）：傳送SR的NTP
RTP Timestamp: 與previous field同一時刻，但是單位是RTP Media clock
Sender's packet count：自會話開始
Sender's octet count：自會話開始
SR的解釋
計算速率等
媒體時鐘和NTP時鐘
⒊SDES: Source Description
用於提供參與者的詳細信息，通常是人可讀的，如email，電話等，依賴於套用.
PT = 202
Format:
固定頭
*{
SSRC/CSRC
List of SDES items
}
Items中每個entry如下：
Type Length content
8 8
Type == 0 表示Lists結束
RFC中規定了一些Items如：CNAME,NAME,EMAIL,PHONE,LOC,TOOL,NOTE,and PRⅣ.
⒋RTCP BYE: Membership Control
通常用於指示會話中的某個成員正在離開.
但是RTCP BYE的含義在某種程度上是依賴於套用的，套用通常有其他的控制協定如SIP,H323等控制會話.
記住BYE不終止會話成員的關係，只是表示正在離開，並且不保證傳輸肯定到達.
PT=203
Format:
固定頭
*{
SSRC
}
可選長度，可選原因
⒌RTCP APP: Application-Defined RTCP Packets
PT=204
⒍Compound Packet
以上的RTCP包從不單獨傳送，它們被打包成複合包（Compound Packet）來傳送，有幾個規則.
1）對活動的傳送者（active data sender),compound必須以SR開始，否則以RR開始，即使沒有數據接收和傳送.後面跟著*個RR.
2）然後是SDES,SDES必須包含一個CNAME，其他可選.
3）如果有BYE的話，放到最後.其他的包可以隨意.
RTCP Packet從來不單獨傳輸，他們按照一定的規則總是組成Compound Packet來傳送.下面介紹這個規則：
1）最前面可以有個可選的32位值（在RTCP compound packet加密時使用）
Security and Privacy
SDES的傳輸中暴露隱私，這是個問題.但是CNAME是必須的.
Packet Validation
⒈所有的包必須是複合包
⒉版本必須是2
⒊複合包開始的RTCP Packet必須是SR和RR
⒋如果需要Padding，則只有最後一個packet是padding的.
⒌所有的RTCP packets的長度必須等於複合RTCP包的長度.
相關資料庫
參與者和會話的信息
⒈RTCP的全局配置信息
1）The RTP bandwidth
1）RTCP所占總頻寬的比例（這意味必須知道RTP所占的總頻寬）：default 0.05
2）傳送間隔：default 5s（最小）
3）傳送部分所占的比例：default 0.025
4）The average size of all RTCP packets sent and received by this participant.
5）The number of members in the session,the number of members when this participant last sent an RTCP packet,and the fraction of those who have sent RTP data packets during the preceding reporting interval.
6）The time at which the implementation last sent an RTCP packet,and the next scheduled transmission time.
8）A flag indicating whether the implementation has sent any RTP data packets since sending the last two RTCP packets.
9）A flag indicating whether the implementation has sent any RTCP packets at all.
10）The number of packets and octets of RTP data it has sent.
11）The last sequence number it used.
12）The correspondence between the RTP clock it is using and an NTP-format timestamp.
會話中每個成員的信息
1）SSRC identifier.
2）Source description information: the CNAME is required; other information may be included (note that these values are not null-terminated,and care must be taken in their handling).
3）Reception quality statistics (packet loss and jitter),to allow generation of RTCP RR packets.
4）Information received from sender reports,to allow lip synchronization (see Chapter 7）.
5）The last time this participant was heard from so that inactive participants can be timed out.
6）A flag indicating whether this participant has sent data within the current RTCP reporting interval.
7）The media playout buffer,and any codec state needed (see Chapter 6,Media Capture,Playout,and Timing).
8）Any information needed for channel coding and error recovery—for example,data awaiting reception of repair packets before it can
Timing Rules
總的目標是限制RTCP占RTP會話量的一小部分，通常是5%.在這個目標的前提下，參與者送出RTCP packet的速率是不固定的，而是變化了，如對有大量的listener的Internet Radio，客戶端可能幾分鐘才傳送，而對two-party的電話可能是幾秒鐘.
有一些規則可以參考，這些規則可以確保實現的可縮放性（Scalability).
⒈Reporting Interval
根據以下幾個部分來計算：
1）.The bandwidth allocated to RTCP:5%通常 * Session頻寬
2）.The average size of RTCP packets sent and received：包括所有頭（UDP,IP)
3）.The total number of participants and the fraction of those participants who are senders
在計算時，
SNo:Sender Number
ANo：所有參與者數目
RNo:Receiver Number
Intl:Interval
ARS:average RTCP size
RW:RTCP bandwidth
if (senders > 0 && senders <= （25% of total number of participants)
{
if (we are sending)
{
Interval = average RTCP size * senders / （25% of RTCP bandwidth)
}
else
{
Interval = average RTCP size * receivers / （75% of RTCP bandwidth)
}
}
else if ((senders = 0) or (senders > （25% of total number of participants))
{
Interval = average RTCP size * total number of members / RTCP bandwidth
}
這樣可以確保Sender即使很少的情況下也可以確保25%的頻寬，能夠送出足夠的lip synchronization信息
If (Interval < minimum interval)
{
Interval = minimum interval
}
當會話中的參與者的數目或者sender所占比例發生變化時，報告間隔應當重新計算.
⒉Basic Transmission Rules
基本的傳輸規則就是：
I = (Interval * random[0.5,1.5])
if (this is the first RTCP packet we are sending) {
I *= 0.5
}
next_rtcp_send_time = current_time + I
對於有很多參與者，並且數目還在變化的會話，每次傳送當前的RTCP Packet後，根據得到的Participants Number來計算.
⒊Forward Reconsideration
當會話中同時到來大量的Participant時，造成網路擁塞（Called as "step join")，為此使用Forward Reconsideration
方法：
在每次傳送前，根據當前的會話信息重新計算傳送時間，
if (current_time >= next_rtcp_check_time) {//1.21828是一個補償因子
new_rtcp_send_time = (rtcp_interval() / 1.21828） + last_rtcp_send_time
if (current_time >= new_rtcp_send_time) {
send RTCP packet
next_rtcp_check_time = (rtcp_interval() /1.21828） + current_time
} else {
next_rtcp_check_time = new_send_time
}
}
⒋Reverse Reconsideration
當大量的人同時離開時，導致RTCP所占頻寬過低（Called as "step leave").
為此，當BYE來時，立即重新計算下個包的傳送時間.
⒌BYE Reconsideration
大量的BYE，為此可以：延遲BYE的傳送，或者乾脆不傳送.
⒍Comments on Reconsideration
各個實現應該考慮這個問題，並儘可能的使用各個Reconsideration.
⒎Common Implementation Problems
1）沒有正確的考慮參與者的數目，固定的Reporting Interval會導致流量呈線性增長.
2）Reporting interval沒有隨機化.有潛在的可能：同步他們的reports，導致
3）在頻寬計算時未考慮Headers(IP,UDP）等
4）padding使用不正確
