WO2006136098A1 - Procédé de traitement d’appel - Google Patents

Procédé de traitement d’appel Download PDF

Info

Publication number
WO2006136098A1
WO2006136098A1 PCT/CN2006/001402 CN2006001402W WO2006136098A1 WO 2006136098 A1 WO2006136098 A1 WO 2006136098A1 CN 2006001402 W CN2006001402 W CN 2006001402W WO 2006136098 A1 WO2006136098 A1 WO 2006136098A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
msc
server
cause value
processing method
Prior art date
Application number
PCT/CN2006/001402
Other languages
English (en)
French (fr)
Inventor
Haopeng Zhu
Zhijun Liao
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2006136098A1 publication Critical patent/WO2006136098A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a call processing method. Background technique
  • the 3rd Generation Partnership Project R4 (Release 4) splits the core network circuit domain mobile switching center MSC (Mobile services Switching Center) into mobile soft. Two devices, the exchange server (MSC Server) and the media gateway MGW (Media Gateway), realize the separation of service control and service bearer.
  • MSC Server Mobile services Switching Center
  • MGW Media Gateway
  • the core network circuit domain MSC server and MGW are two independent devices, and the middle is connected through the Mc interface. connection.
  • the MSC Server device mainly completes call control and the media gateway completes bearer control.
  • the Mc interface is the control interface between the MSC Server and the MGW, and the MSC Server controls the MGW through the Megaco/H.248 protocol. '
  • the MSC Server 1 is a call origination server, and the mobile softswitch server MSC Server 2 is a call tandem server.
  • the processing flow includes the following steps:
  • the MSC Server1 receives an initial address message IAM (Initial address message) call message carrying the called terminal number called party number;
  • IAM Initial address message
  • the MSC Server1 analyzes the called terminal number, and determines that the routing mode of the call is the office point corresponding to the mobile softswitch server MSC Server2, and then the MSC Server1 sends an IAM message to the MSC Server2.
  • step S03 is performed;
  • the MSC Server2 returns a dry release message REL (Release message) to the MSC Server1 to notify the connection that the call fails.
  • REL Release message
  • the MSC Server1 After receiving the REL message, the MSC Server1 returns a release to the MSC Server2. Release the completion message RLC ( Release complete message) and release the call.
  • the dry-release message REL carries the cause value indicating the reason for the connection failure, and MSC Server1 can perform statistical analysis on these cause values.
  • the call originating end does not set different processing procedures according to the REL carrying reason value, but uses the processing method of releasing the call to perform the processing of the bill, which reduces the success rate of the call and affects the satisfaction of the user.
  • the cause value carried in the existing REL message is filled in according to the failure reason code defined in the ITU-T Q.850 protocol.
  • the failure reasons involved in the ITU-T Q.850 protocol are based on the failure in the R99 networking mode. Types are defined, introducing new types of failures that can cause routing failures due to separate architectures: Media gateway failures and circuit busyness do not define new cause values.
  • the present invention provides a call processing method, which solves the problem of low call success rate caused by simply releasing call processing due to the failure of the originating mobile soft handover server to distinguish between connection failures in the prior art.
  • a call processing method includes the following steps:
  • the first mobile softswitch server MSC Server1 sends the call message carrying the called terminal address to the second mobile softswitch server MSC Server2 for connection;
  • the MSG Server2 feeds back a release message REL carrying a cause value, where the cause value identifies the reason for the connection failure;
  • the MSC Server1 pre-sets the loop to determine whether the call can be connected through the third mobile softswitch server MSC Server3. If yes, the MSC Server1 sends the call message to the MSC Server3 for connection; otherwise, the MSC Server1 releases the station. Call the call.
  • the loop is pre-set by the policy in the configuration information of the mobile softswitch server.
  • the other mobile softswitch server is selected by the policy according to the loop to perform the call.
  • the non-called terminal unreachable cause value includes: a value value indicating a media gateway failure to the called terminal and/or a busy circuit.
  • the second mobile softswitch server MSC Server2 is based on locally available resource information and/or Or the quality of service policy confirms that the media gateway is faulty or the circuit is busy.
  • the method further comprises: adding a step of determining whether the media gateway is faulty or the circuit is fully busy in a related processing flow of the mobile softswitch server.
  • the current state information of the media gateway and circuitry is stored in the MSC Server and updated in real time.
  • the method further comprises: extending a connection failure cause value in the ITU-T Q.850 protocol, extending a Cause parameter in the BICC/ISUP signaling, and adding two to indicate that the circuit is busy and represents a media gateway failure.
  • the cause value of the enumeration value is not limited to: extending a connection failure cause value in the ITU-T Q.850 protocol, extending a Cause parameter in the BICC/ISUP signaling, and adding two to indicate that the circuit is busy and represents a media gateway failure.
  • the cause value of the enumeration value is not limited to indicate that the circuit is busy and represents a media gateway failure.
  • the available other softswitch servers are selected according to the local routing configuration information to perform the loop success, and the success rate of the call;
  • the reasons for the connection failure are divided into two categories, one is the unreachable caused by the called terminal itself, and the other is including all other reasons in the existing reason.
  • the existing one is utilized.
  • the cause value carried in the REL message determines the two types of causes. If it is the first type, the call is released, and the system resources are no longer occupied for meaningless detour. If it is the second type, according to the local routing configuration information, when available.
  • the other servers can be connected to the current call;
  • the existing cause value is expanded, and the two types of faults in the separate architecture of the mobile softswitch server and the media gateway are added: the cause value of the outgoing media gateway and the outgoing circuit is busy, so that the originating softswitch server can identify These two reasons for the failure of the connection, thereby further improving the call success rate by using the above-mentioned loop circuit, and improving the reliability of the statistics and analysis of the cause value.
  • FIG. 1 is a flow chart of call processing in accordance with an embodiment of the present invention.
  • the network structure is more flexible.
  • the mobile softswitch server can be used to perform the loop process. Shown as follows:
  • Steps S11 to S13 in the embodiment of the present invention are the same as steps S01 to S03 of the prior art described in the background, and when the call tandem server MSG Server2 cannot successfully connect the call, the call tandem server MSC Server2 originates from the call.
  • the server MSC Server1 returns a release message REL to notify that the call fails to be connected;
  • Step S14 After receiving the REL message, the MSC Server1 returns an RLC acknowledgement message to the MSC Servei'2, and does not directly put the call, but analyzes the cause value of the Cause parameter in the REL, according to the established loopback policy. It is judged that if it is the cause of the connection failure that can be caused by the loop, step S15 is performed; otherwise, the call is released.
  • the loop circuit described here is set in the configuration information of the mobile softswitch server by the policy.
  • the cause values of the connection failure are divided into two categories: The first type is that the called terminal is busy, and the shutdown is temporarily unavailable.
  • the connection succeeded, for example: In the existing ITU-T Q.850 protocol, the cause value is 17, 18, etc.
  • the reason for the failure is the corresponding reason value, which is called the terminal unreachable cause value.
  • the second type is the connection failure caused by the mobile softswitch server that performs the tandem connection, which cannot be properly routed due to the line, etc., including all other reasons except that the called terminal is unreachable, and the present invention refers to these reasons.
  • the corresponding cause value is called the non-called terminal unreachable cause value.
  • the call can be made through another mobile softswitch server.
  • the mobile softswitch server After receiving the REL message, the mobile softswitch server first analyzes whether the cause value of the Cause parameter in the REL belongs to the second type of cause value. If yes, reselect an outgoing route according to the routing data configuration, and step S15 is performed.
  • the reason value is divided into the first category and the second category, and is determined by the operator according to factors such as resource availability and service quality policy, and does not limit the scope of protection of the present invention.
  • Step S15 the MSC Server1 sends an IAM message to the softswitch server MSC Server3 destined for the loopback;
  • Step S16 on the MSC Server3, after analyzing the called number, the available media gateway and circuit for routing the called party can be found, the call continues to be connected, and the MSC Server3 sends an address full message ACM (Addres s Complete Mes sage) to the call originating server MSC.
  • ACM Address s Complete Mes sage
  • Step S17 the MSC Server1 forwards the address full message ACM to the calling end;
  • Step S18 the MSC Server3 sends a response message ANM (Audio Mes sage) to the call originating server MSC Server1;
  • Step S19 The MSC Server1 forwards the response message A to the calling end.
  • the MSC Server 1 can continue to find another softswitch server that can be looped until the route is unreachable, and then release the call.
  • the REL message carries the cause value of the specific connection failure, and the routing failure caused by different reasons is flexibly handled, thereby improving the success rate of the call.
  • the REL message sent by the MSC Server2 to the MSC Server1 must carry an explicit cause value in order to determine whether or not to perform the loopback, but two faults occur more frequently under the core network separation architecture: Media gateway failure and circuit Fully busy fault, because the reason code and processing flow are not defined for the two faults in the prior art, the calling MSC Server cannot first identify the exact connection failure reason from the returned REL message and cannot select the correct processing flow. The loop loop is used to reduce the success rate of the call. At the same time, because the failure reason cannot be clearly counted, the performance analysis of the entire system also has certain errors.
  • Cause value 35 Added this enumeration value to indicate that the circuit is fully busy
  • Cuase value 36 Added this enumeration value to indicate a media gateway failure.
  • the physical interface is connected between the MSC Server and the media gateway through the Mc interface.
  • the media gateway requests registration authentication from the MSC server, and the MSC server sets the media gateway through the registered authentication as an available media gateway and registers, and then the MSC server and The media gateway can send a heartbeat message to detect whether the line is faulty in real time or periodically.
  • the media gateway side can also actively request the MSC server to deactivate through the interaction of related messages.
  • the MSC server will set the line fault or the media gateway required to be deactivated to be unavailable media.
  • the gateway registers and, in this way, the MSC server can keep track of the available status of the currently configured media gateway; for the use of the circuit, it also registers in the currently available resources, as the basis for the line selection when the MSC server routes the call.
  • the MSC Server When there is more than one media gateway to the called terminal, the MSC Server cannot route the call only if all the media gateways are faulty or the media gateway circuit that is not faulty is busy. At this time, the routing MSC Server needs to fail the connection. The calling MSC Server is notified in the REL message.
  • MSC-SERVER1 For MSC-SERVER1, the call starts to be routed to MSC-SERVER2, but the call fails in MSC-SERVER2, and the REL message is returned. MSC-SERVER1 checks the cause value. If it is 35 or 36, then according to the round-trip strategy, Instead of releasing the call, it is rerouted to the MSC-SERVER3 to continue the call, thereby increasing user satisfaction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种呼叫处理方法
