CN104902111A - 一种基于Web RTC多方通话建立的方法、设备和系统 - Google Patents

Abstract

本发明提供一种基于Web RTC多方通话建立的方法、设备和系统，涉及通信领域，能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。具体通过：第一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话的权限，并向待参加多方通话的用户发送加入多方会议的请求，令第一用户向其他用户发送建立媒体通道的邀请，最终通过建立的媒体通道，并结合媒体流复用以及浏览器内音视频标签的技术，从而实现多方通话。本发明用于实现多方通话。

Description

一种基于Web RTC多方通话建立的方法、设备和系统

技术领域

本发明涉及通信领域，尤其涉及一种基于Web RTC多方通话建立的方法、设备和系统。

背景技术

当前由双方通话变更为多方通话的方法主要通过终端混音模式和会场混音模式实现，其中前者主要应用与参与人数较少的例如双方通话变更为三方通话的场景，而后者则应用于较多人数参与的场景。

终端混音模式的实现是在业务方Ａ与用户Ｂ处于通话保持状态，同时与用户Ｃ正在通话时，通过用户A的终端设备分别将A与B、A与C的媒体流进行混音，接着将混音后的媒体流再分别发送至用户B和用户C，使得用户B和用户C能够接收到A与C、A与B的图像和声音，从而间接实现三方通话的效果。

会场混音模式的实现是有业务方Ａ与用户Ｂ处于通话保持状态，同时与用户Ｃ正在通话时，业务方A首先通过会场服务器（MediaResource Server，MRS）申请多方会议的会场资源，接着将A与B、A与C的通话分别通过会话重协商，分别转移到与会场服务器建立的媒体通道中，最终通过与会场服务器的连接，实现多方通话的效果。

虽然上述的终端混音模式和会场混音模式均能实现有双方通话变更为多方通话的要求，但是前者需要能够进行本地混音的终端设备的支持，并且如果进行的多方通话中包含视频时，会对混音设备的性能有很高的要求；后者的实现更是需要MRS的支持，否则无法实现，进一步的，通过会场混音模式实现多方通话每一次都需要申请会场资源，步骤繁琐，当由多方通话恢复成双方通话时，申请的会场资源也不能及时释放，导致资源浪费。

发明内容

本发明的实施例提供一种基于Web RTC多方通话建立的方法、设备和系统，能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，提供一种基于Web RTC多方通话建立的方法，所述方法包括：

接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；

判断所述第一用户建立所述多方通话的权限；

当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息；

向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息；

接收所述第二用户发送的确认加入的信息；

分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道；

通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。

在第一种可能的实现方式中，结合第一方面，所述多方通话至少包括音频流和视频流的传输。

在第二种可能的实现方式中，结合第一方面，所述方法还包括：

当所述多方通话基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

在第三种可能的实现方式中，结合第一方面，所述第二用户为至少一个用户终端。

第二方面，提供一种基于Web RTC多方通话建立的方法，所述方法包括：

向应用服务器发送多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中待建立多方通话的第二用户的消息；

接收所述应用服务器发送的确认建立多方通话的第二扩展消息；

建立与所述第二用户的用于多方通话的媒体通道；

通过所述媒体通道进行多方通话。

在第一种可能的实现方式中，结合第二方面，所述建立与所述第二用户的用于多方通话的媒体通道包括：

向所述第二用户发送建立所述媒体通道的邀请信息；

接收所述第二用户发送的回复邀请的信息，建立与所述第二用户的媒体通道。

在第二种可能的实现方式中，结合第二方面，所述方法包括：

获取本地的媒体流，保存所述本地的媒体流；

将所述本地的媒体流通过与所述第二用户间的媒体通道发送至所述第二用户，从与所述第二用户间的媒体通道接收所述第二用户的媒体流。

在第三种可能的实现方式中，结合第二方面，所述方法还包括：

将所述本地的媒体流通过与第三用户间的媒体通道发送至所述第三用户，从与所述第三用户间的媒体通道接收所述第三用户的媒体流。

第三方面，提供一种基于Web RTC多方通话的设备，所述设备包括：

第一接收单元，用于接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；

权限判断单元，用于判断所述第一用户建立所述多方通话的权限；

第一消息发送单元，用于当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息；

第一请求发送单元，用于向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息；

第一通道建立单元，用于分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道；

第一多方通话单元，用于通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。

在第一种可能的实现方式中，结合第三方面，所述多方通话至少包括音频流和视频流的传输。

