CN117896352A - 一种基于SIP协议的WebRTC媒体流网关系统、容灾方法 - Google Patents

Abstract

本发明提供了一种基于SIP协议的WebRTC媒体流网关系统、容灾方法，通过监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；根据第一媒体服务器信息重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。相比于现有技术，在WebRTC媒体流网关发生容灾，不需要媒体流服务内部做任何处理，使得WebRTC媒体流网关节点异常后导致此节点上提供服务的所有Web浏览器通话仍然可以继续进行使用。

Description

一种基于SIP协议的WebRTC媒体流网关系统、容灾方法

技术领域

本发明涉及网关通信技术领域，具体而言，涉及一种基于SIP协议的WebRTC媒体流网关系统、容灾方法。

背景技术

WebRTC(Web Real-Time Communications)网关系统是由多个信令服务及多个媒体流服务组成一个整体对外提供高并发的服务。它是连接浏览器与公共交换电话网络(Public Switch Telephone Network，PSTN)的网元，它可以允许通过Web浏览器拨打或接听来自PSTN的呼叫。WebRTC网络安全性体现在网络套接字安全(Web Socket Secure，WSS)，安全实时传输协议(Secure Real-Time Protocol，SRTP)。通过WebRTC接入到传统PSTN，让PSTN电话应用更安全更广泛。

现有技术中的媒体流网关负责媒体流传输及音频数据处理，通过多个相同的节点为成千上万的终端或设备提供媒体流服务，一旦发生异常或者需要维护升级，将造成大面积的网络呼叫无声音或会话无法建立等异常。传统的容灾方案会采用高可用(HA，HighAvailable)+远程字典服务(Remote Dictionary Server，Redis)集群方案，节点之间共享，以确保实时传输协议(Real-time Transport Protocol，RTP)在需要时正确故障转移及对Redis集群的监控维护，而这样的方案部署复杂且可利用率很低，且WebRTC媒体流网关节点异常后导致此节点上提供服务的所有Web浏览器通话无法正常使用。

发明内容

有鉴于此，本发明的目的在于提供通过对媒体流网关容灾处理以解决目前使用WebRTC媒体流网关节点异常后导致此节点上提供服务的所有Web浏览器通话仍然可以继续进行使用。

本发明的第一方面提供了一种基于SIP协议的WebRTC媒体流网关系统，所述WebRTC媒体流网关系统包括信令服务器集群、媒体流服务器集群以及异常监测服务器，所述信令服务器集群包括多个SIP服务器；其中：

信令服务器，用于在通话建立时保存会话标识及所用媒体流节点信息，当会话建立时，信令服务器指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；

异常监测服务器，用于监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；

媒体流服务器，用于与异常监测服务器保持连接，并按照预定周期上传当前的工作状态至异常监测服务器；

所述信令服务器，还用于接收到第一媒体服务器信息，并重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

进一步，所述第一媒体服务器信息包括第一媒体服务器IP、端口及状态信息；

所述信令服务器，还用于启动当前本端的媒体流服务，将本端的媒体流服务信息写入至本端的会话描述协议SDP，构成第一SDP请求，发送至远端；所述本端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

远端接收所述第一SDP请求，进行解析并回复应答消息；其中所述应答消息包括远端的媒体流服务信息；所述远端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

所述信令服务器根据所述媒体信息执行SDP协商，SDP协商完成后，开始媒体流数据传输。

进一步，所述异常监测服务器，还用于确定预定的时间内没收到第一媒体流服务器的工作状态信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；

或者，接收第一媒体流服务器发送的维护信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息。

进一步，所述异常监测服务器，还用于向所有的信令服务器的UDP监听端口发送所述第一媒体服务器信息；所述信令服务器收到所述第一媒体服务器信息后，向所述异常监测服务器发送响应指令；并基于所述响应指令发送分配请求至信令服务器；

所述信令服务器，还用于基于所述分配请求，根据负载均衡策略确定第二媒体流服务器，并确定所述第二媒体流服务器IP以及端口信息；根据所述第二媒体流服务器IP以及端口信息重写本端的会话描述协议SDP，并生成第二SDP请求发送至远端。

进一步，所述实现与远端的SDP进行重新协商，重新建立媒体流通道，包括：

