|
一.Introduction An RTCP implementation has three parts: the packet formats, the timing rules, and the participant database Packet Formats: Timing Rules: 所有的RTCP復(fù)合包被周期性送出,這個(gè)周期成為reporting interval,所有的RTCP活動(dòng)都是以這個(gè)間隔發(fā)生的, 除了update of source description 和lip synchronization information,以及在這個(gè)interval內(nèi)發(fā)生的reception quality statistics. Participant Database: 基于收到的RTCP包建立的. 1.根據(jù)這個(gè)db可以填充Reception Report,并發(fā)送給對(duì)方 2.可以維護(hù)Participant Information 3.可以用于進(jìn)行l(wèi)ip synchronization. 二.RTCP的傳輸 1.必須發(fā)送RTCP compound包, 2.odd ports, 是RTP port + 1(最近不要求必須是奇數(shù),也不要求必須大1了) 3.所有的參與者應(yīng)當(dāng)送出compound packets,也接收所有其他的participants發(fā)送的compound packets, Note that feedback is sent to all participants in a multiparty session: either unicast to a translator, which then redistributes the da 三.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(8) 1.RR(Receiver Report) Reception quality reporting:所有發(fā)送RTP數(shù)據(jù)的Sender的信息,每個(gè)block包含一個(gè)SSRC的RTP接受質(zhì)量報(bào)告 PT = 201 Format: Reporter SSRC *{//一個(gè)Reporter Block 固定頭 24 octets的內(nèi)容 包括以下部分: reportee SSRC: cumulative number of packets lost :24bit的有符號(hào)數(shù),從會(huì)話開始到現(xiàn)在期望收到-實(shí)際收到(可為負(fù)) extended highest sequence number :per session loss fraction :per interval, 取整 [丟包/期望收到數(shù)目 * 256](如果丟包為負(fù)值,則結(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) } RR的解釋 這是一個(gè)接收質(zhì)量的反饋,對(duì)Sender和其他的第三方如網(wǎng)絡(luò)的monitor等都有意義 如: 1)可以計(jì)算Round-trip Time (RR收到時(shí)間-LSR - DLSR),round-trip time的估計(jì)是很重要的 2)Lost fraction:短期內(nèi),對(duì)媒體格式的選擇有參考 3)Jitter:突然增大的Jitter通常意味著丟包的開始 2.SR(Sender Report) Sender Report 提供了有關(guān)Sender所發(fā)送的媒體的信息,主要用于進(jìn)行多個(gè)媒體流同步等. PT = 200 Format: 固定頭 Reporter SSRC NTP Timestamp(2 octets):發(fā)送SR的NTP RTP Timestamp: 與previous field同一時(shí)刻,但是單位是RTP Media clock Sender's packet count:自會(huì)話開始 Sender's octet count:自會(huì)話開始 SR的解釋 計(jì)算速率等 媒體時(shí)鐘和NTP時(shí)鐘 3.SDES: Source Description 用于提供參與者的詳細(xì)信息,通常是人可讀的,如email,電話等,依賴于應(yīng)用. PT = 202 Format: 固定頭 *{ SSRC/CSRC List of SDES items } Items中每個(gè)entry如下: Type Length content 8 8 Type == 0 表示Lists結(jié)束 RFC中規(guī)定了一些Items如:CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, and PRIV. 4.RTCP BYE: Membership Control 通常用于指示會(huì)話中的某個(gè)成員正在離開. 但是RTCP BYE的含義在某種程度上是依賴于應(yīng)用的,應(yīng)用通常有其他的控制協(xié)議如SIP,H323等控制會(huì)話. 記住BYE不終止會(huì)話成員的關(guān)系,只是表示正在離開,并且不保證傳輸肯定到達(dá). PT=203 Format: 固定頭 *{ SSRC } 可選長度,可選原因 5.RTCP APP: Application-Defined RTCP Packets PT=204 6.Compound Packet 以上的RTCP包從不單獨(dú)發(fā)送,它們被打包成復(fù)合包(Compound Packet)來發(fā)送,有幾個(gè)規(guī)則. 1)對(duì)活動(dòng)的發(fā)送者(active da 2)然后是SDES,SDES必須包含一個(gè)CNAME,其他可選. 3)如果有BYE的話,放到最后.其他的包可以隨意. RTCP Packet從來不單獨(dú)傳輸,他們按照一定的規(guī)則總是組成Compound Packet來傳送.下面介紹這個(gè)規(guī)則: 1)最前面可以有個(gè)可選的32位值(在RTCP compound packet加密時(shí)使用) 四.Security and Privacy SDES的傳輸中暴露隱私,這是個(gè)問題.但是CNAME是必須的. 五.Packet Validation 1.所有的包必須是復(fù)合包 2.版本必須是2 3.復(fù)合包開始的RTCP Packet必須是SR和RR 4.如果需要Padding,則只有最后一個(gè)packet是padding的. 5.所有的RTCP packets的長度必須等于復(fù)合RTCP包的長度. 六.參與者數(shù)據(jù)庫 參與者和會(huì)話的信息 1.RTCP的全局配置信息 1)The RTP bandwidth 1)RTCP所占總帶寬的比例(這意味必須知道RTP所占的總帶寬):default 0.05 2)發(fā)送間隔:default 5s(最小) 3)發(fā)送部分所占的比例: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 da 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 da 9)A flag indicating whether the implementation has sent any RTCP packets at all. 10)The number of packets and octets of RTP da 11)The last sequence number it used. 12)The correspondence between the RTP clock it is using and an NTP-format timestamp. 會(huì)話中每個(gè)成員的信息 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 da 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, da 七.Timing Rules 總的目標(biāo)是限制RTCP占RTP會(huì)話量的一小部分,通常是5%.在這個(gè)目標(biāo)的前提下,參與者送出RTCP packet的速率是不固定的,而是變化了,如對(duì)有大量的listener的Internet Radio,客戶端可能幾分鐘才發(fā)送,而對(duì)two-party的電話可能是幾秒鐘. 有一些規(guī)則可以參考,這些規(guī)則可以確保實(shí)現(xiàn)的可縮放性(Scalability). 1.Reporting Interval 根據(jù)以下幾個(gè)部分來計(jì)算: 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 在計(jì)算時(shí), SNo:Sender Number ANo:所有參與者數(shù)目 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 } 當(dāng)會(huì)話中的參與者的數(shù)目或者sender所占比例發(fā)生變化時(shí),報(bào)告間隔應(yīng)當(dāng)重新計(jì)算. 2.Basic Transmission Rules 基本的傳輸規(guī)則就是: 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 對(duì)于有很多參與者,并且數(shù)目還在變化的會(huì)話,每次發(fā)送當(dāng)前的RTCP Packet后,根據(jù)得到的Participants Number來計(jì)算. 3.Forward Reconsideration 當(dāng)會(huì)話中同時(shí)到來大量的Participant時(shí),造成網(wǎng)絡(luò)擁塞(Called as "step join"),為此使用Forward Reconsideration 方法: 在每次發(fā)送前,根據(jù)當(dāng)前的會(huì)話信息重新計(jì)算發(fā)送時(shí)間, if (current_time >= next_rtcp_check_time) {//1.21828是一個(gè)補(bǔ)償因子 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 } } 4.Reverse Reconsideration 當(dāng)大量的人同時(shí)離開時(shí),導(dǎo)致RTCP所占帶寬過低(Called as "step leave"). 為此,當(dāng)BYE來時(shí),立即重新計(jì)算下個(gè)包的發(fā)送時(shí)間. 5.BYE Reconsideration 大量的BYE,為此可以:延遲BYE的發(fā)送,或者干脆不發(fā)送. 6.Comments on Reconsideration 各個(gè)實(shí)現(xiàn)應(yīng)該考慮這個(gè)問題,并盡可能的使用各個(gè)Reconsideration. 7.Common Implementation Problems 1)沒有正確的考慮參與者的數(shù)目,固定的Reporting Interval會(huì)導(dǎo)致流量呈線性增長. 2)Reporting interval沒有隨機(jī)化.有潛在的可能:同步他們的reports,導(dǎo)致 3)在帶寬計(jì)算時(shí)未考慮Headers(IP,UDP)等 4)padding使用不正確 |
|
|
