呼叫接续过程中的异常处理方法及服务器的制作方法

文档序号:7847144阅读:195来源:国知局
专利名称:呼叫接续过程中的异常处理方法及服务器的制作方法
技术领域
本发明涉及通信领域,特别涉及一种呼叫接续过程中的异常处理方法及服务器。
背景技术
VoIP (Voice over Internet Protocol,互联网协议电话)简而言之就是将模拟声音信号数字化,以数据封包的型式在IP (Internet Protocol,互联网协议)网络上做实时传递。随着越来越多的VoIP业务的成功应用,以及电信网络和IP网络的不断融合,VoIP业务越来越普及,甚至无线网络也开始支持和部署VoIP业务,并且,VoIP业务使用的协议越来越倾向于用SIP(SeSSi0n Initiation Protocol,会话发起协议)及其对应的扩展协议。对于无线网络下的VoIP业务,由于无线网络不稳定的特点和用户终端容易掉电的特点,支持VoIP业务的用户终端在任何时候都可能出现无线信号质量严重下降或突然掉电等情况,从而导致空口链路断链的异常状况,而应用层协议SIP无法及时发现这些异常,如果这个时候正处在VoIP的呼叫接续过程中,VoIP业务会受到以下影响如果主叫和被叫都为同一局点的移动用户,会出现被叫用户终端误振铃的情况, 即如果主叫用户终端在发送了 ^wite消息(呼叫请求消息)后就出现了无线信号变差或掉电等导致断链的异常状况,则本次呼叫失败,但是由于SIP检测不到该异常,被叫用户终端在发送180消息的同时开始振铃,就是误振铃,如果被叫用户及时应答还会造成无效的应答;如果主叫用户终端到被叫用户终端的呼叫是跨局呼叫(即局向呼叫),不仅会误振铃,还有可能出现误计费的情况,以与ISUP(ISDN User Part, ISDN用户部分)信令互通为例,一个无线VoIP用户呼叫其他网络的另一个用户,在主叫用户终端发送了 ^wite消息到服务器后,被叫用户终端不再需要主叫用户终端发送任何消息就可以振铃和摘机应答, 并发送ANM(Answer Message,应答消息)到服务器,应答后被叫网络侧就开始出话单计费了 ;假如主叫用户终端在向服务器发送ACK(Acknowledgement,确认)消息前出现了无线信号变差或掉电等导致断链的异常状况,则服务器发送的100消息、18x消息和200(应答) 消息主叫用户终端都有可能没有收到,这取决于主叫用户终端发生异常的时间点,如果是在收到200消息后发生的异常,此时ACK消息还没有发送,这种情况下按照SIP的规定,发送200消息的服务器还会将200消息定时重发N次,N次后仍收不到ACK消息才会拆除本次呼叫,而在这个过程中,如果被叫用户已经接听,会出现无法通话并且无任何提示音的情况,但是按照用户的习惯,被叫用户不一定会立即挂机,等被叫用户意识到此次呼叫发生了异常再挂机时,被叫网络侧已经产生了计费话单,短则几秒,长则几十秒,但是主叫网络侧由于认为呼叫没有成功而不会出话单,这样如果主、被叫网络属于不同的运营商,则会出现结算异常。

发明内容
为了解决无线网络下VoIP呼叫接续过程中由异常导致的误振铃和误计费的问题,本发明实施例提供了一种呼叫接续过程中的异常处理方法及服务器。所述技术方案如下—方面,提供了一种呼叫接续过程中的异常处理方法,所述方法包括在接收到主叫用户终端发送的呼叫请求消息之后,检测所述主叫用户终端是否发生异常;如果检测到所述主叫用户终端发生异常,则拆除所述主叫用户终端到被叫用户终端的呼叫,并释放所述呼叫的相关资源。另一方面,提供了一种服务器,所述服务器包括检测模块,用于在接收到主叫用户终端发送的呼叫请求消息之后,检测所述主叫用户终端是否发生异常;拆除模块,用于在所述检测模块检测到所述主叫用户终端发生异常后,拆除所述主叫用户终端到被叫用户终端的呼叫,并释放所述呼叫的相关资源。本发明实施例提供的技术方案带来的有益效果是通过在呼叫接续过程中检测主叫用户终端是否发生异常,并在检测到主叫用户终端发生异常时及时拆除主叫用户终端到被叫用户终端的呼叫,释放该呼叫的相关资源,能够降低呼叫系统的开销,并能够提升被叫用户的感受,减少不必要的振铃,而且在跨局、跨运营商呼叫的情景下及时发现异常并拆除呼叫能够防止呼叫接续过程中的误计费。


