一种多方通话中的呼叫处理方法及装置与流程

本发明涉及通信技术领域，特别涉及一种多方通话中的呼叫处理方法及装置。

背景技术：

随着移动互联网的高速发展，通信服务不断的为用户提供新的空间，多方通话功能能够满足用户通信过程中多个用户同时交流的要求，目前，已有很多终端产品能够实现多方语音通话或者多方视频通话。

针对多方通话，根据3GPP TS24.147的定义，技术上已经可以通过统一资源标识符序列(Uniform Resource Identifier list，URI List)的方式一键发起一通多方通话，满足了用户快速发起多方通话的需求。但是，如果参与多方通话的所有被叫用户设备(User Equipment，UE)中，多个被叫UE均订购了不同的包含早期媒体的业务(如彩铃、包含提示音的补充业务等)，那么主叫UE听到的回铃音将会发生异常。例如，多个被叫UE订购了彩铃业务，那么在被叫UE振铃过程中，主叫UE就会同时听到多个彩铃的播放，从而严重影响主叫UE的体验。

参阅图1所示，以某一个被叫UE为例，现有的多方通话的简易流程如下：

步骤101：主叫UE向其归属的多方通话应用服务器(Application Server)AS发送INVITE消息，请求建立多方通话。

步骤102：多方通话AS为本次多方通话预留媒体资源。

步骤103：多方通话AS向主叫UE返回携带该媒体资源的200OK响应消息。

步骤104：多方通话AS向被叫UE转发该INVITE消息。

步骤105：被叫UE向多方通话AS返回携带早期媒体的18X消息。

由于之前主叫UE与多方通话AS之间已经建立了媒体流，因此多方通话AS会直接将早期媒体向主叫UE发送。

因此，如果多个被叫UE均返回携带早期媒体的18X消息，则主叫UE会同时接收到多个重叠的早期媒体，导致用户体验极差。

目前，已知的解决方案是主叫UE归属的多方通话AS接收到携带早期媒体的18X消息时，将该18X消息做信令解析，通过信令解析将该18X消息做缺省处理，即，媒体行置零，以使主叫UE仅收到单一的通话回铃音。

但上述解决方案涉及信令解析，对多方通话AS的性能要求较高，特别是用户量增大的时候可能导致多方通话AS崩溃。另外，对此类18X消息做缺省处理，从可靠性传输的角度来看，多方通话AS信令解析的处理将影响通话接听前可靠传输机制的响应消息的交互，无法满足可靠性传输的消息交互原则，与国际标准要求违背，对未来业务进行互联互通时提高了门槛。

综上所述，在多方通话过程中，当多个被叫UE同时发送早期媒体时，无法对早期媒体进行有效屏蔽，从而导致主叫UE业务使用发生异常，现有技术还没有有效的解决方案。

技术实现要素：

本发明实施例提供一种多方通话中的呼叫处理方法及装置，用以解决现有技术中存在的在多方通话过程中，当多个被叫UE同时发送早期媒体时，无法对早期媒体进行有效屏蔽，从而导致主叫UE业务使用发生异常的问题。

本发明实施例提供的具体技术方案如下：

一种多方通话中的呼叫处理方法，包括：

主叫用户设备UE归属的多方通话应用服务器AS在接收到主叫UE发送的多方通话请求后，为所述主叫UE预留第一媒体资源；

所述多方通话AS向本次多方通话对应的被叫UE发起呼叫；

所述多方通话AS接收所述被叫UE返回的携带早期媒体的183消息，为所述被叫UE预留第二媒体资源，其中，所述第二媒体资源与所述第一媒体资源不同；

所述多方通话AS接收所述被叫UE发送的用于指示振铃的180消息，基于所述第二媒体资源释放所述早期媒体。

较佳地，多方通话AS接收主叫UE发送的多方通话请求，为所述主叫UE预留第一媒体资源，具体包括：

