WO2015158058A1 - 一种实现呼叫保存和恢复的方法及系统 - Google Patents

一种实现呼叫保存和恢复的方法及系统 Download PDF

Info

Publication number
WO2015158058A1
WO2015158058A1 PCT/CN2014/082953 CN2014082953W WO2015158058A1 WO 2015158058 A1 WO2015158058 A1 WO 2015158058A1 CN 2014082953 W CN2014082953 W CN 2014082953W WO 2015158058 A1 WO2015158058 A1 WO 2015158058A1
Authority
WO
WIPO (PCT)
Prior art keywords
application server
information
cloud
server
session information
Prior art date
Application number
PCT/CN2014/082953
Other languages
English (en)
French (fr)
Inventor
朱景升
罗会平
梅君君
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2015158058A1 publication Critical patent/WO2015158058A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability

Definitions

  • a broadband call platform is an interface of an application server (AS) based on a Session Initialization Protocol (SIP), which implements input and output by the SIP protocol.
  • SIP Session Initialization Protocol
  • the current broadband call platform is based on the call made by the local server. When the local server AS is down or broken, all the session information will be lost.
  • the prior art has no good solution, and can only be used as a call loss. Processing, which affects the operator's subsequent call statistics, bill statistics, and so on.
  • embodiments of the present invention are directed to a method and system for implementing call save and recovery, which are used to solve the call loss problem that occurs after a local server AS is down or broken in the prior art.
  • the embodiment of the present invention is mainly implemented by the following technical solutions:
  • the embodiment of the present invention provides a method for implementing call saving and recovery, where the method includes: the application server establishes a call between the calling terminal and the called terminal. Then, the session information is saved to the cloud; when the application server fails, the preset hosting server of the application server acquires the session information from the cloud to perform corresponding service processing.
  • the session information includes, but is not limited to, calling terminal information, called terminal information, media negotiation information, association information of the called and called terminals, and information used by the calling and called terminals for subsequent interaction processing.
  • the method further comprises: the distribution device detecting, by the heartbeat interaction, whether the application server is faulty.
  • detecting, by the heartbeat interaction, whether the application server is faulty comprises: performing heartbeat interaction detection with the application server, determining that the application server is faulty when the heartbeat response information of the application server is not received after a predetermined number of times is exceeded .
  • the application server has a plurality of preset hosting servers.
  • the hosting server acquiring the session information from the cloud for corresponding service processing includes: the hosting server acquiring the session information from the cloud to continue to complete the calling terminal and the application server The call of the called terminal, or the hosting server acquires the session information from the cloud and performs call statistics and/or bill statistics according to the session information.
  • the embodiment of the invention further provides a system for implementing call saving and recovery, the system comprising: an application server, configured to save the session information to the cloud after the calling terminal and the called terminal establish a call; the hosting server is set to When the application server fails, the session information is obtained from the cloud for corresponding service processing.
  • the session information includes, but is not limited to, calling terminal information, called terminal information, media negotiation information, association information of the called and called terminals, and information used by the calling and called terminals for subsequent interaction processing.
  • the system further includes a distribution device, and the distribution device is configured to detect whether the application server is faulty through a heartbeat interaction.
  • the distribution device is further configured to: by performing heartbeat interaction detection with the application server, when the heartbeat response information of the application server is not received for more than a predetermined number of times, determining that the application server is faulty.
  • the application server has a plurality of preset hosting servers; the distribution device is further configured to: when the application server fails, select the most idle hosting server according to resource usage of each of the hosting servers.
  • the hosting server is configured to: when the application server fails, acquire the session information from the cloud to continue to complete the call between the calling terminal and the called terminal, instead of the application server, Alternatively, the session information is obtained from the cloud and call statistics and/or bill statistics are performed according to the session information.
  • the beneficial effects of the embodiments of the present invention are as follows: In the embodiment of the present invention, a hosting server is set for each AS, and the session information of the application server is saved to the cloud.
  • FIG. 1 is a schematic structural diagram of a system for implementing call save and recovery according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method for implementing call save and recovery according to an embodiment of the present invention
  • FIG. 4 is a flowchart of a call recovery in the cloud according to an embodiment of the present invention
  • FIG. 5 is a schematic structural diagram of another system for implementing call save and recovery according to an embodiment of the present invention
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE INVENTION The preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings in which For the sake of clarity and simplicity, detailed descriptions of known functions and structures in the devices described herein will be omitted when they may obscure the subject matter of the present invention.
  • the main purpose of embodiments of the present invention is to provide a method and system for implementing call save and recovery, for each
  • the AS sets at least one hosting server, and saves the session information of the application server to the cloud.
  • the AS fails, the session is restored by the hosting server, so that the subsequent processes run normally.
  • the invention effectively reduces the call loss problem caused by the AS downtime or the broken link, and saves the session in the cloud, which reduces the regional limitation and greatly improves the user experience.
  • the technical solutions of the present invention will be described in detail below through several specific embodiments.
  • a system for implementing call save and recovery according to the present invention includes: a distribution device (PROXY) and a plurality of application servers AS, each The AS has at least one hosting server.
  • PROXY distribution device
  • AS has at least one hosting server.
  • the PROXY configuration can obtain the managed AS of each AS.
  • the PROXY external link information and index of all AS configurations are the same.
  • the AS configuration PROXY external link includes: link information between the PROXY and the core network, and an index number generated when the link is configured, and the ASN in FIG. 1 is an access service network. Abbreviation.
  • An embodiment of the present invention provides a method for implementing call save and recovery. Referring to FIG. 1 and FIG. 2, the method includes:
  • the application server saves the session information to the cloud after the calling terminal establishes a call with the called terminal.
  • the session information of the present invention includes but is not limited to the calling terminal information, the called terminal information, the media negotiation information, and the calling and called terminal. The associated information and information for subsequent processing by the calling and called terminals. That is, the application server of the present invention saves the session information to the cloud after the media negotiation of the primary and the called terminal is completed. For example, when a call is incoming, it is distributed to the AS based on SIP signaling by the distribution device (PROXY), and is processed by the PROXY, and then sent to the called terminal by the PROXY, and the session information is saved in the cloud when the media negotiation is completed.
  • PROXY distribution device
  • the SIP signaling is distributed into the AS by the PROXY, and the service is processed.
  • the session information on the AS is saved in the cloud.
  • the ToTag information of the SIP signaling of the present invention includes the device number and the activity sequence number of the AS.
  • the SIP signaling further includes the hosting information, where the hosting information specifically includes the device number of the hosted AS.
  • the distribution device detects whether the application server is faulty through a heartbeat interaction. Specifically, the distribution device performs heartbeat interaction detection with the application server, and when the distribution device does not receive the heartbeat response information of the application server after a predetermined number of times, the application server is determined to be faulty.
  • the heartbeat interaction detection of the present invention is initiated by the distribution device, and the request message sent by the distribution device includes the device number and activity sequence number information of the AS.
  • the heartbeat response information returned by the AS includes the resource status of the AS, the activity sequence number, and the device number and activity sequence number information of the hosted AS.
  • the application server may set a plurality of hosting servers, and when detecting that an application server fails, the distribution device according to resource usage of each of the managed servers Select the most idle hosting server, and trigger the hosting server to go to the cloud to obtain the session information for corresponding business processing.
  • the distribution device PROXY determines whether the heartbeat response information of the AS that has not received the specified N times is exceeded, and if so, determines that the AS is faulty. Select another AS for hosting. If there is only one managed AS in the current AS, PROXY sends to this AS for session hosting. If there are multiple managed ASs, PROXY obtains the current multiple managed ASs based on the heartbeat response information of the managed AS. The most idle AS is hosted.
  • the heartbeat response information between the PROXY and the managed AS must contain resource usage information of the hosting AS, for example, the number of sessions used, the number of sessions negotiated by the media, and the total number of sessions.
  • the escrow server performs the corresponding service processing according to the session information, including: the escrow server obtains all session information of the failed application server from the cloud, and performs corresponding service processing according to the session information.
  • the managed device acquires all the session information data saved by the AS according to the device ID of the faulty AS in the SIP signaling sent by the distribution device, and the distribution device sends the SIP signaling that is called in again to the managed AS for processing. .
  • the present invention notifies the corresponding hosting server to host the failed application server.
  • the distribution device sends a message to the managed server for corresponding service. deal with.
  • the step of the hosting server acquiring the session information from the cloud to perform corresponding service processing specifically includes: the hosting server acquiring the session information from the cloud to continue to complete the a call between the calling terminal and the called terminal, and other operations of the subsequent terminal, such as a call, etc.; or, the hosting server acquires the session information from the cloud and performs call statistics or words according to the session information. Single statistics.
  • the cloud storage in the present invention is mainly stored in a key-value manner, and the device number, the activity sequence number, and the session identifier of the application server are combined to form a key value, and the session information to be saved is saved as a value to the cloud.
  • FIG. 3 is a flow chart of the call saving in the cloud of the present invention
  • FIG. 5 is a schematic structural diagram of another system for implementing call save and recovery according to an embodiment of the present invention, as shown in FIG. 3 and As shown in FIG. 5, the steps of saving the call in the cloud specifically include: Step 1.
  • the core network initiates a call, and uses SIP signaling; Step 2: PROXY parses the message header and finds the destination AS information to be forwarded; Step 3: Forwards the message to AS1; Step 4: AS1 parses the message to perform related service processing; Step 5, returns a response to PROXY; Step 6. Returning the response to the core network; Step 7. If the media negotiation is completed, send the save session information to the cloud to save the data. Otherwise, proceed to the process of the first 6 steps (ie, steps 1-6) for media negotiation until the completion; Step 8.
  • the cloud asynchronously returns the storage result; Step 9, the core network sends the hang up message to PROXY; Step 10, PROXY parses the message header and finds the destination AS information to be forwarded; Step 11, forwards the message to AS 1; Step 12, AS1 pairs the message Performing parsing, performing related business processing; Step 13, returning the response to PROXY; Step 14, returning the response to the core network; Step 15, if the session information is stored in the cloud, the session information needs to be sent to the cloud; Step 16, the cloud asynchronously returns the release result.
  • 4 is a flow chart of the call recovery in the cloud of the present invention. Compared with FIG. 3, FIG. 4 has more recovery process during the call, and the hang up call message is not sent to AS1 but to AS2.
  • the method for recovering a call in the cloud of the present invention includes the following steps: Step 1.
  • the core network initiates a call, using SIP signaling; Step 2, PROXY parses the message header and finds the destination AS information to be forwarded; Step 3 Forwarding the message to AS1; Step 4: AS1 parses the message and performs related service processing; Step 5: Return the response to PROXY; Step 6. Return the response to the core network; Step 7. If the media negotiation is completed, send the save session information to the cloud to save the data. Otherwise, continue the process of the first 6 steps for media negotiation until completion.
  • Step 8 the cloud asynchronously returns the storage result;
  • Step 9 PROXY detects the AS1 failure, and finds that AS2 is the most idle AS in the managed device;
  • Step 10 sends a message to restore the failed AS1 session to AS2;
  • Step 11, AS2 returns a response PROXY;
  • Step 12 PROXY manages the destination information of the forwarding application server according to the heartbeat response information returned by AS2;
  • Step 13 AS2 parses the recovery message sent by PROXY, and fetches the data to the cloud;
  • Step 14 the asynchronous response of the cloud returns the obtained session information Data and delete the data in the cloud;
  • Step 15 restore the session completion, update the host session information;
  • Step 16 save the newly restored session data to the cloud;
  • Step 17, the cloud asynchronously returns the storage result;
  • Step 18, the core network sends and hangs Break the message to PROXY;
  • Step 19 PROXY parses the message header and finds the destination to be forwarded
  • Step 20 Forward the message to AS2;
  • Step 25 The cloud asynchronously returns the release result.
  • Embodiments of the present invention also provide a system for implementing call save and recovery.
  • the system includes a distribution device and a hosting server.
  • the application server saves the session information to the cloud.
  • the managed server acquires the session information from the cloud to perform corresponding service processing.
  • the session information is obtained from the cloud to continue to complete the call between the calling terminal and the called terminal, or is obtained from the cloud.
  • the session information is used to perform call statistics or bill statistics according to the session information.
  • the present invention sets at least one hosting server for each AS, and saves the session information of the application server to the cloud.
  • the distribution device of the present invention detects whether the application server is faulty through a heartbeat interaction. Specifically, the distribution device performs heartbeat interaction detection with the application server, and when the heartbeat response information of the application server is not received, the information is not received. Then the application server is determined to be faulty.
  • each application server is configured with multiple hosting servers, and when detecting that an application server fails, the distribution device selects the most idle hosting according to the resource usage of each of the managed servers. The server is hosted. In the following, a system for saving and restoring a call in the cloud according to the present invention will be described in detail.
  • the system includes: a core network device: a call set to initiate SIP signaling, and a call for receiving SIP signaling.
  • Distribution Device Set to forward the call initiated by the terminal to the AS with a certain policy.
  • the heartbeat interaction with the AS is maintained, the running state of the AS is detected, and the failed AS session can be hosted by the other AS that is the most idle hosted by the AS, and the subsequent signaling interaction is sent to the hosting AS.
  • Application server The SIP signaling process interacts, saves session information to the cloud, retrieves session information from the cloud and restores the session, manages AS resource usage, and manages the managed failed AS session information.
  • the cloud storage device stores the key information in the key-value mode. The device ID, the activity sequence number, and the session ID are used to store the key value.
  • the session information to be saved is saved to the cloud as the value.
  • the present invention also provides another schematic structural diagram of a system for implementing call save and recovery, as shown in FIG. 6.
  • the distribution device includes at least: a forwarding unit, a first receiving unit, a first control unit, and a first management unit; and a forwarding unit configured to forward the SIP signaling sent by the core network to the AS according to the forwarding policy, where the SIP signaling includes the hosting
  • the managed AS information is forwarded to the managed AS
  • the first receiving unit is configured to receive the SIP signaling of the AS and forwarded to the core network
  • the first control unit is configured to send the heartbeat to the AS, and receive the heartbeat returned by the AS, according to The heartbeat detects the link state, and if the link is different, sends a escrow message to the escrow AS
  • the first management unit is configured to manage the AS information sent by the AS heartbeat, and timely update the resource information of the AS, and provide the control unit and the forwarding unit
  • the AS includes at least: a second control unit, a second receiving unit, a service processing unit, a sending unit, and a second management unit.
  • the second control unit is configured to perform heartbeat interaction with the distribution device to obtain resource usage of the AS, and the management failure
  • the second receiving unit is configured to receive a message sent by the distribution device, and parse the SIP signaling; the service processing unit is configured to perform the business logic processing on the parsed result; and the sending unit is configured to form the processing result into a SIP letter.
  • the cloud unit is configured to save the session data to the cloud, acquire the data recovery session in the cloud, and manage the cloud-related operation information;
  • the second management unit is configured to manage the faulty AS information, such as the device number, the activity serial number, Restore the number of sessions, the remaining number of existing recovery sessions, the number of sessions to be restored, and so on.
  • the system embodiment of the present invention has the functions and effects of all the method embodiments. For related content, refer to the method embodiment part, which is not discussed in detail herein.
  • the method and system for implementing call save and recovery provided by the present invention can bring the following beneficial effects:
  • the present invention sets at least one hosting server for each application server, and saves the session information of the application server to the cloud.
  • the session is selected to be restored on the most idle managed server, so that the subsequent process runs normally.
  • the invention effectively reduces the call loss problem caused by the AS downtime or the broken link, and saves the session in the cloud, which reduces the regional limitation and greatly improves the user experience.
  • the above is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or within the technical scope disclosed by the present invention. Alternatives are intended to be covered by the scope of the present invention. Therefore, the scope of the invention should be determined by the scope of the claims.
  • the above technical solution provided by the present invention can be applied to a call saving and recovery process, and a hosting server is set for each AS, and session information of the application server is saved to the cloud, and when the AS fails, the technical solution is adopted.