技术领域 本发明涉及通信技术领域， 具体涉及呼叫处理方法。 背景技术
随着第三代移动通信宽带码分多址 WCDMA ( Wideband Code
Division Multiple Access ) 的研究进程不断推进， 第三代移动通信标准化 伙伴项目 3GPP ( 3rd Generation Partnership Project ) R4 ( Release 4 )将 核心网络电路域移动交换中心 MSC ( Mobile services Switching Center )拆 分为移动软交换服务器（ MSC Server )和媒体网关 MGW( Media Gateway ) 两个设备， 从而实现了业务控制和业务承载的分离， 其中核心网络电路 域 MSC server与 MGW是两个独立的设备， 中间通过 Mc接口进行连接。 MSC Server设备主要完成呼叫控制、媒体网关完成承载控制。 Mc接口是 MSC Server和 MGW之间的控制接口， MSC Server通过 Megaco/H.248 协议对 MGW进行控制。 '
如图 1 所示， 为呼叫的处理的基本流程， 其中： 移动软交换服务器
MSC Server 1为呼叫始发服务器， 移动软交换服务器 MSC Server 2为呼 叫汇接服务器， 处理流程包括以下步骤：
S01、 MSC Serverl 接收到入局的携带着被叫终端号码 called party number的初始地址消息 IAM ( Initial address message )呼叫消息；
S02、 MSC Serverl分析被叫终端号码， 确定此呼叫的路由方式是移 动软交换服务器 MSC Server2所对应的局点，那么 MSC Serverl就向 MSC Server2发送 IAM消息；
正常情况下， MSC Server2通过去被叫终端的媒体网关和电路接续呼 叫， 但是， 当 MSC Server2因各种故障无法正常接续本次呼叫时， 执行 步骤 S03;
503、 MSC Server2向 MSC Serverl返回一个幹放消息 REL ( Release message )通知接续本次呼叫失败；
504、 当 MSC Serverl收到 REL消息后， 向 MSC Server2返回一个释 放完成确认消息 RLC ( Release complete message ), 并释放呼叫。
幹放消息 REL中，携带有指示接续失败原因的原因值， MSC Serverl 可以对这些原因值进行统计分析。 但是在呼叫始发端并没有根据 REL携 带原因值设置不同的处理流程， 而是一律采用释放呼叫的处理方式进行 筒单处理， 降低了呼叫的成功率、 影响了用户的满意度。
现有 REL消息中携带的原因值是根据 ITU-T Q.850协议中定义的失 败原因代码填写的， ITU-T Q.850协议中涉及的失败原因都是根据 R99组 网模式中出现的故障类型进行定义， 对于因分离架构而引入新的两类能 够造成路由失败的故障： 媒体网关故障和电路全忙并没有进行定义新的 原因值。
发明内容
本发明提供一种呼叫处理方法， 以解决现有技术中因始发移动软交 换服务器不区别接续失败原因， 简单的进行释放呼叫处理而造成的呼叫 成功率低的问题。
根据本发明提供的一种呼叫处理方法， 包括如下步骤：
第一移动软交换服务器 MSC Serverl将携带被叫终端地址的呼叫消 息发送给第二移动软交换服务器 MSC Server2进行接续；
MSG Server2在接续所述呼叫失败时， 反馈携带原因值的释放消息 REL, 所述原因值标识接续失败的原因；
MSC Serverl 居预先设置的迂回路由策略判断是否可以通过第三 移动软交换服务器 MSC Server3接续所述呼叫， 如果是， 则 MSC Serverl 将所述呼叫消息发送给 MSC Server3进行接续； 否则， MSC Serverl释 放所述呼叫。
所述迂回路由策略预先设置在移动软交换服务器的配置信息中。 更适宜地， 当所述原因值为相关的非被叫终端不可达原因值时， 根 据迂回路由策略选择另一个移动软交换服务器进行迂回路由， 接续呼叫。
所述非被叫终端不可达原因值包括： 标识去被叫终端的媒体网关故 障和 /或电路全忙的原因值。
所述第二移动软交换服务器 MSC Server2根据本地可用资源信息和 / 或服务质量策略对媒体网关故障或电路全忙进行确认。
优选地， 该方法还包括： 在移动软交换服务器的相关处理流程中增 加判断媒体网关是否故障或电路是否全忙的步驟。
更适宜地， 将媒体网关和电路的当前状态信息保存在 MSC Server中 并实时更新。
优选地， 该方法进一步包括： 对 ITU-T Q.850协议中的接续失败原因 值进行扩展， 扩展 BICC/ISUP信令中 Cause参数， 增加两个分别用于表 示电路全忙和表示媒体网关故障的 Cause value枚举值。
由如上所述的本发明的技术方案可知， 应用本发明所述方法， 当呼 叫接续失败时， 根据本地路由配置信息选择可用的其他软交换服务器进 行迂回路由， 呼叫的成功率；
进一步， 将接续失败的原因分为两大类， 一类是被叫终端自身造成 的不可达， 另一类包括现有原因中所有其他原因， 在始发端软交换服务 器侧， 利用现有的 REL消息中携带的原因值对两类原因进行判断， 如果 是第一类， 则释放呼叫， 不再占用系统资源进行无意义的迂回， 如果是 第二类， 根据本地路由配置信息， 当有可用的其他服务器可以接续本次 呼叫时进行迂回路由；
并且， 对现有的原因值进行扩充， 增加了由于移动软交换服务器和 媒体网关分离架构下的两类故障： 出局媒体网关和出局电路全忙的原因 值， 使始发端软交换服务器可以识别这两种接续失败原因， 从而利用上 述的迂回路由方法进一步提高了呼叫成功率， 同时提高了对原因值进行 统计和分析的可靠性。
附图说明
图 1为现有技术中呼叫处理流程图；
图 1为根据本发明的实施例的呼叫处理流程图。
具体实施方式 为使本发明的原理、 特性和优点更加明显， 下面通过具体实施例对 本发明做进一步描述。
随着组网方式的变化， 网络结构更加灵活， 在一次呼叫选路过程中， 如果不是由于被叫终端忙、 关机等无法接通产生的呼叫失败， 而是由于 路由局自身的问题导致无法成功路由本次呼叫时， 完全可以利用移动软 交换服务器进行迂回路由处理流程如图 2所示：
本发明的实施例中的步骤 S11 S13和背景技术中所述现有技术的步 骤 S01〜S03相同， 呼叫汇接服务器 MSG Server2无法正常接续本次呼叫 时，呼叫汇接服务器 MSC Server2向呼叫始发服务器 MSC Serverl返回释 放消息 REL通知接续本次呼叫失败；
步骤 S14、 当 MSC Serverl收到 REL消息后， 向 MSC Servei'2返回 一个 RLC确认消息， 这时并不直接幹放呼叫， 而是分析 REL中 Cause参 数的原因值， 根据制定的迂回路由策略进行判断， 如果是可以迂回路由 的接续失败原因， 则执行步骤 S 15; 否则释放呼叫。
这里所述的迂回路由策略设置在移动软交换服务器的配置信息中， 在迂回路由策略中， 将接续失败的原因值分为两大类： 第一类为被叫终 端忙、 关机等暂时无法接通产生的接续失败， 例如： 现有 ITU-T Q.850协 议中原因值为 17、 18等接续失败原因， 对应的原因值称为终端不可达原 因值， 这时， 应该立即释放， 不再占用系统资源； 第二类是进行汇接的 移动软交换服务器方由于线路等原因无法正常路由呼叫导致的接续失 败， 包括除被叫终端不可达之外的所有其他原因， 本发明将这些原因称 为非被叫终端不可达原因， 相应的原因值称为非被叫终端不可达原因值， 这时， 如果网络结构允许， 可以通过另一个移动软交换服务器进行迂回 路由， 接续呼叫。
因此，移动软交换服务器在收到 REL消息后，首先分析 REL中 Cause 参数的原因值是否属于第二类原因值， 如果是， 根据路由数据配置重新 选择一个出局路由， 执行步骤 S15。
具体如何将原因值分为第一类和第二类， 由运营商根据资源可用情 况、 服务质量策略等因素确定， 并不限定本发明的保护范围。
在这一步骤中， 也可以对所有接续失败的呼叫选择可用移动软交换 服务器进行迂回路由， 但是， 如果是第一类原因， 则后续的迂回多数是 没有意义的， 造成系统资源的浪费， 因此， 较佳的实现方式还是根据具 体原因进行分类的处理方式。
步骤 S15、 MSC Serverl发送 IAM消息给目的地为进行迂回路由的 软交换服务器 MSC Server3;
S16, 在 MSC Server3上， 经过对被叫号码分析， 能够找到路由被叫 的可用媒体网关和电路， 呼叫继续接续， MSC Server3 发送地址全消息 ACM ( Addres s Complete Mes sage )给呼叫始发服务器 MSC Serverl ; 步骤 S17, MSC Serverl将该地址全消息 ACM转发给主叫端； 步骤 S18, MSC Server3发送应答消息 ANM ( Answer Mes sage )给呼 叫始发服务器 MSC Serverl；
步骤 S19， MSC Serverl将该应答消息 A匪转发给主叫端。
这样， 最终完成呼叫接续。
若 MSC Server3不能完成呼叫接续， 按照本发明提供的方法， MSC Serverl可继续查找另一个可以迂回路由的软交换服务器， 直到所有的路 由都不通时， 再释放呼叫。
通过本发明提供的方法， 利用 REL消息中携带有具体接续失败的原 因值， 灵活的处理不同原因引发的路由失败， 提高了呼叫的成功率。
为实现上述方法， 在 MSC Server2发送给 MSC Serverl的 REL消息 中， 必须携带明确的原因值， 以便决定是否进行迂回路由， 但是核心网 分离架构下的较常出现两种故障： 媒体网关故障和电路全忙故障， 由于 现有技术中没有对这两种故障定义原因代码和处理流程， 导致主叫 MSC Server首先无法从返回的 REL消息中识别出确切的接续失败原因而不能 选择正确的处理流程进行迂回路由， 降低了呼叫的成功率， 同时因为无 法明确统计接续失败原因， 造成整个系统的性能分析也存在一定失误。
为解决上述问题，需要在 ITU-T Q.850协议中对现有的接续失败原因 值进行扩展， 扩展 BICC/ISUP信令中 Cause参数的 Cause value的枚举定 义， 增加如下两个定义：
Cause value 35: 新增此枚举值用于表示电路全忙；
Cuase value 36: 新增此枚举值用于表示媒体网关故障。
同时， 在 MSC Server的迂回策略的第二类原因值中， 增加 35和 36 两项， 在 MSC Server在检查到该原因值时， 不释放呼叫， 而是重新路由 到其他 MSC Server进行接续。 代码， 也可以选择其他空闲代码， 只要 BICC/ISUP消息中 Cause参数的 字段位数支持即可。
并且在 MSC Server的相关处理流程中， 增加判断媒体网关是否故障 或电路是否全忙的步骤， 媒体网关和电路的当前使用情况都登记在 MSC Server的资源信息中并随时更新的， 具体过程为：
MSC Server和媒体网关之间通过 Mc接口利用物理线路连接， 媒体 网关在上电后， 向 MSC server请求注册认证， MSC server将通过注册认 证的媒体网关设置为可用媒体网关并登记， 之后 MSC server和媒体网关 可以实时或周期性发送心跳消息检测线路是否故障， 媒体网关侧也可以 通过相关消息的交互主动要求 MSC server去激活， MSC server将出现线 路故障或要求去激活的媒体网关设置为不可用媒体网关并进行登记， 这 样， MSC server可以随时掌握当前所配置媒体网关的可用情况； 对于电 路的使用情况， 也在当前可用资源中进行登记， 作为 MSC server路由呼 叫时进行线路选择的依据。
当去被叫终端的媒体网关不止一个时， 只有全部媒体网关都故障或 者没有故障的媒体网关电路都忙时， MSC Server才无法路由本次呼叫， 这时，路由 MSC Server需要将接续失败原因在 REL消息中通知主叫 MSC Server。
综上， 对 MSC-SERVER1而言， 呼叫开始路由至 MSC-SERVER2, 但在 MSC-SERVER2呼叫失败， 返回 REL消息， MSC-SERVER1检查原 因值， 如果是 35或者是 36, 那么就根据迂回策略， 不释放呼叫， 而是重 新路由到 MSC-SERVER3上， 继续接续呼叫， 从而提高了用户的满意度。
显然， 本领域的技术人员可以对本发明进行各种改动和变型而不脱 离本发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发 明权利要求及其等同技术的范围之内， 则本发明也包含这些改动和变型 在内。

