rtcp

RTCP：RTP 控制協議（RTCP：RTP Control Protocol）

RTCP 提供數據分發質量反饋信息，這是 RTP 作為傳輸協議的部分功能並且它涉及到了其它傳輸協議的流控制和擁塞控制。

RTCP 為 RTP 源攜帶一個持久性傳輸層標識符，稱為規範名或 CNAME。由於一旦發現衝突或程序重啟時， SSRC 標識符會隨之改變，所以接收方需要 CNAME 來跟蹤每一個參與者。同時接收方還要求 CNAME 能夠與一組相關 RTP 會話中來自於給定參與者的多重數據流相關聯，例如同步視頻和音頻。

上述前兩個功能要求所有的參與者都要發送 RTCP 包，因此必須控制速率以便 RTP 按比例增加大量的參與者。通過每一個參與者發送各自的控制包給其它所有參與者，每一個參與者能夠獨立觀察到參與者數量，該數量可用來計算控制包的發送速率。

OPTIONAL 功能用於傳送最少會話控制信息，例如在用戶界面顯示參與者標識。這對於“鬆散受控”會話（在沒有成員控制或闡述協商的情況下，參與者可以加入或退出該會話）是非常有用的。

上述功能 1 － 3 適用於所有環境，尤其是 IP 組播環境。RTP 應用程序設計者應該避免設計只能工作於單播模式並且不能增加到大量數量的機制。在某些情況下如單向鏈接中，不可能有來自接收方的反饋，所以 RTCP 的傳輸就可能由發送方和接收方分別獨立控制。

定義

單位（bit）

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的五種分組類型

結束分組BYE表示關閉一個數據流。

特定應用分組APP使應用程序能夠定義新的分組類型、。

接收端報告分組RR用來使接收端周期性地向所有的點用多播方式進行報告。接收端每收到一個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使用不正確