本發(fā)明涉及通信技術領域，特別涉及一種多方通話中的呼叫處理方法及裝置。

背景技術：

隨著移動互聯(lián)網(wǎng)的高速發(fā)展，通信服務不斷的為用戶提供新的空間，多方通話功能能夠滿足用戶通信過程中多個用戶同時交流的要求，目前，已有很多終端產品能夠實現(xiàn)多方語音通話或者多方視頻通話。

針對多方通話，根據(jù)3GPP TS24.147的定義，技術上已經(jīng)可以通過統(tǒng)一資源標識符序列(Uniform Resource Identifier list，URI List)的方式一鍵發(fā)起一通多方通話，滿足了用戶快速發(fā)起多方通話的需求。但是，如果參與多方通話的所有被叫用戶設備(User Equipment，UE)中，多個被叫UE均訂購了不同的包含早期媒體的業(yè)務(如彩鈴、包含提示音的補充業(yè)務等)，那么主叫UE聽到的回鈴音將會發(fā)生異常。例如，多個被叫UE訂購了彩鈴業(yè)務，那么在被叫UE振鈴過程中，主叫UE就會同時聽到多個彩鈴的播放，從而嚴重影響主叫UE的體驗。

參閱圖1所示，以某一個被叫UE為例，現(xiàn)有的多方通話的簡易流程如下：

步驟101：主叫UE向其歸屬的多方通話應用服務器(Application Server)AS發(fā)送INVITE消息，請求建立多方通話。

步驟102：多方通話AS為本次多方通話預留媒體資源。

步驟103：多方通話AS向主叫UE返回攜帶該媒體資源的200OK響應消息。

步驟104：多方通話AS向被叫UE轉發(fā)該INVITE消息。

步驟105：被叫UE向多方通話AS返回攜帶早期媒體的18X消息。

由于之前主叫UE與多方通話AS之間已經(jīng)建立了媒體流，因此多方通話AS會直接將早期媒體向主叫UE發(fā)送。

因此，如果多個被叫UE均返回攜帶早期媒體的18X消息，則主叫UE會同時接收到多個重疊的早期媒體，導致用戶體驗極差。

目前，已知的解決方案是主叫UE歸屬的多方通話AS接收到攜帶早期媒體的18X消息時，將該18X消息做信令解析，通過信令解析將該18X消息做缺省處理，即，媒體行置零，以使主叫UE僅收到單一的通話回鈴音。

但上述解決方案涉及信令解析，對多方通話AS的性能要求較高，特別是用戶量增大的時候可能導致多方通話AS崩潰。另外，對此類18X消息做缺省處理，從可靠性傳輸?shù)慕嵌葋砜?，多方通話AS信令解析的處理將影響通話接聽前可靠傳輸機制的響應消息的交互，無法滿足可靠性傳輸?shù)南⒔换ピ瓌t，與國際標準要求違背，對未來業(yè)務進行互聯(lián)互通時提高了門檻。

綜上所述，在多方通話過程中，當多個被叫UE同時發(fā)送早期媒體時，無法對早期媒體進行有效屏蔽，從而導致主叫UE業(yè)務使用發(fā)生異常，現(xiàn)有技術還沒有有效的解決方案。

技術實現(xiàn)要素：

本發(fā)明實施例提供一種多方通話中的呼叫處理方法及裝置，用以解決現(xiàn)有技術中存在的在多方通話過程中，當多個被叫UE同時發(fā)送早期媒體時，無法對早期媒體進行有效屏蔽，從而導致主叫UE業(yè)務使用發(fā)生異常的問題。

本發(fā)明實施例提供的具體技術方案如下：

一種多方通話中的呼叫處理方法，包括：

主叫用戶設備UE歸屬的多方通話應用服務器AS在接收到主叫UE發(fā)送的多方通話請求后，為所述主叫UE預留第一媒體資源；

所述多方通話AS向本次多方通話對應的被叫UE發(fā)起呼叫；

所述多方通話AS接收所述被叫UE返回的攜帶早期媒體的183消息，為所述被叫UE預留第二媒體資源，其中，所述第二媒體資源與所述第一媒體資源不同；

所述多方通話AS接收所述被叫UE發(fā)送的用于指示振鈴的180消息，基于所述第二媒體資源釋放所述早期媒體。

較佳地，多方通話AS接收主叫UE發(fā)送的多方通話請求，為所述主叫UE預留第一媒體資源，具體包括：