远端接收到所述第二SDP请求，将其媒体层信息放入所述SDP中，并回复确认指令至所述信令服务器，实现SDP协商完成，并基于第二媒体流服务器实现媒体流数据传输。

此外，本发明还提出一种基于SIP协议的WebRTC媒体流网关容灾方法，所述方法包括：

在本端、远端建立通话时，保存会话标识及所用媒体流节点信息，指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；

监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；

根据第一媒体服务器信息重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

进一步，所述第一媒体服务器信息包括第一媒体服务器IP、端口及状态信息；

所述指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道，包括：

启动当前本端的媒体流服务，将本端的媒体流服务信息写入至本端的会话描述协议SDP，构成第一SDP请求，发送至远端；所述本端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

远端接收所述第一SDP请求，进行解析并回复应答消息；其中所述应答消息包括远端的媒体流服务信息；所述远端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

所述信令服务器根据所述媒体信息执行SDP协商，SDP协商完成后，开始媒体流数据传输。

进一步，所述当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，包括：

确定预定的时间内没收到第一媒体流服务器的工作状态信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；

或者，接收第一媒体流服务器发送的维护信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息。

进一步，所述方法还包括：

所述异常监测服务器向所有的信令服务器的UDP监听端口发送所述第一媒体服务器信息；所述信令服务器收到所述第一媒体服务器信息后，向所述异常监测服务器发送响应指令；并基于所述响应指令发送分配请求至信令服务器；

信令服务器基于所述分配请求，根据负载均衡策略确定第二媒体流服务器，并确定所述第二媒体流服务器IP以及端口信息；根据所述第二媒体流服务器IP以及端口信息重写本端的会话描述协议SDP，并生成第二SDP请求发送至远端。

进一步，所述实现与远端的SDP进行重新协商，重新建立媒体流通道，包括：

远端接收到所述第二SDP请求，将其媒体层信息放入所述SDP中，并回复确认指令至所述信令服务器，实现SDP协商完成，并基于第二媒体流服务器实现媒体流数据传输。

本发明的方案中，通过在本端、远端建立通话时，保存会话标识及所用媒体流节点信息，指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；根据第一媒体服务器信息重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。相比于现有技术，在WebRTC媒体流网关发生容灾，不需要媒体流服务内部做任何处理，媒体流服务器只用专注于自身的媒体流工作，由SIP信令层负责对异常媒体流服务器节点进行切换到正常的媒体流服务器节点，使得WebRTC媒体流网关节点异常后导致此节点上提供服务的所有Web浏览器通话仍然可以继续进行使用，方便部署，高效利用媒体流服务节点，且易于维护及对媒体流服务的负载均衡控制。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本发明现有技术的WebRTC网关系统结构示意图；

图2是本发明实施例1公开的基于SIP协议的WebRTC媒体流网关系统的结构示意图；

图3是本发明实施例1公开的系统实现容灾控制的流程图；

图4是本发明实施例2公开的基于SIP协议的WebRTC媒体流网关容灾方法。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是：在本文中提及的“多个”是指两个或两个以上。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

如图1所示为现有技术的WebRTC网关系统结构示意图。其中，WebRTC网关系统连接浏览器与公共交换电话网络PSTN的网元。其中，Web浏览器与WebRTC网关系统连接，Web浏览器的会话初始协议SIP(Session initialization Protocol)栈可以通过基于SIP协议经由WSS与WebRTC网关系统的信令服务层连接交互。WebRTC网关系统的信令服务层基于SIP协议经由用户数据报协议UDP(User Datagram Protocol)与VOIP(Voice over InternetProtocol)平台进行连接。Web浏览器的WebRTC则与WebRTC网关系统的媒体流服务层之间可以通过安全实时传输协议SRTP(Secure Real-time Transport Protocol)进行交互。WebRTC网关系统的媒体流服务层与VOIP平台之间则基于实时传输协议RTP(Real-timeTransport Protocol)协议进行交互。

进一步，现有技术WebRTC网关系统的信令层(传输协议转换)：WSS(Web SocketSecure网络套接字安全)<-->UDP(User Datagram Protocol，用户数据报协议)。媒体层(加解密转换)：SRTP(Secure RTP，加密实时传输协议)<-->RTP(Real-time TransportProtocol，实时传输协议)。现有技术的单个网关节点支持终端的接入量有限，无法支持高并发应用；一旦网关节点宕机，当前所有进行中的通话均会中断，通话记录也无法正常完成，当前业务全受到影响；无法根据实际需求(应用节点压力情况)进行增减节点(转码时要增加媒体服务节点，服务空闲时减少信令服务节点)，现有的技术如果是单纯增加节点不能实现高并发或者达到性能的最大化。