在第二种可能的实现方式中，结合第三方面，在所述设备中，当所述多方通话基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

在第三种可能的实现方式中，结合第三方面，所述第二用户为至少一个用户终端。

第四方面，提供一种基于Web RTC多方通话建立的系统，所述设备至少包括：

如第一方面所示的会议应用服务器，或如第三方面所述的会议应用服务器；

如第二方面所示的第一用户。

本发明实施例提供一种基于Web RTC多方通话建立的方法、设备和系统，通过第一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话的权限，在确定第一用户具有建立多方通话的请求后，向待参加多方通话的用户发送加入多方会议的请求并附带有该多方通话的成员列表信息，以便于其他用户对是否加入多方通话进行判断，待其他用户向会议应用服务器发送加入多方会议的信息后，令第一用户向其他用户发送建立媒体通道的邀请，并在其他用户回复接收建立媒体通道的信息，从而成功建立第一用户与其他用户的媒体通道。最终通过建立的媒体通道，并结合媒体流复用以及浏览器内音视频标签的技术，从而实现多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的浏览器承载Web RTC应用的层次图；

图2为本发明实施例提供的一种基于Web RTC多方通话建立的方法的流程图；

图3为本发明实施例提供的一种基于Web RTC多方通话建立的方法的详细流程图；

图4为本发明实施例提供的一种基于Web RTC多方通话建立的方法的流程图；

图5为本发明实施例提供的一种基于Web RTC多方通话建立的方法的详细流程图；

图6为本发明实施例提供一种基于Web RTC多方通话建立的设备的结构示意图；

图7为本发明实施例提供另一种基于Web RTC多方通话建立的装置的结构示意图；

图8为本发明实施例提供另一种基于Web RTC多方通话建立的系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例基于Web RTC协议，通过该协议提供的基于web浏览器的实时的点对点技术（Peer to Peer，P2P），实现包括语音、视频、实时协作、数据传输等的通信。与已有的基于web的通信技术不同的是，该协议不需要浏览器安装任何插件及附加软件，通过浏览器内置的音视频解码器，以及信令面和媒体面的协议栈，再加上对JavaScript控制会话建立过程协议即JSEP协议的支持，就可以实现基于Web RTC的网络语音电话业务（Voice over Internet Phone，VoIP）。

具体的在Web RTC的应用中，信令通道、信令消息的生成和解析、会话的控制和管理均是由JavaScript应用层实现的；而媒体参数协商、ICE协商、RTP协议栈、媒体编解码等是由浏览器底层实现的。详细的浏览器承载Web RTC应用的层次图如图1所示。

在图1所示的Web RTC应用中，媒体协商、NAT穿越、RTP协议栈、媒体流的获取呈现、编码解码均是有浏览器底层实现的，浏览器通过开放JavaScript API供应用程序调用，应用程序因此可以根据当前会话的状态控制浏览器底层做出相应的动作。除此之外，应用程序还负责信令通道的维护，将来自浏览器底层的媒体参数封装成相应的信令信息，或解析来自对方的信令消息等。浏览器底层通过上层的应用程序来了和通信另一方交换媒体参数，从而完成媒体协商。

本发明实施例提供一种基于Web RTC多方通话建立的方法，如图2所示，该方法包括：

在本实施例的起始阶段，第一用户正在与第三用户进行两方通话，但第一用户需要建立多方通话，新增的用户为第二用户。

101、第一用户向会议应用服务器发送多方通话建立请求。该请求中包括第一扩展消息，所述第一扩展消息中有待于第一用户建立多方通话的第二用户的信息。

上述多方通话至少包括音频流和视频流的传输。进一步的，当上述多方通话是基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

具体的，当上述多方通话中的信令协议采用的是SIP协议时，通过重新定义的XML数据格式，扩展SIP协议中的Message消息体，利用SIP协议的路由机制对Message消息进行路由，进而实现应用服务器与客户端之间的信息交互。

示例性的，以第一用户为例，客户端发起多方通话请求到应用服务器的扩展消息如下所示：

在上述消息中，包括了该消息的序列号“4001”、消息发送者的名称“A”、连接类型及对应的会话参与者“web RTC---B”、“web---C”等信息。

102、会议应用服务器接收正在通话的第一用户发送的多方通话建立请求。该请求中包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息。

103、会议应用服务器判断第一用户建立多方通话的权限。

104、当第一用户具有建立多方通话的权限时，应用服务器向第一用户发送建立多方通话的第二扩展消息，并向与第一用户正在通话的第三用户发送第三扩展消息。该第三扩展消息中包括参加所述多方通话成员的列表信息。