所述多方通話AS接收主叫UE發(fā)送的用于請求建立多方通話的邀請INVITE消息，為所述主叫UE預留本次多方通話的第一媒體資源，其中，所述INVITE消息中攜帶URI List。

較佳地，所述多方通話AS向本次多方通話對應的被叫UE發(fā)起呼叫，具體包括：

所述多方通話AS根據(jù)所述INVITE消息中攜帶的URI List確定本次多方通話的被叫UE，并在所述INVITE消息中攜帶所述第一媒體資源后，向所述被叫UE轉發(fā)所述INVITE消息。

較佳地，所述多方通話AS接收所述被叫UE返回的攜帶早期媒體的183消息，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息之前，為所述被叫UE預留第二媒體資源，具體包括：

所述多方通話AS接收所述被叫UE返回的攜帶早期媒體的183消息，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息之前，向所述被叫UE發(fā)送攜帶第二媒體資源的臨時正確應答指令(provisional ACKnowledge，PRACK)消息，以及接收所述被叫UE反饋的確認消息。

較佳地，在為所述被叫UE預留第二媒體資源之后，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息時，基于所述第二媒體資源釋放所述早期媒體。

較佳地，進一步包括：

所述多方通話AS在接收到所述被叫UE發(fā)送的用于指示接聽的200OK消息之前，接收所述被叫UE發(fā)送的攜帶所述第一媒體資源的Re-INVITE消息，并向所述被叫UE返回針對所述Re-INVITE消息的確認消息。

一種多方通話中的呼叫處理方法，包括：

被叫UE接收主叫UE歸屬的多方通話AS發(fā)起的呼叫，向所述多方通話AS返回攜帶早期媒體的183消息，其中，所述呼叫是所述多方通話AS在接收到主叫UE發(fā)送的多方通話請求，并為所述主叫UE預留第一媒體資源后，向所述被叫UE發(fā)送的；

所述被叫UE獲取所述多方通話AS為所述被叫UE預留的第二媒體資源，其中，所述第二媒體資源是所述多方通話AS基于所述183消息為所述被叫UE預留的，且所述第二媒體資源與所述第一媒體資源不同；

所述被叫UE向所述多方通話AS發(fā)送用于指示振鈴的180消息，以觸發(fā)所述多方通話AS基于所述第二媒體資源釋放所述早期媒體。

較佳地，所述被叫UE在接收到所述多方通話AS發(fā)起的呼叫后，將所述呼叫中攜帶的第一媒體資源進行保存。

較佳地，進一步包括：

所述被叫UE在向所述多方通話AS發(fā)送用于指示接聽的200OK消息之前，向所述多方通話AS發(fā)送攜帶所述第一媒體資源的Re-INVITE消息，并接收所述多方通話AS返回針對所述Re-INVITE消息的確認消息。

較佳地，所述被叫UE獲取所述多方通話AS為所述被叫UE預留的第二媒體資源，具體包括：

所述被叫UE接收所述多方通話AS發(fā)送的攜帶第二媒體資源的PRACK消息，并向所述多方通話AS返回針對所述PRACK消息的確認消息。

一種多方通話中的呼叫處理裝置，包括：

媒體資源控制模塊，用于在接收到主叫UE發(fā)送的多方通話請求后，為所述主叫UE預留第一媒體資源；

信令交互模塊，用于向本次多方通話對應的被叫UE發(fā)起呼叫，以及接收所述被叫UE返回的攜帶早期媒體的183消息；

所述媒體資源控制模塊，進一步用于為所述被叫UE預留第二媒體資源，其中，所述第二媒體資源與所述第一媒體資源不同；

早期媒體釋放模塊，用于在所述信令交互模塊接收所述被叫UE發(fā)送的用于指示振鈴的180消息后，基于所述第二媒體資源釋放所述早期媒體。

較佳地，在接收主叫UE發(fā)送的多方通話請求，為所述主叫UE預留第一媒體資源時，所述信令交互模塊具體用于，接收主叫UE發(fā)送的用于請求建立多方通話的INVITE消息；所述媒體資源控制模塊具體用于，為所述主叫UE預留本次多方通話的第一媒體資源，其中，所述INVITE消息中攜帶URI List。

較佳地，在向本次多方通話對應的被叫UE發(fā)起呼叫時，所述信令交互模塊具體用于：

