RTP/RTCP协议

最新推荐文章于 2025-02-20 17:33:41 发布

tiankong19999

最新推荐文章于 2025-02-20 17:33:41 发布

阅读量5.4w

点赞数 6

分类专栏：音视频音视频知识点文章标签： rtp

本文链接：https://blog.csdn.net/guoyunfei123/article/details/106261215

版权

音视频同时被 2 个专栏收录

45 篇文章

订阅专栏

音视频知识点

12 篇文章

订阅专栏

RTP/RTCP协议背景

流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。

流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，这样RTP和RTCP就相应的出现了。

实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量,在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

RTP/RTCP协议原理及工作机制

让我们先看一下RTP和RTCP在网络层次中的位置，以便我们更加清楚的了解该协议，如下图1-1所示：

图1-1 RTP&RTCP网络层次关系图

下面我们就从RTP以及RTCP的协议原理，数据包格式，工作机制三个方面来对该协议做一个基本的认识和了解：

RTP协议原理

RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RTP数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输，具体见本文2.2.1RTP数据格式；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务.

RTCP协议原理

RTCP原理是向会话中的所有成员周期性地发送控制包来实现的，应用程序通过接收这些控制数据包，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断.

RTCP协议的功能是通过不同的RTCP数据报文(具体描述的见2.2.2RTCP数据包格式)来实现的，主要有如下几种类型：

SR(Sender Report) 发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
RR(Receiver Report) 接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
SDES 源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE　通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP　由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是组播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。

例如在流媒体应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。

RTCP具有以下四个功能：
1、基本功能是提供数据传输质量的反馈.这是RTP作为一种传输协议的主要作用,它与其他协议的流量和阻塞控制相关.反馈可能对自适应编码有直接作用,但是IP组播的实验表明它对于从接收机得到反馈信息以诊断传输故障也有决定性作用.向所有成员发送接收反馈可以使"观察员"评估这些问题是局部的还是全局的.利用类似多点广播的传输机制,可以使某些实体,诸如没有加入会议的网络业务观察员,接收到反馈信息并作为第三类监视员来诊断网络故障.反馈功能通过RTCP发射机和接收机报告实现.
2、RTCP为每个RTP源传输一个固定的识别符,称为标称名或CNAME.由于当发生冲突或程序重启时SSRC可能改变,接收机要用CNAME来跟踪每个成员.接收机还要用CNAME来关联一系列相关RTP会话期中来自同一个成员的多个数据流,例如同步语音和图像.
3、前两个功能要求所有成员都发送RTCP包,因此必须控制速率以使RTP成员数可以逐级增长.通过让每个成员向所有成员发送控制包,各个成员都可以独立地观察会议中所有成员的数目.
4、可选的功能是传输最少的会议控制信息,例如在用户接口中显示的成员识别.这最可能在"松散控制"的会议中起作用,在"松散控制"会议里,成员可以不经过资格控制和参数协商而加入或退出会议.RTCP作为一个延伸到所有成员的方便通路,必须要支持具体应用所需的所有控制信息通信.

RTP/RTCP数据包格式

RTP数据包格式

RTP报文头格式（见RFC3550 Page12）：

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X| CC |M| PT | sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

以上域具体意义如下：
版本(V):2比特此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中.)
填料(P):1比特若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包.
扩展(X):1比特若设置扩展比特,固定头(仅)后面跟随一个头扩展.
CSRC计数(CC):4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目.
标志(M):1比特标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.
负载类型(PT):7比特此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流.
序列号（sequence number）:16比特每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难.

时间标志（timestamp）:32比特时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量.时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩.
时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧.

同步源（SSRC）:32比特 SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源.

有贡献源（CSRC）列表:0到15项,每项32比特 CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者.

注意：前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表.

RTP报文扩展头格式（见RFC3550 Page18）：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| defined by profile | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| header extension |

| .... |

若RTP头中的扩展比特位X置1,则一个长度可变的头扩展部分被加到RTP固定头之后,.头扩展包含16比特的长度域,指示扩展项中32比特字的个数,不包括4个字节扩展头(因此零是有效值).RTP固定头之后只允许有一个头扩展.为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前16比特用以识别标识符或参数.这16比特的格式由具体实现的上层协议定义.基本的RTP说明并不定义任何头扩展本身。

RTCP数据包格式

RTCP包括五种数据包类型（RFC3550 Page69）：

abbrev. name value(该值RTCP头格式中的PT类型字段)

SR sender report 200

RR receiver report 201

SDES source description 202

BYE goodbye 203

APP application-defined 204

1、SR：

源报告包，用于发送和接收活动源的统计信息；

2、RR：

接收者报告包，用于接收非活动站的统计信息；

3、SDES：

