專利名稱:在話音業(yè)務連續(xù)性中處理呼叫的方法及裝置的制作方法
技術領域：
本發(fā)明涉及通信技術領域：
，尤其一種在話音業(yè)務連續(xù)性中處理呼叫的方法及裝置。
背景技術：
IP多媒體子系統(tǒng)(IMS)是3GPP R5階段增加的WCDMA網絡中疊加在已有分組域之上的一個子系統(tǒng)，采用分組域為其上層控制信令和媒體傳輸的承載通道，并引入SIP協(xié)議作為業(yè)務控制協(xié)議，利用SIP簡單、易擴展、媒體組合方便的特點，通過將業(yè)務控制與承載控制分離，提供豐富的多媒體業(yè)務。IMS中的主要功能實體包括控制用戶注冊、會話控制等功能的會話控制實體CSCF、提供各種業(yè)務邏輯控制功能的應用服務器AS、集中管理用戶簽約數據的歸屬用戶服務器HSS以及用于實現(xiàn)與電路交換網互通的MGCF/IM-MGW(媒體網關控制功能)。用戶通過當前所在地代理節(jié)點P-CSCF接入IMS，會話和業(yè)務觸發(fā)控制及與AS的業(yè)務控制交互則由其注冊地的歸屬域服務節(jié)點S-CSCF完成。
目前，3GPP提出了一種IMS控制的靜態(tài)錨點(IMS control static anchoring)的呼叫控制方案，以解決在兩個域，如CS域和IMS域，之間進行切換的問題。該方案的核心思想是，在IMS歸屬域為用戶分配一個具有作為呼叫連續(xù)性控制功能(Call Continuity Control Function，CCCF)的應用服務器(ApplicationServer，AS)，對于從CS域或是IMS域發(fā)起的與該用戶相關的呼叫/會話都將被傳送到該AS進行錨定控制(Anchoring control)。這樣，后續(xù)無論發(fā)生CS域至IMS域的域間切換或是發(fā)生IMS域至CS域的域間切換，都由該AS對錨定的呼叫/會話進行后續(xù)切換控制處理。
對于IMS中會話控制方式本身就可以很方便的在呼叫路徑中插入一個錨點AS對會話進行控制，即通過定義iFC(initial Filter Criteria，初始過濾準則)使得會話觸發(fā)至AS。
而對于CS域的呼叫控制方式本身不太容易在呼叫路徑中插入一個錨點AS，因此，針對CS域發(fā)起的呼叫觸發(fā)至錨點AS的過程，3GPP規(guī)范目前描述了多種實現(xiàn)方案，其中對于主叫側為CS域時發(fā)起的初始呼叫，即對于主叫側VMSC(VisitedMobile Switch Center，拜訪移動交換中心)在接收到UE的呼叫建立消息后發(fā)起的呼叫，可以有網絡側路由控制{即使用CAMEL(移動網增強邏輯客戶化應用)方案}和終端側路由控制{即使用USSD(Unstructured Supplementary ServiceData非結構化補充數據業(yè)務)和SIP Notify(Session Initial Protocol Notify，會話初始協(xié)議的“通知”操作)}，兩種控制模式將呼叫路由至錨點AS；對于被叫側為CS域時發(fā)起的初始呼叫，即被叫歸屬網絡的GMSC在接收到來自于主叫側的呼叫后，根據GMSC對被叫信息分析后發(fā)起的呼叫，可以使用CAMEL方案和信令攔截方案將呼叫路由至錨點AS。
這種將初始呼叫路由至錨點AS的功能稱為域間選擇功能(Network DomainSelection，NeDS)功能。對于CS域，具有NeDS功能的實體可以為gsmSCF；對于IMS域，具有NeDS功能的實體可以為一個AS。CS域中的路由決策實體gsmSCF可以同IMS域中的路由決策實體AS位于同一物理實體中。
采用靜態(tài)錨點方案完成的VCC(話音業(yè)務連續(xù)性)用戶跨域切換控制過程如圖1所示，在呼叫初始建立時，如UE(A)發(fā)起針對UE(B)的呼叫，則該呼叫通過具有NeDS功能的gsmSCF或AS在主叫側UE(A)的呼叫路徑中插入一個錨點AS，該AS啟用B2BUA(背靠背用戶代理)功能用以將主叫側的呼叫分為AS終止段和AS發(fā)起段兩段。所述的AS終止段即為UE(A)-AS之間的呼叫段，所述的AS發(fā)起段即為AS-UE(B)之間的呼叫段。
在后續(xù)在呼叫的過程中，UE(A’)檢測到域間切換條件滿足時，希望將當前進行的呼叫從UE(A)切換到UE(A’)上進行后續(xù)的呼叫控制，此時UE(A’)則針對當前的呼叫進行錨定控制的AS發(fā)起一個新的呼叫，AS在接收到該呼叫后，判斷出需要進行域間切換時，則AS將UE(A’)新發(fā)起的呼叫與AS發(fā)起段接續(xù)，然后釋放掉AS終止段的呼叫，這樣，在錨點AS的控制下，使得UE(A’)同UE(B)進行了呼叫的接續(xù)，釋放掉先前的UE(A)-AS之間的呼叫段，完成了UE(A)到UE(A’)之間的切換。
上述這種將呼叫進行錨定控制，并在域間切換發(fā)生時進行切換處理的功能叫做呼叫連續(xù)性控制功能(Call continuity Control Function，CCCF)功能，在靜態(tài)錨點方案下，具有CCCF功能的實體為IMS域中的一個AS。
其中，具有NeDS功能的路由決策點gsmSCF或AS可以同具有CCCF功能的AS位于同一個物理實體中；而且UE(A)可以是CS域的終端，UE(A’)可以是IMS域的終端，通過UE(A)到UE(A’)的呼叫切換，實現(xiàn)了用戶A的同一個呼叫從CS域到IMS域之間的呼叫連續(xù)性。
同樣，在呼叫初始建立時，可在主叫側UE(B)的呼叫路徑中插入一個錨點AS，用以實現(xiàn)后續(xù)被叫側的域間切換的呼叫控制。
當CS域的用戶作為主叫發(fā)起呼叫時，且采用網絡側路由控制模式，即CS域中使用CAMEL機制將發(fā)起的呼叫觸發(fā)至AS進行錨定，則相應的處理流程如圖2所示，主要包括以下步驟步驟2-1、注冊到VMSC的UE發(fā)起呼叫建立Setup消息。
步驟2-2、VMSC根據主叫側的CAMEL簽約信息通過Initial DP(初始檢測點)消息將呼叫觸發(fā)到具有NeDS功能的gsmSCF中。
步驟2-3、具有NeDS功能的gsmSCF生成一個指向IMS域中的具有CCCF功能的一個AS的路由號碼IMRN(IMS Routing Number)，使得VMSC根據該路由號碼將呼叫路由至該CCCF上。
具有NeDS功能的gsmSCF可通過在CCCF的標識信息CCCF PSI(CCCFPublic Service Identities，CCCF公共業(yè)務標識)后追加呼叫參考號等方法來構造IMRN，然后，由具有NeDS功能的gsmSCF通過移動網增強邏輯客戶化應用連接(CAMEL connect)消息將IMRN下發(fā)給VMSC。
步驟2-4、VMSC根據IMRN通過初始地址全消息(IAM)消息將呼叫路由至主叫用戶歸屬的IMS網絡中的媒體網關控制功能(MGCF)。
步驟2-5、MGCF判斷出IAM消息中的被叫信息為指向具有CCCF功能的AS的IMRN，則向I-CSCF發(fā)送INVITE消息，該消息中的被叫信息中請求資源統(tǒng)一定位標識(Requested-URI)為IMRN的TEL URI(即電話號碼格式的URI)格式。
步驟2-6、I-CSCF根據Requested-URI向歸屬用戶服務器(HSS)查詢路由信息，獲取同該IMRN相關聯(lián)的AS地址信息，即具有CCCF功能的AS地址信息，然后I-CSCF向具有CCCF功能的AS轉發(fā)INVITE消息。
為了支持HSS能夠根據包含CCCF PSI信息的IMRN返回在對應的具有CCCF功能的AS信息，在HSS中需要配置CCCF PSI數據同具有該CCCF功能的AS地址信息的對應關系。
步驟2-7、具有CCCF功能的AS接收到的被叫信息包含CCCF PSI信息的IMRN的會話后，對會話進行錨定控制，即觸發(fā)B2BUA(背靠背用戶代理)功能，終止掉AS接收到會話，然后發(fā)起一個針對原被叫信息的新會話，即具有CCCF功能的AS通過同HSS的Sh接口獲得主叫用戶側的S-CSCF信息，然后，將會話路由至S-CSCF，并由該S-CSCF將會話路由至原被叫側。
具有CCCF功能的AS在發(fā)起一個針對原被叫信息的新會話時，其會話的原被叫信息是具有CCCF功能的AS根據接收到的INVITE消息中的被叫信息TELURI格式的IMRN索引出該IMRN所對應的呼叫的真實被叫信息，即索引出具有NeDS功能的gsmSCF在步驟2-3中分配的IMRN所對應的真實的被叫號碼信息。
在S-CSCF將呼叫路由至原被叫側的過程中，當原被叫信息為Tel-URI格式時，S-CSCF執(zhí)行ENUM DNS(E.164 Number Domain Name System E.164，域名轉換系統(tǒng))轉換功能，如果能夠將原被叫號碼轉換成SIP URI(會話初始協(xié)議的URI)格式，則后續(xù)的呼叫路由在IMS域中進行，否則，S-CSCF將呼叫路由至本IMS域的BGCF(Breakout Gateway Control Function邊界網關控制功能)，由BGCF將呼叫最終經由MGCF路由至PSTN(公共電話交換網)或CS域，最后由PSTN或CS域將呼叫接續(xù)至被叫。在具有CCCF功能的AS啟用B2BUA功能時，對于在CCCF終止的會話和在CCCF新發(fā)起的會話，CCCF均對其維護狀態(tài)，以對后續(xù)用戶可能發(fā)起的域間切換進行控制。
由于主叫用戶拜訪地的CS域不一定支持CAMEL，因此需要考慮到其他替代方式將呼叫路由至AS，目前3GPP的規(guī)范中提供了終端側路由控制模式下的基于USSD和基于SIP Notify的兩種機制。
其中，USSD機制應用于UE未注冊到IMS域，其基本原理是UE在向VMSC發(fā)起呼叫時，呼叫信令中的被叫地址信息攜帶的是指向具有CCCF功能的AS的CCCF PSI，從而VMSC經由MGCF將呼叫路由至IMS域中具有CCCF功能的AS。而真實的被叫信息，如UE(B)的號碼信息，是通過UE向具有NeDS功能的gsmSCF發(fā)送的USSD信令中攜帶，這樣，在具有NeDS功能的gsmSCF接收到USSD信令后，與具有CCCF功能的AS進行交互，通知CCCF其當前接收到的會話的真實被叫信息，即USSD信令中攜帶UE(B)的號碼信息，從而具有CCCF功能的AS對接收到的UE發(fā)起的呼叫進行錨定，即AS啟動B2BUA功能，終止掉AS接收到會話，然后發(fā)起一個針對原被叫信息的新會話，這里的原被叫信息從具有NeDS功能的gsmSCF接收到的USSD信令中獲得。后續(xù)處理如圖2的步驟2-7所述，根據AS發(fā)起的新會話中的原被叫信息將會話路由至被叫用戶后接續(xù)。
當CS域的用戶作為主叫發(fā)起呼叫時，如果采用終端側路由控制模式，即使用USSD機制將發(fā)起的呼叫觸發(fā)至AS進行錨定，則相應的處理流程如圖3所示，主要包括以下步驟步驟3-1，注冊到VMSC的UE發(fā)起呼叫建立Setup消息，setup中攜帶的被叫信息為一個包含CCCF PSI信息的號碼，并且消息中還攜帶有UE分配的用于唯一標識UE和CCCF之間一次呼叫的呼叫參考號，VMSC根據包含CCCF PSI信息的被叫號碼將UE發(fā)起的呼叫經由MGCF/I-CSCF路由至一個具有CCCF功能的AS中(將UE發(fā)起的呼叫路由至具有CCCF功能AS的處理過程同步驟2-4～步驟2-6類似)。
步驟3-2、在UE接收到VMSC發(fā)送的Call proceeding消息后，UE以應用模式向VMSC發(fā)起USSD信令，其中USSD信令中攜帶本次呼叫的真實的被叫信息，以及在步驟3-1中UE分配的呼叫參考號。
步驟3-3、VMSC向HLR轉發(fā)該USSD信令，HLR向具有CCCF功能的USSD信令處理功能實體，如gsmSCF轉發(fā)該USSD信令，此處具有CCCF功能的USSD信令處理功能實體與步驟3-1中具有CCCF功能的AS可為同一個物理實體；根據接收到的USSD信令中攜帶的呼叫真實的被叫信息和呼叫參考號，具有CCCF功能的AS和/或USSD信令處理功能實體關聯(lián)出步驟3-1中接收到的會話，并且將步驟3-1接收到會話中的被叫信息更新為USSD信令攜帶的呼叫真實的被叫信息。
步驟3-4、具有CCCF功能的AS和/或USSD信令處理功能實體對步驟3-1接收到會話中的被叫信息進行更新后，對會話進行錨定控制(具有CCCF功能的AS和/或USSD信令處理功能實體對會話進行錨定控制的處理過程同步驟2-7類似)。
所述的SIP Notify機制應用于UE已經注冊到IMS域，其基本原理同USSD機制大致一致，即UE在向VMSC發(fā)起呼叫時，呼叫信令中的被叫地址信息攜帶的是指向具有CCCF功能的AS的CCCF PSI，從而VMSC經由MGCF將呼叫路由至IMS域中具有CCCF功能的AS。而真實的被叫信息，如UE(B)的號碼信息，是通過當前注冊到IMS域的UE向具有NeDS功能的AS發(fā)送的SIP Notify信令中攜帶，這樣，在具有NeDS功能的AS接收到SIP Notify信令后，與具有CCCF功能的AS進行交互，通知CCCF其當前接收到的會話的真實被叫信息，即SIPNotify信令中攜帶UE(B)的號碼信息，從而具有CCCF功能的AS對接收到的UE發(fā)起的呼叫進行錨定，即AS啟動B2BUA功能，終止掉AS接收到會話，然后發(fā)起一個針對原被叫信息的新會話，這里的原被叫信息從具有NeDS功能的AS接收到的SIP Notify信令中獲得。后續(xù)處理如圖2的步驟2-7所述，根據AS發(fā)起的新會話中的原被叫信息將會話路由至被叫用戶后接續(xù)。
從目前的語音業(yè)務連續(xù)性的設計方案上可知，對于從CS域或是IMS域發(fā)起的與該用戶相關的呼叫/會話都將被傳送到該用戶歸屬的IMS域中一個具有CCCF功能的AS進行錨定控制，因此，對于普通的CS域的用戶作為主叫發(fā)起呼叫，在實現(xiàn)VCC業(yè)務時，其呼叫路徑是被強行先路由至用戶歸屬IMS域的AS進行錨定后，再由AS將呼叫路由至被叫側。而對于這種CS域的VCC用戶作為主叫發(fā)起呼叫時，有網絡側路由控制和終端側路由控制兩種模式，對于網絡側路由控制模式，UE發(fā)起的呼叫是一個普通的針對真實被叫的呼叫，通過網絡的CAMEL能力將呼叫改向至一個具有CCCF功能的AS進行呼叫的錨定。對于終端側路由控制模式，需要對終端的呼叫邏輯進行修改，UE發(fā)起的呼叫是一個特殊的針對具有CCCF功能的AS的呼叫，而真實的被叫號碼是在后續(xù)UE向具有CCCF功能的USSD信令處理實體發(fā)送的USSD信令中攜帶，具有CCCF功能的AS和/或USSD信令處理實體根據USSD信令中攜帶的真實被叫信息對呼叫的被叫信息進行更新，然后對呼叫進行錨定。
目前在CS域中存在的一些本地業(yè)務，如緊急業(yè)務和合法監(jiān)聽業(yè)務。
緊急業(yè)務(如用戶撥打緊急求助電話110、119等)是一種特殊的電信業(yè)務，目前規(guī)范中定義了兩類緊急業(yè)務，Type-1和Type-2。Type-1的緊急呼叫是指終端上沒有SIM卡的情況發(fā)起的呼叫，此時UE發(fā)送的呼叫建立setup消息中攜帶有相應的指示標明該呼叫為緊急呼叫，VMSC根據setup消息緊急呼叫指示將該呼叫送至緊急呼叫中心接續(xù)；Type-2的緊急呼叫是指終端以傳統(tǒng)的方式發(fā)起呼叫建立setup消息，但是消息中的被叫號碼攜帶的是緊急呼叫號碼，VMSC根據對setup消息中的被叫號碼進行分析后將呼叫送至緊急呼叫中心接續(xù)。
為了盡快地讓發(fā)起緊急呼叫的用戶獲得業(yè)務，緊急呼叫業(yè)務對接續(xù)時延有比較嚴格的要求，因此，目前規(guī)范中的處理是在主叫拜訪地的VMSC中的特殊號碼表中配置所有的本地緊急呼叫號碼，當VMSC接收到UE發(fā)起的setup消息后，根據setup消息中的被叫號碼判斷出為緊急呼叫號碼，則對呼叫進行緊急呼叫流程處理，即不對UE執(zhí)行鑒權、加密等流程，直接將呼叫路由至緊急呼叫中心。CAMEL業(yè)務由于呼叫需要同gsmSCF進行交互，會導致接續(xù)時長的增加，所以目前3GPP的規(guī)范中明確規(guī)定了緊急業(yè)務時不能觸發(fā)CAMEL業(yè)務。因此，如果UE使用基于CAMEL的網絡側路由控制模式下發(fā)起CS域的緊急呼叫業(yè)務時，呼叫是不會送至用戶歸屬IMS網絡中具有CCCF功能的AS進行錨定，后續(xù)呼叫與不能夠進行VCC控制。
合法監(jiān)聽業(yè)務是一種監(jiān)管業(yè)務。所謂的合法監(jiān)聽是指安全機構出于執(zhí)法的需要，對某個通話過程進行監(jiān)聽。目前在CS域監(jiān)聽的實現(xiàn)過程是監(jiān)聽中心預先在MSC(包括該監(jiān)聽中心管轄范疇內的VMSC/GMSC)設置受控數據，監(jiān)聽中心在MSC設置的受控數據包含受控標識和受控事件，受控標識可以是MSISDN、IMSI或IMEI，受控事件可以是呼叫相關的事件和/或呼叫無關的事件，用于指示MSC監(jiān)控同這些MSISDN或IMSI或IMEI相關的呼叫相關和/或呼叫無關的事件。MSC保存受控數據，當本局發(fā)生了與受控標識相關的受控事件時發(fā)生時，MSC根據所保存的受控數據觸發(fā)監(jiān)聽，即對于受控用戶發(fā)起或接收的呼叫，MSC需要單獨建立到監(jiān)聽中心的話音通道將用戶通話內容傳遞過去；對于受控用戶發(fā)起或接收到的其他呼叫無關事件，如SMS，MSC則僅僅向監(jiān)聽中心上報事件通知。由于監(jiān)聽的觸發(fā)在呼叫建立時就進行了，因此，一般受控數據的下發(fā)需要在呼叫建立之前完成。當用戶漫游時，拜訪地的安全機構也可以對用戶在拜訪地發(fā)起的呼叫或是接收到呼叫進行監(jiān)聽，因此，合法監(jiān)聽業(yè)務也屬于一種本地業(yè)務。當UE使用基于CAMEL的網絡側路由控制模式下發(fā)起CS域的呼叫時，安全機構是可以對呼叫中的主叫用戶或被叫用戶進行合法監(jiān)聽的。
由于考慮到網絡支持CAMEL能力的不具有普遍性，即在主叫用戶拜訪地的CS域不一定支持CAMEL，因此VCC規(guī)范提出了使用基于USSD/SIP Notify的終端側路由控制模式，將UE發(fā)起的CS域呼叫路由至具有CCCF功能的AS的替代方案，該替代方案用于網絡不能支持CAMLE的情況下UE發(fā)起CS域呼叫的一種補充方式。
但是，當UE以USSD/SIP Notify方式發(fā)起呼叫時，由于用戶撥打的呼叫真實號碼即緊急呼叫號碼是在USSD或是SIP Notify信令中攜帶至具有CCCF功能的AS，UE發(fā)起的setup信令中攜帶的是指向用戶歸屬IMS網絡中具有CCCF功能的AS的CCCF PSI，后續(xù)由AS將接收到的會話同接收到USSD或是SIP Notify信令進行關聯(lián)，并將會話中的被叫信息更新為USSD/SIP Notify中攜帶的呼叫真實的號碼。由于用戶撥打的真實被叫號碼是通過USSD/SIP Notify信令攜帶至具有CCCF功能的AS，因此，對于Type-2的緊急呼叫，主叫拜訪地的VMSC無法根據接收到的setup信令中識別出該呼叫是一個緊急呼叫，呼叫仍然會送至用戶歸屬IMS網絡中具有CCCF功能的AS進行錨定，后續(xù)呼叫也能夠進行VCC控制。
因此，對于同一個VCC用戶，當其在具有CAMEL能力的網絡下發(fā)起的CS域緊急業(yè)務呼叫，最終呼叫是不能夠進行VCC業(yè)務，和其在不具有CAMEL能力的網絡下發(fā)起的CS域緊急業(yè)務呼叫，最終呼叫是能夠進行VCC業(yè)務的，導致了用戶感受的不一致，從而影響用戶體驗。另外，當UE以USSD/SIP Notify方式發(fā)起呼叫時，由于用戶撥打的真實被叫號碼是通過USSD/SIP Notify信令攜帶至具有CCCF功能的AS，UE發(fā)起的setup信令中攜帶的是指向用戶歸屬IMS網絡中具有CCCF功能的AS的CCCF PSI，因此，主叫拜訪地的VMSC無法根據接收到的setup信令中識別出真實的被叫號碼信息，導致安全機構無法對撥打的真實被叫用戶進行監(jiān)聽。這樣，對于同一個VCC用戶，當其在具有CAMEL能力的網絡下發(fā)起的CS域的呼叫時，最終呼叫是能夠被合法監(jiān)聽的，當其在不具有CAMEL能力的網絡下發(fā)起的CS域的呼叫時，最終呼叫是不能夠被合法監(jiān)聽的，導致了VCC業(yè)務下對合法監(jiān)聽業(yè)務的處理不一致。