所述多方通話AS根據(jù)所述INVITE消息中攜帶的URI List確定本次多方通話的被叫UE，并在所述INVITE消息中攜帶所述第一媒體資源后，向所述被叫UE轉發(fā)所述INVITE消息。

較佳地，在所述信令交互模塊接收所述被叫UE返回的攜帶早期媒體的183消息，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息之前，在為所述被叫UE預留第二媒體資源時，所述媒體資源控制模塊具體用于：

在所述信令交互模塊接收所述被叫UE返回的攜帶早期媒體的183消息，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息之前，向所述被叫UE發(fā)送攜帶第二媒體資源的PRACK消息，以及接收所述被叫UE反饋的確認消息。

較佳地，在為所述被叫UE預留第二媒體資源之后，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息時，所述媒體資源控制模塊進一步用于基于所述第二媒體資源釋放所述早期媒體。

較佳地，所述信令交互模塊進一步用于：

在接收到所述被叫UE發(fā)送的用于指示接聽的200OK消息之前，接收所述被叫UE發(fā)送的攜帶所述第一媒體資源的Re-INVITE消息，并向所述被叫UE返回針對所述Re-INVITE消息的確認消息。

一種多方通話中的呼叫處理裝置，包括：

第一收發(fā)模塊，用于接收主叫UE歸屬的多方通話AS發(fā)起的呼叫，向所述多方通話AS返回攜帶早期媒體的183消息，其中，所述呼叫是所述多方通話AS在接收到主叫UE發(fā)送的多方通話請求，并為所述主叫UE預留第一媒體資源后，向本裝置發(fā)送的；

資源獲取模塊，獲取所述多方通話AS為本裝置預留的第二媒體資源，其中，所述第二媒體資源是所述多方通話AS基于所述183消息為本裝置預留的，且所述第二媒體資源與所述第一媒體資源不同；

第二收發(fā)模塊，用于向所述多方通話AS發(fā)送用于指示振鈴的180消息，以觸發(fā)所述多方通話AS基于所述第二媒體資源釋放所述早期媒體。

較佳地，所述第一收發(fā)模塊具體用于：在接收到所述多方通話AS發(fā)起的呼叫后，將所述呼叫中攜帶的第一媒體資源進行保存。

較佳地，進一步包括：

第三收發(fā)模塊：用于在向所述多方通話AS發(fā)送用于指示接聽的200OK消息之前，向所述多方通話AS發(fā)送攜帶所述第一媒體資源的Re-INVITE消息，并接收所述多方通話AS返回針對所述Re-INVITE消息的確認消息。

較佳地，在獲取所述多方通話AS為所述被叫UE預留的第二媒體資源時，所述資源獲取模塊具體用于：

接收所述多方通話AS發(fā)送的攜帶第二媒體資源的PRACK消息，并向所述多方通話AS返回針對所述PRACK消息的確認消息。

本發(fā)明實施例中，多方通話AS在接收到被叫UE發(fā)送的攜帶早期媒體的183消息后，向被叫UE發(fā)送攜帶與之前為主叫UE預留的媒體資源不同的其他媒體資源的PRACK消息，并接收被叫UE反饋的200OK響應，這樣在被叫 UE振鈴后，多方通話AS可基于上述其他媒體資源釋放早期媒體，有效為主叫UE屏蔽所有的早期媒體，避免了在多個被叫UE均定制早期媒體的情況下，主叫UE同時接收到多個早期媒體的疊加信息，而造成主叫UE業(yè)務體驗異常，同時降低了多方通話AS的放音處理負荷，并且，不需改變國際標準的信令流程，避免了由非標準信令流程和定制化的服務器處理能力對業(yè)務帶來的弊端。

附圖說明

圖1為現(xiàn)有技術中多方通話的簡易流程圖；

圖2為本發(fā)明實施例一多方通話中的呼叫處理流程圖；

圖3為本發(fā)明實施例二多方通話中的呼叫處理流程圖；

圖4為本發(fā)明實施例三主叫方發(fā)起多方通話的流程圖；

圖5為本發(fā)明實施例四多方通話AS與被叫UE之間的信令流程；

圖6為本發(fā)明實施例五多方通話中的呼叫處理裝置結構圖；

圖7為本發(fā)明實施例六多方通話中的呼叫處理裝置結構圖。

具體實施方式

