一种ims系统中的信令处理方法、装置和相关设备的制造方法
【专利摘要】本发明公开了一种IP多媒体子系统(IP Multimedia Subsystem，IMS)中的信令处理方法、装置和相关设备，用以提供一种两个通信设备之间处理交互信令的容错机制，提高会话建立的成功率。IMS系统中的信令处理方法，包括：信令处理装置在信令处理过程中接收到非预期信令时缓存所述非预期信令并启动定时器；如果在所述定时器超时之前接收到预期信令，则所述信令处理装置处理所述预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。
【专利说明】
一种IMS系统中的信令处理方法、装置和相关设备
技术领域
[0001]本发明涉及IMS(IP Multimedia Subsystem，IP多媒体系统)技术领域，尤其涉及一种IMS系统中的信令处理方法和相关设备。
【背景技术】
[0002]IMS是3GPP(3rd Generat1n Partnership Project，第三代合作伙伴计划)在R5中提出的一个全新的IP多媒体子系统，是在PS ((Packet Switch,分组)域基础上扩展的移动核心网络，能够在IP多媒体平台上支持多媒体业务和互联网应用。
[0003]VoLTE(Voice-over-LTE),即高清通话是一种 LTE(Long Term Evolut1n,长期演进)下的解决语音通话的方案，其采用IP数据传输技术，与目前的CSFB(CircuitSwitched Fallback,电路域回落)语音回落2G/3G的通话有着本质性的不同。在支持LTE的MME (Mobility Management Entity，移动性管理实体)下，VoLTE终端将实现语音等媒体包全部在4G网络上进行传输，从而实现数据与语音业务在同一网络下的统一传输。
[0004]SIP (Sess1n Initiat1n Protocol，会话发起协议)是一个面向 Internet 会议和电话的简单信令协议标准，它最初由IETF MMUSIC (Multiparty Multimedia Sess1nControl)工作组提出。頂S采用SIP作为核心控制协议，使用SIP为所有的业务提供统一的会话控制机制。SIP与HTTP (Hypertext transfer protocol，超文本传送协议)和SMTP (Simple Mail Transfer Protocol，简单邮件传输协议)是类似的，都是基于文本的协议，它用于用户间建立和配置交互式通信会议(如:语音、图象、文件传输、交互游戏、虚拟现实等)。
[0005]VoLTE终端在頂S系统中发起语音、视频呼叫的业务时，终端和网络将按照规范规定的SIP信令进行信令协商和流程交互过程。
[0006]主叫(MobileOriginat1n CalI,MO)和被叫(Mobile Terminat1n CalI,MT)终端进行正常呼叫流程的信令交互过程如图1所示。
[0007]MO侧用户拨打被叫用户电话，MO将首先发送出Invite消息，经过网络侧转发处理后到达MT侧；网络侧将Invite转发到MT侧后，将向MO发送临时响应消息lOOTrying，MO侧收到临时响应10Trying消息后，MO侧将默认MT已经成功收到Invite消息，进而MT侧将发送180Ringing振铃消息。
[0008]MO在收到网络侧转发的ISORinging消息后，进行振铃提示被叫电话已经拨通，等待MT接听；在MT接听电话的同时，发送2000K消息，此消息经过网络转发最终到达MO侧；MO收到2000K消息时回复ACK确认消息，此时MO、MT两用户之间的通话通道正式建立；当MO主动挂机结束本次通话时，MO将发送BYE消息；经过网络各网元的传输，当MT接收到BYE消息时，MT将知道MO已经挂机，此时MT回复2000K，即同意结束此通电话；当MO收到MT发送的2000K消息之后，MO和MT在收到网络侧发送的拆链消息后，终端侧将释放已经建立的信令、语音、视频等承载资源。
[0009]当终端侧和网络侧同时支持资源预留协商pre-condit1n功能时，MO要建立语音或者视频通话时，MO、MT终端将通过网络交互，提前协商并预留端到端进行语音、视频等传输的网络资源，在资源没有预留成功前MT侧不会发送ISORinging消息。
[0010]如图2所示，为两个VoLTE终端通过网络进行视频呼叫业务的基本信令流程交互示意图(两用户在建立语音呼叫时，与视频呼叫的差别为仅建立一条QCI = I的语音承载)。首先，MO发起会话，主动发送Invite消息，其中将携带MO侧支持的语音、视频编解码格式，以及申请的语音和视频资源带宽，还携带了当前MO本端的QoS状态为非sendrecv (inactive，非激活状态，不发送也不接收处理媒体包);网络在收到MO发送的Invite消息之后，开始分别向MO、MT发送专有承载的建链请求，并等待MO、MT给予建链成功的回复。
[0011]网络侧将Invite转发到MT侧之后，向MO发送临时响应消息10Trying ;当MO收到10Trying时，MO将认为MT确认收到Invite消息，并且正在处理此消息和正在执行的会话进程；此时MT将发送临时响应183Sess1n Progress (SDP)消息，其中MT将携带根据设备自身支持的以及MO支持的编解码形式协商的期望使用的语音、视频编码格式，该编码方式必须是双方都支持的语音、视频编码格式。
[0012]此时，MO在确认收到MT发送的183消息后，MO将发送PRACK消息；MT收到PRACK消息后回复2000K(for PRACK);当MO收到2000K(for PRACK)后，并且语音QCI = 1、视频QCI = 2的专有承载建立完成之后，MO将发送UPDATE (状态更新)消息，其中更新MO本端状态为sendrecv (可发送，可接收媒体包)，此时MO侧不仅可以发送语音、视频的媒体流，同时也可以接收处理语音、视频的媒体流；MT收到UPDATE后，如果QCI = I的语音承载、QCI=2的视频专有承载建立成功后，MT侧将回复2000K (for update)，同时携带MT本端的QoS状态为sendrecv，即此时MT侧将告知网络和MO侧，它不仅可以支持发送，而且也可以接收语音、视频的媒体流，此时，MO、MT两端QoS转态都变为sendrecv，既可以发送又可以接收，这表明主叫、被叫两终端的状态都已经由inactive状态更新为sendrecv状态。MT在完成状态变更之后，MT侧发送ISORinging振铃消息，MO收到后进行振铃提示。
[0013]此时，当MT用户接听本次呼叫时，MT将发送2000K (for Invite)，经过网络侧处理转发给MO ；M0收到2000K(for Invite)将确认MT侧正确处理并完成了呼叫交流的交互过程，MO将回复ACK消息，即向网络、MT明确已经收到2000K(for Invite)。此时，MO和MT之间的会话正式建立。最后，当MO、MT通话结束时，如果MO主动挂机结束本次会话，MO将主动发送BYE消息，MT收到此消息后回复2000K同意结束此次会话过程。
[0014]其中，MO终端和MT终端之间交互的信令在网络侧的处理主要涉及包括SBC ((Sess1n Border Control, )、P-GW (Packet work Gateway,分组数据网关)，P-CSCF(Proxy Call Sess1n Control Funct1n，代理呼叫会话控制功能实体)等核心网网元。
[0015]根据规范规定，MO只有在收到MT发送的2000K(for update)之后，才可以明确Μ0、ΜΤ两终端状态都已经由inactive状态(不发送不接收媒体包)更新为sendrecv状态(可发送可接收媒体包)。此时，MO将启动设备中的音频、视频媒体流的发送、接收处理机制。但是实际应用中，可能出现以下情况:
[0016](一)现有技术方案中，当MO发送UPDATE消息之后，将等待接收MT侧发送的响应消息2000K(for update)。网络在传输MT发送的2000K (for update)消息的过程中，如果因SBC、P-Gff, P-CSCF等不同网元的传输、处理时延较大，或者因SBC、P-Gff, P-CSCF等不同网元在传输过程中IP包丢失等一系列问题，导致MO侧未成功接收到MT发送的2000K(forupdate)消息。如果MO侧未及时收到2000K(for update)，将影响到MO侧会话资源的协商和状态的变更，最终影响到整个会话进程信令的协商和媒体资源的处理及传输。
[0017]( 二)根据SIP协议规定，如图2所示，MT侧先发送的2000K(for update)，再发送180Ringing消息。经过网络侧处理和转发后，MO侧应该先收到2000K (for update)，再收到180Ringing消息。
[0018]如果因为网络中各网元传输时延、处理滞后等原因，导致在时间顺序上180Ringing消息会先于2000K(for update)到达MO侧。此时，终端侧因收到非预期信令，将可能产生以下两种非预期的结果:(I)MO终端侧正在进行的资源协商和预留进程将会被无故打断；(2)MO会将先收到180Ringing消息作为非预期信令进行丢弃处理。
[0019](I)MO侧正在进行的资源协商和预留进程将会被无故打断
[0020]此场景下，MO因为收到的信令顺序并不符合规范的信令交互流程，从而将会导致资源协商及预留失败，最终本次会话以失败告终。
[0021]另外，在定时器未超时之前MO仍有可能收到2000K(for update)，但是MO设备自身因为正在进行的进程已经被ISORinging消息打断，将无法完成自身状态的更新过程，从而使得MO侧媒体处理能力不能及时更新，无法完成音频、视频媒体流的发送、处理，以及音频播放和视频显示功能。
[0022]终端侧的会话媒体传输和处理机制将不能按照预期正常开启，继而无法完成本地语音、视频媒体流的发送，同时也无法处理MT侧传输过来的语音、视频媒体流，从而导致语音电话单向或者双向无声、视频电话单向或者双向无图像的现象出现，从而影响用户正常感知和体验效果。
[0023](2)MO侧因接收到非预期信令而丢弃非预期信令
[0024]如果MT按照正确的顺序先发出2000K (for update),然后再发送180Ringing消息，但是因为网络网元时延等各种原因导致MO在等待2000K(for update)消息时，先收到了 180Ringing消息。此时，由于终端侧正在进行一个会话资源协商进程，180Ringing的突然到达将会打断正在进行的进程，MO终端侧为保证正在进行的进程正常执行，MO有可能先将此消息直接丢弃。如果在此种场景下，MO在定时器超时之前收到2000K(for update) ,MO一侧则将因为已经丢弃之前的ISORinging振铃消息，而在电话接通后无法听到振铃音，直接进入会话接听模式，使MO在电话接通时无法通过振铃音第一时间提示用户，这在一定程度上将影响到MO用户的会话体验效果。
[0025]由此可见，如何处理由于核心网网元处理信息时延较大或者因核心网网元在传输过程中IP包丢失等引起的信令丢失或者信令乱序等一系列问题，进而导致MO终端和MT终端无法成功建立会话成为现有技术亟待解决的技术问题之一。
【发明内容】
[0026]本发明实施例提供一种IMS系统中的信令处理方法和相关设备，用以提供一种两个通信设备之间交互信令处理的容错机制，提高会话建立的成功率。
[0027]本发明实施例提供一种頂S系统中的信令处理方法，包括:
[0028]信令处理装置在信令处理过程中接收到非预期信令时，缓存所述非预期信令并启动定时器；
[0029]如果在所述定时器超时之前接收到预期信令，则所述信令处理装置处理所述预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。
[0030]所述信令处理装置设置于终端设备中或者核心网设备中。
[0031]所述方法，还包括:
[0032]如果在所述定时器超时之前未接收到预期信令，则所述信令处理装置丢弃已缓存的非预期信令；并
[0033]终止会话建立流程。
[0034]所述方法，还包括:
[0035]提示是否重新发起会话建立流程。
[0036]本发明实施例提供一种信令处理装置，包括:
[0037]定时器管理单元，用于在信令处理过程中接收到非预期信令时，启动定时器；
[0038]缓存单元，用于在信令处理过程中接收到非预期信令时，缓存所述非预期信令；
[0039]信令处理单元，用于如果在所述定时器超时之前接收到预期信令，则在处理所述预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。
[0040]所述装置，还包括会话终止单元，其中:
[0041]所述信令处理单元，还用于如果在所述定时器超时之前未接收到预期信令，则所述信令处理装置丢弃已缓存的非预期信令；
[0042]所述会话终止单元，用于终止会话建立流程。
[0043]所述装置，还包括:
[0044]提示单元，用于提示主叫MO设备是否重新发起会话建立流程。
[0045]一种终端，包括上述的信令处理装置。
[0046]一种核心网设备，包括上述的信令处理装置。
[0047]本发明实施例提供的頂S系统中的信令处理方法、装置和相关设备，在接收到非预期信令时，先缓存非预期信令并启动定时器等待预期信令的到达，如果在定时器超时之前，接收到预期信令，则优先处理接收到的预期信令后，再从缓存中按照预设信令处理流程依次提取非预期信令并进行处理，使得当前的会话建立流程能够被继续处理，提高会话建立的成功率。
[0048]本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
【附图说明】
[0049]此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中:
[0050]图1为现有技术中，非pre-condit1n情况下，MO设备与MT设备建立语音会话的流程示意图；
[0051]图2为现有技术中，当终端及网络的pre-condit1n功能同时开启时，MO设备与MT设备建立视频会话的流程示意图；
[0052]图3为本发明实施例中，頂S系统中针对非预期信令采用容错机制的信令处理方法的实施流程示意图；
[0053]图4为本发明实施例中，网络侧的P-CSCF设备针对非预期信令采用容错机制实施信令处理方法的第一种实施流程示意图；
[0054]图5为本发明实施例中，网络侧的P-CSCF设备针对非预期信令采用容错机制实施信令处理方法的第二种实施流程示意图；
[0055]图6为本发明实施例中，MO终端实施信令处理方法的第一种实施流程示意图；
[0056]图7为本发明实施例中，MO终端实施信令处理方法的第二种实施流程示意图；
[0057]图8为本发明实施例中，MO终端实施信令处理方法的第三种实施流程示意图；
[0058]图9为本发明实施例中，信令处理装置的结构示意图。
【具体实施方式】
[0059]为了避免頂S系统中因网络SBC、P-Gff, P-CSCF等网元的传输、处理时延较大，或者因SBC、P-Gff, P-CSCF等网元在传输过程中IP数据包丢失等导致通信终端在建立通信连接过程中接收到非预期信令，例如上述的MO终端在发送(或者MO侧网络设备在转发)Update (状态更新)消息后，先接收到ISORinging消息，再接收到MT侧发送的、经过网络侧转发的2000K(for update)消息，造成MO侧由于接收到乱序的信令而导致頂S系统中会话建立失败的问题，本发明实施例提供一种頂S系统中非预期信令处理的容错机制，提高頂S系统中会话建立的成功率。
[0060]以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。
[0061]如图3所示，为本发明实施例提供的IMS系统中针对非预期信令采用容错机制的信令处理方法的实施流程示意图，可以包括以下步骤:
[0062]S31、信令处理装置在信令处理过程中接收到非预期信令时，缓存接收到的非预期信令并启动定时器。
[0063]其中，信令处理装置可以设置在终端设备(包括MO设备和MT设备)中或者核心网设备中。为了便于描述，以下实施例中均以信令处理装置设置于MO设备中为例，当信令处理装置设置于MT设备或者核心网设备中时，其信令处理流程与信令处理装置设置于MO设备中类似，这里不再一一赘述。
[0064]具体实施时，信令处理装置在按照预设的信令处理流程处理接收到的信令时，为了便于描述，将其当前等待处理的信令称为预期信令，将当前接收到的、除预期信令以外的其他信令称为非预期信令。
[0065]例如，MO设备在发送了 Update消息之后，按照图2所示的信令处理流程可知，其在当前等待处理的预期信令为MT设备发送的2000K (for update)，则MT设备发送的2000K(for update)消息即为预期信令，而除MT设备发送的2000K(for update)消息以外的其他信令均为非预期信令。例如，在等待期间接收到了 ISORinging消息，则称180Ringing消息为非预期信令。
[0066]MO终端设备在接收到非预期信令时，缓存接收到的非预期信令，同时启动定时器，定时器时长可以根据实际需要进行设置，本发明实施例对此不做限定。例如，可以但不限于将定时器设置为6s。如果信令处理装置接收到ISORinging消息，则先缓存接收到的180Ringing 消息。
[0067]S32、如果在定时器超时之前接收到预期信令，则信令处理装置处理预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。
[0068]延续上例，如果在定时器超时之前接收到2000K (for update)，则信令处理装置首先处理2000K(for update)，再从缓存中提取180Ringing消息进行处理。需要说明的是，如果缓存的非预期信令有多条时，则信令处理装置，按照信令处理流程中需要处理的信令顺序从缓存中依次提取信令并进行处理。
[0069]较佳的，如果在定时器超时之前未接收到预期信令，则信令处理装置丢弃已缓存的非预期信令，并发起终止会话建立流程的操作。更佳的，在终止了当前会话建立流程操作之后，还可以提示MO设备是否重新发起会话建立流程。
[0070]以下分别以网络侧的P-CSCF设备和MO设备实施本发明实施例提供的信令处理方法的流程对本发明实施例的具体实施过程进行说明。
[0071](一 )网络侧实施信令处理方法的流程
[0072]网络侧的信令非预期信令处理主要在网络的P-CSCF网元处实现。如图4所示，首先，MO设备发起会话，主动发送Invite消息，其中将携带MO设备支持的语音、视频编解码格式，以及申请的语音和视频资源带宽，还携带了当前MO设备本端的QoS状态为非sendrecv ；网络在收到MO设备发送的Invite消息之后，开始分别向MO设备、MT设备发送专有承载的建链请求，并等待MO设备、MT设备给予建链成功的回复。
[0073]网络侧将Invite转发到MT设备之后，向MO设备发送临时响应消息10Trying ;当MO设备收到10Trying时，MO设备将认为MT设备确认收到Invite消息，并且正在处理此消息和正在执行的会话进程；此时MT设备将发送临时响应183Sess1n Progress (SDP)消息，其中MT设备将携带根据设备自身支持的以及MO支持的编解码形式协商的期望使用的语音、视频编码格式，该编码方式必须是双方都支持的语音、视频编码格式。
[0074]此时，MO设备在确认收到MT发送的183消息后，MO设备将发送PRACK消息；MT设备收到PRACK消息后回复2000K(for PRACK);当MO设备收到2000K(for PRACK)后，并且语音QCI = 1、视频QCI = 2的专有承载建立完成之后，根据正常会话的SIP信令流程，MO设备将发送UPDATE (状态更新)消息，当MO设备在发出Update消息之后，网络侧P-CSCF在收到Update消息后，等待MT设备发送的2000K (for update)到达P-CSCF。
[0075]如果P-CSCF先收到MT设备发送的180Ringing振铃消息，此场景下，P-CSCF网元将缓存收到的180Ringing消息并启动定时器Tl，等接收到MT发送的2000K(for update)消息后，优先将2000K(for update)转发给MO设备，然后再发送缓存的180Ringing消息给MO设备，从而实现网络中P-CSCF网元对非预期信令的容错修正。
[0076]如果在定时器Tl超时之前，P-CSCF始终未收到MT设备发送的2000K(for update)消息。如图5所示，P-CSCF将分别向MO设备、MT设备发送Cancel消息，终止本次会话协商流程。MO设备、MT设备在收到Cancel消息后，回复2000K确认收到本消息。图5中，MO设备发送Update之前的信令处理与图4中相同，这里不再赘述。
[0077]( 二)终端设备实施信令处理方法的流程
[0078]如图6所示(图6中未示出网络侧设备，实际应用中MO设备和MT设备之间的交互信息需要通过网络设备转发)，首先，MO设备发起会话，主动发送Invite消息，其中将携带MO设备支持的语音、视频编解码格式，以及申请的语音和视频资源带宽，还携带了当前MO设备本端的QoS状态为非sendrecv ;网络在收到MO设备发送的Invite消息之后，开始分别向MO设备、MT设备发送专有承载的建链请求，并等待MO设备、MT设备给予建链成功的回复。
[0079]网络侧将Invite转发到MT设备之后，向MO设备发送临时响应消息10Trying ;当MO设备收到10Trying时，MO设备将认为MT设备确认收到Invite消息，并且正在处理此消息和正在执行的会话进程；此时MT设备将发送临时响应183Sess1n Progress (SDP)消息，其中MT设备将携带根据设备自身支持的以及MO设备支持的编解码形式协商的期望使用的语音、视频编码格式，该编码方式必须是双方都支持的语音、视频编码格式。
[0080]此时，MO设备在确认收到MT设备发送的183消息后，MO设备将发送PRACK消息；MT设备收到PRACK消息后回复2000K(for PRACK);当MO设备收到2000K(for PRACK)后，并且语音QCI = 1、视频QCI = 2的专有承载建立完成之后，根据正常会话的SIP信令流程，MO设备将发送UPDATE (状态更新)消息。当MT设备发送的2000K(for update)消息，因为网络时延、丢包等问题，某些SIP信令未按照预期的顺序和时间到达MO设备的时候，MO设备将无法正确的完成端到端的会话资源协商和预留过程，从而导致端到端会话的建立失败，影响语音、视频等业务的正常进行和用户的体验。
[0081]为了解决上述问题，本发明实施例中，当终端侧发送Update消息之后，MO设备等待MT侧发送的2000K(for update)消息的到达，如果MO设备先收到了除2000K(forupdate)之外的其它信令(例如180Ringing消息)，M0设备将此信令缓存在设备内并启动定时器T，继续等待2000K(for update)的到达。如果在T超时之前，MO始终未收到MT设备发送的2000K(for update)消息，MO将之前收到并缓存的信令进行丢弃，且在MO设备侧结束正在执行的会话流程。与此同时，MO将向MT侧发送Cancel，通知MT设备侧结束正在进行的会话协商进程，如图7所示。
[0082]除此之外，MO设备将提示用户选择是否再次发起会话建立流程，如果用户选择不再发起会话建立流程，终端将进入空闲态；如果用户点击重新发起会话建立流程，MO设备将再次发起Invite消息，再次与网络、对端MT设备进行会话资源的协商和交互过程。
[0083]如果在T超时之前，MO成功收到MT侧发送的2000K(for update)消息。MO将首先处理正在进行的资源协商及预留进程，完成MO设备的状态由inactive更新为sendrecv的过程。然后，MO设备将调用之前收到并缓存的信令进行对应流程的处理。例如，MO设备先收到180Ringing，然后才收到2000K(for update)消息。那么MO设备在收到180Ringing消息后，将此消息缓存在MO设备并启动定时器继续等待2000K(for update)消息。当在定时器超时之前MO设备接收到2000K(for update)消息后，MO将优先更新资源协商的状态信息，然后再调用缓存的ISORinging消息，根据网络侧AS (应用服务器)放音或者终端侧自己放音提示用户。
[0084]基于此，本发明实施例中，MO设备在发送了 Update信令后，可以按照图8所示的流程进行信令处理，包括以下步骤:
[0085]S81、MO 设备发送 Update 信令。
[0086]具体实施时，MO设备在发送Update信令后等待MT设备发送的2000K (forupdate)。
[0087]S82、MO设备接收到网络侧转发的信令。
[0088]S83、MO设备判断接收到的信令是否为预期信令，如果是，执行步骤S84，否则，执行步骤S85。
[0089]本例中，终端等待接收的预期信令为2000K(for update)消息，MO设备判断接收到的信令是否为2000K(for update)消息。
[0090]S84、MO设备按照正确的信令流程通过网络与MT进行信令交互。
[0091]S85、MO设备缓存接收到的信令并启动定时器。
[0092]S86、MO设备判断在定时器超时之前是否接收到预期信令，如果是，执行步骤S87，否则执行步骤S88。
[0093]S87、M0设备处理接收到的预期信令后，再按照信令处理顺序依次调用缓存中缓存的信令并处理，流程结束。
[0094]S88、MO设备丢弃缓存的信令。
[0095]S89、MO设备提示用户是否重新发起会话流程，如果是，执行步骤S810，否则，执行步骤S811。
[0096]S810、重新触发执行会话建立流程，流程结束。
[0097]S811、终止当前的会话建立流程。
[0098]本发明实施例中，在网络侧核心网设备或者MO设备或者MT设备在接收到非预期信令时，设置等待预期信令的定时器，如果在定时器超时之前未接收到预期信令，网络侧核心网设备或者MO设备将主动发送Cancel消息，结束该异常会话流程，从而保证会话互通的正常协商过程。对于在定时器有效期间，核心网设备或者MO设备接收到的非预期信令，则先缓存该信令，并继续等待预期信令，如果在定时器超时之前接收到预期信令，则在对预期信令进行处理之后，再按照信令处理流程依次提取缓存中缓存的信令并进行处理，由此提高了设备的容错能力，而且提高了会话建立等业务的成功率。
[0099]本发明实施例提供的頂S系统中的信令处理方法，可以成功避免:因网络侧SBC、P-Gff, P-CSCF等不同网元设备的信令处理、传输时延导致信令到达终端侧的顺序不符合预期顺序，致使终端侧的媒体发送、处理机制将不能成功的完成状态的变更，或者某些信令因乱序而丢失的问题。譬如:M0侧因先接收到ISORinging消息，致使正在等待MT侧发送的2000K(for update)消息的进程被打断，从而MO侧状态协商失败，无法正常发送语音、视频媒体流和接收处理MT发送过来的语音、视频媒体流；或者MO在等待MT侧发送的2000K(forupdate)消息时，先收到非预期信令180Ringing而主动丢弃，从而导致后期会话成功建立后，缺少振铃首提不。
[0100]网络侧P-CSCF设备通过实施本发明实施例提供的信令处理方法，成功的规避了因SIP信令乱序造成的呼叫等业务失败，在一定程度上解决了因信令乱序导致的语音和视频呼叫失败问题，提高了互通成功率。
[0101]终端侧通过实施本发明实施例提供的信令处理方法，在定时器超时前，MO设备如果始终未收到预期信令，将提示用户是否重新发起该流程，再次与网络、对端终端发起协商和交互流程。使用户在使用的过程中，能够感知呼叫失败，并合理化的提示用户是否再次发起会话建立流程，增强了用户体验和用户感知。
[0102]基于同一发明构思，本发明实施例中还提供了一种頂S系统中的信令处理装置和终端及核心网设备，由于上述装置及设备解决问题的原理与MS系统中的信令处理方法相似，因此上述装置及设备的实施可以参见方法的实施，重复之处不再赘述。
[0103]如图9所示，为本发明实施例提供的頂S系统中的信令处理装置的结构示意图，包括:
[0104]定时器管理单元91，用于在信令处理过程中接收到非预期信令时，启动定时器；
[0105]缓存单元92，用于信令处理过程中接收到非预期信令时，缓存所述非预期信令；
[0106]信令处理单元93，用于如果在所述定时器超时之前接收到预期信令，则所述信令处理装置处理所述预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。
[0107]本发明实施例提供的頂S系统中的信令处理装置，还包括会话终止单元，其中:
[0108]所述信令处理单元，还用于如果在所述定时器超时之前未接收到预期信令，则丢弃已缓存的非预期信令；
[0109]所述会话终止单元，用于终止会话建立流程。
[0110]本发明实施例提供的頂S系统中的信令处理装置，还包括提示单元，用于提示是否重新发起会话建立流程。
[0111]为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。
[0112]具体实施时，上述頂S系统中的信令处理装置可以设置于终端设备或者核心网设备中。
[0113]本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
[0114]本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0115]这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0116]这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0117]尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
[0118]显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
【主权项】
1.一种頂S系统中的信令处理方法，其特征在于，包括: 信令处理装置在信令处理过程中接收到非预期信令时，缓存所述非预期信令并启动定时器； 如果在所述定时器超时之前接收到预期信令，则所述信令处理装置处理所述预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。2.如权利要求1所述的方法，其特征在于，所述信令处理装置设置于终端设备中或者核心网设备中。3.如权利要求1或2所述的方法，其特征在于，还包括: 如果在所述定时器超时之前未接收到预期信令，则所述信令处理装置丢弃已缓存的非预期信令；并 终止会话建立流程。4.如权利要求3所述的方法，其特征在于，还包括: 提示是否重新发起会话建立流程。5.一种頂S系统中的信令处理装置，其特征在于，包括: 定时器管理单元，用于在信令处理过程中接收到非预期信令时，启动定时器； 缓存单元，用于信令处理过程中接收到非预期信令时，缓存所述非预期信令； 信令处理单元，用于如果在所述定时器超时之前接收到预期信令，则在处理所述预期信令之后，按照预设信令处理流程依次从缓存中提取并处理接收到的非预期信令。6.如权利要求5所述的装置，其特征在于，还包括会话终止单元，其中: 所述信令处理单元，还用于如果在所述定时器超时之前未接收到预期信令，则丢弃已缓存的非预期信令； 所述会话终止单元，用于终止会话建立流程。7.如权利要求5或6所述的装置，其特征在于，还包括: 提示单元，用于提示是否重新发起会话建立流程。8.—种终端，其特征在于，包括权利要求5、6或7所述的信令处理装置。9.一种核心网设备，其特征在于，包括权利要求5、6或7所述的信令处理装置。
【文档编号】H04L1/00GK105991239SQ201510100597
【公开日】2016年10月5日
【申请日】2015年3月6日
【发明人】潘璐, 高晨亮, 王森, 王小旭
【申请人】中国移动通信集团公司