所述多方通话AS接收主叫UE发送的用于请求建立多方通话的邀请INVITE消息，为所述主叫UE预留本次多方通话的第一媒体资源，其中，所述INVITE消息中携带URI List。

较佳地，所述多方通话AS向本次多方通话对应的被叫UE发起呼叫，具体包括：

所述多方通话AS根据所述INVITE消息中携带的URI List确定本次多方通话的被叫UE，并在所述INVITE消息中携带所述第一媒体资源后，向所述被叫UE转发所述INVITE消息。

较佳地，所述多方通话AS接收所述被叫UE返回的携带早期媒体的183消息，在再次接收到所述被叫UE发送的用于指示振铃的180消息之前，为所述被叫UE预留第二媒体资源，具体包括：

所述多方通话AS接收所述被叫UE返回的携带早期媒体的183消息，在再次接收到所述被叫UE发送的用于指示振铃的180消息之前，向所述被叫UE发送携带第二媒体资源的临时正确应答指令(provisional ACKnowledge，PRACK)消息，以及接收所述被叫UE反馈的确认消息。

较佳地，在为所述被叫UE预留第二媒体资源之后，在再次接收到所述被叫UE发送的用于指示振铃的180消息时，基于所述第二媒体资源释放所述早期媒体。

较佳地，进一步包括：

所述多方通话AS在接收到所述被叫UE发送的用于指示接听的200OK消息之前，接收所述被叫UE发送的携带所述第一媒体资源的Re-INVITE消息，并向所述被叫UE返回针对所述Re-INVITE消息的确认消息。

一种多方通话中的呼叫处理方法，包括：

被叫UE接收主叫UE归属的多方通话AS发起的呼叫，向所述多方通话AS返回携带早期媒体的183消息，其中，所述呼叫是所述多方通话AS在接收到主叫UE发送的多方通话请求，并为所述主叫UE预留第一媒体资源后，向所述被叫UE发送的；

所述被叫UE获取所述多方通话AS为所述被叫UE预留的第二媒体资源，其中，所述第二媒体资源是所述多方通话AS基于所述183消息为所述被叫UE预留的，且所述第二媒体资源与所述第一媒体资源不同；

所述被叫UE向所述多方通话AS发送用于指示振铃的180消息，以触发所述多方通话AS基于所述第二媒体资源释放所述早期媒体。

较佳地，所述被叫UE在接收到所述多方通话AS发起的呼叫后，将所述呼叫中携带的第一媒体资源进行保存。

较佳地，进一步包括：

所述被叫UE在向所述多方通话AS发送用于指示接听的200OK消息之前，向所述多方通话AS发送携带所述第一媒体资源的Re-INVITE消息，并接收所述多方通话AS返回针对所述Re-INVITE消息的确认消息。

较佳地，所述被叫UE获取所述多方通话AS为所述被叫UE预留的第二媒体资源，具体包括：

所述被叫UE接收所述多方通话AS发送的携带第二媒体资源的PRACK消息，并向所述多方通话AS返回针对所述PRACK消息的确认消息。

一种多方通话中的呼叫处理装置，包括：

媒体资源控制模块，用于在接收到主叫UE发送的多方通话请求后，为所述主叫UE预留第一媒体资源；

信令交互模块，用于向本次多方通话对应的被叫UE发起呼叫，以及接收所述被叫UE返回的携带早期媒体的183消息；

所述媒体资源控制模块，进一步用于为所述被叫UE预留第二媒体资源，其中，所述第二媒体资源与所述第一媒体资源不同；

早期媒体释放模块，用于在所述信令交互模块接收所述被叫UE发送的用于指示振铃的180消息后，基于所述第二媒体资源释放所述早期媒体。

较佳地，在接收主叫UE发送的多方通话请求，为所述主叫UE预留第一媒体资源时，所述信令交互模块具体用于，接收主叫UE发送的用于请求建立多方通话的INVITE消息；所述媒体资源控制模块具体用于，为所述主叫UE预留本次多方通话的第一媒体资源，其中，所述INVITE消息中携带URI List。