針對現(xiàn)有技術中在多方通話過程中無法有效避免被叫UE的早期媒體的缺陷，本發(fā)明實施例中，主叫UE歸屬的多方通話AS在接收到主叫UE發(fā)送的多方通話請求時，為主叫UE預留第一媒體資源，并在接收到被叫UE發(fā)送的攜帶早期媒體的183消息時，為被叫UE預留與第一媒體資源不同的第二媒體資源，這樣，在被叫UE振鈴時，多方通話AS將基于第二媒體資源釋放被叫UE的早期媒體，而不是基于第一媒體資源釋放被叫UE的早期媒體，避免了多個被叫UE均基于第一媒體資源釋放早期媒體而導致的主叫UE同時接收到多個不同的早期媒體，從而可有效屏蔽被叫UE的早期媒體，提升主叫UE的業(yè)務體驗，并且不對多方通話AS造成過多的運行負擔。

下面結合附圖對本發(fā)明實施例優(yōu)選的實施方案作詳細說明。

實施例一、

參閱圖2所示，本發(fā)明實施例一中，多方通話中的呼叫處理流程如下：

步驟200：主叫UE歸屬的多方通話AS在接收到主叫UE發(fā)送的多方通話請求后，為主叫UE預留第一媒體資源。

需要說明的是，在步驟200～步驟220中，為方便描述，將主叫UE歸屬的多方通話AS簡稱為多方通話AS。

實際應用中，多方通話AS接收主叫UE發(fā)送的用于請求建立多方通話的INVITE消息，為主叫UE預留本次多方通話的媒體資源(記為第一媒體資源)，并向主叫UE發(fā)送攜帶第一媒體資源的200OK消息，在接收到主叫UE返回的ACK消息后，多方通話AS與主叫UE建立媒體流，即，多方通話AS在后續(xù)過程中可直接向主叫UE播放彩鈴等早期媒體。

其中，INVITE消息中攜帶URI List，多方通話AS可通過URI List確定本次多方通話對應的所有被叫UE，并確定為本次多方通話預留的媒體資源大小。

步驟210：多方通話AS向本次多方通話對應的被叫UE發(fā)起呼叫。

具體地，多方通話AS已根據(jù)INVITE消息中攜帶的URI List確定本次多方通話的所有被叫UE，在INVITE消息中攜帶第一媒體資源，依次向每一個被叫UE轉發(fā)該INVITE消息，通知被叫UE本次多方通話使用的第一媒體資源。其中，被叫UE在接收到INVITE消息后，會將第一媒體資源的信息在本地保存。

步驟220：多方通話AS接收被叫UE返回的攜帶早期媒體的183消息，為被叫UE預留第二媒體資源，其中，第二媒體資源與所述第一媒體資源不同。

具體應用中，被叫UE在接收到INVITE消息后會回復183消息，如果被叫UE訂購了包含早期媒體的業(yè)務，則會在183消息中攜帶早期媒體。多方通話AS接收到被叫UE返回的攜帶早期媒體的183消息后，為被用UE預留與第一媒體資源不同的其他媒體資源(可記為第二媒體資源)，預留第二媒體資源的流程可基于國際標準信令定義中的一組PRACK，PRACK 200OK交互消 息來完成。

國際標準信令定義中，多方通話AS為保證被叫UE的通話質量，會向被叫UE發(fā)送攜帶資源的PRACK消息，并接收被叫UE返回的200OK消息，實現(xiàn)為被叫UE的資源預留。本發(fā)明實施例一在國際標準信令流程的基礎上，通過向被叫UE發(fā)送攜帶與第一媒體資源不同的第二媒體資源的PRACK消息，并接收被叫UE返回的針對PRACK消息的200OK消息，實現(xiàn)為被叫UE媒體資源的預留。

其中，多方通話AS可以針對多個被叫UE預留公用的第二媒體資源，或者，為不同的被叫UE預留不同的第二媒體資源。

步驟230：多方通話AS接收被叫UE發(fā)送的用于指示振鈴的180消息，基于第二媒體資源釋放早期媒體。

由于主叫UE與多方通話AS之間建立連接的是第一媒體資源，多方通話AS只能基于第一媒體資源向主叫UE發(fā)送媒體流，第二媒體資源與第一媒體資源不同，因此，基于第二媒體資源釋放的早期媒體不會被主叫UE接收到，從而，同時釋放多個被叫UE的早期媒體不會造成主叫UE的業(yè)務體驗發(fā)生異常。