源描述包，用于报告和站点相关的信息，包括CNAME；

4、BYE：

断开RTCP包，是站点离开系统的报告，表示结束；

5、APP：

应用特定函数。

不同类型的RTCP信息包可堆叠，不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包，然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包的显式计数。

组合包中每个RTCP包可独立处理，而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束：

1、只要带宽允许，在SR包或RR包中的接收统计应该经常发送，因此每个周期发送的组合RTCP 包中应包含报告包。

2、每个组合包中都应该包含SDES CNAME，因为新接收者需要通过接收CNAME来识别源，并与媒体联系进行同步。

3、组合包前面是包类型数量，其增长应该受到限制。

所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：

加密前缀（Encryption prefix）：

仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。

SR或RR：

组合包中第一个RTCP包必须是一个报告包，以帮助分组头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。

附加RR：

如报告统计源数目超过31，在初始报告包后应该有附加RR 包。

SDES：

包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项，这要根据特别的应用需要，并同时考虑带宽限制。

BYE或APP：

除了BYE应作为最后一个包发送，其它RTCP包类型可以任意顺序排列，包类型出现可不止一次。

混合器从多个源组合单个RTCP包，如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册，以获得合法的类型号。

所有己定义的其它RTCP数据包可按任意次序排列，只有BYE数据包例外。在RTCP数据包中，它必须是最后一个数据包并且只能出现一次，而其它类型的数据包可出现多次。

1. 1. 1. 发送端报告SR

现在我们就SR报文为例详细描述一下RTCP报文格式（RFC3550 Page35）：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header |V=2|P| RC | PT=SR=200 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of sender |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

sender | NTP timestamp, most significant word |

info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| NTP timestamp, least significant word |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| RTP timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| sender's packet count |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| sender's octet count |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report | SSRC_1 (SSRC of first source) |

block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 | fraction lost | cumulative number of packets lost |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| extended highest sequence number received |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| interarrival jitter |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| last SR (LSR) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| delay since last SR (DLSR) |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report | SSRC_2 (SSRC of second source) |

block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2 : ... :

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| profile-specific extensions |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

每个RTCP包的开始部分是与RTP数据包相类似的固定部分,随后是一块结构化单元,它随负载类型不同长度发生变化,但是总以32比特终止.

发射机报告包由3部分组成,若定义,可能跟随第4个面向协议的扩展部分.
第一部分：

8字节长.该域有以下意义:
版本(V):2比特 RTP版本识别符,在RTCP包内的意义与RTP包中的相同.此协议中定义的版本号为2.
填料(P):1比特若设置填料比特,该RTCP包在末端包含一些附加填料比特,并不是控制信息的基本部分.填料的最后一个比特统计了多少个字节必须被忽略.某些有固定块大小的加密算法可能需要填料比特.在复合RTCP包中,复合包作为一个整体加密,填料比特只能加在最后一个单包的后面.
接收报告块计数(RC):5比特该包中所含接收报告块的数目.零值有效.
包类型(PT):8比特包含常数200,用以识别这个为RTCP SR包.
长度:16比特以32比特字为单位,该RTCP包的长度减一,包括头和任何填料.(偏移量1保证零值有效,避免了在扫描RTCP包长度时可能发生的无限循环,同时以32比特为单位避免了对以4为倍数的有效性检测.)
SSRC:32比特 SR包发起者的同步源标识符.

第二部分：

发射机信息,20比特长,在每个发射机报告包中出现.它概括了从此发射机发出的数据传输情况.此域有以下意义:
NTP时间标志:64比特指示了此报告发送时的壁钟时刻,它可以与从其它接收机返回的接收报告块中的时间标志结合起来,测量到这些接收机的环路时沿.接收机必须期望此时间标志的准确度远低于NTP时间标志的分辨率.测量的不确定度不可知,因此也无需指示.某个发射机,能够跟踪逝去时间但是无法跟踪壁钟时间,可以用加入会议后的逝去时间代替.假定该值小于68年,则最高比特为零.允许用抽样时钟估计逝去壁钟时间.无法用壁钟时间或逝去时间的可以设置此项为零.
RTP时间标志:32比特 与以上的NTP时间标志对应同一时刻,但是与数据包中的RTP时间标志具有相同的单位和偏移量.这个一致性可以用来让NTP时间标志已经同步的源间进行媒体内/间同步,还可以让与媒体无关的接收机估计标称RTP时钟频率.注意在大多数情况下此时间标志不等于任何临近的RTP包中的时间标志.然而,通过"RTP时间标志计数器"和"由在抽样点上周期性检测壁钟时间得到的实际时间"两者之间的关系,可以通过相应的NTP时间标志计算得到此RTP时间标志.
发送的报文数:32比特从开始传输到此SR包产生时该发射机发送的RTP数据包总数.若发射机改变SSRC识别符,该计数器重设.
发送的字节文数:32比特从开始传输到此SR包产生时该发射机在RTP数据包发送的字节总数(不包括头和填料).若发射机改变SSRC识别符,该计数器重设.此域可以用来估计平均负载类型数据速率.

