。
[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无需联系会场服务器进行繁琐的会场资源申请，进一步节省当多方通话恢复