專利名稱：一種業(yè)務控制單元預處理方法、裝置及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及因特網多媒體子系統(tǒng)的業(yè)務調用技術，特別涉及一種業(yè)務控 制單元預處理方法、裝置及系統(tǒng)。
背景技術：
因特網協(xié)議多媒體子系統(tǒng)(IMS, Internet Protocol Multimedia Subsystem ) 是第三代移動通信合作伙伴計劃(3GPP， 3rd Generation Partnership Project) 定義的一個IP多媒體子系統(tǒng)。IMS網絡采用會話初始化協(xié)議(SIP)作為呼 叫控制信令，是3G移動通信網絡提供統(tǒng) 一 多媒體業(yè)務和應用的目標網絡。在IMS網絡中，會話層和業(yè)務層分離，IMS為業(yè)務的調用提供必要的方法。 各種業(yè)務的宿主執(zhí)行環(huán)境稱為業(yè)務控制單元，能夠提供各種業(yè)務邏輯控制功能。 業(yè)務控制單元包括IMS應用服務器、傳統(tǒng)智能網業(yè)務控制功能實體(SCF， Service Control Function)等。以IMS應用服務器為例，在IMS網絡中提供業(yè) 務的過程包括以下三個基本步驟步驟l:定義可能的業(yè)務或業(yè)務集合；步驟2:當用戶定購/修改業(yè)務訂購關系時，以初始過濾規(guī)則(iFC， Initial Filter Criteria)的形式創(chuàng)建用戶專有的業(yè)務數(shù)據；具體來說，iFC中包含業(yè)務調用條件及其對應的應用服務器(AS， Application Server),業(yè)務調用條件由業(yè)務點觸發(fā)器(SPT， Service Point Trigger)描述，SPT的內容包括請求-統(tǒng)一資源標識(Request-URI)，標 識SIP初始請求所指向的資源；SIP方法(Method),表示該SIP初始請求 的類型；SIP頭域(Header),包含與該SIP初始請求相關的信息，可以是 任何SIP頭域及其中的頭域內容；會話情形(Session Case)，有三個可能
的值，即起始、終止或終止未注冊；會話描述(Session Description) ， SIP 方法內的任何會話描述協(xié)議(SDP, Session Description Protocol)字段內容。
步驟3:當服務-呼叫會話控制功能(S-CSCF)接收到SIP初始請求時， 根據當前會話情形和所接收到的SIP初始請求消息，執(zhí)行iFC,確定與當前 會話情形以及該SIP初始請求相對應的應用服務器，并將所接收到的SIP初 始請求傳遞給所確定的應用服務器。
通常，不同的業(yè)務可以由不同的應用服務器提供，而不同業(yè)務在應用過 程中可能會存在相互影響和沖突。例如，S-CSCF收到一個SIP邀請消息 (INVITE),依據iFC的執(zhí)行，依次調用了 AS1、 AS2、 AS3這三個應用服 務器，并將該INVITE消息發(fā)送至被叫用戶；被叫用戶終端振鈴，假設;波叫 用戶開通了無應答前轉語音郵箱服務，振鈴超時后，呼叫被前轉至語音郵箱； 語音郵箱應答，S-CSCF接收到來自于語音郵箱的應答響應消息(200 OK)， 按照現(xiàn)有技術，該200 OK消息將按照已經建立的信令路徑依次發(fā)往AS3、 AS2和AS1;而AS2接收到200 OK消息則認為這是用戶返回的200 OK消 息，將向其播放語音信息，而本例中的200 0K消息實際上是語音郵箱返回 的，顯然，AS2不能接收該200OK消息。
而且，根據IMS標準，應用服務器只能被SIP初始請求消息，如INVITE 消息、即時消息(MESSAGE)、訂閱消息(SUBSCRIBE )和參考消息(REFER) 等所觸發(fā)，即iFC中只處理SIP初始請求消息；但是，某些應用服務器實際 上只有在通信過程中的特定場景下才需要被觸發(fā)。例如，處理遇忙呼叫前轉 (Call Forwarding Busy, CFB )的應用服務器CFB AS只有在被叫用戶遇忙 時才需要被觸發(fā)，但是，由于現(xiàn)有技術在SIP初始請求時就需要建立信令路 徑，因此，CFB AS必須在SIP初始請求時就被觸發(fā)，而如果被叫用戶當前 空閑，則CFB AS將無用的處在信令路徑中，顯然，這樣降低了呼叫建立的 效率、延長了呼叫接續(xù)的時間。
此外，根據IMS標準， 一個完整、正常的呼叫建立過程將依次經過 INVITE消息、183響應碼消息、臨時確認消息(PRACK) 、 200響應碼消
息、更新消息(UPDATE) 、 200響應碼消息、180振鈴響應消息、PRACK 消息、200響應碼消息、200應答響應消息、確認消息(ACK)共11個消息。 當S-CSCF收到INVITE消息，依據iFC的執(zhí)行，調用AS1并向其發(fā)送INVITE 消息之后，此后S-CSCF所收到的10個后續(xù)呼叫建立消息，都將按照已經 建立的信令路徑發(fā)送給AS1;但實際上，AS1只需要接收INVITE消息、180 振鈴響應消息、200應答響應消息、ACK消息這共4個消息即可實現(xiàn)業(yè)務邏 輯控制，S-CSCF將所有消息都發(fā)送給AS1，降低了呼叫建立的效率、延長 呼叫了接續(xù)的時間。
由上述分析可見，由于現(xiàn)有技術中應用服務器的信令路徑在SIP初始請 求時就被固定，無法在通信后續(xù)過程中再進行調整。因此，無法解決業(yè)務控 制單元被調用之后的業(yè)務交互及沖突問題，無法按照需要向業(yè)務控制單元發(fā) 送消息，并使得呼叫建立的效率較低、呼叫接續(xù)的時間較長。