与步骤101中信息类似的，应用服务器向第一用户发送建立多方通话的相应消息举例如下。

上述消息包括了该消息的序号cmd、多方通话建立的结果res、以及该多方通话的序号id，具体的，以上述消息为例，cmd的值4002为建立的多方通话的消息序号，res的值0表示该多方通话已成功建立，id的值0001表示该多方通话的序号为0001，若res的值不为0时，表明该多方通话由于其他的原因未能成功建立。

105、会议应用服务器向第二用户发送加入多方通话的请求，该请求中包括参加所述多方通话成员的列表信息。

该多方通话的请求是会议应用服务器在确认了多方通话的发起者具有建立多方通话的权限后，向需要加入多方通话的第三方发送加入多方会议的请求，并携带多方通话成员的列表信息，以便于第三方对会议发起者进行权限的判断。

在本实施例中，会议应用服务器向第二用户发送由第一用户发起的多方通话的加入请求，并且在该加入请求中还包括了与此多方通话相关的成员列表信息，以便于第二用户对此多方通话加入的必要性进行判断，并根据判断结果确定是否加入该多方通话。

106、第二用户接收应用服务器发送的多方通话的请求，该请求中包括参加所述多方通话的列表信息。

在接收到应用服务器发送的多方通话的请求，根据请求中包括的参加多方通话的列表信息对该多方通话的必要性进行判断。

107、第二用户在确认该多方通话请求的正确性后，向应用服务器发送确认加入多方通话的信息。

该确认加入的信息表示第二用户经过对加入该多方通话的必要性进行判断后，决定加入由第一用户发起的该多方通话。

若第二用户经过判断后，决定不加入该多方通话，则向应用服务器发送拒绝加入的消息。

108、应用服务器接收第二用户发送的确认加入的信息。

109、应用服务器分别在第一用户与第二用户间、第三用户与第二用户间建立用于多方通话的媒体通道。

这里建立的媒体通道分别用于第一用户与第二用户、第三用户与第二用户进行通话，使得在该多方通话中，任意两方之间均有直接的点到点的用于传输音频流和视频流的传输通道，最终使得在整个多方通话中，每一个用户均有与其他任意用户相连的通道，进一步的，每一个用户均作为一个Web RTC客户端，在获取到用户自身的至少包括音频流和视频流的媒体流，将该媒体流于本地进行保存后，将获取到的媒体流可以通过与其他用户相连的媒体通道发送至其他用户处，从而实现了多方通话。

进一步的，每个用户即每一个Web RTC客户端在接收到其他客户端通过对应的媒体通道传输过来的媒体流时，在用户浏览器的页面上新建多个HTML5的<Audio>标签，每个标签的源Source设置为其中一个客户端的媒体流，这样通过多个<Audio>标签就可以同时播放多个媒体流，也就是在该客户端中可以同时听到多个客户端的声音；对应媒体流中的视频流的处理方法类似，通过建立多个<Video>标签，使得在客户端中可以同时播放多个客户端的视频图像，通过上述对媒体流进行复用及同时处理多路的媒体流，从而实现多路通话。

与步骤101及104中的消息格式类似，会议应用服务器控制待加入的用户接入多方通话的信息示例性的为：

上述信息包括了该消息的序号cmd、该多方通话的主控制方（也称为该多方通话的主席）的序号userid、以及该多方通话的其他参与者的序号attendee。

具体的，以上述消息为例，cmd的值4003为该多方通话的序号，userID的值为a表明该多方通话的主控制方（或该多方通话的主席）的序号，attendee的值分别为b、c表明该多方通话的其他参与者的序号。

根据上述描述，如图3所示，建立媒体通道的具体步骤包括：

1091、第一用户向第二用户发送建立媒体通道的邀请信息。

1092、第二用户接收第一用户发送的建立媒体通道的邀请信息。

1093、第二用户判断邀请信息发送方的正确性。

这里是第二用户根据事先从应用服务器接收到的参加多方通话成员的列表信息，判断邀请信息的发送方也就是第一用户的正确性，或者是第一用户是否具有发起多方通话的权限。

1094、第二用户确定邀请信息发送方正确后，向第一用户回复接收邀请的信息，并建立于第一用户的媒体通道。

由于第二用户已经判断过邀请信息发送方也就是第一用户发起多方通话的权限，因此，第二用户在建立于第一用户的媒体通道后，再接收到来自于第一用户的消息后，采取有别于正常通话消息的处理方式。