如图2所示为本发明实施例的一种基于SIP协议的WebRTC媒体流网关系统的结构示意图。如图2所示，WebRTC媒体流网关系统包括webrtc媒体流网关、webrtc信令网关以及异常检测服务。其中，webrtc媒体流网关即基于媒体流服务器集群来实现，webrtc信令网关基于信令服务器集群来实现，异常检测服务基于一异常监测服务器来实现即可。所述信令服务器集群包括多个SIP服务器。

信令服务器集群，由多个相同的SIP服务器按照一定的规则方案组成的集群，它以SIP信令为基础，这是外部节点或设备接入的入口，对内管理及调用媒体流服务节点。

媒体流服务器集群，由多个相同的媒体流服务器组成，主要提供媒体流转发服务，对于Web网页，提供加密的媒体流(SRTP)，PSTN侧提供明文数据流(RTP)。

异常监测服务器，用于实时检测媒体流服务状态，检测到异常后，立即通知信令服务做媒体流切换。

本实施例，通过SIP信令级别的媒体故障转移即媒体流重新锚定(re-anchoring)，将当前的故障媒体流节点切换到其它指定的可用媒体流结点。它并不依赖于媒体流服务内部的任何容灾实现。

本实施例，信令服务器，用于在通话建立时保存会话标识及所用媒体流节点信息，当会话建立时，信令服务器指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道。

进一步，信令服务器，还用于启动当前本端的媒体流服务，将本端的媒体流服务信息写入至本端的会话描述协议SDP，构成第一SDP请求，发送至远端；所述本端的媒体流服务信息包括ICE(Interactive Connectivity Establishment，交互式连接建立)信息、IP、端口以及媒体编码器信息。

远端接收所述第一SDP请求，进行解析并回复应答消息；其中所述应答消息包括远端的媒体流服务信息；所述远端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

信令服务器根据所述媒体信息执行SDP协商，SDP协商完成后，开始媒体流数据传输。

信令服务指定具体媒体流服务给当前的会话，信令服务会启动当前媒体流服务(如媒体流服务的端口监听)，将媒体流服务信息(如IP，端口)放入本端SDP，构成Invite消息(即请求消息)，发给远端。

远端接听电话，会回复200OK(即Answer)消息，SDP里会携带自己的媒体信息，此时，信令服务需要将此媒体信息传给本地offer里已分配的媒体流服务，开始媒体层协商(比如ICE协商，媒体属性协商等等)，SDP协商完成后，开始媒体流数据传输。

本实施例，协商时，先进行媒体codec的协商，确保本端、远端的使用同一套编解码器，比如都是H.264编解码或者都是H.265编解码。然后是媒体通道的协商，对于WebRTC侧，是ICE协商(不同的socket连接里都带ICE字段里的用户名/密码，最终确立一个最佳的socket通道)；对于非WebRTC侧(即传统的PSTN)，直接发给对端SDP的m行信息(即IP，端口port)。

具体地，本实施例，信令服务器在通话建立时保存会话呼叫的唯一标识call-id及所用媒体流服务器节点等信息，当会话建立时信令服务器会指定分配一个媒体服务节点放在本端会话描述协议(SDP，Session Description Protocol)里，与远端的SDP进行协商，建立会话。Call-id能唯一标识当前的会话，通过它可找到当前的通话，所有通话中的会话全保存在本地信令服务的内存里。

异常监测服务器，用于监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器。

进一步，异常监测服务器，还用于确定预定的时间内没收到第一媒体流服务器的工作状态信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；或者，接收第一媒体流服务器发送的维护信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；第一媒体服务器信息包括第一媒体服务器IP、端口及状态信息。

具体地，本实施例，异常监测服务器向信令服务器的UDP监听端口发异常媒体流服务信息，不断重发，直到收到信令服务响应为止。信令服务收到此请求后，会按负载均衡策略分配一个新的可用媒体流服务节点。

