本發(fā)明涉及通信技術(shù)，尤其涉及一種呼叫處理方法及裝置。

背景技術(shù)：

在通信系統(tǒng)的演進(jìn)過程中，新舊系統(tǒng)的通信網(wǎng)絡(luò)往往需要共存一定時間，發(fā)展用戶是往往需要考慮到支持新系統(tǒng)的終端和號碼以及和舊系統(tǒng)的兼容性，因此同時支持兩張卡，多種模式的雙卡雙待終端也應(yīng)運而生。

對于使用雙卡雙待終端來說，每次發(fā)起呼叫時，都需要用戶根據(jù)各卡的當(dāng)前使用狀況來手動選擇使用哪一張卡進(jìn)行呼叫，操作繁瑣，效率低下，給用戶帶來不便。

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

本發(fā)明提供一種呼叫處理方法及裝置，用以解決現(xiàn)有技術(shù)中用戶每次發(fā)起呼叫時都需要手動選擇進(jìn)行本次呼叫的卡導(dǎo)致的呼叫效率低下的技術(shù)問題。

本發(fā)明提供一種呼叫處理方法，包括：

向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)；

接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息；

當(dāng)需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡。

進(jìn)一步地，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡，包括：

根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡；

若能夠確定語音套餐余量最多的卡，則以所述語音套餐余量最多的卡發(fā)起呼叫。

進(jìn)一步地，在向應(yīng)用服務(wù)器發(fā)送訂閱請求之前，還包括：

接收用戶輸入的余量預(yù)設(shè)閾值；

相應(yīng)地，所述訂閱請求中攜帶有所述余量預(yù)設(shè)閾值，以使所述業(yè)務(wù)運營支持系統(tǒng)在卡的語音套餐余量小于或等于所述余量預(yù)設(shè)閾值時發(fā)送所述業(yè)務(wù)狀態(tài)信息；

所述根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡，包括：

若多個卡中僅有一個未接收到業(yè)務(wù)狀態(tài)信息，則判斷所述未接收到業(yè)務(wù)狀態(tài)信息的卡為語音套餐余量最多的卡，反之則判斷不能確定語音套餐余量最多的卡。

進(jìn)一步地，所述方法還包括：

若不能確定語音套餐余量最多的卡，則獲取各卡的無線制式信息；

根據(jù)各卡的無線制式信息，確定發(fā)起呼叫的卡。

進(jìn)一步地，所述方法還包括：

若不能確定語音套餐余量最多的卡，則確定正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡，并以所述正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡作為發(fā)起呼叫的卡。

本發(fā)明還提供一種呼叫處理裝置，包括：

發(fā)送模塊，用于向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)；

接收模塊，用于接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息；

確定模塊，用于在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡。

進(jìn)一步地，所述確定模塊，包括：

判斷單元，用于在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡；

呼叫單元，用于在能夠確定語音套餐余量最多的卡時，以所述語音套餐余量最多的卡發(fā)起呼叫。

進(jìn)一步地，所述發(fā)送模塊還用于：在向應(yīng)用服務(wù)器發(fā)送訂閱請求之前，接收用戶輸入的余量預(yù)設(shè)閾值；

相應(yīng)地，所述訂閱請求中攜帶有所述余量預(yù)設(shè)閾值，以使所述業(yè)務(wù)運營支持系統(tǒng)在卡的語音套餐余量小于或等于所述余量預(yù)設(shè)閾值時發(fā)送所述業(yè)務(wù)狀態(tài)信息；

所述判斷單元具體用于：在需要發(fā)起呼叫時，若多個卡中僅有一個未接收到業(yè)務(wù)狀態(tài)信息，則判斷所述未接收到業(yè)務(wù)狀態(tài)信息的卡為語音套餐余量最多的卡，反之則判斷不能確定語音套餐余量最多的卡。

進(jìn)一步地，所述呼叫單元還用于：

若不能確定語音套餐余量最多的卡，則獲取各卡的無線制式信息；

根據(jù)各卡的無線制式信息，確定發(fā)起呼叫的卡。

進(jìn)一步地，所述呼叫單元還用于：

若不能確定語音套餐余量最多的卡，則確定正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡，并以所述正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡作為發(fā)起呼叫的卡。

本發(fā)明提供的呼叫處理方法及裝置，通過向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)，并接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息，在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡，無需用戶手動進(jìn)行選擇，簡化了呼叫操作，提高了呼叫效率，為用戶提供了便利。

附圖說明

圖1為本發(fā)明實施例一提供的呼叫處理方法的流程圖；

圖2為本發(fā)明實施例二提供的呼叫處理方法的流程圖；

圖3為本發(fā)明實施例三提供的呼叫處理方法的流程圖；

圖4為本發(fā)明實施例四提供的呼叫處理裝置的結(jié)構(gòu)框圖。

具體實施方式

為使本發(fā)明實施例的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護(hù)的范圍。

在本申請實施例中使用的術(shù)語是僅僅出于描述特定實施例的目的，而非旨在限制本發(fā)明。在本申請實施例和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。