为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。图1是本发明实施例一提供的呼叫接续过程中的异常处理方法流程图;图2是本发明实施例二提供的呼叫接续过程中的异常处理方法流程图;图3是本发明实施例二提供的检测主叫用户终端是否发生异常的流程图;图4是本发明实施例二提供的另一种检测主叫用户终端是否发生异常的流程图;图5是本发明实施例三提供的服务器结构示意图;图6是本发明实施例三提供的另一种服务器结构示意图;图7是本发明实施例三提供的另一种服务器结构示意图;图8是本发明实施例三提供的另一种服务器结构示意图。
具体实施例方式为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。实施例一本发明实施例提供了一种呼叫接续过程中的异常处理方法,参见图1,方法流程包括101 在接收到主叫用户终端发送的^wite消息之后,检测主叫用户终端是否发生异常;102:如果检测到主叫用户终端发生异常,则拆除主叫用户终端到被叫用户终端的呼叫,并释放该呼叫的相关资源。本发明实施例提供的方法,通过在呼叫接续过程中检测主叫用户终端是否发生异常,并在检测到主叫用户终端发生异常时及时拆除主叫用户终端到被叫用户终端的呼叫, 释放该呼叫的相关资源,能够降低呼叫系统的开销,并能够提升被叫用户的感受,减少不必要的振铃,而且在跨局、跨运营商呼叫的情景下及时发现异常并拆除呼叫能够防止呼叫接续过程中的误计费。实施例二本发明实施例提供了一种呼叫接续过程中的异常处理方法,该方法可以用于无线网络和IP网络下的VoIP呼叫接续过程中,并且适用于局内呼叫和局向呼叫等多种场景。为了便于说明,本发明实施例以无线网络下的局向呼叫为例进行说明,但不限定于此。参见图 2,方法流程包括201 服务器接收主叫用户终端发送的hvite消息;具体地,本发明实施例中的服务器是指可以向主叫用户终端发出的^wite消息提供服务并回送应答的任何服务器,本发明实施例对此不作具体限定,例如,可以是代理服务器(Proxy Server)或SIP服务器(SIP krver),其中,SIP服务器又可以是IMS (IP Multimedia Subsystem, IP) >NGN(Next Generation Network,T"—ft ) 或其他能够完成服务器功能的网元。进一步地,服务器接收到主叫用户终端发送的^wite消息后,要进行原有呼叫流程的响应,具体为向主叫用户终端发送临时响应消息100,向被叫用户终端发送 IAMdnitial Address Message,初始地址消息),并接收被叫用户终端发送的ACM(Address Complete Message,地址完成消息)和ANM。对于上述不影响本发明的原有呼叫流程本发明实施例不再详细描述。202:判断是否需要对主叫用户终端进行异常检测,如果需要,则执行203,否则, 按照原有呼叫流程执行,流程结束;其中,202是可选步骤。由于检测主叫用户终端是否发生异常的过程会占用一定的无线空口带宽,因此可以先进行是否需要对主叫用户终端进行异常检测的判断,选择性的对那些由异常导致的问题严重的场景进行异常检测,因此执行202可以降低系统开销。判断是否需要对主叫用户终端进行异常检测的具体方式可以是判断主叫用户终端发起的呼叫是否是局向呼叫,如果是,说明异常可能导致误计费的问题,则需要对主叫用户终端进行异常检测;和/或,判断主叫用户终端是否是在无线网络下发起的呼叫,如果是,说明主叫用户终端容易发生异常,则需要对主叫用户终端进行异常检测,其中,可以通过主叫用户终端的域名或号段或增加特殊标志来区分主叫用户终端是否在无线网络。优选地,可以上述两个判断过程都予以执行,即最终只针对主叫用户终端在无线网络下发起的局向呼叫进行异常检测,这样可以减少异常检测带来的系统开销。203 检测主叫用户终端是否发生异常,如果是,则执行204,否则,执行206 ;具体地,检测主叫用户终端是否发生异常的具体方式可以是向主叫用户终端发
6送检测请求消息,并开始计时;如果在计时达到预设时间之前接收到主叫用户终端发送的检测响应消息,则向主叫用户终端发送新的检测请求消息,并重新开始计时;如果在计时达到预设时间之前没有接收到主叫用户终端发送的检测响应消息,则在计时达到预设时间之后,向主叫用户终端重复发送之前发送的检测请求消息,并重新开始计时;判断重复发送的次数是否达到预设的最大重发次数,如果是,则判定主叫用户终端发生异常。其中,主叫用户终端发生异常可能是出现了无线信号变差或掉电等导致断链的异常状况。进一步地,参见图3,为检测主叫用户终端是否发生异常的流程图。需要说明的是, 图3中的检测请求消息和检测响应消息相对于18x消息、200消息和ACK消息的顺序是不确定的,是随呼叫的实际情况而变化的,且不是每条检测请求消息都会有对应的检测响应消息,其中,被叫用户终端振铃后,服务器会向主叫用户终端发送18x消息,被叫用户终端应答后,服务器会向主叫用户终端发送200消息,并等待主叫用户终端返回针对该200消息的ACK消息,18x消息代表180到189之间的任意一条消息。也就是说,在收到ACK消息之前服务器可以向主叫用户终端发送多条检测请求消息并接收到多条检测响应消息,并在收到ACK消息之后还有可能收到检测响应消息,图3中仅画出了第一次向主叫用户终端发送检测请求消息并接收到相应的检测响应消息的内容,但不限定于此。具体地,服务器构造并发送检测请求消息,并开始计时;如果在计时达到预设时间之前收到检测响应消息,且还未收到针对200消息的ACK消息,则构造并发送新的检测请求消息,并重新开始计时;如果在计时达到预设时间之前未收到检测响应消息,则在计时达到预设时间之后,再次发送与之前发送的检测请求消息相同的检测请求消息,并重新开始计时;如果重复发送的次数达到预设的最大重发次数后,仍然没有收到检测响应消息,则判定主叫用户终端发生异常。可选地,为了减少空口消息负荷,服务器可以设定在向主叫用户终端发送200消息之后首次发起检测请求消息。如果图3流程中的18x消息要求可靠性传送,则相应的流程会变成如图4所示,在主叫用户终端收到服务器发送的18x消息后,向服务器发送PRACK消息告知服务器18x消息已经收到了,服务器再向主叫用户终端返回PRACK消息的响应消息200。当然,呼叫接续流程还可能发生其他一些变化,但不管呼叫接续流程如何变化,检测请求消息的发送和等待检测响应消息的机制都同上述对图3的描述相类似,本发明实施例不再赘述。其中,上述计时功能可以由定时器完成,本发明实施例对此不作具体限定,例如可以是Timers。预设时间的长短可以根据不同的网络需求预先进行配置,建议以毫秒为单位。另外,最大重发次数也可以预先配置,例如配置为N,N为大于等于1的整数。204:如果检测到主叫用户终端发生异常,则拆除主叫用户终端到被叫用户终端的呼叫,并释放该呼叫的相关资源;具体地,服务器主动发起呼叫拆除,拆除主叫用户终端和被叫用户终端的本次呼叫,并释放本次呼叫的相关资源,比如占用的空口资源等等。205 记录拆除原因为检测到主叫用户终端发生异常,流程结束;具体地,记录下来的拆除原因可以供运营商查看,从而能够更具体地分析呼叫失败的原因。206:如果接收到主叫用户终端发送的ACK消息,或,接收到主叫用户终端或被叫用户终端发送的呼叫拆除消息,则停止检测。
7
停止检测可以具体包括停止计时,并将后续接收到的检测响应消息做丢弃处理。具体地,接收到针对200消息的ACK消息后,不管是否还有检测请求消息等待响应,都立刻停止检测定时器,后续如果收到检测响应消息则做丢弃处理;如果在收到针对 200消息的ACK消息前主叫用户终端或被叫用户终端发起了呼叫拆除,则立刻停止检测定时器,后续如果收到检测响应消息则做丢弃处理。需要说明的是,优选地,本发明实施例中的检测请求消息可以为RFC3261协议中定义的OPTIONS消息,检测响应消息为与OPTIONS消息对应的响应消息,其中,通过OPTIONS 消息和响应消息中的Transaction ID(事务号)来判断主叫用户终端返回的响应消息是否是针对OPTIONS消息的响应。OPTIONS消息是RFC3261协议中定义的用来查询用户终端或服务器能力的消息,所有的用户终端和服务器都支持OPTIONS消息。OPTIONS消息可以在对话内发送,也可以在对话外发送,且不影响原来的呼叫状态。RFC3261协议中规定,如果 OPTIONS消息没有收到响应,可以认为对应的用户终端不可达。服务器构造OPTIONS消息的原则和方式同RFC3^1协议的11. 1小节,可以不包含Acapt头域,以便减少响应消息的大小。主叫用户终端收到OPTIONS消息后,按RFC3261协议规定的处理方式进行响应。使用OPTIONS消息及其对应的响应消息作为检测请求消息和检测响应消息的好处是,利用现有的RFC3^1协议,所使用的消息和流程基于RFC3^1协议就可以实现,不需要新增消息和新元,并且所有用户终端都支持;使异常检测方法简单,利于实现,只需要服务器侧按照上述方法步骤进行修改即可。可选地,检测请求消息和检测响应消息也可以使用自定义的消息,或者还可以使用其他SIP消息,例如使用正在草案阶段的PING消息等。使用这些消息除了服务器侧需要修改外,用户终端侧也需要修改进而支持上述异常检测的方法。本发明实施例提供的方法,通过在呼叫接续过程中向主叫用户终端发送检测请求消息,并接收主叫用户终端返回的检测响应消息来检测主叫用户终端是否发生异常,能够及时检测到主叫用户终端的异常,并在检测到异常时及时拆除主叫用户终端到被叫用户终端的呼叫,释放该呼叫的相关资源,能够降低呼叫系统的开销,并能够提升被叫用户的感受,减少不必要的振铃,而且在跨局、跨运营商呼叫的情景下及时发现异常并拆除呼叫能够防止呼叫接续过程中的误计费;另外,拆除呼叫后记录拆除原因为检测到主叫用户终端发生异常,可以使运营商能够更具体地分析呼叫失败的原因。实施例三本发明实施例提供了一种服务器,该服务器是指可以向主叫用户终端发出的 ^vite消息提供服务并回送应答、并且能够执行实施例二中的方法步骤的任何服务器,本发明实施例对此不作具体限定,例如,可以是代理服务器(Proxy Server)或SIP服务器 (SIP krver),其中,SIP服务器又可以是IMS、NGN或其他能够完成服务器功能的网元。参见图5,该服务器包括检测模块501,用于在接收到主叫用户终端发送的hvite消息之后,检测主叫用户终端是否发生异常;拆除模块502,用于在检测模块501检测到主叫用户终端发生异常后,拆除主叫用户终端到被叫用户终端的呼叫,并释放呼叫的相关资源。可选地,参见图6,该服务器还包括
8
判断模块503,用于在检测模块501检测主叫用户终端是否发生异常之前,判断是否需要对主叫用户终端进行异常检测,如果需要,则执行检测模块501。进一步地,判断模块503,具体用于判断主叫用户终端发起的呼叫是否是局向呼叫,如果是,则需要对主叫用户终端进行异常检测;和/或,判断主叫用户终端是否是在无线网络下发起的呼叫,如果是,则需要对主叫用户终端进行异常检测。更进一步地,检测模块501,具体用于向主叫用户终端发送检测请求消息,并开始计时;如果在计时达到预设时间之前接收到主叫用户终端发送的检测响应消息,则向主叫用户终端发送新的检测请求消息,并重新开始计时;如果在计时达到预设时间之前没有接收到主叫用户终端发送的检测响应消息,则在计时达到预设时间之后,向主叫用户终端重复发送之前发送的检测请求消息,并重新开始计时;判断重复发送的次数是否达到预设的最大重发次数,如果是,则判定主叫用户终端发生异常。可选地,参见图7,该服务器还包括停止模块504,用于在检测模块501检测主叫用户终端是否发生异常之后,如果接收到主叫用户终端发送的ACK消息,或,接收到主叫用户终端或被叫用户终端发送的呼叫拆除消息,则停止检测。进一步地,停止模块504,具体用于停止计时,并将后续接收到的检测响应消息做丢弃处理。可选地,参见图8,该服务器还包括记录模块505,用于在拆除模块502释放呼叫的相关资源之后,记录拆除原因为检测到主叫用户终端发生异常。综上所述,本发明实施例通过在呼叫接续过程中向主叫用户终端发送检测请求消息,并接收主叫用户终端返回的检测响应消息来检测主叫用户终端是否发生异常,能够及时检测到主叫用户终端的异常,并在检测到异常时及时拆除主叫用户终端到被叫用户终端的呼叫,释放该呼叫的相关资源,能够降低呼叫系统的开销,并能够提升被叫用户的感受, 减少不必要的振铃,而且在跨局、跨运营商呼叫的情景下及时发现异常并拆除呼叫能够防止呼叫接续过程中的误计费;另外,拆除呼叫后记录拆除原因为检测到主叫用户终端发生异常,可以使运营商能够更具体地分析呼叫失败的原因。需要说明的是上述实施例提供的服务器在处理呼叫接续过程中的异常时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将服务器的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的服务器与呼叫接续过程中的异常处理方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
权利要求
1.一种呼叫接续过程中的异常处理方法,其特征在于,所述方法包括在接收到主叫用户终端发送的呼叫请求消息之后,检测所述主叫用户终端是否发生异常;如果检测到所述主叫用户终端发生异常,则拆除所述主叫用户终端到被叫用户终端的呼叫,并释放所述呼叫的相关资源。
2.根据权利要求1所述的方法,其特征在于,检测所述主叫用户终端是否发生异常之前,还包括判断是否需要对所述主叫用户终端进行异常检测,如果需要,则执行所述检测所述主叫用户终端是否发生异常的步骤。
3.根据权利要求2所述的方法,其特征在于,判断是否需要对所述主叫用户终端进行异常检测,包括判断所述主叫用户终端发起的呼叫是否是局向呼叫,如果是,则需要对所述主叫用户终端进行异常检测;和/或判断所述主叫用户终端是否是在无线网络下发起的呼叫,如果是,则需要对所述主叫用户终端进行异常检测。
4.根据权利要求1所述的方法,其特征在于,检测所述主叫用户终端是否发生异常,包括向所述主叫用户终端发送检测请求消息,并开始计时;如果在计时达到预设时间之前接收到所述主叫用户终端发送的检测响应消息,则向所述主叫用户终端发送新的检测请求消息,并重新开始计时;如果在计时达到预设时间之前没有接收到所述主叫用户终端发送的检测响应消息,则在计时达到预设时间之后,向所述主叫用户终端重复发送之前发送的检测请求消息,并重新开始计时;判断所述重复发送的次数是否达到预设的最大重发次数,如果是,则判定所述主叫用户终端发生异常。
5.根据权利要求4所述的方法,其特征在于,所述检测请求消息为RFC3^1协议中定义的OPTIONS消息,所述检测响应消息为与所述OPTIONS消息对应的响应消息。
6.根据权利要求4或权利要求5所述的方法,其特征在于,检测所述主叫用户终端是否发生异常之后,还包括如果接收到所述主叫用户终端发送的确认消息,或,接收到所述主叫用户终端或被叫用户终端发送的呼叫拆除消息,则停止检测。
7.根据权利要求6所述的方法,其特征在于,停止检测,包括 停止计时,并将后续接收到的检测响应消息做丢弃处理。
8.根据权利要求1所述的方法,其特征在于,释放所述呼叫的相关资源之后,还包括 记录拆除原因为检测到所述主叫用户终端发生异常。
9.一种服务器,其特征在于,所述服务器包括检测模块,用于在接收到主叫用户终端发送的呼叫请求消息之后,检测所述主叫用户终端是否发生异常;拆除模块,用于在所述检测模块检测到所述主叫用户终端发生异常后,拆除所述主叫用户终端到被叫用户终端的呼叫,并释放所述呼叫的相关资源。
10.根据权利要求9所述的服务器,其特征在于,所述服务器还包括 判断模块,用于在所述检测模块检测所述主叫用户终端是否发生异常之前,判断是否需要对所述主叫用户终端进行异常检测,如果需要,则执行所述检测模块。
11.根据权利要求10所述的服务器,其特征在于,所述判断模块,具体用于判断所述主叫用户终端发起的呼叫是否是局向呼叫,如果是,则需要对所述主叫用户终端进行异常检测;和/或,判断所述主叫用户终端是否是在无线网络下发起的呼叫,如果是,则需要对所述主叫用户终端进行异常检测。
12.根据权利要求9所述的服务器,其特征在于,所述检测模块,具体用于向所述主叫用户终端发送检测请求消息,并开始计时;如果在计时达到预设时间之前接收到所述主叫用户终端发送的检测响应消息,则向所述主叫用户终端发送新的检测请求消息,并重新开始计时;如果在计时达到预设时间之前没有接收到所述主叫用户终端发送的检测响应消息,则在计时达到预设时间之后,向所述主叫用户终端重复发送之前发送的检测请求消息, 并重新开始计时;判断所述重复发送的次数是否达到预设的最大重发次数,如果是,则判定所述主叫用户终端发生异常。
13.根据权利要求12所述的服务器,其特征在于,所述服务器还包括停止模块,用于在所述检测模块检测所述主叫用户终端是否发生异常之后,如果接收到所述主叫用户终端发送的确认消息,或,接收到所述主叫用户终端或被叫用户终端发送的呼叫拆除消息,则停止检测。
14.根据权利要求13所述的服务器,其特征在于,所述停止模块,具体用于停止计时, 并将后续接收到的检测响应消息做丢弃处理。
15.根据权利要求9所述的服务器,其特征在于,所述服务器还包括记录模块,用于在所述拆除模块释放所述呼叫的相关资源之后,记录拆除原因为检测到所述主叫用户终端发生异常。
全文摘要
本发明实施例提供了一种呼叫接续过程中的异常处理方法及服务器,涉及通信领域,所述方法包括在接收到主叫用户终端发送的呼叫请求消息之后,检测所述主叫用户终端是否发生异常;如果检测到所述主叫用户终端发生异常,则拆除所述主叫用户终端到被叫用户终端的呼叫,并释放所述呼叫的相关资源。本发明通过在呼叫接续过程中检测主叫用户终端是否发生异常,并在检测到主叫用户终端发生异常时及时拆除主叫用户终端到被叫用户终端的呼叫,释放该呼叫的相关资源,能够降低呼叫系统的开销,并能够提升被叫用户的感受,减少不必要的振铃,而且在跨局、跨运营商呼叫的情景下及时发现异常并拆除呼叫能够防止呼叫接续过程中的误计费。
文档编号H04L12/24GK102439906SQ201180002366
公开日2012年5月2日 申请日期2011年10月27日 优先权日2011年10月27日
发明者黄路明 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1