较佳地，在向本次多方通话对应的被叫UE发起呼叫时，所述信令交互模块具体用于：

所述多方通话AS根据所述INVITE消息中携带的URI List确定本次多方通话的被叫UE，并在所述INVITE消息中携带所述第一媒体资源后，向所述被叫UE转发所述INVITE消息。

较佳地，在所述信令交互模块接收所述被叫UE返回的携带早期媒体的183消息，在再次接收到所述被叫UE发送的用于指示振铃的180消息之前，在为所述被叫UE预留第二媒体资源时，所述媒体资源控制模块具体用于：

在所述信令交互模块接收所述被叫UE返回的携带早期媒体的183消息，在再次接收到所述被叫UE发送的用于指示振铃的180消息之前，向所述被叫UE发送携带第二媒体资源的PRACK消息，以及接收所述被叫UE反馈的确认消息。

较佳地，在为所述被叫UE预留第二媒体资源之后，在再次接收到所述被叫UE发送的用于指示振铃的180消息时，所述媒体资源控制模块进一步用于基于所述第二媒体资源释放所述早期媒体。

较佳地，所述信令交互模块进一步用于：

在接收到所述被叫UE发送的用于指示接听的200OK消息之前，接收所述被叫UE发送的携带所述第一媒体资源的Re-INVITE消息，并向所述被叫UE返回针对所述Re-INVITE消息的确认消息。

一种多方通话中的呼叫处理装置，包括：

第一收发模块，用于接收主叫UE归属的多方通话AS发起的呼叫，向所述多方通话AS返回携带早期媒体的183消息，其中，所述呼叫是所述多方通话AS在接收到主叫UE发送的多方通话请求，并为所述主叫UE预留第一媒体资源后，向本装置发送的；

资源获取模块，获取所述多方通话AS为本装置预留的第二媒体资源，其中，所述第二媒体资源是所述多方通话AS基于所述183消息为本装置预留的，且所述第二媒体资源与所述第一媒体资源不同；

第二收发模块，用于向所述多方通话AS发送用于指示振铃的180消息，以触发所述多方通话AS基于所述第二媒体资源释放所述早期媒体。

较佳地，所述第一收发模块具体用于：在接收到所述多方通话AS发起的呼叫后，将所述呼叫中携带的第一媒体资源进行保存。

较佳地，进一步包括：

第三收发模块：用于在向所述多方通话AS发送用于指示接听的200OK消息之前，向所述多方通话AS发送携带所述第一媒体资源的Re-INVITE消息，并接收所述多方通话AS返回针对所述Re-INVITE消息的确认消息。

较佳地，在获取所述多方通话AS为所述被叫UE预留的第二媒体资源时，所述资源获取模块具体用于：

接收所述多方通话AS发送的携带第二媒体资源的PRACK消息，并向所述多方通话AS返回针对所述PRACK消息的确认消息。

本发明实施例中，多方通话AS在接收到被叫UE发送的携带早期媒体的183消息后，向被叫UE发送携带与之前为主叫UE预留的媒体资源不同的其他媒体资源的PRACK消息，并接收被叫UE反馈的200OK响应，这样在被叫 UE振铃后，多方通话AS可基于上述其他媒体资源释放早期媒体，有效为主叫UE屏蔽所有的早期媒体，避免了在多个被叫UE均定制早期媒体的情况下，主叫UE同时接收到多个早期媒体的叠加信息，而造成主叫UE业务体验异常，同时降低了多方通话AS的放音处理负荷，并且，不需改变国际标准的信令流程，避免了由非标准信令流程和定制化的服务器处理能力对业务带来的弊端。

附图说明

图1为现有技术中多方通话的简易流程图；

图2为本发明实施例一多方通话中的呼叫处理流程图；

图3为本发明实施例二多方通话中的呼叫处理流程图；

图4为本发明实施例三主叫方发起多方通话的流程图；

图5为本发明实施例四多方通话AS与被叫UE之间的信令流程；