應(yīng)當(dāng)理解，本文中使用的術(shù)語“和/或”僅僅是一種描述關(guān)聯(lián)對象的關(guān)聯(lián)關(guān)系，表示可以存在三種關(guān)系，例如，A和/或B，可以表示：單獨存在A，同時存在A和B，單獨存在B這三種情況。另外，本文中字符“/”，一般表示前后關(guān)聯(lián)對象是一種“或”的關(guān)系。

取決于語境，如在此所使用的詞語“如果”、“若”可以被解釋成為“在……時”或“當(dāng)……時”或“響應(yīng)于確定”或“響應(yīng)于檢測”。類似地，取決于語境，短語“如果確定”或“如果檢測(陳述的條件或事件)”可以被解釋成為“當(dāng)確定時”或“響應(yīng)于確定”或“當(dāng)檢測(陳述的條件或事件)時”或“響應(yīng)于檢測(陳述的條件或事件)”。

還需要說明的是，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的商品或者系統(tǒng)不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種商品或者系統(tǒng)所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的商品或者系統(tǒng)中還存在另外的相同要素。

實施例一

本發(fā)明實施例一提供一種呼叫處理方法。圖1為本發(fā)明實施例一提供的呼叫處理方法的流程圖。如圖1所示，本實施例中的呼叫處理方法，可以包括：

步驟101、向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)。

本實施例中方法的執(zhí)行主體可以為用戶設(shè)備，所述用戶設(shè)備可以為手機、平板設(shè)備等，所述用戶設(shè)備中設(shè)置有至少兩張卡，相應(yīng)的，所述用戶設(shè)備為多卡多待終端，例如，若用戶設(shè)備中設(shè)置有兩張卡，則所述用戶設(shè)備為雙卡雙待終端，若設(shè)置有三張卡，則所述用戶設(shè)備為三卡三待終端。

本實施例中，用戶設(shè)備的功能可以基于IP多媒體子系統(tǒng)(IP Multimedia Core Network Subsystem，IMS)來實現(xiàn)，IMS是由第三代合作伙伴計劃(3rd Generation Partnership Project，3GPP)提出的一種基于IP的網(wǎng)絡(luò)架構(gòu)，構(gòu)建了一個開放而靈活的業(yè)務(wù)環(huán)境，支持多媒體應(yīng)用，能夠為用戶提供豐富的多媒體業(yè)務(wù)。在IMS體系中，控制層和業(yè)務(wù)層是分離的，控制層不提供具體業(yè)務(wù)，只負(fù)責(zé)向業(yè)務(wù)層提供必要的觸發(fā)、路由和計費等控制功能?？刂茖拥目刂乒δ苁怯珊艚袝捒刂乒δ?Call Session Control Function，簡稱CSCF)完成的。CSCF分為代理呼叫會話控制功能(Proxy Call Session Control Function，P-CSCF)、查詢呼叫會話控制功能(Interrogating Call Session Control Function，I-CSCF)和服務(wù)呼叫會話控制功能(Serving Call Session Control Function，S-CSCF)三種類型。業(yè)務(wù)層由應(yīng)用服務(wù)器(Appl ication Server，AS)組成，能提供具體業(yè)務(wù)服務(wù)。S-CSCF根據(jù)用戶的簽約信息控制業(yè)務(wù)觸發(fā)，調(diào)用AS上的業(yè)務(wù)，實現(xiàn)業(yè)務(wù)功能。AS和S-CSCF可以統(tǒng)稱為服務(wù)設(shè)備(Server Equipment，簡稱SE)。會話中的端到端設(shè)備稱為用戶設(shè)備(User Equipment，UE)，負(fù)責(zé)與使用者的交互。在IMS中各功能實體之間使用SIP(初始會話協(xié)議)進(jìn)行通訊。SIP協(xié)議的靈活擴展性保證了終端能夠基于IP添加新的功能。

SIP協(xié)議中的訂閱流程：

所謂事件通告機制是指網(wǎng)絡(luò)中的一些實體可以訂閱網(wǎng)絡(luò)中某些資源或呼叫的狀態(tài)信息，當(dāng)那些被訂閱的資源的狀態(tài)發(fā)生改變時，負(fù)責(zé)這一資源的網(wǎng)絡(luò)實體將向訂閱者發(fā)送通告，通報當(dāng)前資源狀態(tài)的變化情況。在規(guī)范中定義了兩個擴展方法：訂閱(SUBSCRIBE)和通告(NOTIFY)。SUBSCRIBE方法用于發(fā)起訂閱請求，NOTIFY方法用于通告當(dāng)前資源狀態(tài)。會話啟動協(xié)議事件通告機制涉及以下幾個部分：

(1)訂閱者

訂閱者負(fù)責(zé)接收NOTIFY消息的會話啟動協(xié)議用戶代理(SIP UA)。這些NOTIFY消息中包含訂閱者訂閱的資源信息。訂閱者典型的動作是向通告者發(fā)送SUBSCRIBE消息以請求創(chuàng)建一次訂閱關(guān)系。

