首页> 中国专利> 一种电话会议室桥接的方法及VoIP服务器

一种电话会议室桥接的方法及VoIP服务器

摘要

本发明提供一种电话会议室桥接方法,可以将本地服务器上的本地会议室和对端服务器的对端会议室进行合并操作,其特征在于,所述方法包括以下操作步骤:步骤a、在所述本地服务器和所述对端服务器之间建立桥接通道;步骤b、通过所述桥接通道接收所述对端会议室音频信息和会议操作业务请求,并将所述本地会议室音频信息和会议业务请求发送至所述对端服务器;步骤c、会议室桥接的混音处理,将所述对端会议室音频信息作为一路通话线路的音频输入,与本地各与会方线路输入的音频信息进行混音处理后通讯传输。当会议的议题相关时,多个会议室可以自由合并,从而方便实现会议语音、会议成员管理的共享操作。

著录项

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-04-23

    授权

    授权

  • 2016-08-17

    实质审查的生效 IPC(主分类):H04M3/56 申请日:20140604

    实质审查的生效

  • 2015-12-23

    公开

    公开

说明书

技术领域

本发明属于通讯技术领域,尤其涉及多个IP音视频电话会议的整合管理方法及相关设备。

背景技术

随着电子通信技术的不断发展,远程会议已经成为人们日常工作的重要沟通方式,传统电话会议和传统视频会议,由电信运营商来运营,利用程控电话交换网络传输语音和视频,虽然语音质量高,但是对于企业来说却要负担较高的成本,而且灵活性差。随着VoIP技术的发展,借助IP电话来召开会议可已经成为很多企业的选择。企业只需缴纳市话费以及较低廉的宽带费,就可以召开长途电话会议。

目前对于大多说企业来说,总部和各个分部内部都有各自的IPPBX服务器维护着自己的电话局域网,可以独立召开各自的电话会议,但当各个会议的议题相关时,此时就有将多个会议室合并的需求。

目前对于这种情况的一种解决办法是:所有与会人员全部打进一台IPPBX服务器上的会议室内,这样所有人都处在一个会议室内,可以进行电话会议。如图1所示,分机1,2,3在深圳IPPBX上注册,分机4,5,6在杭州IPPBX注册,深圳IPPBX和杭州IPPBX通过中继互通。如果分机4,5,6想要参与到深圳IPPBX上会议室的会议,那么分机4,5,6只能通过杭州IPPBX上的中继直接拨打深圳IPPBX上的会议室号码。此种方法下,分机4,5,6的音视频信号(线路4,5,6)都各自通过以太网传播,当与会人员较多时,就需要较高的网络带宽来承载大量的音视频信号。如果网络带宽不够高,那么会议的音视频质量将会受到严重的影响。

另外一种解决办法是:借助于市面上专门的电话会议合并系统,该系统独立于企业统一通信系统之外,但是该系统仅仅能实现会议室音频信息的合并,当会议主席方想要对另外一个会议室内的某个成员进行禁言、踢人操作时往往不能实现,该系统并不是会议室全部业务的合并。另外,对于企业不仅要购置一套内部电话通信系统,还要另外购买一套专门的电话会议室合并系统,对企业的购买预算有所提高。

发明内容

本发明的目的在于提供一种电话会议室桥接的方法,可以实现多个会议室的合并,并且桥接后的会议可以大幅度降低对宽带资源的要求。

为了实现上述发明目的,本发明的技术方案如下:

一种电话会议室桥接的方法,可以将本地服务器上的本地会议室和对端服务器的对端会议室进行合并操作,所述方法包括以下操作步骤:步骤a:在所述本地服务器和所述对端服务器之间建立桥接通道;步骤b:通过所述桥接通道接收所述对端会议室音频信息和会议操作业务请求,并将所述本地会议室音频信息和会议室业务操作请求发送至所述对端服务器;步骤c:会议室桥接的混音处理,将所述对端会议室音频信息作为一路通话线路的音频输入,与本地各与会方线路输入的音频信息进行会议室混音处理后通讯传输。