图6为本发明实施例五多方通话中的呼叫处理装置结构图；

图7为本发明实施例六多方通话中的呼叫处理装置结构图。

具体实施方式

针对现有技术中在多方通话过程中无法有效避免被叫UE的早期媒体的缺陷，本发明实施例中，主叫UE归属的多方通话AS在接收到主叫UE发送的多方通话请求时，为主叫UE预留第一媒体资源，并在接收到被叫UE发送的携带早期媒体的183消息时，为被叫UE预留与第一媒体资源不同的第二媒体资源，这样，在被叫UE振铃时，多方通话AS将基于第二媒体资源释放被叫UE的早期媒体，而不是基于第一媒体资源释放被叫UE的早期媒体，避免了多个被叫UE均基于第一媒体资源释放早期媒体而导致的主叫UE同时接收到多个不同的早期媒体，从而可有效屏蔽被叫UE的早期媒体，提升主叫UE的业务体验，并且不对多方通话AS造成过多的运行负担。

下面结合附图对本发明实施例优选的实施方案作详细说明。

实施例一、

参阅图2所示，本发明实施例一中，多方通话中的呼叫处理流程如下：

步骤200：主叫UE归属的多方通话AS在接收到主叫UE发送的多方通话请求后，为主叫UE预留第一媒体资源。

需要说明的是，在步骤200～步骤220中，为方便描述，将主叫UE归属的多方通话AS简称为多方通话AS。

实际应用中，多方通话AS接收主叫UE发送的用于请求建立多方通话的INVITE消息，为主叫UE预留本次多方通话的媒体资源(记为第一媒体资源)，并向主叫UE发送携带第一媒体资源的200OK消息，在接收到主叫UE返回的ACK消息后，多方通话AS与主叫UE建立媒体流，即，多方通话AS在后续过程中可直接向主叫UE播放彩铃等早期媒体。

其中，INVITE消息中携带URI List，多方通话AS可通过URI List确定本次多方通话对应的所有被叫UE，并确定为本次多方通话预留的媒体资源大小。

步骤210：多方通话AS向本次多方通话对应的被叫UE发起呼叫。

具体地，多方通话AS已根据INVITE消息中携带的URI List确定本次多方通话的所有被叫UE，在INVITE消息中携带第一媒体资源，依次向每一个被叫UE转发该INVITE消息，通知被叫UE本次多方通话使用的第一媒体资源。其中，被叫UE在接收到INVITE消息后，会将第一媒体资源的信息在本地保存。

步骤220：多方通话AS接收被叫UE返回的携带早期媒体的183消息，为被叫UE预留第二媒体资源，其中，第二媒体资源与所述第一媒体资源不同。

具体应用中，被叫UE在接收到INVITE消息后会回复183消息，如果被叫UE订购了包含早期媒体的业务，则会在183消息中携带早期媒体。多方通话AS接收到被叫UE返回的携带早期媒体的183消息后，为被用UE预留与第一媒体资源不同的其他媒体资源(可记为第二媒体资源)，预留第二媒体资源的流程可基于国际标准信令定义中的一组PRACK，PRACK 200OK交互消 息来完成。

国际标准信令定义中，多方通话AS为保证被叫UE的通话质量，会向被叫UE发送携带资源的PRACK消息，并接收被叫UE返回的200OK消息，实现为被叫UE的资源预留。本发明实施例一在国际标准信令流程的基础上，通过向被叫UE发送携带与第一媒体资源不同的第二媒体资源的PRACK消息，并接收被叫UE返回的针对PRACK消息的200OK消息，实现为被叫UE媒体资源的预留。

其中，多方通话AS可以针对多个被叫UE预留公用的第二媒体资源，或者，为不同的被叫UE预留不同的第二媒体资源。

步骤230：多方通话AS接收被叫UE发送的用于指示振铃的180消息，基于第二媒体资源释放早期媒体。

