專(zhuān)利名稱(chēng):一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法和設(shè)備的制作方法
技術(shù)領(lǐng)域:
本發(fā)明涉及通信技術(shù)領(lǐng)域,特別是涉及一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法和設(shè)備。
背景技術(shù):
IP多々某體子系統(tǒng)(IP Multimedia Subsystem, IMS)網(wǎng)絡(luò)是第三代合作伙 伴計(jì)劃(3rd Generation Partnership Project, 3GPP )定義的,3GPP 24.229標(biāo)準(zhǔn) 中定義的IP多々某體子系統(tǒng)業(yè)務(wù)控制(IP Multimedia Subsystem Service Control, ISC)接口是指呼叫會(huì)話(huà)控制功能(Call Session Control Function, CSCF )與 應(yīng)用服務(wù)器(Application Server, AS)之間的接口。其中,被叫服務(wù)-呼叫會(huì) 話(huà)控制功能(Serving-Call Session Control Function, S-CSCF )對(duì)于觸發(fā)AS的 前轉(zhuǎn)識(shí)別只是對(duì)觸發(fā)前后的消息中的請(qǐng)求資源標(biāo)志符(Request-Universal Resource Identifier, Request-URI)簡(jiǎn)單的比較,當(dāng)此判斷應(yīng)用到IMS網(wǎng)絡(luò)上時(shí), 將面臨如下問(wèn)題因業(yè)務(wù)需要和場(chǎng)景的繁多,與S-CSCF對(duì)接觸發(fā)的AS經(jīng)常進(jìn) 行一些改號(hào)業(yè)務(wù),對(duì)于請(qǐng)求INVITE消息的Request-URI經(jīng)常修改為一些和業(yè)務(wù) 相關(guān)的形式,導(dǎo)致S-CSCF識(shí)別為前轉(zhuǎn)而重復(fù)進(jìn)行被叫路由導(dǎo)致業(yè)務(wù)失敗。
3GPP 24.229中對(duì)于S-CSCF識(shí)別前轉(zhuǎn)的描述并未給出詳細(xì)具體描述,被叫 S-CSCF對(duì)于觸發(fā)AS的前轉(zhuǎn)業(yè)務(wù)的識(shí)別只是根據(jù)觸發(fā)前后會(huì)話(huà)發(fā)起協(xié)議(the Session Initiation Protocol, SIP )消息中的Request-URI是否改變來(lái)作簡(jiǎn)單的識(shí) 別。例如觸發(fā)AS前的SIP消息中的Request-URI為"TEL:+8675528760001", 觸發(fā)AS后AS將SIP消息中的Request-URI修改為了 "TEL:+8613911112222", 那么S-CSCF判斷觸發(fā)前后的Request-URI發(fā)生了變化,識(shí)別為前轉(zhuǎn)直接路由到 前轉(zhuǎn)方網(wǎng)絡(luò)不進(jìn)行后續(xù)業(yè)務(wù)觸發(fā)。
在實(shí)現(xiàn)本發(fā)明的過(guò)程中,發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)至少存在以下問(wèn)題
現(xiàn)有技術(shù)方案中,S-CSCF對(duì)前轉(zhuǎn)的識(shí)別只是才艮據(jù)觸發(fā)前后SIP消息中的 Request-URI是否改變來(lái)識(shí)別,因業(yè)務(wù)需要和場(chǎng)景的繁多,與S-CSCF對(duì)接觸發(fā)
6的AS對(duì)于INVITE消息的Request-URI經(jīng)常修改為各種和業(yè)務(wù)相關(guān)的形式,當(dāng)對(duì) Request-URI改變的簡(jiǎn)單的判斷應(yīng)用到IMS網(wǎng)絡(luò)上時(shí),會(huì)出現(xiàn)前轉(zhuǎn)業(yè)務(wù)識(shí)別不 準(zhǔn)確,或無(wú)法識(shí)別前轉(zhuǎn)業(yè)務(wù)的問(wèn)題。
發(fā)明內(nèi)容
本發(fā)明實(shí)施例要解決的問(wèn)題是提供一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法和設(shè)備,用 于準(zhǔn)確識(shí)別前轉(zhuǎn)業(yè)務(wù)。
為達(dá)到上述目的,本發(fā)明實(shí)施例一方面提出一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法, 包括
當(dāng)接收的消息中的請(qǐng)求資源標(biāo)識(shí)符Request-URI被改變時(shí),判斷所述消息 是否符合初始過(guò)濾規(guī)則iFC所包含的一個(gè)或多個(gè)業(yè)務(wù)觸發(fā)點(diǎn)SPT中的匹配條 件;
當(dāng)所述消息符合所述iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件時(shí),根 據(jù)所述iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn) 業(yè)務(wù)。
另一方面,本發(fā)明實(shí)施例還提出一種S-CSCF,包括
匹配判斷模塊,用于當(dāng)接收的消息中的Request-URI被改變時(shí),判斷所述 消息是否符合iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件;
前轉(zhuǎn)識(shí)別模塊,用于當(dāng)所述匹配判斷模塊判斷所述消息符合所述iFC所 包含的一個(gè)或多個(gè)SPT中的匹配條件時(shí),根據(jù)所述iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別 標(biāo)識(shí)識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù)。
本發(fā)明實(shí)施例的技術(shù)方案具有以下優(yōu)點(diǎn),因?yàn)椴捎昧烁鶕?jù)iFC所包含的 一個(gè)或多個(gè)SPT中的匹配條件及其對(duì)應(yīng)的擴(kuò)展參數(shù)進(jìn)行前轉(zhuǎn)業(yè)務(wù)識(shí)別的方法 和設(shè)備,從而,可以準(zhǔn)確的進(jìn)行前轉(zhuǎn)業(yè)務(wù)的識(shí)別,達(dá)到了提高業(yè)務(wù)識(shí)別準(zhǔn)確 率,避免因誤識(shí)別而導(dǎo)致通信資源浪費(fèi)的效果。
為了更清楚地說(shuō)明本發(fā)明實(shí)施例的技術(shù)方案,下面將對(duì)實(shí)施例描述中所需要使用的附圖作簡(jiǎn)單地介紹,顯而易見(jiàn)地,下面描述中的附圖僅僅是本發(fā) 明的一些實(shí)施例,對(duì)于本領(lǐng)域普通技術(shù)人員來(lái)講,在不付出創(chuàng)造性勞動(dòng)的前 提下,還可以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明實(shí)施例一中一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法的流程示意圖2為本發(fā)明實(shí)施例二中一種S-CSCF的結(jié)構(gòu)示意圖; 圖3為本發(fā)明實(shí)施例三中一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法的流程示意圖; 圖4為本發(fā)明實(shí)施例四中一種原被叫信息的獲取方法的流程示意圖; 圖5為本發(fā)明實(shí)施例四中場(chǎng)景一下獲取原被叫信息的流程示意圖; 圖6為本發(fā)明實(shí)施例四中場(chǎng)景二下獲取原被叫信息的流程示意圖; 圖7為本發(fā)明實(shí)施例四中場(chǎng)景三下獲取原被叫信息的流程示意圖。
具體實(shí)施例方式
下面將結(jié)合本發(fā)明實(shí)施例中的附圖,對(duì)本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行 清楚、完整地描述,顯然,所描述的實(shí)施例僅僅是本發(fā)明的一部分實(shí)施例, 而不是全部的實(shí)施例?;诒景l(fā)明中的實(shí)施例,本領(lǐng)域普通技術(shù)人員在沒(méi)有 做出創(chuàng)造性勞動(dòng)前提下所獲得的所有其他實(shí)施例,都屬于本發(fā)明保護(hù)的范圍。
本發(fā)明實(shí)施例一提供了 一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法,其流程示意圖如圖l所 示,包括以下步驟
步驟S101、當(dāng)接收的消息中的Request-URI被改變時(shí),判斷該消息是否符 合初始過(guò)濾規(guī)則(Initial Filter Criteria, iFC )所包含的一個(gè)或多個(gè)業(yè)務(wù)觸發(fā)點(diǎn) (Service Point Trigger, SPT )中的匹配條件。
當(dāng)該消息符合iFC所包含的 一個(gè)或多個(gè)SPT中的匹配條件時(shí),轉(zhuǎn)入步驟 S102;
當(dāng)該消息不符合iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件時(shí),轉(zhuǎn)入步驟 S103。
其中,接收的消息可以為應(yīng)用服務(wù)器AS觸發(fā)后返回的消息。 其中,iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件具體通過(guò)精確值或正則 表達(dá)式進(jìn)行設(shè)置,該匹配條件的具體內(nèi)容為在第一SPT中的〈Request-URI〉字段設(shè)置的Request-URI內(nèi)容;和/或,
在第二SPT中的〈SIPHeader〉字段設(shè)置的History-info頭域;和/或,
在第三SPT中的〈SIPHeader〉字段設(shè)置的Diversion頭域。
具體的,基于上述的匹配條件設(shè)置,該消息符合iFC所包含的一個(gè)或多個(gè)
SPT中的匹配條件的判斷依據(jù)包括以下幾種情況
當(dāng)所接收的AS觸發(fā)后返回的消息中的Request-URI與在第一SPT中的
〈Request-URI〉字段設(shè)置的Request-URI內(nèi)容相匹配時(shí),判斷該消息符合匹配條
件;或,
當(dāng)所接收的AS觸發(fā)后返回的消息中的Request-URI與在第一SPT中的 〈Request-URI〉字段設(shè)置的Request-URI內(nèi)容相匹配,且該消息在AS觸發(fā)前所 對(duì)應(yīng)的消息和在第二SPT中的〈SIPHeader〉字段設(shè)置的History-info頭域的信息 相匹配時(shí),判斷該消息符合匹配條件;或,
當(dāng)所接收的AS觸發(fā)后返回的消息中的Request-URI和該消息在AS觸發(fā)前 所對(duì)應(yīng)的消息之間的差異性關(guān)系與在第一SPT中的〈Request-URI〉字段設(shè)置的 Request-URI內(nèi)容和在第二SPT中的〈SIPHeader〉字段設(shè)置的History-info頭域所 對(duì)應(yīng)的差異性關(guān)系相匹配時(shí),判斷該消息符合匹配條件;或,
當(dāng)所接收的AS觸發(fā)后返回的消息中的Request-URI與在第一SPT中的 〈Request-URI〉字段設(shè)置的Request-URI內(nèi)容匹配,且與在第三SPT中的 〈SIPHeader〉字段設(shè)置的Diversion頭域所設(shè)置的內(nèi)容相匹配時(shí),判斷該消息符 合匹配條件。
步驟S102、才艮據(jù)iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別消息所對(duì)應(yīng)的業(yè)務(wù)是否 為前轉(zhuǎn)業(yè)務(wù)。
前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)包括力良務(wù)器標(biāo)識(shí)和前轉(zhuǎn)標(biāo)識(shí)。
當(dāng)iFC包含的服務(wù)器標(biāo)識(shí)為全網(wǎng)識(shí)別位置字符,且前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確認(rèn)字 符時(shí),轉(zhuǎn)入步驟S104;
當(dāng)iFC包含的服務(wù)器標(biāo)識(shí)不是全網(wǎng)識(shí)別位置字符,或該前轉(zhuǎn)標(biāo)識(shí)不是前轉(zhuǎn) 確認(rèn)字符時(shí),轉(zhuǎn)入步驟S103。
具體的,根據(jù)iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別該消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù)的流程為
判斷iFC包含的服務(wù)器標(biāo)識(shí)是否為全網(wǎng)識(shí)別位置字符;
當(dāng)該iFC包含的服務(wù)器標(biāo)識(shí)為全網(wǎng)識(shí)別位置字符時(shí),判斷該前轉(zhuǎn)標(biāo)識(shí)是否 為前轉(zhuǎn)確認(rèn)字符;
當(dāng)該前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確認(rèn)字符時(shí),識(shí)別該消息所對(duì)應(yīng)的業(yè)務(wù)為前轉(zhuǎn)業(yè)務(wù)。 步驟S103、識(shí)別該消息所對(duì)應(yīng)的業(yè)務(wù)為非前轉(zhuǎn)業(yè)務(wù),進(jìn)行該消息所對(duì)應(yīng)
的后續(xù)業(yè)務(wù)的觸發(fā)。
步驟S104、識(shí)別該消息所對(duì)應(yīng)的業(yè)務(wù)為前轉(zhuǎn)業(yè)務(wù),將該消息路由到前轉(zhuǎn)
方網(wǎng)絡(luò)。
進(jìn)一步需要指出的是,在上述的方法中,當(dāng)iFC為針對(duì)單一用戶(hù)的配置時(shí), 該iFC配置在該單一用戶(hù)所簽約的歸屬簽約用戶(hù)服務(wù)器(Home Subscriber Server, HSS )上;當(dāng)iFC為針對(duì)當(dāng)前網(wǎng)絡(luò)的全部用戶(hù)的配置時(shí),該iFC配置在 S-CSCF上。
進(jìn)一步的,上述方法還包括根據(jù)消息中攜帶的History-Info信息,獲取該 消息在AS觸發(fā)前所對(duì)應(yīng)消息的原被叫信息的方法,具體流程如下
獲取所接收的AS觸發(fā)后返回的消息中的最后一條index信息;
根據(jù)該index信息,獲耳又該index信息的父級(jí)index信息;
確認(rèn)該父級(jí)index信息所對(duì)應(yīng)的信息為該消息在AS觸發(fā)前所對(duì)應(yīng)消息的 原凈皮叫信息。
才艮據(jù)實(shí)際情況,對(duì)本發(fā)明實(shí)施例中的步驟或流程進(jìn)行相應(yīng)的調(diào)換或改變, 并不影響本專(zhuān)利保護(hù)范圍。
本發(fā)明實(shí)施例的技術(shù)方案具有以下優(yōu)點(diǎn),因?yàn)椴捎昧烁鶕?jù)iFC所包含的 一個(gè)或多個(gè)SPT中的匹配條件及其對(duì)應(yīng)的擴(kuò)展參數(shù)進(jìn)4亍前轉(zhuǎn)業(yè)務(wù)識(shí)別的方 法,從而,可以準(zhǔn)確的進(jìn)行前轉(zhuǎn)業(yè)務(wù)的識(shí)別,達(dá)到了提高業(yè)務(wù)識(shí)別準(zhǔn)確率, 避免因誤識(shí)別而導(dǎo)致通信資源浪費(fèi)的效果。
基于上述實(shí)施例所提出的方法,本發(fā)明實(shí)施例二提出了一種S-CSCF,其 結(jié)構(gòu)示意圖如圖2所示,具體包括匹配判斷模塊1,用于當(dāng)接收的消息中的Request-URI被改變時(shí),判斷該 消息是否符合iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件
匹配判斷模塊1具體用于應(yīng)用服務(wù)器AS觸發(fā)后返回的消息,當(dāng)接收的消 息中的Request-URI被改變時(shí),判斷所述消息是否符合iFC所包含的一個(gè)或多 個(gè)SPT中的匹配條件。
匹配判斷才莫塊1,具體包括
第一判斷子模塊11,用于判斷所接收的AS觸發(fā)后返回的消息中的 Request-URI是否4皮改變;
條件獲取子模塊12,用于當(dāng)?shù)谝慌袛嘧幽K11判斷所接收的AS觸發(fā)后 返回的消息中的Request-URI被改變時(shí),在HSS或本地獲取所接收的AS觸發(fā) 后返回的消息所對(duì)應(yīng)的iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件;
第二判斷子模塊13,用于判斷所接收的AS觸發(fā)后返回的消息是否符合 條件獲取子模塊12所獲取的匹配條件。
前轉(zhuǎn)識(shí)別模塊2,用于當(dāng)匹配判斷模塊1判斷該消息符合iFC所包含的一 個(gè)或多個(gè)SPT中的匹配條件時(shí),根據(jù)該iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別該 消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù),該前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)包括服務(wù)器標(biāo)識(shí)和 前轉(zhuǎn)標(biāo)識(shí),前轉(zhuǎn)識(shí)別^t塊2具體包括
第三判斷子模塊21,用于根據(jù)所述匹配條件,判斷服務(wù)器標(biāo)識(shí)是否為全 網(wǎng)識(shí)別位置字符;
第四判斷子模塊22,用于當(dāng)?shù)谌袛嘧幽K21判斷服務(wù)器標(biāo)識(shí)為全網(wǎng)識(shí) 別位置字符時(shí),判斷前轉(zhuǎn)標(biāo)識(shí)是否為前轉(zhuǎn)確認(rèn)字符,當(dāng)前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確認(rèn) 字符時(shí),識(shí)別消息所對(duì)應(yīng)的業(yè)務(wù)為前轉(zhuǎn)業(yè)務(wù)。
進(jìn)一步的,S-CSCF還包括
信息獲取模塊3,用于根據(jù)所接收的AS觸發(fā)后返回的消息中的最后一條 索虧1 index信息的父級(jí)index信息,獲取該消息在AS觸發(fā)前所對(duì)應(yīng)消息的原 凈皮叫信息。
上述模塊可以分布于一個(gè)裝置,也可以分布于多個(gè)裝置。上述模塊可以 合并為一個(gè)模塊,也可以進(jìn)一步拆分成多個(gè)子模塊。
ii本發(fā)明實(shí)施例的技術(shù)方案具有以下優(yōu)點(diǎn),因?yàn)椴捎昧烁鶕?jù)iFC所包含的 一個(gè)或多個(gè)SPT中的匹配條件及其對(duì)應(yīng)的擴(kuò)展參數(shù)進(jìn)行前轉(zhuǎn)業(yè)務(wù)識(shí)別的 S-CSCF,從而,可以準(zhǔn)確的進(jìn)行前轉(zhuǎn)業(yè)務(wù)的識(shí)別,達(dá)到了提高業(yè)務(wù)識(shí)別準(zhǔn)確 率,避免因誤識(shí)別而導(dǎo)致通信資源浪費(fèi)的效果。
在現(xiàn)有的技術(shù)場(chǎng)景下,結(jié)合具體的示例,Request-UR形式變換應(yīng)用場(chǎng)景 主要包括以下幾種情況
情況一、被叫觸發(fā)前的Request-URI為"tel:+8675512345",對(duì)接的AS出 于業(yè)務(wù)需求或者自身支持能力限制,將觸發(fā)后的Request-URI作了形式變換, 修改為了 "sip:+8675512345@huawei.com;user=phone,,。
情況二、觸發(fā)前的Request-URI為"tel:12345;phone-context=+86755",對(duì) 接的AS對(duì)此短號(hào)形式進(jìn)行了號(hào)碼分析和規(guī)整,將觸發(fā)后的R叫uest-URI規(guī)整為 了 "tel:+8675512345",實(shí)際上是同一個(gè)號(hào)碼。
情況三、觸發(fā)前的Request-URI為"tel:+8675512345",對(duì)接的AS進(jìn)行了 業(yè)務(wù)參數(shù)的添加(例如Cic),觸發(fā)AS后的Request-URI被修改為了 "tel:+8675512345;cic=+8001"。
情況四、觸發(fā)前的Request-URI為"tel:+8613911112222",對(duì)接的AS進(jìn) 行了特殊業(yè)務(wù)處理,將號(hào)碼統(tǒng)一添加了運(yùn)營(yíng)預(yù)選前綴(例如17951 ),觸發(fā) AS后的Request-URI被修改為了 "tel:179586113911112222"。
需要指出的是,上述四種情況只是為了方便描述而選擇了具體的號(hào)碼或 標(biāo)識(shí)的示例,在具體的應(yīng)用中,具體號(hào)碼或標(biāo)識(shí)內(nèi)容的變化并不影響上述各 情況所代表的示例范圍。
下面,為了更清楚的闡述本發(fā)明實(shí)施例所提出的技術(shù)方案,本發(fā)明在后 續(xù)實(shí)施例中結(jié)合上述的幾種情況,進(jìn)行具體的說(shuō)明。
現(xiàn)有的前轉(zhuǎn)識(shí)別技術(shù)只是簡(jiǎn)單的對(duì)觸發(fā)前后的R叫uest-URI進(jìn)行比 較,這樣的識(shí)別并不能準(zhǔn)確區(qū)分前轉(zhuǎn)業(yè)務(wù),因此,會(huì)將多種非前轉(zhuǎn)場(chǎng)景被 識(shí)別成了前轉(zhuǎn)情況,而額外多進(jìn)行一次被叫路由過(guò)程,并進(jìn)而導(dǎo)致業(yè)務(wù)失 敗,影響了業(yè)務(wù)響應(yīng)效率,浪費(fèi)了網(wǎng)絡(luò)資源。本發(fā)明實(shí)施例所提出的技術(shù)方案是通過(guò)S-CSCF靈活運(yùn)用已有的用戶(hù) 簽約數(shù)據(jù)iFC和擴(kuò)展部分參數(shù)對(duì)前轉(zhuǎn)的靈活識(shí)別方式,解決S-CSCF對(duì)各 種場(chǎng)景下AS改號(hào)后的前轉(zhuǎn)的有效識(shí)別,避免被叫觸發(fā)時(shí)影響路由的部分 發(fā)生變化,額外多進(jìn)行一次被叫路由過(guò)程所帶來(lái)的導(dǎo)致業(yè)務(wù)失敗。
在本發(fā)明實(shí)施例所提出的技術(shù)方案中,S-CSCF靈活運(yùn)用規(guī)范已有的 用戶(hù)簽約數(shù)據(jù)中iFC的SPT中〈R叫uest-URI〉字段和/或〈SIPHeader〉字段以 及其他字段來(lái)進(jìn)行匹配條件的配置,并判斷觸發(fā)AS后的消息是否滿(mǎn)足制 定的SPT,在上述判斷的結(jié)果為是時(shí),將當(dāng)前的消息觸發(fā)到該SPT所對(duì)應(yīng) 的〈ApplicationServer〉服務(wù)器。對(duì)于前轉(zhuǎn)業(yè)務(wù),在〈ApplicationServer〉中的 〈ServerName〉字段,不再配置AS的地址,而是配置了全網(wǎng)識(shí)別的 一 個(gè)位 置字符,即全網(wǎng)識(shí)別位置字符,并且配置S-CSCF自身進(jìn)行業(yè)務(wù)識(shí)別的一 個(gè)擴(kuò)展參數(shù)作為前轉(zhuǎn)標(biāo)識(shí),本發(fā)明實(shí)施例中以"CF,,對(duì)該前轉(zhuǎn)標(biāo)識(shí)進(jìn)行命 名,在具體的應(yīng)用場(chǎng)景中,參數(shù)名稱(chēng)的變化并不會(huì)影響本發(fā)明的保護(hù)范圍。 例如用戶(hù)簽約的iFC為 <InitialFilterCriteria> <Priority〉0</Priori!y> <TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF> <SPT〉
<ConditionNegated>l</ConditionNegated> <Group>0</Group>
〈Request-URI〉制定的URI</Request-URI> </SPT> </TriggerPoint> <ApplicationServer>
〈ServerName〉全網(wǎng)識(shí)別位置字符;CF=1 </ServerName> <DefaultHandling index="0">0</DefaultHandling> </ Applications erver>
13</InitialFilterCriteria>
當(dāng)觸發(fā)AS后的SIP消息中的Request-URI發(fā)生了變化,消息中的 Request-URI被AS修改為制定的URI時(shí),S-CSCF執(zhí)行此條iFC時(shí)會(huì)判斷 該消息滿(mǎn)足此觸發(fā)點(diǎn)的匹配條件,從而,觸發(fā)到<ApplicationServer>中的 <ServerName>,此時(shí)S-CSCF判斷〈ServerName〉是全網(wǎng)識(shí)別的位置字符而 非AS地址,將不進(jìn)行ISC接口的AS觸發(fā)路由而是進(jìn)行自身的業(yè)務(wù)邏輯 判斷。例如獲取<ServerName〉中擴(kuò)展的前轉(zhuǎn)標(biāo)識(shí)"CF",根據(jù)此參數(shù)判 斷當(dāng)前消息所對(duì)應(yīng)的業(yè)務(wù)是否是前轉(zhuǎn)業(yè)務(wù),如果CF=1則為前轉(zhuǎn),如果CF=0 或者不存在則認(rèn)為非前轉(zhuǎn)。
具體的,基于上述的技術(shù)思路,本發(fā)明實(shí)施例所提出的技術(shù)方案通過(guò) 對(duì)iFC數(shù)據(jù)配置及擴(kuò)展參數(shù)"CF"的靈活運(yùn)用,解決各種場(chǎng)景下的前轉(zhuǎn)識(shí) 別問(wèn)題,下面,通過(guò)本發(fā)明實(shí)施例三對(duì)具體的識(shí)別過(guò)程進(jìn)行說(shuō)明,其流程 示意圖如圖3所示,包括以下步驟
步驟S301、 S-CSCF收到從AS觸發(fā)回來(lái)的消息后,判斷該消息中的 Request-URI是否,皮改變。
如果Request-URI未凈皮改變,則轉(zhuǎn)入步驟S302;
如果Request-URI被改變,則轉(zhuǎn)入步驟S303,進(jìn)一步判斷該消息所對(duì) 應(yīng)的業(yè)務(wù)是否是前轉(zhuǎn)業(yè)務(wù)。
步驟S302、 S-CSCF繼續(xù)對(duì)該消息執(zhí)行業(yè)務(wù)觸發(fā),而不進(jìn)行前轉(zhuǎn)。 步驟S303、 S-CSCF判斷該Request-URI是否符合iFC所包含的一個(gè) 或多個(gè)SPT中的匹配條件。
當(dāng)S-CSCF判斷該Request-URI符合匹配條件時(shí),轉(zhuǎn)入步驟S304; 當(dāng)S-CSCF判斷該Request-URI不符合匹配條件時(shí),轉(zhuǎn)入步驟S302。 在本步驟中,S-CSCF執(zhí)行下一條S-CSCF內(nèi)部業(yè)務(wù)邏輯識(shí)別(如前轉(zhuǎn) 識(shí)別邏輯)的iFC,使用iFC中SPT的〈Request-URI〉和/或〈SIPHeader〉以 及其他字段所設(shè)置的條件作為觸發(fā)S-CSCF進(jìn)行內(nèi)部前轉(zhuǎn)識(shí)別邏輯的判斷 驅(qū)動(dòng),即,利用iFC的觸發(fā)條件的滿(mǎn)足,進(jìn)一步觸發(fā)根據(jù)〈ApplicationServer〉 所進(jìn)行的前轉(zhuǎn)業(yè)務(wù)識(shí)別。步驟S304 、 S-CSCF判斷滿(mǎn)足該STP觸發(fā)條件所觸發(fā)的 〈ApplicationServer〉是否為全網(wǎng)識(shí)別位置字符。
當(dāng)〈ApplicationServer〉為全網(wǎng)識(shí)別位置字符時(shí),轉(zhuǎn)入步驟S305;
當(dāng)〈ApplicationServer〉不是全網(wǎng)識(shí)別位置字符時(shí),轉(zhuǎn)入步驟S302。
步驟S305 、 S-CSCF判斷滿(mǎn)足該SPT觸發(fā)條件所觸發(fā)的 <ApplicationServer>中的前轉(zhuǎn)標(biāo)識(shí)是否為前轉(zhuǎn)確^人字符。
基于本發(fā)明實(shí)施例前述的場(chǎng)景設(shè)置,本步驟相當(dāng)于判斷"CF,,的標(biāo)識(shí) 值是否為1, CF=1即表示前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確認(rèn)字符。
當(dāng)S-CSCF判斷前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確認(rèn)字符,即CF4時(shí),轉(zhuǎn)入步驟S306;
當(dāng)S-CSCF判斷前轉(zhuǎn)標(biāo)識(shí)不是前轉(zhuǎn)確認(rèn)字符,或不存在前轉(zhuǎn)標(biāo)識(shí),即 CF=0或無(wú)CF值時(shí),轉(zhuǎn)入步驟S302。
步驟S306、 S-CSCF識(shí)別該消息所對(duì)應(yīng)的業(yè)務(wù)為前轉(zhuǎn)業(yè)務(wù),將該消息路 由到前轉(zhuǎn)方網(wǎng)絡(luò)。
根據(jù)實(shí)際情況,對(duì)本發(fā)明實(shí)施例中的步驟或流程進(jìn)行相應(yīng)的調(diào)換或改變, 并不影響本專(zhuān)利保護(hù)范圍。
為了更加清楚地對(duì)上述識(shí)別過(guò)程進(jìn)行說(shuō)明,本發(fā)明實(shí)施例#4居具體的 應(yīng)用示例對(duì)上述的方法實(shí)現(xiàn)場(chǎng)景進(jìn)行描述。
首先,需要說(shuō)明的是,上述的SPT中的匹配條件可以支持精確配置, 也可以支持正則表達(dá)式配置。
下面,根據(jù)具體的實(shí)施場(chǎng)景分情況進(jìn)行說(shuō)明。
情況一、當(dāng)S-CSCF只針對(duì)AS觸發(fā)回來(lái)的消息中的Request-URI來(lái)識(shí) 別是否是前轉(zhuǎn)時(shí),則只需要在SPT中配置〈Request-URI〉為制定的 Request-URI即可,可以是精確值,也可以是正則表達(dá)式。
具體示例如下
例1:當(dāng)用戶(hù)B需要#1前轉(zhuǎn)到C時(shí),S-CSCF可通過(guò)如下配置的iFC 來(lái)識(shí)別此次前轉(zhuǎn)(例如C的號(hào)碼為"TEL:+867551234"): <InitialFilterCriteria>
<Priority>0</Priority><TriggerPoint>
<CondkionTypeCNF>0</ConditionTypeCNF> <SPT>
<ConditionNegated〉 1 </ConditionNegated> <Group>0</Group>
<Request-URI>TEL:+867551234</Request-URI> </SPT> </TriggerPoint> <ApplicationServer>
〈ServerName〉全網(wǎng)識(shí)別4立置字符;CF= 1 </ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria>
例2:觸發(fā)AS后R叫uest-URI被改號(hào)為具有制定的具有某些特征的正 則匹配URI (例如以+86755為前綴的號(hào)碼),則識(shí)別為前轉(zhuǎn)。S-CSCF可 通過(guò)如下配置的iFC進(jìn)行此類(lèi)識(shí)別。 <InitialFilterCriteria>
<Priority〉0</Priority> <TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF〉 <SPT>
<ConditionNegated> 1 </ConditionNegated> <Group>0</Group>
<R^quest-URI>TEL:+86755(.*)</Request-URI> </SPT> </TriggerPoint> <ApplicationServer>〈ServerName〉全網(wǎng)識(shí)別位置字符;CF-1 </ServerName> 〈DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria>
情況二、當(dāng)S-CSCF需要同時(shí)判斷觸發(fā)前和觸發(fā)后的R叫uest-URI來(lái) 識(shí)別是否是前轉(zhuǎn),即需要觸發(fā)前的原被叫滿(mǎn)足某個(gè)條件,同時(shí)需要觸發(fā)AS 后所改變的Request-URI也滿(mǎn)足某個(gè)條件時(shí),iFC中的SPT需要使用 〈SIPHeader〉配置History-Info頭域,因?yàn)镠istory-info頭域能夠正確的代表 改號(hào)前的原被叫的Request-URI 。
例3:設(shè)置觸發(fā)前的原被叫為制定的URI (例如以139前綴的號(hào)碼) 且觸發(fā)后的Request-URI為某類(lèi)特征號(hào)碼(以86755為前綴的號(hào)碼),則識(shí) 別為前轉(zhuǎn)/非前轉(zhuǎn),例如,同振業(yè)務(wù)中需要對(duì)以86755為前綴的號(hào)碼認(rèn)為非 前轉(zhuǎn),其它號(hào)碼認(rèn)為前轉(zhuǎn)。 <InitialFilterCriteria>
<Pri ority>0 </Priority >
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF> <SPT>
<ConditionNegated> 1 </ConditionNegated> <Group>0</Group>
<Request-URI>TEL:+86755(.*)</R^quest-URI> </SPT> <SPT>
<ConditionNegated> 1 </ConditionNegated>
<Group>0</Group>
<SIPHeader>
<Header>History-Info</Header><Content>TEL:+l 39(. *)</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer>
〈ServerName〉全網(wǎng)識(shí)別位置字符;CF=(K/ServerName> 〈DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria>
上述匹配條件可以只包含〈SIPHeader^而不包括REQUEST-URI,其原 理相同,再次不再贅述。
iFC中的SPT也可使用〈SIPHeader〉配置Diversion頭域,因?yàn)镈iversion 頭域也能夠代表改號(hào)前的原被叫的Request-URI。 <InitialFilterCriteria〉
<Priority>0</Priority> <TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF> <SPT>
<ConditionNegated> 1 </ConditionNegated> <Group>0</Group>
<Request-URI>TEL:+86755(.*)</Request-URI> </SPT> <SPT>
<ConditionNegated〉 1 </ConditionNegated>
<Group>0</Group>
<SIPHeader>
<Header>Diversion</Header>
<Content>TEL:+139(.*)</Content>
18</SIPHeader> </SPT> </TriggerPoint> <ApplicationServer>
〈ServerName〉全網(wǎng)識(shí)別位置字符;CF:0〈/ServerName〉 <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria>
情況三、當(dāng)S-CSCF需要判斷觸發(fā)前后的R叫uest-URI有差異性關(guān)系 時(shí),需要控制差異是否是前轉(zhuǎn)的判斷依據(jù),而差異是多種多樣的,通過(guò)靈 活配置History-Info頭域中的原內(nèi)容和新的內(nèi)容的差異正則表達(dá)式將差異 配置出來(lái),達(dá)到控制的效果,上述原內(nèi)容可以為原URI,新的內(nèi)容可以為 新的URI。
例4:設(shè)置觸發(fā)AS后原R叫uest-URI被改變?yōu)閿y帶了某些關(guān)鍵參數(shù)(例 如Phone-context或Trunk Group或cic或rn等)制定l直的Request-URI 時(shí),則識(shí)別為前轉(zhuǎn)。S-CSCF可通過(guò)如下配置的iFC進(jìn)行此類(lèi)識(shí)別。 <InitialFilterCriteria>
<Priority>0</Priority> <TriggerPoint〉
<ConditionTypeCNF>0</ConditionTypeCNF> <SPT>
<ConditionNegated〉 1 </ConditionNegated> <Group>0</Group>
〈R叫uest畫(huà)URI〉(條件)[cic二制定cic](.*)</Request-URI〉 </SPT> <SPT>
<ConditionNegated> 1 </ConditionNegated> <Group>0</Group><SIPHeader>
<Header>History-Info</Header> <Content>TEL: !條件!</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer>
〈ServerName〉全網(wǎng)識(shí)別位置字符;CF= 1 </ServerName> 〈DefaultHandling index="0">0</DefaultHandling> </Applications erver> </InitialFilterCriteria>
例5:觸發(fā)前的Request-URI為T(mén)EL形式,而觸發(fā)后的Request-URI 為此號(hào)碼的SIP:user=phone形式時(shí),則識(shí)別為非前轉(zhuǎn)。 <InitialFilterCriteria>
<Priority>0</Priority> <TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF> <SPT>
<ConditionNegated> 1 </ConditionNegated> <Group>0</ Group〉
<Request-URI>SIP:!條件! @(. * );user=phone</Request-URI> </SPT> <SPT>
<ConditionNegated> 1 </ConditionNegated>
<Group>0</Group>
<SIPHeader>
<Header〉History-Info</Header><Content>TEL: !條件!</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer>
〈ServerName〉全網(wǎng)識(shí)別位置字符;CF=0</ServerName> 〈DefaultHandling index="0">0</DefaultHandling> </Applications erver> </InitialFilterCriteria>
需要進(jìn)一步指出的是,上述三種情況所對(duì)應(yīng)的例1至例5所提出的各 種具體應(yīng)用場(chǎng)景中,通過(guò)前轉(zhuǎn)標(biāo)識(shí)CF的靈活調(diào)整,可以對(duì)符合匹配條件 的AS觸發(fā)返回的消息是否對(duì)應(yīng)前轉(zhuǎn)業(yè)務(wù)做出準(zhǔn)確識(shí)別,并且,上述各方 法可以單獨(dú)使用,也可以組合使用,從而可以實(shí)現(xiàn)對(duì)待識(shí)別消息的屬性的 準(zhǔn)確定義,從而靈活確定待識(shí)別消息的范圍。
本發(fā)明實(shí)施例的技術(shù)方案具有以下優(yōu)點(diǎn),因?yàn)椴捎昧烁鶕?jù)iFC所包含的 一個(gè)或多個(gè)SPT中的匹配條件及其對(duì)應(yīng)的擴(kuò)展參數(shù)進(jìn)行前轉(zhuǎn)業(yè)務(wù)識(shí)別的方 法,從而,可以準(zhǔn)確的進(jìn)行前轉(zhuǎn)業(yè)務(wù)的識(shí)別,達(dá)到了^t是高業(yè)務(wù)識(shí)別準(zhǔn)確率, 避免因誤識(shí)別而導(dǎo)致通信資源浪費(fèi)的效果。
再進(jìn)一步的,本發(fā)明實(shí)施例四還提出了一種原被叫信息的獲取方法,根 據(jù)消息中攜帶的History-Info信息,獲取該消息在AS觸發(fā)前所對(duì)應(yīng)消息的原 :帔叫信息,具體流程圖如圖4所示。
因?yàn)镠istory-Info是一個(gè)列表list,要準(zhǔn)確獲取到當(dāng)前S-CSCF所處理 的原被叫的信息,可以通過(guò)以下步驟實(shí)現(xiàn)
步驟S401 、 S-CSCF獲取當(dāng)前收到的AS觸發(fā)后的Invite消息中的最后 一條index 。
步驟S402、 S-CSCF根據(jù)該index信息,再獲取此index所在的父級(jí)
21index,該父級(jí)index所對(duì)應(yīng)的信息即為該消息在AS觸發(fā)前所對(duì)應(yīng)消息的原 被叫信息。
進(jìn)一步的,通過(guò)以下前轉(zhuǎn)場(chǎng)景進(jìn)行具體說(shuō)明,以下場(chǎng)景涵蓋了各種前 轉(zhuǎn)業(yè)務(wù)點(diǎn),即通過(guò)History-Info的獲取算法可正確獲取到當(dāng)前S-CSCF所處 理的原被叫信息。
場(chǎng)景一、如圖5所示,此場(chǎng)景中發(fā)生兩次前轉(zhuǎn),其中第一次為早前轉(zhuǎn) (即,無(wú)條件前轉(zhuǎn)),第二次為晚前轉(zhuǎn)(即,遇忙前轉(zhuǎn))。其中,<B;index=l> 是原被叫,C;index二l.l〉是B用戶(hù)所觸發(fā)的AS無(wú)條件前轉(zhuǎn)后的第一被叫, <0;11^6乂=1.2〉是觸發(fā)AS后遇忙前轉(zhuǎn)后的第二被叫。
其中,〈C;index^.l〉和〈D;index二1.2〉是同級(jí)index,而〈B;indexO是 <C;index=l 1〉禾口〈D;index二l.2>的父級(jí)index。
那么對(duì)于原被叫B所在的S-CSCF2來(lái)說(shuō),在第一次無(wú)條件前轉(zhuǎn)中,獲 取的原被叫的信息就是觸發(fā)AS后的消息的當(dāng)前History-Info中最后一跳 〈C;index二l.l〉的上一級(jí)index=l的URI,即〈B;indexO,而在第二次遇忙 前轉(zhuǎn)中,獲^F又的原-故叫的信息就是觸發(fā)AS后的消息的當(dāng)前History-Info中 最后一跳的〈D;index二1.2〉的上一級(jí)index=l的URI,即〈B;index-l〉。
場(chǎng)景二、如圖6所示,此場(chǎng)景中發(fā)生了兩次無(wú)條件前轉(zhuǎn),在第一次無(wú) 條件前轉(zhuǎn)中,〈B;indexO是原被叫,經(jīng)過(guò)B用戶(hù)的AS前轉(zhuǎn)到〈C;index-1.1〉 的第二原被叫,而在第二次無(wú)條件前轉(zhuǎn)中,〈C;index二l.l〉則成為了原被叫, 然后再經(jīng)過(guò)C用戶(hù)的前轉(zhuǎn)AS前轉(zhuǎn)到〈D;index^.l.l〉的當(dāng)前被叫。
其中,〈B;index^〉是〈C;index^l.l〉的父級(jí)index,而〈C;index^.l〉是 〈D;index二l.l.l〉的父纟及index。
那么S-CSCF2對(duì)應(yīng)的是第一次無(wú)條件前轉(zhuǎn),其獲取的原被叫則為其當(dāng) 前觸發(fā)AS后的History-Info中最后一跳〈C;index^.l〉的上一級(jí)index=l的 URI, W<B;index=l>;而S-CSCF3對(duì)應(yīng)的是第二次無(wú)條件前轉(zhuǎn),其獲取的 原被叫則為其當(dāng)前觸發(fā)后的History-Info中最后一跳〈D;index-l.l.l〉的上 一級(jí)index=l.l的URI,即〈C;index4.1〉。三次前轉(zhuǎn),包括兩次無(wú)條件前
轉(zhuǎn)和一次遇忙前轉(zhuǎn),在第一次無(wú)條件前轉(zhuǎn)中,〈B;index二l〉是原凈皮叫,經(jīng)過(guò) B用戶(hù)的AS無(wú)條件前轉(zhuǎn)到C后增加了〈C;index^.l〉的第二原被叫,由于 C用戶(hù)忙,于是B的AS進(jìn)行了第二次遇忙前轉(zhuǎn),前轉(zhuǎn)到〈D;index^l.2〉的 第三原被叫;D用戶(hù)的觸發(fā)AS將呼叫進(jìn)行第三次無(wú)條件前轉(zhuǎn),前轉(zhuǎn)到當(dāng) 前用戶(hù)E。
其中,〈B;index^〉是〈C;index^.l〉和〈D;index^.2〉的父級(jí)index,而 <D;index=l .2〉是〈E;index二l .2.1>的父級(jí)index。
那么對(duì)于S-CSCF2來(lái)說(shuō),第一次無(wú)條件前轉(zhuǎn)獲取的原被叫就為觸發(fā)后 當(dāng)前History-Info中最后一跳〈C;index^.l〉的上一級(jí)index=l的URI,即 <B;index=l>,第二次遇忙前轉(zhuǎn)獲取的原被叫就為觸發(fā)后當(dāng)前的History-Info 中最后一跳的〈D;index^.2〉的上一級(jí)index=l的URI,即〈B;index二l〉。
對(duì)于S-CSCF4來(lái)說(shuō),獲取的原被叫就為觸發(fā)后當(dāng)前的History-Info中 最后一跳的〈E;index^.2.1〉的上一級(jí)index=1.2的URI,即〈D;index^1.2〉。
通過(guò)應(yīng)用本發(fā)明實(shí)施例所提出的技術(shù)方案,S-CSCF能夠利用iFC中 對(duì)SPT的靈活運(yùn)用及擴(kuò)展參數(shù)"CF"的運(yùn)用,即可解決S-CSCF對(duì)各種場(chǎng) 景下AS改號(hào)后的前轉(zhuǎn)的有效識(shí)別,避免被叫觸發(fā)時(shí)候不影響路由的部分 發(fā)生變化,額外多進(jìn)行一次被叫路由過(guò)程,導(dǎo)致業(yè)務(wù)失敗。
通過(guò)以上的實(shí)施方式的描述,本領(lǐng)域的4支術(shù)人員可以清楚地了解到本 發(fā)明可以通過(guò)硬件實(shí)現(xiàn),也可以可借助軟件加必要的通用硬件平臺(tái)的方式 來(lái)實(shí)現(xiàn)基于這樣的理解,本發(fā)明的技術(shù)方案可以以軟件產(chǎn)品的形式體現(xiàn)出 來(lái),該軟件產(chǎn)品可以存儲(chǔ)在一個(gè)非易失性存儲(chǔ)介質(zhì)(可以是CD-ROM, U 盤(pán),移動(dòng)硬盤(pán)等)中,包括若干指令用以使得一臺(tái)計(jì)算機(jī)設(shè)備(可以是個(gè) 人計(jì)算機(jī),服務(wù)器,或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個(gè)實(shí)施例所述的方法。
本領(lǐng)域技術(shù)人員可以理解附圖只是一個(gè)優(yōu)選實(shí)施例的示意圖,附圖中的 模塊或流程并不一定是實(shí)施本發(fā)明所必須的。
23以上所述僅是本發(fā)明的優(yōu)選實(shí)施方式,應(yīng)當(dāng)指出,對(duì)于本技術(shù)領(lǐng)域的 普通技術(shù)人員來(lái)說(shuō),在不脫離本發(fā)明原理的前提下,還可以j故出若干改進(jìn) 和潤(rùn)飾,這些改進(jìn)和潤(rùn)飾也應(yīng)^見(jiàn)本發(fā)明的保護(hù)范圍。
權(quán)利要求
1、一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法,其特征在于,包括當(dāng)接收的消息中的請(qǐng)求資源標(biāo)識(shí)符Request-URI被改變時(shí),判斷所述消息是否符合初始過(guò)濾規(guī)則iFC所包含的一個(gè)或多個(gè)業(yè)務(wù)觸發(fā)點(diǎn)SPT中的匹配條件;當(dāng)所述消息符合所述iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件時(shí),根據(jù)所述iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù)。
2、 如權(quán)利要求l所述的方法,其特征在于,所述接收的消息為應(yīng)用服務(wù) 器AS觸發(fā)后返回的消息。
3、 如權(quán)利要求l所述的方法,其特征在于,所述前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)包括 服務(wù)器標(biāo)識(shí)和前轉(zhuǎn)標(biāo)識(shí)。
4、 如權(quán)利要求l所述的方法,其特征在于,所述iFC所包含的一個(gè)或多 個(gè)SPT中的匹配條件,具體通過(guò)精確值或正則表達(dá)式進(jìn)行設(shè)置。
5、 如權(quán)利要求4所述的方法,其特征在于,所述iFC所包含的一個(gè)或多 個(gè)SPT中的匹配條件,具體為在第一 SPT中的請(qǐng)求資源標(biāo)識(shí)符〈Request-URI〉字段設(shè)置的Request-URI 內(nèi)容;和/或,在第二 SPT中的會(huì)話(huà)發(fā)起協(xié)議頭〈SIPHeader〉字段設(shè)置的歷史信息 History-info頭域;和/或,在第三SPT中的〈SIPHeader〉字段設(shè)置的轉(zhuǎn)移Diversion頭域。
6、 如權(quán)利要求1或4或5任一項(xiàng)所述的方法,其特征在于,所述消息符 合所述iFC所包含的 一個(gè)或多個(gè)SPT中的匹配條件,具體包括當(dāng)所接收的AS觸發(fā)后返回的消息中的R叫uest-URI與所述在第一 SPT中 的〈Request-URI〉字段設(shè)置的Request-URI內(nèi)容相匹配時(shí),判斷所述消息符合 所述匹配條件;或,當(dāng)所接收的AS觸發(fā)后返回的消息中的R叫uest-URI與所述在第一 SPT中 的〈R叫uest-URI〉字段設(shè)置的Request-URI內(nèi)容相匹配,且所述消息在AS觸發(fā)前所對(duì)應(yīng)的消息和所述在第二 SPT中的〈SIPHeader^字段設(shè)置的 History-info頭域的信息相匹配時(shí),判斷所述消息符合所述匹配條件;或,當(dāng)所4妄收的AS觸發(fā)后返回的消息中的Request-URI和所述消息在AS觸 發(fā)前所對(duì)應(yīng)的消息之間的差異性關(guān)系與所述在第一 SPT中的〈Request-URI〉字 段設(shè)置的Request-URI內(nèi)容和所述在第二 SPT中的〈SIPHeader〉字段設(shè)置的 History-info頭域所對(duì)應(yīng)的差異性關(guān)系相匹配時(shí),判斷所述消息符合所述匹配 條件;或,當(dāng)所接收的AS觸發(fā)后返回的消息中的Request-URI與所述在第一 SPT中 的〈Request-URI〉字段設(shè)置的Request-URI內(nèi)容匹配,且與所述在第三SPT中 的〈SIPHeader〉字段設(shè)置的Diversion頭域中所設(shè)置的內(nèi)容相匹配時(shí),判斷所述 消息符合所述匹配條件。
7、 如權(quán)利要求3所述的方法,其特征在于,所述根據(jù)所述iFC包含的前 轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù),具體為判斷所述服務(wù)器標(biāo)識(shí)是否為全網(wǎng)識(shí)別位置字符;當(dāng)判斷結(jié)果為所述服務(wù)器標(biāo)識(shí)為全網(wǎng)識(shí)別位置字符時(shí),判斷所述前轉(zhuǎn)標(biāo) 識(shí)是否為前轉(zhuǎn)確認(rèn)字符;當(dāng)所述前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確iiv字符時(shí),識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)為前轉(zhuǎn) 業(yè)務(wù)。
8、 如權(quán)利要求l所述的方法,其特征在于,當(dāng)所述iFC為針對(duì)單一用戶(hù)的配置時(shí),所述iFC配置在所述單一用戶(hù)所 簽約的歸屬簽約用戶(hù)服務(wù)器HSS上;當(dāng)所述iFC為針對(duì)當(dāng)前網(wǎng)絡(luò)的全部用戶(hù)的配置時(shí),所述iFC配置在服務(wù)-呼叫會(huì)話(huà)控制功能實(shí)體S-CSCF上。
9、 如權(quán)利要求l所述的方法,其特征在于,還包括才艮據(jù)所述消息中攜帶 的History-Info信息,獲取所述消息在AS觸發(fā)前所對(duì)應(yīng)消息的原被叫信息的 方法,具體為獲取所接收的AS觸發(fā)后返回的消息中的最后一條索引index信息; 根據(jù)所述index信息,獲取所述index信息的父級(jí)index信息;確認(rèn)所述父級(jí)index信息所對(duì)應(yīng)的信息為所述消息在AS觸發(fā)前所對(duì)應(yīng)消 息的原;故叫信息。
10、 一種S-CSCF,其特4正在于,包括匹配判斷模塊,用于當(dāng)接收的消息中的Request-URI被改變時(shí),判斷所述 消息是否符合iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件;前轉(zhuǎn)識(shí)別模塊,用于當(dāng)所述匹配判斷模塊判斷所述消息符合所述iFC所 包含的一個(gè)或多個(gè)SPT中的匹配條件時(shí),根據(jù)所述iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別 標(biāo)識(shí)識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù)。
11、 如權(quán)利要求10所述的S-CSCF,其特征在于,所述匹配判斷模塊具 體用于應(yīng)用服務(wù)器AS觸發(fā)后返回的消息,當(dāng)接收的消息中的Request-URI被 改變時(shí),判斷所述消息是否符合iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件。
12、 如權(quán)利要求10所述的S-CSCF,其特征在于,所述前轉(zhuǎn)識(shí)別模塊具 體用于根據(jù)所述iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)包括的服務(wù)器標(biāo)識(shí)和前轉(zhuǎn)標(biāo)識(shí) 的類(lèi)型識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù)。
13、 如權(quán)利要求10所述的S-CSCF,其特征在于,所述匹配判斷模塊, 具體包括第一判斷子模塊,用于判斷所接收的AS觸發(fā)后返回的消息中的 Request-URI是否一皮改變;條件獲取子模塊,用于當(dāng)所述第一判斷子模塊判斷所接收的AS觸發(fā)后返 回的消息中的Request-URI被改變時(shí),在歸屬簽約用戶(hù)服務(wù)器HSS或本地獲 取所接收的AS觸發(fā)后返回的消息所對(duì)應(yīng)的iFC所包含的一個(gè)或多個(gè)SPT中 的匹配條4牛;第二判斷子模塊,用于判斷所接收的AS觸發(fā)后返回的消息是否符合所述 條件獲取子模塊所獲取的匹配條件。
14、 如權(quán)利要求12所述的S-CSCF,其特征在于,所述前轉(zhuǎn)識(shí)別模塊, 具體包括第三判斷子模塊,用于根據(jù)所述匹配條件,判斷所述服務(wù)器標(biāo)識(shí)是否為 全網(wǎng)識(shí)別位置字符;第四判斷子模塊,用于當(dāng)所述第三判斷子才莫塊判斷所述iFC包含的服務(wù) 器標(biāo)識(shí)為全網(wǎng)識(shí)別位置字符時(shí),判斷所述前轉(zhuǎn)標(biāo)識(shí)是否為前轉(zhuǎn)確認(rèn)字符,當(dāng) 所述前轉(zhuǎn)標(biāo)識(shí)為前轉(zhuǎn)確認(rèn)字符時(shí),識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)為前轉(zhuǎn)業(yè)務(wù)。
15、如權(quán)利要求IO所述的S-CSCF,其特征在于,還包括 信息獲取模塊,用于根據(jù)所接收的AS觸發(fā)后返回的消息中的最后一條索 引index信息的父級(jí)index信息,獲取所述消息在AS觸發(fā)前所對(duì)應(yīng)消息的原 一皮叫信息。
全文摘要
本發(fā)明實(shí)施例公開(kāi)了一種前轉(zhuǎn)業(yè)務(wù)的識(shí)別方法和設(shè)備,所述方法包括當(dāng)接收的消息中的請(qǐng)求資源標(biāo)識(shí)符Request-URI被改變時(shí),判斷所述消息是否符合初始過(guò)濾規(guī)則iFC所包含的一個(gè)或多個(gè)業(yè)務(wù)觸發(fā)點(diǎn)SPT中的匹配條件;當(dāng)所述消息符合所述iFC所包含的一個(gè)或多個(gè)SPT中的匹配條件時(shí),根據(jù)所述iFC包含的前轉(zhuǎn)業(yè)務(wù)識(shí)別標(biāo)識(shí)識(shí)別所述消息所對(duì)應(yīng)的業(yè)務(wù)是否為前轉(zhuǎn)業(yè)務(wù)。通過(guò)應(yīng)用本發(fā)明的技術(shù)方案,可以準(zhǔn)確而靈活的進(jìn)行前轉(zhuǎn)業(yè)務(wù)的識(shí)別,達(dá)到了提高業(yè)務(wù)識(shí)別準(zhǔn)確率,避免因誤識(shí)別而導(dǎo)致業(yè)務(wù)失敗和通信資源浪費(fèi)的效果。
文檔編號(hào)H04W4/16GK101448226SQ200810187970
公開(kāi)日2009年6月3日 申請(qǐng)日期2008年12月31日 優(yōu)先權(quán)日2008年12月31日
發(fā)明者王瞬迪, 娜 雷 申請(qǐng)人:華為技術(shù)有限公司