發(fā)明內容
有鑒于此，本發(fā)明的主要目的在于提供一種業(yè)務控制單元預處理方法， 以使得業(yè)務控制單元的信令路徑在通信后續(xù)過程中能夠被調整，從而解決業(yè) 務交互及沖突問題。
本發(fā)明的第二個主要目的在于提供一種業(yè)務控制單元預處理裝置，以使 得業(yè)務控制單元的信令路徑在通信后續(xù)過程中能夠被調整，從而解決業(yè)務交 互及沖突問題。
本發(fā)明的第三個主要目的在于提供一種業(yè)務控制單元預處理系統(tǒng)，以使 得業(yè)務控制單元的信令路徑在通信后續(xù)過程中能夠被調整，從而解決業(yè)務交 互及沖突問題。
為達到上述目的，本發(fā)明的技術方案具體是這樣實現(xiàn)的
一種業(yè)務控制單元預處理方法，該方法包括以下步驟
A、執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制單元及其相對應的預處理描 述信息；
B、在業(yè)務執(zhí)行過程中，根據所確定的預處理描述信息對當前通信進;f亍處理。
進一步地，在步驟A之前可以包括
AO 、根據所述被調用業(yè)務控制單元在業(yè)務執(zhí)行過程中可能出現(xiàn)的處理情 況，在所述業(yè)務過濾規(guī)則中設置與所述被調用業(yè)務控制單元相對應的預處理描 述信息。
步驟B所述進行相應的處理可以為當所述預觸發(fā)條件滿足時，執(zhí)行與所
述預觸發(fā)條件相對應的預處理方式。
其中，所述預觸發(fā)條件可以包括后續(xù)消息、會話狀態(tài)和業(yè)務控制單元調用
失敗中的至少一種；
所述預處理方式可以包括發(fā)送消息、拒絕消息、重新調用業(yè)務控制單元、
調用同質業(yè)務控制單元、調用新的業(yè)務控制單元、執(zhí)行下一條業(yè)務過濾規(guī)則、
停止執(zhí)行業(yè)務過濾規(guī)則、釋放業(yè)務控制單元和通信釋放中的至少一種。
其中，所述后續(xù)消息可以包括所述被調用業(yè)務控制單元被調用之后、直至
當前通信被釋放之前的包括釋放消息在內的所有消息中的至少 一個； 所述會話狀態(tài)可以包括當前通信的所有過程狀態(tài)中的至少一個； 所述業(yè)務控制單元調用失敗可以包括所述被調用業(yè)務控制單元沒有響應和
/或所述^皮調用業(yè)務控制單元中的業(yè)務邏輯調用失敗。
其中，所述預觸發(fā)條件中的后續(xù)消息可以包括任意后續(xù)消息的消息名稱
和/或消息內容和/或消息來源信息。
其中，所述預處理方式中的發(fā)送消息可以為向所述被調用業(yè)務控制單元
發(fā)送指定的消息。
其中，所述指定的消息可以為指定消息名稱的消息。
進一步地，所述指定的消息可以為指定消息內容和/或消息來源的消息。
其中，所述指定的消息可以包括所述預觸發(fā)條件中的后續(xù)消息。
其中，所述預處理方式中的拒絕消息可以為禁止向所述被調用業(yè)務控制
單元發(fā)送所述預觸發(fā)條件中的后續(xù)消息。
進一步地，在所述業(yè)務過濾規(guī)則中可以描述與所述被調用業(yè)務控制單元同
質的業(yè)務控制單元信息；
所述調用同質業(yè)務控制單元可以為當所述被調用業(yè)務控制單元調用失敗 時，向所述同質業(yè)務控制單元發(fā)送調用消息。
進一步地，在所述預處理描述信息中可以指定新業(yè)務控制單元的地址；
所述調用新的業(yè)務控制單元可以為當所迷預觸發(fā)條件滿足時，向所述新 業(yè)務控制單元發(fā)送調用消息。
進一步地，當所述業(yè)務控制單元調用失敗為業(yè)務控制單元中的業(yè)務邏輯調 用失敗時，所述被調用業(yè)務控制單元可以返回表示業(yè)務邏輯調用失敗的消息。
其中，所述被調用業(yè)務控制單元可以為多個業(yè)務控制單元。
進一步地，可以在所述預觸發(fā)條件中描述與所述業(yè)務控制單元調用失敗相 關的所述被調用業(yè)務控制單元。
進一步地，可以在所述預處理方式中描述所述發(fā)送消息的目的業(yè)務控制單 元，和/或所述拒絕消息的目的業(yè)務控制單元，和/或與所述重新調用業(yè)務控制單 元的來源相關的所述被調用業(yè)務控制單元，和/或與所述調用同質業(yè)務控制單元 的來源相關的所述被調用業(yè)務控制單元，和/或所述釋放業(yè)務控制單元的目的業(yè) 務控制單元。
進一步地，可以在所述預處理描述信息中描述多個被調用業(yè)務控制單元的 預觸發(fā)條件的任意組合、以及與所述預觸發(fā)條件的任意組合相對應的預處理方式。
其中，執(zhí)行步驟A所述業(yè)務過濾規(guī)則的依據是接收到業(yè)務觸發(fā)消息、或 當前通信過程狀態(tài)發(fā)生遷移。
其中，所述業(yè)務控制單元可以為因特網多媒體子系統(tǒng)IMS應用服務器或傳 統(tǒng)智能網業(yè)務控制功能實體SCF。
一種業(yè)務控制單元預處理裝置，該裝置包括預處理信息獲取模塊和預處 理方法執(zhí)行模塊；
所述預處理信息獲取模塊，用于執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制 單元及其相對應的預處理描述信息，并向所述預處理方法執(zhí)行模塊提供所述預
處理描述信息；
所述預處理方法執(zhí)行模塊，用于在業(yè)務執(zhí)行過程中，根據所述預處理信息 獲取模塊所提供的預處理描述信息對當前通信進行處理。
進一步地，該裝置還可以包括預觸發(fā)條件匹配模塊；
所述預處理描述信息可以包括預觸發(fā)條件及其對應的預處理方法；
所述預觸發(fā)條件匹配模塊，可以用于在所述業(yè)務執(zhí)行過程中，根據所述預 處理信息獲取模塊所提供的預觸發(fā)條件判斷所述預觸發(fā)條件是否滿足，當所述 預觸發(fā)條件滿足時，通知所述預處理方法執(zhí)行模塊，執(zhí)行所述預處理信息獲取 模塊所提供的預處理方法。
一種業(yè)務控制單元預處理系統(tǒng)，該系統(tǒng)包括業(yè)務過濾規(guī)則庫、業(yè)務控制 單元預處理裝置和業(yè)務控制單元；
所述業(yè)務過濾規(guī)則庫，用于保存或產生用戶的業(yè)務過濾規(guī)則，并用于向所 述業(yè)務控制單元預處理裝置提供所述業(yè)務過濾規(guī)則；
所述業(yè)務控制單元預處理裝置，用于根據業(yè)務過濾規(guī)則庫所提供的業(yè)務過 濾規(guī)則，確定與所述業(yè)務控制單元相對應的預處理描述信息，并根據所述預處 理描述信息對當前通信進行處理；
所述業(yè)務控制單元，用于根據所述業(yè)務控制單元預處理裝置的處理，提供 各種業(yè)務邏輯控制功能。
其中，當在業(yè)務處理過程中產生業(yè)務過濾規(guī)則時，所述業(yè)務控制單元，可 以進一 步用于將所產生的業(yè)務過濾規(guī)則發(fā)送給業(yè)務過濾規(guī)則庫；
所述業(yè)務過濾規(guī)則庫，可以進一步用于接收、并保存來自于所述業(yè)務控制 單元的業(yè)務過濾規(guī)則。
其中，所迷業(yè)務過濾規(guī)則庫為至少一個；
所述業(yè)務過濾規(guī)則庫可以為單獨設置的用戶簽約數(shù)據庫；
或者，可以設置于所述業(yè)務控制單元預處理裝置中，所述業(yè)務過濾規(guī)則庫 中的業(yè)務過濾規(guī)則作為程序或配置數(shù)據存在于所述業(yè)務控制單元預處理裝置之中；或者，可以設置于所述業(yè)務控制單元中，所述業(yè)務過濾規(guī)則庫中的業(yè)務過 濾規(guī)則在業(yè)務處理過程中產生。由上述技術方案可見，本發(fā)明預先根據被調用業(yè)務控制單元在業(yè)務執(zhí)行 過程中可能出現(xiàn)的處理情況，在業(yè)務過濾規(guī)則中設置與被調用業(yè)務控制單元相對應的預處理描述信息；然后執(zhí)行業(yè)務過濾規(guī)則，確定業(yè)務控制單元及其 相對應的預處理描述信息；在此后的業(yè)務執(zhí)行過程中，根據所確定的預處理 描述信息，對當前通信處理，從而能夠在通信后續(xù)過程中調整業(yè)務控制單元 的信令路徑，解決業(yè)務控制單元被調用之后的業(yè)務交互及沖突問題，并提高 呼叫建立效率、縮短呼叫接續(xù)時間。而且，本發(fā)明的預處理描述信息是根據被調用業(yè)務控制單元在業(yè)務執(zhí)行 過程中可能出現(xiàn)的處理情況設置的，而由于業(yè)務控制單元所能提供的服務能 力是可知的，因此預處理描述信息可以針對業(yè)務控制單元的服務能力、以及 不同處理情況進行設置，從而解決業(yè)務控制單元被調用之后的業(yè)務交互及沖 突問題。此外，本發(fā)明可以在一個業(yè)務過濾規(guī)則中對多個被調用業(yè)務控制單元進 行預處理，如此， 一方面可以簡化對業(yè)務過濾規(guī)則的描述和執(zhí)行；另一方面， 還可以組合出更多、更為靈活的預處理應用。