由于主叫UE与多方通话AS之间建立连接的是第一媒体资源，多方通话AS只能基于第一媒体资源向主叫UE发送媒体流，第二媒体资源与第一媒体资源不同，因此，基于第二媒体资源释放的早期媒体不会被主叫UE接收到，从而，同时释放多个被叫UE的早期媒体不会造成主叫UE的业务体验发生异常。

进一步地，被叫UE接听后，会向多方通话AS发送针对INVITE消息的200OK响应消息，但此时由于被叫UE与多方通话AS之间建立连接的是第二媒体资源，因此主叫UE与被叫UE之间不能正常建立数据交互。本发明实施例一中，多方通话AS在接收到被叫UE发送的用于指示接听的200OK消息之前，基于国际标准定义中的媒体重协商流程将被叫UE与多方通话AS之间重新建立媒体流连接，具体为：接收被叫UE发送的携带第一媒体资源的Re-INVITE消息，并向被叫UE返回针对Re-INVITE消息的确认消息。同时，将本地第二媒体资源释放，避免造成过多的运行负荷。其中，在步骤210中，被叫UE在接收到INVITE消息后，已将第一媒体资源的信息在本地保存，那么在进行媒体重协商的过程中，可直接在Re-INVITE消息中携带第一媒体资 源，实现媒体资源的重协商。

在多方通话AS接收到被叫UE发送的用于指示接听的200OK消息后，向被叫UE反馈ACK消息，至此，被叫UE便可与主叫UE申请的第一媒体资源建立媒体流，即可与主叫UE之间进行正常的数据交互。

至此，本发明实施例一设计的多方通话中的呼叫处理方法介绍完毕。

实施例二、

本发明实施例二设计了另一种多方通话中的呼叫处理方法。参阅图3所示，以其中任意一个被叫UE为例进行介绍，具体如下：

步骤300：被叫UE接收主叫UE归属的多方通话AS发起的呼叫，向多方通话AS返回携带早期媒体的183消息，其中，该呼叫是多方通话AS在接收到主叫UE发送的多方通话请求，并为主叫UE预留第一媒体资源后，向被叫UE发送的。

需要说明的是，主叫UE归属的多方通话AS在本发明实施例二中仍被简称为多方通话AS。

具体地，被叫UE接收到多方通话AS发送的INVITE消息，该INVITE消息是多方通话AS接收的主叫UE发送的。被叫UE在接收到多方通话AS发起的呼叫后，将呼叫中携带的第一媒体资源进行保存。

步骤310：被叫UE获取多方通话AS为其预留的第二媒体资源，其中，第二媒体资源是所述多方通话AS基于所述183消息为所述被叫UE预留的，且第二媒体资源与所述第一媒体资源不同。

具体地，被叫UE接收多方通话AS发送的携带第二媒体资源的PRACK消息，并向多方通话AS返回针对该PRACK消息的确认消息。

步骤320：被叫UE向多方通话AS发送用于指示振铃的180消息，以触发多方通话AS基于所述第二媒体资源释放早期媒体。

具体地，被叫UE振铃，向多方通话AS发送用于指示被叫用户处于振铃状态的180消息，多方通话AS在接收到用于指示振铃的180消息后，基于第 二媒体资源释放被叫用户的早期媒体，由于之前主叫UE与多方通话AS之间建立的媒体连接是基于第一媒体资源的，所以该早期媒体不会被主叫UE接收到，从而有效的屏蔽了早期媒体。

被叫UE接听后会向多方通话AS发送用于指示被叫UE处于接听状态的200OK消息，本发明实施例二中，被叫UE在向多方通话AS发送用于指示接听的200OK消息之前，向多方通话AS发送携带第一媒体资源的Re-INVITE消息，并接收多方通话AS返回针对该Re-INVITE消息的确认消息，以达到媒体重协商的目的，这样，被叫UE与主叫UE在多方通话AS中的媒体资源相同，可正常进行数据交互。

至此，本发明实施例二设计的多方通话中的呼叫处理方法介绍完毕。