第三部分：

零到多个接收报告块,块数等于从上一个报告以来该发射机收听到的其它源的数目.每个接收报告块传输关于从某个同步源来的数据包的接收统计信息.若某个源因冲突而改变其SSRC识别符,接收机并不延续统计数字.这些统计数字是:
SSRC_n(源识别符):32比特在此接收报告块中信息所属源的SSRC识别符.
丢包率:8比特自从前一SR包或RR包发射以来,从SSRC_n传来的RTP数据包的损失比例,以固定点小数的形式表示,小数点在此域的左侧,等于将损失比例乘256后取整数部分.该值定义为损失包数被期望接收的包数除,在下一段中定义.若由于复制而导致包损为负值,损失比例值设为零.注意在收到上一个包后,接收机无法告之以后的包是否丢失,若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此源发送接收报告块.
累计包丢失数:24比特从开始接收到现在,从源SSRC_n发到本源的RTP数据包的丢包总数.该值定义为期望接收的包数减去实际接收的包数,接收的包括复制的或迟到的.由于迟到的包不算作损失,在发生复制时包损可能为负值.期望接收的包数定义为扩展的上一接收序号(随后定义)减去最初接收序号.
接收到的扩展的最高序列号:32比特低16比特包含从源SSRC_n来的最高接收序列号,高16比特用相应的序列号周期计数器扩展该序列号.注意在同一会议中的不同接收机,若启动时间明显不同,将产生不同的扩展项.
到达间隔抖动:32比特 RTP数据包到达时刻统计方差的估计值,以时间标志为单位测量,用无符号整数表达.到达时刻抖动J定义为一对包中接收机相对发射机的时间跨度差值的平均偏差(平滑后的绝对值).如以下等式所示,该值等于两个包相对传输时间的差值,相对传输时间是指包的RTP时间标志和到达时刻接收机时钟,以同一单位的差值.若Si是包i的RTP时间标志,Ri是包i以RTP时间标志单位的到达时刻值,对于两个包i和j,D可以表达为
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算,利用该包和前一包i-1的偏差D(按到达顺序,而非序号顺序),根据公式J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

计算.无论何时发送接收报告,都用当前的J值.
此处描述的抖动计算允许与协议独立的监视器对来自不同实现的报告进行有效的解释.
上一SR报文 (LSR):32比特接收到的来自源SSRC_n的最新RTCP发射机报告(SR)的64位NTP时间标志的中间32位.若还没有接收到SR,该域值为零.
自上一SR的时间延时(DLSR):32比特是从收到来自SSRC_n的SR包到发送此接收报告块之间的延时,以1/65536秒为单位.若还未收到来自SSRC_n的SR包,该域值为零.
假设SSRC_r为发出此接收报告块的接收机.源SSRC_n可以通过记录收到此接收报告块的时刻A来计算到SSRC_r的环路传输时延.可以利用最新的SR时间标志(LSR)域计算整个环路时间A-LSR,然后减去此DLSR域得到环路传播时延.
可以用此来近似测量到一族接收机的距离,尽管有些连接可能有非常不对称的时延.

接收机报告包(RR)与发射机报告包基本相同,除了包类型域包含常数201和没有发射机信息的5个字(NTP和RTP时间标志和发射机包和字节计数).余下区域与SR包意义相同.若没有发送和接收据报告,在RTCP复合包头部加入空的RR包(RC=0)。

1. 1. 1. 接收端报告RR

RR数据包的格式如表2. 4所示。除净荷类型字段的值为常量201外，其它字段与SR数据包中相应字段的含义相同。去掉了5个字(NTP时间标志、RTP时间标志、发送端数据包和字节计数)的发送端信息。

不发送数据或不接收报告时，在混合RTCP数据包的开始部分应放置空的RR数据包(RC=0)。

0	1	2	3-7		8-15	16-31
V=2		P	RC		PT=SR=201	长度
数据包接收端SSRC
SSRC-1(第一个数据源SSRC)
丢失率(8位)				丢失数据包累计数(24位)
收到的最大序号扩充
接收抖动
最后SR延时(LSR)
从最后一个SR以来的延时(DLSR)
SSRC-2(第二个数据源的SSRC )
......
由框架文件说明的补充

表2-4发送端报告格式

1. 1. 1. SDES源描述包