Claims

权 利 要 求
1、 一种呼叫处理方法， 其特征在于， 包括步骤：
第一移动软交换服务器 MSC Serverl将携带被叫终端地址的呼叫消 息发送给第二移动软交换服务器 MSC Server2进行接续；
MSC Server2 在接续所述呼叫失败时， 反馈携带原因值的释放消息
REL, 所述原因值标识接续失败的原因；
MSC Serverl 根据预先设置的迂回路由策略判断是否可以通过第三 移动软交换服务器 MSC Server3接续所述呼叫， 如果是， 则 MSC Serverl 将所述呼叫消息发送给 MSC Server3进行接续；
否则， MSC Serverl释放所述呼叫。
2、 如权利要求 1所述的呼叫处理方法， 其特征在于， 所述迂回路由 策略预先设置在移动软交换服务器的配置信息中。
3、 如权利要求 1所述的呼叫处理方法， 其特征在于，
当所述原因值为相关的非被叫终端不可达原因值时， 根据迂回路由 策略选择另一个移动软交换服务器进行迂回路由， 接续呼叫。
4、 如权利要求 1或 3所述的呼叫处理方法， 其特征在于， 所述非被 叫终端不可达原因值包括： 标识去被叫终端的媒体网关故障和 /或电路全 忙的原因值。
5、 如权利要求 4所述的呼叫处理方法， 其特征在于， 所述第二移动 软交换服务器 MSC Server2根据本地可用资源信息和 /或服务质量策略对 媒体网关故障或电路全忙进行确认。
6、如权利要求 4所述的呼叫处理方法， 其特征在于， 该方法还包括： 在移动软交换服务器的相关处理流程中增加判断媒体网关是否故障或电 路是否全忙的步骤。
7、如权利要求 4所述的呼叫处理方法， 其特征在于，该方法还包括： 将媒体网关和电路的当前状态信息保存在 MSC Server中并实时更新。
8、 如权利要求 4所述的呼叫处理方法， 其特征在于， 该方法进一步 包括： 对 ITU-T Q.850 协议中的接续失败原因值进行扩展， 扩展 BICC/ISUP信令中 Cause参数， 增加两个分别用于表示电路全忙和表示 媒体网关故障的 Cause value枚举值。
PCT/CN2006/001402 2005-06-20 2006-06-20 Procédé de traitement d’appel WO2006136098A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2005100768958A CN100417293C (zh) 2005-06-20 2005-06-20 一种呼叫处理方法
CN200510076895.8 2005-06-20