优选的,在步骤a之前还包括:发送一个扩展的会议室桥接请求,即在INVITE请求时添加一个自定义字段,利用哈希算法对本地服务器上的会议室号码进行包装生成哈希字符串后传输;接收INVITE请求后判断是否为上述会议室桥接请求,同时在本地数据库中检查判断是否存在上述的哈希字符串,如果存在则避免重复桥接而拒绝桥接请求。

优选的,上述对端会议室音频信息是所述对端服务器的各与会方线路输入的音频信息经混合叠加处理而成,上述本地会议室音频信息是所述本地服务器的各与会方线路输入的音频信息经混合叠加处理而成。

优选的,上述本地服务器可以发送携带本地会议室成员信息的SIP信令给对端服务器,上述对端服务器可以发送携带对端会议室成员信息的SIP信令给本地服务器,从而可以实现不同会议室成员的信息共享。

优选的,上述实现多个会议室成员信息共享具体包括以下步骤:本地服务器整理本地会议室成员信息,以一定格式保存;本地服务器通过会议室接入密码,使用可逆加密方式加密本地会议室成员信息;本地服务器将加密后的本地会议成员信息通过SIP信令发送至对端服务器;对端服务器接收到上述SIP信令后,使用会议室接入密码进行解密;对端服务器将解密后的对端会议室成员信息和本地会议室成员信息整合并显示。

优选的,所述SIP信令也可以携带会议室业务操作请求,包括本地服务器对上述对端会议室执行的踢人、禁言的业务操作,具体通过以下步骤:本地服务器根据用户的输入,整合操作命令并保存成一定格式;本地服务器使用会议室接入密码,使用可逆加密方式加密操作命令;本地服务器将加密后的操作命令通过SIP信令发送至对端服务器;对端服务器接收到所述加密后的操作命令后,使用所述会议室接入密码进行解密;对端服务器将解密后的操作命令进行鉴权、执行,并将执行结果使用所述会议室接入密码进行可逆加密,并发送给所述本地服务器;本地服务器使用所述会议室接入密码解密所述执行结果,并显示给用户。

本发明另外还公开了一种电话会议室桥接的VoIP服务器,可以与对端SIP通讯的服务器建立会议室桥接通道,该VoIP服务器包括:信令通讯模块、桥接控制模块、会议室桥接通道,以及混音处理模块,其中,信令通讯模块用于发送或接收会议室桥接请求、会议室成员信息,以及会议操作业务请求;所述桥接控制模块负责根据桥接信令建立或者断开会议室桥接通道;所述会议室桥接通道负责本地会议室音频信息的发送,以及接收传输来的对端会议室音频信息;所述混音处理模块负责对输入的音频信息进行混音处理,生成所述本地会议室音频信息和桥接后的会议室音频信息。

优选的,上述本地会议室音频信息,是本地各与会方线路输入的音频信息经混合叠加处理而成;上述桥接后的会议室音频信息,是将对端会议室音频信息作为一路通话线路的音频输入,与本地各与会方线路输入的音频信息进行混音处理而成。

优选的,上述VoIP服务器还进一步包括本地会议室,负责该VoIP服务器端本地电话会议的召开,即:接收所述本地各与会方线路输入的音频信息并传输至所述混音处理模块;接收来自所述与会方的业务操作信令,以及接收来自所述桥接控制模块的控制信令和接收所述桥接后的会议室音频信息输出至所述本地各与会方。

优选的,上述信令通讯模块发送的本地会议室成员信息,是通过会议室接入密码,使用可逆加密方式加密生成而成的,信令通讯模块接收对端会议室成员信息后,由桥接控制模块使用会议室接入密码进行解密,提取出对端会议室成员信息并和本地会议室成员信息整合后,传输至本地会议室并显示。

