編輯“RTCP”

'''RTP'''控制協(xié)議采用與數(shù)據(jù)包相同的分發(fā)機制，將控制包周期性傳輸?shù)剿袝拝⑴c者中，底層協(xié)議必須提供數(shù)據(jù)和控制包的多路發(fā)送，并提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息，這是RTP作為傳輸協(xié)議的部分功能，并且它涉及到了其它傳輸協(xié)議的流控制和擁塞控制，RTCP攜帶一個持久性傳輸層標(biāo)識符，稱為規(guī)范名或[[CNAME]]，由于一旦發(fā)現(xiàn)沖突或[[程序]]重啟時，SSRC標(biāo)識符會隨之改變，所以接收方需要CNAME來跟蹤每一個參與者。同時接收方還要求CNAME能夠與一組相關(guān)RTP會話中來自于給定參與者的多重數(shù)據(jù)流相關(guān)聯(lián)。
== RTCP概況 ==
*RTCP功能要求所有的參與者都要發(fā)送RTCP包，因此必須控制速率以便[[RTP]]按比例增加大量的參與者，通過每一個參與者發(fā)送各自的控制包給其它所有參與者，每一個參與者能夠獨立觀察到參與者數(shù)量，該數(shù)量可用來計算控制包的發(fā)送速率。
*OPTIONAL功能用于傳送最少會話控制信息，例如在用戶界面顯示參與者標(biāo)識，這對于“松散受控”會話（在沒有成員控制或闡述協(xié)商的情況下，參與者可以加入或退出該會話）是非常有用的。
*上述功能適用于所有環(huán)境，尤其是[[IP]]組播環(huán)境，RTP應(yīng)用程序設(shè)計者應(yīng)該避免設(shè)計只能工作于單播模式并且不能增加到大量數(shù)量的機制，在某些情況下如單向鏈接中不可能有來自接收方的反饋，所以RTCP的傳輸就可能由發(fā)送方和接收方分別獨立控制。

== RTCP分組類型 ==
*RTCP分為下面五種類型
類型 縮寫表示 意義

200	SR	發(fā)送端報告

201	RR	接收端報告

202	SDES	遠點

203	BYE	結(jié)束

204	APP	特定應(yīng)用

結(jié)束分組BYE表示關(guān)閉一個數(shù)據(jù)流。
*特定應(yīng)用分組APP使[[應(yīng)用程序]]能夠定義新的分組類型，接收端報告分組RR用來使接收端周期性地向所有的點用多播方式進行報告，接收端每收到一個RTP流就產(chǎn)生一個接收端報告分組RR，該RTP流的分組丟失率（若分組丟失率太高，發(fā)送端就應(yīng)該適當(dāng)?shù)亟档桶l(fā)送分組的速率）；在該RTP流中的最后一個RTP分組的序號；分組到達時間間隔的抖動等。
*發(fā)送RR分組有兩個目的，第一可以使所有的接收端和發(fā)送端了解當(dāng)前網(wǎng)絡(luò)的狀態(tài)。第二可以使所有發(fā)送RTCP分組的站點自適應(yīng)地調(diào)整自己發(fā)送RTCP分組的速率，使得起控制作用的RTCP分組不要過多地影響傳送應(yīng)用數(shù)據(jù)的RTP分組在網(wǎng)絡(luò)中的傳輸，通常是使RTCP分組的通信量不超過網(wǎng)絡(luò)中工大[[數(shù)據(jù)]]分組的數(shù)據(jù)量的5%，而接收端的通信量又應(yīng)小于所有RTCP分組的通信量的75%。
*發(fā)送端報告分組SR用來使發(fā)送端周期性地向所有接收端用多播方式進行報告，發(fā)送端每發(fā)送一個RTP流就要發(fā)送一個發(fā)送端報告分組SR，SR分組的內(nèi)容有：該RTP流的SSRC，該RTP流中最新產(chǎn)生的RTP分組的時間戳和絕對時鐘時間該RTP流包含的分組數(shù)；該RTP流包含的字節(jié)數(shù)。絕對時鐘時間是必要的，因為RTP要求每一種媒體使用一個流。

== RTCP的實現(xiàn) ==
=== Introduction ===
An RTCP implementation has three parts: the packet formats, the timing rules, and the participant database

Packet Formats:

Timing Rules:

所有的RTCP復(fù)合包被周期性送出,這個周期稱為reporting interval,所有的RTCP活動都是以這個間隔發(fā)生的, 除了update of source description 和lip synchronization information,以及在這個interval內(nèi)發(fā)生的reception quality statistics。基于收到的RTCP包建立的：
#根據(jù)這個db可以填充Reception Report,并發(fā)送給對方
#可以維護Participant Information
#可以用于進行l(wèi)ip synchronization.
=== RTCP的傳輸 ===
#必須發(fā)送RTCP compound包,
#odd ports, 是RTP port + 1(最近不要求必須是奇數(shù),也不要求必須大1了)
#所有的參與者應(yīng)當(dāng)送出compound packets,也接收所有其他的participants發(fā)送的compound packets,
三.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

1.RR(Receiver Report)

Reception quality reporting:所有發(fā)送RTP數(shù)據(jù)的Sender的信息,每個block包含一個SSRC的RTP接受質(zhì)量報告

PT = 201

Format:

Reporter SSRC

{//一個Reporter Block

固定頭

24 octets的內(nèi)容

包括以下部分:

reportee SSRC:

cumulative number of packets lost :24bit的有符號數(shù),從會話開始到現(xiàn)在期望收到-實際收到(可為負)

extended highest sequence number :per session

loss fraction :per interval, 取整 [丟包/期望收到數(shù)目 * 256](如果丟包為負值,則結(jié)果設(shè)為0)

interarrival jitter :

last sender report timestamp(LSR) :從reportee端最后收到的Sender Report中NTP timestamp的中32bits.(無則為0)

delay since last sender report(DLSR) :最后收到SR和發(fā)送RR之間的間隔,以1/65536為單位(否則為0)

}

Items中每個entry如下:

Type Length content

8 8

Type == 0 表示Lists結(jié)束

RFC中規(guī)定了一些Items如:CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, and PRIV.
=== Packet Validation ===
#所有的包必須是復(fù)合包
#版本必須是2
#復(fù)合包開始的RTCP Packet必須是SR和RR
#如果需要Padding,則只有最后一個packet是padding的.
#所有的RTCP packets的長度必須等于復(fù)合RTCP包的長度.
=== 參與者數(shù)據(jù)庫 ===
參與者和會話的信息
#RTCP的全局配置信息
#The RTP bandwidth
#RTCP所占總帶寬的比例(這意味必須知道RTP所占的總帶寬):default 0.05
#發(fā)送間隔:default 5s(最小)
#發(fā)送部分所占的比例:default 0.025
#The average size of all RTCP packets sent and received by this participant. 
== 相關(guān)條目 ==
*[[GTP]]
*[[TCP]]
*[[SOAP]]
== 參考來源 ==
*http://baike.baidu.com/view/738138.htm
[[category:網(wǎng)絡(luò)協(xié)議|R]]