進一步地，被叫UE接聽后，會向多方通話AS發(fā)送針對INVITE消息的200OK響應消息，但此時由于被叫UE與多方通話AS之間建立連接的是第二媒體資源，因此主叫UE與被叫UE之間不能正常建立數(shù)據(jù)交互。本發(fā)明實施例一中，多方通話AS在接收到被叫UE發(fā)送的用于指示接聽的200OK消息之前，基于國際標準定義中的媒體重協(xié)商流程將被叫UE與多方通話AS之間重新建立媒體流連接，具體為：接收被叫UE發(fā)送的攜帶第一媒體資源的Re-INVITE消息，并向被叫UE返回針對Re-INVITE消息的確認消息。同時，將本地第二媒體資源釋放，避免造成過多的運行負荷。其中，在步驟210中，被叫UE在接收到INVITE消息后，已將第一媒體資源的信息在本地保存，那么在進行媒體重協(xié)商的過程中，可直接在Re-INVITE消息中攜帶第一媒體資 源，實現(xiàn)媒體資源的重協(xié)商。

在多方通話AS接收到被叫UE發(fā)送的用于指示接聽的200OK消息后，向被叫UE反饋ACK消息，至此，被叫UE便可與主叫UE申請的第一媒體資源建立媒體流，即可與主叫UE之間進行正常的數(shù)據(jù)交互。

至此，本發(fā)明實施例一設計的多方通話中的呼叫處理方法介紹完畢。

實施例二、

本發(fā)明實施例二設計了另一種多方通話中的呼叫處理方法。參閱圖3所示，以其中任意一個被叫UE為例進行介紹，具體如下：

步驟300：被叫UE接收主叫UE歸屬的多方通話AS發(fā)起的呼叫，向多方通話AS返回攜帶早期媒體的183消息，其中，該呼叫是多方通話AS在接收到主叫UE發(fā)送的多方通話請求，并為主叫UE預留第一媒體資源后，向被叫UE發(fā)送的。

需要說明的是，主叫UE歸屬的多方通話AS在本發(fā)明實施例二中仍被簡稱為多方通話AS。

具體地，被叫UE接收到多方通話AS發(fā)送的INVITE消息，該INVITE消息是多方通話AS接收的主叫UE發(fā)送的。被叫UE在接收到多方通話AS發(fā)起的呼叫后，將呼叫中攜帶的第一媒體資源進行保存。

步驟310：被叫UE獲取多方通話AS為其預留的第二媒體資源，其中，第二媒體資源是所述多方通話AS基于所述183消息為所述被叫UE預留的，且第二媒體資源與所述第一媒體資源不同。

具體地，被叫UE接收多方通話AS發(fā)送的攜帶第二媒體資源的PRACK消息，并向多方通話AS返回針對該PRACK消息的確認消息。

步驟320：被叫UE向多方通話AS發(fā)送用于指示振鈴的180消息，以觸發(fā)多方通話AS基于所述第二媒體資源釋放早期媒體。

具體地，被叫UE振鈴，向多方通話AS發(fā)送用于指示被叫用戶處于振鈴狀態(tài)的180消息，多方通話AS在接收到用于指示振鈴的180消息后，基于第 二媒體資源釋放被叫用戶的早期媒體，由于之前主叫UE與多方通話AS之間建立的媒體連接是基于第一媒體資源的，所以該早期媒體不會被主叫UE接收到，從而有效的屏蔽了早期媒體。

被叫UE接聽后會向多方通話AS發(fā)送用于指示被叫UE處于接聽狀態(tài)的200OK消息，本發(fā)明實施例二中，被叫UE在向多方通話AS發(fā)送用于指示接聽的200OK消息之前，向多方通話AS發(fā)送攜帶第一媒體資源的Re-INVITE消息，并接收多方通話AS返回針對該Re-INVITE消息的確認消息，以達到媒體重協(xié)商的目的，這樣，被叫UE與主叫UE在多方通話AS中的媒體資源相同，可正常進行數(shù)據(jù)交互。

至此，本發(fā)明實施例二設計的多方通話中的呼叫處理方法介紹完畢。

上述過程中，在主叫UE、被叫UE，分別與多方通話AS的消息交互過程中，可能經(jīng)過不同的網(wǎng)元，為方便描述，本發(fā)明實施例一、本發(fā)明實施例二中均未一一列出，其中，經(jīng)過不同網(wǎng)元時均進行消息透傳，不做其他處理。

下面結合具體的實施方案對本發(fā)明實施例作進一步詳細的描述。

實施例三、