优选的,上述会议室业务操作请求包括本地服务器对上述对端会议室执行的踢人、禁言的业务操作,桥接控制模块将加密后的操作命令通过SIP信令由信令通讯模块发送至对端服务器,对端服务器接收所述加密后的操作命令后解密、鉴权、执行,并将执行结果加密后发送至本地服务器,由桥接控制模块解密执行结果传输给本地会议室进行显示。

优选的,上述信令通信模块接收来自对端服务器的踢人、禁言的业务操作命令,由桥接控制模块对上述操作命令解密后进行鉴权、执行,并将执行结果加密后发送给对端服务器用于显示。

本发明公开的一种电话会议室桥接的方法,当会议的议题相关时,多个会议室可以自由合并,方便快捷的实现多个会议成员之间的会议语音共享,以及对合并的会议室成员也能进行踢人、禁言等管理操作,从而可以避免重新进行会议召集的繁琐操作。此外,通过本发明技术方案,直接将传输来的对端会议室语音作为一路语音输入,与本地通话线路进行会议混音处理,避免了传统电话会议中对所有与会方语音逐一进行通讯传输和混音叠加,从而可以大幅度降低对宽带资源的要求,处理效率更高。

附图说明

图1为现有技术中进行多个电话会议的工作原理示意图;

图2为本发明实施例的会议室桥接网络通讯示意图;

图3为本发明具体实施例的会议室桥接实现的流程图;

图4所示为本发明具体实施例中具有会议室桥接功能的服务器功能框架图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明实施例中的技术方案进行清楚、完整的描述。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。基于本发明中的实施例,本领域的技术人员所获得的所有其他实施例都属于本发明保护的范围。

针对以上问题,本发明提供了一种在VoIP服务器端实现会议室业务合并的方案,该方案不借助于任何外部系统,在VoIP服务器端内部实现,不仅能实现会议室音频信息的合并,还能实现会议室其他业务操作的合并。

图2为本发明具体实施例的会议室桥接网络通讯示意图。本实施例以处在不同IPPBX上的两个会议室的合并为例进行阐述,在会议室桥接前,进行初始配置和会议呼叫。起始配置:首先,分机1,2,3分机4,5,6分别在深圳IPPBX1和杭州IPPBX2上注册账号;其次,配置IPPBX1和IPPBX2的中继和路由使两台IPPBX能够互通;最后,在IPPBX1和IPPBX2上建立本地会议室1和对端会议室2。会议呼叫:分机1,2,3呼叫会议室1,分机3,4,5呼叫会议室2。通过本发明的会议室桥接方案,IPPBX1和IPPBX2之间将会建立桥接通道,从而会议室1和会议室2的音频信息将会通过上述建立的桥接通道进行传输,并分别在IPPBX1端和IPPBX2端进行桥接后的会议室语音的混音处理,从而实现所有与会话机的语音共享。

图3为本发明具体实施例的会议室桥接实现的流程图。由该图可知,本发明的实现包括以下步骤:

步骤S310:发送会议室桥接请求,本地会议室1所在的IPPBX1向对端会议室2所在的IPPBX2发送一个会议室桥接请求,并等待请求回应码。

步骤S320:接收会议室桥接请求,对端会议室2所在的IPPBX2收到会议室桥接请求后,并发送“OK”回应码。

步骤S330:建立桥接通道及会议室混音处理,IPPBX1收到“OK”回应码后,与服务器IPPBX2建立桥接通道,同时在IPPBX1端启动本地会议室1的混音处理,生成的本地会议室1音频信息。此处的混音处理是将会议室1所有的与会方线路1、线路2、线路3输入的音频进行混合叠加处理。

步骤S340:通过桥接通道进行会议室音频信息的通讯传输,即IPPBX1将上述本地会议室1音频信息发送到IPPBX2;同理,IPPBX2将混音处理生成的对端会议室2音频信息通过会议室桥接通道发送到IPPBX1。