SDES源描述包提供了直观的文本信息来描述会话的参加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项，这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成，数据块可以没有，也可有多个。包头由版本（V）、填充（P）、长度指示、包类型（PT）和源计数（SC）组成。PT占8位，用于识别RTCP的SDES包，SC占5位，指示包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。

0	1	2	3-7	8-15	16-31
V=2		P	RC	PT=SDES=202	长度
SSRC/CSRC-1
SDES数据项 ……
SSRC/CSRC-2
SDES数据项 ……

表2-5数据源描述RTCP数据包

数据源描述RTCP数据包如表格2-5， SDES数据包分为三层，它由报头和0个或多个数据块组成。每个数据块由描述块中数据源的数据项组成。下面将分别介绍这些数据项。V, P, Length, SSRC/CSRC字段与SR数据包中相应字段的含义相同。

PT: 8位。其值为常量202，标识RTCP SDES数据包。

SC: 5位。SDES数据包所含的SSRC/CSRC数据块数。0为有效值。

每个数据块由一个SSRC/CSRC标识符再加上0个或多个数据项组成。这些数据项携带SSRC/CSRC信息。每个数据块用一个32位的分隔符分隔。每个数据项由一个8位的类型字段，一个8位的描述文本长度的字节计数字段和文本组成。文本长度不能超过255个字节，文本不能用空字节结束。数据块的数据项以一个或多个空字节结尾。在最后一个数据项的未尾，若不足32个字节，则以空字节填补。

下面说明几种SDES数据项。其中CNAME数据项是必须的，有些仅用于特定的框架文件，但通常指定所有类型的数据项以实现共享并可简化独立于框架文件的应用程序。

1. 1. 1. 1. CNAME：端点标识符SDES数据项

0-7	8-15	16-31
CNAME=1	长度	用户名和域名

表2-6应用程序或工具名SDES数据项

CNAME有下列特点:

由于发生冲突或程序重新启动时SSRC标识符会发生变化，因此需要CNAME来为此间未发生变化的数据源提供标识符。
与SSRC标识符类似，在同一RTP会话中，对应于每个会话人员的CNAME标识符必须是唯一的。
为简化第三方控制，CNAME必须适用于程序或个人定位数据源。

因此，CNAME应该尽可能通过某种算法得到而不是手工加入。为了满足上述要求必须使用下列格式，除非框架文件说明了其它的格式。其格式为“user @host"，在单用户系统中为“host"。其中的“host”或者是主机域名，或者是用ASCII码表示的主机的数字地址。数字地址通常用于RTP通信接口。域名比较直观易于阅读。但在某些操作环境下却不易获取，此时可用数字地址代替。

当应用程序允许用户从一个节点产生多个数据源时CNAME的上述格式无法为每个数据源提供唯一的标识符。这种应用程序还需依赖SSRC来进一步区分数据源，使其能唯一地标识多个数据源。

在一组相关的RTP会话中，如果每个应用程序独立地产生CNAME，那么CNAME标识符将不能为同一用户的多种媒体工具提供连接。

1. 1. 1. 1. NAME：用户名SDES数据项

0-7	8-15	16-31
NAME=2	长度	数据源名称

表2-7用户名SDES数据项

NAME描述数据源的真实名称。其格式由用户指定。这种格式最适于显示户列表，因此只需经常发送用户名而不是发送CNAME。 NAME应在会话期间保持不变。

1. 1. 1. 1. EMAIL：电子邮件地址SDES数据项

0-7	8-15	16-31
EMAIL=3	长度	数据源EMAIL地址

表2-8电子邮件地址SDES数据项

在会话期间EMAIL的值应保持不变。

1. 1. 1. 1. PHONE：电话号码SDES数据项

0-7	8-15	16-31
PHONE=4	长度	数据源电话号码

表2-9电话号码SEDS数据项

电话号码应由“+”开始。

1. 1. 1. 1. LOC：用户地理位置SDES数据项

0-7	8-15	16-31
LOC=5	长度	数据源用户地理位置

表2-10用户地理位置SDES数据项

根据应用程序的不同，该数据项的详细程度也不同。它由应用程序或用户决定，但格式和内容应由框架文件预先说明。除移动节点外，LOC应在会话其间保持不变。

1. 1. 1. 1. TOOL：应用程序或工具名SDES数据项

0-7	8-15	16-31
TOOL=6	长度	应用程序的名称或版本信息

表2-11应用程序或工具名SDES数据项

该数据项是一个字符串，表示应用程序的名称或版本信息。它可用于程序调试。在会话期间该值应保持不变。

1. 1. 1. 数据包(BYE)

0	1	2	3-7	8-15	16-31
V=2		P	SC	PT=BYE=203	长度
SSRC/CSRC
……
长度(可选)				数据源离开会话的原因

表2-12 Goodbye RTCP数据包