Abstract

本发明公开了一种实现呼叫保存和恢复的方法及系统，其中，该方法包括：应用服务器在主叫终端和被叫终端建立通话后，将会话信息保存到云端；当所述应用服务器发生故障时，所述应用服务器的预设托管服务器从所述云端获取所述会话信息进行相应的业务处理。本发明通过对每个应用服务器均设置至少一个托管服务器，并将应用服务器的会话信息保存到云端，在AS出现故障时，选择在一台最空闲托管服务器上恢复会话，从而使后续流程正常运行，从而有效的降低了AS宕机或者断链带来的呼损问题，并且大大提高了用户体验。

Description

一种实现呼叫保存和恢复的方法及系统 技术领域 本发明涉及通信技术领域， 尤其涉及一种实现呼叫保存和恢复的方法及系统。 背景技术 宽带呼叫平台是由基于会话初始协议 (Session Initialization Protocol , SIP)的应用服 务器 （Application Server, AS), 由 SIP协议实现输入和输出的接口。 目前的宽带呼叫平台都是基于本地服务器实现的呼叫， 当本地服务器 AS 出现宕 机或者断链， 则所有的会话信息都会丢失， 现有技术对此没有很好的解决办法， 只能 作为呼损处理， 从而影响了运营商对后续的呼叫统计、 话单统计等等。 发明内容 鉴于上述的分析，本发明实施例旨在提供一种实现呼叫保存和恢复的方法及系统， 用以解决现有技术中本地服务器 AS宕机或者断链后出现的呼损问题。 为解决上述问题， 本发明实施例主要是通过以下技术方案实现的： 本发明实施例 提供了一种实现呼叫保存和恢复的方法， 该方法包括： 应用服务器在主叫终端和被叫终端建立通话后， 将会话信息保存到云端； 当所述应用服务器发生故障时， 所述应用服务器的预设托管服务器从所述云端获 取所述会话信息进行相应的业务处理。 优选地， 所述会话信息包括但不限于主叫终端信息、 被叫终端信息、 媒体协商信 息、 主被叫终端的关联信息和用于主被叫终端进行后续交互处理的信息。 优选地， 该方法还包括： 分发设备通过心跳交互检测所述应用服务器是否发生故 障。 优选地， 通过心跳交互检测所述应用服务器是否发生故障包括： 通过与所述应用服务器进行心跳交互检测， 当在超过预定次数没有收到所述应用 服务器的心跳响应信息， 则判定该应用服务器故障。 优选地， 所述应用服务器的预设托管服务器为多个， 当所述应用服务器发生故障 时， 根据各个所述托管服务器的资源使用情况选择最空闲的托管服务器从云端获取所 述会话信息进行相应的业务处理。 优选地，所述托管服务器从所述云端获取所述会话信息进行相应的业务处理包括: 所述托管服务器从所述云端获取所述会话信息以代替所述应用服务器继续完成所 述主叫终端和所述被叫终端的通话， 或者， 所述托管服务器从所述云端获取所述会话 信息并根据所述会话信息进行呼叫统计和 /或话单统计。 本发明实施例还提供了一种实现呼叫保存和恢复的系统， 该系统包括： 应用服务器， 设置为在主叫终端和被叫终端建立通话后，将会话信息保存到云端； 托管服务器， 设置为当所述应用服务器发生故障时， 从所述云端获取所述会话信 息进行相应的业务处理。 优选地， 所述会话信息包括但不限于主叫终端信息、 被叫终端信息、 媒体协商信 息、 主被叫终端的关联信息和用于主被叫终端进行后续交互处理的信息。 优选地， 所述系统还包括分发设备； 所述分发设备， 设置为通过心跳交互检测所述应用服务器是否发生故障。 优选地， 所述分发设备还设置为， 通过与所述应用服务器进行心跳交互检测， 当 在超过预定次数没有收到所述应用服务器的心跳响应信息，则判定该应用服务器故障。 优选地， 所述应用服务器的预设托管服务器为多个； 所述分发设备还设置为， 当所述应用服务器发生故障时， 根据各个所述托管服务 器的资源使用情况选择最空闲的托管服务器作为该故障的应用服务器的托管服务器。 优选地， 所述托管服务器设置为， 当所述应用服务器发生故障时， 从所述云端获 取所述会话信息以代替所述应用服务器继续完成所述主叫终端和所述被叫终端的通 话， 或者， 从所述云端获取所述会话信息并根据所述会话信息进行呼叫统计和 /或话单 统计。 本发明实施例有益效果如下: 本发明实施例对每个 AS均设置一个托管服务器， 并将应用服务器的会话信息保 存到云端， 在 AS出现故障时， 通过托管服务器恢复会话， 从而使后续流程正常运行。 本发明有效的降低了 AS宕机或者断链带来的呼损问题， 并且将会话保存在云端， 减 弱了地域性的限制， 并且大大提高了用户体验。 本发明实施例的其他特征和优点将在随后的说明书中阐述， 并且部分的从说明书 中变得显而易见， 或者通过实施本发明而了解。 本发明实施例的目的和其他优点可通 过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实现和获得。 附图说明 图 1为本发明实施例的实现呼叫保存和恢复的系统的组成架构示意图； 图 2为本发明实施例的实现呼叫保存和恢复的方法的流程图； 图 3为本发明实施例的呼叫在云端保存流程图； 图 4是本发明实施例的呼叫在云端恢复流程图； 图 5为本发明实施例的另一种实现呼叫保存和恢复的系统的组成架构示意图； 图 6为本发明实施例的再一种实现呼叫保存和恢复的系统的组成结构示意图。 具体实施方式 下面结合附图来具体描述本发明的优选实施例， 其中， 附图构成本申请一部分， 并与本发明的实施例一起用于阐释本发明的原理。 为了清楚和简化目的， 当其可能使 本发明的主题模糊不清时， 将省略本文所描述的器件中已知功能和结构的详细具体说 明。 本发明实施例的主要目的是提供一种实现呼叫保存和恢复的方法及系统， 对每个
AS均设置至少一个托管服务器， 并将应用服务器的会话信息保存到云端， 在 AS出现 故障时， 通过托管服务器恢复会话， 从而使后续流程正常运行。 本发明有效的降低了 AS宕机或者断链带来的呼损问题， 并且将会话保存在云端， 减弱了地域性的限制， 并 且大大提高了用户体验。 下面就通过几个具体实施例对本发明的技术方案进行详细说 明。 图 1为本发明实施例的实现呼叫保存和恢复的系统的组成结构示意图， 参见图 1， 本发明的实现呼叫保存和恢复的系统包括： 分发设备 (PROXY)和多个应用服务器 AS， 每个 AS均至少设置一个托管服务器， PROXY配置能够获取每个 AS的托管 AS， 所 有 AS配置的 PROXY对外链路信息和索引均相同。所述 AS配置 PROXY对外链路包 括： PROXY和核心网之间的链路信息以及与配置此链路时生成的索引号等， 其中， 图 1中的 ASN为接入业务网络 （Access Service Network) 的简称。 本发明实施例提供了一种实现呼叫保存和恢复的方法， 参见图 1和图 2， 该方法 包括：
5101、 应用服务器在主叫终端和被叫终端建立通话后， 将会话信息保存到云端； 本发明的会话信息包括但不限于主叫终端信息、 被叫终端信息、 媒体协商信息、 主被叫终端的关联信息和用于主被叫终端进行后续交互处理的信息。 即， 本发明的应用服务器在主、 被叫终端媒体协商完成后， 将会话信息保存到云 端。 例如， 呼叫呼入时， 基于 SIP信令由分发设备 （PROXY) 分发进入 AS， 进行业 务处理， 再由 PROXY发送到被叫终端， 媒体协商完成时将会话信息保存在云端。 相 应的， 呼叫挂断时， SIP信令由 PROXY分发进入 AS， 进行业务处理， 媒体协商完成 时将 AS上的会话信息保存在云端。本发明的 SIP信令的 ToTag信息包括 AS的设备号、 活动序号， 当该应用服务器发生故障时， SIP 信令中还包括托管信息， 所述托管信息 具体包括托管 AS的设备号等。
5102、 当所述应用服务器发生故障时， 所述应用服务器的预设托管服务器从所述 云端获取所述会话信息进行相应的业务处理。 本发明实施例中分发设备通过心跳交互检测所述应用服务器是否发生故障。 具体 为， 分发设备通过与所述应用服务器进行心跳交互检测， 当在超过预定次数分发设备 没有收到所述应用服务器的心跳响应信息， 则判定该应用服务器故障。 本发明的心跳交互检测由分发设备发起， 分发设备发出的请求消息包含 AS 的设 备号和活动序号信息等。 AS返回的心跳响应信息包含 AS的资源现状、 活动序号和托 管 AS的设备号和活动序号信息等。 本发明还提供了一个优选的实施例， 所述应用服务器可设定多个托管服务器， 当 检测到某个应用服务器发生故障时， 分发设备根据各个所述托管服务器的资源使用情 况选择最空闲的托管服务器， 并触发该托管服务器到云端获取所述会话信息进行相应 的业务处理。 具体是，分发设备 PROXY判断是否超过指定的 N次未收到 AS的心跳响应信息， 若是则判断 AS故障。 选择另一台 AS进行托管， 如果当前 AS的只有一个托管 AS， 则 PROXY发送到此 AS进行会话托管， 若有多个托管 AS， 则 PROXY根据托管 AS 的心跳响应信息获取当前多个托管 AS 中最空闲的 AS 进行托管。 在该种情况下， PROXY和托管 AS之间的心跳响应信息必须包含托管 AS的资源使用情况信息，例如， 会话使用个数、 媒体协商完成会话的个数和总的会话个数等等。 本发明实施例中托管服务器根据所述会话信息进行相应的业务处理包括： 所述托管服务器到云端获取该发生故障的应用服务器的所有会话信息， 并根据所 述会话信息进行相应的业务处理。 例如， 托管设备根据分发设备发送来的 SIP信令中 的故障的 AS 的设备号到云端获取其保存的所有会话信息数据， 且分发设备将再次呼 入的 SIP信令发送到托管 AS上进行处理。 即本发明在分发设备检测到某个应用服务器故障后， 通知相应的托管服务器对故 障的应用服务器进行托管， 当呼叫 SIP信令再次进入时， 分发设备将消息发送给该托 管服务器进行相应的业务处理。 本发明中的所述托管服务器从所述云端获取所述会话信息进行相应的业务处理的 步骤具体包括： 所述托管服务器从所述云端获取所述会话信息以代替所述应用服务器 继续完成所述主叫终端和所述被叫终端的通话， 以及后续终端的其它操作，如呼转等； 或者， 所述托管服务器从所述云端获取所述会话信息并根据所述会话信息进行呼叫统 计或话单统计。 本发明中的云存储主要以 key-value的方式进行存储， 以应用服务器的设备号、活 动序号和会话标识组成 key值， 将要保存的会话信息作为 value值保存到云端。 下面对本发明的方法进行详细的说明： 图 3是本发明的呼叫在云端保存流程图， 图 5是本发明实施例的另一种实现呼叫 保存和恢复的系统的组成架构示意图， 如图 3和 5所示， 呼叫在云端保存的步骤具体 包括： 步骤 1、 核心网发起呼叫， 使用 SIP信令； 步骤 2、 PROXY解析消息头并查找要转发的目的 AS信息； 步骤 3、 将消息转发到 AS1 ; 步骤 4、 AS1对消息进行解析， 进行相关业务处理； 步骤 5、 返回响应给 PROXY; 步骤 6、 返回响应给核心网； 步骤 7、 若媒体协商完成， 则发送保存会话信息到云端进行保存数据， 否则继续 进行前 6步 （即步骤 1-6) 的流程进行媒体协商， 直至完成； 步骤 8、 云端异步返回存储结果； 步骤 9、 核心网发送挂断消息到 PROXY; 步骤 10、 PROXY解析消息头并查找要转发的目的 AS信息； 步骤 11、 将消息转发到 AS 1 ; 步骤 12、 AS1对消息进行解析， 进行相关业务处理； 步骤 13、 返回响应给 PROXY; 步骤 14、 返回响应给核心网； 步骤 15、 若会话信息保存在云端， 需要发送释放会话信息到云端； 步骤 16、 云端异步返回释放结果。 图 4是本发明的呼叫在云端恢复流程图。 与图 3相比， 图 4多了通话过程中的恢 复过程， 挂断呼叫消息不在发往 AS1， 而是发往 AS2。 结合图 4和 5， 本发明的呼叫 在云端恢复的方法包括以下步骤： 步骤 1、 核心网发起呼叫， 使用 SIP信令； 步骤 2、 PROXY解析消息头并查找要转发的目的 AS信息； 步骤 3、 将消息转发到 AS1 ; 步骤 4、 AS1对消息进行解析， 进行相关业务处理； 步骤 5、 返回响应给 PROXY; 步骤 6、 返回响应给核心网； 步骤 7、 若媒体协商完成， 则发送保存会话信息到云端进行保存数据， 否则继续 进行前 6步的流程进行媒体协商， 直至完成； 步骤 8、 云端异步返回存储结果； 步骤 9、 PROXY检测到 AS1故障， 并找到 AS2是托管设备中最空闲的 AS; 步骤 10、 发送恢复故障 AS1会话的消息到 AS2; 步骤 11、 AS2返回响应给 PROXY; 步骤 12、PROXY根据 AS2返回的心跳响应信息管理转发应用服务器的目的信息; 步骤 13、 AS2解析 PROXY发过来的恢复消息， 去云端取数据； 步骤 14、 云端异步响应返回取得的会话信息数据并将云端中的数据删除； 步骤 15、 恢复会话完成， 更新托管会话信息； 步骤 16、 将新恢复的会话数据保存到云端； 步骤 17、 云端异步返回存储结果； 步骤 18、 核心网发送挂断消息到 PROXY; 步骤 19、 PROXY解析消息头并查找要转发的目的应用服务器的信息； 步骤 20、 将消息转发到 AS2; 步骤 21、 AS2对消息进行解析， 进行相关业务处理； 步骤 22、 AS2返回响应给 PROXY; 步骤 23、 PROXY返回响应给核心网； 步骤 24、 若会话信息保存在云端， 需要发送释放会话信息到云端； 步骤 25、 云端异步返回释放结果。 本发明实施例还提供了一种实现呼叫保存和恢复的系统， 参见图 1， 该系统包括 分发设备和托管服务器。 应用服务器在主叫终端和被叫终端建立通话后， 将会话信息保存到云端； 托管服务器当所述应用服务器发生故障时， 从所述云端获取所述会话信息进行相 应的业务处理。 具体为， 当所述应用服务器发生故障时， 从所述云端获取所述会话信 息以代替所述应用服务器继续完成所述主叫终端和所述被叫终端的通话， 或者， 从所 述云端获取所述会话信息并根据所述会话信息进行呼叫统计或话单统计。 本发明通过对每个 AS均设置至少一个托管服务器， 并将应用服务器的会话信息 保存到云端， 在 AS 出现故障时， 选择在一台最空闲托管服务器上恢复会话， 从而使 后续流程正常运行。 本发明的分发设备通过心跳交互检测所述应用服务器是否发生故障， 具体的， 分 发设备通过与所述应用服务器进行心跳交互检测， 当在超过预定次数没有收到所述应 用服务器的心跳响应信息， 则判定该应用服务器故障。 本发明还提供了一个优选实施例， 将每个应用服务器设定多个托管服务器， 分发 设备在检测到某个应用服务器发生故障时， 根据各个所述托管服务器的资源使用情况 选择最空闲的托管服务器进行托管。 下面以一个具体的例子对本发明的一种呼叫在云端保存和恢复的系统进行详细说 明， 该系统包括： 核心网设备： 设置为发起 SIP信令的呼叫， 接收 SIP信令的呼叫。 分发设备： 设置为将终端发起的呼叫以一定的策略转发给 AS。保持和 AS之间的 心跳交互，检测 AS的运行状态，并能够将出现故障的 AS会话让互为托管的最空闲的 另一台 AS托管， 在后续的信令交互发给托管 AS。 应用服务器： SIP 信令流程交互， 保存会话信息到云端， 从云中取会话信息并恢 复会话， 管理 AS资源使用情况， 管理托管的故障 AS会话信息。 云存储设备： 存储主要以 key-value的方式进行存储， 以 AS的设备号、 活动序号 和会话标识组成 key值， 将要保存的会话信息作为 value值保存到云端。 本发明还提供了另一种实现呼叫保存和恢复的系统的组成结构示意图， 具体如图 6所示。 分发设备至少包括： 转发单元、 第一接收单元、 第一控制单元和第一管理单元； 转发单元， 设置为根据转发策略转发核心网发过来的 SIP信令给 AS， 当 SIP信令 内包括托管信息时， 查找托管 AS信息， 转发给托管 AS; 第一接收单元， 设置为接收 AS的 SIP信令转发到核心网； 第一控制单元， 设置为发送心跳给 AS， 接收 AS返回的心跳， 根据心跳检测链路 状态， 若链路不同， 发送托管消息给托管 AS; 第一管理单元，设置为管理 AS心跳发送来的 AS信息，及时更新 AS的资源信息， 提供给控制单元和转发单元查询；
AS至少包括： 第二控制单元、第二接收单元、 业务处理单元、 发送单元和第二管 理单元； 第二控制单元， 设置为和分发设备之间心跳交互， 获取 AS 的资源使用情况， 托 管故障 AS的会话； 第二接收单元， 设置为接收分发设备发过来的消息， 解析 SIP信令； 业务处理单元， 设置为将解析的结果进行业务逻辑处理； 发送单元， 设置为将处理结果组成 SIP信令发送出去； 云化单元， 设置为保存会话数据到云， 获取云中数据恢复会话， 管理云化相关操 作信息； 第二管理单元， 设置为管理故障 AS 的信息， 如设备号、 活动序号、 恢复会话个 数， 现有恢复会话剩余个数， 待恢复会话个数等。 本发明的系统实施例具备所有方法实施例的功能和效果， 相关内容可参考方法实 施例部分， 在此不再详细论述。 本发明提供的实现呼叫保存和恢复的方法及系统， 能够带来以下有益效果： 本发明对每个应用服务器均设置至少一个托管服务器， 并将应用服务器的会话信 息保存到云端， 在 AS 出现故障时， 选择在一台最空闲托管服务器上恢复会话， 从而 使后续流程正常运行。 本发明有效的降低了 AS宕机或者断链带来的呼损问题， 并且 将会话保存在云端， 减弱了地域性的限制， 并且大大提高了用户体验。 以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易想到的变化或替 换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的保护范围应该以权利要求书 的保护范围为准。 工业实用性 本发明提供的上述技术方案，可以应用于呼叫保存和恢复过程中，采用对每个 AS 均设置一个托管服务器， 并将应用服务器的会话信息保存到云端， 在 AS出现故障时， 通过托管服务器恢复会话， 从而使后续流程正常运行的技术方案。 有效的降低了 AS 宕机或者断链带来的呼损问题， 并且将会话保存在云端， 减弱了地域性的限制， 并且 大大提高了用户体验。