步骤S350:会议室桥接的混音处理,IPPBX1将接收来的会议室2音频信息和本地会议室1的各线路输入音频信息进行会议室混音处理,IPPBX2将接收来的会议室1音频信息和本地会议室2的各线路输入音频信息进行会议室混音处理。IPPBX1的会议室混音处理具体包括:IPPBX1将会议室1内的每一路输入音频都转换为内部统一的线性语音格式,将接收来的会议室2音频信息也转换成内部统一的线性语音格式,然后对转换完成的音频信息做会议室混音处理,生成会议室桥接后的音频信息,此音频信息为线性语音格式。然后将混音后的音频信息再转换为每个输入通道相应的语音格式,原路分发出去。由于此时的混音处理与普通电话会议混音处理相同,因此具体处理方式不再赘述。同理,在IPPBX2端也会做上述相似的处理。

步骤S360:桥接后的会议室业务操作,IPPBX1发送携带本地会议室1成员信息的OPTIONS请求给对端会议室2所在IPPBX2,IPPBX2收到请求后提取出其中的成员信息并显示,这样对端会议室2就知道本地会议室1中有哪些成员;同理,IPPBX2发送携带对端会议室成员信息的OPTIONS请求给IPPBX1,本地会议室所在IPPBX1做同样的处理。这样两端会议室就互相知道了对方的成员信息。同时,这两台IPPBX也可以相互发送携带命令的OPTIONS请求,比如踢人,禁言等等。

步骤S370:会议室桥接断开,本地会议室所在IPPBX1发送BYE请求给对端会议室所在IPPBX2,对端会议室所在IPPBX2收到BYE请求后解除会议室桥接通道。

以上步骤中会议室桥接通道指的是:本地会议室1所在的IPPBX1服务器与会议室2所在的IPPBX2服务器上的一个软件通讯通道,该通道用来传输IPPBX2发出的会议室2音频信息以及各种业务请求、IPPBX1发出的会议室1音频信息以及各种业务请求。

当两个会议室桥接成功之后,IPPBX1和IPPBX2两个服务器之间会议室成员信息可以相互共享,此处,我们以IPPBX2端共享会议室1成员信息为例具体说明:

在IPPBX1端,由其整理本地会议室1的成员信息,以XML格式保存;通过会议室接入密码,使用可逆加密方式加密本地会议室1的成员信息;将加密后的信息通过SIP信令发送至所述对端IPPBX2服务器。

在IPPBX2端,接收到IPPBX1发送过来的本地会议1成员信息后,使用所述会议室接入密码进行解密;将解密后的对端会议室1的成员信息和本地会议室2的成员信息整合并显示。

此外,当会议室桥接成功后,不同的服务器可以直接对对端服务器的与会方进行类似踢人、禁言等业务操作。我们以服务器IPPBX1端对服务器IPPBX2端的与会方成员进行上述业务操作为例具体说明:

在IPPBX1端,由其根据用户的输入,整合操作命令并保存成一定格式;通过会议室接入密码,使用可逆加密方式加密操作命令;将加密后的操作命令通过SIP信令发送至所述对端服务器IPPBX2上。

在IPPBX2端,接收到所述加密后的操作命令后,通过所述会议室接入密码进行解密;解密后的操作命令进行鉴权、执行,并将执行结果使用所述会议室接入密码进行可逆加密,反馈给所述本地服务器IPPBX1;

本地服务器IPPBX1使用所述会议室接入密码解密所述执行结果,也可以将结果显示给线路1、线路2、线路3各与会方终端。

作为本发明另一个具体实施例,对于处在同一台IPPBX上的两个会议室的合并,本方案也给予如下阐述:

步骤S410:首先,分机1,2,3,4,5,6在IPPBX1注册账号,然后在IPPBX1上建立会议室1和会议室2。

