CN106161179A - 一种基于网页的实时通信的媒体处理方法与装置 - Google Patents

Abstract

一种基于网页的实时通信的媒体处理方法与装置，在多用户实时多媒体通信场景下，降低客户端处理负荷及减少网络带宽消耗。所述方法包括：第一WebRTC终端与第二WebRTC终端建立点对点实时多媒体通信后，应用服务器接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入通信的消息，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接；所述应用服务器控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

Description

一种基于网页的实时通信的媒体处理方法与装置

技术领域

本发明涉及网络实时通信技术，尤其是指一种基于网页的实时通信的媒体处理方法与装置。

背景技术

WebRTC(Web Real-Time Communication，基于网页的实时通信)是Google收购Global IP Solution公司而获得的一项支持网页浏览器进行实时音视频通信的技术。为了促进免插件的Web浏览器实时多媒体通信的发展，Google于2011年将WebRTC技术向公众开源，并联合业界相关厂商成立了W3C WebRTC标准组和IETF RTC-WEB标准组。其中，W3C WebRTC标准组负责制定面向Web开发者的JavaScript API，IETF RTC-WEB标准组则负责制定浏览器内部WebRTC协议栈的音视频编解码、网络传输和NAT(NetworkAddress Translation，网络地址转换)穿越等技术标准。

随着WebRTC标准的持续推进，主流的Chrome、Firefox和Opera等浏览器都将WebRTC功能原生地嵌入到浏览器框架当中。利用这些浏览器提供的JavaScript API，Web开发者可以利用自主选择的信令协议完成“邀约/应答(Offer/Answer)媒体协商过程，进而实现两方或多方之间的音视频通信或其他网页即时通信业务。

WebRTC带给Web开发者最大的好处在于，过去必须由浏览器插件实现的音视频编解码模块、网络传输模块等都集成到浏览器内部，这样就极大地降低了网页即时通信的开发工作量和难度，使得Web开发者有更多的精力投入实时多媒体交互的业务逻辑。正因为这种利好因素，近年来WebRTC原型系统如雨后春笋般涌现，包括电信运营商、互联网厂商都积极开展WebRTC技术的研究和探索。

尽管WebRTC携各种优势在互联网上引起广泛的关注，但同时也应当注意到，任何技术都具有两面性。就WebRTC而言，其媒体交互方案采用了点对点的直传方式就是一个隐形弊端。

在图1所示的简单WebRTC实时通信场景下，多个WebRTC终端位于同一个局域网环境或多个WebRTC终端分别位于不同的非对称型NAT之后的局域网当中。其中，中间的WebRTC终端和非对称型NAT都标注有“1……N”字样，代表1至N个这样的WebRTC终端与非对称型NAT网元对。由图1可知，每一个通信参与方都需要在发送N-1(N为通信参与方总数)路实时媒体流的同时，接收其他N-1方发送的实时媒体流。这样一来，每一个WebRTC终端实际上都需要同时处理((N-1)+(N-1)+1)路媒体流，也即共计2N-1路。其中，“1”表示各个WebRTC终端自己一方的媒体流。图1中，细实线表示信令链路，粗实线表示跨局域网媒体链路，粗虚线表示局域网媒体链路。

在图2所示的中继WebRTC实时通信场景下，其本质上与图1的方式是一致的，同样每个WebRTC终端都需要处理2N-1路媒体流。它们的主要区别在于，这些互相通信的WebRTC终端并不是处于同一个局域网环境当中，而是位于不同的对称型NAT之后的局域网当中，因此所有的媒体流都需要经过中继服务器绕道至其他各方。图1中，细实线表示信令链路，粗实线表示媒体链路。

实践证明，在两方通话或局域网环境下的少数多方会议场景下，WebRTC点对点媒体流直传方式或许还可以勉强应对。然而，随着通信人数的增多，以及面对复杂的Internet环境时，这将不可避免地导致客户端处理负荷过重、用户网络带宽消耗过大和服务质量急剧下降等不良影响，进而最终影响到用户的即时通信体验和业务的发展壮大。

发明内容

本发明要解决的技术问题是提供一种WebRTC的媒体处理方法与装置，在多用户实时多媒体通信场景下，降低客户端处理负荷以及减少网络带宽消耗。

为了解决上述技术问题，本发明提供了一种基于网页的实时通信WebRTC的媒体处理方法，应用服务器执行以下处理：

第一WebRTC终端与第二WebRTC终端建立点对点实时多媒体通信后，所述应用服务器接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入通信的消息，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，并断开所述第一WebRTC终端与第二WebRTC终端之间的点对点媒体连接；

所述应用服务器控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

进一步地，所述媒体处理单元包括媒体服务器；或者，所述媒体处理单元包括媒体网关和多点控制单元。

进一步地，所述媒体处理单元包括媒体服务器；

所述应用服务器分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器之间利用所述媒体协商的结果建立双方之间的媒体通道；或者

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器利用所述媒体协商的结果建立双方之间的经交互式连接建立ICE中继服务器的媒体通道。

进一步地，所述媒体处理单元包括媒体网关和多点控制单元；

所述应用服务器分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道；或者

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道。

进一步地，所述应用服务器分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

在每个WebRTC终端与所述媒体处理单元进行媒体协商的过程中，所述应用服务器将每个WebRTC终端发送给所述媒体处理单元的消息转换为所述媒体处理单元能够识别和处理的消息格式，以及将所述媒体处理单元发送给WebRTC终端的消息转换为所述WebRTC终端能够识别和处理的消息格式。

进一步地，所述应用服务器控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的任一个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流，包括：

所述应用服务器与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

进一步地，所述应用服务器与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，包括：

所述应用服务器向所述媒体处理单元发送创建会议的请求，在接收到所述媒体处理单元返回的会议连接相关的信息后，向所述媒体处理单元发送媒体合成与展示策略信息，以使所述媒体处理单元根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

本发明还提供了一种基于网页的实时通信WebRTC的媒体处理装置，位于应用服务器，所述装置包括第一媒体连接建立模块以及会议建立控制模块，其中：

所述第一媒体连接建立模块，用于在接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入所述第一WebRTC终端与第二WebRTC终端之间已建立的通信的消息后，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，并断开所述第一WebRTC终端与第二WebRTC终端之间的点对点媒体连接；

所述会议建立控制模块，用于控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

进一步地，所述媒体处理单元包括媒体服务器；

所述第一媒体连接建立模块分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器之间利用所述媒体协商的结果建立双方之间的媒体通道；或者

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器利用所述媒体协商的结果建立双方之间的经交互式连接建立ICE中继服务器的媒体通道。

进一步地，所述媒体处理单元包括媒体网关和多点控制单元；

所述第一媒体连接建立模块分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道；或者

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道。

进一步地，所述第一媒体连接建立模块分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

在每个WebRTC终端与所述媒体处理单元进行媒体协商的过程中，所述第一媒体连接建立模块用于将每个WebRTC终端发送给所述媒体处理单元的消息转换为所述媒体处理单元能够识别和处理的消息格式，以及将所述媒体处理单元发送给WebRTC终端的消息转换为所述WebRTC终端能够识别和处理的消息格式。

进一步地，所述会议建立控制模块控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的任一个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流，包括：

所述会议建立控制模块用于与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

进一步地，所述会议建立控制模块与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，包括：

所述会议建立控制模块用于向所述媒体处理单元发送创建会议的请求，在接收到所述媒体处理单元返回的会议连接相关的信息后，向所述媒体处理单元发送媒体合成与展示策略信息，以使所述媒体处理单元根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

为了解决上述技术问题，本发明还提供了一种基于网页的实时通信WebRTC的媒体处理方法，媒体处理单元执行以下处理：

所述媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接；

所述媒体处理单元与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

进一步地，所述媒体处理单元包括媒体服务器；或者，所述媒体处理单元包括媒体网关和多点控制单元。

进一步地，所述媒体处理单元包括媒体服务器；

所述媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间的媒体通道；或者

根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间经交互式连接建立ICE中继服务器的媒体通道。

进一步地，所述媒体处理单元包括媒体网关和多点控制单元；

所述媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，利用媒体协商结果建立所述媒体网关与多个WebRTC终端中每一个WebRTC终端之间的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道；或者

根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，利用媒体协商结果建立多个WebRTC终端中每一个WebRTC终端与所述媒体网关的经所述ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道。

进一步地，所述媒体处理单元与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，包括：

所述媒体处理单元接收所述应用服务器发送的创建会议的请求，向所述媒体处理单元返回会议连接相关的信息，接收所述应用服务器发送的媒体合成与展示策略信息，根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

本发明还提供了一种基于网页的实时通信WebRTC的媒体处理装置，位于媒体处理单元，所述装置包括第二媒体连接建立模块和会议建立及媒体流合成与展示模块，其中：

所述第二媒体连接建立模块，用于根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接；

所述会议建立及媒体流合成与展示模块，用于与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

进一步地，所述媒体处理单元包括媒体服务器；或者，所述媒体处理单元包括媒体网关和多点控制单元。

进一步地，所述媒体处理单元包括媒体服务器；

所述第二媒体连接建立模块根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，并利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间的媒体通道；或者

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，并利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间经交互式连接建立ICE中继服务器的媒体通道。

进一步地，所述媒体处理单元包括媒体网关和多点控制单元；

所述第二媒体连接建立模块根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，并利用媒体协商结果建立所述媒体网关与多个WebRTC终端中每一个WebRTC终端之间的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道；或者

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，并利用媒体协商结果建立多个WebRTC终端中每一个WebRTC终端与所述媒体网关的经所述ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道。

进一步地，所述会议建立及媒体流合成与展示模块与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，包括：

所述会议建立及媒体流合成与展示模块用于接收所述应用服务器发送的创建会议的请求，向所述媒体处理单元返回会议连接相关的信息，接收所述应用服务器发送的媒体合成与展示策略信息，根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

为了解决上述技术问题，本发明还提供了一种基于网页的实时通信WebRTC的媒体处理方法，WebRTC终端执行以下处理：