BYE数据包的格式如表2-12。它表示一个或多个数据源将由活动态转变成非活动态。数据包中各字段的含义如下:

V, P, Length, SC, SSRC/CSRC字段与SDES数据包中相应字段的含义相同。

PT: 8位。其值为常量203，标识RTCP BYE数据包。

混合器收到BYE数据包后在不改变其SSRC/CSRC标识符的情况下转发该数据包。混合器关闭时，应发送一个BYE数据包列出它处理的所有特定数据源及其SSRC标识符。另外，BYE数据包可能包含一个8位的计数字节，其后是多个文本字节，表示某数据源离开会话的原因。

1. 1. 1. APP数据包

APP数据包的格式如表2.13，它用于试验新的应用类型，开发新功能。APP RTCP数据包中各字段的含义如下:

0	1	2	3-7	8-15	16-31
V=2		P	辅助类型	PT=APP=204	长度
SSRC/CSRC
名称
应用程序说明的数据

表2-13应用程序定义的RTCP数据包

V, P, Length, SSRC/CSRC字段与BYE数据包中相应字段的含义相同。

辅助类型(subtype): 5位。辅助类型允许用户在一个名字下定义一组APP数据包或任何由应用程序说明的数据包。

PT: 8位。其值为常量204，标识RTCP APP数据包。

Name: 4个字节。定义一组APP数据包所使用的，用户任选的名称。在某

应用程序收到的所有APP数据包中该名称必须是唯一的。用户可选用程序名，作为APP数据包所使用的名称。

应用程序说明的数据:变长。此类数据在APP数据包中可以出现也可以不出现。它由应用程序说明，其长度必须为32的整数(n*32)位，n=0, 1, 2, 3,……

RTP/RTCP工作机制

RTP工作机制

RTP根据应用程序的要求将流媒体数据包封装成RTP数据包并进行发送；它靠上层的调用以及依赖网络层发送来实现；

工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。

RTCP工作机制

RTCP报文不封装音视频数据，而是封装发送端或者接收端的统计报表信息；

在RTP会话期间，每个参与者周期性的向其它参与者发送RTCP控制信息包，如下图1-2所示：

图1-2 RTCP工作示意图

因为网络的情况很不稳定，如果网络情况好我们可以减少语音的延迟时间，也可以增大视频的发送帧率或质量。若网络状况不好我们可以增大语音延迟时间以保证语音连续，也可减少视频的发送帧率或质量，以减少网络的阻塞。

RTCP包的发送率根据与会者的数量来调整.

RTP协议关键技术指标

时间戳

时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。

RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。

在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值，如多个分组属于同一画像。

RTCP中的SR（Sender Report发送端报告）控制分组包含NTP（网络时间，是以1900-1-1零时为起点的系统绝对时间）时间戳和RTP时间戳（封装数据时候打上的时间戳与媒体帧上打上的时间戳不同）可用于同步音视频媒体流。其实现机制如下：

RTP时间戳是依据邻近的RTP数据包中的时间戳结合NTP时间差得到的，用公式表达为：

RTP_tsi = tsi + NTPi-NTP'i

其中：

RTP_tsi表示RTCP中的RTP时间戳；tsi表示邻近的RTP包中的时间戳；NTPi表示RTCP的网络时间戳；NTP'i表示邻近的RTP包对应的网络时间戳；下标表示第i个源。

RTP_tsj=tsj+NTPj—NTP'j 表示第j个源的RTP时间戳；

因此，i和源j之间的相对时差可以表示为：