(2)通告者

通告者負(fù)責(zé)產(chǎn)生NOTIFY請求的SIP UA。通告者在NOTIFY消息中向訂閱者回饋當(dāng)前資源的狀態(tài)。通告者典型的動作是接收SUBSCRIBE消息并創(chuàng)建相應(yīng)的訂閱關(guān)系。

(3)訂閱

所謂訂閱就是一組與某個對話相關(guān)聯(lián)的應(yīng)用狀態(tài)的集合。訂閱關(guān)系既存在于訂閱者中，又存在于通告者中。

(4)事件包

事件包是通告者向訂閱者發(fā)送的一組資源的狀態(tài)信息。RFC 3265中給出了抽象的事件包模板定義，對應(yīng)具體業(yè)務(wù)可定義相應(yīng)的事件包類型，例如：在席事件包、對話事件包等，這些事件包可使用不同的語法并具有各自的語義。這種框架賦予會話啟動協(xié)議事件通告機制極大的生命力和靈活性，有助于快速提供新的業(yè)務(wù)。

SUBSCRIBE方法和會話啟動協(xié)議基本規(guī)范中定義的邀請(INVITE)方法都可以創(chuàng)建一個對話。當(dāng)訂閱者想得到網(wǎng)絡(luò)中某一資源的狀態(tài)時，便向負(fù)責(zé)這一資源的會話啟動協(xié)議實體發(fā)起SUBSCRIBE請求。SUBSCRIBE消息中的請求統(tǒng)一資源標(biāo)識符(Request-URI)就是所要請求的資源的統(tǒng)一資源標(biāo)識符(URI)，這一URI同時還為會話啟動協(xié)議代理服務(wù)器路由請求提供線索。SUBSCRIBE請求中必須包含一個擴展的Event頭部，其中注明要訂閱的事件類型，即事件包標(biāo)記，如，dialog(用于代答業(yè)務(wù))、refer(用于呼叫轉(zhuǎn)交)等。還可包含擴展的Allowed-Event頭部，指示本節(jié)點能夠支持的事件包類型。

對于訂閱者來說，它總是在一定的時間段內(nèi)對它感興趣的某一資源進(jìn)行觀察，因此，SUBSCRIBE消息中應(yīng)包含expires頭部，這一頭部值表明訂閱者期望的有效訂閱時長。為了延長某一訂閱的時間，訂閱者可以在有效期內(nèi)再次發(fā)送SUBSCRIBE消息來刷新這一訂閱。具體某次訂閱的有效時長，最終是由對SUBSCRIBE請求的2XX響應(yīng)中的expires頭部值或NOTIFY消息中的Subscription-State頭部的expires參數(shù)決定的。expires頭部值等于0的SUBSCRIBE請求表示撤消訂閱。如果訂閱關(guān)系能夠建立，SUBSCRIBE消息將會觸發(fā)通告資源狀態(tài)的NOTIFY消息立即回送。訂閱者想要獲得的資源狀態(tài)信息封裝在后繼通告消息NOTIFY的消息體中，為了能夠正確地解釋這部分信息，訂閱者應(yīng)該向通告者指明自己支持的消息體格式，因此，在SUBSCRIBE消息中應(yīng)攜帶Accept頭部，比如：Accept:application/dialog-info+xml，這表明訂閱者支持用可擴展標(biāo)識語言(XML)描述的對話事件包，實際上就是一種通用Internet郵件擴展(MIME)格式消息體。如果SUBSCRIBE消息中沒有攜帶Accept頭部，則通告者根據(jù)SUBSCRIBE消息中Event頭部指明的事件包標(biāo)記選擇默認(rèn)的格式傳送資源狀態(tài)信息。

SUBSCRIBE請求通過2XX響應(yīng)確認(rèn)。不同的2XX響應(yīng)具有不同的語義：

(1)200OK表示訂閱已被接受且用戶已被授權(quán)訂閱請求的資源。

(2)202Accepted(接受)是事件通知機制擴展的響應(yīng)碼，表示訂閱請求已被理解，但是否授權(quán)給訂閱者未確定。

2XX響應(yīng)中必須包含expires頭部，這個值指明通告者確定的此次訂閱的有效時長，且必須滿足：expires 200OK<＝expires SUBSCRIBE，即禁止通告者延長訂閱時長。如果返回非2XX響應(yīng)，則表示訂閱失敗，將沒有后繼的NOTIFY消息。

通告者收到SUBSCRIBE請求時，首先判定是否理解消息中的Event頭部，如果不理解，則通告者返回擴展的“489Bad Event”(錯誤事件)響應(yīng)。通告者還會檢查消息中的expires頭部，如果其值滿足：(0<expires SUBSCRIBE<1hour)&&(0<expires SUBSCRIBE<Min通告者-config)，其中，Min通告者-config為通告者最小配置訂閱時長，則通告者向訂閱者返回“423Interval too small”(時間間隔太短)響應(yīng)，表示提出的訂閱時長太短。此外，通告者還應(yīng)根據(jù)本地策略對提出SUBSCRIBE請求的用戶進(jìn)行鑒權(quán)。