步骤S420:桥接通道建立,由于会议室1和会议室2在同一台IPPBX上,因此,不再需要发再经由SIP发送桥接请求,而是由系统内部自行将会议室1和2桥接在一起。

步骤S430:会议室桥接通讯,会议室1将本会议室内与会方的音频信号混音后通过会议室桥接通道发往会议室2,同时从会议室桥接通道接收来自会议室2的混音数据;同理,会议室2将本会议室内与会方的音频信号混音后通过会议室桥接通道发往会议室1,同时从会议室桥接通道接收来自会议室1的混音数据。

步骤S440:会议室桥接的混音处理,会议室1将每一路输入音频都转换为内部统一的线性语音格式,将接收来的会议室2的音频信息也转换成内部统一的线性语音格式,然后对转换完成的音频信息做混音处理,生成混音后的音频信息,此音频信息为线性语音格式。然后将混音后的音频信息再转换为每个输入通道相应的语音格式,原路分发出去。同理,在会议室2也做上述的相似处理。

步骤S450:桥接后的会议室业务操作,由于会议室1和会议室2在同一台IPPBX上,因此,此步骤不再需要发送OPTIONS请求。系统内部直接将两个会议室的成员信息进行合并。会议室1和会议室2可以直接相互看到对方成员信息,IPPBX1也可以直接对会议室1和会议室2中的成员进行业务操作。

步骤S460:会议室桥接断开,IPPBX1解除会议室桥接通道,此时,会议室1和会议室2之间没有了专门的联系通道,相互无法听到对方的声音。

本发明中两台IPPBX交互使用SIP协议,所述步骤S310中用到会议室桥接请求,由于传统SIP协议中没有会议室桥接请求,因此本发明对SIP中的INVITE请求需要进行扩展,以区别传统请求。

传统INVITE请求部分如下:

INVITEsip:6301192.168.124.154SIP/2.0

Via:SIP/2.0/UDP192.168.124.155:5060;branch=z9hG4bK6bf8be6f;rport

Max-Forwards:70

From:<sip:6300192.168.124.155>;tag=as6c623872

To:<sip:6301192.168.124.154>

Contact:<sip:6300192.168.124.155:5060>

Call-ID:98-16ef54f855bd430b6230bfb760605040192.168.124.155:5060

CSeq:102INVITE

本发明在传统INVITE请求中另外添加一个头字段:X-Grandstream-Mcb-Req:${CONF_HASH:40}${SHA1_PASS:40},其中CONF_HASH:利用哈希算法对本地会议室号码(即要合并的本地会议室)进行包装的字符串,SHA1_PASS:利用哈希算法对对端会议室接入密码进行包装的字符串,以避免敏感信息明文在网络中传输,加强安全性。对端IPPBX收到INVITE请求后,根据X-Grandstream-Mcb-Req字段判断出是会议室桥接请求,然后对X-Grandstream-Mcb-Req中的SHA1_PASS字符串进行检查,如果字符串正确则密码验证通过。同时在本地数据库中检查是否有CONF_HASH字段,有则说明该合并请求会议室已经处于桥接状态,不能重复桥接,拒绝请求直接挂断;没有则在数据库中添加该字段,继续后续处理。当桥接解除时需要从数据库中删除该字段。

上述步骤S320中用到“OK”回应码,本发明对传统SIP“OK”回应消息进行扩展,传统SIP回应如下:

SIP/2.0200OK

Via:SIP/2.0/UDP192.168.124.155:5060;branch=z9hG4bK6bf8be6f;received=192.168.124.155;rport=5060

From:"Multi-conferenceBridge"<sip:6300192.168.124.155>;tag=as6c623872

To:<sip:6301192.168.124.154>;tag=as0e36cdae

Call-ID:98-16ef54f855bd430b6230bfb760605040192.168.124.155:5060

CSeq:102INVITE

Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO,PUBLISH

Supported:replaces,timer

Contact:<sip:6301192.168.124.154:5060>