其中，异常监测服务器的监测服务用于发现工作状态异常的媒体服务器，各个媒体流服务节点主动与监测程序保持连接，各个媒体服务器需要定期汇报当前的工作状态。一旦监测服务检测到异常，监测服务记录下异常的媒体服务器IP及状态信息等。

需要说明的是，异常监测服务规定的时间内没收到媒体流的状态通知，确认此媒体流服务节点异常，异常监测服务记录下此媒体流服务异常状态信息。

可以替代的是，在本需要对某个媒体流服务器节点维护时，习惯用命令行来操作，本信令服务支持命令行操作，在信令服务侧输入：异常的媒体流服务节点+指定的新增媒体流服务节点(可选)。通过先启动一个节点来接替当前节点的工作，即新增一个媒体流服务节点，如果当前媒体流服务压力小，可以直接通过其它的现有运行的媒体流服务来分担。

无论是规定的时间内没收到媒体流的状态通知的媒体服务器节点，或者是某个需要媒体流服务器节点，都视为异常，需要来进行记录下对应的媒体服务器IP及状态信息，从而便于切换一个新的媒体流服务器节点来接替相关工作。当前异常媒体流服务节点上的通话已经成功切换到其它媒体服务上。当前的异常节点可以停止服务。

其中，对于某个媒体流服务器节点维护的情况，待维护完成后，该维护的媒体流服务器节点可向异常监测服务器继续按照预定周期发送器状态信息。

异常监测服务器，还用于向所有的信令服务器的UDP监听端口发送所述第一媒体服务器信息；所述信令服务器收到所述第一媒体服务器信息后，向所述异常监测服务器发送响应指令；并基于响应指令发送分配请求至信令服务器。

进一步，异常监测服务器将异常节点通知所有信令服务器，监测程序主动与各个信令服务器保持连接，将记录的异常媒体流服务信息推向信令服务。

媒体流服务器，用于与异常监测服务器保持连接，并按照预定周期上传当前的工作状态至异常监测服务器。

信令服务器，还用于接收到第一媒体服务器信息，并重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

具体地，信令服务器还用于基于所述分配请求，根据负载均衡策略确定第二媒体流服务器，并确定所述第二媒体流服务器IP以及端口信息；根据所述第二媒体流服务器IP以及端口信息重写本端的会话描述协议SDP，并生成第二SDP请求发送至远端。

具体地，当前的信令服务节点，会在隶属于本信令服务节点的所有正在进行的通话，找到当前使用了异常的媒体服务器节点1的会话，用媒体流服务器节点2(上述分配的可用媒体流服务节点)的IP、端口，来重写原来的本端SDP，并启动媒体流服务节点2，构成Re-Invite消息发给远端。

其中，用媒体流服务器节点2(上述分配的可用媒体流服务节点)的IP、端口，来重写原来的本端SDP后，放入SIP协议中的修改会话(Re-Invite)的本端SDP里，与远端的SDP重新协商，重新建立媒体流通道。

进一步，远端接收到所述第二SDP请求，将远端自身的媒体层信息放入SDP里，回复200OK(即answer)。媒体层重新启动协商，SDP协商完成后，开始新媒体流数据传输。

为了进一步更清楚的描述本实施例的基于SIP协议的WebRTC媒体流网关系统，在媒体流服务节点宕机或者异常不可用时，实现容灾的控制方法，如图3所述为本实施例的系统实现容灾控制的流程图。

1.发起会话(媒体流节点1)。具体地，信令服务指定具体媒体流服务给当前的会话，信令服务会启动当前媒体流服务(如媒体流服务的端口监听)，将媒体流服务信息(如IP,端口)放入本端SDP，构成Invite消息(即offer)，发给远端。

2.对方接听。具体地，远端接听电话，会回复200OK(即Answer)消息，SDP里会携带自己的媒体信息，此时，信令服务需要将此媒体信息传给本地offer里已分配的媒体流服务，开始媒体层协商(比如ICE协商，媒体属性协商等等)，SDP协商完成后，开始媒体流数据传输。

3.检测到异常。具体地，异常监测服务规定的时间内没收到媒体流的状态通知，确认此媒体流服务节点异常，异常监测服务记录下此媒体流服务异常状态信息；