與訂閱相關(guān)的信息由NOTIFY消息傳送。通告者在成功創(chuàng)建訂閱關(guān)系后，必須立即發(fā)送NOTIFY消息，向訂閱者通告當(dāng)前訂閱資源的狀態(tài)，。通告者使用SUBSCRIBE消息中Accept頭部明確允許的或者Event頭部隱含指明的消息體格式將資源的狀態(tài)信息或指向該資源狀態(tài)的URI封裝在消息中。消息也可包含擴展的Al lowed-Events頭部，指示本節(jié)點能夠支持的事件包類型。NOTIFY消息中必須包含擴展的Subscription-State頭部，指示創(chuàng)建的訂閱的狀態(tài)。共有3種訂閱狀態(tài)，分別是：

(1)active：訂閱已被接受且授權(quán)成功。

(2)pending：SUBSCRIBE請求已收到，但還沒有足夠的信息決定接受或拒絕此次訂閱。

(3)terminated：訂閱未激活，或創(chuàng)建的訂閱關(guān)系終止。

對應(yīng)active狀態(tài)或peding狀態(tài)，該頭部還帶有expires參數(shù)指示此次訂閱的有效時長。對應(yīng)terminated狀態(tài)，該頭部應(yīng)包含reason參數(shù)指示訂閱被終止的原因，或者包含Retry-After參數(shù)，指示訂閱者過一段時間后重新發(fā)起訂閱請求。

訂閱者收到通告者NOTIFY請求后，將進(jìn)行匹配檢查。如果找到相應(yīng)的匹配，且NOTIFY消息中的Subscription-State頭部指示的訂閱狀態(tài)是active或pending，訂閱者創(chuàng)建新的訂閱或?qū)υ挘OTIFY請求回送200OK響應(yīng)。如果匹配失敗，則發(fā)送“481Subscription does not exist”(訂閱不存在)響應(yīng)。

在訂閱有效期內(nèi)，如果資源狀態(tài)發(fā)生變化，則通告者使用NOTIFY請求及時將變化信息通告訂閱者。

擴展的SUBSCRIBE方法和基本的INVITE方法都可以創(chuàng)建對話。在某一對話中，SUBSCRIBE請求將創(chuàng)建和該對話關(guān)聯(lián)的訂閱，而該對話有可能是由INVITE建立起來的。因此，如果訂閱終止，且當(dāng)前無其他應(yīng)用狀態(tài)(如由INVITE請求建立起來的應(yīng)用狀態(tài))和該對話關(guān)聯(lián)，則該對話結(jié)束。如果仍有訂閱和該對話關(guān)聯(lián)，雖然其他的應(yīng)用狀態(tài)已結(jié)束，但該對話并沒有結(jié)束。換句話說，由INVITE創(chuàng)建的對話并不會因為收到或發(fā)送了再見請求而結(jié)束，因為仍有訂閱關(guān)系和此對話相關(guān)聯(lián)。與此類似，當(dāng)多個訂閱和同一對話關(guān)聯(lián)時，必須當(dāng)與此對話相關(guān)聯(lián)的所有訂閱都結(jié)束時，該對話才結(jié)束。這一概念非常類似于程序設(shè)計里對文件描述符的引用，其中文件描述符相當(dāng)于對話，對文件描述符引用的進(jìn)程相當(dāng)于建立的訂閱關(guān)系。

SUBSCRIBE請求可以觸發(fā)通告者對其資源狀態(tài)的立即回送，因此，訂閱者可以利用這一特性實現(xiàn)對資源狀態(tài)的輪詢。當(dāng)訂閱處于激活狀態(tài)時，訂閱者在SUBSCRIBE請求的expires頭部寫入當(dāng)前剩下的訂閱有效時長的秒數(shù)，這樣，能夠立即觸發(fā)通告者產(chǎn)生NOTIFY消息，將當(dāng)前資源的狀態(tài)通告給訂閱者。需要指出的是，這種對資源的輪詢會導(dǎo)致網(wǎng)絡(luò)、通告者和訂閱者負(fù)荷的增加。在如移動通信這樣的特定應(yīng)用中，訂閱者一般是數(shù)據(jù)處理能力較慢、需要額外供電的移動終端設(shè)備，隨著事件通告頻度的增加和通告事件包的增大，將消耗很多寶貴的帶寬資源，造成網(wǎng)絡(luò)擁塞和訂閱者的過載。因此，訂閱者需要對通告者的狀態(tài)通告頻率作出限制。另外，訂閱者還可以在SUBSCRIBE消息中指定一些事件包的過濾規(guī)則，使得通告者能夠根據(jù)這一過濾規(guī)則產(chǎn)生通告事件，而不是任何狀態(tài)發(fā)生變化時都發(fā)起通告。