發(fā)明內容本發(fā)明提供一種在話音業(yè)務連續(xù)性中處理呼叫的方法及裝置，以解決現(xiàn)有技術中簽約了VCC業(yè)務的用戶在不支持CAMEL能力的網絡發(fā)起呼叫時，需要通過異步交互傳遞被叫信息而存在的延長接續(xù)時延的問題；進一步的，解決由此造成VCC業(yè)務下對其他業(yè)務處理不一致或影響用戶體驗的問題。
本發(fā)明提供以下技術方案一種在話音業(yè)務連續(xù)性中處理呼叫的方法，包括如下步驟A、電路域用戶發(fā)起呼叫，并且在該呼叫中攜帶呼叫連續(xù)性控制功能公共業(yè)務標識(CCCF PSI)和被叫用戶信息；B、將所述電路域呼叫轉換為包含所述CCCF PSI和被叫用戶信息的會話建立請求消息，并路由到具有CCCF功能的實體；C、所述具有CCCF功能實體從所述會話請求中獲取被叫信息，并對會話進行錨定控制。
其中步驟A中，通過所述呼叫信令的被叫信息部分攜帶所述CCCF PSI和被叫用戶信息；或者，在所述呼叫信令的被叫信息部分攜帶所述CCCF PSI，通過呼叫信令中的其他參數攜帶被叫用戶信息。
電路域中的網絡實體發(fā)送初始地址消息時，在該消息的被叫部分攜帶所述CCCF PSI，通過該消息中的其他參數攜帶被叫用戶信息。
轉換所述電路呼叫信令的網絡實體解析出初始地址消息中攜帶被叫用戶信息的參數，根據該消息中的被叫信息部分攜帶的CCCF PSI與解析出的被叫用戶信息構造被叫號碼偽碼，并攜帶在會話建立請求消息中。
電路域中接收到所述呼叫的設備在根據呼叫中攜帶的用戶信息確定本次會話中不能發(fā)起VCC業(yè)務時，進一步觸發(fā)禁止VCC業(yè)務的處理流程。
所述禁止VCC業(yè)務的處理流程包括電路域中接收到所述呼叫的設備進一步向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息；所述具有CCCF功能的網絡實體依據該相關信息，在接收到針對該會話發(fā)起的話音業(yè)務連續(xù)性(VCC)請求時拒絕該請求。
通過呼叫信令將禁止VCC業(yè)務的相關信息發(fā)送到具有CCCF功能的網絡實體；或者，通過管理接口向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
確定本次會話不能發(fā)起VCC業(yè)務的情況包括本次會話中的用戶被合法監(jiān)聽時，以及本次會話中的用戶發(fā)起了呼叫中的業(yè)務。
所述用戶被合法監(jiān)聽時，在接受合法監(jiān)聽中心控制的網絡實體接收到受控數據后向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息；或者，由合法監(jiān)聽中心直接向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
步驟B之前進一步包括步驟A1、電路域中接收到所述呼叫的設備在根據呼叫中攜帶的被叫用戶信息確定該用戶是否能發(fā)起VCC業(yè)務，若是，將呼叫路由到具有信令轉換功能的網絡實體，并繼續(xù)步驟B；否則，則將該呼叫直接路由到被叫用戶。
步驟B之前進一步包括步驟A2、電路域接收到所述呼叫的網絡實體根據所述被叫用戶信息和預先配置的緊急呼叫中心信息，判斷被叫是否為緊急中心，若是，則將呼叫直接路由到緊急中心；否則，將呼叫路由到具有信令轉換功能的網絡實體，并繼續(xù)步驟B。
所述具有CCCF功能的實體獲取被叫信息后，根據所述被叫用戶信息和預先配置的緊急呼叫中心信息判斷該被叫是否為緊急中心，若是則將呼叫路由到緊急中心，否則，對會話進行錨定控制。
將呼叫路由到緊急中心時，根據CCCF公共業(yè)務標識與用戶當前所在位置的對應關系，將呼叫路由到用戶位置最近的緊急呼叫中心。
一種在話音業(yè)務連續(xù)性中處理呼叫的方法，包括如下步驟網絡中接續(xù)呼叫的網絡實體將用戶發(fā)起的呼叫路由到IMS網絡中具有呼叫連續(xù)性控制功能(CCCF功能)的網絡實體，由該網絡實體對會話進行錨定控制；以及所述具有CCCF功能的網絡實體在控制所述會話過程中接收到針對該會話發(fā)起的話音業(yè)務連續(xù)性(VCC)請求時，判斷是否禁止該請求，若是，則拒絕該請求，否則，接受該請求并進行后續(xù)處理。
其中所述接續(xù)呼叫的網絡實體在確定本次會話中不能發(fā)起VCC業(yè)務時，進一步向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息，由網絡實體設置相應的標識。
通過所述呼叫信令將禁止VCC業(yè)務的相關信息發(fā)送到具有CCCF功能的網絡實體；或者，通過管理接口向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
確定本次會話不能發(fā)起VCC業(yè)務的情況包括本次會話中的用戶被合法監(jiān)聽時，以及本次會話中的用戶發(fā)起了呼叫中的業(yè)務。
用戶被合法監(jiān)聽時，由接受合法監(jiān)聽中心控制的網絡實體接收到受控數據后向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息；或者，由合法監(jiān)聽中心直接向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
一種終端設備，包括呼叫信令產生模塊，用于VCC業(yè)務用戶發(fā)起呼叫時，產生包含具有呼叫連續(xù)性控制功能公共業(yè)務標識和被叫用戶信息的呼叫信令；收發(fā)模塊，與所述呼叫信令產生模塊連接，用于將呼叫信令產生模塊產生的所述呼叫信令發(fā)送到網絡，以及從網絡接收信令和業(yè)務數據。
本發(fā)明在簽約了VCC業(yè)務的用戶發(fā)起CS域呼叫時，在setup消息中同時攜帶指向具有CCCF功能的CCCF PSI和真實的被叫信息，使得具有CCCF功能的實體能夠直接從會話建立請求消息中獲得被叫地址信息，從而可以縮短接續(xù)時延；同時，主叫拜訪地的VMSC既能根據setup消息中的CCCF PSI將呼叫路由至IMS域進行錨定，又能根據setup消息中的被叫號碼正常進行緊急呼叫業(yè)務或是合法監(jiān)聽等本地業(yè)務。
圖1為現(xiàn)有技術中VCC業(yè)務的用戶跨域切換控制過程示意圖；圖2為現(xiàn)有技術中采用網絡側控制模式實現(xiàn)VCC業(yè)務的流程圖；圖3為現(xiàn)有技術中采用終端側控制模式實現(xiàn)VCC業(yè)務的流程圖；圖4為本發(fā)明中實現(xiàn)VCC業(yè)務的流程圖；圖5為本發(fā)明中合法監(jiān)聽時，禁止UE發(fā)起VCC業(yè)務的流程圖；圖6為本發(fā)明中呼叫中業(yè)務時，禁止UE發(fā)起VCC業(yè)務的流程圖；圖7為本發(fā)明中終端設備的結構示意圖。
具體實施方式在實現(xiàn)話音業(yè)務連續(xù)性業(yè)務的靜態(tài)錨點過程中，為了使VCC業(yè)務用戶在不支持CAMEL的電路域發(fā)起呼叫時，具有CCCF功能的應用服務器(AS)能夠從與呼叫消息對應的會話請求消息中獲取被叫用戶信息，本發(fā)明在用戶設備發(fā)送的呼叫信令(setup消息)中同時攜帶指向具有CCCF功能的CCCF PSI和真實的被叫信息，并通過CS域傳送到IMS域具有CCCF功能的AS進行錨定后，直接從該會話建立請求消息中獲取被叫信息將會話路由至被叫側進行接續(xù)。
進一步的，拜訪地的網絡設備能根據setup消息中的真實的被叫信息正常進行緊急呼叫業(yè)務或是合法監(jiān)聽等本地業(yè)務。
參閱圖4所示，在不支持CAMEL的CS域中，用戶設備(UE)發(fā)起呼叫的處理流程如下步驟4-1、UE向拜訪移動交換中心(VMSC)發(fā)送setup消息，setup消息中的被叫地址信息中的攜帶的是被叫號碼偽碼(Pseudo called number)。
這里，UE通過在CCCF PSI后追加真實被叫信息的方式來構造Pseudocalled number。如采用“CCCF PSI+真實被叫信息”的方式來構造Pseudo callednumber。另外，考慮到setup消息中的被叫地址的長度限制，被叫地址信息中的也可以只攜帶CCCF PSI，而真實的被叫號碼在setup消息中的其他參數中攜帶。
這里，被叫號碼偽碼中的CCCF PSI可以是由具有CCCF功能的AS根據UE當前所在的位置信息動態(tài)分配并提供給UE的，用以保證將UE從不同的VMSC下發(fā)起的呼叫都能夠根據相對應的CCCF PSI信息路由至具有CCCF功能的AS中進行錨定。
步驟4-2、在建立了主叫側的無線資源連接后，VMSC向UE發(fā)送的Callproceeding消息，然后VMSC根據接收到的Setup消息中被叫地址信息中攜帶的CCCF PSI信息，通過IAM消息將呼叫路由至主叫用戶歸屬的IMS網絡中的MGCF。
當被叫地址信息中只攜帶了CCCF PSI，而真實的被叫號碼在setup消息中的其他參數中攜帶時，在向MGCF發(fā)送的IAM消息需要攜帶有真實被叫號碼的相應參數。
步驟4-3、MGCF判斷出IAM消息中的被叫信息中包含有指向具有CCCF功能的AS的CCCF PSI時，則向問詢呼叫會話控制功能(I-CSCF)發(fā)送INVITE消息，該消息中的被叫信息Requested-URI為被叫號碼偽碼的TEL URI格式。當被叫地址信息中的只攜帶了CCCF PSI，而真實的被叫號碼在IAM消息中的其他參數中攜帶時，MGCF向I-CSCF發(fā)送的INVITE消息中被叫信息Requested-URI為CCCF PSI的TEL URI格式，并且MGCF需要將攜帶在IAM其他參數中的真實的被叫號碼在INVITE消息中的其他參數中發(fā)送至I-CSCF。
步驟4-4、I-CSCF根據Requested-URI中TEL URI格式的被叫號碼偽碼向HSS查詢路由信息，獲取同該被叫號碼偽碼中的CCCF PSI部分相關聯(lián)的AS地址信息，即具有CCCF功能的AS地址信息，然后I-CSCF向具有CCCF功能的AS轉發(fā)INVITE消息，該INVITE消息中的Requested-URI為TEL URI格式的被叫號碼偽碼。為了支持HSS能夠根據TEL-URI格式的被叫號碼偽碼返回被叫號碼偽碼中的CCCF PSI部分對應的具有CCCF功能的AS地址信息，需要預先在HSS中配置TEL-URI格式的CCCF PSI數據同具有該CCCF功能的AS地址信息的對應關系。這里，可以在HSS中定義一種Wildcard CCCF PSI(通配的CCCF PSI)，這樣，當I-CSCF使用TEL-URI格式的被叫號碼偽碼向HSS查詢路由信息時，HSS只需要根據被叫號碼偽碼中的CCCF PSI部分匹配到Wildcard CCCF PSI，就可以向I-CSCF返回該Wildcard CCCF PSI相對應的具有CCCF功能的AS地址信息。
當被叫地址信息中只攜帶了CCCF PSI，而真實的被叫號碼在IAM消息中的其他參數中攜帶時，I-CSCF向具有CCCF功能的AS發(fā)送的INVITE消息中被叫信息Requested-URI為CCCF PSI的TEL URI格式，并且I-CSCF需要將攜帶在IAM其他參數中的真實的被叫號碼在INVITE消息中的其他參數中發(fā)送至具有CCCF功能的AS。
步驟4-5、具有CCCF功能的AS接收到的被叫信息包含CCCF PSI信息的被叫號碼偽碼的會話，或是接收到被叫信息包含CCCF PSI，真實被叫號碼在INVITE消息中的其他參數中攜帶的會話后，對會話進行錨定控制，即觸發(fā)B2BUA功能，終止掉AS接收到會話，然后發(fā)起一個針對原被叫信息的新會話，即具有CCCF功能的AS通過同HSS的Sh接口獲得主叫用戶側的S-CSCF信息，然后，將具有CCCF功能的AS發(fā)起的針對原被叫信息的會話路由至該S-CSCF，并由該S-CSCF將會話路由至原被叫側。
這里，在具有CCCF功能的AS觸發(fā)B2BUA功能，發(fā)起一個針對原被叫信息的新會話時，其會話中的原被叫信息從接收到的INVITE消息中的被叫信息TEL URI格式的Pseudo called number中包含的真實的被叫信息中獲得，或是從接收到的INVITE消息中的其他參數中獲得。
在S-CSCF將呼叫路由至原被叫側的過程中，當原被叫信息為Tel-URI格式時，S-CSCF執(zhí)行ENUM DNS轉換功能，如果能夠將原被叫號碼轉換成SIPURI格式，則后續(xù)的呼叫路由在IMS域中進行，否則，S-CSCF將呼叫路由至本IMS域的BGCF，由BGCF將呼叫最終經由MGCF路由至PSTN或CS域，最后由PSTN或CS域將呼叫接續(xù)至被叫。在具有CCCF功能的AS啟用B2BUA功能時，對于在CCCF終止的會話和在CCCF新發(fā)起的會話，CCCF均對其維護狀態(tài)，以對后續(xù)用戶可能發(fā)起的域間切換進行控制。
從上述流程可知，VCC業(yè)務用戶在不支持CAMEL的CS域發(fā)起呼叫時，其發(fā)送的呼叫建立消息中為攜帶有CCCF PSI信息和真實被叫信息的被叫號碼偽碼，這樣，根據被叫號碼偽碼中的CCCF PSI信息CS域和IMS域的實體可以將呼叫路由至VCC業(yè)務用戶歸屬的IMS域中具有CCCF功能的AS進行錨定，根據被叫號碼偽碼中的真實被叫信息，具有CCCF功能的AS能夠直接從呼叫信令中獲取VCC業(yè)務用戶發(fā)起呼叫的真實被叫號碼信息，然后執(zhí)行B2BUA功能，將呼叫正確地路由至真實被叫側進行接續(xù)。
另外，當VCC業(yè)務用戶在支持CAMEL的CS域以這種基于被叫號碼偽碼的終端側路由控制方式發(fā)起呼叫時，此時VMSC以CAMEL的處理邏輯優(yōu)先于對被叫號碼偽碼的處理邏輯，即VMSC根據主叫側的VCC CAMEL簽約信息通過Initial DP消息將呼叫觸發(fā)到具有NeDS功能的gsmSCF中，后續(xù)處理同圖2中的步驟2-3～2-7。這樣，對于VCC業(yè)務用戶在支持CAMEL的CS域以這種基于被叫號碼偽碼的終端側路由控制方式發(fā)起呼叫時，最終是以基于CAMEL網絡側路由控制方式將呼叫路由至具有CCCF功能的AS進行錨定。因此，這種基于被叫號碼偽碼的終端側路由控制方式同基于CAMEL的網絡側路由控制方式能夠相互結合兼容。
根據本發(fā)明的基于被叫號碼偽碼的終端側路由控制方式，對于UE發(fā)起緊急呼叫業(yè)務，如果運營商允許用戶發(fā)起后續(xù)的VCC業(yè)務，則在對主叫拜訪地的VMSC進行數據配置時，不能將“CCCF PSI+緊急呼叫號碼”(在CCCF PSI后追加真實被叫信息的方式下)或緊急呼叫號碼(真實的被叫號碼在setup消息中的其他參數中攜帶的情況下)作為一種本地緊急呼叫號碼配置在特殊號碼表中，這樣，當VMSC接收到UE發(fā)起的setup消息后，根據setup消息中的被叫號碼中的CCCF PSI直接將呼叫路由至用戶歸屬IMS域中的具有CCCF功能的AS進行錨定，在具有CCCF功能的AS接收到呼叫后，根據被叫信息中的真實被叫號碼和在具有CCCF功能的AS中預先配置的特殊號碼表判斷出用戶撥打的是緊急呼叫號碼，則將呼叫路由回緊急呼叫中心。
在具有CCCF功能的AS在將呼叫錨定后路由回緊急呼叫中心時，由于具有CCCF功能的AS在分配CCCF PSI時并提供給UE時，分配的CCCF PSI可以同用戶當前所在的位置信息具有一定的映射關系，因此具有CCCF功能的AS可以根據CCCF PSI將呼叫路由回距離用戶當前所在的位置最近的緊急呼叫中心，以便緊急呼叫中心可以盡快響應用戶的請求，如派出救援人員等。
根據本發(fā)明的基于被叫號碼偽碼的終端側路由控制方式，對于UE發(fā)起緊急呼叫業(yè)務，如果運營商需要禁止用戶發(fā)起后續(xù)的VCC業(yè)務，可以通過在主叫拜訪地的VMSC進行數據配置，將“CCCF PSI+緊急呼叫號碼”(在CCCFPSI后追加真實被叫信息的方式下)或緊急呼叫號碼(真實的被叫號碼在setup消息中的其他參數中攜帶的情況下)作為一種本地緊急呼叫號碼配置在特殊號碼表中。在上述流程的步驟2中，當VMSC接收到UE發(fā)起的setup消息后，根據setup消息中的被叫號碼“CCCF PSI+緊急呼叫號碼”判斷出為本次呼叫為緊急呼叫，則對呼叫進行緊急呼叫流程處理，即不對UE執(zhí)行鑒權、加密和錨定等流程，直接將呼叫路由至緊急呼叫中心，即不再進行步驟3至步驟5。這樣，由于呼叫沒有被錨定，后續(xù)用戶就無法進行VCC業(yè)務。
為了支持合法監(jiān)聽業(yè)務，將“CCCF PSI+被監(jiān)聽叫號碼”(在CCCF PSI后追加真實被叫信息的方式下)或者被監(jiān)聽號碼(真實的被叫號碼在setup消息中的其他參數中攜帶的情況下)設置成監(jiān)聽號碼；在上述步驟2中，當VMSC接收到UE發(fā)起的setup消息后，根據setup消息中的被叫號碼中的“CCCF PSI+真實被叫號碼”或“真實被叫號碼”判斷出該被叫號碼接聽或者撥打的呼叫都需要被安全機構進行合法監(jiān)聽時，則可以在主叫的VMSC觸發(fā)對被叫用戶的合法監(jiān)聽流程。
主叫拜訪地的VMSC獲知該呼叫已經受到安全機構的合法監(jiān)聽時，此時如果主叫UE或網絡發(fā)起VCC業(yè)務，CS域中的話路即主叫VMSC中的話路將被拆除，主叫UE的話路將會從IMS域中接續(xù)到被叫，這樣在VMSC中執(zhí)行的監(jiān)聽則不能繼續(xù)進行。為了避免已經處于監(jiān)聽狀態(tài)下的呼叫在發(fā)生VCC業(yè)務之后導致的監(jiān)聽不能繼續(xù)進行，可以通過如下兩種方式對已經處于監(jiān)聽狀態(tài)下的呼叫進行處理第一種方式對于處于監(jiān)聽狀態(tài)下的電路域呼叫不進行錨定控制。當使用基于CAMLE的網絡側控制模式實現(xiàn)VCC業(yè)務的錨定處理時，在具有NeDS功能的gsmSCF判斷出該VCC用戶需要受到合法機構的監(jiān)聽，則不生成IMRN，直接下發(fā)Continue繼續(xù)呼叫，則后續(xù)呼叫直接路由至被叫側，不會路由至IMS域中的具有CCCF功能的一個AS上進行錨定，因此，由于電路域的呼叫沒有錨定在IMS域，后續(xù)無論是UE還是網絡都不能成功發(fā)起VCC業(yè)務，從而可以保障合法監(jiān)聽業(yè)務的正常進行。當使用基于被叫號碼偽碼的終端側控制模式實現(xiàn)VCC業(yè)務的錨定處理時，在上述圖4的流程步驟2中，主叫拜訪地的VMSC對于已經處于監(jiān)聽狀態(tài)下的呼叫，則對setup消息中的被叫號碼中的CCCF PSI進行剝除，直接將呼叫路由至被叫側進行接續(xù)，即不再進行步驟3至步驟5。這樣，對于已經處理監(jiān)聽狀態(tài)下的呼叫，VMSC不會根據被叫號碼偽碼中的CCCF PSI將其路由至用戶歸屬IMS域中的具有CCCF功能的AS進行錨定，因此，后續(xù)無論是UE還是網絡都不能成功發(fā)起VCC業(yè)務，從而可以保障合法監(jiān)聽業(yè)務的正常進行。
由于在初期開展VCC業(yè)務時，網絡中可以采用一些配置的方法來實現(xiàn)電路域被叫側VCC業(yè)務的錨定處理，如對GMSC或是對HSS進行增強判斷呼叫是否屬于簽約了VCC業(yè)務的用戶，是否需要將呼叫路由至IMS域以實現(xiàn)電路域被叫側的VCC業(yè)務的錨定處理。對于這些配置方案，則可以通過在GMSC或是HSS中增加相應的處理，即判斷呼叫中的被叫側VCC用戶是否受到合法機構的監(jiān)聽，如果是，則對該呼叫不進行錨定處理。
第二種方式是，對于處于監(jiān)聽狀態(tài)下的呼叫，在進行會話錨定控制后拒絕用戶并避免網絡后續(xù)發(fā)起的VCC業(yè)務請求。該方式適用于基于CAMLE的網絡側控制模式實現(xiàn)電路域主/被叫側VCC業(yè)務的錨定處理，以及基于USSD/SIPNotify的終端側控制模式實現(xiàn)電路域被叫側VCC業(yè)務的錨定處理，以及基于配置方案實現(xiàn)電路域被叫側VCC業(yè)務的錨定處理，以及本發(fā)明所述的基于被叫號碼偽碼的終端側控制模式實現(xiàn)電路域被叫側VCC業(yè)務的錨定處理等多種呼叫錨定方式。
參閱圖5所示，對于第二種方式其主要處理流程如下步驟500、主叫/被叫拜訪地的VMSC或是主叫/被叫歸屬電路域網絡的相關實體(如GMSC)判斷出用戶發(fā)起的呼叫已經處于監(jiān)聽狀態(tài)，這里，發(fā)現(xiàn)主叫/被叫用戶發(fā)起的呼叫已經處于監(jiān)聽狀態(tài)的實體稱為受控MSC。
步驟510、受控MSC向主叫/被叫用戶歸屬IMS域的具有CCCF功能的AS發(fā)送相應的禁止VCC業(yè)務的指示，指示中攜帶相應的需要被禁止VCC業(yè)務的用戶標識，如MSISDN，進一步的，指示中還可以攜帶主叫/被叫用戶當前的呼叫相關信息，如呼叫的主叫/被叫側用戶標識。主叫/被叫用戶歸屬IMS域具有CCCF功能的AS存儲相應的被禁止VCC業(yè)務的用戶標識和其對應的呼叫信息。
步驟520、主叫/被叫用戶歸屬IMS域具有CCCF功能的AS接收到來自于主叫/被叫用戶的切換請求。
步驟530、具有CCCF功能的AS判斷是否對發(fā)起切換的用戶設置了禁止VCC業(yè)務，若是，則進行步驟540，否則，進行步驟550。
步驟540、具有CCCF功能的AS拒絕用戶的切換請求。
步驟550、具有CCCF功能的AS接受用戶的切換請求并進行后續(xù)處理(后續(xù)處理與現(xiàn)技術相同，不再贅述)。
進一步的，在呼叫結束時，具有CCCF功能的AS釋放先前存儲被禁止VCC業(yè)務的用戶標識和其對應的呼叫信息。
另外，主叫/被叫用戶歸屬IMS域具有CCCF功能的AS根據存儲的被禁止的VCC業(yè)務的用戶標識和其對應的呼叫信息，需要保證網絡不允許觸發(fā)對于處于監(jiān)聽狀態(tài)下的用戶的VCC業(yè)務，這樣，無論是UE還是網絡都不能成功發(fā)起VCC業(yè)務，從而可以保障合法監(jiān)聽業(yè)務的正常進行。
在上述第二種方式中，受控MSC向主叫/被叫用戶歸屬IMS域的具有CCCF功能的AS發(fā)送相應的禁止VCC業(yè)務的指示時，受控MSC可以通過管理接口向AS發(fā)送禁止VCC業(yè)務的指示，即當受控MSC接收到監(jiān)聽中心設置的受控數據時，根據受控數據中的受控標識，即需要進行合法監(jiān)聽的用戶標識，判斷出受控用戶的歸屬IMS網絡，并通過管理接口，如運營維護接口向受控用戶歸屬IMS網絡的具有CCCF功能的AS發(fā)送相應的受控數據，具有CCCF功能的AS存儲相應的受控數據，拒絕后續(xù)受控用戶發(fā)起的VCC切換。
另外，也可以由監(jiān)聽中心直接通過管理接口向受控用戶歸屬IMS網絡的具有CCCF功能的AS同步發(fā)送相應的受控數據。在通過管理接口向受控用戶歸屬IMS網絡的具有CCCF功能的AS發(fā)送相應的受控數據時，可以經由一個或多個中間實體將受控數據轉發(fā)或分發(fā)至受控用戶所歸屬的具有CCCF功能的AS。這樣，具有CCCF功能的AS不需要受控MSC在呼叫中進行相應的受控數據的通知，而是直接根據監(jiān)聽中心提供的受控數據拒絕相關的受控用戶的發(fā)起的VCC切換。
在受控MSC向主叫/被叫用戶歸屬IMS域的具有CCCF功能的AS發(fā)送相應的禁止VCC業(yè)務的指示時，受控MSC可以通過在呼叫信令中增加相應的指示，通過呼叫信令將該指示攜帶至具有CCCF功能的AS，即當受控MSC存儲了監(jiān)聽中心設置的受控數據，判斷出受控用戶發(fā)起呼叫時，受控MSC通過在IAM信令中增加相應的指示，當呼叫錨定在具有CCCF功能的AS時，AS根據IAM信令中的相應指示判斷出該用戶的呼叫已經被監(jiān)聽，則拒絕后續(xù)受控用戶發(fā)起的VCC切換；當受控MSC存儲了監(jiān)聽中心設置的受控數據，判斷出受控用戶接收到呼叫時，受控MSC通過在ACM或ANM應答信令中增加相應的指示，受控MSC發(fā)送的ACM或ANM應答信令發(fā)送至對呼叫進行錨定的具有CCCF功能的AS時，AS根據ACM或ANM信令中的相應指示判斷出該用戶的呼叫已經被監(jiān)聽，則拒絕后續(xù)受控用戶發(fā)起的VCC切換。
另外，方式二提出在進行會話錨定控制后拒絕用戶并避免網絡后續(xù)發(fā)起的VCC業(yè)務請求不僅僅可以應用于處于監(jiān)聽狀態(tài)下的呼叫。對于一些電路域的呼叫由于其在呼叫過程中發(fā)起了的業(yè)務，如多方通話、呼叫等待業(yè)務，由于IMS域目前尚不能支持對這些業(yè)務的處理，對于這些呼叫中的業(yè)務，當用戶從電路域切換至IMS域后，則會由于IMS域的業(yè)務能力不足導致中斷了用戶當前進行的這些呼叫中的業(yè)務，帶給用戶不好的業(yè)務感受。因此，同樣可以采用方式二提出的方法，對于已經激活了電路域的呼叫中業(yè)務時，具有CCCF功能的AS需要拒絕用戶并避免網絡后續(xù)發(fā)起的VCC業(yè)務請求。
參閱圖6所示，對于已經激活了電路域的呼叫中業(yè)務時，具有CCCF功能的AS需要拒絕用戶并避免網絡后續(xù)發(fā)起的VCC業(yè)務請求的主要流程如下步驟600、主叫/被叫拜訪地的VMSC或是主叫/被叫歸屬電路域網絡的相關實體(如GMSC)判斷出用戶發(fā)起了的呼叫中的業(yè)務，如呼叫等待，多方通話等。
步驟610、主叫/被叫拜訪地的VMSC或是主叫/被叫歸屬電路域網絡的相關實體(如GMSC)向主叫/被叫用戶歸屬IMS域的具有CCCF功能的AS發(fā)送相應的禁止VCC業(yè)務的指示，指示中攜帶相應的需要被禁止VCC業(yè)務的用戶標識，如MSISDN，進一步的，指示中還可以攜帶主叫/被叫用戶當前的呼叫相關信息，如呼叫的主叫/被叫側用戶標識。主叫/被叫用戶歸屬IMS域具有CCCF功能的AS存儲相應的被禁止VCC業(yè)務的用戶標識和其對應的呼叫信息。
步驟620、主叫/被叫用戶歸屬IMS域具有CCCF功能的AS接收到來自于主叫/被叫用戶的切換請求。
步驟630、具有CCCF功能的AS判斷是否對發(fā)起切換的用戶設置了禁止VCC業(yè)務，若是，則進行步驟640，否則，進行步驟650。
步驟640、AS拒絕用戶的切換請求。
步驟650、AS接受用戶的切換請求并進行后續(xù)處理(后續(xù)處理與現(xiàn)技術相同，不再贅述)。
進一步的，在呼叫結束時，具有CCCF功能的AS釋放先前存儲被禁止VCC業(yè)務的用戶標識和其對應的呼叫信息。
主叫/被叫用戶歸屬IMS域具有CCCF功能的AS根據存儲的被禁止的VCC業(yè)務的用戶標識和其對應的呼叫信息，需要保證網絡不允許觸發(fā)對于處于呼叫中業(yè)務狀態(tài)下的用戶的VCC業(yè)務。這樣，無論是UE還是網絡都不能成功發(fā)起VCC業(yè)務，從而可以保障呼叫中業(yè)務的正常進行。
對于主叫/被叫拜訪地的VMSC或是主叫/被叫歸屬電路域網絡的相關實體(如GMSC)向主叫/被叫用戶歸屬IMS域的具有CCCF功能的AS發(fā)送相應的禁止VCC業(yè)務的指示時，可以是MSC通過呼叫信令將該指示攜帶至具有CCCF功能的AS的方式，其具體實現(xiàn)同上述第二種方式中的在呼叫信令中增加相關指示信息的方法類似，在此不再贅述。
相應的，本發(fā)明的終端設備如圖7所示，該終端設備至少包括一個呼叫信令產生模塊和收發(fā)模塊(其余完成現(xiàn)有其他功能的模塊未示出)，其中呼叫信令產生模塊用于VCC業(yè)務用戶在CS域發(fā)起呼叫時，產生包含具有呼叫連續(xù)性控制功能公共業(yè)務標識和被叫用戶信息的呼叫信令；收發(fā)模塊，用于將呼叫信令產生模塊產生的所述呼叫信令發(fā)送到網絡，以及從網絡接收信令和業(yè)務數據。
顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若對本發(fā)明的這些修改和變型屬于本發(fā)明權利要求
及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。
權利要求
1.一種在話音業(yè)務連續(xù)性中處理呼叫的方法，其特征在于，包括如下步驟A、電路域用戶發(fā)起呼叫，并且在該呼叫中攜帶呼叫連續(xù)性控制功能公共業(yè)務標識(CCCF PSI)和被叫用戶信息；B、將所述電路域呼叫轉換為包含所述CCCF PSI和被叫用戶信息的會話建立請求消息，并路由到具有CCCF功能的實體；C、所述具有CCCF功能實體從所述會話請求中獲取被叫信息，并對會話進行錨定控制。
2.如權利要求
1所述的方法，其特征在于，步驟A中，通過所述呼叫信令的被叫信息部分攜帶所述CCCF PSI和被叫用戶信息；或者在所述呼叫信令的被叫信息部分攜帶所述CCCF PSI，通過呼叫信令中的其他參數攜帶被叫用戶信息。
3.如權利要求
1所述的方法，其特征在于，電路域中的網絡實體發(fā)送初始地址消息時，在該消息的被叫部分攜帶所述CCCF PSI，通過該消息中的其他參數攜帶被叫用戶信息。
4.如權利要求
3所述的方法，其特征在于，轉換所述電路呼叫信令的網絡實體解析出初始地址消息中攜帶被叫用戶信息的參數，根據該消息中的被叫信息部分攜帶的CCCF PSI與解析出的被叫用戶信息構造被叫號碼偽碼，并攜帶在會話建立請求消息中。
5.如權利要求
1至4任一項所述的方法，其特征在于，電路域中接收到所述呼叫的設備在根據呼叫中攜帶的用戶信息確定本次會話中不能發(fā)起VCC業(yè)務時，進一步觸發(fā)禁止VCC業(yè)務的處理流程。
6.如權利要求
5所述的方法，其特征在于，禁止VCC業(yè)務的處理流程包括電路域中接收到所述呼叫的設備進一步向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息；所述具有CCCF功能的網絡實體依據該相關信息，在接收到針對該會話發(fā)起的話音業(yè)務連續(xù)性(VCC)請求時拒絕該請求。
7.如權利要求
6所述的方法，其特征在于，通過呼叫信令將禁止VCC業(yè)務的相關信息發(fā)送到具有CCCF功能的網絡實體；或者，通過管理接口向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
8.如權利要求
5所述的方法，其特征在于，確定本次會話不能發(fā)起VCC業(yè)務的情況包括本次會話中的用戶被合法監(jiān)聽，以及本次會話中的用戶發(fā)起了呼叫中的業(yè)務。
9.如權利要求
8所述的方法，其特征在于，所述用戶被合法監(jiān)聽時，在接受合法監(jiān)聽中心控制的網絡實體接收到受控數據后向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息；或者，由合法監(jiān)聽中心直接向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
10.如權利要求
1至4任一項所述的方法，其特征在于，步驟B之前進一步包括步驟A1、電路域中接收到所述呼叫的設備在根據呼叫中攜帶的被叫用戶信息確定該用戶是否能發(fā)起VCC業(yè)務，若是，將呼叫路由到具有信令轉換功能的網絡實體，并繼續(xù)步驟B；否則，則將該呼叫直接路由到被叫用戶。
11.如權利要求
10所述的方法，其特征在于，確定本次會話不能發(fā)起VCC業(yè)務的情況包括該用戶被合法監(jiān)聽，以及該用戶發(fā)起了呼叫中的業(yè)務。
12.如權利要求
1至4任一項所述的方法，其特征在于，步驟B之前還包括步驟A2、電路域接收到所述呼叫的網絡實體根據所述被叫用戶信息和預先配置的緊急呼叫中心信息，判斷被叫是否為緊急中心，若是，則將呼叫直接路由到緊急中心；否則，將呼叫路由到具有信令轉換功能的網絡實體，并繼續(xù)步驟B。
13.如權利要求
1至4任一項所述的方法，其特征在于，所述具有CCCF功能的實體獲取被叫信息后，根據所述被叫用戶信息和預先配置的緊急呼叫中心信息判斷該被叫是否為緊急中心，若是則將呼叫路由到緊急中心，否則，對會話進行錨定控制。
14.如權利要求
13所述的方法，其特征在于，將呼叫路由到緊急中心時，根據CCCF公共業(yè)務標識與用戶當前所在位置的對應關系，將呼叫路由到用戶位置最近的緊急呼叫中心。
15.一種在話音業(yè)務連續(xù)性中處理呼叫的方法，其特征在于，包括如下步驟網絡中接續(xù)呼叫的網絡實體將用戶發(fā)起的呼叫路由到IMS網絡中具有呼叫連續(xù)性控制功能(CCCF功能)的網絡實體，由該網絡實體對會話進行錨定控制；以及所述具有CCCF功能的網絡實體在控制所述會話過程中接收到針對該會話發(fā)起的話音業(yè)務連續(xù)性(VCC)請求時，判斷是否禁止該請求，若是，則拒絕該請求，否則，接受該請求并進行后續(xù)處理。
16.如權利要求
15所述的方法，其特征在于，所述接續(xù)呼叫的網絡實體在確定本次會話中不能發(fā)起VCC業(yè)務時，進一步向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息，由網絡實體設置相應的標識。
17.如權利要求
16所述的方法，其特征在于，通過所述呼叫信令將禁止VCC業(yè)務的相關信息發(fā)送到具有CCCF功能的網絡實體；或者，通過管理接口向所述具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
18.如權利要求
16所述的方法，其特征在于，確定本次會話不能發(fā)起VCC業(yè)務的情況包括本次會話中的用戶被合法監(jiān)聽，以及本次會話中的用戶進行了呼叫中的業(yè)務。
19.如權利要求
18所述的方法，其特征在于，用戶被合法監(jiān)聽時，由接受合法監(jiān)聽中心控制的網絡實體接收到受控數據后向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息；或者，由合法監(jiān)聽中心直接向具有CCCF功能的網絡實體發(fā)送禁止VCC業(yè)務的相關信息。
20.一種終端設備，其特征在于，包括呼叫信令產生模塊，用于VCC業(yè)務用戶發(fā)起呼叫時，產生包含具有呼叫連續(xù)性控制功能公共業(yè)務標識和被叫用戶信息的呼叫信令；收發(fā)模塊，與所述呼叫信令產生模塊連接，用于將呼叫信令產生模塊產生的所述呼叫信令發(fā)送到網絡，以及從網絡接收信令和業(yè)務數據。
專利摘要
本發(fā)明公開了一種在話音業(yè)務連續(xù)性中處理呼叫的方法，該方法在電路域用戶發(fā)起呼叫時，在該呼叫中攜帶呼叫連續(xù)性控制功能公共業(yè)務標識(CCCF PSI)和被叫用戶信息；將所述電路域呼叫轉換為包含所述CCCF PSI和被叫用戶信息的會話建立請求消息，并路由到具有CCCF功能的實體；該實體從所述會話請求中獲取被叫信息，并對會話進行錨定控制。本發(fā)明還同時公開了一種終端設備，至少包括呼叫信令產生模塊，用于VCC業(yè)務用戶發(fā)起呼叫時，產生包含具有呼叫連續(xù)性控制功能公共業(yè)務標識和被叫用戶信息的呼叫信令；收發(fā)模塊，與所述呼叫信令產生模塊連接，用于將呼叫信令產生模塊產生的所述呼叫信令發(fā)送到網絡，以及從網絡接收信令和業(yè)務數據。
文檔編號H04W4/16GK1997201SQ200510137207
公開日2007年7月11日 申請日期2005年12月31日
發(fā)明者朱東銘, 段小琴 申請人:華為技術有限公司導出引文BiBTeX, EndNote, RefMan