（RTP_tsi – tsi） -( RTP_tsj - tsj) = (NTPi –NTP'i) - （NTPj—NTP'j）；

由于NTP同步，差值可以反映出两个源的相对时差。因为要同步不同来源的媒体流，必须使得同步他们的绝对时间基准，而NTP时间戳正是这样的绝对时间基准[4]。而对于同一来源的媒体流，应用RTP的时间戳来保证其同步。

时延

影响时延的因素有多个方面：编解码、网络、防抖动缓冲、报文队列等都影响时延，其中有些是固定时延，如编解码网络速率等；有些是变化的，如防抖动缓冲和队列调度等，固定的时延可以通过改变编解码方式和提高网络速率来改变，而变化的时延通常采用提高转发效率来提高；

假设SSRC_r为发出一个接收报告块的接收机.源SSRC_n可以通过记录收到接收报告块的时刻A来计算到SSRC_r的环路传输时延.可以利用最新的SR时间标志(LSR)域计算整个环路时间A-LSR,然后减去此DLSR域得到环路传播时延.

抖动

在视频电话中，语音、视频数据都是使用UDP协议传送的，但这种协议传输的数据包在网络层不能保证其发送顺序，需要应用层进行排序。在网络的传输中都会有延时，且随着网络负载的变化，延时的长短也不相同，对于语音数据，如果接收方收到后立即播放，很容易造成语音的抖动。

RTP数据包到达时刻统计方差的估计值,以时间标志为单位测量,用无符号整数表达

到达时刻抖动J定义为一对包中接收机相对发射机的时间跨度差值的平均偏差(平滑后的绝对值).如以下等式所示,该值等于两个包相对传输时间的差值,相对传输时间是指包的RTP时间标志和到达时刻接收机时钟,以同一单位的差值.若Si是包i的RTP时间标志,Ri是包i以RTP时间标志单位的到达时刻值,对于两个包i和j,D可以表达为
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算,利用该包和前一包i-1的偏差D(按到达顺序,而非序号顺序),根据公式

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

计算.无论何时发送接收报告,都用当前的J值.

为了更好的解决抖动的问题，最好能实现抖动缓存（原理比较简单，在此不做详细描述），一是保证语通道读取数据包的顺序正确，二是控制接收方按照采集的时间顺序播放语音，减少语音的抖动；另外提供QoS和资源预留使语音数据获得优先发送和获得固定的带宽也是解决抖动问题的主要手段。

丢包率

丢包率是通过计算接收包数量和发送包数量的比率得到的，丢包率获得的整个流程是：发送方每间隔一定时间读取每个发送通道的发包数量和数据长度，组成一个此通道的RTCP报文发送给接收方，同时将发送数据包计数清零；接收方收到RTCP包后，读取接收通道接收到的包数量，并计算出丢包率，通过一个RTCP接收汇报包发送给发送方，同时对接收数据包计数清零。

自从前一SR包或RR包发射以来,从SSRC_n传来的RTP数据包的损失比例,以固定点小数的形式表示,定义为损失包数被期望接收的包数除,在下一段中定义.若由于复制而导致包损为负值,损失比例值设为零.注意在收到上一个包后,接收机无法告之以后的包是否丢失,若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此源发送接收报告块.

会话和流两级分用

一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。

多种流同步控制

RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。

RTP转换器和混合器

除了端系统，RTP还支持转换器和混合器。在RTP这一层次上，它们称为“中间系统”.虽然支持这一个功能会增加协议的复杂性，但是在音视频应用中对这两项功能的需求是显而易见的。

转换器和混合器概述

RTP转换器或混合器连接两个或多个传输层的“区域”。通常每个区域由公共网络和传输协议(如:IP, UDP)，多点传送地址或单点传送地址和传输层目标端口来定义。在某个系统中一个转换器或混合器可用于多个RTP会话，但每个会话在逻辑上是一个独立的整体。

为了避免在设置转换器或混合器时出现环路，应遵循下列原则:

由转换器或混合器连接的区域中的RTP会话的每个用户必须与其它用户不同，至少应有一个参数(协议、地址、与端口不同)或者在网络层上与其它用户隔离。

除非将传输的数据源划分成若干互不相交的子集，每个转换器或混合器对应其中的一个子集，否则不能平行设置转换器和混合器。

类似地，所有通过转换器和混合器进行通信的RTP端系统共享相同的SSRC空间。因此所有端系统的SSRC标识符必须是唯一的。转换器和混合器可以设计成多种不同的形式以适应不同的应用。转换器和混合器的区别在于转换器转发来自不同数据源的数据流，而混合器则将这些数据流混合成一个新的数据流。

转换器完整无缺地转发RTP数据包及其SSRC标识符，使接收端能识别多个数据源。有些转换器是原原本本地转发数据，而有些会改变数据的编码方法从而改变数据的净荷类型和时间标志。如果多个数据包经重新编码后成为一个数据包或反之，那么转换器必须重新给输出数据包分配序号。如果不是通过其它方式了解净荷类型或原始数据源的传输地址，那么接收端无法检测是否存在转换器。

混合器接收来自一个或多个数据源的RTP数据包组成的多个数据流，用某种方式将它们组成混合数据流，然后传输混合数据流。通常多个输入源在时间上是不同步的，因此混合器应调整数据流的时间标志并产生新的时间标志。所有经混合器传输的数据包都由混合器产生的SSRC标识符标识。为了维持对混合数据包中原始数据源的识别，混合器应在数据包的CSRC标识符中插入SSRC标识符并列在RTP报头之后。对某些应用程序混合器可以不识别CSRC列表中的数据源，但这会产生一种潜在的危险，即无法检测数据源所存在的环路。

与转换器相比混合器的优点是输出带宽被限制在一个数据源所占用的带宽。当输入端有多个活动数据源时情况也是如此。这一点对于由低带宽连接的应用是非常重要的。缺点是位于混合器输出一侧的接收端无法对某个数据包是传输还是抑制进行控制。

图4-1由端系统、混合器和转换器组成的RTP网络

图4-1显示了一组混合器和转换器，并说明它们对SSRC和CSRC标识符的作用。用「EX]表示端系统，(MX)表示混合器，<TX>表示转换器。符号“M1:48(l,17)”表示由Ml产生的数据包，其中，SSRC标识符的值为48，两个CSRC标识符，1和17，表示该数据包来自E1和E2。