Claims

权 利 要 求 书 、 一种实现呼叫保存和恢复的方法， 包括： 应用服务器在主叫终端和被叫终端建立通话后， 将会话信息保存到云端； 当所述应用服务器发生故障时， 所述应用服务器的预设托管服务器从所述 云端获取所述会话信息进行相应的业务处理。 、 根据权利要求 1所述的方法，其中，所述会话信息包括但不限于主叫终端信息、 被叫终端信息、 媒体协商信息、 主被叫终端的关联信息和用于主被叫终端进行 后续交互处理的信息。 、 根据权利要求 1所述的方法， 其中， 还包括：
分发设备通过心跳交互检测所述应用服务器是否发生故障。 、 根据权利要求 3所述的方法， 其中， 通过心跳交互检测所述应用服务器是否发 生故障包括：
通过与所述应用服务器进行心跳交互检测， 当在超过预定次数没有收到所 述应用服务器的心跳响应信息， 则判定该应用服务器故障。 、 根据权利要求 1-4中任意一项所述的方法， 其中， 所述应用服务器的预设托管服务器为多个，当所述应用服务器发生故障时， 根据各个所述托管服务器的资源使用情况选择最空闲的托管服务器从云端获取 所述会话信息进行相应的业务处理。 、 根据权利要求 1-4中任意一项所述的方法， 其中， 所述托管服务器从所述云端 获取所述会话信息进行相应的业务处理包括：
所述托管服务器从所述云端获取所述会话信息以代替所述应用服务器继续 完成所述主叫终端和所述被叫终端的通话；
或者， 所述托管服务器从所述云端获取所述会话信息并根据所述会话信息进行呼 叫统计和 /或话单统计。 、 一种实现呼叫保存和恢复的系统， 包括： 应用服务器， 设置为在主叫终端和被叫终端建立通话后， 将会话信息保存 到云端；
托管服务器， 设置为当所述应用服务器发生故障时， 从所述云端获取所述 会话信息进行相应的业务处理。 、 根据权利要求 7所述的系统，其中，所述会话信息包括但不限于主叫终端信息、 被叫终端信息、 媒体协商信息、 主被叫终端的关联信息和用于主被叫终端进行 后续交互处理的信息。 、 根据权利要求 7所述的系统， 其中， 还包括分发设备； 所述分发设备， 设置为通过心跳交互检测所述应用服务器是否发生故障。 0、 根据权利要求 9所述的系统， 其中， 所述分发设备还设置为， 通过与所述应用服务器进行心跳交互检测， 当在 超过预定次数没有收到所述应用服务器的心跳响应信息， 则判定该应用服务器 故障。 1、 根据权利要求 7-10中的任意一项所述的系统， 其中， 所述应用服务器的预设托 管服务器为多个；
所述分发设备还设置为， 当所述应用服务器发生故障时， 根据各个所述托 管服务器的资源使用情况选择最空闲的托管服务器作为该故障的应用服务器的 托管服务器。 、 根据权利要求 7-10中的任意一项所述的系统， 其中， 所述托管服务器具体设置为， 当所述应用服务器发生故障时， 从所述云端 获取所述会话信息以代替所述应用服务器继续完成所述主叫终端和所述被叫终 端的通话， 或者， 从所述云端获取所述会话信息并根据所述会话信息进行呼叫 统计和 /或话单统计。
PCT/CN2014/082953 2014-04-18 2014-07-24 一种实现呼叫保存和恢复的方法及系统 WO2015158058A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410157674.2 2014-04-18
CN201410157674.2A CN105007143A (zh) 2014-04-18 2014-04-18 一种实现呼叫保存和恢复的方法及系统