参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接；

在所述媒体处理单元建立所述多方会议后，所述多方会议中的每个WebRTC终端向所述媒体处理单元发送一路媒体流，以及接收媒体处理单元下发的一路合成后的媒体流。

进一步地，所述方法还包括，作为所述多方会议主持人的WebRTC终端先与一个参与会议的WebRTC终端建立点对点实时多媒体通信，在需要由两方转向多方通信时，向所述应用服务器发送决定将其他一个或多个第三方WebRTC终端加入通信的消息。

进一步地，所述媒体处理单元包括媒体服务器；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的媒体通道；或者

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的经交互式连接建立ICE中继服务器的媒体通道。

进一步地，所述媒体处理单元包括媒体网关和多点控制单元；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的媒体通道；或者

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的经ICE中继服务器的媒体通道。

本发明还提供了一种基于网页的实时通信WebRTC的媒体处理装置，位于WebRTC终端，所述装置包括第三媒体连接建立模块以及媒体收发模块，其中：

所述第三媒体连接建立模块，用于根据应用服务器的协助建立与媒体处理单元的媒体连接；

所述媒体收发模块，用于在所述媒体处理单元建立所述多方会议后，所述多方会议中向所述媒体处理单元发送一路媒体流，以及接收媒体处理单元下发的一路合成后的媒体流。

进一步地，所述装置还包括主持模块，用于在所述WebRTC终端作为所述多方会议主持人时，先与一个参与会议的WebRTC终端建立点对点实时多媒体通信，在需要由两方转向多方通信时向所述应用服务器发送决定将其他一个或多个第三方WebRTC终端加入通信的消息。

进一步地，所述媒体处理单元包括媒体服务器；

所述第三媒体连接建立模块根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的媒体通道；或者

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的经交互式连接建立ICE中继服务器的媒体通道。

进一步地，所述媒体处理单元包括媒体网关和多点控制单元；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的媒体通道；或者

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的经ICE中继服务器的媒体通道。

为了充分利用WebRTC技术的优势并有效规避其不足，本文提出了一种WebRTC自适应媒体处理方法和装置。利用该方法和装置，在两方之间的音视频通话场景下采用WebRTC本身的点对点媒体方案，充分利用WebRTC技术的优势，一旦涉及到多方音视频会议场景，则切换到基于中心节点的媒体处理方案。基于此，可以使业务的用户体验得到优化和提升。

这里需要指出的是，虽然本发明重点阐述的是WebRTC领域由两方的点对点多媒体通信向基于中心节点的多方多媒体通信转换的媒体处理方案，但是显而易见的是，对于该领域当中由多方点对点多媒体通信向基于中心节点的多方多媒体通信转换的媒体处理方案，经由本发明很容易推导出来。为了节省篇幅，本文不再进行WebRTC领域当中多方点对点多媒体通信向基于中心节点的多方媒体通信转换方案的具体展开。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

需要特别指出的是，下面描述中的附图仅作为本发明的部分代表性的实施例。需要说明的是，图9至12中，细实线表示信令链路，粗实线表示媒体链路。图18至25所示的实施例当中只选取了最具有代表性的由两方点对点通信转换成三方会议场景下的核心流程，由此很容易可以推导出由两方点对点通信转换成四方或更多方会议的流程。对于本领域内的普通技术人员而言，在无需付出创造性劳动的前提下，还可以根据这些附图获得其他的相关方案或流程。

图1是WebRTC典型的点对点媒体处理方案图；

图2是WebRTC中继方式下的点对点媒体处理方案图；

图3是本发明实施例一应用服务器执行处理流程图；

图4是本发明实施例一装置结构示意图；

图5是本发明实施例二媒体处理单元执行处理流程图；

图6是本发明实施例二装置结构示意图；

图7是本发明实施例三媒体处理单元执行处理流程图；

图8是本发明实施例三装置结构示意图；

图9是媒体服务器支持WebRTC协议栈的情形下无需媒体中继的多方媒体处理系统架构图；

图10是媒体服务器支持WebRTC协议栈的情形下需要媒体中继的多方媒体处理系统架构图；

图11是多点控制单元不支持WebRTC协议栈的情形下无需媒体中继的多方媒体处理系统架构图；

图12是多点控制单元不支持WebRTC协议栈的情形下需要媒体中继的多方媒体处理系统架构图；

图13是WebRTC终端示意图；

图14是应用服务器(AS)核心模块示意图；

图15是支持WebRTC协议栈的媒体服务器核心模块示意图；

图16是多点控制单元核心模块示意图；

图17是媒体网关核心模块示意图；

图18是本发明应用示例1媒体服务器支持WebRTC协议栈的情形下无需媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图；

图19是本发明应用示例2媒体服务器支持WebRTC协议栈的情形下需要媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图；

图20是本发明应用示例3媒体服务器支持WebRTC协议栈的情形下无需媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图；

图21是本发明应用示例4媒体服务器支持WebRTC协议栈的情形下需要媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图；

图22是本发明应用示例5多点控制单元不支持WebRTC协议栈情形下无需媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图；

图23是本发明应用示例6多点控制单元不支持WebRTC协议栈情形下需要媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图；

图24是本发明应用示例7多点控制单元不支持WebRTC协议栈情形下无需媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图；

图25是本发明应用示例8多点控制单元不支持WebRTC协议栈情形下需要媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。本文所描述的实施例是比较有代表性的一部分实施例，而非完全穷举所有的实施例。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例一

本实施例描述一种基于网页的实时通信WebRTC的媒体处理方法，如图3所示，应用服务器执行以下处理：

步骤1，第一WebRTC终端与第二WebRTC终端建立点对点实时多媒体通信后，应用服务器接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入通信的消息，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，并断开所述第一WebRTC终端与第二WebRTC终端之间的点对点媒体连接；

所述媒体处理单元包括媒体服务器或者包括媒体网关和多点控制单元。所述媒体服务器和多点控制单元的核心功能均包括媒体流合成，为方便描述，设定本文中媒体服务器支持WebRTC协议栈，多点控制单元不支持WebRTC协议栈。

当媒体处理单元包括媒体服务器时，根据是否需要ICE(InteractiveConnectivity Establishment，交互式连接建立)服务器做服务器与各个WebRTC终端之间的媒体中继的情况，可以采用如下之一方式建立媒体连接：

不需要ICE服务器做媒体中继的情况：应用服务器分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器之间利用所述媒体协商的结果建立双方之间的媒体通道；

需要交ICE服务器做媒体中继的情况：应用服务器分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器利用所述媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道。

当媒体处理单元包括媒体网关和多点控制单元时，根据是否需要ICE服务器做媒体网关与各个WebRTC终端之间的媒体中继的情况，可以采用如下之一方式建立媒体连接：

不需要ICE服务器做媒体中继的情况：应用服务器分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道；

需要ICE服务器做媒体中继的情况：应用服务器分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道。

具体地，在每个WebRTC终端与所述媒体处理单元进行媒体协商的过程中，所述应用服务器将每个WebRTC终端发送给所述媒体处理单元的消息转换为所述媒体处理单元能够识别和处理的消息格式，以及将所述媒体处理单元发送给WebRTC终端的消息转换为所述WebRTC终端能够识别和处理的消息格式。

步骤2，所述应用服务器控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

在本步骤中，所述应用服务器与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

具体地，所述应用服务器向所述媒体处理单元发送创建会议的请求，在接收到所述媒体处理单元返回的会议连接相关的信息后，向所述媒体处理单元发送媒体合成与展示策略信息，以使所述媒体处理单元根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

实现上述方法的装置位于应用服务器，如图4所示，包括第一媒体连接建立模块以及会议建立控制模块，其中：

所述第一媒体连接建立模块，用于在接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入所述第一WebRTC终端与第二WebRTC终端之间已建立的通信的消息后，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，并断开所述第一WebRTC终端与第二WebRTC终端之间的点对点媒体连接；

所述会议建立控制模块，用于控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

所述媒体处理单元为媒体服务器：

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器之间利用所述媒体协商的结果建立双方之间的媒体通道；或者

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器利用所述媒体协商的结果建立双方之间的经交互式连接建立ICE中继服务器的媒体通道。

所述媒体处理单元包括媒体网关和多点控制单元：

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道；或者

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道。

在每个WebRTC终端与所述媒体处理单元进行媒体协商的过程中，所述第一媒体连接建立模块用于将每个WebRTC终端发送给所述媒体处理单元的消息转换为所述媒体处理单元能够识别和处理的消息格式，以及将所述媒体处理单元发送给WebRTC终端的消息转换为所述WebRTC终端能够识别和处理的消息格式。

在本实施例中，所述会议建立控制模块用于与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

具体地，所述会议建立控制模块用于向所述媒体处理单元发送创建会议的请求，在接收到所述媒体处理单元返回的会议连接相关的信息后，向所述媒体处理单元发送媒体合成与展示策略信息，以使所述媒体处理单元根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

采用本实施例方法和装置，对用户终端处理能力要求低、带宽消耗小，在多用户实时多媒体通信场景下，提高WebRTC业务的灵活性和竞争力，用户体验好。

实施例二

本实施例描述一种基于网页的实时通信WebRTC的媒体处理方法，如图5所示，媒体处理单元执行以下处理：

步骤1，媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接；

当媒体处理单元包括媒体服务器时，根据是否需要ICE服务器做媒体服务器与各个WebRTC终端之间的媒体中继的情况，可以采用如下之一方式建立媒体连接：

不需要ICE服务器做媒体中继的情况：根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间的媒体通道；

需要ICE服务器做媒体中继的情况：根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间经交互式连接建立ICE中继服务器的媒体通道。

当媒体处理单元包括媒体网关和多点控制单元时，根据是否需要ICE服务器做媒体网关与各个WebRTC终端之间的媒体中继的情况，可以采用如下之一方式建立媒体连接：

不需要ICE服务器做媒体中继的情况：根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，利用媒体协商结果建立所述媒体网关与多个WebRTC终端中每一个WebRTC终端之间的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道；