參閱圖4所示，根據(jù)3GPP規(guī)范協(xié)議，主叫方發(fā)起多方通話的流程如下：

步驟401：主叫方(記為UE1)向IMS核心網(wǎng)IMS Core(SBC/P-SCCF)發(fā)送INVITE消息。

其中，INVITE消息用于發(fā)起多方通話請求，攜帶有URI List，URI List中包含有主叫方本次多方通話對應的所有被叫方的信息。

步驟402：IMS Core(SBC/P-SCCF)向UE1返回臨時響應100Trying。

步驟403：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)轉發(fā)INVITE消息。

步驟404：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)返回臨時響應100Trying。

步驟405：IMS Core(S/I-CSCF)向UE1歸屬的多方通話應用服務器 (Application Server)AS轉發(fā)INVITE消息。

步驟406：多方通話AS向IMS Core(S/I-CSCF)返回臨時響應100Trying。

至此，多方通話AS在接收到的INVITE消息后，為UE1預留本次多方通話的媒體資源(即MRF)，在完成多方通話媒體資源的創(chuàng)建后，執(zhí)行步驟107及后續(xù)步驟。

步驟407～步驟409：多方通話AS向UE1回復200OK消息應答該INVITE消息，其中，200OK消息中攜帶為UE1預留的媒體資源信息MRF，INVITE消息經(jīng)過網(wǎng)元IMS Core(S/I-CSCF)和網(wǎng)元IMS Core(SBC/P-SCCF)時均采用透傳的方式。

步驟410～步驟412：UE1經(jīng)過IMS Core(SBC/P-SCCF)和IMS Core(S/I-CSCF)向多方通話AS返回ACK消息。

至此，UE1與多方通話AS之間建立媒體連接。

實施例四、

參閱圖5所示，以任意一個被叫UE(可記為UE2)為例，本發(fā)明實施例四設計的多方通話過程中主叫UE所屬的多方通話AS(以下簡稱AS1)與被叫UE之間的信令流程如下：

步驟501：AS1向ENUM/DNS發(fā)送INVITE消息。

該INVITE消息中攜帶URI List，以及AS1為UE1預留的媒體資源MRF的信息。

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

步驟502’：ENUM/DNS查詢號碼映射功能成功，根據(jù)返回的SIP URI路由到參與方(即被叫UE)，以下流程以UE2為例進行介紹。

步驟503：ENUM/DNS向IMS Core(S/I-CSCF)發(fā)送該INVITE消息。

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

步驟504’：IMS Core(S/I-CSCF)查詢用戶數(shù)據(jù)管理功能，獲取為用戶提供服務的服務器，即獲取UE2歸屬的多方通話AS(以下簡稱AS2)。

步驟505：IMS Core(S/I-CSCF)向AS2發(fā)送該INVITE消息。

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

步驟507：AS2向IMS Core(S/I-CSCF)發(fā)送該INVITE消息。

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

步驟509：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)發(fā)送該INVITE消息。

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

步驟511：IMS Core(SBC/P-SCCF)向UE2發(fā)送該INVITE消息。

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

步驟513：UE2向IMS Core(SBC/P-SCCF)發(fā)送攜帶早期媒體(即P-Early Media)的183Session Progress。

步驟514：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)發(fā)送該183Session Progress。

步驟515：IMS Core(S/I-CSCF)向AS2發(fā)送該183Session Progress。

步驟516：AS2向IMS Core(S/I-CSCF)發(fā)送該183Session Progress。

步驟517：IMS Core(S/I-CSCF)向ENUM/DNS發(fā)送該183Session Progress。

步驟518：ENUM/DNS向AS1發(fā)送該183Session Progress。

上述步驟501到步驟518為國際標準信令流程。

步驟519：AS1向ENUM/DNS發(fā)送攜帶與為UE1預留的媒體資源不同的其他媒體資源(記為other MRF)的PRACK消息。

步驟520：ENUM/DNS向IMS Core(S/I-CSCF)發(fā)送該PRACK消息。

步驟521：IMS Core(S/I-CSCF)向AS2發(fā)送該PRACK消息。

步驟522：AS2向IMS Core(S/I-CSCF)發(fā)送該PRACK消息。

步驟523：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)發(fā)送該PRACK消息。

步驟524：IMS Core(SBC/P-SCCF)向UE2發(fā)送該PRACK消息。

步驟525：UE2向IMS Core(SBC/P-SCCF)發(fā)送該PRACK消息的200OK響應。