上述过程中，在主叫UE、被叫UE，分别与多方通话AS的消息交互过程中，可能经过不同的网元，为方便描述，本发明实施例一、本发明实施例二中均未一一列出，其中，经过不同网元时均进行消息透传，不做其他处理。

下面结合具体的实施方案对本发明实施例作进一步详细的描述。

实施例三、

参阅图4所示，根据3GPP规范协议，主叫方发起多方通话的流程如下：

步骤401：主叫方(记为UE1)向IMS核心网IMS Core(SBC/P-SCCF)发送INVITE消息。

其中，INVITE消息用于发起多方通话请求，携带有URI List，URI List中包含有主叫方本次多方通话对应的所有被叫方的信息。

步骤402：IMS Core(SBC/P-SCCF)向UE1返回临时响应100Trying。

步骤403：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)转发INVITE消息。

步骤404：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)返回临时响应100Trying。

步骤405：IMS Core(S/I-CSCF)向UE1归属的多方通话应用服务器 (Application Server)AS转发INVITE消息。

步骤406：多方通话AS向IMS Core(S/I-CSCF)返回临时响应100Trying。

至此，多方通话AS在接收到的INVITE消息后，为UE1预留本次多方通话的媒体资源(即MRF)，在完成多方通话媒体资源的创建后，执行步骤107及后续步骤。

步骤407～步骤409：多方通话AS向UE1回复200OK消息应答该INVITE消息，其中，200OK消息中携带为UE1预留的媒体资源信息MRF，INVITE消息经过网元IMS Core(S/I-CSCF)和网元IMS Core(SBC/P-SCCF)时均采用透传的方式。

步骤410～步骤412：UE1经过IMS Core(SBC/P-SCCF)和IMS Core(S/I-CSCF)向多方通话AS返回ACK消息。

至此，UE1与多方通话AS之间建立媒体连接。

实施例四、

参阅图5所示，以任意一个被叫UE(可记为UE2)为例，本发明实施例四设计的多方通话过程中主叫UE所属的多方通话AS(以下简称AS1)与被叫UE之间的信令流程如下：

步骤501：AS1向ENUM/DNS发送INVITE消息。

该INVITE消息中携带URI List，以及AS1为UE1预留的媒体资源MRF的信息。

步骤502：ENUM/DNS返回100Trying。

步骤502’：ENUM/DNS查询号码映射功能成功，根据返回的SIP URI路由到参与方(即被叫UE)，以下流程以UE2为例进行介绍。

步骤503：ENUM/DNS向IMS Core(S/I-CSCF)发送该INVITE消息。

步骤504：IMS Core(S/I-CSCF)向ENUM/DNS返回100Trying。

步骤504’：IMS Core(S/I-CSCF)查询用户数据管理功能，获取为用户提供服务的服务器，即获取UE2归属的多方通话AS(以下简称AS2)。

步骤505：IMS Core(S/I-CSCF)向AS2发送该INVITE消息。

步骤506：AS2向IMS Core(S/I-CSCF)返回100Trying。

步骤507：AS2向IMS Core(S/I-CSCF)发送该INVITE消息。

步骤508：IMS Core(S/I-CSCF)向AS2返回100Trying。

步骤509：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)发送该INVITE消息。

步骤510：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)返回100Trying。

步骤511：IMS Core(SBC/P-SCCF)向UE2发送该INVITE消息。

步骤512：UE2向IMS Core(SBC/P-SCCF)返回100Trying。

步骤513：UE2向IMS Core(SBC/P-SCCF)发送携带早期媒体(即P-Early Media)的183Session Progress。

步骤514：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)发送该183Session Progress。

步骤515：IMS Core(S/I-CSCF)向AS2发送该183Session Progress。

步骤516：AS2向IMS Core(S/I-CSCF)发送该183Session Progress。

步骤517：IMS Core(S/I-CSCF)向ENUM/DNS发送该183Session Progress。

步骤518：ENUM/DNS向AS1发送该183Session Progress。

上述步骤501到步骤518为国际标准信令流程。