Publications (1)

Publication Number Publication Date
WO2015158058A1 true WO2015158058A1 (zh) 2015-10-22

Family

ID=54323439

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/082953 WO2015158058A1 (zh) 2014-04-18 2014-07-24 一种实现呼叫保存和恢复的方法及系统

Country Status (2)

Country Link
CN (1) CN105007143A (zh)
WO (1) WO2015158058A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107959693B (zh) * 2016-10-14 2022-04-15 中兴通讯股份有限公司 一种呼出方法、同步服务器以及呼出系统
CN109845389B (zh) * 2017-03-21 2021-05-04 华为技术有限公司 一种通信方法及装置
CN114500221B (zh) * 2021-12-28 2024-04-26 阿里巴巴（中国）有限公司 云系统、公有云的管控方法、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101667933A (zh) * 2009-10-23 2010-03-10 杭州华三通信技术有限公司 一种安全认证系统及其主备切换方法和设备
CN102685163A (zh) * 2011-03-15 2012-09-19 中兴通讯股份有限公司 一种DSN VoIP业务系统中的基本会话保护方法和系统
CN103326880A (zh) * 2013-04-24 2013-09-25 武汉大学 Genesys呼叫系统高可用性云计算监控系统及方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101667933A (zh) * 2009-10-23 2010-03-10 杭州华三通信技术有限公司 一种安全认证系统及其主备切换方法和设备
CN102685163A (zh) * 2011-03-15 2012-09-19 中兴通讯股份有限公司 一种DSN VoIP业务系统中的基本会话保护方法和系统
CN103326880A (zh) * 2013-04-24 2013-09-25 武汉大学 Genesys呼叫系统高可用性云计算监控系统及方法