一般說來，訂閱者使用SUBSCRIBE請求建立一次訂閱，稱為顯式訂閱創(chuàng)建，與此相對應(yīng)的還有一種隱式的訂閱創(chuàng)建，即訂閱者不是通過SUBSCRIBE請求來創(chuàng)建訂閱。而是通過轉(zhuǎn)交(REFER)方法，一種由RFC3515定義的用于實現(xiàn)呼叫轉(zhuǎn)交等業(yè)務(wù)的方法。REFER請求隱式地在被轉(zhuǎn)交用戶處創(chuàng)建訂閱，所要觀察的資源是轉(zhuǎn)交請求的狀態(tài)。

業(yè)務(wù)運營支持(Business&Operation Support System，BOSS)系統(tǒng)，面對客戶是統(tǒng)一的；面對業(yè)務(wù)運營商，它融合了業(yè)務(wù)支撐系統(tǒng)(BSS)與運營支撐系統(tǒng)(OSS)，是一個綜合的業(yè)務(wù)運營和管理支撐平臺，同時也是真正融合業(yè)務(wù)(不同的運營商有不同業(yè)務(wù)的融合，如傳統(tǒng)網(wǎng)絡(luò)接入業(yè)務(wù)、IP數(shù)據(jù)業(yè)務(wù)、內(nèi)容提供業(yè)務(wù)與移動增值業(yè)務(wù)等)的綜合管理平臺。

針對不同的運營商(如固定網(wǎng)絡(luò)經(jīng)營者，移動網(wǎng)絡(luò)經(jīng)營者，IP網(wǎng)絡(luò)經(jīng)營者，數(shù)據(jù)網(wǎng)絡(luò)經(jīng)營者等)，以及不同的服務(wù)對象，BOSS系統(tǒng)通常有以下幾類主要業(yè)務(wù)及其功能。

面向多種業(yè)務(wù)的功能：多種業(yè)務(wù)有固定話音及數(shù)據(jù)、無線話音及數(shù)據(jù)、無線數(shù)據(jù)等，功能主要有工單調(diào)度、資源管理等融合的營業(yè)系統(tǒng)、多業(yè)務(wù)融合的計費系統(tǒng)與賬務(wù)系統(tǒng)、統(tǒng)一的客戶服務(wù)系統(tǒng)、統(tǒng)一的客戶關(guān)系管理(CRM)系統(tǒng)、業(yè)務(wù)開通與保障、業(yè)務(wù)開發(fā)與決策、SLA(服務(wù)水平協(xié)議)/QoS(服務(wù)質(zhì)量保證)管理以及應(yīng)用集成等。面向一般消費者及大眾化IP業(yè)務(wù)的功能主要有：營業(yè)系統(tǒng)、賬務(wù)系統(tǒng)、計費系統(tǒng)、客戶服務(wù)、客戶分析、業(yè)務(wù)開發(fā)與規(guī)劃、業(yè)務(wù)激活、業(yè)務(wù)保障和應(yīng)用集成等。面向企業(yè)和個人用戶的數(shù)據(jù)業(yè)務(wù)的功能：針對個人用戶特別是大客戶的企業(yè)用戶所需的個性化服務(wù)，其流程復(fù)雜，多樣化，主要功能有：營業(yè)系統(tǒng)、工單調(diào)度、資源管理、計費系統(tǒng)、賬務(wù)系統(tǒng)、客戶服務(wù)系統(tǒng)、CRM系統(tǒng)、業(yè)務(wù)開通與保障、業(yè)務(wù)開發(fā)與決策、SLA/QoS管理以及應(yīng)用集成等。

本實施例中，所述用戶設(shè)備開機后，各卡均開始進(jìn)行IMS初始注冊，完成鑒權(quán)及注冊流程后，各卡可以分別向應(yīng)用服務(wù)器發(fā)送訂閱請求。具體地，可以通過IMS中的P-CSCF和S-CSCF向AS發(fā)送所述訂閱請求。

所述AS收到所述訂閱請求后，可以通過網(wǎng)關(guān)向BOSS系統(tǒng)發(fā)送查詢請求，以訂閱卡的業(yè)務(wù)狀態(tài)。所述卡的業(yè)務(wù)狀態(tài)可以包括但不限于：卡的套餐狀況、卡的歸屬地、卡的資費、卡是否處于漫游狀態(tài)等等。

步驟102、接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息。

具體地，所述BOSS系統(tǒng)可以將業(yè)務(wù)狀態(tài)信息發(fā)送給應(yīng)用服務(wù)器，再由所述應(yīng)用服務(wù)器將所述業(yè)務(wù)狀態(tài)信息發(fā)送給用戶設(shè)備。

步驟103、當(dāng)需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡。

為了便于詳細(xì)說明，本實施例中以所述業(yè)務(wù)狀態(tài)用于表征卡所訂閱的套餐中的語音套餐余量的多少為例來進(jìn)行描述。

一般在用戶設(shè)備初始IMS注冊結(jié)束后，用戶設(shè)備會發(fā)起訂閱流程，此時訂閱的事件(Event)，一般為registration state event package(注冊狀態(tài)事件包)，是為重注冊、重鑒權(quán)等功能做準(zhǔn)備的。