4.程序调用。具体地，异常监测服务向信令服务的UDP监听端口发异常媒体流服务信息，不断重发，直到收到信令服务响应为止。信令服务收到此请求后，会按负载均衡策略分配一个新的可用媒体流服务节点。

5.Re-Invite(媒体流节点2)。具体地，当前的信令服务节点，会在隶属于本信令服务节点的所有正在进行的通话，找到当前使用了此异常的媒体服务节点的会话，用媒体流服务节点2(上一步里分配的可用媒体流服务节点)的IP，端口重写原来的本端SDP，并启动媒体流服务节点2，构成Re-Invite消息发给远端。

6.200OK。具体地，远端接受新的SDP请求(即offer),它将自己的媒体层信息放入SDP里，回复200OK(即answer)。媒体层重新启动协商，SDP协商完成后，开始新媒体流数据传输。

综上，本实施例，通过在本端、远端建立通话时，保存会话标识及所用媒体流节点信息，指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；根据第一媒体服务器信息重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

相比于现有技术，在WebRTC媒体流网关发生容灾，不需要媒体流服务内部做任何处理，媒体流服务器只用专注于自身的媒体流工作，由SIP信令层负责对异常媒体流服务器节点进行切换到正常的媒体流服务器节点，方便部署，高效利用媒体流服务节点，且易于维护及对媒体流服务的负载均衡控制。

实施例2

如图4所示，本实施例提出一种基于SIP协议的WebRTC媒体流网关容灾方法，所述方法包括：

S1，在本端、远端建立通话时，保存会话标识及所用媒体流节点信息，指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；

S2，监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；

S3，根据第一媒体服务器信息重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

进一步，所述第一媒体服务器信息包括第一媒体服务器IP、端口及状态信息；

所述S1中，指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道，包括：

启动当前本端的媒体流服务，将本端的媒体流服务信息写入至本端的会话描述协议SDP，构成第一SDP请求，发送至远端；所述本端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息。

远端接收所述第一SDP请求，进行解析并回复应答消息；其中所述应答消息包括远端的媒体流服务信息；所述远端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息。

所述信令服务器根据所述媒体信息执行SDP协商，SDP协商完成后，开始媒体流数据传输。

进一步，所述S2中，当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，包括：

确定预定的时间内没收到第一媒体流服务器的工作状态信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；

或者，接收第一媒体流服务器发送的维护信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息。

进一步，所述方法还包括：

根据所述异常监测服务器向所有的信令服务器的UDP监听端口发送所述第一媒体服务器信息；所述信令服务器收到所述第一媒体服务器信息后，向所述异常监测服务器发送响应指令；并基于所述响应指令发送分配请求至信令服务器；

信令服务器基于所述分配请求，根据负载均衡策略确定第二媒体流服务器，并确定所述第二媒体流服务器IP以及端口信息；根据所述第二媒体流服务器IP以及端口信息重写本端的会话描述协议SDP，并生成第二SDP请求发送至远端。

进一步，所述S3中，实现与远端的SDP进行重新协商，重新建立媒体流通道，包括：

远端接收到所述第二SDP请求，将其媒体层信息放入所述SDP中，并回复确认指令至所述信令服务器，实现SDP协商完成，并基于第二媒体流服务器实现媒体流数据传输。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于SIP协议的WebRTC媒体流网关系统，其特征在于，所述WebRTC媒体流网关系统包括信令服务器集群、媒体流服务器集群以及异常监测服务器，所述信令服务器集群包括多个SIP服务器；其中：

信令服务器，用于在通话建立时保存会话标识及所用媒体流节点信息，当会话建立时，信令服务器指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；

异常监测服务器，用于监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；

媒体流服务器，用于与异常监测服务器保持连接，并按照预定周期上传当前的工作状态至异常监测服务器；

所述信令服务器，还用于接收到第一媒体服务器信息，并重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

2.根据权利要求1所述的基于SIP协议的WebRTC媒体流网关系统，其特征在于，所述第一媒体服务器信息包括第一媒体服务器IP、端口及状态信息；

所述信令服务器，还用于启动当前本端的媒体流服务，将本端的媒体流服务信息写入至本端的会话描述协议SDP，构成第一SDP请求，发送至远端；所述本端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

远端接收所述第一SDP请求，进行解析并回复应答消息；其中所述应答消息包括远端的媒体流服务信息；所述远端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