Also Published As

Publication number Publication date
CN105007143A (zh) 2015-10-28

Similar Documents

Publication Publication Date Title
US9391854B2 (en) Method and router for packet processing during server failure
US8051189B2 (en) Methods, systems, and computer program products for session initiation protocol (SIP) fast switchover
US8374079B2 (en) Proxy server, communication system, communication method and program
JP2022502926A (ja) Ｕｅ移行方法、装置、システム、および記憶媒体
US20130297804A1 (en) Load Balancing for SIP Services
US9113031B2 (en) Call control for conferencing calls
WO2016082710A1 (zh) 一种呼叫控制方法、Diameter协议转发设备及系统
US10367856B2 (en) Failover management of SIP based multimedia communication sessions
US20140043960A1 (en) Method, tor switch, and system for implementing protection switchover based on trill network
US9215078B2 (en) Multicast method and multicast device
KR20150007623A (ko) 패킷 전달 시스템에서의 보호 절체 방법 및 장치
US20140143413A1 (en) Method, local gateway, and system for local voice survivability
WO2012088910A1 (zh) 连通性故障检测方法和系统
WO2014117737A1 (zh) Oam报文处理方法、设备及系统
JP2007004361A (ja) 負荷分散装置
CN105813228A (zh) 基于SIP over TCP/TLS的通信方法及相关装置
KR101620809B1 (ko) Ｓｉｐ 프록시 장애 극복을 위한 방법
WO2014146541A1 (zh) Cdn与网络融合系统、调度模块选定方法及计算机存储介质
US10680930B2 (en) Method and apparatus for communication in virtual network
WO2015158058A1 (zh) 一种实现呼叫保存和恢复的方法及系统
CN107222883B (zh) 无线控制器备份方法、备份切换方法、装置及系统
WO2015042840A1 (zh) 一种故障恢复的方法、节点和路径计算单元
US10063495B2 (en) Method and apparatus for improved handling of IMS node blacklisting
KR20200072941A (ko) 실시간 오류 감지를 통한 vrrp 기반의 네트워크 장애 대응 방법 및 장치
JP5518771B2 (ja) 冗長ネットワークシステム、終端装置及び中継点隣接装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14889582

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14889582

Country of ref document: EP

Kind code of ref document: A1