圖1為本發(fā)明較佳實施例中業(yè)務控制單元預處理方法的流程示意圖。 圖2為本發(fā)明具體實施例一至三中業(yè)務控制單元預處理方法的流程示 意圖。圖3為本發(fā)明具體實施例中業(yè)務控制單元預處理裝置的結構示意圖。 圖4為本發(fā)明具體實施例中業(yè)務控制單元預處理系統(tǒng)的結構示意圖.
具體實施方式
為使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下參照附圖并舉 實施例，對本發(fā)明作進一步詳細說明。圖1為本發(fā)明較佳實施例中業(yè)務控制單元預處理方法的流程示意圖。參見圖1，該方法包括以下步驟步驟101:執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制單元及其相對應的 預處理描述信息。本步驟中，業(yè)務過濾規(guī)則被執(zhí)行的依據是根據業(yè)務觸發(fā)消息、當前通 信的過程狀態(tài)發(fā)生了遷移等，例如，業(yè)務觸發(fā)消息可以是SIP初始請求消息 等，狀態(tài)遷移可以是從"振鈴，，狀態(tài)遷移到"終端無應答"狀態(tài)等。本發(fā)明預先根據被調用業(yè)務控制單元在業(yè)務執(zhí)行過程中可能出現(xiàn)的處 理情況，在業(yè)務過濾規(guī)則中設置與被調用業(yè)務控制單元相對應的預處理描述 信息，該預處理描述信息包括預觸發(fā)條件及其相對應的預處理方式其中，預觸發(fā)條件包括后續(xù)消息、會話狀態(tài)以及業(yè)務控制單元調用失敗 中的至少一種；預處理方式包括發(fā)送消息、拒絕消息、重新調用業(yè)務控制單 元、調用同質業(yè)務控制單元、調用新的業(yè)務控制單元、執(zhí)行下一條業(yè)務過濾 規(guī)則、停止執(zhí)行業(yè)務過濾規(guī)則、釋放業(yè)務控制單元和通信釋放中的至少一種。這里，預觸發(fā)條件中的后續(xù)消息是指該業(yè)務控制單元被調用之后(即收 到業(yè)務觸發(fā)消息或當前通信的過程狀態(tài)發(fā)生遷移之后)、直至當前通信被釋 放之前的所有消息，也包括釋放消息，例如可以是SIP初始請求消息的響應 消息、或任意SIP方法等；后續(xù)消息的消息名稱、消息內容及其任意組合都 可以作為預觸發(fā)條件；預觸發(fā)條件中可以包括一個或一個以上后續(xù)消息；預觸發(fā)條件中的會話狀態(tài)包括當前通信的所有過程狀態(tài)及其任意組合， 以3GPP TS 23.278標準為例，會話狀態(tài)包括收集信息、分析信息、路由 選擇失敗、發(fā)端一忙、發(fā)端_無應答、發(fā)端—應答、發(fā)端一拆線、發(fā)端—放棄、 終端試呼鑒權、終端一忙、終端一無應答、終端—應答、終端—拆線、終端一》丈棄，在預觸發(fā)條件中可以包括上述會話狀態(tài)中的一個或一個以上；上述每一 會話狀態(tài)的具體解釋可參見3GPP TS 23.278,這里不再贅述；預觸發(fā)條件中的業(yè)務控制單元調用失敗是指被調用業(yè)務控制單元沒有 響應，或被調用業(yè)務控制單元中的業(yè)務邏輯調用失敗等；其中，后者表示業(yè) 務控制單元被正常調用，返回了響應，但是未能如期為用戶提供相應的業(yè)務， 導致業(yè)務邏輯調用失敗的原因可能是用戶無權限或無數(shù)據使用該業(yè)務、業(yè)務 控制單元中某個功能故障等，業(yè)務邏輯調用失敗不同于業(yè)務控制單元中的業(yè) 務邏輯被正常調用但通信失敗的情況，例如呼叫限制業(yè)務被調用就屬于通信 失??；可以擴展相關協(xié)議，使得當業(yè)務邏輯調用失敗時，業(yè)務控制單元可以 返回表示業(yè)務邏輯調用失敗的消息，如一個表示業(yè)務邏輯調用失敗的SIP響 應碼或攜帶有業(yè)務邏輯調用失敗指示的SIP消息等；在實際應用中，也可以 將返回的失敗消息作為預觸發(fā)條件中的后續(xù)消息來表示業(yè)務邏輯調用失??； 在預觸發(fā)條件中，可以分別描述各種業(yè)務控制單元調用失敗的情況，例如， 業(yè)務控制單元沒有相應或業(yè)務邏輯調用失敗等，也可以將各種業(yè)務控制單元 調用失敗的情況統(tǒng)一描述。預處理方式中的發(fā)送消息為向業(yè)務控制單元發(fā)送指定的消息，預處理 方式中可以只描述所指定的消息的名稱，還可以進一步描述所指定的消息的 內容，并且，所指定的消息還可以是預觸發(fā)條件中的后續(xù)消息；預處理方式中的拒絕消息為禁止向業(yè)務控制單元發(fā)送預觸發(fā)條件中的 后續(xù)消息；預處理方式中的重新調用業(yè)務控制單元為向調用失敗的業(yè)務控制單元 重新發(fā)送調用消息；該預處理方式可以用于處理預觸發(fā)條件為業(yè)務控制單元 調用失敗的情況；預處理方式中的調用同質業(yè)務控制單元為向同質業(yè)務控制單元發(fā)送調 用消息；該預處理方式可以用于處理預觸發(fā)條件為業(yè)務控制單元調用失敗的 情況；這里，同質業(yè)務控制單元是指能提供與當前調用失敗的業(yè)務控制單元 相同服務的業(yè)務控制單元，如AS7調用失敗，AS8能提供與AS7相同的服
務，則調用AS8，向其發(fā)送消息；同質業(yè)務控制單元的地址可以與被調用業(yè) 務控制單元的地址一起設置在業(yè)務過濾規(guī)則中，如此，執(zhí)行業(yè)務過濾規(guī)則時， 就可以得到與某個業(yè)務控制單元相應的同質業(yè)務控制單元的地址；預處理方式中的調用新的業(yè)務控制單元為指定新業(yè)務控制單元的地 址，向所指定的新業(yè)務控制單元發(fā)送調用消息；上述調用同質業(yè)務控制單元 也可以通過本方式實現(xiàn)，即在本方式中設置同質業(yè)務控制單元的地址；預處理方式中的執(zhí)行下一條業(yè)務過濾規(guī)則為若存在下一條業(yè)務過濾規(guī) 則，則執(zhí)行下一條業(yè)務過濾規(guī)則；預處理方式中的停止執(zhí)行業(yè)務過濾規(guī)則為若存在下一條業(yè)務過濾規(guī) 則，則停止執(zhí)行后續(xù)的業(yè)務過濾規(guī)則，并繼續(xù)處理當前通信，例如，繼續(xù)向 凈皮叫路由；預處理方式中的釋放業(yè)務控制單元為釋放已經被調用的業(yè)務控制單 元， 一般的，也可以釆用將預處理方式中的發(fā)送消息設定為釋放消息，例如 SIPBYE消息、SIP撤消(CANCEL)消息等，表示釋放已經被調用的業(yè)務 控制單元。預處理方式中的通信釋放為釋放當前通信。步驟102:在業(yè)務執(zhí)行過程中，根據所確定的預處理描述信息對當前通 信進行處理。本步驟中，當預處理描述信息中的預觸發(fā)條件滿足時，按照預處理描述 信息中的預處理方式進行相應的處理。至此，完成本發(fā)明業(yè)務控制單元預處理方法。上述方法中，業(yè)務控制單元是各種業(yè)務的宿主執(zhí)行環(huán)境，能夠提供各種 業(yè)務邏輯控制功能。業(yè)務控制單元為IMS應用服務器、傳統(tǒng)智能網業(yè)務控 制功能實體(SCF， Service Control Function)等。下面的實施例中以IMS 應用服務器為例進行說明。實施例一本實施例中，假設收到一個SIP INVITE消息，調用了IMS應用服務器AS1，其后，在被叫用戶無應答時，呼叫被前轉至語音郵箱，語音郵箱應答, 返回200 0K應答響應消息，而ASl不希望收到系統(tǒng)自動應答的200 OK消 息，因此，應當對ASl屏蔽該200 0K消息。為了實現(xiàn)對ASl屏蔽系統(tǒng)自動應答的200 OK消息，本實施例中采用對 現(xiàn)有iFC進行擴展的方式，預先在業(yè)務過濾規(guī)則中設置與ASl相對應的預 處理描述信息。為簡化起見，以下僅列出一個完整業(yè)務過濾規(guī)則中與本實施 例相關的業(yè)務過濾規(guī)則片斷<TriggerPoint> <SPT><Method>INVITE</Method> </SPT> </TriggerPoint > <ApplicationServer><ServerName>sip:asl@ims.example.com</ServerName> <Pretreatment><PreTriggerMessage><MessageName>200</MessageName><Origination>No—ApplicationServer—SameCall</Origination><SIPHeader><Header>Contact</Header> <Content>automata</Content> </SIPHeader> </PreTriggerMessage> <PreHandlingMode><Mode>Rej ectMessage</Mode> </PreHandlingMode> </Pretreatment> </ApplicationServer>
為描述方便，在本實施例中將上述業(yè)務過濾規(guī)則片斷稱為業(yè)務過濾規(guī)則一。 以下對本實施例中業(yè)務控制單元預處理方法的說明，也著重描述與該業(yè)務過濾 規(guī)則片斷相關的部分。圖2為本發(fā)明具體實施例一至三中業(yè)務控制單元預處理方法的流程示意 圖。參見圖2，該方法包括以下步驟步驟201:根據業(yè)務觸發(fā)消息INVITE,執(zhí)行業(yè)務過濾規(guī)則，確定被調用應 用服務器及其相對應的預處理描述信息。本步驟中所執(zhí)行的業(yè)務過濾規(guī)則如業(yè)務過濾規(guī)則一所示，其中， <TriggerPoint>與〈/TriggerPoint〉之間的內容為觸發(fā)點信息，表示該業(yè)務過濾規(guī) 則的觸發(fā)條件，本實施例中，該業(yè)務過濾規(guī)則的觸發(fā)條件是取值為INVITE的 方法(Method)業(yè)務點觸發(fā)器(SPT)。本步驟中，根據INVITE消息執(zhí)行業(yè)務過濾規(guī)則一之后，得到被調用應用 服務器名(ServerName)及其相對應的預處理描述信息(Pretreatment),即 如業(yè)務過濾頭見則 一所示〈ApplicationServer〉與〈/ApplicationServer〉之間的內容。其中，ServerName表示被調用應用服務器地址，本實施例中，取值為 sip:asl@ims.example.com,代表AS1的地址；如果存在與AS1同質的業(yè)務控制 單元，可以在這里設置AS1的同質業(yè)務控制單元的地址；〈PretreatmenP與〈/Pretreatment〉之間的內容表示與AS1相對應的預處理描 述信息，這部分內容就是本實施例對業(yè)務過濾規(guī)則的擴展描述。預處理描述信 息包括預觸發(fā)條件及其相對應的預處理方式；同一業(yè)務控制單元在不同情況下 可能存在不同的預處理描述信息，本發(fā)明中，可以釆用一個〈Pretreatment〉 〈/PretreatmenP描述所有預觸發(fā)條件及其相對應的預處理方式，也可以采用多個式；預處理描述信息中，〈PreTriggerMessage〉與〈/PreTriggerMessag^之間的內 容表示預觸發(fā)條件，該部分內容可以由任意后續(xù)消息的消息名稱、消息內容以 及該消息的來源信息組成；〈PreHandlingMode〉與〈/PreHandlingModO之間的內 容表示與預觸發(fā)條件相對應的預處理方式。如業(yè)務過濾規(guī)則一所示的預觸發(fā)條件中包括消息名稱(MessageName )、 消息來源(Origination )、 SIP頭域(SIPHeader )、頭域(Header)和頭域的內容 (Content);其中，MessageName表示后續(xù)消息的名稱，本實施例中，取值為200;Origination表示后續(xù)消息的來源，由于后續(xù)消息既可以是被調用業(yè)務控制 單元收到調用消息后返回的消息，也可以是來自于其它設備的消息；而且，后 續(xù)消息既可以與調用消息位于同 一通信中，如被調用業(yè)務控制單元返回的初始 請求消息的后續(xù)呼叫建立消息；也可以位于與調用消息不同的通信中，如本實 施例中的200 OK消息既可能是上述INVITE消息的的響應消息，還可能是一個 新的呼叫的響應消息，因此，需要指明后續(xù)消息的來源，即來自哪個設備及哪 個通信，進一步地，可以根據實際應用的需要，具體指明來源設備的名稱、類 型、屬性及地址等。本發(fā)明通過設置來源標識以表示后續(xù)消息的來源，例如， 針對后續(xù)消息是否來自于被調用業(yè)務控制單元、后續(xù)消息與調用消息是否位于 同一通信中設置不同的來源標識；本實施例中，將后續(xù)消息的來源標識設置為 NoApplicationServer—SameCall ，其中，No—ApplicationServer表示后續(xù)消息200 不是由被調用業(yè)務控制單元發(fā)出，SameCall表示后續(xù)消息200與調用消息位于 同一通信中；〈SIPHeader〉與々SIPHeader〉之間的內容表示后續(xù)消息的SIP頭域內容，本 實施例中，將Header設置為聯(lián)系頭域(Contact )， Content頭域內容設置為自動 操作(automata);預處理方式中的方式(Mode)表示與預觸發(fā)條件相對應的預處理方式，本 實施例中，設置為表示拒絕消息(RejectMessage)的預處理方式。步驟202:記錄被調用應用服務器的預處理描述信息，并向被調用應用服 務器發(fā)送INVITE消息，即初始調用該應用服務器。本步驟中，根據步驟201所執(zhí)行的業(yè)務過濾規(guī)則一，得到被調用應用服務 器AS1及其相對應的預處理描述信息，記錄AS1的預處理描述信息、向AS1 發(fā)送INVITE消息。步驟203:根據業(yè)務執(zhí)行過程中所接收到的后續(xù)消息、當前會話狀態(tài)以及 業(yè)務控制單元的調用失敗，對照所記錄的預處理描述信息，判斷預觸發(fā)條件是 否滿足，當預觸發(fā)條件滿足時，使用預處理描述信息中相應的預處理方式處理 當前通信。本步驟中，當收到來自于語音郵箱的200 OK應答響應消息時，將該200 OK 應答響應消息與所記錄的預觸發(fā)條件進行匹配由于該200 OK消息是來自于 語音郵箱的應答，因此消息中的Contact頭域中設置了 "automata",表示這是一 個來自于系統(tǒng)的自動應答；而且，該200 OK消息不是由被調用業(yè)務控制單元 發(fā)出的，且與調用消息位于同一通信中，因此，與步驟202所記錄的預觸發(fā)條 件匹配成功。匹配成功之后，使用預處理描述信息中與該預觸發(fā)條件相對應的 預處理方式處理相應的業(yè)務控制單元，本實施例中，預處理方式為表示拒絕消 息的處理方式，即不把該200 0K應答響應消息發(fā)向AS1。類似的，通過將183、 PRACK消息、UPDATE消息等對業(yè)務控制單元處理 業(yè)務邏輯控制無用的后續(xù)呼叫建立消息作為預觸發(fā)條件中的后續(xù)消息，并將與 之相應的預處理方式設置為拒絕消息，就可以實現(xiàn)按照需要向業(yè)務控制單元發(fā) 送消息，將對業(yè)務控制單元處理業(yè)務邏輯控制無用的后續(xù)呼叫建立消息向業(yè)務 控制單元屏蔽，從而簡化了呼叫處理、提高了呼叫建立效率、縮短了呼叫接續(xù) 時間。至此，結束本實施例業(yè)務控制單元預處理方法。由上述實施例可見，本實施例預先根據被調用應用服務器AS1在業(yè)務執(zhí)行 過程中可能出現(xiàn)的處理情況，在業(yè)務過濾規(guī)則一中設置與AS1相對應的預處理 描述信息；然后，根據業(yè)務觸發(fā)消息INVITE執(zhí)行業(yè)務過濾規(guī)則一，得到與AS1 相對應的預處理描述信息；在此后的業(yè)務執(zhí)行過程中，4艮據所確定的預處理描 述信息，處理ASl,從而實現(xiàn)了根據需要調整被調用業(yè)務控制單元的信令路徑， 解決了業(yè)務交互及沖突問題，此外，還能夠提高呼叫建立效率、縮短呼叫接續(xù) 時間。
在上述實施例中，以預觸發(fā)條件為后續(xù)消息、預處理方式為拒絕消息的情 況為例對本發(fā)明技術方案進行了詳細的說明。在實際應用中，當會話狀態(tài)發(fā)生遷移時，也可能滿足預觸發(fā)條件；而對于業(yè)務控制單元而言，也存在其他的預 處理方式，例如發(fā)送消息的方式，在下面的實施例二中將對這些情況下如何實 施本發(fā)明進行詳細說明。 實施例二本實施例中，假設收到一個SIP INVITE消息，調用了 IMS應用服務器AS2, 其后，在^皮叫用戶無應答時，AS2希望退出當前通信，因此，應當向AS2發(fā)送 新的調用消息。為了在被叫用戶無應答時，實現(xiàn)AS2退出當前通信，本實施例中采用對現(xiàn) 有iFC進行擴展的方式，預先在業(yè)務過濾規(guī)則中設置與AS2相對應的預處理描 述信息。為簡化起見，以下僅列出一個完整業(yè)務過濾規(guī)則中與本實施例相關的 業(yè)務過濾規(guī)則片斷<TriggerPoint> <SPT><Method>INVITE</Method> </SPT> 〈/TriggerPoint > <ApplicationServer><ServerName>sip:as2@ims.example.com</ServerName> <Pretreatment><PreTriggerSessionState><SessionState>Terminating_NoAnswer</SessionState> </PreTriggerSessionState> <PreHandlingMode〉<Mode>NewMessage</Mode><MessageName>BYE</MessageName><Origination>SameCallWithInvokingMessage</Origination></PreHandlingMode> </Pretreatment> </ApplicationServer>為描述方便，在本實施例中將上述業(yè)務過濾規(guī)則片斷稱為業(yè)務過濾規(guī)則二。 以下對本實施例中業(yè)務控制單元預處理方法的說明，也著重描述與該業(yè)務過濾 規(guī)則片斷相關的部分。本實施例中業(yè)務控制單元預處理方法的流程示意圖與實施例一中圖2相 同，請參見圖2。本實施例中，業(yè)務控制單元預處理方法包括以下步驟在步驟201中，根據業(yè)務觸發(fā)消息INVITE,執(zhí)行業(yè)務過濾規(guī)則，確定被調 用應用服務器及其相對應的預處理描述信息。本步驟中所執(zhí)行的業(yè)務過濾規(guī)則如業(yè)務過濾規(guī)則二所示，〈TriggerPoinP與 々TriggerPoint〉之間的內容為觸發(fā)點信息，與實施例一相同，本實施例中業(yè)務過 濾規(guī)則的觸發(fā)條件是取值為INVITE的方法(Method)業(yè)務點觸發(fā)器(SPT)。本步驟中，根據INVITE消息執(zhí)行業(yè)務過濾規(guī)則二之后，與實施例一類似， 得到被調用應用服務器名(ServerName)及其相對應的預處理描述信息 (Pretreatment )， 即戈口業(yè)務過濾規(guī)貝'J 二所示<ApplicationServer>與 〈/ApplicationServer〉之間的內容；其中，ServerName表示被調用應用服務器地址，本實施例中，取值為 sip:as2敏ms.example.com, 代表AS2的地址；其中，〈Pretreatment〉與〈/Pretreatment〉之間的內容表示與AS2相對應的預 處理描述信息，這部分內容就是本實施例對業(yè)務過濾規(guī)則的擴展描述。預處理描述信息中，〈PreTriggerSessionState〉與〈/PreTriggerSessionState〉之 間的內容表示預觸發(fā)條件，該部分內容可以是任意會話狀態(tài)的名稱及其相關的 任何內容；〈PreHandUngMode〉與〈/PreHandlingMode〉之間的內容表示與預觸發(fā) 條件相對應的預處理方式。如業(yè)務過濾規(guī)則二所示的預觸發(fā)條件中，會話狀態(tài)(SessionState)表示會 話狀態(tài)的名稱，本實施例中，取值為終端—無應答(Terminating_NoAnswer); 本實施例中，設置為表示發(fā)送消息(NewMessage)的預處理方式，并在消息名稱 (MessageName)中指定該新消息為再見消息(BYE)。與指明后續(xù)消息的來源 類似，這里需要指明該新消息的來源，可以設置來源標識以指明該新消息的來 源，例如，根據該新消息與對應的后續(xù)消息以及業(yè)務觸發(fā)消息的關系是否位 于同一會話或是否位于同一通信中，設置相應的來源標識；本實施例中，將新 消息的Origination設置為SameCallWithlnvokingMessage,表示該BYE消息與 AS2的調用消息，即業(yè)務觸發(fā)消息INVITE屬于同一通信過程。在步驟202中，記錄步驟201所得到的的預處理描述信息，并向AS2發(fā)送 INVITE消息，即初始調用AS2。在步驟203中，根據業(yè)務執(zhí)行過程中所接收到的后續(xù)消息、當前會話狀態(tài) 以及業(yè)務控制單元的調用失敗，對照所記錄的預處理描述信息，判斷預觸發(fā)條 件是否滿足，當預觸發(fā)條件滿足時，使用預處理描述信息中相應的預處理方式 處理當前通信。本步驟中，當用戶的會話狀態(tài)遷移為終端一無應答時，將該會話狀態(tài)與所記 錄的預觸發(fā)條件進行匹配，匹配成功，使用預處理描述信息中與該預觸發(fā)條件 相對應的預處理方式處理相應的應用服務器。本實施例中，根據會話狀態(tài)和預 處理描述信息獲得相應的預處理方式為發(fā)送消息，所指定的消息名稱為BYE, 向AS2發(fā)送SIP BYE消息，使AS2退出當前通信，即AS2只處理用戶終端的 應答，只要會話狀態(tài)是用戶無應答，AS2就退出當前通信。至此，結束本實施例業(yè)務控制單元預處理方法。由上述實施例可見，本實施例預先根據被調用應用服務器AS2在業(yè)務執(zhí)行 過程中可能出現(xiàn)的處理情況，在業(yè)務過濾規(guī)則二中設置與AS2相對應的預處理 描述信息；然后，根據業(yè)務觸發(fā)消息INVITE執(zhí)行業(yè)務過濾規(guī)則二，得到與AS2 相對應的預處理描述信息；在此后的業(yè)務執(zhí)行過程中，根據所確定的預處理描 述信息，處理AS2，從而實現(xiàn)了根據需要調整被調用業(yè)務控制單元的信令路徑， 解決了業(yè)務交互及沖突問題。 在上述實施例中，給出了被調用業(yè)務控制單元在同 一個通信過程中被調整 的示例，即所描述的初始調用和預觸發(fā)條件是當用戶處于同 一個通信過程中的 情況下，對被調用業(yè)務控制單元的相關處理。在實際應用中，被調用業(yè)務控制 單元的初始調用和預觸發(fā)條件所描述的處理也可以是用戶在不同通信過程中的 相關處理，例如，被調用業(yè)務控制單元已經處于一個通信過程中，當用戶發(fā)起 或收到另一個通信時，將引起被調用業(yè)務控制單元的調整，在下面的實施例三 中將對這些情況下如何實施本發(fā)明進行介紹。實施例三本實施例中，假設收到一個SIP INVITE1消息，調用了 IP電視(IPTV) AS ，向用戶提供IPTV服務；其后，當用戶收到 一個呼入來話SIP INVITE2消 息時，IPTV AS應暫停向用戶播放視頻流媒體，以便用戶能夠接受該新呼入來 話，并與新呼入來話的主叫方建立通話；此后，當該新呼入來話被釋放時，IPTV AS應恢復向用戶播ii^見頻流:煤體。因此，在本實施例中存在兩個通信過程，一 個是用戶與IPTV之間的通信，另一個是用戶與新呼入來話主叫方之間的通4言。為了在用戶收到一個新呼入來話時，實現(xiàn)IPTVAS暫停服務，并在新呼入 來話被釋放時實現(xiàn)IPTV AS恢復服務，本實施例中采用對現(xiàn)有iFC進行擴展的 方式，預先在針對INVITE 1消息的業(yè)務過濾規(guī)則中設置與IPTVAS相對應的預 處理描述信息。為簡化起見，以下僅列出一個完整業(yè)務過濾規(guī)則中與本實施例 所調用的IPTVAS相關的預處理描述信息片斷<Pretreatm6nt> <PreTriggerMessage><MessageName>INVITE</MessageName><Origination>DifferentCall</Origination> </PreTriggerMessage> <PreHandlingMode><Mode>SameMess￡^e</Mode> </PreHandlingMode><PreTriggerMessage><MessageName>BYE</MessageName> </PreTriggerMessage> <PreHandlingMode><Mode>SameMessage</Mode> </PreHandlingMode> </Pretreatmcnt>為描述方便，在本實施例中將上述預處理描述信息片斷稱為預處理描述信 息三。以下對本實施例中業(yè)務控制單元預處理方法的說明，也著重描述與該預 處理描述信息片斷相關的部分。本實施例中業(yè)務控制單元預處理方法的流程示意圖與實施例一中圖2相 同，請參見圖2。本實施例中，業(yè)務控制單元預處理方法包括以下步驟在步驟201中，根據業(yè)務觸發(fā)消息INVITEl,執(zhí)行業(yè)務過濾規(guī)則，確定被 調用應用服務器及其相對應的預處理描述信息。本步驟中根據業(yè)務觸發(fā)消息INVITE1執(zhí)行業(yè)務過濾規(guī)則之后，得到與IPTV AS相對應的預處理描述信息，如預處理描述信息三所示其中，第 一個〈PretreatmenP與〈/Pretreatmen1^之間的內容為針對新呼入來 話的預處理描述信息MessageName設置為INVITE消息，Origination設置為 Different Call,表示預觸發(fā)條件是來自于不同通信的INVITE消息；Mode設置 為SameMessage，表示預處理方式為向IPTVAS發(fā)送預觸發(fā)條件中的后續(xù)消息， 即新呼入來話的INVITE消息，因此這里不需要再設定消息名稱；第二個〈Pretreatment〉與〈/PretreatmenP之間的內容為針對呼入來話凈皮釋放 的預處理描述信息MessageName設置為BYE消息，表示預觸發(fā)條件是BYE 消息；Mode設置為SameMessage,表示預處理方式是向IPTV AS發(fā)送BYE消 息，即預處理方式中所指定的發(fā)送消息是預觸發(fā)條件中的后續(xù)消息。與針對新呼入來話的預處理描述信息類似，在針對呼入來話被釋放的預處
理描述信息中同樣可以指明后續(xù)消息BYE的來源?？梢詫⒑罄m(xù)消息置于業(yè)務過 濾規(guī)則中的特定位置以指明消息來源，為此，本實施例提供了兩種指明消息來 源的方式第一種方式是將具有相同來源的后續(xù)消息置于預處理描述信息的同一子層 中，并以各后續(xù)消息在預處理描述信息中的先后次序確定各后續(xù)消息的來源， 即在后消息是在前消息的后續(xù)消息，也即在后消息與在前消息具有相同來源， 因此，在后消息無需以來源標識指明消息來源；如預處理描述信息三所示，將 對BYE消息的預處理描述信息和對INVITE消息的預處理描述信息設置在同一 〈Pretreatment〉與〈/Pretreatment〉之間，并將BYE消息的預處理描述信息置于 INVITE消息的預處理描述信息之后，以表示該BYE消息是位于INVITE消息 之后的后續(xù)呼叫建立消息，因此只需指明INVITE消息的來源即可；第二種方式是將一個后續(xù)消息的預處理描述信息作為子預處理描述信息， 嵌套設置在另一個后續(xù)消息的預處理描述信息中，以表明前者是后者按其預處 理方式處理當前通信之后的后續(xù)消息，并在子預處理描述信息中指明相應的后 續(xù)消息的來源；按照第二種方式設置的本實施例中IPTVAS的預處理描述信息 如下所示<Pretreatment><PreTriggerMessage><MessageName>INVITE</MessageName><Origination>DifferentCall</Origination> </PreTriggerMessage> <PreHandlingMode><Mode>SameMessage</Mode> </PreHandlingMode><SubPretreatment><PreTriggerM6Ssage><MessageName>BYE</MessageName><Origination>SameCall</Origination > </PreTriggerMessage> <PreHandlingMode><Mode>SameMessage</Mode> </PreHandlingMode> </SubPretreatment> </Pretreatment>在上述預處理描述信息中，SubPretreatment表示嵌套的子預處理， 〈SubPretreatment〉與〈/SubPretreatment〉之間的內容為后續(xù)消息BYE的預處理 描述信息，這部分內容嵌套設置于INVITE消息的預處理描述信息之中，以表 示該BYE消息是按照該INVITE消息的預處理方式處理當前通信之后的后續(xù)消 息；BYE消息的Origination設置為SameCall，表示該后續(xù)消息BYE與其上一 級后續(xù)消息INVITE位于同 一通信中。在步驟202中，記錄步驟201所得到的IPTV AS的預處理描述信息、并初 始調用IPTV AS。在步驟203中，根據業(yè)務執(zhí)行過程中所接收到的后續(xù)消息、當前會話狀態(tài) 以及業(yè)務控制單元的調用失敗，對照所記錄的預處理描述信息，判斷預觸發(fā)條 件是否滿足，當預觸發(fā)條件滿足時，使用預處理描述信息中相應的預處理處理 當前通信。本步驟中，當收到新呼入來話INVITE2消息時，才艮據所確定的預處理描述 信息，向IPTVAS發(fā)送該INVITE2消息；IPTVAS收到該INVITE2消息，解 析之后確定這是一個新的用于建立通話的呼入來話，則IPTV AS暫停對用戶的 服務；此后，新呼入來話被釋放，IPTVAS收到BYE消息，解析之后確定這是 對新呼入來話的釋放，則IPTVAS恢復對用戶的服務。 至此，結束本實施例業(yè)務控制單元預處理方法。 本實施例中，也可以按照如下方式設置預處理描述信息 預先在業(yè)務過濾規(guī)則中設置對IPTVAS的預觸發(fā)條件和預處理方式，其中， 針對預觸發(fā)條件INVITE2消息的預處理方式是向IPTV AS發(fā)送一個新的 INVITE3消息，并指定該INVITE3消息的內容為將INVITE1消息建立會話 的媒體方向設置為"去激活(inactive)",即該INVITE3消息是一個re-INVITE 消息(re-INVITEl );針對預觸發(fā)條件BYE消息的預處理方式是向IPTV AS發(fā) 送一個INVITE4消息，該消息也是re-INVITEl消息，其媒體方向設置為"激活(active)";并將上述INVITE3消息和INVITE4消息的Origination設置為 SameDialogWithlnvokingMessage，表示INVITE3和INVITE4與調用消息，即 業(yè)務觸發(fā)消息INVITE1位于同一會話中，即與INVITE1具有相同的對話(Dialog)標識；然后，根據業(yè)務觸發(fā)消息INVITEl執(zhí)行業(yè)務過濾規(guī)則，得到與IPTV AS 相對應的預處理描述信息；此后在業(yè)務執(zhí)行過程中，當收到INVITE2消息時，根據所確定的預處理描 述信息，向IPTV AS發(fā)送INVITE3消息；IPTV AS收到該INVITE3消息，將 INVITEl消息建立會話的媒體方向設置為去激活，即不向用戶發(fā)送媒體；當新 呼入來話被釋放時，即收到BYE消息時，向IPTVAS發(fā)送INVITE4消息，將 INVITEl消息建立會話的媒體方向設置為激活，IPTVAS恢復服務。以上是對本發(fā)明實施例三的說明，下面通過實施例四來說明預處理方式為 執(zhí)行下 一條業(yè)務過濾規(guī)則的具體實施方法。實施例四本實施例中，假設用戶發(fā)起一個INVITE消息，并在INVITE消息的要求 頭域(Require)中描述了協(xié)議擴展或者在INVITE消息體中描述了某種媒體類 型，執(zhí)行業(yè)務過濾規(guī)則之后，調用了一個提供彩鈴業(yè)務的彩鈴業(yè)務AS;當被調碼(BadExtension),或者當被調用彩鈴業(yè)務AS不支持消息體中所描述的媒體 類型時將返回415不支持的媒體類型響應碼(Unsupported Media Type)。本實按照現(xiàn)有技術，AS4只會在SIP初始請求時被調用，當彩鈴業(yè)務AS返回420
響應碼或415響應碼時，AS4將不會被調用，即AS4將無法加入到用戶的呼叫 信令路徑中。但是，由于彩鈴業(yè)務不是呼叫建立過程中的必須業(yè)務，用戶希望 在彩鈴業(yè)務不能正常提供的情況下，后續(xù)業(yè)務依然能夠正常提供，以提高呼叫接續(xù)成功率。為了實現(xiàn)在彩鈴業(yè)務AS不能正常提供業(yè)務的情況下，AS4能夠被正常調 用，本實施例預先在業(yè)務過濾規(guī)則中設置如下所示的預處理描述信息<Pretreatment><PreTriggerMessage><MessageName>420</MessageName> <Origination>FromApplicationServer</Origination> <MessageName>415</MessageName> <Origination>FromApplicationServer</Origination></PreTriggerMessage><PreHandlingMode><Mode>GoNextFilterCriteria</Mode></PreHandlingMode> </Pretreatm6nt>上述預處理描述信息中，預觸發(fā)條件中后續(xù)消息的名稱是420消息和415 消息，Origination i殳置為FromApplicationServer，表示這是凈皮調用彩鈴業(yè)務AS 的返回消息；并且在預觸發(fā)條件中包含了一個以上的后續(xù)消息，表示這些后續(xù) 消息具有相同的預處理方式；預處理方式中，Mode設置為GoNextFilterCriteria，表示執(zhí)行下一條業(yè)務過 濾規(guī)則。如此，在業(yè)務執(zhí)行過程中，當預觸發(fā)條件滿足時，AS4的業(yè)務過濾規(guī)則將 被執(zhí)行，AS4將加入到用戶的呼叫信令路徑中，實現(xiàn)了對業(yè)務控制單元的信令 路徑的調整，解決了業(yè)務交互和沖突問題，并提高了呼叫建立效率。通常，可以使用彩鈴業(yè)務AS的業(yè)務觸發(fā)消息INVITE來執(zhí)行AS4的業(yè)務
過濾規(guī)則，當然也可以在此進一步指定下一條業(yè)務過濾規(guī)則的執(zhí)行依據。在上面的實施例四中，以預觸發(fā)條件是后續(xù)消息、預處理方式是執(zhí)行下一 條業(yè)務過濾規(guī)則為例，對本發(fā)明的具體實施方式
進行了詳細說明，下面的實施 例五中對預觸發(fā)條件是后續(xù)消息、預處理方式是停止執(zhí)行業(yè)務過濾規(guī)則的情況 進行詳細說明。實施例五本實施例中，假設用戶發(fā)起一個INVITE消息，執(zhí)行業(yè)務過濾規(guī)則之后， 調用了應用服務器AS5; AS5檢測到該呼叫是一個緊急呼叫，因此在返回的 INVITE消息中設置緊急標志；在遇到緊急呼叫時，應停止使用其他業(yè)務，并繼 續(xù)向被叫路由該呼叫。為此，本實施例預先在業(yè)務過濾規(guī)則中設置如下所示的 預處理描述信息<Pretreatment><PreTriggerMessage><MessageName〉INVTTE</MessageName><Origination>FromApplicationServer</Origination><SIPHeader><Header>Priority</Header> <Content>urgent</Content> </SIPHeader> </PreTriggerMessage> <PreHandlingMode><Mode>StopNextFilterCriteria</Mode> </PreHandlingMode> </Pretreatment>上述預處理描述信息中，預觸發(fā)條件中后續(xù)消息的名稱是INVITE消息， Origination設置為FromApplicationServer,表示這是被調用應用服務器AS5的 返回消息；Header設置為Priority頭域，Content設置為緊急(urgent),表示這是一個緊急呼叫；
預處理方式中，Mode設置為StopNextFilterCriteria，表示停止執(zhí)行業(yè)務過濾規(guī)則。這樣，在業(yè)務執(zhí)行過程中，當預觸發(fā)條件滿足時，如果AS5的業(yè)務過濾規(guī) 則之后還存在后續(xù)業(yè)務過濾規(guī)則，將停止執(zhí)行后續(xù)業(yè)務過濾規(guī)則，即將后續(xù)業(yè) 務過濾規(guī)則對應的業(yè)務控制單元排除在用戶的呼叫信令路徑之外；并繼續(xù)向被 叫路由該呼叫。如此，實現(xiàn)了對業(yè)務控制單元的信令路徑的調整，解決了緊急 業(yè)務與其他業(yè)務的沖突，并提高了呼叫建立效率、縮短了呼叫接續(xù)時間。以上通過實施例五介紹了預觸發(fā)條件是后續(xù)消息、預處理方式是停止執(zhí)行 后續(xù)業(yè)務過濾的本發(fā)明具體實施方式
，下面通過實施例六說明如何在業(yè)務控制 單元調用失敗時，按照實際需要實施調用新的業(yè)務控制單元這一預處理方式。實施例六本實施例中，假設用戶發(fā)起一個INVITE消息，執(zhí)行業(yè)務過濾規(guī)則之后， 調用了應用服務器AS6;而AS6當前狀態(tài)為"忙"，無法處理業(yè)務邏輯控制， 因此，返回486此處忙響應碼(Busy Here),此時應調用遇忙呼叫前轉(Call Forwarding Busy, CFB ) AS。為了實現(xiàn)根據實際需要調用CFB AS，本實施例 在業(yè)務過濾規(guī)則中設置的預處理描述信息如下所示<Pretreatment><PreTriggerMessage><MessageName>486</MessageName><Origination>FromApplicationServer</Origination> </PreTriggerMessage> <PreHandlingMode><Mode>InvokingNewApplicationServer</Mode><ServerName>sip:cfb-as@ims.example.com</ServerName> </PreHandlingMode> </Pretreatm6nt>上述預處理描述信息中，預觸發(fā)條件中后續(xù)消息的名稱是486消息， Origination設置為FromApplicationServer，表示這是被調用應用服務器AS6的 返回的調用失敗消 息;預處理方式中，Mode設置為InvokingNewApplicationServer，表示調用新 的業(yè)務控制單元，并在ServerName中設置新業(yè)務控制單元的名稱，例如，本實 施例中設置為sip:cfb-as@ims.example.com,即CFB AS的地址。如此，在業(yè)務執(zhí)行過程中，當預觸發(fā)條件滿足時，呼叫將發(fā)向CFBAS的 地址，即只有在業(yè)務控制單元的觸發(fā)條件滿足時，才調用該業(yè)務控制單元，實 現(xiàn)了根據實際需要調用業(yè)務控制單元，解決了業(yè)務交互和沖突問題，并提高了 呼叫建立效率、縮短了呼叫接續(xù)時間。通常，可以使用AS6的業(yè)務觸發(fā)消息INVITE來調用CFB AS的業(yè)務過濾 規(guī)則，當然也可以在此進一步指定發(fā)向新的業(yè)務控制單元的調用消息。至此，結束對本發(fā)明實施例六中業(yè)務控制單元預處理方法的說明。在上述實施例中，給出了在一個業(yè)務過濾規(guī)則中描述與一個被調用業(yè)務控 制單元相關的預處理描述信息的具體實施方式
，即在一個業(yè)務過濾規(guī)則中對一 個被調用業(yè)務控制單元進行預處理。除此之外，本發(fā)明還支持在一個業(yè)務過濾 規(guī)則中對一個以上被調用業(yè)務控制單元進行預處理，下面的實施例七中將對這 種情況下如何實施本發(fā)明進行介紹。實施例七本實施例中，假設IMS應用服務器AS1和AS2在收到INVITE消息后 被調用，其后，在被叫用戶無應答時，AS1和AS2都希望退出當前通信。 為了實現(xiàn)在被叫用戶無應答時，AS1和AS2退出當前通信，本實施例預先 針對AS1和AS2設置了如下所示的業(yè)務過濾規(guī)則<TriggerPoint> <SPT><Method>INVITE</Method> </SPT> 〈/TriggerPoint > <ApplicationServer><ServerName>sip:as 1 @ims.example.com</ServerName> < ServerName〉sip: as2敏ms. example com</ServerName> <Pretreatment><PreTriggerSessionState〉<SessionState〉Terminating—NoAnswer</SessionState> </PreTriggerSessionState> <PreHandlingMode><Mode>NewMessage</Mode> <MessageName>BYE</MessageName> <Origination>SameCallWithInvokingMessage</Origination〉 </PreHandlingMode〉 </Pretreatment> </ApplicationServer〉在上述業(yè)務過濾規(guī)則中，〈ApplicationServer〉與〈/ApplicationServer〉之間的 內容表示被調用應用服務器；本實施例中，給出了兩個被調用應用服務器名 sip:asl@ims.example.com和sip:as2@ims.example.com，表示該業(yè)務過濾規(guī)則對 這兩個應用服務器ASl和AS2都有效；業(yè)務過濾規(guī)則被執(zhí)行后，ASl和AS2 將被調用， 一般的，可以按先后順序調用ASl和AS2，也可以在業(yè)務過濾規(guī)則 中指明其它的調用方式，如同時調用等；預觸發(fā)條件中的會話狀態(tài)為被叫無應答(Terminating—NoAnswer)，預處理 方式為發(fā)送BYE消息，發(fā)送消息的Origination為SameCallWithlnvoking Message,表示該發(fā)送消息和ASl和AS2的調用消息位于同一通信中。這樣，在業(yè)務執(zhí)行過程中，當預觸發(fā)條件被叫無應答滿足時，將向對應的 被調用業(yè)務控制單元ASl和AS2發(fā)送SIP BYE消息，使其退出。一般的，預處理方式中的所指定的發(fā)送消息是發(fā)向當前業(yè)務過濾規(guī)則中的 所有被調用業(yè)務控制單元，當然，也可以在此指定該消息的目的地，即發(fā)往哪 個被調用業(yè)務控制單元。在本實施例中，AS1和AS2共用了相同的預觸發(fā)條件
及其對應的預處理方式，在實際應用中，也可以分別描述AS1和AS2的預觸發(fā) 條件及其對應的預處理方式。本發(fā)明所提供的技術方案，可以在一個業(yè)務過濾規(guī)則中出現(xiàn)一個以上^史調 用業(yè)務控制單元，并且，對這些被調用業(yè)務控制單元的預處理描述信息可以統(tǒng) 一描述或分別描述。在描述預觸發(fā)條件時，可以指明后續(xù)消息的來源，以及與 該來源相關的被調用業(yè)務控制單元；可以指明與某個業(yè)務控制單元調用失敗相 關的被調用業(yè)務控制單元，即指明業(yè)務控制單元調用失敗的來源。在描述預處 理方式時，可以指明發(fā)送消息的來源，以及與該來源相關的被調用業(yè)務控制單 元；可以指明發(fā)送消息的目的業(yè)務控制單元；可以指明拒絕消息的目的業(yè)務控 制單元；可以指明釋放業(yè)務控制單元的目的業(yè)務控制單元；可以指明與重新調 用業(yè)務控制單元、調用同質業(yè)務控制單元的來源相關的被調用業(yè)務控制單元。本發(fā)明在一個業(yè)務過濾規(guī)則中對多個被調用業(yè)務控制單元進行預處理 的方式， 一方面可以簡化對業(yè)務過濾規(guī)則的描述和執(zhí)行；另一方面，還可以 組合出更多的預處理應用，例如，可以在一個業(yè)務過濾規(guī)則中通過對不同被 調用業(yè)務控制單元的預觸發(fā)條件的組合，得到多種預處理方式。對實施例七 來說，可以在AS1和AS2都調用失敗時，預處理方式設置為通信釋放，而 當AS1和AS2中只有一個調用失敗時，預處理方式設置為執(zhí)行下一條業(yè)務 過濾規(guī)則。為了實現(xiàn)上述處理，可以設置如下所示的業(yè)務過濾規(guī)則<ApplicationServer><ServerName>sip:as 1 @ims.example.com</ServerName> <ServerName>sip:as2@ims.example.com</ServerName> <Pretreatment><PreTriggerInvokingFailure>〈ConditionTypeCNF〉 1 </ConditionTypeCNF> <Source> sip:as l@ims.example.com </Source> <Source> sip:as2敏ms.example.com </Source> </PreTriggerInvokingFailure><PreHandlingMode><Mode>CallRelease</Mode> </PreHandlingMode> </Pretreatment> <Pretreatment><PreTriggerInvokingFailure><ConditionTypeCNF>0</ConditionTypeCNF> <Source> sip:asl@ims.example.com </Source> <Source> sip:as2@ims.example.com </Source> </PreTriggerInvokingFailure> <PreHandlingMode><Mode>GoNextFilterCriteria</Mode> </PreHandlingMode> </Pretreatment> </ApplicationServer>在上述業(yè)務過濾規(guī)則中，PreTriggerlnvokingFailure表示預觸發(fā)條件是業(yè)務 4空制單元調用失敗，〈PreTriggerlnvokingFailure〉與</PreTriggerInvokingFailure> 之間的內容為描述了這種預觸發(fā)條件。其中，Source表示發(fā)生業(yè)務控制單元調用失敗的來源，本例中給出了兩個 來源AS1和AS2;ConditionTypeCNF表示采用正則表達式的條件組合，第一個預觸發(fā)條件，ConditionTypeCNF取值為1，表示兩個來源ASl和AS2的組合類 型是"與(AND)",即預觸發(fā)條件是ASl和AS2調用失??；第二個 〈PreTriggerlnvokingFailure〉與〈/PreTriggerlnvokingFailure〉之間的內容為笫二個 預觸發(fā)條件，ConditionTypeCNF取值為0，表示兩個來源ASl和AS2的組合類 型是"或(OR)",即預觸發(fā)條件是AS1或AS2調用失??；第一個預觸發(fā)條件中，預處理方式設置為通信釋放(CallRdease),第二個 預觸發(fā)條件中，預處理方式設置為執(zhí)行下一條業(yè)務過濾規(guī)則(GoNextFilter Criteria )。因此，在業(yè)務執(zhí)行過程中，當AS1和AS2均調用失敗時，將釋放當前通4言， 而當AS1、 AS2其中之一調用失敗時，將執(zhí)行下一條業(yè)務過濾規(guī)則。由上述示 例可見，本發(fā)明可以通過組合的方式提供更為靈活、豐富的預觸發(fā)條件和預處 理方式。需要說明的是，對一個以上的被調用業(yè)務控制單元的預觸發(fā)條件的組合， 可以應用在任何形式的業(yè)務過濾規(guī)則中，而不僅僅是上述示例中所示出的參與 組合的被調用業(yè)務控制單元同時也是當前業(yè)務過濾規(guī)則中的被調用的業(yè)務控制 單元的情況。例如，業(yè)務控制單元也可以是其它業(yè)務過濾規(guī)則中的被調用的業(yè) 務控制單元，只要指明其來源即可。至此，結束對本發(fā)明實施例七的業(yè)務控制單元預處理方法的說明。 為了實現(xiàn)對業(yè)務控制單元的預處理，本發(fā)明提供了 一種業(yè)務控制單元預處 理裝置，該裝置用于執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制單元及其相對應 的預處理描述信息，并在業(yè)務執(zhí)行過程中，根據所確定的預處理描述信息處理 業(yè)務控制單元。下面舉一個裝置實施例對本發(fā)明業(yè)務控制單元預處理裝置進行說明。圖3為本發(fā)明具體實施例中業(yè)務控制單元預處理裝置的結構示意圖。參見 圖3，該裝置包括預處理信息獲取模塊301、預觸發(fā)條件匹配模塊302和預處理 方法執(zhí)行模塊303。其中，預處理信息獲取模塊301,用于執(zhí)行業(yè)務過濾規(guī)則，確定包含預觸 發(fā)條件及其對應的預處理方法的預處理描述信息，并用于向預觸發(fā)條件匹配模 塊302提供預觸發(fā)條件、向預處理方法執(zhí)行模塊303提供預處理方法；預觸發(fā)條件匹配模塊302，用于在所述業(yè)務執(zhí)行過程中，判斷該觸發(fā)條件 與預處理信息獲取模塊301所提供的預觸發(fā)條件是否滿足，當預觸發(fā)條件滿足 時，通知預處理方法執(zhí)行模塊303;預處理方法執(zhí)行模塊303，用于根據預觸發(fā)條件匹配模塊302的通知，執(zhí)
行預處理信息獲取模塊301所提供的預處理方法。下面通過一個系統(tǒng)實施例，說明如何將圖3所示裝置應用于本發(fā)明業(yè)務控 制單元預處理系統(tǒng)中。圖4為本發(fā)明具體實施例中業(yè)務控制單元預處理系統(tǒng)的 結構示意圖。參見圖4，該系統(tǒng)包括業(yè)務過濾規(guī)則庫410、業(yè)務控制單元預處理 裝置420和業(yè)務控制單元430，其中，業(yè)務控制單元預處理裝置420，進一步包 括預處理信息獲取模塊421、預觸發(fā)條件匹配模塊422和預處理方法執(zhí)行才莫塊 423。圖4所示系統(tǒng)中，業(yè)務過濾規(guī)則庫410，用于保存或產生用戶的業(yè)務過濾 規(guī)則，并用于向業(yè)務控制單元預處理裝置420中的預處理信息獲取模塊421提 供業(yè)務過濾規(guī)則；預處理信息獲取模塊421,用于接收、并執(zhí)行來自于業(yè)務過濾規(guī)則庫410 的業(yè)務過濾規(guī)則，并向預觸發(fā)條件匹配模塊422提供預觸發(fā)條件、向預處理方 法執(zhí)行模塊423提供預處理方法；預觸發(fā)條件匹配模塊422，用于在所述業(yè)務 執(zhí)行過程中，判斷觸發(fā)條件是否滿足，當預觸發(fā)條件滿足時，通知預處理方法 執(zhí)行模塊423執(zhí)行預處理方法，對業(yè)務控制單元430以及當前通信進行相應的 處理；業(yè)務控制單元430,用于根據業(yè)務控制單元預處理裝置420中預處理方法 執(zhí)行模塊423的處理，提供各種業(yè)務邏輯控制功能；進一步的，當在業(yè)務處理 過程中產生業(yè)務過濾規(guī)則時，業(yè)務控制單元430用于將所產生的業(yè)務過濾規(guī)則 發(fā)送給業(yè)務過濾規(guī)則庫410，業(yè)務過濾規(guī)則庫410進一步用于接收、并保存來 自于業(yè)務控制單元430的業(yè)務過濾規(guī)則。圖4所示系統(tǒng)中，可以存在一個或一個以上的業(yè)務過濾規(guī)則庫410,該系 統(tǒng)中的業(yè)務過濾規(guī)則庫410可以是獨立的用戶簽約數(shù)據庫，如歸屬用戶服務器 (HSS, Home Subscriber Server),業(yè)務過濾規(guī)則作為用戶簽約數(shù)據存放其中， 如前述的iFC;該系統(tǒng)中的業(yè)務過濾規(guī)則庫410也可以位于業(yè)務控制單元預處 理裝置420中，如業(yè)務過濾規(guī)則作為一段程序或配置數(shù)據存在于業(yè)務控制單元 預處理裝置420中；該系統(tǒng)中的業(yè)務過濾規(guī)則庫410還可以位于業(yè)務控制單元 430中，如業(yè)務控制單元430在業(yè)務處理過程中產生業(yè)務過濾規(guī)則。圖4所示系統(tǒng)中，業(yè)務控制單元預處理裝置420可以是3GPP IMS標準中 定義的S-CSCF、業(yè)務代理(Service Broker )或業(yè)務能力交互管理(SCIM， Service Capability Interaction Manager)應用月良務器等；業(yè)務控制單元430是各種業(yè)務的宿主執(zhí)行環(huán)境，可以是MS應用服務器、 傳統(tǒng)智能網SCF實體等；業(yè)務過濾規(guī)則庫410與業(yè)務控制單元預處理裝置420之間的接口可以是 Diameter協(xié)議或內部接口協(xié)議等；業(yè)務過濾規(guī)則庫410與業(yè)務控制單元430之 間的接口可以是Diameter協(xié)議或內部接口協(xié)議等；業(yè)務控制單元預處理裝置420 與業(yè)務控制單元430之間的接口可以是SIP協(xié)議、智能業(yè)務協(xié)議(如智能網應 用規(guī)程協(xié)議INAP， Intelligent Network Application Protocol),內部接口協(xié)議等。以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范 圍。凡在本發(fā)明的精神和原則之內所作的任何修改、等同替換、改進等，均 應包含在本發(fā)明的保護范圍之內。
權利要求
1、一種業(yè)務控制單元預處理方法，其特征在于，該方法包括以下步驟A、執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制單元及其相對應的預處理描述信息；B、在業(yè)務執(zhí)行過程中，根據所確定的預處理描述信息對當前通信進行處理。
2、 根據權利要求1所述的方法，其特征在于，在步驟A之前，進一步包括A0 、根據所述被調用業(yè)務控制單元在業(yè)務執(zhí)行過程中可能出現(xiàn)的處理情 況，在所述業(yè)務過濾規(guī)則中設置與所述被調用業(yè)務控制單元相對應的預處理描 述信息。
3、 根據權利要求2所述的方法，其特征在于，所述預處理描述信息包括預 觸發(fā)條件及其相對應的預處理方式；步驟B所述進行相應的處理為當所述預觸發(fā)條件滿足時，執(zhí)行與所述預 觸發(fā)條件相對應的預處理方式。
4、 根據權利要求3所述的方法，其特征在于，所述預觸發(fā)條件包括后續(xù)消 息、會話狀態(tài)和業(yè)務控制單元調用失敗中的至少一種；所述預處理方式包括發(fā)送消息、拒絕消息、重新調用業(yè)務控制單元、調用 同質業(yè)務控制單元、調用新的業(yè)務控制單元、執(zhí)行下一條業(yè)務過濾規(guī)則、停止 執(zhí)行業(yè)務過濾規(guī)則、釋放業(yè)務控制單元和通信釋放中的至少一種。
5、 根據權利要求4所述的方法，其特征在于，所述后續(xù)消息包括所述被調 用業(yè)務控制單元被調用之后、直至當前通信被釋放之前的包括釋放消息在內的 所有消息中的至少一個；所述^L調用業(yè)務控制單元中的業(yè)務邏輯調用失敗。
6、 根據權利要求5所述的方法，其特征在于，所述預觸發(fā)條件中的后續(xù)消 息包括任意后續(xù)消息的消息名稱和/或消息內容和/或消息來源信息。
7、 根據權利要求4所述的方法，其特征在于，所述預處理方式中的發(fā)送消 息為向所述被調用業(yè)務控制單元發(fā)送指定的消息。
8、 根據權利要求7所述的方法，其特征在于，所述指定的消息為指定消 息名稱的消息。
9、 根據權利要求8所述的方法，其特征在于，所述指定的消息為進一步 指定消息內容和/或消息來源的消息。
10、 根據權利要求7所述的方法，其特征在于，所述指定的消息包括所述 預觸發(fā)條件中的后續(xù)消息。
11、 根據權利要求4所述的方法，其特征在于，所述預處理方式中的拒絕 消息為禁止向所述被調用業(yè)務控制單元發(fā)送所述預觸發(fā)條件中的后續(xù)消息。
12、 根據權利要求4所述的方法，其特征在于，進一步在所述業(yè)務過濾規(guī) 則中描述與所述被調用業(yè)務控制單元同質的業(yè)務控制單元信息；所述調用同質業(yè)務控制單元為當所述被調用業(yè)務控制單元調用失敗時， 向所述同質業(yè)務控制單元發(fā)送調用消息。
13、 根據權利要求4所述的方法，其特征在于，進一步在所述預處理描述 信息中指定新業(yè)務控制單元的地址；所述調用新的業(yè)務控制單元為當所述預觸發(fā)條件滿足時，向所述新業(yè)務 控制單元發(fā)送調用消息。
14、 根據權利要求5所述的方法，其特征在于，當所述業(yè)務控制單元調用 失敗為業(yè)務控制單元中的業(yè)務邏輯調用失敗時，所述被調用業(yè)務控制單元進一 步返回表示業(yè)務邏輯調用失敗的消息。
15、 根據權利要求1至14所述的方法，其特征在于，所述被調用業(yè)務控制 單元為多個業(yè)務控制單元。
16、 根據權利要求15所述的方法，其特征在于，進一步在所述預觸發(fā)條件 中描述與所述業(yè)務控制單元調用失敗相關的所述被調用業(yè)務控制單元。
17、 根據權利要求15所述的方法，其特征在于，進一步在所述預處理方式 中描述所述發(fā)送消息的目的業(yè)務控制單元，和/或所述拒絕消息的目的業(yè)務控制 單元，和/或與所述重新調用業(yè)務控制單元的來源相關的所述被調用業(yè)務控制單 元，和/或與所述調用同質業(yè)務控制單元的來源相關的所述被調用業(yè)務控制單 元，和/或所述釋放業(yè)務控制單元的目的業(yè)務控制單元。
18、 根據權利要求1至14所述的方法，其特征在于，進一步在所述預處理 描述信息中描述多個被調用業(yè)務控制單元的預觸發(fā)條件的任意組合、以及與所 述預觸發(fā)條件的任意組合相對應的預處理方式。
19、 根據權利要求1至14任一所述方法，其特征在于，執(zhí)行步驟A所述 業(yè)務過濾規(guī)則的依據是接收到業(yè)務觸發(fā)消息、或當前通信過程狀態(tài)發(fā)生遷移。
20、 根據權利要求1至14任一所述方法，其特征在于，所述業(yè)務控制單元 為因特網多媒體子系統(tǒng)IMS應用服務器或傳統(tǒng)智能網業(yè)務控制功能實體SCF。
21、 一種業(yè)務控制單元預處理裝置，其特征在于，該裝置包括預處理信 息獲取模塊和預處理方法執(zhí)行模塊；所述預處理信息獲取模塊，用于執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制 單元及其相對應的預處理描述信息，并向所述預處理方法執(zhí)行模塊提供所述預 處理描述信息；所述預處理方法執(zhí)行模塊，用于在業(yè)務執(zhí)行過程中，根據所述預處理信息 獲取^t塊所提供的預處理描述信息對當前通信進行處理。
22、 根據權利要求21所述的裝置，其特征在于，該裝置還進一步包括預觸 發(fā)條件匹配模塊；所述預處理描述信息包括預觸發(fā)條件及其對應的預處理方法； 所述預觸發(fā)條件匹配模塊，用于在所述業(yè)務執(zhí)行過程中，根據所述預處理 信息獲取4莫塊所提供的預觸發(fā)條件判斷所述預觸發(fā)條件是否滿足，當所述預觸 發(fā)條件滿足時，通知所述預處理方法執(zhí)行模塊，執(zhí)行所述預處理信息獲取模塊 所提供的預處理方法。
23、 一種業(yè)務控制單元預處理系統(tǒng)，其特征在于，該系統(tǒng)包括業(yè)務過濾規(guī)則庫、業(yè)務控制單元預處理裝置和業(yè)務控制單元；所述業(yè)務過濾規(guī)則庫，用于保存或產生用戶的業(yè)務過濾規(guī)則，并用于向所 述業(yè)務控制單元預處理裝置提供所述業(yè)務過濾規(guī)則；所述業(yè)務控制單元預處理裝置，用于根據業(yè)務過濾規(guī)則庫所提供的業(yè)務過 濾規(guī)則，確定與所述業(yè)務控制單元相對應的預處理描述信息，并根據所述預處 理描述信息對當前通信進行處理；所述業(yè)務控制單元，用于根據所述業(yè)務控制單元預處理裝置的處理，提供 各種業(yè)務邏輯控制功能。
24、 根據權利要求23所述的系統(tǒng)，其特征在于，當在業(yè)務處理過程中產生 業(yè)務過濾規(guī)則時，所述業(yè)務控制單元，進一步用于將所產生的業(yè)務過濾規(guī)則發(fā) 送給業(yè)務過濾規(guī)則庫；所述業(yè)務過濾規(guī)則庫，進一步用于接收、并保存來自于所述業(yè)務控制單元 的業(yè)務過濾規(guī)則。
25、 根據權利要求23所述的系統(tǒng)，其特征在于，所述業(yè)務過濾規(guī)則庫為至少一 所述業(yè)務過濾規(guī)則庫為單獨設置的用戶簽約數(shù)據庫；或者，設置于所述業(yè)務控制單元預處理裝置中，所述業(yè)務過濾規(guī)則庫中的 業(yè)務過濾規(guī)則作為程序或配置數(shù)據存在于所述業(yè)務控制單元預處理裝置之中；或者，設置于所述業(yè)務控制單元中，所述業(yè)務過濾規(guī)則庫中的業(yè)務過濾規(guī) 則在業(yè)務處理過程中產生。
全文摘要
本發(fā)明公開了一種業(yè)務控制單元預處理方法，首先執(zhí)行業(yè)務過濾規(guī)則，確定被調用業(yè)務控制單元及其相對應的預處理描述信息，然后在業(yè)務執(zhí)行過程中，根據所確定的預處理描述信息對當前通信進行處理。本發(fā)明還公開了一種業(yè)務控制單元預處理裝置和系統(tǒng)。應用本發(fā)明能夠在通信后續(xù)過程中調整業(yè)務控制單元的信令路徑，從而解決業(yè)務交互及沖突問題，提高呼叫建立效率、縮短呼叫接續(xù)時間。
文檔編號H04L29/06GK101163135SQ20061013196
公開日2008年4月16日 申請日期2006年10月13日 優(yōu)先權日2006年10月13日
發(fā)明者施有鑄 申請人:華為技術有限公司