转换器中RTCP的处理

除了转发和修改数据包外，转换器和混合器还需要处理数据包。在大多数情况下，它们还需要把从端系统收到的RTCP混合数据包拆开，加入SDES信息并修改SR或RR数据包。由数据包的到达或转换器/混合器本身的RTCP间隔定时器来触发对上述信息的重新传输。

不修改数据包的转换器对RTCP数据包也不作修改。以某种方式改变净荷的转换器必须对SR和RR信息作相应的修改以便仍然反映数据的特点和接收质量。此类转换器不能简单地传送RTCP数据包。通常转换器不应将来自不同数据源的SR和RR数据包聚集在一个数据包中，因为这样做会降低基于LSR和DLSR字段的传输延时的精确度。

对SR发送端信息的处理:转换器不产生对应的发送端信息，但需要把从一个区域收到的SR数据包转发给其它区域。在传输过程中SSRC保持不变但对发送端信息将作必要的调整。如果转换器改变了数据编码格式，那么它必须修改SR数据包中“发送端的字节计数”字段的值。

如果将几个数据包合成一个数据包，那么它必须修改SR数据包中“发送端数据包计数”字段的值。若改变了数据包时间标志的频率，则必须修改SR数据包中“RTP时间标志”字段的值。

对SR/RR接收报告数据块的处理:转换器把从一个区域收到的接收报告传送给其它区域。接收报告的传输方向与数据的传输方向相反。

如果转换器把几个数据包合成一个数据包并改变所对应的序号，那么它必须为“数据丢失”字段和“最大序号扩充”字段求反。

对SSRC标识符的处理:转换器无须为自身设置SSRC标识符，但它可能需要分配一个SSRC标识符以发送所接收的报告。由于接收报告要发送到所有的用户，所以这些报告将发送到所有相连的区域。

对SDES的处理:从一个区域接收SDES信息并把它们发送到其它区域时，转换器一般不改变SDES信息，但在带宽受限制时会过滤掉非CNAME的SDES信息。传送CNAME时必须保证能够检测SSRC标识符所产生的冲突。当转换器产生其自身的RR数据包时，它必须将自身的SDES CNAME信息发送给这些RR数据包所在的区域。对BYE数据包的处理:转换器转发BYE数据包时不改变该数据包。当打算减少传输的数据包数量时，转换器及其SSRC必须为相应的SSRC产生BYE数据包。

对APP数据包的处理:转换器转发APP数据包时不改变数据包。

混合器中RTCP的处理

由于混合器能产生一个新的数据流，因此它不传送SR或RR数据包而重新产生SR或RR数据包。

对SR发送端信息的处理:因为混合过程失掉了源数据流的特点，所以混合器不传输来自数据源的发送端信息。作为同步源，混合器重新产生SR数据包。它包含有关混合数据流的发送端信息并按混合数据流的发送方向发送该SR数据包。

对SR/RR接收报告的处理:对于每个区域中的所有数据源，混合器都产生自己的接收报告然后将它们发送到同一个区域，而不发送到其它区域也不将从一个区域收到的接收报告发送到其它区域。

对SDES的处理:将从一个区域接收的SDES信息传送给其它区域时，混合器通常不改变该信息，但在带宽受限制时可能会过滤掉非CNAME的SDES信息。传送CNAME时必须保证能够检测SSRC标识符所产生的冲突。当转换器产生其自身的RR数据包时，它必须将自身的SDES CNAME信息发送给这些RR数据包所在的区域。

由于混合器不传送SR或RR，所以它通常要从混合RTCP数据包中抽出SDES数据包。为了减少系统开销，多个SDES数据包中的数据块应集中在一个SDES数据包内，然后放入SR或RR数据包。混合器两端的RTCP数据包传输速率可能各不相同。

未插入CSRC标识符的混合器将不传送SDESC NAMES。此时，在两个区域中SSRC标识符是互相独立的。如前所述，这种操作将不能检测循环。

对BYE的处理:混合器需要传输BYE数据包。如果要减少传输的数据包，那么混合器在产生BYE数据包的同时也应产生相应的SSRC标识符。

对APP的处理:混合器对APP数据包的处理方式由应用程序说明。

RTP/RTCP协议应用方案

RTP协议应用方案之单播