需要ICE服务器做媒体中继的情况：根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，利用媒体协商结果建立多个WebRTC终端中每一个WebRTC终端与所述媒体网关的经所述ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道。

步骤2，所述媒体处理单元与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

在本步骤中，所述媒体处理单元接收所述应用服务器发送的创建会议的请求，向所述媒体处理单元返回会议连接相关的信息，接收所述应用服务器发送的媒体合成与展示策略信息，根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

实现上述方法的装置位于媒体处理单元，如图6所示，所述装置包括第二媒体连接建立模块和会议建立及媒体流合成与展示模块，其中：

所述第二媒体连接建立模块，用于根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接；

所述会议建立及媒体流合成与展示模块，用于与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

所述媒体处理单元包括媒体服务器：

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，并利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间的媒体通道；或者

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，并利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间经交互式连接建立ICE中继服务器的媒体通道。

所述媒体处理单元包括媒体网关和多点控制单元：

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，并利用媒体协商结果建立所述媒体网关与多个WebRTC终端中每一个WebRTC终端之间的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道；或者

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，并利用媒体协商结果建立多个WebRTC终端中每一个WebRTC终端与所述媒体网关的经所述ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道。

在本实施例中，所述会议建立及媒体流合成与展示模块用于接收所述应用服务器发送的创建会议的请求，向所述媒体处理单元返回会议连接相关的信息，接收所述应用服务器发送的媒体合成与展示策略信息，根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

采用本实施例方法和装置，对用户终端处理能力要求低、带宽消耗小，在多用户实时多媒体通信场景下，提高WebRTC业务的灵活性和竞争力，用户体验好。

实施例三

本实施例描述一种基于网页的实时通信WebRTC的媒体处理方法，如图7所示，WebRTC终端执行以下处理：

步骤1，参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接；

在一个优选实施例中，作为所述多方会议主持人的WebRTC终端先与一个参与会议的WebRTC终端建立点对点实时多媒体通信，在需要由两方转向多方通信时，向所述应用服务器发送决定将其他一个或多个第三方WebRTC终端加入通信的消息。

当媒体处理单元包括媒体服务器时，根据是否需要ICE服务器做服务器与各个WebRTC终端之间的媒体中继的情况，可以采用如下之一方式建立媒体连接：

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的媒体通道；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的经交互式连接建立ICE中继服务器的媒体通道。

当媒体处理单元包括媒体网关和多点控制单元时，根据是否需要ICE服务器做服务器与各个WebRTC终端之间的媒体中继的情况，可以采用如下之一方式建立媒体连接：

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的媒体通道；或者

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的经ICE中继服务器的媒体通道。

应用服务器的协助主要包括：将每个WebRTC终端发送给媒体处理单元的消息转换为媒体处理单元能够识别和处理的消息格式，以及将媒体处理单元发送给WebRTC终端的消息转换为WebRTC终端能够识别和处理的消息格式。

步骤2，在所述媒体处理单元建立所述多方会议后，所述多方会议中的每个WebRTC终端向所述媒体处理单元发送一路媒体流，以及接收媒体处理单元下发的一路合成后的媒体流。

实现上述方法的装置位于WebRTC终端，如图8所示，包括第三媒体连接建立模块以及媒体收发模块，其中：

所述第三媒体连接建立模块，用于根据应用服务器的协助建立与媒体处理单元的媒体连接；

所述媒体收发模块，用于在所述媒体处理单元建立所述多方会议后，所述多方会议中向所述媒体处理单元发送一路媒体流，以及接收媒体处理单元下发的一路合成后的媒体流。

在一个优选实施例中，所述装置还包括主持模块，用于在所述WebRTC终端作为所述多方会议主持人时，先与一个参与会议的WebRTC终端建立点对点实时多媒体通信，在需要由两方转向多方通信时，向所述应用服务器发送决定将其他一个或多个第三方WebRTC终端加入通信的消息。

所述媒体处理单元包括媒体服务器；

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的媒体通道；或者

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的经交互式连接建立ICE中继服务器的媒体通道。

所述媒体处理单元包括媒体网关和多点控制单元；

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的媒体通道；或者

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的经ICE中继服务器的媒体通道。

采用本实施例方法和装置，对用户终端处理能力要求低、带宽消耗小，在多用户实时多媒体通信场景下，提高WebRTC业务的灵活性和竞争力，用户体验好。

下面从物理层面对实现上述方法的多媒体处理系统中的各个网元节点进行说明。

图9所示的是媒体服务器支持WebRTC协议栈的情形下无需媒体中继的多方媒体处理系统架构图。该系统包括多个WebRTC终端、多个非对称型的NAT(Network Address Translation，网络地址转换)、应用服务器(AS)、媒体服务器以及综合了STUN(Simple Traversal of UDP over NATs，NAT的UDP简单穿越)和TURN(Traversal Using Relays around NAT，中继NAT穿透)NAT穿越方案的ICE(Interactive Connectivity Establishment，交互式连接建立)服务器。其中：

WebRTC终端具有图13所示的结构。它包括一个支持WebRTC协议栈及HTML5API的Web浏览器和基于WebRTC、HTML5、JavaScript或JSP(JavaServer Page)等技术开发的Web实时应用程序。

应用服务器(AS)具有图14所示的结构。它包括协议转换模块、业务控制模块、路由分发模块以及Web容器四个主要单元。其中：协议转换模块负责互联网信令(ROAP、JSON等)与SIP信令之间的协议转换工作，以适配WebRTC终端侧与媒体服务器或多点控制单元之间在信令上的差异。业务控制模块负责会话逻辑、会议发起/通知/终止以及媒体展示策略控制等。路由分发模块负责不同WebRTC终端之间、WebRTC终端与媒体网关之间或WebRTC终端与媒体服务器之间的信令路由选择。Web容器提供WebRTC实时通信应用程序的运行环境、Web套接字(WebSocket)以及HTTP(s)长连接等支持。

媒体服务器具有图15所示的结构。它包括SRTP协议栈、VP8编解码器、媒体合成模块、媒体协商与媒体展现控制模块以及ICE代理五个主要单元。其中：SRTP协议栈负责处理WebRTC终端侧发送的SRTP媒体流。VP8编解码器负责将WebRTC终端侧的VP8媒体流解码或将媒体合成模块合成的多方媒体流按照VP8格式编码。媒体合成模块负责将多个WebRTC终端发送的多个实时媒体流进行混音混频处理以获得一个统一的媒体流。媒体协商与媒体展现控制模块负责完成与来自应用服务器的媒体信令的协商以及接收应用服务器(AS)的媒体展示策略并控制媒体合成模块按照既定的策略来处理多个媒体流的合成。ICE代理负责完成媒体服务器与各个WebRTC终端之间的连通性测试，为两者之间建立媒体链路提供依据。

ICE Server提供NAT/防火墙穿透的支持。ICE Server包括两个核心单元，STUN服务器和TURN服务器。其中：STUN服务器用于支持对非对称型NAT的穿透，TURN用于支持对称型NAT以及防火墙的穿透。ICE Server接收WebRTC终端当中ICE代理发出的地址收集请求，并将收集到的WebRTC终端主机地址、WebRTC终端主机对外的公网地址(NAT地址，STUN服务器提供)以及媒体中继地址(TURN服务器提供)返回给WebRTC终端。

在图9中，WebRTC终端各自与ICE Server交互获取本地完整的的媒体面SDP(Session Description Protocol，会话描述协议)信息(包括音视频编解码、媒体加密密钥和算法、ICE候选地址等)，包装成ROAP(RTCWebOffer/Answer Protocol)或JSON(JavaScript Object Notation)等互联网信令格式，经由WebSocket或HTTP(s)长连接等传输通道发送至应用服务器。应用服务器首先会根据上述ROAP或JSON消息辨识是两方通话场景还是多方会议场景。

当应用服务器判定是两方通话场景时，直接将上述ROAP或JSON消息转发给目标WebRTC终端，并将目标WebRTC终端返回的包括目标WebRTC媒体协商信息的ROAP或JSON消息转发给主叫WebRTC终端。之后，WebRTC终端与被叫WebRTC终端之间根据协商的媒体链路进行点对点通信。

当应用服务器判定是多方会议场景时，它首先将ROAP信息或JSON信息转换成媒体服务器能够识别的SIP信息，再将该SIP信息转发给媒体服务器。相应地，媒体服务器根据这些WebRTC终端的媒体面SDP信息(一般地，主动发起协商的一方媒体面SDP信息称之为OFFER)，生成本地支持的协商媒体面SDP信息(一般地，被动接受协商一方的媒体面SDP信息称之为ANSWER)，并经由相反的路径和方式返回给各个WebRTC终端。经过上述完整的协商过程之后，WebRTC终端与媒体服务器就获取到了通信双方都支持的媒体格式、加密方式和密钥以及对端媒体链路的候选地址。WebRTC终端的ICE代理与媒体服务器的ICE代理之间根据上述候选地址进行连通性测试。一旦某一条媒体链路双方都能够联通，则WebRTC终端与媒体服务器之间的媒体链路就建立起来了。当WebRTC终端和媒体服务器之间有多条媒体链路可以连通时，WebRTC终端主机地址的优先级最高、WebRTC终端主机对外的公网地址(即STUN服务器返回的NAT地址)次之，媒体中继地址(即TURN服务器返回的地址)作为最后的连通链路选择。当媒体服务器通过它与各个WebRTC终端之间的媒体链路接收到各个WebRTC终端发送过来的多个媒体流时，会根据应用服务器提交给它的媒体展示控制策略信息对这些媒体流做混音混频等合成处理，并将最终生成的统一一路媒体流回送给各个WebRTC终端。这样，对于每个WebRTC终端而言，都只需要发送一路媒体流给媒体服务器，同时接收媒体服务器回送的一路媒体流，就可以完成多个WebRTC终端之间的相互通信。

