1、基于 PC 平台的多方会话的研究与实现第 32 卷VoL32第 l2 期l2计算机工程ComputerEngineering2006 年 6 月June2006?多娴 I 体技术及应用?illlq,loo( 卜_3428(2006)1_o23s_03 文献标识码:A 中圈分类号:TP37基于 PC 平台的多方会话的研究与实现罗芹,王荣良(华东师范大学计算机科学与技术系,上海 200062)擅耍:多方会话技术主要包括会话管理及语音处理两个部分 .该文采用集中式信令和分布式媒体的多方会话模式,将会话管理和语音处理分离,研究并实现_一个基于 PC 的可形成一定规模的多方会话模型 .该模型易于扩展,适
2、合于公司运行 n关 t 诃:SIP;集中式信令;分布式媒体;DirectX;RTP/RTCPResearchandImplementationofMulti-conferenceBasedonPCPlatformLUOQin,WANGRongliangfDepartmentofComputerScienceTochnology,EastChinaNormalUniversity,Shanghai200062)Abstract|Multiconferencetechniquemainlycontainstwoparts:sessionmanagementandvoicedisposa1.This
3、paperfsear【 mesandimplementsaPCbasedscalablemulticonferencesystem.Thissystemadoptscentralizedsignalinganddistributedmediamulticonferencemodelinwhichsessionandvoicearedisposedseparately.Keywords!SIP;Centralizedsignaling;Distributedmedia;DirectX;RTP/RTCP多方会话,是指连接多个客户到一个会话中来,并混合他们的语音流成一个语音流,在每个客户端分别播放出
4、来.对于会话管理技术,目前比较流行的有 IETF 组织提出的 SIP标准及 ITU 组织提出的 H,323 标准.H.323 是一个比较成熟的技术,但其实现复杂且不易于扩展.目前,关于 SIP 研究与应用越来越热.SIP 标准是用来建立,维持和终止一个用户或多个用户之间的通话.尽管它最初的设想是用于大规模多方会话协议,然而,如今 SIP 主要用于点到点的通话.文献【1】中提出了多个基于 SIP 的多方会话模式.其中有好几种模型用到了目前已存在的 SIP 扩展.对于每一种会话模式,重点讨论了会话的管理,并未涉及语音的处理.一方面,绝大多数会话模式,都采用第 3 方控制,即由一个会议服务器来对信令
5、和媒体进行管理.这种会议模式,完全受制于服务器的处理能力,容易形成单点瓶颈,而且不易于扩展.另一方面,PC 作为功能强大的个人终端 ,在多方会话模型中完全可以分担服务器的部分负载.如它可采用微软的DirectXSDK(软件开发包)提供的 DirectSoundAPI 对语音进行实时的捕 f 获,回放和混音.且它能够将接收到的语音包快速地编解码,实时地传输出去.正是由于完全集中式会议模型的缺陷及个人 PC 的高处理性能 ,本文选用该文献中提到的一种将信令管理和媒体处理分离的模型:集中式信令和分布式媒体的会话模型,将蒴!体处理置于个人终端上,在现有SIP 标准和 PC 机基础上,研究并实现了一个多
6、方会话实例.l 基于集中式信令和分布式媒体的会议模型如前所述,在一个多方会话模型中,主要涉及两种实体的管理:信令和媒体.对于信令的管理,我们采用目前应用较广的 SIP 标准.使用 SIP 标准来建立,管理和终止一个用户或多个用户之间的通话.对于媒体的处理,主要包括对语音的编解码及混音.在一个集中式信令和分布式媒体会议模型中,信令部分由会议服务器完成,而媒体的处理,则完全置于与会者终端来完成.1.1 会议模型在一个集中式信令,分布式媒体会议模型中,假设共有4 位与会者 A,B,c 和 D.A,B 和 c 同时讲话,D 只在收听.其结构如图 l 所示.田 1 集中式信令,分布式攥体该模型中,仍然通
7、过会议服务器管理信令.当服务器分别和 A,B,C 和 D 建立连接后(图中的实线箭头表示),语音的 RTP 传输在各与会者之间进行.发言者(C)将语音传输给所有其他与会者(A,B 和 D),同时接收其他活动与会者(A,B) 的语音包,并进行解码,混合.这里,服务器只负责信令传输,而不接触任何媒体.媒体处理分布到每个终端,因而服务器的负载得到均衡.而 SIP 联系仍然是点到点的.这里共有 4 个用户同时通话,从每个与会者到服务器,都使用不同的 CallID.1.2 会议管理这种会议模式,通过第 3 方呼叫控制工作.当有一个新作者倚介:罗芹(1981 一), 女 ,硕上生,主研方向:基于 SIP
8、的多方会话;王荣良,副教授收藕日期:200507 一 10E-mail:livlovlev126.corn一235用户加入时,会议服务器就向每一位与会者发送 reINVITE.为了说明这种会议模式的建立过程,在此假设会议中已有 3个与会者 A,B 和 c,在这种状态下,每个用户直接向其他用户发送媒体流.当有一个新的用户 D 要加入会议时 ,SIP交互过程如图 2 所示.AllCS 盯 verDKFP 传精 JNVITE(1)C1200Ok(2)c2Ack(3)re-INVITE(200Ok(5)Ack(6)Je-INVITE(7)200OK(8)Ack(9)-INVITE(10)200OK(1
9、1)-ck(12)5,e-INVITE(I3200OK(14)Ackf15)re-INVITE(16:200Okf】7)Ack(18)盯 P 传精 C3圈 2 会议呼叫藏程首先用户 D 向服务器发送 INVITE(1)请求,在 INVITE的 SDP 中,包含 D 接收一个媒体流的地址和端口.会议服务器发送 200OK(2)成功应答,表示 D 已与会.为了实现 4 方通话,用户 D 还要提供另外两个可接受媒体的端口号 .因此,服务器向用户 D 发送 FeINVITE(4)请求.该请求中包含了另外两个要传输的媒体.在对服务器的 200OK(5)应答中,新用户给出另外两个可以接收媒体的地址.然后,
10、服务器分别向已存在的 3 个用户(A,B 和 c)通知新用户传输媒体的端 121.首先,服务器向用户 c 发送 reINVITE(7)请求,该请求包括 D 接受媒体的一个端口 D1.C 在对服务器的响应(8)中给出它接受新媒体的端口号 c3.同样,服务器分别通知用户 A,B 新用户接收媒体的端口 D2,D3,并获得用户 A,B接受新媒体的端口号 A3,B3.最后,服务器通知用户 D 更新和 C3,B3,A3 的连接地址和端口号 .在 D 的应答(16)中,返回的是和前面一样的 3 个端口号:DI,D2,D3.此时,D 可以分别和用户 A,B,c 相互发送媒体.端口号对应为:D1(-C3,D2(
11、-B3,D3(-A3.如果有 N 个用户,则每个用户需给出 N 一 1 个接收其他 N 一 1 个用户的媒体流的地址(端口号 ).由整个流程可以看出,会议中每增加一个用户,则服务器与用户之间的交互,一方面是通知与会者新用户加入,另一方面获得原与会者与新加入用户双方开始通信的端口号并由服务器通知双方.这样操作以后,在所有用户之间建立真正的单对单的 RTP 传输,语音的编解码及混音完全交由终端来完成.而服务器只负责信令部分.1.3 晨务逻辑定位建立这个会议的主要逻辑都集中在会议服务器上.该服务器负责初始化会议,邀请新用户加入,获得新用户与原会议与会者进行媒体传输的地址和端口号,并通知双方.一236
12、 一对于终端用户的唯一要求是,支持同一类型的多个并行的媒体流,并且能够将所有接收到的媒体流混合起来.当然,它们还要支持第 3 方(会议服务器)的控制原语.这不需要任何超出 SIP 标准以外的东西.该会议模型的建立,完全可以在现有的 SIP 标准基础上实现,而不需任何扩展.2 音频处理会议建立后,通话质量的好坏,语音处理足关键的一方面.在该模型中,语音处理完全交由终端来完成.语音处理包括:语音的编码,语音的解码,语音的混合以及语音数据的传输.2.1 语音码模块设计语音编码模块主要是把用户语音的 PCM(脉冲编码调制)样值编码成少量的比特(帧).采用编码处理后,可使语音在链路产生误码,网络抖动和突
13、发传输时具有更好的健壮性.在接收端,语音帧先被解码为 PCM 语音样值,然后再转换成语音波形.本文选择的方案是 G.729 压缩算法.该算法为低时延设计,在 8kbps 的带宽传输话音,在良好的信道条件下达到了较高的长活质量,并且在有随机比特误码和多次转接等情况_F 有很好的稳健性 .该算法的另一个显着优点是达到 16:1 的高压缩率,这对于省网络带宽具有明显的优势.当然,对实时语音采用这样的编解码算法,对终端的处理能力提出了很高的要求.但这对于以 Pc 作为终端的会议系统来说,是完全可以胜任的.2.1.1 语音的采集,编码当会议中的与会者发占时.由 DirectSound 的DirectSo
14、undCapture 对象将与会者的语音进行实时采集,并存放到捕获缓存 DirectSoundCaptureBuffer 中.通过对捕获缓冲设置一定数量的感知点,使得当指针到达感知点时,能触发相应的方法,发送两个感知点之间的数据.这里设置发送缓存的数据为 320B,采用 G.729 算法进行压缩后,语音数据为20B.然后加上相应的 RTP 头部再发送出去.发送的报文格式如图 3.圈 3 实际生避的语青包格式2.1.2 语音接收,播放在接收端,将语音包接收后,首先根据 RTP 协议,检查数据的有效性,然后,去除 RTP 头部包装,对其中的有效数据进行解码还原,解码后的有语音数据被写入到 Dire
15、ctSound中的 DirectSoundSecondaryBuffer(流式辅助缓存)中,当该辅助缓存中的数据达到一定数量时,进行播放.2.2 语音的传2.2.1RTP/RTCP 协议语音传输是多方会话中的一个关键技术点.语音数据不同于一般的数据报文,它要求很高的实时性,无法容忍超时重传或包乱序的现象,但却可以容忍一定数量的丢包.实时传输协议(RealtimeTransportProtocol,RTP)是用于传输Internet 上多媒体数据流的一个传输协议,协议目标是提供时间信息和实现流同步.数据流的流量控制或拥塞控制是依靠实时传输控制协议(RealtimeTransportControl
16、Protocol,RTCP)来提供 ,RTCP 协议负责管理传输质量在当前应用进程之间交换控制信息.这里主要用到 RTP 的 3 个域:SSRC 源标识,序列号和时戳.SSRC 域是 RTP 的一个头部域,该域是一个同步源标识符,用一个 32 位整型数来标识 RTP 语音流来源.在同一个RTP 会话中, 该标识唯一确定.本文的实现方法是以本机 IP地址,使用端口号,当前的时问作为参数通过 MD5 算法来产生该标识,以此来保证 SSRC 产生的唯一性,通过对 SSRC的验证,可保证收到的是来 fj 同一个源的数据.头部域中,最重要的部分是序列号和时戳.前者能够将接收到的包重排序并且能检测到丢包.
17、后者提供媒体间及媒体内的同步功能.2.2.2 数据的多地发送在该模型中,与会者 C 饔同时向与会者 A,B 和 D 发送C 的语音数据包.根据图 2 的交互流程,每位与会者与其他N 一 1 个与会者使用 N 一 1 个不同的端 13 号进行收发数据.但发送的语音数据是完全一样的.因此发送数据很简单,C 只需将本地实时采集,编码并封装好的数据,在多端口(C1,C2,C3)同时发送出去即可.在实现时,可以根据与会者的数目,动态加载 socket,每个 socket 绑定到会话建立时确定的端口,当该与会者发言时,就将组装后的语音报文在这些端口同时发送出去.2.3 涡音对于完全集中式会议,服务器不仅需
18、要对多个媒体流进行混音,还需从混合语音中减去某个与会者的语音再传输给该与会者,从而消除回音.而在本文的会议模型中,由于语音的处理在:每个终端完成,每位与会者发送自己的语音 ,接收其他与会者的语音,因此他只需混合所有其他与会者的语音,而不需考虑回声消除.混音的实现,完全可以由 PC 中的硬件实现.这里我们调用 DirectSoundAPI 实现.DirectSound 有 PrimaryBuffer(主缓冲区)和 SecondaryBuffer(辅助缓冲区 )两个缓冲.主缓冲区只有一个,直接与硬件相关,这个主缓冲的作用就是进行混音并把混音结果送到输出设备.辅助缓冲区可以有多个,一个辅助缓冲用于存
19、放一路播放数据.各辅助缓 I 中区中的数据在主缓冲混合,由主缓冲送到音频输出设备,.这就可以方便地实现混音.在初始化 DirectSound 时,它会 EI 动创建一个 PrimaryBuffer,应用程序需设置其数据格式;:浦助缓冲由应用程序自己创建,应用程序只需把数据放入二级缓存就可以播放了.当有多个媒体流同时到:送时,具体实现过程如图 4 所示.圈 4DirectSound 的渭音屎理我们为每位与会者分配一个缓冲数组,数组的大小与一帧音频数据大小相同.程序运行时,一方面每位与会者分别在多个端 IEI 接收所有其他与会者发送过来的语音报文,根据RTP 报头中 SSRC 域的用户身份标识,将
20、解压后的数据置于相应的 SecondaryBuffer 缓存中 .并根据时间顺序将每帧语音数据排列好.另一方面,程序不断地对 SecondaryBuffer 中的语音数据进行循环播放和更新.DirectSound 的硬件将这些来自于不同 SecondaryBuffer 的声音在主缓存进行自动混音 .然后交由输出设备输出,从而方便地实现了混音.在实现时,我们分别用中文,英文和日文读了一段录音,在同一个终端用程序同时播放出来仔细听任一种语言的内容,都可以听出大概意思.声音效果还比较满意.3 模型的可扩展性这种会议模型的扩展性取决于多个因索.从媒体角度考虑,会议服务器从来不会接触到单个的媒体流.然而
21、,对于N 个用户,每个与会者都需要能够接收,解码并混合 N 一 1 个媒体流,但每个与会者只需要对一个流进行编码.解码相对于编码开销要小得多,支持多个解码并不会增加多少系统开销,对于使用静音抑制的情况尤其如此,因为在使用静音抑制的情况下,只有当前在说话的用户才会发送媒体流.这就是说用户只需解码(接收) 当前正在说话的用户发送的媒体流.而在一段时间里,往往只有一个用户在说话,如图 5.甲,:,/,c,/I/:一一一一一一佃圈 5 只有一位用户发言时的语音传这种情况下,只有一位用户与其他所有与会者发送同一个媒体流,可以大大提高会议的扩展性和效率.然而,对于服务器仍然有信令的负担.如果说会议中有N
22、个用户,那么每增加一个新的用户(第 N+1 个)需要 N+3个 INVITE 交互,而对于每个交互 ,又需要 3 条信息.同样,一个用户离开会议需要 N 个 BYE 交互,每个交互有 2 条信息.对于 N 值很大,而会议成员又动态变化的情况,这可能会是一个潜在的负担.4 结束语本文采用集中式信令,分布式媒体的会议模型,在 PC平台上构建一个多方会话的实例,其优点在于完全可以基于目前现有的 SIP 标准建立会话,而不需任何扩展,且不需考虑复杂的混音过程,完全由硬件完成.作为媒体的处理,包括语音的编解码及混音都已在现有的平台上实现.然而,这种会议模型在具体的应用环境中,涉及语音到达的先后时间差的测量与处理,系统对多用户同时讲话时的承受能力等问题,还有待进一步研究.jI考文献1RosenbergJ,SchulzrinneH.ModelsforMultiPartyConferenceinsTPS.InternetDraft,IETEWorkinProgress,200011.