在正常的通话方式下，由于第二用户已经处于多方通话的环境中，也就是处于通话状态，因此，再接收到来自于其他用户的通话请求后，默认是要向其他用户返回“您所拨打的用户正在通话中”等类似的占线信息；但是当前由于第一用户是处于第二用户事先从会议应用服务器的多方通话成员的信息列表中的，因此，对于像第一用户这样来自于多方通话成员的信息列表中的用户发送的通话请求及通话信息，第二用户会采取会议内会话请求处理方式，即不弹出对话窗口或者不触发振铃模式，直接自动接收通话。

尤其是在第二用户与第一用户建立了媒体通道后的第一条通话时，采取上述“静默”处理的优点在于可以令第二用户更快的进入到已接入多方通话的状态，也就是仅仅是在第二用户向会议应用处理器返回加入多方通话后，针对于由第一用户或其他用户发送的建立媒体通道的请求，不再进行多余的提示，这样有助于令第二用户尽快的进入多方通话的状态中，避免第二用户会接收到多次加入多方通话的提示，从而提升第二用户的体验。

至此，第一用户与第二用户之间的信息传输通道已经完全建立完毕，至于之前与第一用户正在进行双方通话的第三用户，它与第二用户建立媒体通道的方式与上述针对于第一用户和第二用户建立媒体通道的方法完全一致，并且值得一提的是，这里的第三用户与第二用户建立媒体通道的时间和第一用户与第二用户建立媒体通道在时间上是同时进行的，这样可以最大程度上节省建立会议媒体通道的时间，在本实施例中为了表述清晰，故将二者分开进行描述，并在此进行说明。

110、按照步骤1091至1094所示的方法，依次完成第一用户、第三用户与所有待参加多方通话用户的媒体通道的建立，并通过建立好的媒体通道，进行多方通话。

本发明实施例提供一种基于Web RTC多方通话建立的方法，通过第一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话的权限，在确定第一用户具有建立多方通话的请求后，向待参加多方通话的用户发送加入多方会议的请求并附带有该多方通话的成员列表信息，以便于其他用户对是否加入多方通话进行判断，待其他用户向会议应用服务器发送加入多方会议的信息后，令第一用户向其他用户发送建立媒体通道的邀请，并在其他用户回复接收建立媒体通道的信息，从而成功建立第一用户与其他用户的媒体通道。最终通过建立的媒体通道，并结合媒体流复用以及浏览器内音视频标签的技术，从而实现多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

本发明实施例提供一种基于Web RTC多方通话建立的方法，如图4所示，该方法包括：

本实施例用于将正在通话的两方，变更成三方通话的通话形式。由于使用范围较小，因此仅作为上一实施例将双方通话变更为多方通话的特例，也作为一种基于Web RTC协议，实现多方通话方法的补充。

在本实施例的起始阶段，第一用户与第二用户处于通话保持状态，同时第一用户与第三用户处于正在通话中。

201、第一用户向应用服务器发送建立多方通话的第一信息。

上述多方通话至少包括音频流和视频流的传输。进一步的，当上述多方通话是基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

具体的，当上述多方通话中的信令协议采用的是SIP协议时，通过重新定义的XML数据格式，扩展SIP协议中的Message消息体，利用SIP协议的路由机制对Message消息进行路由，进而实现应用服务器与客户端之间的信息交互。

202、应用服务器判断第一用户建立多方通话的权限。

203、当第一用户具有建立多方通话的权限后，应用服务器向第一用户发送成功建立多方通话的第二消息。

204、应用服务器向第三用户发送第三消息，所述第三消息中包括第二用户的相关信息，和第一用户成功建立多方通话的消息。

205、第三用户接收到第三消息后，将自身的状态变更为“多方通话”。

206、应用服务器向第二用户发送第四消息，所述第四消息中包括第三用户的相关信息，和第一用户成功建立多方通话的消息。

207、第二用户将自身的状态变更为“多方通话”，并与第三用户建立媒体通道。

208、在第二用户与第三用户建立媒体通道后，结合已经处于通话状态的第一用户和第三用户，实现多方通话。

这里建立的媒体通道分别用于第二用户与第三用户进行通话，使得在该多方通话中，任意两方之间均有直接的点到点的用于传输音频流和视频流的传输通道，最终使得在整个多方通话中，每一个用户均有与其他任意用户相连的通道，进一步的，每一个用户均作为一个WebRTC客户端，在获取到用户自身的至少包括音频流和视频流的媒体流，将该媒体流于本地进行保存后，将获取到的媒体流可以通过与其他用户相连的媒体通道发送至其他用户处，从而实现了多方通话。