為了能夠使用SIP協(xié)議中的訂閱機制來訂閱當(dāng)前卡的業(yè)務(wù)狀態(tài)，可以引入一個新的event：voice plan usage(語音計劃命令)，作為所述訂閱信息。具體地，可以定義Event：voice plan usage的語義為，查詢當(dāng)前BOSS系統(tǒng)中該卡的語音套餐余量是否小于余量預(yù)設(shè)閾值，即，所述業(yè)務(wù)狀態(tài)信息用于表示卡的語音套餐余量是否小于余量預(yù)設(shè)閾值。若卡內(nèi)的語音套餐余量大于余量預(yù)設(shè)閾值，則不需要通知用戶設(shè)備，若卡內(nèi)的語音套餐余量小于余量預(yù)設(shè)閾值，則可以通過Notify(通知)消息通知用戶設(shè)備。

所述語音套餐余量是指卡的套餐中的剩余語音通話時間，例如，卡1的套餐包括100分鐘免費語音通話，本月已使用60分鐘，則卡1的語音套餐余量為40分鐘，卡2的套餐包括200分鐘免費語音通話，本月已使用180分鐘，則卡2的語音套餐余量為20分鐘。

所述余量預(yù)設(shè)閾值可以根據(jù)實際需要來設(shè)置，例如可以為30分鐘，或者，所述余量預(yù)設(shè)閾值可以由用戶手動輸入，滿足用戶的個性化需求。相應(yīng)地，所述訂閱請求中可以攜帶有所述余量預(yù)設(shè)閾值，以使所述BOSS系統(tǒng)在卡的語音套餐余量小于或等于所述余量預(yù)設(shè)閾值時發(fā)送所述業(yè)務(wù)狀態(tài)信息。

BOSS系統(tǒng)在接收到AS發(fā)送的查詢請求后，可以設(shè)置卡的語音套餐余量不足余量預(yù)設(shè)閾值時，通過AS向用戶設(shè)備發(fā)送相關(guān)的業(yè)務(wù)狀態(tài)信息。若此時卡仍處于IMS注冊狀態(tài)，AS會將BOSS系統(tǒng)的業(yè)務(wù)狀態(tài)信息以Notify消息的格式發(fā)送給用戶設(shè)備；若此時該卡不處于IMS注冊狀態(tài)，AS上查不到該卡的信息，則等到下一次該卡進(jìn)行IMS注冊后再推送該業(yè)務(wù)狀態(tài)信息。

這樣，通過引入新的Event，就可以實現(xiàn)AS向BOSS系統(tǒng)發(fā)送訂閱請求，BOSS系統(tǒng)返回相應(yīng)的業(yè)務(wù)狀態(tài)信息。

相應(yīng)的，步驟103中的根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡，可以包括：

根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡；若能夠確定語音套餐余量最多的卡，則以所述語音套餐余量最多的卡發(fā)起呼叫。

具體地，若多個卡中僅有一個未接收到業(yè)務(wù)狀態(tài)信息，則判斷所述未接收到業(yè)務(wù)狀態(tài)信息的卡為語音套餐余量最多的卡，反之則判斷不能確定語音套餐余量最多的卡。

例如，用戶設(shè)備中有三張卡，其中卡1和卡2都收到了業(yè)務(wù)狀態(tài)信息，說明卡1和卡2中的語音套餐余量都不足余量預(yù)設(shè)閾值了，而卡3沒有收到，說明卡3的語音套餐余量大于余量預(yù)設(shè)閾值，因此可以判定卡3為語音套餐余量最多的卡，當(dāng)需要發(fā)起呼叫時，可以用卡3進(jìn)行呼叫。

若不能確定語音套餐余量最多的卡，則可以使用默認(rèn)的卡來進(jìn)行呼叫，或者，使用其他規(guī)則判斷由哪張卡發(fā)起呼叫，例如使用剩余話費較多的卡來發(fā)起呼叫。

除了語音套餐余量的多少以外，業(yè)務(wù)狀態(tài)信息還可以用于表示卡的其它狀態(tài)信息，相應(yīng)的，在步驟103中發(fā)起呼叫時，可以根據(jù)其它狀態(tài)信息的預(yù)設(shè)規(guī)則選擇由哪張卡進(jìn)行呼叫。

例如，所述業(yè)務(wù)狀態(tài)信息可以用于表示卡是否處于漫游狀態(tài)，需要發(fā)起呼叫時，可以優(yōu)先使用不處于漫游狀態(tài)的卡進(jìn)行呼叫?；蛘?，所述業(yè)務(wù)狀態(tài)信息用于表示卡的歸屬地，用戶設(shè)備可以根據(jù)各卡的歸屬地和用戶當(dāng)前所在地理位置來確定由哪張卡發(fā)起呼叫，若用戶當(dāng)前所在地理位置屬于某卡的歸屬地，則優(yōu)先使用該卡發(fā)起呼叫?；蛘?，所述業(yè)務(wù)狀態(tài)信息可以用于表示卡的資費，在發(fā)起呼叫時，可以使用資費較多的卡進(jìn)行呼叫。