步驟526：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)發(fā)送該200OK響應。

步驟527：IMS Core(S/I-CSCF)向AS2發(fā)送該200OK響應。

步驟528：AS2向IMS Core(S/I-CSCF)發(fā)送該200OK響應。

步驟529：IMS Core(S/I-CSCF)向ENUM/DNS發(fā)送該200OK響應。

步驟530：ENUM/DNS向AS1發(fā)送該200OK響應。

上述步驟519至步驟530為國際標準信令流程。通過步驟519至步驟530，AS1可為UE2預留與UE1不同的媒體資源(即other MRF)，當UE2振鈴時，AS1會基于該不同的媒體資源釋放早期媒體，有效屏蔽了早期媒體。

步驟531：UE2向IMS Core(SBC/P-SCCF)發(fā)送攜帶為UE1預留的MRF的Re-INVITE消息。

步驟532：IMS Core(SBC/P-SCCF)向IMS Core(S/I-CSCF)發(fā)送該Re-INVITE消息。

步驟533：IMS Core(S/I-CSCF)向AS2發(fā)送該Re-INVITE消息。

步驟534：AS2向IMS Core(S/I-CSCF)發(fā)送該Re-INVITE消息。

步驟535：IMS Core(S/I-CSCF)向ENUM/DNS發(fā)送該Re-INVITE消息。

步驟536：ENUM/DNS向AS1發(fā)送該Re-INVITE消息。

步驟537：AS1向ENUM/DNS發(fā)送針對Re-INVITE消息的200OK響應。

步驟538：ENUM/DNS向IMS Core(S/I-CSCF)發(fā)送該200OK響應。

步驟539：IMS Core(S/I-CSCF)向AS2發(fā)送該200OK響應。

步驟540：AS2向IMS Core(S/I-CSCF)發(fā)送該200OK響應。

步驟541：IMS Core(S/I-CSCF)向IMS Core(SBC/P-SCCF)發(fā)送該200OK響應。

步驟542：IMS Core(SBC/P-SCCF)向UE2發(fā)送該200OK響應。

上述步驟531至步驟542的信令交互為國際標準信令流程。通過步驟531至步驟542，UE2與AS1之間建立新的媒體連接，可基于為UE1預留的MRF進行正常數(shù)據(jù)交互。

步驟543～步驟548：UE2接聽，向AS1發(fā)送針對INVITE的200OK響應。

步驟548～步驟554：AS1向UE2反饋ACK。

上述步驟543～步驟554的信令交互為用戶接聽電話的標準信令流程，在此不再贅述。

實施例五、

基于同一發(fā)明構思，參閱圖6所示，本發(fā)明實施例五設計了一種多方通話中的呼叫處理裝置，包括：

媒體資源控制模塊60，用于在接收到主叫UE發(fā)送的多方通話請求后，為所述主叫UE預留第一媒體資源；

信令交互模塊61，用于向本次多方通話對應的被叫UE發(fā)起呼叫，以及接收所述被叫UE返回的攜帶早期媒體的183消息；

媒體資源控制模塊60，進一步用于為所述被叫UE預留第二媒體資源，其中，所述第二媒體資源與所述第一媒體資源不同。

早期媒體釋放模塊62，用于在信令交互模塊61接收所述被叫UE發(fā)送的用于指示振鈴的180消息后，基于第二媒體資源釋放早期媒體。

較佳地，在接收主叫UE發(fā)送的多方通話請求，為所述主叫UE預留第一媒體資源時，信令交互模塊61具體用于，接收主叫UE發(fā)送的用于請求建立多方通話的邀請INVITE消息；媒體資源控制模塊60具體用于，為所述主叫UE預留本次多方通話的第一媒體資源，其中，所述INVITE消息中攜帶URI List。

較佳地，在向本次多方通話對應的被叫UE發(fā)起呼叫時，信令交互模塊61具體用于：

所述多方通話AS根據(jù)所述INVITE消息中攜帶的URI List確定本次多方 通話的被叫UE，并在所述INVITE消息中攜帶所述第一媒體資源后，向所述被叫UE轉發(fā)所述INVITE消息。

較佳地，在信令交互模塊61接收所述被叫UE返回的攜帶早期媒體的183消息，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息之前，在為所述被叫UE預留第二媒體資源時，媒體資源控制模塊60具體用于：