进一步的，每个用户即每一个Web RTC客户端在接收到其他客户端通过对应的媒体通道传输过来的媒体流时，在用户浏览器的页面上新建多个HTML5的<Audio>标签，每个标签的源Source设置为其中一个客户端的媒体流，这样通过多个<Audio>标签就可以同时播放多个媒体流，也就是在该客户端中可以同时听到多个客户端的声音；对应媒体流中的视频流的处理方法类似，通过建立多个<Video>标签，使得在客户端中可以同时播放多个客户端的视频图像，通过上述对媒体流进行复用及同时处理多路的媒体流，从而实现多路通话。

在步骤207中，如图5所述，第二用户与第三用户建立媒体通道具体包括：

2071、第二用户恢复与第一用户的通话状态，并向应用服务器发送建立媒体通道的邀请信息，所述邀请信息中包括第二用户的属性参数。

2072、应用服务器判断所述邀请消息为多方通话内的呼叫请求，在不触发补充业务的前提下，将所述邀请信息转发至第三用户。

2073、第三用户根据已确定的“多方通话”的状态，并结合所述邀请消息为多方通话内的呼叫请求，向应用服务器发送第五消息，所述第五消息包括第三用户的属性参数。

2074、应用服务器将第五消息发送至第二用户，成功建立第二用户与第三用户的媒体通道。

由于第三用户已经与第一用户处于通话状态，因此，步骤2072中，应用服务器在向第三用户转发所述邀请信息前，需要对所述邀请信息的发送方进行判断。

在正常的通话方式下，由于第三用户已经处于多方通话的环境中，也就是处于通话状态，因此，再接收到来自于其他用户的信息后，默认是要向其他用户返回“您所拨打的用户正在通话中”等类似的占线信息；但是当前由于发送消息的第二用户是处于应用服务器已经获取到的多方通话成员中的，因此，对于像第二用户这样来自于多方通话成员中的用户发送的通话请求及通话信息，第三用户会采取会议内会话请求处理方式，即不弹出对话窗口或者不触发振铃模式，直接自动接收通话。

尤其是在第三用户已经将自身状态变更为“多方通话”时，采取上述“静默”处理的优点在于可以令第三用户更快的进入到已接入多方通话的状态，也就是仅仅是在第三用户接收到应用处理器发送的第三消息后，针对于由第二用户或其他用户发送的建立媒体通道的请求，不再进行多余的提示，这样有助于令第三用户尽快的进入多方通话的状态中，避免第三用户会接收到多次加入多方通话的提示，从而提升第三用户的体验。

在上述步骤中，各个用户与会议应用服务器及呼叫应用服务器之间的信息传输，均需要经过会话管理器Session Manager的转发，这样可以实现消息传输的准确性与及时性，以免由于会议应用服务器和呼叫服务器由于信息处理不及时导致的信息丢失或延迟。因为上述步骤众多，信息传输路径复杂，就没有将会话管理器在步骤中的信息转发过程进行描述，仅是将其功能在这里进行统一描述，但并不代表会话管理器没有参与上述步骤中的信息传输。

本发明实施例提供一种基于Web RTC多方通话建立的方法，通过第一用户向应用服务器发送建立多方通话的第一消息，应用服务器判断第一用户是否具有建立多方通话的权限，并在确定第一用户具有建立多方通话的权限后，向第一用户发送成功建立多方通话的第二消息，同时应用服务器向第三用户和第二用户分别发送第三、第四消息，以便第三用户和第二用户获取第一用户已经成功建立多方通话的消息并变更自身状态，在第二用户和第三用户建立媒体通道后，结合已经处于通话状态的第一用户和第三用户，最终实现多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

本发明实施例提供一种基于Web RTC多方通话建立的设备1，如图6所示，该设备具体包括：

第一接收单元11，用于接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；

权限判断单元12，用于判断所述第一用户建立所述多方通话的权限；

第一消息发送单元13，用于当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息；

第一请求发送单元14，用于向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息；

第一通道建立单元15，用于分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道；

第一多方通话单元16，用于通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。

在设备1中，所述多方通话至少包括音频流和视频流的传输。

进一步的，所述多方通话至少包括音频流和视频流的传输。

当所述多方通话基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

