嘉应学院毕业论文(设计)
了克服这些不利因素，RTP包头携带时间戳和序列号，这样接收方就可以重建源产生的计时信息，语音报文可以按照20毫秒的间隔连续回放了。其计时信息是接收方按照会议中不同的RTP源分别重建的。同时，接收方也可以利用序列号来估算包丢失数。
与会者在会议进行期间可能加入或退出，因此了解在某一时刻有哪些人参加了会议，以及它们的语音数据接收情况是很有必要的。因此每个与会者的应用程序都周期性地广播含有自己名字的RTCP接收报告。RTCP接收报告表明了这一与会者接收语音数据的效果，同时它可以用来控制自适应编码器。另外，用户也可以使用名字以外的其它表示信息，这要视控制带宽的情况而定。一个与会者离开会议时要发送RTCP BYE报文，以通知其它的参与者自己离开了。 （2）音频和视频会议
如果在一个会议里同时有音频和视频，它们将采用独立的RTP会话来传送，两个媒体流的RTCP报文采用不同的UDP端口对或多播地址。在RTP层音频和视频并没有直接的联系，除非某个特定的用户需要在RTCP报文中使用相同的标识将这两个RTP会话联系起来。音频和视频采用独立的RTP会话的原因之一是可以允许部分与会者根据需要只接收者音频或视频流。尽管采用独立的RTP会话，同源的音频和视频可以根据RTCP的时间信息进行同步回放。
（3）混合器和转换器
当某一与会者采用低速链路接入会议，而大部分与会者采用高速链路接入，如果让每个与会者使用窄带，低质量的语音编码器，这显然不是一个很好的解决办法，这时就需要使用“混合器”。混合器（Mixer）是一个RTP层的中继设备，将它置于低速链路端，它对到来的音频报文按20毫秒的间隔重新进行同步，然后将重构的音频数据流混合成一路窄带的数据流转发给窄带用户。这些新的报文可以按照单播或多播的形式发送给接收者。RTP包头提供了一个字段CSRC，使混合器可以辨别混合报文的各个信源，这样在接收端就可以正确获知谁是发送者。
“转换器”（Translators）也是一种RTP层的中继设备，当某些与会者不能通过多播（multicast）方式直接连接到会与，比如它们处在不让任何IP包通过的应用级防火墙之后，这时就需要用到“转换器”。在防火墙内外各安装一个转换器，当外面的转换器接收到安全的数据包后，将它们以隧道方式直接发送给防火墙内的转换器，由它转发给防火墙内的用户。
混合器和转换器可以针对很多不同的目的而设计。比如视频混合器，它可以将多路不同的视频流的单个图像混合成一路视频流，模拟一个群体场景。转换器的一个应用例子是
7
嘉应学院毕业论文(设计)
连接一些只能使用IP/UDP的主机和只能使用ST-II主机，或者对单个信源的视频流进行逐包的编码翻译，而不作重新同步或混合。
2.3 RTP数据包格式
2．3．1 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 | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
以上域具体意义如下：
（1）版本(V):2比特 此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初\语音工具使用的协议中.)
（2）填料(P):1比特 若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包. （3）扩展(X):1比特 若设置扩展比特,固定头(仅)后面跟随一个头扩展.
（4）CSRC计数(CC):4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目. （5）标志(M):1比特 标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.
8
嘉应学院毕业论文(设计)
（6）负载类型(PT):7比特 此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流.
（7）序列号（sequence number）:16比特 每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难.
（8）时间标志（timestamp）:32比特 时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量.时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩.
时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的 顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧.
（9）同步源（SSRC）:32比特 SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源.
（10）有贡献源（CSRC）列表:0到15项,每项32比特 CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者.
注意：前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表.
9
嘉应学院毕业论文(设计)
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说明并不定义任何头扩展本身。
第三章 实时语音通信系统简介
3.1 系统平台
本系统是在linux下实现的，选用Ubuntu 12.04作为软件的实现平台，vim作为编写工具，编程语言采用C++。在linux平台上，音频采集采用ALSA（Advanced Linux Sound Architecture ）的lib库，利用网上现有的oRTP库实现基于RTP的实时语音传输。
10
嘉应学院毕业论文(设计)
Linux是一位芬兰的年轻人Linus Benedict Torvalds于1991年10月在赫尔辛基大学对外正式发布一套操作系统，它一种Unix风格的操作系统，在源代码级上兼容绝大部分Unix标准，是一个支持多用户、多进程、多线程、功能强大而且执行稳定的操作系统。非常重要的一点，Linux还是一种开放、免费的操作系统，还具有可移植性和自由代码等特性，这是其它操作系统所无法比拟的。目前Linux已经得到了越来越多的应用。
3.2 系统实现的基本原理和框架结构
本系统主要实现音频数据的实时传输通话。采用在计算机以太网上进行点对点的通信模式。具体的过程是：上层通过麦克风采集音频数据，然后采用G729a进行音频压缩，发送方RTP协议从上层接收音频数据（这里采用PCM编码），封装成RTP数据包发送给下层协议UDP，UDP提供RTP和RTCP的分流，RTP使用一个偶数号端口，相应的RTCP使用其后的奇数号端口。接收方则对网络层传来的数据包解封，并交由RTP提取音频数据，然后进行音频解压缩，再经扬声器播放出来。
下面图3.1是本系统的基本框架流程图：
实时语音通信模块实现过程见下图3.1：
图3.1 基本框架流程图
本系统核心模块是语音通话模块的实现，下面是语音通话模块的流程图：
11