图10是媒体服务器支持WebRTC协议栈的情形下需要媒体中继的多方媒体处理系统架构图。图10与图9的基本思想是一致的，系统架构当中的网元及其功能也相同，它们的主要区别在于图10是在WebRTC终端主机地址和WebRTC终端主机对外的公网地址都无法完成与媒体服务器之间媒体链路连通的情形下，不得不选择媒体中继地址来转发所有的媒体流。这种方式下，各个WebRTC终端的媒体流都需要经ICE Server转发给媒体服务器。同样地，由媒体服务器返回的合成媒体流也需要经过ICE Server回送给各个WebRTC终端。

图11是MCU(多点控制单元)不支持WebRTC协议栈的情形下无需媒体中继的多方媒体处理系统架构图。图11与图9主要有两点区别：其一，多点控制单元(MCU)与媒体服务器(MS)处于同一位置，但多点控制单元(MCU)不支持WebRTC协议栈，仅作为媒体流合成和展示控制的网元；其二，在多点控制单元(MCU)的前面，引入了一个媒体网关(MG)网元。

多点控制单元的结构如图16所示。这里需要特别说明的是，图16所示的多点控制单元与图15所示的媒体服务器可以归为同一类网元，它们的核心功能都是媒体合成与展现。只不过为了区别起见，本发明将不支持WebRTC协议栈的媒体合成与展现单元称之为多点控制单元，而将支持WebRTC协议栈的媒体合成与展现单元称之为媒体服务器。由图16可知，多点控制单元包括媒体合成模块和媒体协商与媒体展现控制模块两个核心功能体。其中：媒体合成模块负责将多个WebRTC终端发送的多个实时媒体流进行混音混频处理以获得一个统一的媒体流。媒体协商与媒体展现控制模块负责与来自应用服务器的媒体信令进行协商以及接收应用服务器(AS)的媒体展示策略并控制媒体合成模块按照既定的策略来处理多个媒体流的合成。

媒体网关(MG)的主要功能是对WebRTC终端侧的媒体流与多点控制单元侧的媒体流进行适配。媒体网关的结构如图17所示。由图17可知，媒体网关包括会话管理控制单元、VP8/H.26X转换单元、SRTP/RTP转换单元以及ICE代理四个核心模块。其中，会话管理控制单元负责协调WebRTC终端与多点控制单元之间的媒体协商，并使得WebRTC终端与多点控制单元在媒体层面上彼此透明。VP8/H.26X转换单元负责完成VP8编码与H.26X编码之间的相互转换，以适配WebRTC终端侧和多点控制单元侧的媒体编码差异。SRTP/RTP转换单元负责完成SRTP和RTP之间的相互转换，以适配WebRTC终端侧和多点控制单元侧的媒体传输差异。ICE代理负责完成媒体网关与WebRTC终端之间的连通性测试，以建立两者之间的媒体链路。

在图11中，WebRTC终端各自与ICE Server交互获取本地完整的媒体面SDP(Session Description Protocol)信息(包括音视频编解码、媒体加密密钥和算法、ICE候选地址等，为方便说明不妨记作Offer)，包装成ROAP(RTCWebOffer/Answer Protocol)或JSON(JavaScript Object Notation)等互联网信令格式，经由WebSocket或HTTP(s)长连接等传输通道发送至应用服务器，应用服务器首先会根据上述ROAP或JSON消息辨识是两方通话场景还是多方会议场景。

当应用服务器判定是两方通话场景时，直接将上述ROAP或JSON消息转发给目标WebRTC终端，并将目标WebRTC终端返回的包括目标WebRTC媒体协商信息的ROAP或JSON消息转发给主叫WebRTC终端。之后，主叫WebRTC终端与被叫WebRTC终端之间根据协商的媒体链路进行点对点通信。

当应用服务器判定是多方会议场景时，应用服务器将上述包含Offer信息的ROAP信息或JSON信息转发给媒体网关。媒体网关首先取出上述Offer信息并保存一份副本在本地，然后将原始Offer按照与多点控制单元相适配的方式进行改造进而生成一个全新的媒体协商信息Offer-MG返回给应用服务器。应用服务器将Offer-MG发送给多点控制单元进行媒体协商并返回协商后的媒体信息Answer-MCU给应用服务器，应用服务器将Answer-MCU转发给媒体网关。媒体网关保存一份Answer-MCU副本在本地，然后按照上述Offer进行改造，生成与WebRTC终端相适配的媒体信息Answer-MG返回给应用服务器，应用服务器将Answer-MG返回给WebRTC终端。之后，WebRTC终端按照协商过程中提供的候选媒体连接信息分别与媒体网关进行连通性测试并生成各自媒体链路。当各个WebRTC终端的媒体流到达媒体网关时，媒体网关会进行媒体传输和编解码格式转换，之后再传送给多点控制单元。多点控制单元根据应用服务器提交的媒体控制与展现策略进行多方媒体流的混音混频处理，并将生成的统一媒体流返回给媒体网关，媒体网关再利用它与各个WebRTC终端之间的媒体链路返回给各方。这样，对于每个WebRTC终端而言，都只需要发送一路媒体流给媒体网关，同时接收媒体网关回送的一路媒体流，就可以完成多个WebRTC终端之间的相互通信。

图12是多点控制单元不支持WebRTC协议栈的情形下需要媒体中继的多方媒体处理系统架构图。图12与图11的基本思想是一致的，系统架构当中的网元及其功能也相同。它们的主要区别在于图12是在WebRTC终端主机地址和WebRTC终端主机对外的公网地址都无法完成媒体链路连通的情形下，不得不选择媒体中继地址来转发所有的媒体流。这种方式下，各个WebRTC终端的媒体流都需要经ICE Server转发给媒体网关。同样地，由媒体网关返回的合成媒体流也需要经过ICE Server回送给各个WebRTC终端。

为了更加清晰地阐述上述过程，下面将结合典型的应用示例来详细地说明各个网元之间交互的流程。

应用示例1

图18是媒体服务器支持WebRTC协议栈的情形下无需媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图。所述先呼入是指将第三方WebRTC终端先接入MS，再接入主持人(chair)WebRTC终端。其主要步骤如下：

1)主持人发起与参与者1(Participant1)之间点对点实时多媒体通信

1.1.1)主持人WebRTC终端与ICE Server交互(interaction)，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer(提议)-C；

1.1.2)主持人WebRTC终端将上述媒体面信息Offer-C按照ROAP或JSON格式进行包装，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

1.1.3)应用服务器将利用它与参与者1WebRTC终端之间的WebSocket或HTTP(s)长连接将Offer-C转发给参与者1WebRTC终端；

1.1.4)参与者1WebRTC终端接收Offer-C，并发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息；

1.1.5)参与者1WebRTC终端根据本地媒体面信息和Offer-C，完成双方之间的媒体协商，生成协商后的媒体信息Answer(应答)-P1。然后按照ROAP或JSON格式对Answer-P1进行包装并返回给应用服务器；

1.1.6)应用服务器将Answer-P1返回给主持人WebRTC终端；

1.1.7)主持人WebRTC终端发送一个确认的ROAP或JSON消息OK给应用服务器；

1.1.8)应用服务器将OK消息转发给参与者1WebRTC终端；

1.1.9)主持人WebRTC终端与参与者1WebRTC终端分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试(connectivity check)，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

1.1.10)主持人WebRTC终端与参与者1WebRTC终端利用两者之间优先级最高的媒体链路建立点对点实时多媒体通信。

2)主持人根据需要，决定将参与者2(Participant2)加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

1.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

1.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2(participate 2)标识一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成参与方2WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

1.2.3)应用服务器从上述步骤1.2.2中的invite消息里面提取出参与者2的信息，并组装出一个由参与者2到媒体服务器的SIP INVITE邀请，该邀请的消息体不带任何媒体信息；

1.2.4)媒体服务器根据本地的媒体能力生成自己的媒体面协商信息Offer-MS，并包装在SIP 200OK消息转换返给应用服务器；

1.2.5)应用服务器提取出SIP 200OK当中的Offer-MS，并以ROAP或JSON格式进行包装发送给参与方2WebRTC终端；

1.2.6)参与方2WebRTC终端接收Offer-MS，并发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息；

1.2.7)参与者2WebRTC终端根据本地媒体面信息和Offer-MS，完成双方之间的媒体协商，生成协商后的媒体信息Answer-P2。然后按照ROAP或JSON格式对Answer-P2进行包装并返回给应用服务器；

1.2.8)应用服务器回送一个ROAP或JSON格式的OK确认消息给参与方2WebRTC终端；

1.2.9)应用服务器将包含Answer-P2的ROAP或JSON消息转换成SIPACK消息发送给媒体服务器。其中，Answer-P2作为消息体嵌在SIP ACK消息当中；

1.2.10)参与方2WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

1.2.11)参与方2WebRTC终端与媒体服务器利用两者之间优先级最高的媒体链路建立双方之间的媒体通道。

b)完成主持人WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

1.3.1)应用服务器从上述步骤1.2.2中的invite消息里面提取出主持人WebRTC终端媒体面信息Offer-C，并组装出一个由主持人到媒体服务器的SIPINVITE邀请，该邀请的消息体携带Offer-C媒体信息；

1.3.2)媒体服务器接收上述SIP INVITE消息，然后根据本地的媒体能力以及主持人WebRTC终端的媒体协商信息Offer-C生成的媒体面协商信息Answer-MS，并包装在SIP 200OK消息转换返给应用服务器；

1.3.3)应用服务器提取出SIP 200OK当中的Answer-MS，并以ROAP或JSON格式进行包装发送给主持人WebRTC终端；

1.3.4)主持人WebRTC终端接收Answer-MS，并发送一个确认的ROAP或JSON消息OK给应用服务器；

1.3.5)应用服务器将上述OK消息转换成SIP ACK消息发送给媒体服务器进行确认；

1.3.6)主持人WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

1.3.7)主持人WebRTC终端与媒体服务器利用两者之间优先级最高的媒体链路建立双方之间点对点的媒体通道。