在實際應(yīng)用中，通過與AS和BOSS系統(tǒng)的交互，用戶設(shè)備能夠獲得各卡的業(yè)務(wù)狀態(tài)信息，在需要發(fā)起呼叫時，用戶設(shè)備可以根據(jù)各卡的業(yè)務(wù)狀態(tài)信息，自動選擇相應(yīng)的卡進(jìn)行呼叫。

本實施例提供的呼叫處理方法，通過向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)，并接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息，在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡，無需用戶手動進(jìn)行選擇，簡化了呼叫操作，提高了呼叫效率，為用戶提供了便利。

實施例二

本發(fā)明實施例二提供一種呼叫處理方法。本實施例是在前述實施例提供的技術(shù)方案的基礎(chǔ)上，在不能確定語音套餐余量最多的卡時，通過各卡的無線制式信息確定由哪張卡發(fā)起呼叫。

圖2為本發(fā)明實施例二提供的呼叫處理方法的流程圖。如圖2所示，本實施例中的方法，可以包括：

步驟201、向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)。

步驟202、接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息。

步驟203、當(dāng)需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡。

步驟201至步驟203的具體實現(xiàn)原理可以參照實施例一，此處不再贅述。

步驟204、若不能確定語音套餐余量最多的卡，則獲取各卡的無線制式信息。

步驟205、根據(jù)各卡的無線制式信息，確定發(fā)起呼叫的卡。

本實施例中，若能夠確定語音套餐余量最多的卡，則以所述語音套餐余量最多的卡發(fā)起呼叫。若不能，則可以根據(jù)各卡的無線制式信息，確定由哪張卡進(jìn)行呼叫。

具體地，用戶設(shè)備可以先獲取各卡的無線制式信息，所述無線制式信息用于表示卡所處的小區(qū)的狀態(tài)，例如：VoLTE小區(qū)、不支持VoLTE的LTE小區(qū)(只能使用CSFB發(fā)起呼叫)、3G小區(qū)、2G小區(qū)等等。

由于用戶設(shè)備中的多張卡可能處于不同的無線技術(shù)下，因此發(fā)起語音呼叫的語音質(zhì)量、呼叫時延都有差異。一般來說，VoLTE制式下語音質(zhì)量最好，接入時延最短，不支持VoLTE的LTE環(huán)境下一般使用CSFB發(fā)起呼叫，CSFB的接入時延較長，因此直接選擇2G/3G發(fā)起呼叫會比CSFB更快。

因此，在發(fā)起呼叫時，可以優(yōu)先使用處于VoLTE小區(qū)的卡進(jìn)行呼叫，其次是處于2G/3G小區(qū)的卡，最后是只能使用CSFB的卡。

若用戶設(shè)備中的多張卡的無線制式信息均相同，即各卡都處在相同的無線制式下，則可以選取默認(rèn)的卡發(fā)起呼叫，或者使用任意一張卡發(fā)起呼叫，或者使用其他規(guī)則確定由哪張卡發(fā)起呼叫。

本實施例提供的呼叫處理方法，在不能確定語音套餐余量最多的卡時，可以通過獲取各卡的無線制式信息，并根據(jù)各卡的無線制式信息，確定發(fā)起呼叫的卡，能使用戶設(shè)備自動使用當(dāng)前最適宜通話的卡進(jìn)行呼叫，進(jìn)一步為用戶提供了便利。

實施例三

本發(fā)明實施例三提供一種呼叫處理方法。本實施例是在前述實施例提供的技術(shù)方案的基礎(chǔ)上，在不能確定語音套餐余量最多的卡時，通過數(shù)據(jù)業(yè)務(wù)確定由哪張卡發(fā)起呼叫。

圖3為本發(fā)明實施例三提供的呼叫處理方法的流程圖。如圖3所示，本實施例中的方法，可以包括：

步驟301、向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)。

步驟302、接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息。

步驟303、當(dāng)需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡。

步驟301至步驟303的具體實現(xiàn)原理可以參照實施例一，此處不再贅述。

步驟304、若不能確定語音套餐余量最多的卡，則確定正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡，并以所述正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡作為發(fā)起呼叫的卡。

本實施例中，若能夠確定語音套餐余量最多的卡，則以所述語音套餐余量最多的卡發(fā)起呼叫。若不能，則可以以所述正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡作為發(fā)起呼叫的卡。具體地，可以通過建立的DRB(Data RB，終端與基站之間的數(shù)據(jù)承載)來判斷哪張卡正在進(jìn)行數(shù)據(jù)業(yè)務(wù)。