步骤519：AS1向ENUM/DNS发送携带与为UE1预留的媒体资源不同的其他媒体资源(记为other MRF)的PRACK消息。

步骤520：ENUM/DNS向IMS Core(S/I-CSCF)发送该PRACK消息。

步骤521：IMS Core(S/I-CSCF)向AS2发送该PRACK消息。

步骤522：AS2向IMS Core(S/I-CSCF)发送该PRACK消息。

步骤523：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)发送该PRACK消息。

步骤524：IMS Core(SBC/P-SCCF)向UE2发送该PRACK消息。

步骤525：UE2向IMS Core(SBC/P-SCCF)发送该PRACK消息的200OK响应。

步骤526：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)发送该200OK响应。

步骤527：IMS Core(S/I-CSCF)向AS2发送该200OK响应。

步骤528：AS2向IMS Core(S/I-CSCF)发送该200OK响应。

步骤529：IMS Core(S/I-CSCF)向ENUM/DNS发送该200OK响应。

步骤530：ENUM/DNS向AS1发送该200OK响应。

上述步骤519至步骤530为国际标准信令流程。通过步骤519至步骤530，AS1可为UE2预留与UE1不同的媒体资源(即other MRF)，当UE2振铃时，AS1会基于该不同的媒体资源释放早期媒体，有效屏蔽了早期媒体。

步骤531：UE2向IMS Core(SBC/P-SCCF)发送携带为UE1预留的MRF的Re-INVITE消息。

步骤532：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)发送该Re-INVITE消息。

步骤533：IMS Core(S/I-CSCF)向AS2发送该Re-INVITE消息。

步骤534：AS2向IMS Core(S/I-CSCF)发送该Re-INVITE消息。

步骤535：IMS Core(S/I-CSCF)向ENUM/DNS发送该Re-INVITE消息。

步骤536：ENUM/DNS向AS1发送该Re-INVITE消息。

步骤537：AS1向ENUM/DNS发送针对Re-INVITE消息的200OK响应。

步骤538：ENUM/DNS向IMS Core(S/I-CSCF)发送该200OK响应。

步骤539：IMS Core(S/I-CSCF)向AS2发送该200OK响应。

步骤540：AS2向IMS Core(S/I-CSCF)发送该200OK响应。

步骤541：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)发送该200OK响应。

步骤542：IMS Core(SBC/P-SCCF)向UE2发送该200OK响应。

上述步骤531至步骤542的信令交互为国际标准信令流程。通过步骤531至步骤542，UE2与AS1之间建立新的媒体连接，可基于为UE1预留的MRF进行正常数据交互。

步骤543～步骤548：UE2接听，向AS1发送针对INVITE的200OK响应。

步骤548～步骤554：AS1向UE2反馈ACK。

上述步骤543～步骤554的信令交互为用户接听电话的标准信令流程，在此不再赘述。

实施例五、

基于同一发明构思，参阅图6所示，本发明实施例五设计了一种多方通话中的呼叫处理装置，包括：

媒体资源控制模块60，用于在接收到主叫UE发送的多方通话请求后，为所述主叫UE预留第一媒体资源；

信令交互模块61，用于向本次多方通话对应的被叫UE发起呼叫，以及接收所述被叫UE返回的携带早期媒体的183消息；

媒体资源控制模块60，进一步用于为所述被叫UE预留第二媒体资源，其中，所述第二媒体资源与所述第一媒体资源不同。

早期媒体释放模块62，用于在信令交互模块61接收所述被叫UE发送的用于指示振铃的180消息后，基于第二媒体资源释放早期媒体。

较佳地，在接收主叫UE发送的多方通话请求，为所述主叫UE预留第一媒体资源时，信令交互模块61具体用于，接收主叫UE发送的用于请求建立多方通话的邀请INVITE消息；媒体资源控制模块60具体用于，为所述主叫UE预留本次多方通话的第一媒体资源，其中，所述INVITE消息中携带URI List。