c)完成参与方1WebRTC终端与媒体服务器之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的点对点媒体链路：

1.4.1)应用服务器发送一个更新媒体信息(Info for updating)的ROAP或JSON通知消息给参与方1WebRTC终端；

1.4.2)参与方1WebRTC终端接收到上述通知消息后，发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-P1；

1.4.3)参与方1WebRTC终端将Offer-P1按照ROAP或JSON格式进行包装并发送给应用服务器；

1.4.4)应用服务器提取出Offer-P1，并组装出一个由参与方1WebRTC终端到媒体服务器的SIP INVITE邀请消息，Offer-P1作为该邀请消息的消息体；

1.4.5)媒体服务器根据本地的媒体能力和Offer-P1生成自己的媒体面协商信息Answer-MS，并包装在SIP 200OK消息转换返给应用服务器；

1.4.6)应用服务器提取出SIP 200OK当中的Offer-MS，并以ROAP或JSON格式进行包装发送给参与方1WebRTC终端；

1.4.7)参与方1WebRTC终端接收Answer-MS，并回送一个ROAP或JSON格式的OK确认消息给应用服务器；

1.4.8)应用服务器将该OK消息转换成SIP ACK消息给媒体服务器；

1.4.9)参与方1WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

1.4.10)参与方1WebRTC终端与媒体服务器利用两者之间优先级最高的媒体链路建立双方之间的媒体通道；

1.4.11)参与方1WebRTC终端发送一个ROAP或JSON格式的shut down消息给应用服务器，要求断开(shutdown)参与方1与主持人之间的点对点媒体链路；

1.4.12)应用服务器将该shut down消息转发给主持人WebRTC终端；

1.4.13)主持人回送一个ROAP或JSON格式的确认消息OK给参与方1WebRTC终端，并断开本地相应的媒体链路；

1.4.14)参与方1WebRTC终端收到该OK确认消息后，断开本地相应的媒体链路；

1.4.15)参与方1与主持人之间点对点媒体链路的拆除(Media connectivityremove)。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

1.5.1)应用服务器发送包含会议名称的SIP INFO消息给媒体服务器，提交需要在媒体服务器上创建会议的请求；

1.5.2)媒体服务器按照所述名称创建会议并返回一个200OK消息给应用服务器，该消息中包含会议连接相关的信息(connection msg)作为后续应用服务器提交媒体合成与展示策略的依据；

会议连接相关信息包括会议名称、会议连接信息等。

1.5.3)应用服务器提取出所述会议名称、会议连接信息以及当前参会者信息，组装出所述会议对应的多方媒体合成与展示策略信息，并提交给媒体服务器；

1.5.4)所述媒体服务器按照所述应用服务器提交的媒体合成与展示策略完成所述多方会议的媒体流合成，并利用所述媒体服务器与各个WebRTC终端之间的媒体链路完成合成媒体流的分发。之后，发送200OK的确认给所述应用服务器。

对于参与会议的每个WebRTC终端，只需要向媒体服务器发送一路媒体流即可。

假设参与会议的WebRTC终端有n个，多方媒体合成与展示策略例如可以是设置为媒体服务器将参与会议的n个WebRTC终端的媒体流合成一路，再分别发送给参与会议的每个WebRTC终端，即每个WebRTC终端收到一路媒体流，其中包括n个WebRTC终端的媒体信息；或者设置为媒体服务器将参与会议的n-1个WebRTC终端的媒体流合成一路，发送给被剔除媒体信息的WebRTC终端，即对于WebRTC终端X，其收到一路媒体流，其中包括除自己之外的其他n-1个WebRTC终端的媒体信息。

应用示例2

图19所示的是媒体服务器支持WebRTC协议栈的情形下需要媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图，其主要步骤如下：

1)主持人发起与参与者1之间的实时多媒体通信

2.1.1)至2.1.8)与图18当中的1.1.1)至1.1.8)基本相同，为节省篇幅，这里不再赘述。

2.1.9)主持人WebRTC终端与参与者1WebRTC终端分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

2.1.10)主持人WebRTC终端与参与者1WebRTC终端利用两者之间的ICE中继服务器建立实时多媒体通信。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

2.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

2.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成参与方2WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

2.2.3)至2.2.9)可以参考图18当中的1.2.3)至1.2.9)，这里不再赘述。

2.2.10)参与方2WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

2.2.11)参与方2WebRTC终端与媒体服务器利用两者之间的ICE中继服务器建立双方之间的媒体通道。

b)完成主持人WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

2.3.1)至2.3.5)可以参考图18当中的1.3.1)至1.3.5)，这里不再赘述。

2.3.6)主持人WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

c)主持人WebRTC终端与媒体服务器利用两者之间的ICE中继服务器建立双方之间的媒体通道。

2.4.1)至2.4.8)可以参考图18当中的1.4.1)至1.4.8)，这里不再赘述。

2.4.9)参与方1WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

2.4.10)参与方1WebRTC终端与媒体服务器利用两者之间的ICE中继服务器建立双方之间的媒体通道；

2.4.11)至2.4.15)可以参考图18当中的1.4.11)至1.4.15)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

2.5.1)至2.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

应用示例3

图20是媒体服务器支持WebRTC协议栈的情形下无需媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图。所述后呼入是指先将主持人WebRTC终端接入MS，再接入第三方WebRTC终端。其主要步骤如下：

1)主持人发起与参与者1之间点对点实时多媒体通信

3.1.1)至3.1.10)可以参考图18当中的1.1.1)至1.1.10)，这里不再赘述。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

3.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

3.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成主持人WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

3.2.3)应用服务器从上述步骤3.2.2中的invite消息里面提取出主持人WebRTC终端媒体面信息Offer-C，并组装出一个由主持人到媒体服务器的SIPINVITE邀请，该邀请的消息体携带Offer-C媒体信息；

3.2.4)至3.2.9)可以参考图18当中的1.3.2)至1.3.7)，这里不再赘述。

b)完成参与方2WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

3.3.1)应用服务器从上述步骤3.2.2中的invite消息里面提取出参与者2的信息，并组装出一个ROAP或JSON格式的invite消息给参与者2WebRTC终端，邀请参与者2加入多方通信；

3.3.2)参与者2WebRTC终端发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-P2；

3.3.3)参与方2WebRTC终端将Offer-P2按照ROAP或JSON格式包装后，将其发送给应用服务器；

3.3.4)应用服务器提取出Offer-P2，并组装出一个由参与方2WebRTC终端到媒体服务器的SIP INVITE邀请消息，Offer-P2作为该邀请消息的消息体；

3.3.5)媒体服务器根据本地的媒体能力和Offer-P2生成自己的媒体面协商信息Answer-MS，并包装在SIP 200OK消息转换返给应用服务器；

3.3.6)应用服务器提取出SIP 200OK当中的Offer-MS，并以ROAP或JSON格式进行包装发送给参与方2WebRTC终端；

3.3.7)参与方2WebRTC终端接收Answer-MS，并回送一个ROAP或JSON格式的OK确认消息给应用服务器；

3.3.8)应用服务器将该OK消息转换成SIP ACK消息给媒体服务器；

3.3.9)参与方2WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

3.3.10)参与方1WebRTC终端与媒体服务器利用两者之间优先级最高的媒体链路建立双方之间的媒体通道；

c)完成参与方1WebRTC终端与媒体服务器之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的点对点媒体链路：

3.4.1)至3.4.15)可以参考图18当中的1.4.1)至1.4.15)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

3.5.1)至3.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

应用示例4

图21是媒体服务器支持WebRTC协议栈的情形下需要媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图。其主要步骤如下：

1)主持人发起与参与者1之间点对点实时多媒体通信

4.1.1)至4.1.8)与图18当中的1.1.1)至1.1.8)基本相同，为节省篇幅，这里不再赘述。

4.1.9)主持人WebRTC终端与参与者1WebRTC终端分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

4.1.10)主持人WebRTC终端与参与者1WebRTC终端利用两者之间的ICE中继服务器建立实时多媒体通信。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

4.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

4.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成主持人WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

4.2.3)至4.2.7)可以参考图20当中的3.2.3)至3.2.7)，为节省篇幅，这里不再赘述。

4.2.8)主持人WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

4.2.9)主持人WebRTC终端与媒体服务器利用两者之间的ICE中继服务器建立双方之间点对点的媒体通道。

b)完成参与方2WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

4.3.1)至4.3.8)可以参考图20当中的3.3.1)至3.3.8)，这里不再赘述。

4.3.9)参与方2WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

4.3.10)参与方1WebRTC终端与媒体服务器利用两者之间的ICE中继服务器建立双方之间的媒体通道；

c)完成参与方1WebRTC终端与媒体服务器之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的点对点媒体链路：

4.4.1)至4.4.8)可以参考图20当中的3.4.1)至3.4.8)，这里不再赘述。

4.4.9)参与方1WebRTC终端与媒体服务器分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

4.4.10)参与方1WebRTC终端与媒体服务器利用两者之间的ICE中继服务器建立双方之间的媒体通道；

4.4.11)至4.4.14)可以参考图18当中的1.4.11)至1.4.14)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

4.5.1)至4.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

应用示例5

图22是多点控制单元不支持WebRTC协议栈情形下无需媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图。其主要步骤如下：

1)主持人发起与参与者1之间的实时多媒体通信

5.1.1)至5.1.10)可以参考图18当中的1.1.1)至1.1.10)，这里不再赘述。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

5.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

5.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成参与方2WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

5.2.3)应用服务器从上述步骤5.2.2中invite消息里面提取出参与者2的信息，并组装出一个由参与者2到媒体服务器的SIP INVITE邀请，该邀请的消息体不带任何媒体信息；

5.2.4)多点控制单元根据本地的媒体能力生成自己的媒体面协商信息Offer-MCU，并包装在SIP 200OK消息中返回给应用服务器；

5.2.5)应用服务器提取出SIP 200OK当中的Offer-MCU，并以ROAP或JSON格式进行包装发送给媒体网关；