Content-Type:application/sdp

Content-Length:375

本发明在传统回应消息体中添加一个头字段:

X-Grandstream-Mcb-Resp:${CONF_HASH}

其中CONF_HASH:利用哈希算法对对端会议室号码(即要合并的对端会议室)进行包装的字符串。

本地会议室收到回应后,根据X-Grandstream-Mcb-Resp检查出该回应是会议室桥接请求对应的回应码,然后在本地数据库中查找CONF_HASH字段,没有则将该字段存在数据库中,有则说明已经桥接,直接挂断。当桥接解除时需要从数据库中删除该字段。

上述步骤S360中用到OPTIONS请求,此请求属于SIP协议的扩展请求,同样的道理,我们需要定制专属于会议室桥接的OPTIONS请求,以区别传统的OPTIONS请求。

传统OPTIONS请求:

OPTIONSsip:carolchicago.comSIP/2.0

Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKhjhs8ass877

Max-Forwards:70

To:<sip:carolchicago.com>

From:Alice<sip:aliceatlanta.com>;tag=1928301774

Call-ID:a84b4c76e66710

CSeq:63104OPTIONS

Contact:<sip:alicepc33.atlanta.com>

Content-Type:application/sdp

Content-Length:0

当OPTIONS携带成员信息时,本发明将Content-Type:application/sdp字段换成Content-Type:application/X-Grandstream-Mcb-info

X-Grandstream-Mcb-info表示此OPTIONS属于会议室桥接,并且携带的数据为XML格式,此XML数据为会议室成员信息。例如:

<?xmlversion="1.0"encoding="UTF-8"?>

<Meeting-roomID=“6300”>

<User1number=“1000”channel=“SIP/1000-00000003”time=“00:20:00”></User1>

<User2number=“1001”channel=“SIP/1001-00000003”time=“00:30:00”></User2>

</Meeting-room>

当IPPBX收到OPTIONS请求后根据X-Grandstream-Mcb判断出此OPTIONS属于会议室桥接,然后开始解析附加XML数据中会议室成员信息,必要时可以存储此信息。此外,进一步给出使用对端接入密码XML的实现,避免明文传输。

当OPTIONS携带控制命令时,本发明将Content-Type:application/sdp字段换成Content-Type:application/X-Grandstream-Mcb-command。

X-Grandstream-Mcb-command:表示此OPTIONS属于会议室桥接,并且携带的数据是命令信息,以XML格式保存。例如:

<?xmlversion="1.0"encoding="UTF-8"?>

<Commandcontent=“meetmekick63001000”>

</Command>

或者

<?xmlversion="1.0"encoding="UTF-8"?>

<Commandcontent=“meetmemute63001000”>

</Command>

当IPPBX收到OPTIONS请求后根据X-Grandstream-Mcb-cammand判断出此OPTIONS属于会议室桥接,并且携带的信息为命令信息。然后开始解析命令并执行命令。再进一步给出使用对端接入密码加密XML的实现,避免明文传输。

图4所示为本发明具体实施例中具有会议室桥接功能的服务器功能框架图。为了实现本发明的会议室桥接功能,在进行通讯桥接的两端服务器应同时支持以下各工作模块的功能。由该图可知,IPPBX服务器包括:信令通讯模块、桥接控制模块、会议室桥接通道、混音处理模块,以及本地会议室。

其中,信令通讯模块,用来发送会议室桥接请求到对方IPPBX服务器,或者接收来自对方的会议室桥接请求并解析。例如,IPPBX1中的信令通讯模块向IPPBX2发送会议室桥接请求,邀请会议室2加入会议室1,然后等待会议室2的回应,在上述会议室桥接请求中附带有会议室2的认证信息。信令通讯模块会检查请求类型是否为会议室桥接请求并且检查其认证信息是否正确,当请求类型和认证信息都正确时回送“OK”应答码。上述桥接请求信令是一个扩展的会议室桥接请求,即在INVITE请求时添加一个自定义字段,并利用哈希算法对所述本地会议室号码进行包装后的请求信令。此外,该信令通讯模块还用来接收或者发送携带本地会议室成员信息的OPTIONS请求,经解析后将其中的业务信令传输给桥接控制模块进一步处理。