较佳地，在向本次多方通话对应的被叫UE发起呼叫时，信令交互模块61具体用于：

所述多方通话AS根据所述INVITE消息中携带的URI List确定本次多方 通话的被叫UE，并在所述INVITE消息中携带所述第一媒体资源后，向所述被叫UE转发所述INVITE消息。

较佳地，在信令交互模块61接收所述被叫UE返回的携带早期媒体的183消息，在再次接收到所述被叫UE发送的用于指示振铃的180消息之前，在为所述被叫UE预留第二媒体资源时，媒体资源控制模块60具体用于：

在信令交互模块61接收所述被叫UE返回的携带早期媒体的183消息，在再次接收到所述被叫UE发送的用于指示振铃的180消息之前，向所述被叫UE发送携带第二媒体资源的PRACK消息，以及接收所述被叫UE反馈的确认消息。

较佳地，在为所述被叫UE预留第二媒体资源之后，在再次接收到所述被叫UE发送的用于指示振铃的180消息时，媒体资源控制模块60进一步用于基于所述第二媒体资源释放所述早期媒体。

较佳地，信令交互模块61进一步用于：

在接收到所述被叫UE发送的用于指示接听的200OK消息之前，接收所述被叫UE发送的携带所述第一媒体资源的重邀请Re-INVITE消息，并向所述被叫UE返回针对所述Re-INVITE消息的确认消息。

实施例六、

基于同一发明构思，参阅图7所示，本发明实施例六设计了另一种多方通话中的呼叫处理装置，包括：

第一收发模块70，用于接收主叫UE归属的多方通话AS发起的呼叫，向所述多方通话AS返回携带早期媒体的183消息，其中，所述呼叫是所述多方通话AS在接收到主叫UE发送的多方通话请求，并为所述主叫UE预留第一媒体资源后，向本装置发送的；

资源获取模块71，获取多方通话AS为本装置预留的第二媒体资源，其中，第二媒体资源是多方通话AS基于所述183消息为本装置预留的，且所述第二媒体资源与所述第一媒体资源不同。

第二收发模块72，用于向所述多方通话AS发送用于指示振铃的180消息，以触发所述多方通话AS基于所述第二媒体资源释放所述早期媒体。

较佳地，所述第一收发模块70具体用于：在接收到所述多方通话AS发起的呼叫后，将所述呼叫中携带的第一媒体资源进行保存。

较佳地，进一步包括：

第三收发模块73：用于在向所述多方通话AS发送用于指示接听的200OK消息之前，向所述多方通话AS发送携带所述第一媒体资源的Re-INVITE消息，并接收所述多方通话AS返回针对所述Re-INVITE消息的确认消息。

较佳地，在获取所述多方通话AS为所述被叫UE预留的第二媒体资源时，资源获取模块71具体用于：

接收所述多方通话AS发送的携带第二媒体资源的PRACK消息，并向所述多方通话AS返回针对所述PRACK消息的确认消息。

综上所述，本发明实施例中，多方通话AS在接收到被叫UE发送的携带早期媒体的183消息后，向被叫UE发送携带与之前为主叫UE预留的媒体资源不同的其他媒体资源的PRACK消息，并接收被叫UE反馈的200OK响应，这样在被叫UE振铃后，多方通话AS可基于上述其他媒体资源释放早期媒体，有效为主叫UE屏蔽所有的早期媒体，避免了在多个被叫UE均定制早期媒体的情况下，主叫UE同时接收到多个早期媒体的叠加信息，而造成主叫UE业务体验异常，同时降低了多方通话AS的放音处理负荷。另外，在被叫UE接听后，通过标准的SIP Re-INVITE消息进行媒体重协商，使得主被叫UE能够正常进行数据交互，并且同时释放上述其他媒体资源予以复用，避免了多方通话AS的运行负荷。并且，上述方法不需改变国际标准的信令流程，避免了由非标准信令流程和定制化的服务器处理能力对业务带来的弊端。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包 含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。