180

更新時間: 2013-08-29

廣告

概述
RTCP:RTP 控制協議 (RTCP:RTP Control Protocol)
RTP 控制協議(RTCP)採用與數據包相同的分發機制,將控制包周期性傳輸到所有會話參與者中。底層協議必須提供數據和控制包的多路發送,例如使用不同的 UDP 埠號。
RTCP 提供數據分發質量反饋信息,這是 RTP 作為傳輸協議的部分功能並且它涉及到了其它傳輸協議的流控制和擁塞控制。
RTCP 為 RTP 源攜帶一個持久性傳輸層標識符,稱為規範名或 CNAME。由於一旦發現衝突或程序重啟時, SSRC 標識符會隨之改變,所以接收方需要 CNAME 來跟蹤每一個參與者。同時接收方還要求 CNAME 能夠與一組相關 RTP 會話中來自於給定參與者的多重數據流相關聯,例如同步視頻和音頻。
上述前兩個功能要求所有的參與者都要發送 RTCP 包,因此必須控制速率以便 RTP 按比例增加大量的參與者。通過每一個參與者發送各自的控制包給其它所有參與者,每一個參與者能夠獨立觀察到參與者數量,該數量可用來計算控制包的發送速率。
OPTIONAL 功能用於傳送最少會話控制信息,例如在用戶界面顯示參與者標識。這對於「鬆散受控」會話(在沒有成員控制或闡述協商的情況下,參與者可以加入或退出該會話)是非常有用的。
上述功能 1 - 3 適用於所有環境,尤其是 IP 組播環境。RTP 應用程序設計者應該避免設計只能工作於單播模式並且不能增加到大量數量的機制。在某些情況下如單向鏈接中,不可能有來自接收方的反饋,所以 RTCP 的傳輸就可能由發送方和接收方分別獨立控制。
協議結構
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 的倍數的有效性校驗)。
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的包格式
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加密時使用)
Packet Validation
⒈所有的包必須是複合包
⒉版本必須是2
⒊複合包開始的RTCP Packet必須是SR和RR
⒋如果需要Padding,則只有最後一個packet是padding的.
⒌所有的RTCP packets的長度必須等於複合RTCP包的長度.
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使用不正確

廣告