在客户端与媒体服务器之间建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户端，这种传送方式称为单播。

优点：便于控制和管理；

缺点：每个用户必须分别对媒体服务器发送单独的查询，而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余造成服务器负担沉重，响应需要很长时间.

RTP协议应用方案之广播

广播指的是用户被动地接收流。在广播过程中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流; 广播方式中资料包的单独一个拷贝将发送给网络上的所有用户, 而不管用户是否需要，会非常浪费网络带宽。

优点：简单

缺点：浪费网络带宽

RTP协议应用方案之组播

组播技术构建的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，媒体服务器只需要发送一个信息包，所有发出请求的客户端即可同时收到连续数据流而无延时。这就大大减少了网络上传输的信息包的总量, 组播吸收了单播和广播两种发送方式的长处，克服了上述两种发送方式的弱点，将资料包的单独一个拷贝发送给需要的那些客户。组播不会复制资料包的多个拷贝传输到网络上，也不会将资料包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。

优点：减少网络上传输的信息包的总量。网络利用效率大大提高，成本大为下降；

缺点：当不同的用户同时点播同一个节目时，由于点播总有先后顺序，后点播的用户并不是从开始播放，而是依照网络中同时点播此节目的其它用户的播放进度，这就造成当前用户极有可能从节目的中间开始看起,很难做到个性化。

下面我们就组播方案进行详细的分析：

RTP协议组播方案总体概述

　组播方案中包括由服务器端、客户端和组播网络载体三部分组成，由于组播网络对于客户端和服务器来说可以是屏蔽的，因此本文仅对服务器和客户端做详细描述，组播整体方案示意图如下图1-3所示：

　图1-3 组播整体方案示意图

如图1-3所示：

　RTPSender　　为服务器端；

RTPReceiver　为客户端；

Multicast　　为组播网络；

流数据包由RTPSender发送，经过Multicast网络，到达RTPReceiver客户端；

RTP协议组播方案服务器端实现

服务器端的算法为：

１、打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程，端口的选择是RTP数据在偶数UDP端口传输，RTCP包在下一个高奇数端口传输；
　　　２、创建一个UDP套接字并将其绑定到所提供服务的地址之上。
　　　３、反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。

服务器端将音视频流封装成RTP数据包通过组播网络发送，如图1-4：

　图1-4服务器发送示意图

RTP协议组播方案客户端实现

客户端加入组播群组后，就可以接收音视频流，如图1-5所示：

　　　　　　　　　如图1-5　客户端接收示意图

RTP协议视频帧率和质量调整策略

视频帧率和质量的动态调整的目的是在保证语音质量的情况下，不需要用户干预，而尽网络带宽的可能提高视频的帧率和质量；同时，在网络可用带宽下降时，自适应网络的带宽动态调整视频的帧率和质量，尽可能不出现马赛克，不影响音视频的传输。

判断网络带宽一般有两种方法：一是通过丢包率；二是通过RTCP包循环一圈的时间。

丢包率的计算流程见本文3.4丢包率中的描述，但丢包率由于以下原因往往不能正确反映实现带宽的情况：

一是由于UDP包的接收顺序不能保证，接收到的数据包可能多于发送的数据包例如复制数据包，造成计算的丢包率不能正确反映网络带宽；另一个问题是RTCP的数据包可能丢失，如果发送方RTCP发送汇报包丢失，则接收方接收数据包计数不能正确清零，如接收方RTCP接收汇报包丢失，则发送方不能得到丢包率，因此也不能正确反映网络带宽。

因此一般采用RTCP包循环一圈的时间来判断网络带宽。但是RTCP包循环一圈的时间不能准确反映网络带宽，我们通过一些措施使之尽量准确：一是使用多个RTCP包的循环时间的平均值判断网络带宽，尽量避免网络的抖动情况；二是设置最大循环时间为400ms，解决丢失RTCP包或网络突然发生抖动时对计算循环时间的平均值造成的影响。

视频调整的频率：首先使用一个比较低的帧率和质量的动态调整，然后根据网络带宽的情况逐步调整帧率和质量。一般在开始阶段（如1分钟以内）调整的频繁一些（比如10秒钟调整一次），这样调整的目的是使视频的质量和帧率尽快的适应带宽；然后保持一个固定的间隔调整一次（比如1分钟），使视频帧率和质量随着网络的变化不断调整。

RTP现在还没有一个标准的视频帧率和质量调整算法，服务器根据自身的情况进行相应的调整，一般来说根据RTCP包循环时间的平均值计算出一个加权值，然后根据这个值所在的区间，并经过一定的处理后，对视频的帧率和质量分别进行相应的调整以满足需要。要得到一个明确的算法，需要我们做相应的测试实验来验证我们的算法；