在信令交互模塊61接收所述被叫UE返回的攜帶早期媒體的183消息，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息之前，向所述被叫UE發(fā)送攜帶第二媒體資源的PRACK消息，以及接收所述被叫UE反饋的確認消息。

較佳地，在為所述被叫UE預留第二媒體資源之后，在再次接收到所述被叫UE發(fā)送的用于指示振鈴的180消息時，媒體資源控制模塊60進一步用于基于所述第二媒體資源釋放所述早期媒體。

較佳地，信令交互模塊61進一步用于：

在接收到所述被叫UE發(fā)送的用于指示接聽的200OK消息之前，接收所述被叫UE發(fā)送的攜帶所述第一媒體資源的重邀請Re-INVITE消息，并向所述被叫UE返回針對所述Re-INVITE消息的確認消息。

實施例六、

基于同一發(fā)明構思，參閱圖7所示，本發(fā)明實施例六設計了另一種多方通話中的呼叫處理裝置，包括：

第一收發(fā)模塊70，用于接收主叫UE歸屬的多方通話AS發(fā)起的呼叫，向所述多方通話AS返回攜帶早期媒體的183消息，其中，所述呼叫是所述多方通話AS在接收到主叫UE發(fā)送的多方通話請求，并為所述主叫UE預留第一媒體資源后，向本裝置發(fā)送的；

資源獲取模塊71，獲取多方通話AS為本裝置預留的第二媒體資源，其中，第二媒體資源是多方通話AS基于所述183消息為本裝置預留的，且所述第二媒體資源與所述第一媒體資源不同。

第二收發(fā)模塊72，用于向所述多方通話AS發(fā)送用于指示振鈴的180消息，以觸發(fā)所述多方通話AS基于所述第二媒體資源釋放所述早期媒體。

較佳地，所述第一收發(fā)模塊70具體用于：在接收到所述多方通話AS發(fā)起的呼叫后，將所述呼叫中攜帶的第一媒體資源進行保存。

較佳地，進一步包括：

第三收發(fā)模塊73：用于在向所述多方通話AS發(fā)送用于指示接聽的200OK消息之前，向所述多方通話AS發(fā)送攜帶所述第一媒體資源的Re-INVITE消息，并接收所述多方通話AS返回針對所述Re-INVITE消息的確認消息。

較佳地，在獲取所述多方通話AS為所述被叫UE預留的第二媒體資源時，資源獲取模塊71具體用于：

接收所述多方通話AS發(fā)送的攜帶第二媒體資源的PRACK消息，并向所述多方通話AS返回針對所述PRACK消息的確認消息。

綜上所述，本發(fā)明實施例中，多方通話AS在接收到被叫UE發(fā)送的攜帶早期媒體的183消息后，向被叫UE發(fā)送攜帶與之前為主叫UE預留的媒體資源不同的其他媒體資源的PRACK消息，并接收被叫UE反饋的200OK響應，這樣在被叫UE振鈴后，多方通話AS可基于上述其他媒體資源釋放早期媒體，有效為主叫UE屏蔽所有的早期媒體，避免了在多個被叫UE均定制早期媒體的情況下，主叫UE同時接收到多個早期媒體的疊加信息，而造成主叫UE業(yè)務體驗異常，同時降低了多方通話AS的放音處理負荷。另外，在被叫UE接聽后，通過標準的SIP Re-INVITE消息進行媒體重協(xié)商，使得主被叫UE能夠正常進行數(shù)據(jù)交互，并且同時釋放上述其他媒體資源予以復用，避免了多方通話AS的運行負荷。并且，上述方法不需改變國際標準的信令流程，避免了由非標準信令流程和定制化的服務器處理能力對業(yè)務帶來的弊端。

本領域內的技術人員應明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序產品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包 含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、CD-ROM、光學存儲器等)上實施的計算機程序產品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設備(系統(tǒng))、和計算機程序產品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設備的處理器以產生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設備的處理器執(zhí)行的指令產生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數(shù)據(jù)處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設備上，使得在計算機或其他可編程設備上執(zhí)行一系列操作步驟以產生計算機實現(xiàn)的處理，從而在計算機或其他可編程設備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

盡管已描述了本發(fā)明的優(yōu)選實施例，但本領域內的技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本發(fā)明范圍的所有變更和修改。

顯然，本領域的技術人員可以對本發(fā)明實施例進行各種改動和變型而不脫離本發(fā)明實施例的精神和范圍。這樣，倘若本發(fā)明實施例的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。