5.2.6)媒体网关取出ROAP或JSON消息里面的Offer-MCU，首先保存一份Offer-MCU的副本在本地，然后将原始的Offer-MCU当中的音视频编解码信息更改为WebRTC终端能够识别的格式，增加媒体流加密密钥和加密算法信息，将媒体连接地址更改为本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Offer-MG-P2返回给应用服务器；

5.2.7)应用服务器将Offer-MG-P2按照ROAP或JSON格式进行包装，并转发给参与方2WebRTC终端；

5.2.8)参与方2WebRTC终端接收Offer-MG-P2，并发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息；

5.2.9)参与者2WebRTC终端根据本地媒体面信息和Offer-MG-P2，完成参与者2WebRTC终端与媒体网关之间的媒体协商，生成协商后的媒体信息Answer-P2。然后按照ROAP或JSON格式对Answer-P2进行包装并返回给应用服务器；

5.2.10)应用服务器将ROAP或JSON格式的Answer-P2消息转发给媒体网关；

5.2.11)媒体网关取出ROAP或JSON消息里面的Answer-P2，首先保存一份Answer-P2的副本在本地，然后将原始的Answer-P2当中的音视频编解码信息更改为多点控制单元能够识别的格式，删除媒体流加密密钥和加密算法信息，将媒体连接地址更改为本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Answer-P2-MG返回给应用服务器；

5.2.12)应用服务器将包含Answer-P2-MG的ROAP或JSON消息转换成SIP ACK消息发送给多点控制单元。其中，Answer-P2-MG作为消息体嵌在SIP ACK消息当中；

5.2.13)应用服务器发送一个ROAP或JSON格式的OK消息给参与者2WebRTC终端进行确认；

5.2.14)参与方2WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，并按照优先级由高到低的顺序完成参与者2WebRTC终端与媒体网关之间以及多点控制单元与媒体网关之间的媒体建链；

5.2.15)参与方2WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

b)完成主持人WebRTC终端与媒体服务器之间的媒体协商，并建立两者之间的媒体通道：

5.3.1)应用服务器从上述步骤5.2.2中invite消息里面提取出主持人WebRTC终端媒体面信息Offer-C，并以ROAP或JSON格式进行包装发送给媒体网关；

5.3.2)媒体网关取出ROAP或JSON消息里面的Offer-C，首先保存一份Offer-C的副本在本地，然后将原始的Offer-C当中的音视频编解码信息更改为多点控制单元能够识别的格式，删除媒体流加密密钥和加密算法信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Offer-C-MG返回给应用服务器；

5.3.3)应用服务器将Offer-C-MG作为SIP INVITE消息的消息体，发送给多点控制单元；

5.3.4)多点控制单元根据Offer-C-MG以及本地的媒体能力，生成媒体协商信息Answer-MCU-C，并将其封装的SIP 200OK消息当中返回给应用服务器；

5.3.5)应用服务器取出SIP 200OK当中的Answer-MCU-C，以ROAP或JSON格式包装后发送给媒体网关；

5.3.6)媒体网关首先保存一份Answer-MCU-C的副本在本地作为后面与媒体网关通信的依据，然后将原始的Answer-MCU-C当中的音视频编解码信息更改为WebRTC终端能够识别的格式，增加与Offer-C当中媒体流加密密钥和加密算法相适配的信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Answer-MCU-C-MG返回给应用服务器；

5.3.7)应用服务器将Answer-MCU-C-MG以ROAP或JSON格式包装后转发给主持人WebRTC终端；

5.3.8)主持人WebRTC终端发送一个ROAP或JSON格式的OK确认消息给应用服务器；

5.3.9)应用服务器将该OK确认消息转换成SIP ACK消息发送给多点控制单元；

5.3.10)主持人WebRTC终端与媒体网关分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

5.3.11)参与方1WebRTC终端与媒体网关利用两者之间优先级最高的媒体链路建立双方之间的媒体通道，媒体网关与多点控制单元按照协商过程中的媒体连接地址建立双方之间的媒体通道。

c)完成参与方1WebRTC终端与媒体服务器之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的媒体链路：

5.4.1)应用服务器发送一个更新媒体信息的ROAP或JSON通知消息给参与方1WebRTC终端；

5.4.2)参与方1WebRTC终端接收到上述通知消息后，发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-P1；

5.4.3)参与方1WebRTC终端将Offer-P1按照ROAP或JSON格式进行包装并发送给应用服务器；

5.4.4)应用服务器将ROAP或JSON格式的Offer-P1转发给媒体网关；

5.4.5)媒体网关取出ROAP或JSON消息里面的Offer-P1，首先保存一份Offer-P1的副本在本地，然后将原始的Offer-P1当中的音视频编解码信息更改为多点控制单元能够识别的格式，删除媒体流加密密钥和加密算法信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Offer-P1-MG返回给应用服务器；

5.4.6)应用服务器将Offer-P1-MG作为SIP INVITE消息的消息体，发送给多点控制单元；

5.4.7)多点控制单元根据Offer-P1-MG以及本地的媒体能力，生成媒体协商信息Answer-MCU-P1，并将其封装的SIP 200OK消息当中返回给应用服务器；

5.4.8)应用服务器取出SIP 200OK当中的Answer-MCU-P1，以ROAP或JSON格式包装后发送给媒体网关；

5.4.9)媒体网关首先保存一份Answer-MCU-P1的副本在本地作为后面与媒体网关通信的依据，然后将原始的Answer-MCU-P1当中的音视频编解码信息更改为Offer-P1副本相适配的格式，增加与Offer-C当中媒体流加密密钥和加密算法相适配的信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Answer-MCU-P1-MG返回给应用服务器；

5.4.10)应用服务器将Answer-MCU-P1-MG以ROAP或JSON格式包装后转发给参与者1WebRTC终端；

5.4.11)参与者1WebRTC终端发送一个ROAP或JSON格式的OK确认消息给应用服务器；

5.4.12)应用服务器将该OK确认消息转换成SIP ACK消息发送给多点控制单元；

5.4.13)参与者1WebRTC终端与媒体网关分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

5.4.14)参与方1WebRTC终端与媒体网关利用两者之间优先级最高的媒体链路建立双方之间的媒体通道，媒体网关与多点控制单元按照协商过程中的媒体连接地址建立双方之间的媒体通道。

5.4.15)至2.4.19)可以参考图18当中的1.4.11)至1.4.15)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

5.5.1)至5.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

应用示例6

图23是多点控制单元不支持WebRTC协议栈情形下需要媒体中继的先呼入第三方的WebRTC自适应媒体处理核心流程图。其主要步骤如下：

1)主持人发起与参与者1之间的实时多媒体通信

6.1.1)至6.1.8)可以参考图18当中的1.1.1)至1.1.10)，这里不再赘述。

6.1.9)主持人WebRTC终端与参与者1WebRTC终端分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

6.1.10)主持人WebRTC终端与参与者1WebRTC终端利用两者之间的ICE中继服务器建立实时多媒体通信。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

6.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

6.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成参与方2WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

6.2.3)至6.2.13)可以参考图22当中的5.2.3)至5.2.13)，这里不再赘述。

6.2.14)参与方2WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，发现WebRTC终端与媒体网关之间只能通过ICE中继服务器建立媒体链接；

6.2.15)参与方2WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

b)完成主持人WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

6.3.1)至6.3.9)可以参考图22当中的5.3.1)至5.3.9)，这里不再赘述。

6.3.10)主持人WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，发现主持人WebRTC终端与媒体网关之间只能通过ICE中继服务器建立媒体链接；

6.3.11)主持人WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

c)完成参与方1WebRTC终端与多点控制单元之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的媒体链路：

6.4.1)至6.4.12)可以参考图22当中的5.4.1)至5.4.12)，这里不再赘述。

6.4.13)参与方1WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，发现主持人WebRTC终端与媒体网关之间只能通过ICE中继服务器建立媒体链接；

6.4.14)参与方1WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

6.4.15)至6.4.19)可以参考图18当中的1.4.11)至1.4.15)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

6.5.1)至6.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

应用示例7

图24是多点控制单元不支持WebRTC协议栈情形下无需媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图。其主要步骤如下：

1)主持人发起与参与者1之间的实时多媒体通信

7.1.1)至7.1.10)可以参考图18当中的1.1.1)至1.1.10)，这里不再赘述。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

7.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

7.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成主持人WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

7.2.3)应用服务器从上述步骤7.2.2中invite消息里面提取出主持人WebRTC终端媒体面信息Offer-C，并以ROAP或JSON格式进行包装发送给媒体网关；

7.2.4)媒体网关取出ROAP或JSON消息里面的Offer-C，首先保存一份Offer-C的副本在本地，然后将原始的Offer-C当中的音视频编解码信息更改为多点控制单元能够识别的格式，删除媒体流加密密钥和加密算法信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Offer-C-MG返回给应用服务器；

7.2.5)应用服务器将Offer-C-MG作为SIP INVITE消息的消息体，发送给多点控制单元；

7.2.6)多点控制单元根据Offer-C-MG以及本地的媒体能力，生成媒体协商信息Answer-MCU-C，并将其封装的SIP 200OK消息当中返回给应用服务器；

7.2.7)应用服务器取出SIP 200OK当中的Answer-MCU-C，以ROAP或JSON格式包装后发送给媒体网关；

7.2.8)媒体网关首先保存一份Answer-MCU-C的副本在本地作为后面与媒体网关通信的依据，然后将原始的Answer-MCU-C当中的音视频编解码信息更改为WebRTC终端能够识别的格式，增加与Offer-C当中媒体流加密密钥和加密算法相适配的信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Answer-MCU-C-MG返回给应用服务器；

7.2.9)应用服务器将Answer-MCU-C-MG以ROAP或JSON格式包装后转发给主持人WebRTC终端；

7.2.10)主持人WebRTC终端发送一个ROAP或JSON格式的OK确认消息给应用服务器；