Publications (1)

Publication Number Publication Date
WO2006136098A1 true WO2006136098A1 (fr) 2006-12-28

Family

ID=37570108

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/001402 WO2006136098A1 (fr) 2005-06-20 2006-06-20 Procédé de traitement d’appel

Country Status (2)

Country Link
CN (1) CN100417293C (zh)
WO (1) WO2006136098A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101257437A (zh) * 2007-02-28 2008-09-03 华为技术有限公司 呼叫仲裁节点失败路由重选方法、交换机和系统
CN108197015A (zh) * 2017-12-29 2018-06-22 天脉聚源（北京）科技有限公司 以消息的方式写入日志数据的方法及装置
CN113691680B (zh) * 2021-08-17 2024-01-30 北京恒安嘉新安全技术有限公司 一种bicc呼叫阻断方法、系统、装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298063B1 (en) * 1995-11-03 2001-10-02 Cisco Technology, Inc. System and method for providing backup machines for implementing multiple IP addresses on multiple ports
CN1430382A (zh) * 2001-12-27 2003-07-16 富士施乐株式会社 用于外部网络连接的设定信息分配方法
CN1620781A (zh) * 2002-04-25 2005-05-25 国际商业机器公司 动态改变数据处理网络中的连接的系统和方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19834674A1 (de) * 1998-07-31 2000-02-03 Ericsson Telefon Ab L M Verfahren, Vermittlungsstelle, Telekommunikationssystem und Mobilstation für ein vorübergehendes selektives nationales Roaming bei vorgegebenen Netzbetriebsbedingungen in einem Mobilfunk-Kommunikationssystem
JP2001189743A (ja) * 2000-01-04 2001-07-10 Toshiba Corp 通信システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298063B1 (en) * 1995-11-03 2001-10-02 Cisco Technology, Inc. System and method for providing backup machines for implementing multiple IP addresses on multiple ports
CN1430382A (zh) * 2001-12-27 2003-07-16 富士施乐株式会社 用于外部网络连接的设定信息分配方法
CN1620781A (zh) * 2002-04-25 2005-05-25 国际商业机器公司 动态改变数据处理网络中的连接的系统和方法