桥接控制模块,从信令通讯模块处接收并处理桥接信令,负责建立或者断开会议室桥接通道。例如,IPPBX2的信令通讯模块确认对方请求类型和认证信息都正确则会应答IPPBX1,同时如果IPPBX1收到“OK”应答并解析确认为会议室桥接类型,则会由桥接控制模块建立会议室桥接通道。当IPPBX1发送“BYE”请求给IPPBX2,通知IPPBX2断开会议室桥接,IPPBX2收到IPPBX1的“BYE”请求后,解除桥接通道。

此外,该桥接控制模块接收到来自信令通讯模块的OPTIONS请求后,通过会议室接入密码解密提取出其中的成员信息并输出显示,这样对端会议室就知道本地会议室中有哪些成员;同理,IPPBX2发送携带对端会议室成员信息的OPTIONS请求给IPPBX1,IPPBX1做同样的处理。这样两端会议室就互相知道了对方的成员信息。此时,上述桥接控制模块也会将本地会议室成员信息通过会议室接入密码,使用可逆加密方式加密后由信令通讯模块发送到对端服务器上。

会议室桥接通道,负责进行本地会议室音频信息的传输,以及接收传输来的对端会议室的音频信息。

混音处理模块,负责对输入的音频信息进行混音处理,生成本地会议室音频信息和桥接后的会议室音频信息。对于本地会议室音频信息,是将本地会议室所有通话线路输入的音频信息混合叠加处理而成,该音频信息后续会作为合并时会议室的一路语音输入发送至对端服务器。对于桥接后的会议室音频信息,是本地服务器接收到对端会议室音频信息后,将其作为其中一路通话输入,与本地各与会方的音频信息进行会议混音处理而成,此时的会议混音处理与普通电话会议的混音处理完全一样,因此详细处理过程不再赘述。

本地会议室,负责本地电话会议的召开,即:接收所述本地各与会方线路,如线路1、线路2、线路3输入的音频信息,并将上述音频信息传输至所述混音处理模块;接收来自所述与会方的业务操作信令,以及接收来自所述桥接控制模块的控制信令和接收所述桥接后的会议室音频信息输出至所述本地各与会方。

另外,作为一个较佳实施例,通过本发明的会议室桥接方案也可以实现桥接后的会议室踢人、禁言操作。例如:IPPBX1发送携带踢人命令信息的OPTIONS请求给IPPBX2,IPPBX2收到请求后解析出其中的踢人命令和需要踢的对象,然后由IPPBX2的桥接控制模块对某个成员执行踢人操作,并同时会把执行结果反馈至IPPBX1。由此,会议室1中的成员就可以将会议室2中的某个成员踢出合并后的会议室。如果,在OPTIONS请求中携带禁言信息,可以将对端会议室中某个成员进行禁言操作。上述业务操作均会由桥接控制模块发送相应的操作指令到对端服务器,由其执行对本地与会方话机的业务操作,并同时将执行结果反馈回去。

为了实现上述桥接后的会议室业务操作,桥接控制模块需要将加密后的操作命令通过SIP信令由所述信令通讯模块发送至所述对端服务器,所述对端服务器接收所述加密后的操作命令后解密、鉴权、执行,并将执行结果加密后发送至所述本地服务器,由所述桥接控制模块解密所述执行结果传输给所述本地会议室进行显示。以及在信令通信模块接收来自所述对端服务器的踢人、禁言的业务操作命令,由所述桥接控制模块对所述操作命令解密后进行鉴权、执行,并将执行结果加密后发送给所述对端服务器用于显示。

以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号