7.2.11)应用服务器将该OK确认消息转换成SIP ACK消息发送给多点控制单元；

7.2.12)主持人WebRTC终端与媒体网关分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

7.2.13)参与方1WebRTC终端与多点控制单元利用两者之间优先级最高的媒体链路建立双方之间的媒体通道，媒体网关与多点控制单元按照协商过程中的媒体连接地址建立双方之间的媒体通道。

b)完成参与方2WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

7.3.1)应用服务器从上述主持人提交的invite消息里面提取出参与者2的信息，并组装出一个ROAP或JSON格式的邀请消息给参与者2；

7.3.2)参与者2WebRTC终端收到邀请消息后，发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-P2；

7.3.3)参与方2WebRTC终端将Offer-P2按照ROAP或JSON格式进行包装并发送给应用服务器；

7.3.4)应用服务器将ROAP或JSON格式的Offer-P2转发给媒体网关；

7.3.5)媒体网关取出ROAP或JSON消息里面的Offer-P2，首先保存一份Offer-P2的副本在本地，然后将原始的Offer-P2当中的音视频编解码信息更改为多点控制单元能够识别的格式，删除媒体流加密密钥和加密算法信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Offer-P2-MG返回给应用服务器；

7.3.6)应用服务器将Offer-P2-MG作为SIP INVITE消息的消息体，发送给多点控制单元；

7.3.7)多点控制单元根据Offer-P2-MG以及本地的媒体能力，生成媒体协商信息Answer-MCU-P2，并将其封装的SIP 200OK消息当中返回给应用服务器；

7.3.8)应用服务器取出SIP 200OK当中的Answer-MCU-P2，以ROAP或JSON格式包装后发送给媒体网关；

7.3.9)媒体网关首先保存一份Answer-MCU-P2的副本在本地作为后面与媒体网关通信的依据，然后将原始的Answer-MCU-P2当中的音视频编解码信息更改为Offer-P2副本相适配的格式，增加与Offer-P2当中媒体流加密密钥和加密算法相适配的信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Answer-MCU-P2-MG返回给应用服务器；

7.3.10)应用服务器将Answer-MCU-P2-MG以ROAP或JSON格式包装后转发给参与者2WebRTC终端；

7.3.11)参与者2WebRTC终端发送一个ROAP或JSON格式的OK确认消息给应用服务器；

7.3.12)应用服务器将该OK确认消息转换成SIP ACK消息发送给多点控制单元；

7.3.13)参与者2WebRTC终端与媒体网关分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

7.3.14)参与方2WebRTC终端与多点控制单元利用两者之间优先级最高的媒体链路建立双方之间的媒体通道，媒体网关与多点控制单元按照协商过程中的媒体连接地址建立双方之间的媒体通道。

c)完成参与方1WebRTC终端与媒体服务器之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的点对点媒体链路：

7.4.1)应用服务器发送一个更新媒体信息的ROAP或JSON通知消息给参与方1WebRTC终端；

7.4.2)参与方1WebRTC终端接收到上述通知消息后，发起与ICE Server的交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-P1；

7.4.3)参与方1WebRTC终端将Offer-P1按照ROAP或JSON格式进行包装并发送给应用服务器；

7.4.4)应用服务器将ROAP或JSON格式的Offer-P1转发给媒体网关；

7.4.5)媒体网关取出ROAP或JSON消息里面的Offer-P1，首先保存一份Offer-P1的副本在本地，然后将原始的Offer-P1当中的音视频编解码信息更改为多点控制单元能够识别的格式，删除媒体流加密密钥和加密算法信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Offer-P1-MG返回给应用服务器；

7.4.6)应用服务器将Offer-P1-MG作为SIP INVITE消息的消息体，发送给多点控制单元；

7.4.7)多点控制单元根据Offer-P1-MG以及本地的媒体能力，生成媒体协商信息Answer-MCU-P1，并将其封装的SIP 200OK消息当中返回给应用服务器；

7.4.8)应用服务器取出SIP 200OK当中的Answer-MCU-P1，以ROAP或JSON格式包装后发送给媒体网关；

7.4.9)媒体网关首先保存一份Answer-MCU-P1的副本在本地作为后面与媒体网关通信的依据，然后将原始的Answer-MCU-P1当中的音视频编解码信息更改为Offer-P1副本相适配的格式，增加与Offer-C当中媒体流加密密钥和加密算法相适配的信息，将媒体连接地址更改为媒体网关本地的候选媒体连接地址，进而生成一个全新的媒体协商信息Answer-MCU-P1-MG返回给应用服务器；

7.4.10)应用服务器将Answer-MCU-P1-MG以ROAP或JSON格式包装后转发给参与者1WebRTC终端；

7.4.11)参与者1WebRTC终端发送一个ROAP或JSON格式的OK确认消息给应用服务器；

7.4.12)应用服务器将该OK确认消息转换成SIP ACK消息发送给多点控制单元；

7.4.13)参与者1WebRTC终端与媒体网关分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现有多条候选媒体连接地址可以连通。于是按照候选地址的优先级确定媒体连接的优先级(主机地址优先级最高、主机对外的公网地址优先级次之，媒体中继地址优先级最低)，决定使用主机地址或主机对外的公网地址来完成两端之间的媒体建链；

7.4.14)参与方1WebRTC终端与多点控制单元利用两者之间优先级最高的媒体链路建立双方之间的媒体通道，媒体网关与多点控制单元按照协商过程中的媒体连接地址建立双方之间的媒体通道。

7.4.15)至7.4.19)可以参考图18当中的1.4.11)至1.4.15)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

7.5.1)至7.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

应用示例8

图25是多点控制单元不支持WebRTC协议栈情形下需要媒体中继的后呼入第三方的WebRTC自适应媒体处理核心流程图。其主要步骤如下：

1)主持人发起与参与者1之间的实时多媒体通信

8.1.1)至8.1.8)可以参考图18当中的1.1.1)至1.1.10)，这里不再赘述。

8.1.9)主持人WebRTC终端与参与者1WebRTC终端分别根据媒体协商过程中交换的候选媒体连接地址依次进行连通性测试，发现只有媒体中继地址可以完成两端之间的媒体建链；

8.1.10)主持人WebRTC终端与参与者1WebRTC终端利用两者之间的ICE中继服务器建立实时多媒体通信。

2)主持人根据需要，决定将参与者2加入到讨论当中来。这样，点对点的实时通信过程就演变成了多方会议的场景。其核心流程如下：

8.2.1)主持人WebRTC终端与ICE Server交互，获取本地的音视频编解码、媒体加密算法和密钥以及候选的媒体连接地址等媒体面信息Offer-C；

8.2.2)主持人WebRTC终端将上述媒体面信息Offer-C和被邀请方参与方2一起按照ROAP或JSON格式进行包装生成invite消息，然后利用主持人WebRTC终端与应用服务器之间的WebSocket或HTTP(s)长连接发送给应用服务器；

应用服务器接下来会完成如下几个方面的工作：

a)完成主持人WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

8.2.3)至8.2.11)可以参考图24当中的7.2.3)至7.2.11)，这里不再赘述。

8.2.12)主持人WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，发现WebRTC终端与媒体网关之间只能通过ICE中继服务器建立媒体链接；

6.2.13)主持人WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

b)完成参与方2WebRTC终端与多点控制单元之间的媒体协商，并建立两者之间的媒体通道：

8.3.1)至8.3.12)可以参考图24当中的7.3.1)至7.3.12)，这里不再赘述。

8.3.13)参与方2WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，发现WebRTC终端与媒体网关之间只能通过ICE中继服务器建立媒体链接；

8.3.14)参与方2WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

c)完成参与方1WebRTC终端与多点控制单元之间的媒体协商，建立两者之间的媒体通道，并断开参与方1WebRTC终端与主持人WebRTC终端之间的媒体链路：

8.4.1)至8.4.12)可以参考图24当中的7.4.1)至7.4.12)，这里不再赘述。

8.4.13)参与方1WebRTC终端和多点控制单元分别根据媒体协商过程中交换的候选媒体连接地址依次与媒体网关进行连通性测试，发现WebRTC终端与媒体网关之间只能通过ICE中继服务器建立媒体链接；

8.4.14)参与方1WebRTC终端与多点控制单元利用各自与媒体网关之间的媒体链路建立通信。

8.4.15)至8.4.19)可以参考图18当中的1.4.11)至1.4.15)，这里不再赘述。

这里需要特别指出的是，上述a)、b)和c)之间并无明确的先后顺序关系，在其他实施例中，a)、b)和c)可以任意交换执行次序。

3)应用服务器与媒体服务器交互，完成多方会议在媒体服务器上的创建以及所述多方会议媒体合成与展示策略指定和媒体流合成与分发：

8.5.1)至8.5.4)可以参考图18当中的1.5.1)至1.5.4)，这里不再赘述。

虽然本发明所揭露的实施方式如上，但所述的内容仅为便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (31)

1.一种基于网页的实时通信WebRTC的媒体处理方法，其特征在于，应用服务器执行以下处理：

第一WebRTC终端与第二WebRTC终端建立点对点实时多媒体通信后，所述应用服务器接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入通信的消息，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，并断开所述第一WebRTC终端与第二WebRTC终端之间的点对点媒体连接；

所述应用服务器控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

2.根据权利要求1所述的方法，其特征在于，

所述媒体处理单元包括媒体服务器；或者

所述媒体处理单元包括媒体网关和多点控制单元。

3.根据权利要求2所述的方法，其特征在于，

所述媒体处理单元包括媒体服务器；

所述应用服务器分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器之间利用所述媒体协商的结果建立双方之间的媒体通道；或者

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器利用所述媒体协商的结果建立双方之间的经交互式连接建立ICE中继服务器的媒体通道。

4.根据权利要求2所述的方法，其特征在于，

所述媒体处理单元包括媒体网关和多点控制单元；

所述应用服务器分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道；或者

分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道。

5.根据权利要求1或3或4所述的方法，其特征在于，

