提高了通信资源的使用效率。
【附图说明】
[0047] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现 有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本 发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可W 根据该些附图获得其他的附图。
[004引图1为本发明实施例提供的浏览器承载WebRTC应用的层次图；
[0049] 图2为本发明实施例提供的一种基于WebRTC多方通话建立的方法的流程图；
[0050] 图3为本发明实施例提供的一种基于WebRTC多方通话建立的方法的详细流程 图；
[0051] 图4为本发明实施例提供的一种基于WebRTC多方通话建立的方法的流程图；
[0052] 图5为本发明实施例提供的一种基于WebRTC多方通话建立的方法的详细流程 图；
[0053] 图6为本发明实施例提供一种基于WebRTC多方通话建立的设备的结构示意图；
[0054]图7为本发明实施例提供另一种基于WebRTC多方通话建立的装置的结构示意 图；
[00巧]图8为本发明实施例提供另一种基于WebRTC多方通话建立的系统的结构示意 图。
【具体实施方式】
[0056] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他 实施例，都属于本发明保护的范围。
[0057] 本发明实施例基于WebRTC协议，通过该协议提供的基于web浏览器的实时的点 对点技术（PeertoPeer,P2P)，实现包括语音、视频、实时协作、数据传输等的通信。与已 有的基于web的通信技术不同的是，该协议不需要浏览器安装任何插件及附加软件，通过 浏览器内置的音视频解码器，W及信令面和媒体面的协议找，再加上对化vaScript控制会 话建立过程协议即JSEP协议的支持，就可W实现基于WebRTC的网络语音电话业务（Voice overInternetPhone,VoIP)。
[0058] 具体的在WebRTC的应用中，信令通道、信令消息的生成和解析、会话的控制和管 理均是由化vaScript应用层实现的；而媒体参数协商、ICE协商、RTP协议找、媒体编解码 等是由浏览器底层实现的。详细的浏览器承载WebRTC应用的层次图如图1所示。
[0059] 在图1所示的WebRTC应用中，媒体协商、NAT穿越、RTP协议找、媒体流的获取呈 现、编码解码均是有浏览器底层实现的，浏览器通过开放化vaScriptAPI供应用程序调用， 应用程序因此可W根据当前会话的状态控制浏览器底层做出相应的动作。除此之外，应用 程序还负责信令通道的维护，将来自浏览器底层的媒体参数封装成相应的信令信息，或解 析来自对方的信令消息等。浏览器底层通过上层的应用程序来了和通信另一方交换媒体参 数，从而完成媒体协商。
[0060] 本发明实施例提供一种基于WebRTC多方通话建立的方法，如图2所示，该方法包 括：
[0061] 在本实施例的起始阶段，第一用户正在与第H用户进行两方通话，但第一用户需 要建立多方通话，新增的用户为第二用户。
[0062] 101、第一用户向会议应用服务器发送多方通话建立请求。该请求中包括第一扩展 消息，所述第一扩展消息中有待于第一用户建立多方通话的第二用户的信息。
[0063] 上述多方通话至少包括音频流和视频流的传输。进一步的，当上述多方通话是基 于会话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩 展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[0064] 具体的，当上述多方通话中的信令协议采用的是SIP协议时，通过重新定义的XML 数据格式，扩展SIP协议中的Message消息体，利用SIP协议的路由机制对Message消息进 行路由，进而实现应用服务器与客户端之间的信息交互。
[0065] 示例性的，W第一用户为例，客户端发起多方通话请求到应用服务器的扩展消息 如下所示：
[0066] -?A
[0067] 在上述消息中，包括了该消息的序列号"4001"、消息发送者的名称"A"、连接类型 及对应的会话参与者"webRTC---B"、"webC"等信息。
[0068] 102、会议应用服务器接收正在通话的第一用户发送的多方通话建立请求。该请求 中包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户 的f旨息。
[0069] 103、会议应用服务器判断第一用户建立多方通话的权限。
[0070] 104、当第一用户具有建立多方通话的权限时，应用服务器向第一用户发送建立多 方通话的第二扩展消息，并向与第一用户正在通话的第H用户发送第H扩展消息。该第H 扩展消息中包括参加所述多方通话成员的列表信息。
[0071] 与步骤101中信息类似的，应用服务器向第一用户发送建立多方通话的相应消息 举例如下。
[0072]
[0073] 上述消息包括了该消息的序号cHKl、多方通话建立的结果res、W及该多方通话的 序号id,具体的，W上述消息为例，cmd的值4002为建立的多方通话的消息序号，res的值 0表示该多方通话已成功建立，id的值0001表示该多方通话的序号为0001，若res的值不 为0时，表明该多方通话由于其他的原因未能成功建立。
[0074] 105、会议应用服务器向第二用户发送加入多方通话的请求，该请求中包括参加所 述多方通话成员的列表信息。
[00巧]该多方通话的请求是会议应用服务器在确认了多方通话的发起者具有建立多方 通话的权限后，向需要加入多方通话的第H方发送加入多方会议的请求，并携带多方通话 成员的列表信息，W便于第H方对会议发起者进行权限的判断。
[0076] 在本实施例中，会议应用服务器向第二用户发送由第一用户发起的多方通话的加 入请求，并且在该加入请求中还包括了与此多方通话相关的成员列表信息，W便于第二用 户对此多方通话加入的必要性进行判断，并根据判断结果确定是否加入该多方通话。
[0077] 106、第二用户接收应用服务器发送的多方通话的请求，该请求中包括参加所述多 方通话的列表信息。
[0078] 在接收到应用服务器发送的多方通话的请求，根据请求中包括的参加多方通话的 列表信息对该多方通话的必要性进行判断。
[0079] 107、第二用户在确认该多方通话请求的正确性后，向应用服务器发送确认加入多 方通话的信息。
[0080] 该确认加入的信息表示第二用户经过对加入该多方通话的必要性进行判断后，决 定加入由第一用户发起的该多方通话。
[0081] 若第二用户经过判断后，决定不加入该多方通话，则向应用服务器发送拒绝加入 的消息。
[0082] 108、应用服务器接收第二用户发送的确认加入的信息。
[0083] 109、应用服务器分别在第一用户与第二用户间、第H用户与第二用户间建立用于 多方通话的媒体通道。
[0084] 该里建立的媒体通道分别用于第一用户与第二用户、第H用户与第二用户进行通 话，使得在该多方通话中，任意两方之间均有直接的点到点的用于传输音频流和视频流的 传输通道，最终使得在整个多方通话中，每一个用户均有与其他任意用户相连的通道，进一 步的，每一个用户均作为一个WebRTC客户端，在获取到用户自身的至少包括音频流和视频 流的媒体流，将该媒体流于本地进行保存后，将获取到的媒体流可W通过与其他用户相连 的媒体通道发送至其他用户处，从而实现了多方通话。
[0085] 进一步的，每个用户即每一个WebRTC客户端在接收到其他客户端通过对应的媒 体通道传输过来的媒体流时，在用户浏览器的页面上新建多个HTML5的〈Audio〉标签，每个 标签的源Source设置为其中一个客户端的媒体流，该样通过多个〈Audio〉标签就可W同时 播放多个媒体流，也就是在该客户端中可W同时听到多个客户端的声音；对应媒体流中的 视频流的处理方