本實施例可以優(yōu)選地用于雙卡雙待單通終端，因為單通終端同時只能使用一張卡進(jìn)行業(yè)務(wù)，如果卡1正在進(jìn)行數(shù)據(jù)業(yè)務(wù)，再使用卡2發(fā)起呼叫的話，卡1所在進(jìn)行的數(shù)據(jù)業(yè)務(wù)就會中斷，直到卡2的通話結(jié)束后才能重新接續(xù)數(shù)據(jù)業(yè)務(wù)。因此，本實施例中設(shè)置為數(shù)據(jù)業(yè)務(wù)優(yōu)先，即哪一張卡正在進(jìn)行數(shù)據(jù)業(yè)務(wù)，就使用哪一張卡發(fā)起呼叫，而一張卡同時使用數(shù)據(jù)業(yè)務(wù)和語音業(yè)務(wù)是不會受影響的，可以并發(fā)進(jìn)行，提高效率。

本實施例提供的呼叫處理方法，在不能確定語音套餐余量最多的卡時，可以通過確定正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡，并以所述正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡作為發(fā)起呼叫的卡，使得用戶正在使用的數(shù)據(jù)不受影響，進(jìn)一步提高用戶體驗度。

上述實施例二和實施例三中的方法還可以組合使用，即可以首先根據(jù)語音通話余量選擇由哪張卡發(fā)起呼叫，在無法確定語音通話余量最多的卡時，可以根據(jù)無線制式來選擇由哪張卡發(fā)起呼叫，在各卡的無線制式相同或者無法獲取卡的無線制式的情況下，可以選擇正在使用數(shù)據(jù)業(yè)務(wù)的卡發(fā)起呼叫。或者，可以首先根據(jù)語音通話余量選擇由哪張卡發(fā)起呼叫，在無法確定語音通話余量最多的卡時，可以選擇正在使用數(shù)據(jù)業(yè)務(wù)的卡發(fā)起呼叫，若沒有正在使用數(shù)據(jù)業(yè)務(wù)的卡，則可以根據(jù)各卡的無線制式來選擇由哪張卡發(fā)起呼叫。

實施例四

本發(fā)明實施例四提供一種呼叫處理裝置。圖4為本發(fā)明實施例四提供的呼叫處理裝置的結(jié)構(gòu)框圖。如圖4所述，本實施例中的呼叫處理裝置，可以包括：

發(fā)送模塊401，用于向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)；

接收模塊402，用于接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息；

確定模塊403，用于在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡。

本實施例提供的呼叫處理裝置，可以用于執(zhí)行實施例一所述的呼叫處理方法，其具體實現(xiàn)原理與實施例一類似，此處不再贅述。

本實施例提供的呼叫處理裝置，通過向應(yīng)用服務(wù)器發(fā)送訂閱請求，以使所述應(yīng)用服務(wù)器根據(jù)所述訂閱請求向業(yè)務(wù)運營支持系統(tǒng)發(fā)送查詢請求，從而訂閱各卡的業(yè)務(wù)狀態(tài)，并接收所述業(yè)務(wù)運營支持系統(tǒng)根據(jù)所述查詢請求通過所述應(yīng)用服務(wù)器返回的至少一個卡的業(yè)務(wù)狀態(tài)信息，在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，確定發(fā)起呼叫的卡，無需用戶手動進(jìn)行選擇，簡化了呼叫操作，提高了呼叫效率，為用戶提供了便利。

進(jìn)一步地，所述確定模塊403，可以包括：

判斷單元，用于在需要發(fā)起呼叫時，根據(jù)所述至少一個卡的業(yè)務(wù)狀態(tài)信息，判斷是否能夠確定語音套餐余量最多的卡；

呼叫單元，用于在能夠確定語音套餐余量最多的卡時，以所述語音套餐余量最多的卡發(fā)起呼叫。

進(jìn)一步地，所述發(fā)送模塊401還用于：在向應(yīng)用服務(wù)器發(fā)送訂閱請求之前，接收用戶輸入的余量預(yù)設(shè)閾值；

相應(yīng)地，所述訂閱請求中攜帶有所述余量預(yù)設(shè)閾值，以使所述業(yè)務(wù)運營支持系統(tǒng)在卡的語音套餐余量小于或等于所述余量預(yù)設(shè)閾值時發(fā)送所述業(yè)務(wù)狀態(tài)信息；

所述判斷單元具體用于：在需要發(fā)起呼叫時，若多個卡中僅有一個未接收到業(yè)務(wù)狀態(tài)信息，則判斷所述未接收到業(yè)務(wù)狀態(tài)信息的卡為語音套餐余量最多的卡，反之則判斷不能確定語音套餐余量最多的卡。

進(jìn)一步地，所述呼叫單元還用于：若不能確定語音套餐余量最多的卡，則獲取各卡的無線制式信息；根據(jù)各卡的無線制式信息，確定發(fā)起呼叫的卡。

進(jìn)一步地，所述呼叫單元還用于：若不能確定語音套餐余量最多的卡，則確定正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡，并以所述正在進(jìn)行數(shù)據(jù)業(yè)務(wù)的卡作為發(fā)起呼叫的卡。

最后應(yīng)說明的是：以上各實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述各實施例對本發(fā)明進(jìn)行了詳細(xì)的說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解：其依然可以對前述各實施例所記載的技術(shù)方案進(jìn)行修改，或者對其中部分或者全部技術(shù)特征進(jìn)行等同替換；而這些修改或者替換，并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的范圍。