Also Published As

Publication number Publication date
CN100417293C (zh) 2008-09-03
CN1885991A (zh) 2006-12-27

Similar Documents

Publication Publication Date Title
JP4001813B2 (ja) テレコミュニケーションシステムにおけるユーザターミナルへの接続の監視
US8571546B2 (en) Method for implementing dual-homing
US7301938B2 (en) Method of transferring a packet switched to a circuit switched call
CN101365169B (zh) 路由控制的实现方法、系统、媒体网关及媒体网关控制器
EP2481203B1 (en) Technique for monitoring a call
CN100574486C (zh) 通信网络中双归属组网的系统及其方法
US7532568B1 (en) Geographic redundancy for call servers in a cellular system based on a bearer-independent core network
WO2007000094A1 (fr) Procede pour effectuer un raccordement a double anneau de central de commutation mobile
WO2009070999A1 (fr) Procédé et dispositif pour ajuster l'état de relais
US20080161054A1 (en) Node selection function for multipoint radio network configurations
WO2009015525A1 (en) A method for switching the session control path of ip multimedia core network subsystem centralized service
WO2006081772A1 (fr) Méthode pour obtenir un fonctionnement dans les deux sens entre domaine de circuit et domaine de groupe
WO2007124641A1 (fr) Procédé et dispositif permettant de percevoir un utilisateur qui déclenche un service supplémentaire
WO2008071126A1 (fr) Procédé et dispositif de détection d'état de transport de charge ainsi que procédé de distribution et système de ressource de transport de charge
WO2009039688A1 (en) Late call forwarding method in ip multimedia core network subsystem centralized service
KR100719167B1 (ko) 2-계층 통신 네트워크에서의 접속 해제
US20120224469A1 (en) Network fault detection method and apparatus
WO2006136098A1 (fr) Procédé de traitement d’appel
WO2006136075A1 (fr) Procédé pour implémenter une double appartenance dans la séparation entre le réseau de contrôle et le réseau de relèvement
US20070217342A1 (en) Method and Apparatus for Security Protection of Service Interruption in Switch Network
CN100428825C (zh) 双归属系统中业务倒换/倒回时恢复业务数据的方法
WO2007131421A1 (fr) Méthode et procédé pour déclencher le son de lecture de panne
WO2009070958A1 (fr) Procédé et dispositif de détection d'échec de circuit de jonction de plan utilisateur, de détection de récupération et d'établissement de rapport de celle-ci
WO2007022684A1 (fr) Procédé de détection de connexion dans une procédure d’appel entre bsc et msc
WO2007137515A1 (fr) Système et procédé permettant au contrôleur de passerelle média (mgc) d'obtenir le statut de support, passerelle média (mgw) et mgc

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06761306

Country of ref document: EP

Kind code of ref document: A1