一种基于WebRTC多方通话建立的方法、设备和系统的制作方法
一种基于Web RTC多方通话建立的方法、设备和系统的制作方法
【技术领域】
[0001] 本发明涉及通信领域，尤其涉及一种基于WebRTC多方通话建立的方法、设备和系 统。
【背景技术】
[0002] 当前由双方通话变更为多方通话的方法主要通过终端混音模式和会场混音模式 实现，其中前者主要应用与参与人数较少的例如双方通话变更为H方通话的场景，而后者 则应用于较多人数参与的场景。
[0003] 终端混音模式的实现是在业务方A与用户B处于通话保持状态，同时与用户C正 在通话时，通过用户A的终端设备分别将A与B、A与C的媒体流进行混音，接着将混音后的 媒体流再分别发送至用户B和用户C，使得用户B和用户C能够接收到A与C、A与B的图 像和声音，从而间接实现H方通话的效果。
[0004] 会场混音模式的实现是有业务方A与用户B处于通话保持状态，同时与用户C正 在通话时，业务方A首先通过会场服务器（MediaResourceServer,MRS)申请多方会议的 会场资源，接着将A与B、A与C的通话分别通过会话重协商，分别转移到与会场服务器建立 的媒体通道中，最终通过与会场服务器的连接，实现多方通话的效果。
[0005] 虽然上述的终端混音模式和会场混音模式均能实现有双方通话变更为多方通话 的要求，但是前者需要能够进行本地混音的终端设备的支持，并且如果进行的多方通话中 包含视频时，会对混音设备的性能有很高的要求；后者的实现更是需要MRS的支持，否则 无法实现，进一步的，通过会场混音模式实现多方通话每一次都需要申请会场资源，步骤繁 琐，当由多方通话恢复成双方通话时，申请的会场资源也不能及时释放，导致资源浪费。
【发明内容】
[0006] 本发明的实施例提供一种基于WebRTC多方通话建立的方法、设备和系统，能够降 低由于进行本地混音造成的对设备性能较高的要求，还可W无需联系会场服务器进行繁琐 的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终 减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0007] 为达到上述目的，本发明的实施例采用如下技术方案：
[0008] 第一方面，提供一种基于WebRTC多方通话建立的方法，所述方法包括：
[0009] 接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消 息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；
[0010] 判断所述第一用户建立所述多方通话的权限；
[0011] 当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立 所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第H用户发送第H扩展消 息，所述第H扩展消息中包括参加所述多方通话成员的列表信息；
[0012] 向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通 话成员的列表信息；
[0013] 接收所述第二用户发送的确认加入的信息；
[0014] 分别在所述第一用户与所述第二用户间、所述第H用户与所述第二用户间建立用 于多方通话的媒体通道；
[0015] 通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。
[0016] 在第一种可能的实现方式中，结合第一方面，所述多方通话至少包括音频流和视 频流的传输。
[0017] 在第二种可能的实现方式中，结合第一方面，所述方法还包括：
[0018] 当所述多方通话基于会话发起协议（SessionInitiationProtocol,SIP)时，所 述第一扩展消息、所述第二扩展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[0019] 在第H种可能的实现方式中，结合第一方面，所述第二用户为至少一个用户终端。
[0020] 第二方面，提供一种基于WebRTC多方通话建立的方法，所述方法包括：
[0021] 向应用服务器发送多方通话建立请求，所述请求包括第一扩展消息，所述第一扩 展消息中待建立多方通话的第二用户的消息；
[0022] 接收所述应用服务器发送的确认建立多方通话的第二扩展消息；
[0023] 建立与所述第二用户的用于多方通话的媒体通道；
[0024] 通过所述媒体通道进行多方通话。
[0025] 在第一种可能的实现方式中，结合第二方面，所述建立与所述第二用户的用于多 方通话的媒体通道包括：
[0026]向所述第二用户发送建立所述媒体通道的邀请信息；
[0027]接收所述第二用户发送的回复邀请的信息，建立与所述第二用户的媒体通道。
[0028] 在第二种可能的实现方式中，结合第二方面，所述方法包括：
[0029] 获取本地的媒体流，保存所述本地的媒体流；
[0030] 将所述本地的媒体流通过与所述第二用户间的媒体通道发送至所述第二用户，从 与所述第二用户间的媒体通道接收所述第二用户的媒体流。
[0031] 在第H种可能的实现方式中，结合第二方面，所述方法还包括：
[0032] 将所述本地的媒体流通过与第H用户间的媒体通道发送至所述第H用户，从与所 述第H用户间的媒体通道接收所述第H用户的媒体流。
[0033] 第H方面，提供一种基于WebRTC多方通话的设备，所述设备包括：
[0034] 第一接收单元，用于接收正在通话的第一用户发送的多方通话建立请求，所述请 求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户 的信息；
[00巧]权限判断单元，用于判断所述第一用户建立所述多方通话的权限；
[0036] 第一消息发送单元，用于当所述第一用户具有建立所述多方通话的权限时，向所 述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话 的第H用户发送第H扩展消息，所述第H扩展消息中包括参加所述多方通话成员的列表信 息；
[0037] 第一请求发送单元，用于向所述第二用户发送加入所述多方通话的请求，所述请 求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信 息；
[0038] 第一通道建立单元，用于分别在所述第一用户与所述第二用户间、所述第H用户 与所述第二用户间建立用于多方通话的媒体通道；
[0039] 第一多方通话单元，用于通过已经建立的所述用于多方通话的媒体通道，进行所 述多方通话。
[0040] 在第一种可能的实现方式中，结合第H方面，所述多方通话至少包括音频流和视 频流的传输。
[0041] 在第二种可能的实现方式中，结合第H方面，在所述设备中，当所述多方通话基于 会话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩展 消息、所述第H扩展消息为基于所述SIP的扩展消息。
[0042] 在第H种可能的实现方式中，结合第H方面，所述第二用户为至少一个用户终端。
[0043] 第四方面，提供一种基于WebRTC多方通话建立的系统，所述设备至少包括：
[0044] 如第一方面所示的会议应用服务器，或如第H方面所述的会议应用服务器；
[0045] 如第二方面所示的第一用户。
[0046] 本发明实施例提供一种基于WebRTC多方通话建立的方法、设备和系统，通过第 一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有 建立多方通话的权限，在确定第一用户具有建立多方通话的请求后，向待参加多方通话的 用户发送加入多方会议的请求并附带有该多方通话的成员列表信息，W便于其他用户对是 否加入多方通话进行判断，待其他用户向会议应用服务器发送加入多方会议的信息后，令 第一用户向其他用户发送建立媒体通道的邀请，并在其他用户回复接收建立媒体通道的信 息，从而成功建立第一用户与其他用户的媒体通道。最终通过建立的媒体通道，并结合媒体 流复用W及浏览器内音视频标签的技术，从而实现多方通话；能够降低由于进行本地混音 造成的对设备性能较高的要求，还可W无需联系会场服务器进行繁琐的会场资源申请，进 一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建 立步骤， 提高了通信资源的使用效率。
【附图说明】
[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同时听到多个客户端的声音；对应媒体流中的 视频流的处理方 法类似，通过建立多个〈Video〉标签，使得在客户端中可W同时播放多个 客户端的视频图像，通过上述对媒体流进行复用及同时处理多路的媒体流，从而实现多路 通话。
[008引与步骤101及104中的消息格式类似，会议应用服务器控制待加入的用户接入多 方通话的信息示例性的为：
[0087]
[008引
[0089] 上述信息包括了该消息的序号CHKl、该多方通话的主控制方(也称为该多方通话的 主席）的序号useritW及该多方通话的其他参与者的序号attendee。
[0090] 具体的，W上述消息为例，cmd的值4003为该多方通话的序号，userlD的值为a表 明该多方通话的主控制方(或该多方通话的主席）的序号，attendee的值分别为b、c表明该 多方通话的其他参与者的序号。
[0091] 根据上述描述，如图3所示，建立媒体通道的具体步骤包括：
[0092] 1091、第一用户向第二用户发送建立媒体通道的邀请信息。
[0093] 1092、第二用户接收第一用户发送的建立媒体通道的邀请信息。
[0094] 1093、第二用户判断邀请信息发送方的正确性。
[0095] 该里是第二用户根据事先从应用服务器接收到的参加多方通话成员的列表信息， 判断邀请信息的发送方也就是第一用户的正确性，或者是第一用户是否具有发起多方通话 的权限。
[0096] 1094、第二用户确定邀请信息发送方正确后，向第一用户回复接收邀请的信息，并 建立于第一用户的媒体通道。
[0097] 由于第二用户已经判断过邀请信息发送方也就是第一用户发起多方通话的权限， 因此，第二用户在建立于第一用户的媒体通道后，再接收到来自于第一用户的消息后，采取 有别于正常通话消息的处理方式。
[0098] 在正常的通话方式下，由于第二用户已经处于多方通话的环境中，也就是处于通 话状态，因此，再接收到来自于其他用户的通话请求后，默认是要向其他用户返回"您所拨 打的用户正在通话中"等类似的占线信息；但是当前由于第一用户是处于第二用户事先从 会议应用服务器的多方通话成员的信息列表中的，因此，对于像第一用户该样来自于多方 通话成员的信息列表中的用户发送的通话请求及通话信息，第二用户会采取会议内会话请 求处理方式，即不弹出对话窗口或者不触发振铃模式，直接自动接收通话。
[0099] 尤其是在第二用户与第一用户建立了媒体通道后的第一条通话时，采取上述"静 默"处理的优点在于可W令第二用户更快的进入到已接入多方通话的状态，也就是仅仅是 在第二用户向会议应用处理器返回加入多方通话后，针对于由第一用户或其他用户发送的 建立媒体通道的请求，不再进行多余的提示，该样有助于令第二用户尽快的进入多方通话 的状态中，避免第二用户会接收到多次加入多方通话的提示，从而提升第二用户的体验。
[0100] 至此，第一用户与第二用户之间的信息传输通道已经完全建立完毕，至于之前与 第一用户正在进行双方通话的第H用户，它与第二用户建立媒体通道的方式与上述针对于 第一用户和第二用户建立媒体通道的方法完全一致，并且值得一提的是，该里的第H用户 与第二用户建立媒体通道的时间和第一用户与第二用户建立媒体通道在时间上是同时进 行的，该样可W最大程度上节省建立会议媒体通道的时间，在本实施例中为了表述清晰，故 将二者分开进行描述，并在此进行说明。
[0101] 110、按照步骤1091至1094所示的方法，依次完成第一用户、第H用户与所有待参 加多方通话用户的媒体通道的建立，并通过建立好的媒体通道，进行多方通话。
[0102] 本发明实施例提供一种基于WebRTC多方通话建立的方法，通过第一用户向会议 应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话 的权限，在确定第一用户具有建立多方通话的请求后，向待参加多方通话的用户发送加入 多方会议的请求并附带有该多方通话的成员列表信息，W便于其他用户对是否加入多方通 话进行判断，待其他用户向会议应用服务器发送加入多方会议的信息后，令第一用户向其 他用户发送建立媒体通道的邀请，并在其他用户回复接收建立媒体通道的信息，从而成功 建立第一用户与其他用户的媒体通道。最终通过建立的媒体通道，并结合媒体流复用W及 浏览器内音视频标签的技术，从而实现多方通话；能够降低由于进行本地混音造成的对设 备性能较高的要求，还可W无需联系会场服务器进行繁琐的会场资源申请，进一步节省当 多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提 高了通信资源的使用效率。
[0103] 本发明实施例提供一种基于WebRTC多方通话建立的方法，如图4所示，该方法包 括：
[0104] 本实施例用于将正在通话的两方，变更成H方通话的通话形式。由于使用范围较 小，因此仅作为上一实施例将双方通话变更为多方通话的特例，也作为一种基于WebRTC协 议，实现多方通话方法的补充。
[0105] 在本实施例的起始阶段，第一用户与第二用户处于通话保持状态，同时第一用户 与第H用户处于正在通话中。
[0106] 201、第一用户向应用服务器发送建立多方通话的第一信息。
[0107] 上述多方通话至少包括音频流和视频流的传输。进一步的，当上述多方通话是基 于会话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩 展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[010引具体的，当上述多方通话中的信令协议采用的是SIP协议时，通过重新定义的XML数据格式，扩展SIP协议中的Message消息体，利用SIP协议的路由机制对Message消息进 行路由，进而实现应用服务器与客户端之间的信息交互。
[0109] 202、应用服务器判断第一用户建立多方通话的权限。
[0110] 203、当第一用户具有建立多方通话的权限后，应用服务器向第一用户发送成功建 立多方通话的第二消息。
[0111] 204、应用服务器向第H用户发送第H消息，所述第H消息中包括第二用户的相关 信息，和第一用户成功建立多方通话的消息。
[0112] 205、第H用户接收到第H消息后，将自身的状态变更为"多方通话"。
[0113] 206、应用服务器向第二用户发送第四消息，所述第四消息中包括第H用户的相关 信息，和第一用户成功建立多方通话的消息。
[0114] 207、第二用户将自身的状态变更为"多方通话"，并与第H用户建立媒体通道。
[0115] 208、在第二用户与第H用户建立媒体通道后，结合已经处于通话状态的第一用户 和第H用户，实现多方通话。
[0116] 该里建立的媒体通道分别用于第二用户与第H用户进行通话，使得在该多方通话 中，任意两方之间均有直接的点到点的用于传输音频流和视频流的传输通道，最终使得在 整个多方通话中，每一个用户均有与其他任意用户相连的通道，进一步的，每一个用户均作 为一个WebRTC客户端，在获取到用户自身的至少包括音频流和视频流的媒体流，将该媒体 流于本地进行保存后，将获取到的媒体流可W通过与其他用户相连的媒体通道发送至其他 用户处，从而实现了多方通话。
[0117] 进一步的，每个用户即每一个WebRTC客户端在接收到其他客户端通过对应的媒 体通道传输过来的媒体流时，在用户浏览器的页面上新建多个HTML5的〈Audio〉标签，每个 标签的源Source设置为其中一个客户端的媒体流，该样通过多个〈Audio〉标签就可W同时 播放多个媒体流，也就是在该客户端中可W同时听到多个客户端的声音；对应媒体流中的 视频流的处理方法类似，通过建立多个〈Video〉标签，使得在客户端中可W同时播放多个 客户端的视频图像，通过上述对媒体流进行复用及同时处理多路的媒体流，从而实现多路 通话。
[0118] 在步骤207中，如图5所述，第二用户与第H用户建立媒体通道具体包括：
[0119] 2071、第二用户恢复与第一用户的通话状态，并向应用服务器发送建立媒体通道 的邀请信息，所述邀请信息中包括第二用户的属性参数。
[0120] 2072、应用服务器判断所述邀请消息为多方通话内的呼叫请求，在不触发补充业 务的前提下，将所述邀请信息转发至第H用户 。
[0121] 2073、第H用户根据已确定的"多方通话"的状态，并结合所述邀请消息为多方通 话内的呼叫请求，向应用服务器发送第五消息，所述第五消息包括第H用户的属性参数。
[0122] 2074、应用服务器将第五消息发送至第二用户，成功建立第二用户与第H用户的 媒体通道。
[0123] 由于第H用户已经与第一用户处于通话状态，因此，步骤2072中，应用服务器在 向第H用户转发所述邀请信息前，需要对所述邀请信息的发送方进行判断。
[0124] 在正常的通话方式下，由于第H用户已经处于多方通话的环境中，也就是处于通 话状态，因此，再接收到来自于其他用户的信息后，默认是要向其他用户返回"您所拨打的 用户正在通话中"等类似的占线信息；但是当前由于发送消息的第二用户是处于应用服务 器已经获取到的多方通话成员中的，因此，对于像第二用户该样来自于多方通话成员中的 用户发送的通话请求及通话信息，第H用户会采取会议内会话请求处理方式，即不弹出对 话窗口或者不触发振铃模式，直接自动接收通话。
[01巧]尤其是在第H用户已经将自身状态变更为"多方通话"时，采取上述"静默"处理 的优点在于可W令第H用户更快的进入到已接入多方通话的状态，也就是仅仅是在第H用 户接收到应用处理器发送的第H消息后，针对于由第二用户或其他用户发送的建立媒体通 道的请求，不再进行多余的提示，该样有助于令第H用户尽快的进入多方通话的状态中，避 免第H用户会接收到多次加入多方通话的提示，从而提升第H用户的体验。
[0126] 在上述步骤中，各个用户与会议应用服务器及呼叫应用服务器之间的信息传输， 均需要经过会话管理器SessionManager的转发，该样可W实现消息传输的准确性与及时 性，W免由于会议应用服务器和呼叫服务器由于信息处理不及时导致的信息丢失或延迟。 因为上述步骤众多，信息传输路径复杂，就没有将会话管理器在步骤中的信息转发过程进 行描述，仅是将其功能在该里进行统一描述，但并不代表会话管理器没有参与上述步骤中 的信息传输。
[0127] 本发明实施例提供一种基于WebRTC多方通话建立的方法，通过第一用户向应用 服务器发送建立多方通话的第一消息，应用服务器判断第一用户是否具有建立多方通话的 权限，并在确定第一用户具有建立多方通话的权限后，向第一用户发送成功建立多方通话 的第二消息，同时应用服务器向第H用户和第二用户分别发送第H、第四消息，W便第H用 户和第二用户获取第一用户已经成功建立多方通话的消息并变更自身状态，在第二用户和 第H用户建立媒体通道后，结合已经处于通话状态的第一用户和第H用户，最终实现多方 通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可W无需联系会场服 务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源 的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。
[012引本发明实施例提供一种基于WebRTC多方通话建立的设备1，如图6所示，该设备 具体包括：
[0129] 第一接收单元11，用于接收正在通话的第一用户发送的多方通话建立请求，所述 请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用 户的信息；
[0130] 权限判断单元12,用于判断所述第一用户建立所述多方通话的权限；
[0131] 第一消息发送单元13,用于当所述第一用户具有建立所述多方通话的权限时，向 所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话 的第H用户发送第H扩展消息，所述第H扩展消息中包括参加所述多方通话成员的列表信 息；
[0132] 第一请求发送单元14,用于向所述第二用户发送加入所述多方通话的请求，所述 请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信 息；
[0133] 第一通道建立单元15,用于分别在所述第一用户与所述第二用户间、所述第H用 户与所述第二用户间建立用于多方通话的媒体通道；
[0134] 第一多方通话单元16,用于通过已经建立的所述用于多方通话的媒体通道，进行 所述多方通话。
[0135] 在设备1中，所述多方通话至少包括音频流和视频流的传输。
[0136] 进一步的，所述多方通话至少包括音频流和视频流的传输。
[0137] 当所述多方通话基于会话发起协议（SessionInitiationProtocol,SIP)时，所 述第一扩展消息、所述第二扩展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[013引所述第二用户为至少一个用户终端。
[0139] 本发明实施例提供一种基于WebRTC多方通话建立的设备，该设备接收第一用户 发送的多方通话建立请求，并判断第一用户建立多方通话的权限，当所述第一用户具有建 立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息， 并向与所述第一用户正在通话的第H用户发送第H扩展消息，向所述第二用户发送加入所 述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二 用户发送的确认加入的信息，分别在所述第一用户与所述第二用户间、所述第H用户与所 述第二用户间建立用于多方通话的媒体通道，通过已经建立的所述用于多方通话的媒体通 道，进行所述多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可W 无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时 造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0140] 本发明实施例还提供一种基于WebRTC多方通话建立的装置2,如图7所示，该装 置2包括；总线21 及连接到总线21上的存储器22、处理器23、接收器24和发射器25,其 中存储器22用于存储相关指令，该处理器23执行该指令用于接收正在通话的第一用户发 送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第 一用户建立多方通话的第二用户的信息；该处理器23执行相关指令还用于判断所述第一 用户建立所述多方通话的权限；该处理器23执行相关指令还用于当所述第一用户具有建 立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息， 并向与所述第一用户正在通话的第H用户发送第H扩展消息，所述第H扩展消息中包括参 加所述多方通话成员的列表信息；该处理器23执行相关指令还用于向所述第二用户发送 加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息；该处理器 23执行相关指令还用于接收所述第二用户发送的确认加入的信息；该处理器23执行相关 指令还用于分别在所述第一用户与所述第二用户间、所述第H用户与所述第二用户间建立 用于多方通话的媒体通道；该处理器23执行相关指令还用于通过已经建立的所述用于多 方通话的媒体通道，进行所述多方通话。
[0141] 在本发明实施例中，可选的，该处理器23执行相关指令进行的多方通话至少包括 音频流和视频流的传输。
[0142] 在本发明实施例中，可选的，该处理器23执行相关指令进行的多方通话基于会话 发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩展消 息、所述第H扩展消息为基于所述SIP的扩展消息。
[0143] 在本发明实施例中，可选的，该处理器23执行相关指令进行多方通话中的第二用 户为至少一个用户终端。
[0144] 本发明实施例提供一种基于WebRTC多方通话建立的装置，该设备接收第一用户 发送的多方通话建立请求，并判断第一用户建立多方通话的权限，当所述第一用户具有建 立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息， 并向与所述第一用户正在通话的第H用户发送第H扩展消息，向所述第二用户发送加入所 述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二 用户发送的确认加入的信息，分别在所述第一用户与所述第二用户间、所述第H用户与所 述第二用户间建立用于多方通话的媒体通道，通过已经建立的所述用于多方通话的媒体通 道，进行所述多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可w无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复 成双方通话时 造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0145]本发明实施例提供一种基于WebRTC多方通话建立的系统3,如图8所示，该系统 3至少包括：
[0146]如上述实施例中设备1所示的会议应用服务器，或如上述实施例装置2所述的会 议应用服务器；
[0147]如上述实施例中所示的第一用户。
[0148]本发明实施例提供一种基于WebRTC多方通话建立的系统，通过接收应用服务器 发送的加入多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，在确认 所述多方通话请求的正确性后，向所述应用服务器发送确认加入所述多方通话的信息，建 立与第一用户的用于多方通话的媒体通道，最终通过所述媒体通道进行多方通话；能够降 低由于进行本地混音造成的对设备性能较高的要求，还可W无需联系会场服务器进行繁琐 的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终 减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0149]在本申请所提供的几个实施例中，应该理解到，所掲露的方法，装置，和系统，可W通过其它的方式实现。例如，W上所描述的装置实施例仅仅是示意性的，例如，所述单元的 划分，仅仅为一种逻辑功能划分，实际实现时可W有另外的划分方式，例如多个单元或组件 可W结合或者可W集成到另一个系统，或一些特征可W忽略，或不执行。另一点，所显示或 讨论的相互之间的禪合或直接禪合或通信连接可W是通过一些接口，装置或单元的间接禪 合或通信连接，可W是电性，机械或其它的形式。
[0150]所述作为分离部件说明的单元可W是或者也可W不是物理上分开的，作为单元显 示的部件可W是或者也可W不是物理单元，即可W位于一个地方，或者也可W分布到多个 网络单元上。可W根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目 的。
[0151]另外，在本发明各个实施例中的各功能单元可W集成在一个处理单元中，也可W是各个单元单独物理包括，也可W两个或两个W上单元集成在一个单元中。上述集成的单 元既可W采用硬件的形式实现，也可W采用硬件加软件功能单元的形式实现。
[0152]上述W软件功能单元的形式实现的集成的单元，可W存储在一个计算机可读取存 储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用W使得一台计算机 设备(可W是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的部 分步骤。而前述的存储介质包括；U盘、移动硬盘、只读存储器（ReadHDnlyMemory,简称 ROM)、随机存取存储器（RandomAccessMemo巧，简称RAM)、磁碟或者光盘等各种可W存储 程序代码的介质。
[0153]W上所述，仅为本发明的【具体实施方式】，但本发明的保护范围并不局限于此，任何 熟悉本技术领域的技术人员在本发明掲露的技术范围内，可轻易想到变化或替换，都应涵 盖在本发明的保护范围之内。因此，本发明的保护范围应W所述权利要求的保护范围为准。
【主权项】
1. 一种基于WebRTC多方通话建立的方法，其特征在于，所述方法包括： 接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所 述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息； 判断所述第一用户建立所述多方通话的权限； 当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述 多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息， 所述第三扩展消息中包括参加所述多方通话成员的列表信息； 向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成 员的列表信息； 接收所述第二用户发送的确认加入的信息； 分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多 方通话的媒体通道； 通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。2. 根据权利要求1所述的方法，其特征在于，所述多方通话至少包括音频流和视频流 的传输。3. 根据权利要求1所述的方法，其特征在于，所述方法还包括： 当所述多方通话基于会话发起协议（SessionInitiationProtocol,SIP)时，所述第 一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。4. 一种基于WebRTC多方通话建立的方法，其特征在于，所述方法包括： 向应用服务器发送多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消 息中待建立多方通话的第二用户的消息； 接收所述应用服务器发送的确认建立多方通话的第二扩展消息； 建立与所述第二用户的用于多方通话的媒体通道； 通过所述媒体通道进行多方通话。5. 根据权利要求4所述的方法，其特征在于，所述建立与所述第二用户的用于多方通 话的媒体通道包括： 向所述第二用户发送建立所述媒体通道的邀请信息； 接收所述第二用户发送的回复邀请的信息，建立与所述第二用户的媒体通道。6. 根据权利要求4所述的方法，其特征在于，所述方法包括： 获取本地的媒体流,保存所述本地的媒体流； 将所述本地的媒体流通过与所述第二用户间的媒体通道发送至所述第二用户，从与所 述第二用户间的媒体通道接收所述第二用户的媒体流。7. 根据权利要求4所述的方法，其特征在于，所述方法还包括： 将所述本地的媒体流通过与第三用户间的媒体通道发送至所述第三用户，从与所述第 三用户间的媒体通道接收所述第三用户的媒体流。8. -种基于WebRTC多方通话建立的设备，其特征在于，所述设备包括： 第一接收单元，用于接收正在通话的第一用户发送的多方通话建立请求，所述请求包 括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信 息； 权限判断单元，用于判断所述第一用户建立所述多方通话的权限； 第一消息发送单元，用于当所述第一用户具有建立所述多方通话的权限时，向所述第 一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三 用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息； 第一请求发送单元，用于向所述第二用户发送加入所述多方通话的请求，所述请求中 包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息； 第一通道建立单元，用于分别在所述第一用户与所述第二用户间、所述第三用户与所 述第二用户间建立用于多方通话的媒体通道； 第一多方通话单元，用于通过已经建立的所述用于多方通话的媒体通道，进行所述多 方通话。9. 根据权利要求8所述的设备，其特征在于，所述多方通话至少包括音频流和视频流 的传输。10. 根据权利要求8所述的设备，其特征在于，在所述设备中，当所述多方通话基于会 话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩展消 息、所述第三扩展消息为基于所述SIP的扩展消息。11. 一种基于WebRTC多方通话建立的系统，其特征在于，所述系统至少包括： 如权利要求1至3任意一项所述的会议应用服务器，或如权利要求8至10任意一项所 述的会议应用服务器； 如权利要求4至7任意一项所述的第一用户。
【专利摘要】本发明提供一种基于Web RTC多方通话建立的方法、设备和系统，涉及通信领域，能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。具体通过：第一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话的权限，并向待参加多方通话的用户发送加入多方会议的请求，令第一用户向其他用户发送建立媒体通道的邀请，最终通过建立的媒体通道，并结合媒体流复用以及浏览器内音视频标签的技术，从而实现多方通话。本发明用于实现多方通话。
【IPC分类】H04M3/56, H04L29/06
【公开号】CN104902111
【申请号】CN201410081884
【发明人】徐明远, 胡彬, 陈鑫
【申请人】华为技术有限公司
【公开日】2015年9月9日
【申请日】2014年3月6日
【公告号】WO2015131750A1
【技术领域】
[0001] 本发明涉及通信领域，尤其涉及一种基于WebRTC多方通话建立的方法、设备和系 统。
【背景技术】
[0002] 当前由双方通话变更为多方通话的方法主要通过终端混音模式和会场混音模式 实现，其中前者主要应用与参与人数较少的例如双方通话变更为H方通话的场景，而后者 则应用于较多人数参与的场景。
[0003] 终端混音模式的实现是在业务方A与用户B处于通话保持状态，同时与用户C正 在通话时，通过用户A的终端设备分别将A与B、A与C的媒体流进行混音，接着将混音后的 媒体流再分别发送至用户B和用户C，使得用户B和用户C能够接收到A与C、A与B的图 像和声音，从而间接实现H方通话的效果。
[0004] 会场混音模式的实现是有业务方A与用户B处于通话保持状态，同时与用户C正 在通话时，业务方A首先通过会场服务器（MediaResourceServer,MRS)申请多方会议的 会场资源，接着将A与B、A与C的通话分别通过会话重协商，分别转移到与会场服务器建立 的媒体通道中，最终通过与会场服务器的连接，实现多方通话的效果。
[0005] 虽然上述的终端混音模式和会场混音模式均能实现有双方通话变更为多方通话 的要求，但是前者需要能够进行本地混音的终端设备的支持，并且如果进行的多方通话中 包含视频时，会对混音设备的性能有很高的要求；后者的实现更是需要MRS的支持，否则 无法实现，进一步的，通过会场混音模式实现多方通话每一次都需要申请会场资源，步骤繁 琐，当由多方通话恢复成双方通话时，申请的会场资源也不能及时释放，导致资源浪费。
【发明内容】
[0006] 本发明的实施例提供一种基于WebRTC多方通话建立的方法、设备和系统，能够降 低由于进行本地混音造成的对设备性能较高的要求，还可W无需联系会场服务器进行繁琐 的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终 减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0007] 为达到上述目的，本发明的实施例采用如下技术方案：
[0008] 第一方面，提供一种基于WebRTC多方通话建立的方法，所述方法包括：
[0009] 接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消 息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息；
[0010] 判断所述第一用户建立所述多方通话的权限；
[0011] 当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立 所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第H用户发送第H扩展消 息，所述第H扩展消息中包括参加所述多方通话成员的列表信息；
[0012] 向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通 话成员的列表信息；
[0013] 接收所述第二用户发送的确认加入的信息；
[0014] 分别在所述第一用户与所述第二用户间、所述第H用户与所述第二用户间建立用 于多方通话的媒体通道；
[0015] 通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。
[0016] 在第一种可能的实现方式中，结合第一方面，所述多方通话至少包括音频流和视 频流的传输。
[0017] 在第二种可能的实现方式中，结合第一方面，所述方法还包括：
[0018] 当所述多方通话基于会话发起协议（SessionInitiationProtocol,SIP)时，所 述第一扩展消息、所述第二扩展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[0019] 在第H种可能的实现方式中，结合第一方面，所述第二用户为至少一个用户终端。
[0020] 第二方面，提供一种基于WebRTC多方通话建立的方法，所述方法包括：
[0021] 向应用服务器发送多方通话建立请求，所述请求包括第一扩展消息，所述第一扩 展消息中待建立多方通话的第二用户的消息；
[0022] 接收所述应用服务器发送的确认建立多方通话的第二扩展消息；
[0023] 建立与所述第二用户的用于多方通话的媒体通道；
[0024] 通过所述媒体通道进行多方通话。
[0025] 在第一种可能的实现方式中，结合第二方面，所述建立与所述第二用户的用于多 方通话的媒体通道包括：
[0026]向所述第二用户发送建立所述媒体通道的邀请信息；
[0027]接收所述第二用户发送的回复邀请的信息，建立与所述第二用户的媒体通道。
[0028] 在第二种可能的实现方式中，结合第二方面，所述方法包括：
[0029] 获取本地的媒体流，保存所述本地的媒体流；
[0030] 将所述本地的媒体流通过与所述第二用户间的媒体通道发送至所述第二用户，从 与所述第二用户间的媒体通道接收所述第二用户的媒体流。
[0031] 在第H种可能的实现方式中，结合第二方面，所述方法还包括：
[0032] 将所述本地的媒体流通过与第H用户间的媒体通道发送至所述第H用户，从与所 述第H用户间的媒体通道接收所述第H用户的媒体流。
[0033] 第H方面，提供一种基于WebRTC多方通话的设备，所述设备包括：
[0034] 第一接收单元，用于接收正在通话的第一用户发送的多方通话建立请求，所述请 求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户 的信息；
[00巧]权限判断单元，用于判断所述第一用户建立所述多方通话的权限；
[0036] 第一消息发送单元，用于当所述第一用户具有建立所述多方通话的权限时，向所 述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话 的第H用户发送第H扩展消息，所述第H扩展消息中包括参加所述多方通话成员的列表信 息；
[0037] 第一请求发送单元，用于向所述第二用户发送加入所述多方通话的请求，所述请 求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信 息；
[0038] 第一通道建立单元，用于分别在所述第一用户与所述第二用户间、所述第H用户 与所述第二用户间建立用于多方通话的媒体通道；
[0039] 第一多方通话单元，用于通过已经建立的所述用于多方通话的媒体通道，进行所 述多方通话。
[0040] 在第一种可能的实现方式中，结合第H方面，所述多方通话至少包括音频流和视 频流的传输。
[0041] 在第二种可能的实现方式中，结合第H方面，在所述设备中，当所述多方通话基于 会话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩展 消息、所述第H扩展消息为基于所述SIP的扩展消息。
[0042] 在第H种可能的实现方式中，结合第H方面，所述第二用户为至少一个用户终端。
[0043] 第四方面，提供一种基于WebRTC多方通话建立的系统，所述设备至少包括：
[0044] 如第一方面所示的会议应用服务器，或如第H方面所述的会议应用服务器；
[0045] 如第二方面所示的第一用户。
[0046] 本发明实施例提供一种基于WebRTC多方通话建立的方法、设备和系统，通过第 一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有 建立多方通话的权限，在确定第一用户具有建立多方通话的请求后，向待参加多方通话的 用户发送加入多方会议的请求并附带有该多方通话的成员列表信息，W便于其他用户对是 否加入多方通话进行判断，待其他用户向会议应用服务器发送加入多方会议的信息后，令 第一用户向其他用户发送建立媒体通道的邀请，并在其他用户回复接收建立媒体通道的信 息，从而成功建立第一用户与其他用户的媒体通道。最终通过建立的媒体通道，并结合媒体 流复用W及浏览器内音视频标签的技术，从而实现多方通话；能够降低由于进行本地混音 造成的对设备性能较高的要求，还可W无需联系会场服务器进行繁琐的会场资源申请，进 一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建 立步骤， 提高了通信资源的使用效率。
【附图说明】
[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同时听到多个客户端的声音；对应媒体流中的 视频流的处理方 法类似，通过建立多个〈Video〉标签，使得在客户端中可W同时播放多个 客户端的视频图像，通过上述对媒体流进行复用及同时处理多路的媒体流，从而实现多路 通话。
[008引与步骤101及104中的消息格式类似，会议应用服务器控制待加入的用户接入多 方通话的信息示例性的为：
[0087]
[008引
[0089] 上述信息包括了该消息的序号CHKl、该多方通话的主控制方(也称为该多方通话的 主席）的序号useritW及该多方通话的其他参与者的序号attendee。
[0090] 具体的，W上述消息为例，cmd的值4003为该多方通话的序号，userlD的值为a表 明该多方通话的主控制方(或该多方通话的主席）的序号，attendee的值分别为b、c表明该 多方通话的其他参与者的序号。
[0091] 根据上述描述，如图3所示，建立媒体通道的具体步骤包括：
[0092] 1091、第一用户向第二用户发送建立媒体通道的邀请信息。
[0093] 1092、第二用户接收第一用户发送的建立媒体通道的邀请信息。
[0094] 1093、第二用户判断邀请信息发送方的正确性。
[0095] 该里是第二用户根据事先从应用服务器接收到的参加多方通话成员的列表信息， 判断邀请信息的发送方也就是第一用户的正确性，或者是第一用户是否具有发起多方通话 的权限。
[0096] 1094、第二用户确定邀请信息发送方正确后，向第一用户回复接收邀请的信息，并 建立于第一用户的媒体通道。
[0097] 由于第二用户已经判断过邀请信息发送方也就是第一用户发起多方通话的权限， 因此，第二用户在建立于第一用户的媒体通道后，再接收到来自于第一用户的消息后，采取 有别于正常通话消息的处理方式。
[0098] 在正常的通话方式下，由于第二用户已经处于多方通话的环境中，也就是处于通 话状态，因此，再接收到来自于其他用户的通话请求后，默认是要向其他用户返回"您所拨 打的用户正在通话中"等类似的占线信息；但是当前由于第一用户是处于第二用户事先从 会议应用服务器的多方通话成员的信息列表中的，因此，对于像第一用户该样来自于多方 通话成员的信息列表中的用户发送的通话请求及通话信息，第二用户会采取会议内会话请 求处理方式，即不弹出对话窗口或者不触发振铃模式，直接自动接收通话。
[0099] 尤其是在第二用户与第一用户建立了媒体通道后的第一条通话时，采取上述"静 默"处理的优点在于可W令第二用户更快的进入到已接入多方通话的状态，也就是仅仅是 在第二用户向会议应用处理器返回加入多方通话后，针对于由第一用户或其他用户发送的 建立媒体通道的请求，不再进行多余的提示，该样有助于令第二用户尽快的进入多方通话 的状态中，避免第二用户会接收到多次加入多方通话的提示，从而提升第二用户的体验。
[0100] 至此，第一用户与第二用户之间的信息传输通道已经完全建立完毕，至于之前与 第一用户正在进行双方通话的第H用户，它与第二用户建立媒体通道的方式与上述针对于 第一用户和第二用户建立媒体通道的方法完全一致，并且值得一提的是，该里的第H用户 与第二用户建立媒体通道的时间和第一用户与第二用户建立媒体通道在时间上是同时进 行的，该样可W最大程度上节省建立会议媒体通道的时间，在本实施例中为了表述清晰，故 将二者分开进行描述，并在此进行说明。
[0101] 110、按照步骤1091至1094所示的方法，依次完成第一用户、第H用户与所有待参 加多方通话用户的媒体通道的建立，并通过建立好的媒体通道，进行多方通话。
[0102] 本发明实施例提供一种基于WebRTC多方通话建立的方法，通过第一用户向会议 应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话 的权限，在确定第一用户具有建立多方通话的请求后，向待参加多方通话的用户发送加入 多方会议的请求并附带有该多方通话的成员列表信息，W便于其他用户对是否加入多方通 话进行判断，待其他用户向会议应用服务器发送加入多方会议的信息后，令第一用户向其 他用户发送建立媒体通道的邀请，并在其他用户回复接收建立媒体通道的信息，从而成功 建立第一用户与其他用户的媒体通道。最终通过建立的媒体通道，并结合媒体流复用W及 浏览器内音视频标签的技术，从而实现多方通话；能够降低由于进行本地混音造成的对设 备性能较高的要求，还可W无需联系会场服务器进行繁琐的会场资源申请，进一步节省当 多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提 高了通信资源的使用效率。
[0103] 本发明实施例提供一种基于WebRTC多方通话建立的方法，如图4所示，该方法包 括：
[0104] 本实施例用于将正在通话的两方，变更成H方通话的通话形式。由于使用范围较 小，因此仅作为上一实施例将双方通话变更为多方通话的特例，也作为一种基于WebRTC协 议，实现多方通话方法的补充。
[0105] 在本实施例的起始阶段，第一用户与第二用户处于通话保持状态，同时第一用户 与第H用户处于正在通话中。
[0106] 201、第一用户向应用服务器发送建立多方通话的第一信息。
[0107] 上述多方通话至少包括音频流和视频流的传输。进一步的，当上述多方通话是基 于会话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩 展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[010引具体的，当上述多方通话中的信令协议采用的是SIP协议时，通过重新定义的XML数据格式，扩展SIP协议中的Message消息体，利用SIP协议的路由机制对Message消息进 行路由，进而实现应用服务器与客户端之间的信息交互。
[0109] 202、应用服务器判断第一用户建立多方通话的权限。
[0110] 203、当第一用户具有建立多方通话的权限后，应用服务器向第一用户发送成功建 立多方通话的第二消息。
[0111] 204、应用服务器向第H用户发送第H消息，所述第H消息中包括第二用户的相关 信息，和第一用户成功建立多方通话的消息。
[0112] 205、第H用户接收到第H消息后，将自身的状态变更为"多方通话"。
[0113] 206、应用服务器向第二用户发送第四消息，所述第四消息中包括第H用户的相关 信息，和第一用户成功建立多方通话的消息。
[0114] 207、第二用户将自身的状态变更为"多方通话"，并与第H用户建立媒体通道。
[0115] 208、在第二用户与第H用户建立媒体通道后，结合已经处于通话状态的第一用户 和第H用户，实现多方通话。
[0116] 该里建立的媒体通道分别用于第二用户与第H用户进行通话，使得在该多方通话 中，任意两方之间均有直接的点到点的用于传输音频流和视频流的传输通道，最终使得在 整个多方通话中，每一个用户均有与其他任意用户相连的通道，进一步的，每一个用户均作 为一个WebRTC客户端，在获取到用户自身的至少包括音频流和视频流的媒体流，将该媒体 流于本地进行保存后，将获取到的媒体流可W通过与其他用户相连的媒体通道发送至其他 用户处，从而实现了多方通话。
[0117] 进一步的，每个用户即每一个WebRTC客户端在接收到其他客户端通过对应的媒 体通道传输过来的媒体流时，在用户浏览器的页面上新建多个HTML5的〈Audio〉标签，每个 标签的源Source设置为其中一个客户端的媒体流，该样通过多个〈Audio〉标签就可W同时 播放多个媒体流，也就是在该客户端中可W同时听到多个客户端的声音；对应媒体流中的 视频流的处理方法类似，通过建立多个〈Video〉标签，使得在客户端中可W同时播放多个 客户端的视频图像，通过上述对媒体流进行复用及同时处理多路的媒体流，从而实现多路 通话。
[0118] 在步骤207中，如图5所述，第二用户与第H用户建立媒体通道具体包括：
[0119] 2071、第二用户恢复与第一用户的通话状态，并向应用服务器发送建立媒体通道 的邀请信息，所述邀请信息中包括第二用户的属性参数。
[0120] 2072、应用服务器判断所述邀请消息为多方通话内的呼叫请求，在不触发补充业 务的前提下，将所述邀请信息转发至第H用户 。
[0121] 2073、第H用户根据已确定的"多方通话"的状态，并结合所述邀请消息为多方通 话内的呼叫请求，向应用服务器发送第五消息，所述第五消息包括第H用户的属性参数。
[0122] 2074、应用服务器将第五消息发送至第二用户，成功建立第二用户与第H用户的 媒体通道。
[0123] 由于第H用户已经与第一用户处于通话状态，因此，步骤2072中，应用服务器在 向第H用户转发所述邀请信息前，需要对所述邀请信息的发送方进行判断。
[0124] 在正常的通话方式下，由于第H用户已经处于多方通话的环境中，也就是处于通 话状态，因此，再接收到来自于其他用户的信息后，默认是要向其他用户返回"您所拨打的 用户正在通话中"等类似的占线信息；但是当前由于发送消息的第二用户是处于应用服务 器已经获取到的多方通话成员中的，因此，对于像第二用户该样来自于多方通话成员中的 用户发送的通话请求及通话信息，第H用户会采取会议内会话请求处理方式，即不弹出对 话窗口或者不触发振铃模式，直接自动接收通话。
[01巧]尤其是在第H用户已经将自身状态变更为"多方通话"时，采取上述"静默"处理 的优点在于可W令第H用户更快的进入到已接入多方通话的状态，也就是仅仅是在第H用 户接收到应用处理器发送的第H消息后，针对于由第二用户或其他用户发送的建立媒体通 道的请求，不再进行多余的提示，该样有助于令第H用户尽快的进入多方通话的状态中，避 免第H用户会接收到多次加入多方通话的提示，从而提升第H用户的体验。
[0126] 在上述步骤中，各个用户与会议应用服务器及呼叫应用服务器之间的信息传输， 均需要经过会话管理器SessionManager的转发，该样可W实现消息传输的准确性与及时 性，W免由于会议应用服务器和呼叫服务器由于信息处理不及时导致的信息丢失或延迟。 因为上述步骤众多，信息传输路径复杂，就没有将会话管理器在步骤中的信息转发过程进 行描述，仅是将其功能在该里进行统一描述，但并不代表会话管理器没有参与上述步骤中 的信息传输。
[0127] 本发明实施例提供一种基于WebRTC多方通话建立的方法，通过第一用户向应用 服务器发送建立多方通话的第一消息，应用服务器判断第一用户是否具有建立多方通话的 权限，并在确定第一用户具有建立多方通话的权限后，向第一用户发送成功建立多方通话 的第二消息，同时应用服务器向第H用户和第二用户分别发送第H、第四消息，W便第H用 户和第二用户获取第一用户已经成功建立多方通话的消息并变更自身状态，在第二用户和 第H用户建立媒体通道后，结合已经处于通话状态的第一用户和第H用户，最终实现多方 通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可W无需联系会场服 务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源 的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。
[012引本发明实施例提供一种基于WebRTC多方通话建立的设备1，如图6所示，该设备 具体包括：
[0129] 第一接收单元11，用于接收正在通话的第一用户发送的多方通话建立请求，所述 请求包括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用 户的信息；
[0130] 权限判断单元12,用于判断所述第一用户建立所述多方通话的权限；
[0131] 第一消息发送单元13,用于当所述第一用户具有建立所述多方通话的权限时，向 所述第一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话 的第H用户发送第H扩展消息，所述第H扩展消息中包括参加所述多方通话成员的列表信 息；
[0132] 第一请求发送单元14,用于向所述第二用户发送加入所述多方通话的请求，所述 请求中包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信 息；
[0133] 第一通道建立单元15,用于分别在所述第一用户与所述第二用户间、所述第H用 户与所述第二用户间建立用于多方通话的媒体通道；
[0134] 第一多方通话单元16,用于通过已经建立的所述用于多方通话的媒体通道，进行 所述多方通话。
[0135] 在设备1中，所述多方通话至少包括音频流和视频流的传输。
[0136] 进一步的，所述多方通话至少包括音频流和视频流的传输。
[0137] 当所述多方通话基于会话发起协议（SessionInitiationProtocol,SIP)时，所 述第一扩展消息、所述第二扩展消息、所述第H扩展消息为基于所述SIP的扩展消息。
[013引所述第二用户为至少一个用户终端。
[0139] 本发明实施例提供一种基于WebRTC多方通话建立的设备，该设备接收第一用户 发送的多方通话建立请求，并判断第一用户建立多方通话的权限，当所述第一用户具有建 立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息， 并向与所述第一用户正在通话的第H用户发送第H扩展消息，向所述第二用户发送加入所 述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二 用户发送的确认加入的信息，分别在所述第一用户与所述第二用户间、所述第H用户与所 述第二用户间建立用于多方通话的媒体通道，通过已经建立的所述用于多方通话的媒体通 道，进行所述多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可W 无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时 造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0140] 本发明实施例还提供一种基于WebRTC多方通话建立的装置2,如图7所示，该装 置2包括；总线21 及连接到总线21上的存储器22、处理器23、接收器24和发射器25,其 中存储器22用于存储相关指令，该处理器23执行该指令用于接收正在通话的第一用户发 送的多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消息中有待与所述第 一用户建立多方通话的第二用户的信息；该处理器23执行相关指令还用于判断所述第一 用户建立所述多方通话的权限；该处理器23执行相关指令还用于当所述第一用户具有建 立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息， 并向与所述第一用户正在通话的第H用户发送第H扩展消息，所述第H扩展消息中包括参 加所述多方通话成员的列表信息；该处理器23执行相关指令还用于向所述第二用户发送 加入所述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息；该处理器 23执行相关指令还用于接收所述第二用户发送的确认加入的信息；该处理器23执行相关 指令还用于分别在所述第一用户与所述第二用户间、所述第H用户与所述第二用户间建立 用于多方通话的媒体通道；该处理器23执行相关指令还用于通过已经建立的所述用于多 方通话的媒体通道，进行所述多方通话。
[0141] 在本发明实施例中，可选的，该处理器23执行相关指令进行的多方通话至少包括 音频流和视频流的传输。
[0142] 在本发明实施例中，可选的，该处理器23执行相关指令进行的多方通话基于会话 发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩展消 息、所述第H扩展消息为基于所述SIP的扩展消息。
[0143] 在本发明实施例中，可选的，该处理器23执行相关指令进行多方通话中的第二用 户为至少一个用户终端。
[0144] 本发明实施例提供一种基于WebRTC多方通话建立的装置，该设备接收第一用户 发送的多方通话建立请求，并判断第一用户建立多方通话的权限，当所述第一用户具有建 立所述多方通话的权限时，向所述第一用户发送确认建立所述多方通话的第二扩展消息， 并向与所述第一用户正在通话的第H用户发送第H扩展消息，向所述第二用户发送加入所 述多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，并接收所述第二 用户发送的确认加入的信息，分别在所述第一用户与所述第二用户间、所述第H用户与所 述第二用户间建立用于多方通话的媒体通道，通过已经建立的所述用于多方通话的媒体通 道，进行所述多方通话；能够降低由于进行本地混音造成的对设备性能较高的要求，还可w无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复 成双方通话时 造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0145]本发明实施例提供一种基于WebRTC多方通话建立的系统3,如图8所示，该系统 3至少包括：
[0146]如上述实施例中设备1所示的会议应用服务器，或如上述实施例装置2所述的会 议应用服务器；
[0147]如上述实施例中所示的第一用户。
[0148]本发明实施例提供一种基于WebRTC多方通话建立的系统，通过接收应用服务器 发送的加入多方通话的请求，所述请求中包括参加所述多方通话成员的列表信息，在确认 所述多方通话请求的正确性后，向所述应用服务器发送确认加入所述多方通话的信息，建 立与第一用户的用于多方通话的媒体通道，最终通过所述媒体通道进行多方通话；能够降 低由于进行本地混音造成的对设备性能较高的要求，还可W无需联系会场服务器进行繁琐 的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终 减少了多方通话的建立步骤，提高了通信资源的使用效率。
[0149]在本申请所提供的几个实施例中，应该理解到，所掲露的方法，装置，和系统，可W通过其它的方式实现。例如，W上所描述的装置实施例仅仅是示意性的，例如，所述单元的 划分，仅仅为一种逻辑功能划分，实际实现时可W有另外的划分方式，例如多个单元或组件 可W结合或者可W集成到另一个系统，或一些特征可W忽略，或不执行。另一点，所显示或 讨论的相互之间的禪合或直接禪合或通信连接可W是通过一些接口，装置或单元的间接禪 合或通信连接，可W是电性，机械或其它的形式。
[0150]所述作为分离部件说明的单元可W是或者也可W不是物理上分开的，作为单元显 示的部件可W是或者也可W不是物理单元，即可W位于一个地方，或者也可W分布到多个 网络单元上。可W根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目 的。
[0151]另外，在本发明各个实施例中的各功能单元可W集成在一个处理单元中，也可W是各个单元单独物理包括，也可W两个或两个W上单元集成在一个单元中。上述集成的单 元既可W采用硬件的形式实现，也可W采用硬件加软件功能单元的形式实现。
[0152]上述W软件功能单元的形式实现的集成的单元，可W存储在一个计算机可读取存 储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用W使得一台计算机 设备(可W是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的部 分步骤。而前述的存储介质包括；U盘、移动硬盘、只读存储器（ReadHDnlyMemory,简称 ROM)、随机存取存储器（RandomAccessMemo巧，简称RAM)、磁碟或者光盘等各种可W存储 程序代码的介质。
[0153]W上所述，仅为本发明的【具体实施方式】，但本发明的保护范围并不局限于此，任何 熟悉本技术领域的技术人员在本发明掲露的技术范围内，可轻易想到变化或替换，都应涵 盖在本发明的保护范围之内。因此，本发明的保护范围应W所述权利要求的保护范围为准。
【主权项】
1. 一种基于WebRTC多方通话建立的方法，其特征在于，所述方法包括： 接收正在通话的第一用户发送的多方通话建立请求，所述请求包括第一扩展消息，所 述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信息； 判断所述第一用户建立所述多方通话的权限； 当所述第一用户具有建立所述多方通话的权限时，向所述第一用户发送确认建立所述 多方通话的第二扩展消息，并向与所述第一用户正在通话的第三用户发送第三扩展消息， 所述第三扩展消息中包括参加所述多方通话成员的列表信息； 向所述第二用户发送加入所述多方通话的请求，所述请求中包括参加所述多方通话成 员的列表信息； 接收所述第二用户发送的确认加入的信息； 分别在所述第一用户与所述第二用户间、所述第三用户与所述第二用户间建立用于多 方通话的媒体通道； 通过已经建立的所述用于多方通话的媒体通道，进行所述多方通话。2. 根据权利要求1所述的方法，其特征在于，所述多方通话至少包括音频流和视频流 的传输。3. 根据权利要求1所述的方法，其特征在于，所述方法还包括： 当所述多方通话基于会话发起协议（SessionInitiationProtocol,SIP)时，所述第 一扩展消息、所述第二扩展消息、所述第三扩展消息为基于所述SIP的扩展消息。4. 一种基于WebRTC多方通话建立的方法，其特征在于，所述方法包括： 向应用服务器发送多方通话建立请求，所述请求包括第一扩展消息，所述第一扩展消 息中待建立多方通话的第二用户的消息； 接收所述应用服务器发送的确认建立多方通话的第二扩展消息； 建立与所述第二用户的用于多方通话的媒体通道； 通过所述媒体通道进行多方通话。5. 根据权利要求4所述的方法，其特征在于，所述建立与所述第二用户的用于多方通 话的媒体通道包括： 向所述第二用户发送建立所述媒体通道的邀请信息； 接收所述第二用户发送的回复邀请的信息，建立与所述第二用户的媒体通道。6. 根据权利要求4所述的方法，其特征在于，所述方法包括： 获取本地的媒体流,保存所述本地的媒体流； 将所述本地的媒体流通过与所述第二用户间的媒体通道发送至所述第二用户，从与所 述第二用户间的媒体通道接收所述第二用户的媒体流。7. 根据权利要求4所述的方法，其特征在于，所述方法还包括： 将所述本地的媒体流通过与第三用户间的媒体通道发送至所述第三用户，从与所述第 三用户间的媒体通道接收所述第三用户的媒体流。8. -种基于WebRTC多方通话建立的设备，其特征在于，所述设备包括： 第一接收单元，用于接收正在通话的第一用户发送的多方通话建立请求，所述请求包 括第一扩展消息，所述第一扩展消息中有待与所述第一用户建立多方通话的第二用户的信 息； 权限判断单元，用于判断所述第一用户建立所述多方通话的权限； 第一消息发送单元，用于当所述第一用户具有建立所述多方通话的权限时，向所述第 一用户发送确认建立所述多方通话的第二扩展消息，并向与所述第一用户正在通话的第三 用户发送第三扩展消息，所述第三扩展消息中包括参加所述多方通话成员的列表信息； 第一请求发送单元，用于向所述第二用户发送加入所述多方通话的请求，所述请求中 包括参加所述多方通话成员的列表信息，并接收所述第二用户发送的确认加入的信息； 第一通道建立单元，用于分别在所述第一用户与所述第二用户间、所述第三用户与所 述第二用户间建立用于多方通话的媒体通道； 第一多方通话单元，用于通过已经建立的所述用于多方通话的媒体通道，进行所述多 方通话。9. 根据权利要求8所述的设备，其特征在于，所述多方通话至少包括音频流和视频流 的传输。10. 根据权利要求8所述的设备，其特征在于，在所述设备中，当所述多方通话基于会 话发起协议（SessionInitiationProtocol,SIP)时，所述第一扩展消息、所述第二扩展消 息、所述第三扩展消息为基于所述SIP的扩展消息。11. 一种基于WebRTC多方通话建立的系统，其特征在于，所述系统至少包括： 如权利要求1至3任意一项所述的会议应用服务器，或如权利要求8至10任意一项所 述的会议应用服务器； 如权利要求4至7任意一项所述的第一用户。
【专利摘要】本发明提供一种基于Web RTC多方通话建立的方法、设备和系统，涉及通信领域，能够降低由于进行本地混音造成的对设备性能较高的要求，还可以无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复成双方通话时造成的会场资源的浪费，最终减少了多方通话的建立步骤，提高了通信资源的使用效率。具体通过：第一用户向会议应用服务器发送建立多方通话的请求，会议应用服务器判断第一用户是否有建立多方通话的权限，并向待参加多方通话的用户发送加入多方会议的请求，令第一用户向其他用户发送建立媒体通道的邀请，最终通过建立的媒体通道，并结合媒体流复用以及浏览器内音视频标签的技术，从而实现多方通话。本发明用于实现多方通话。
【IPC分类】H04M3/56, H04L29/06
【公开号】CN104902111
【申请号】CN201410081884
【发明人】徐明远, 胡彬, 陈鑫
【申请人】华为技术有限公司
【公开日】2015年9月9日
【申请日】2014年3月6日
【公告号】WO2015131750A1
最新回复(0)