所述信令服务器根据所述媒体信息执行SDP协商，SDP协商完成后，开始媒体流数据传输。

3.根据权利要求2所述的基于SIP协议的WebRTC媒体流网关系统，其特征在于，所述异常监测服务器，还用于确定预定的时间内没收到第一媒体流服务器的工作状态信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；

或者，接收第一媒体流服务器发送的维护信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息。

4.根据权利要求3所述的基于SIP协议的WebRTC媒体流网关系统，其特征在于，所述异常监测服务器，还用于向所有的信令服务器的UDP监听端口发送所述第一媒体服务器信息；所述信令服务器收到所述第一媒体服务器信息后，向所述异常监测服务器发送响应指令；并基于所述响应指令发送分配请求至信令服务器；

所述信令服务器，还用于基于所述分配请求，根据负载均衡策略确定第二媒体流服务器，并确定所述第二媒体流服务器IP以及端口信息；根据所述第二媒体流服务器IP以及端口信息重写本端的会话描述协议SDP，并生成第二SDP请求发送至远端。

5.根据权利要求4所述的基于SIP协议的WebRTC媒体流网关系统，其特征在于，所述实现与远端的SDP进行重新协商，重新建立媒体流通道，包括：

远端接收到所述第二SDP请求，将其媒体层信息放入所述SDP中，并回复确认指令至所述信令服务器，实现SDP协商完成，并基于第二媒体流服务器实现媒体流数据传输。

6.一种基于SIP协议的WebRTC媒体流网关容灾方法，其特征在于，所述方法包括：

在本端、远端建立通话时，保存会话标识及所用媒体流节点信息，指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道；

监测媒体服务器的状态信息；当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，并发送至所有的信令服务器；

根据第一媒体服务器信息重新分配一可用的第二媒体流服务器至本端的会话描述协议SDP中，实现与远端的SDP进行重新协商，重新建立媒体流通道。

7.根据权利要求6所述的基于SIP协议的WebRTC媒体流网关容灾方法，其特征在于，所述第一媒体服务器信息包括第一媒体服务器IP、端口及状态信息；

所述指定分配一个媒体流服务器节点至本端的会话描述协议SDP中，并生成第一SDP请求发送至远端，实现与远端的SDP进行协商，建立媒体流通道，包括：

启动当前本端的媒体流服务，将本端的媒体流服务信息写入至本端的会话描述协议SDP，构成第一SDP请求，发送至远端；所述本端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；

远端接收所述第一SDP请求，进行解析并回复应答消息；其中所述应答消息包括远端的媒体流服务信息；所述远端的媒体流服务信息包括ICE信息、IP、端口以及媒体编码器信息；所述信令服务器根据所述媒体信息执行SDP协商，SDP协商完成后，开始媒体流数据传输。

8.根据权利要求7所述的基于SIP协议的WebRTC媒体流网关容灾方法，其特征在于，

所述当监测到第一媒体服务器的工作状态异常，记录第一媒体服务器信息，包括：

确定预定的时间内没收到第一媒体流服务器的工作状态信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息；

或者，接收第一媒体流服务器发送的维护信息，确认第一媒体流服务器异常，记录所述第一媒体服务器信息。

9.根据权利要求8所述的基于SIP协议的WebRTC媒体流网关容灾方法，其特征在于，所述方法还包括：

所述异常监测服务器向所有的信令服务器的UDP监听端口发送所述第一媒体服务器信息；所述信令服务器收到所述第一媒体服务器信息后，向所述异常监测服务器发送响应指令；并基于所述响应指令发送分配请求至信令服务器；

信令服务器基于所述分配请求，根据负载均衡策略确定第二媒体流服务器，并确定所述第二媒体流服务器IP以及端口信息；根据所述第二媒体流服务器IP以及端口信息重写本端的会话描述协议SDP，并生成第二SDP请求发送至远端。

10.根据权利要求9所述的基于SIP协议的WebRTC媒体流网关容灾方法，其特征在于，所述实现与远端的SDP进行重新协商，重新建立媒体流通道，包括：

远端接收到所述第二SDP请求，将其媒体层信息放入所述SDP中，并回复确认指令至所述信令服务器，实现SDP协商完成，并基于第二媒体流服务器实现媒体流数据传输。