所述应用服务器分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

在每个WebRTC终端与所述媒体处理单元进行媒体协商的过程中，所述应用服务器将每个WebRTC终端发送给所述媒体处理单元的消息转换为所述媒体处理单元能够识别和处理的消息格式，以及将所述媒体处理单元发送给WebRTC终端的消息转换为所述WebRTC终端能够识别和处理的消息格式。

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

所述应用服务器控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的任一个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流，包括：

所述应用服务器与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

7.根据权利要求6所述的方法，其特征在于，

所述应用服务器与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，包括：

所述应用服务器向所述媒体处理单元发送创建会议的请求，在接收到所述媒体处理单元返回的会议连接相关的信息后，向所述媒体处理单元发送媒体合成与展示策略信息，以使所述媒体处理单元根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

8.一种基于网页的实时通信WebRTC的媒体处理方法，其特征在于，媒体处理单元执行以下处理：

所述媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接；

所述媒体处理单元与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

9.根据权利要求8所述的方法，其特征在于，

所述媒体处理单元包括媒体服务器；或者

所述媒体处理单元包括媒体网关和多点控制单元。

10.根据权利要求9所述的方法，其特征在于，

所述媒体处理单元包括媒体服务器；

所述媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间的媒体通道；或者

根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间经交互式连接建立ICE中继服务器的媒体通道。

11.根据权利要求9所述的方法，其特征在于，

所述媒体处理单元包括媒体网关和多点控制单元；

所述媒体处理单元根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，利用媒体协商结果建立所述媒体网关与多个WebRTC终端中每一个WebRTC终端之间的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道；或者

根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，利用媒体协商结果建立多个WebRTC终端中每一个WebRTC终端与所述媒体网关的经所述ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道。

12.根据权利要求8所述的方法，其特征在于，

所述媒体处理单元与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，包括：

所述媒体处理单元接收所述应用服务器发送的创建会议的请求，向所述媒体处理单元返回会议连接相关的信息，接收所述应用服务器发送的媒体合成与展示策略信息，根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

13.一种基于网页的实时通信WebRTC的媒体处理方法，其特征在于，WebRTC终端执行以下处理：

参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接；

在所述媒体处理单元建立所述多方会议后，所述多方会议中的每个WebRTC终端向所述媒体处理单元发送一路媒体流，以及接收媒体处理单元下发的一路合成后的媒体流。

14.根据权利要求13所述的方法，其特征在于，

所述方法还包括，作为所述多方会议主持人的WebRTC终端先与一个参与会议的WebRTC终端建立点对点实时多媒体通信，在需要由两方转向多方通信时，向所述应用服务器发送决定将其他一个或多个第三方WebRTC终端加入通信的消息。

15.根据权利要求13所述的方法，其特征在于，

所述媒体处理单元包括媒体服务器；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的媒体通道；或者

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的经交互式连接建立ICE中继服务器的媒体通道。

16.根据权利要求13所述的方法，其特征在于，

所述媒体处理单元包括媒体网关和多点控制单元；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的媒体通道；或者

所述参与多方会议的每个WebRTC终端根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的经ICE中继服务器的媒体通道。

17.一种基于网页的实时通信WebRTC的媒体处理装置，位于应用服务器，其特征在于，所述装置包括第一媒体连接建立模块以及会议建立控制模块，其中：

所述第一媒体连接建立模块，用于在接收到第一WebRTC终端决定将其他一个或多个第三方WebRTC终端加入所述第一WebRTC终端与第二WebRTC终端之间已建立的通信的消息后，分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，并断开所述第一WebRTC终端与第二WebRTC终端之间的点对点媒体连接；

所述会议建立控制模块，用于控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的每个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流。

18.根据权利要求17所述的装置，其特征在于，

所述媒体处理单元包括媒体服务器；

所述第一媒体连接建立模块分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器之间利用所述媒体协商的结果建立双方之间的媒体通道；或者

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体服务器之间的媒体协商，以使得每个WebRTC终端与所述媒体服务器利用所述媒体协商的结果建立双方之间的经交互式连接建立ICE中继服务器的媒体通道。

19.根据权利要求17所述的装置，其特征在于，

所述媒体处理单元包括媒体网关和多点控制单元；

所述第一媒体连接建立模块分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道；或者

所述第一媒体连接建立模块用于分别协助完成第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，以使得每个WebRTC终端与所述媒体网关利用媒体协商的结果建立双方之间的经ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元利用媒体协商的结果建立双方之间的媒体通道。

20.根据权利要求17或18或19所述的装置，其特征在于，

所述第一媒体连接建立模块分别协助建立第一WebRTC终端、第二WebRTC终端、第三方WebRTC终端与媒体处理单元之间的媒体连接，包括：

在每个WebRTC终端与所述媒体处理单元进行媒体协商的过程中，所述第一媒体连接建立模块用于将每个WebRTC终端发送给所述媒体处理单元的消息转换为所述媒体处理单元能够识别和处理的消息格式，以及将所述媒体处理单元发送给WebRTC终端的消息转换为所述WebRTC终端能够识别和处理的消息格式。

21.根据权利要求17所述的装置，其特征包括：

所述会议建立控制模块控制所述媒体处理单元建立第一WebRTC终端、第二WebRTC终端与第三方WebRTC终端的多方会议，以使得所述多方会议中的任一个WebRTC终端只需要发送一路媒体流，接收一路合成后的媒体流，包括：

所述会议建立控制模块用于与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

22.根据权利要求21所述的装置，其特征在于，

所述会议建立控制模块与所述媒体处理单元进行交互，在所述媒体处理单元上创建多方会议，控制所述媒体处理单元进行多方媒体合成与展示，包括：

所述会议建立控制模块用于向所述媒体处理单元发送创建会议的请求，在接收到所述媒体处理单元返回的会议连接相关的信息后，向所述媒体处理单元发送媒体合成与展示策略信息，以使所述媒体处理单元根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用所述媒体处理单元与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

23.一种基于网页的实时通信WebRTC的媒体处理装置，位于媒体处理单元，其特征在于，所述装置包括第二媒体连接建立模块和会议建立及媒体流合成与展示模块，其中：

所述第二媒体连接建立模块，用于根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接；

所述会议建立及媒体流合成与展示模块，用于与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，以使在一个多方会议中，会议中的每个WebRTC终端只需要向所述媒体处理单元发送一路媒体流，以及接收所述媒体处理单元发送的一路合成后的媒体流。

24.根据权利要求23所述的装置，其特征在于，

所述媒体处理单元包括媒体服务器；或者

所述媒体处理单元包括媒体网关和多点控制单元。

25.根据权利要求24所述的装置，其特征在于，

所述媒体处理单元包括媒体服务器；

所述第二媒体连接建立模块根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，并利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间的媒体通道；或者

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成与多个WebRTC终端中每一个WebRTC终端之间的媒体协商，并利用媒体协商结果与多个WebRTC终端中每一个WebRTC终端建立双方之间经交互式连接建立ICE中继服务器的媒体通道。

26.根据权利要求24所述的装置，其特征在于，

所述媒体处理单元包括媒体网关和多点控制单元；

所述第二媒体连接建立模块根据应用服务器的协助，分别建立与多个WebRTC终端中每一个WebRTC终端之间的媒体连接，包括：

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，并利用媒体协商结果建立所述媒体网关与多个WebRTC终端中每一个WebRTC终端之间的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道；或者

所述第二媒体连接建立模块用于根据所述应用服务器的协助，分别完成多个WebRTC终端中每一个WebRTC终端与所述媒体网关之间的媒体协商，以及所述媒体网关与所述多点控制单元之间的媒体协商，并利用媒体协商结果建立多个WebRTC终端中每一个WebRTC终端与所述媒体网关的经所述ICE中继服务器的媒体通道，以及所述媒体网关与所述多点控制单元之间的媒体通道。

27.根据权利要求23所述的装置，其特征在于，

所述会议建立及媒体流合成与展示模块与所述应用服务器进行交互，创建多方会议，进行多方媒体合成与展示，包括：

所述会议建立及媒体流合成与展示模块用于接收所述应用服务器发送的创建会议的请求，向所述媒体处理单元返回会议连接相关的信息，接收所述应用服务器发送的媒体合成与展示策略信息，根据所述媒体合成与展示策略信息完成多方会议的媒体流合成，并利用与多方会议中各WebRTC终端之间的媒体连接完成媒体流分发。

28.一种基于网页的实时通信WebRTC的媒体处理装置，位于WebRTC终端，其特征在于，所述装置包括第三媒体连接建立模块以及媒体收发模块，其中：

所述第三媒体连接建立模块，用于根据应用服务器的协助建立与媒体处理单元的媒体连接；

所述媒体收发模块，用于在所述媒体处理单元建立所述多方会议后，所述多方会议中向所述媒体处理单元发送一路媒体流，以及接收媒体处理单元下发的一路合成后的媒体流。

29.根据权利要求28所述的装置，其特征在于，

所述装置还包括主持模块，用于在所述WebRTC终端作为所述多方会议主持人时，先与一个参与会议的WebRTC终端建立点对点实时多媒体通信，在需要由两方转向多方通信时，向所述应用服务器发送决定将其他一个或多个第三方WebRTC终端加入通信的消息。

30.根据权利要求28所述的装置，其特征在于，

所述媒体处理单元包括媒体服务器；

所述第三媒体连接建立模块根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的媒体通道；或者

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体服务器之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体服务器双方之间的经交互式连接建立ICE中继服务器的媒体通道。

31.根据权利要求28所述的装置，其特征在于，

所述媒体处理单元包括媒体网关和多点控制单元；

所述参与多方会议的每个WebRTC终端根据应用服务器的协助建立与媒体处理单元的媒体连接，包括：

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的媒体通道；或者

所述第三媒体连接建立模块根据应用服务器的协助完成与所述媒体网关之间的媒体协商，利用所述媒体协商的结果建立本WebRTC终端与所述媒体网关双方之间的经ICE中继服务器的媒体通道。