一.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包建立的.
1.根据这个db可以填充Reception Report,并发送给对方
2.可以维护Participant Information
3.可以用于进行lip synchronization.
二.RTCP的传输
1.必须发送RTCP compound包,
2.odd ports, 是RTP port + 1(最近不要求必须是奇数,也不要求必须大1了)
3.所有的参与者应当送出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(8)
1.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通常意味着丢包的开始
2.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时钟
3.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 PRIV.
4.RTCP BYE: Membership Control
通常用于指示会话中的某个成员正在离开.
但是RTCP BYE的含义在某种程度上是依赖于应用的,应用通常有其他的控制协议如SIP,H323等控制会话.
记住BYE不终止会话成员的关系,只是表示正在离开,并且不保证传输肯定到达.
PT=203
Format:
固定头
*{
SSRC
}
可选长度,可选原因
5.RTCP APP: Application-Defined RTCP Packets
PT=204
6.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
1.所有的包必须是复合包
2.版本必须是2
3.复合包开始的RTCP Packet必须是SR和RR
4.如果需要Padding,则只有最后一个packet是padding的.
5.所有的RTCP packets的长度必须等于复合RTCP包的长度.
六.参与者数据库
参与者和会话的信息
1.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).
1.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所占比例发生变化时,报告间隔应当重新计算.
2.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来计算.
3.Forward Reconsideration
当会话中同时到来大量的Participant时,造成网络拥塞(Called as "step join"),为此使用Forward Reconsideration
方法:
在每次发送前,根据当前的会话信息重新计算发送时间,
- if (current_time >= next_rtcp_check_time) {
- 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
当大量的人同时离开时,导致RTCP所占带宽过低(Called as "step leave").
为此,当BYE来时,立即重新计算下个包的发送时间.
5.BYE Reconsideration
大量的BYE,为此可以:延迟BYE的发送,或者干脆不发送.
6.Comments on Reconsideration
各个实现应该考虑这个问题,并尽可能的使用各个Reconsideration.
7.Common Implementation Problems
1)没有正确的考虑参与者的数目,固定的Reporting Interval会导致流量呈线性增长.
2)Reporting interval没有随机化.有潜在的可能:同步他们的reports,导致
3)在带宽计算时未考虑Headers(IP,UDP)等
4)padding使用不正确
(rageliu) |