所述第二用户为至少一个用户终端。

本发明实施例提供一种基于Web RTC多方通话建立的设备，该设备接收第一用户发送的多方通话建立请求，并判断第一用户建立多方通话的权限，当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息，分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道，通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

本发明实施例还提供一种基于Web RTC多方通话建立的装置2，如图7所示，该装置2包括：总线21；以及连接到总线21上的存储器22、处理器23、接收器24和发射器25，其中存储器22用于存储相关指令，该处理器23执行该指令用于接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；该处理器23执行相关指令还用于判断所述第一用户建立所述多方通话的权限；该处理器23执行相关指令还用于当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息；该处理器23执行相关指令还用于向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息；该处理器23执行相关指令还用于接收所述第二用户发送的确认加入的信息；该处理器23执行相关指令还用于分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道；该处理器23执行相关指令还用于通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。

在本发明实施例中，可选的，该处理器23执行相关指令进行的多方通话至少包括音频流和视频流的传输。

在本发明实施例中，可选的，该处理器23执行相关指令进行的多方通话基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

在本发明实施例中，可选的，该处理器23执行相关指令进行多方通话中的第二用户为至少一个用户终端。

本发明实施例提供一种基于Web RTC多方通话建立的装置，该设备接收第一用户发送的多方通话建立请求，并判断第一用户建立多方通话的权限，当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息，分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道，通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

本发明实施例提供一种基于Web RTC多方通话建立的系统3，如图8所示，该系统3至少包括：

如上述实施例中设备1所示的会议应用服务器，或如上述实施例装置2所述的会议应用服务器；

如上述实施例中所示的第一用户。

本发明实施例提供一种基于Web RTC多方通话建立的系统，通过接收应用服务器发送的加入多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，在确认所述多方通话请求的正确性后，向所述应用服务器发送确认加入所述多方通话的信息，建立与第一用户的用于多方通话的媒体通道，最终通过所述媒体通道进行多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法，装置，和系统，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，简称ROM）、随机存取存储器（Random Access Memory，简称RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种基于Web RTC多方通话建立的方法，其特征在于，所述方法包括：

接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；

判断所述第一用户建立所述多方通话的权限；

当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息；

向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息；

接收所述第二用户发送的确认加入的信息；

分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道；

通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。

2.根据权利要求1所述的方法，其特征在于，所述多方通话至少包括音频流和视频流的传输。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述多方通话基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

4.一种基于Web RTC多方通话建立的方法，其特征在于，所述方法包括：

向应用服务器发送多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中待建立多方通话的第二用户的消息；

接收所述应用服务器发送的确认建立多方通话的第二扩展消息；

建立与所述第二用户的用于多方通话的媒体通道；

通过所述媒体通道进行多方通话。

5.根据权利要求4所述的方法，其特征在于，所述建立与所述第二用户的用于多方通话的媒体通道包括：

向所述第二用户发送建立所述媒体通道的邀请信息；

接收所述第二用户发送的回复邀请的信息，建立与所述第二用户的媒体通道。

6.根据权利要求4所述的方法，其特征在于，所述方法包括：

获取本地的媒体流，保存所述本地的媒体流；

将所述本地的媒体流通过与所述第二用户间的媒体通道发送至所述第二用户，从与所述第二用户间的媒体通道接收所述第二用户的媒体流。

7.根据权利要求4所述的方法，其特征在于，所述方法还包括：

将所述本地的媒体流通过与第三用户间的媒体通道发送至所述第三用户，从与所述第三用户间的媒体通道接收所述第三用户的媒体流。

8.一种基于Web RTC多方通话建立的设备，其特征在于，所述设备包括：

第一接收单元，用于接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；

权限判断单元，用于判断所述第一用户建立所述多方通话的权限；

第一消息发送单元，用于当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息；

第一请求发送单元，用于向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息；

第一通道建立单元，用于分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多方通话的媒体通道；

第一多方通话单元，用于通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。

9.根据权利要求8所述的设备，其特征在于，所述多方通话至少包括音频流和视频流的传输。

10.根据权利要求8所述的设备，其特征在于，在所述设备中，当所述多方通话基于会话发起协议（Session Initiation Protocol，SIP）时，所述第一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。

11.一种基于Web RTC多方通话建立的系统，其特征在于，所述系统至少包括：

如权利要求1至3任意一项所述的会议应用服务器，或如权利要求8至10任意一项所述的会议应用服务器；

如权利要求4至7任意一项所述的第一用户。