專利名稱：在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法及系統(tǒng)。
背景技術(shù)：
在SIP(Session Initiation Protocol，即會話發(fā)起協(xié)議)中，提供了一種訂閱/通知(SUBSCRIBE/NOTIFY)的機(jī)制，訂閱者可以向被訂閱者(通知者)發(fā)送SIP SUBSCRIBE消息(會話發(fā)起協(xié)議訂閱消息)，消息中攜帶表示訂閱信息的事件包(event package)，被訂閱者向訂閱者發(fā)送SIP NOTIFY消息(會話發(fā)起協(xié)議通知消息)，消息中攜帶被訂閱的內(nèi)容。目前，按照SIP協(xié)議的定義，表示訂閱信息的事件包由Event header(事件頭域)負(fù)責(zé)傳遞，而Event頭域只能通過SIP SUBSCRIBE消息、SIPNOTIFY消息以及一種SIP PUBLISH消息(會話發(fā)起協(xié)議發(fā)布消息)攜帶。
SIP協(xié)議的訂閱/通知機(jī)制向用戶提供了一種非常靈活的業(yè)務(wù)申請的方法，用戶在自己終端上可以申請訂閱各種各樣的業(yè)務(wù)，比如某個好朋友的在線狀態(tài)、天氣預(yù)報、對某個惡意騷擾電話的追查等待。
但是如前所述，用戶的訂閱只能通過SIP SUBSCRIBE消息來實現(xiàn)，這類申請訂閱的業(yè)務(wù)是和呼叫無關(guān)的，不需要和某個具體呼叫相關(guān)聯(lián)。而我們又知道，某些申請訂閱的業(yè)務(wù)是和呼叫相關(guān)的，即該業(yè)務(wù)的申請訂閱只在某個呼叫中有效。用戶發(fā)起某個呼叫，希望在這個呼叫中應(yīng)用某種業(yè)務(wù)，則可以臨時申請訂閱該業(yè)務(wù)應(yīng)用于該特定呼叫中，比如，用戶發(fā)起一次呼叫，希望臨時申請“計費(fèi)通知(Advice of Charge)”業(yè)務(wù)，使網(wǎng)絡(luò)可以通知他/她這次呼叫所發(fā)生的費(fèi)用；再如，用戶發(fā)起一次呼叫，希望臨時申請“主叫號碼顯示限制”業(yè)務(wù)，使這次呼叫建立過程中網(wǎng)絡(luò)不將他/她的號碼顯示給被叫用戶。
顯然，用戶發(fā)起呼叫，終端將發(fā)送SIP INVITE消息(會話發(fā)起協(xié)議邀請消息)，而傳遞用戶訂閱信息的事件包的Event頭域只能在SIPSUBSCRIBE消息中傳遞，因此目前SIP協(xié)議的訂閱機(jī)制無法實現(xiàn)用戶“臨時”申請訂閱業(yè)務(wù)作用在某個特定呼叫上的需求。
當(dāng)前，為了解決這個問題，一般的方法是在SIP INVITE消息中采用一個獨(dú)立的頭域(header)來指示上述的在呼叫發(fā)起時申請的業(yè)務(wù)信息，比如在ETSI(European Telecommunications Standards Institute，歐洲電信標(biāo)準(zhǔn)協(xié)會)的TISPAN(Telecommunications and Internet ConvergedServices and Protocols for Advanced Networking)系列標(biāo)準(zhǔn)中，采用一個P-AOC頭域來指示呼叫發(fā)起時對“計費(fèi)通知”業(yè)務(wù)的申請，采用一個Privacy頭域來指示呼叫發(fā)起時對“主叫號碼顯示限制”業(yè)務(wù)的申請。
但是，我們也知道，用戶在呼叫發(fā)起時“臨時”申請訂閱的此類業(yè)務(wù)是會有很多種的，具體數(shù)目是由用戶需求決定的，當(dāng)前是無法預(yù)知的，如果這類業(yè)務(wù)實現(xiàn)時都采用一個獨(dú)立頭域的方式，缺乏統(tǒng)一的機(jī)制，將會使SIP協(xié)議變得不可控，不具有可預(yù)見性。再如，已經(jīng)激活了呼叫等待業(yè)務(wù)的用戶發(fā)起一次呼叫時，希望申請“臨時撤消呼叫等待”業(yè)務(wù)，使這次呼叫建立的通話不受新呼入來話的影響。
特別是，某些業(yè)務(wù)既可在呼叫發(fā)起時申請，也可以不在呼叫發(fā)起時申請，比如前述的“計費(fèi)通知”業(yè)務(wù)，用戶在呼叫發(fā)起時沒有申請該業(yè)務(wù)，而是在通話中想查詢一下已經(jīng)發(fā)生了多少費(fèi)用，則用戶在通話中申請訂閱“計費(fèi)通知”業(yè)務(wù)，顯然，這時的訂閱仍然是利用SIP SUBSCRIBE消息攜帶事件包來完成的。
這樣，同一個業(yè)務(wù)的申請在不同應(yīng)用場景下將會分別通過一個獨(dú)立頭域、一個訂閱事件包來實現(xiàn)，造成實現(xiàn)流程不統(tǒng)一以及帶來的資源浪費(fèi)。
此外，在SIP INVITE消息中通過一個獨(dú)立頭域來指示對業(yè)務(wù)的申請，很難向用戶反饋業(yè)務(wù)應(yīng)用成功還是失敗的信息，因為SIP INVITE消息的目的是為了建立呼叫進(jìn)行通話，它的SIP會話建立過程都是為這個目的服務(wù)的，沒有更多的考慮這類和呼叫相關(guān)的業(yè)務(wù)的應(yīng)用狀況，顯然即使業(yè)務(wù)應(yīng)用失敗，也不能因此而拒絕此次呼叫的建立。比如前述的“主叫號碼顯示限制”業(yè)務(wù)，網(wǎng)絡(luò)對這個業(yè)務(wù)應(yīng)用成功還是失敗，按目前的標(biāo)準(zhǔn)流程，申請業(yè)務(wù)的主叫用戶都不得而知。
從上述分析可以看出，在用戶發(fā)起呼叫時，現(xiàn)有技術(shù)通過SIPINVITE消息攜帶一個獨(dú)立頭域來指示在呼叫發(fā)起時申請的業(yè)務(wù)信息主要有如下三個缺點1、用戶在呼叫發(fā)起時“臨時”申請訂閱的業(yè)務(wù)是會有很多種的，具體數(shù)目是由用戶需求決定的，當(dāng)前是無法預(yù)知的，采用一個獨(dú)立頭域的實現(xiàn)方式缺乏統(tǒng)一的機(jī)制，將會使SIP協(xié)議變得不可控，不具有可預(yù)見性。
2、對某些既可在呼叫發(fā)起時申請，也可以不在呼叫發(fā)起時申請的業(yè)務(wù)，同一個業(yè)務(wù)的申請在不同應(yīng)用場景下將會分別通過一個獨(dú)立頭域、一個訂閱事件包來實現(xiàn)，造成實現(xiàn)流程不統(tǒng)一以及帶來的資源浪費(fèi)。
3、用戶在呼叫發(fā)起時申請業(yè)務(wù)后，很難知道該業(yè)務(wù)的應(yīng)用成功還是失敗的信息，業(yè)務(wù)應(yīng)用結(jié)果對用戶不透明，用戶體驗性不好。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是克服現(xiàn)有技術(shù)通過SIP INVITE消息攜帶一個獨(dú)立頭域來指示在呼叫發(fā)起時申請的業(yè)務(wù)信息，會使SIP協(xié)議變得不可控、實現(xiàn)流程不統(tǒng)一以及帶來資源浪費(fèi)的缺點，提供一種在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法及系統(tǒng)，仍沿用SIP協(xié)議的現(xiàn)有機(jī)制，保持SIP協(xié)議現(xiàn)有機(jī)制的完整性，并使業(yè)務(wù)應(yīng)用結(jié)果向用戶透明，增加用戶的業(yè)務(wù)體驗性。
本發(fā)明為解決上述技術(shù)問題所采用的技術(shù)方案為這種在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，包括以下步驟在以會話發(fā)起協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中，用戶終端或網(wǎng)絡(luò)在其發(fā)起的非訂閱消息的會話發(fā)起協(xié)議會話消息中，通過一個頭域攜帶一個或一個以上、表示與當(dāng)前所述會話發(fā)起協(xié)議會話相關(guān)業(yè)務(wù)被訂閱信息的事件包；所述業(yè)務(wù)的業(yè)務(wù)控制節(jié)點接收所述事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理。
所述頭域可以為事件頭域，并使事件頭域能由訂閱消息和通知消息之外的其它會話發(fā)起協(xié)議消息攜帶。所述頭域為事件頭域時，并使其可以傳遞多個所述事件包。
所述頭域可以為新擴(kuò)展的一個會話發(fā)起協(xié)議頭域，使其能由訂閱消息和通知消息之外的其它會話發(fā)起協(xié)議消息攜帶。所述頭域為新擴(kuò)展的一個會話發(fā)起協(xié)議頭域時，使其可以傳遞多個所述事件包。
所述非訂閱消息的會話發(fā)起協(xié)議會話消息可以為呼叫消息，包括會話發(fā)起協(xié)議邀請消息或會話發(fā)起協(xié)議即時消息。
用戶終端發(fā)起攜帶所述事件包的所述呼叫消息，所述業(yè)務(wù)控制節(jié)點接收到所述的事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理，若允許用戶終端對所述業(yè)務(wù)的訂閱申請，則在條件滿足時，發(fā)送包含所述業(yè)務(wù)應(yīng)用相關(guān)信息的通知消息。
所述通知消息可以為會話發(fā)起協(xié)議通知消息、或會話發(fā)起協(xié)議發(fā)布消息、或會話發(fā)起協(xié)議響應(yīng)碼消息。
所述業(yè)務(wù)在呼叫建立后申請訂閱，該申請訂閱可由會話發(fā)起協(xié)議訂閱消息中通過事件頭域攜帶所述事件包來完成，所述業(yè)務(wù)的業(yè)務(wù)控制節(jié)點接收到所述的事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理。
用戶終端發(fā)起未攜帶所述事件包的所述呼叫消息，網(wǎng)絡(luò)中第一網(wǎng)元在收到該呼叫消息后，根據(jù)業(yè)務(wù)的預(yù)置信息和當(dāng)前會話情況，在該呼叫消息中插入所述事件包，發(fā)送至業(yè)務(wù)控制節(jié)點；或者，用戶終端發(fā)起攜帶所述事件包的所述呼叫消息，經(jīng)過網(wǎng)絡(luò)中第二網(wǎng)元發(fā)送至業(yè)務(wù)控制節(jié)點。
所述第一網(wǎng)元或第二網(wǎng)元收到包含所述業(yè)務(wù)應(yīng)用相關(guān)信息的通知消息，如果該通知消息是會話發(fā)起協(xié)議通知消息，則將該通知消息轉(zhuǎn)換成會話發(fā)起協(xié)議發(fā)布消息或會話發(fā)起協(xié)議響應(yīng)碼消息，向用戶終端發(fā)送；如果該通知消息是會話發(fā)起協(xié)議發(fā)布消息，則將該消息向用戶終端轉(zhuǎn)發(fā)，或轉(zhuǎn)換成會話發(fā)起協(xié)議響應(yīng)碼消息向用戶終端發(fā)送。
對業(yè)務(wù)控制節(jié)點接受訂閱的所述事件包，所述第一網(wǎng)元或第二網(wǎng)元為其創(chuàng)建訂閱實例。
用戶終端發(fā)起攜帶所述事件包的所述呼叫消息，在收到所述通知消息后，為該通知消息中攜帶的事件包創(chuàng)建訂閱實例。
所述會話發(fā)起協(xié)議響應(yīng)碼消息中攜帶的事件包通過新擴(kuò)展的會話發(fā)起協(xié)議頭域或事件頭域傳遞。
所述用戶終端、或第一網(wǎng)元、或第二網(wǎng)元發(fā)起攜帶所述事件包的所述呼叫消息，為所述事件包對應(yīng)的訂閱和所述呼叫創(chuàng)建一個對話，或分別創(chuàng)建不同的對話。
若所述訂閱和所述呼叫被分別創(chuàng)建不同的對話，則在所述頭域中攜帶所述訂閱對應(yīng)的對話參數(shù)。
用戶終端發(fā)起攜帶所述事件包的所述呼叫消息中指示用戶終端是否為所述事件包創(chuàng)建訂閱實例。
所述呼叫消息中通過支持頭域的內(nèi)容來指示用戶終端是否為所述事件包創(chuàng)建訂閱實例。
相應(yīng)的一種在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，以會話發(fā)起協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中包括訂閱者，用于在其發(fā)出的非訂閱消息的會話發(fā)起協(xié)議會話消息中通過攜帶一個或一個以上、表示與當(dāng)前所述呼叫相關(guān)業(yè)務(wù)被訂閱信息的事件包；通知者，用于接收所述事件包，向所述訂閱者發(fā)送攜帶所述業(yè)務(wù)應(yīng)用信息的通知消息。
本發(fā)明的有益效果為本發(fā)明在SIP協(xié)議給出一種和當(dāng)前SIP訂閱/通知機(jī)制保持一致的、在呼叫發(fā)起時對業(yè)務(wù)的申請訂閱方法，可以通過呼叫消息攜帶表示被訂閱業(yè)務(wù)信息的事件包。在用戶終端發(fā)起的呼叫消息中通過一個固定的頭域傳遞表示被訂閱業(yè)務(wù)信息的事件包，對一種被訂閱業(yè)務(wù)只需要定義一個事件包，而不需要擴(kuò)展不同的獨(dú)立頭域，仍沿用SIP協(xié)議的現(xiàn)有機(jī)制，保持了SIP協(xié)議現(xiàn)有機(jī)制的完整性。
同時，該事件包同樣可以在SIP SUBSCRIBE消息中通過Event頭域傳遞，即對那些既可在呼叫發(fā)起時申請，也可以不在呼叫發(fā)起時申請的業(yè)務(wù)，定義同一個事件包就能在不同應(yīng)用場景下使用，業(yè)務(wù)申請訂閱成功后的流程基本一致。
同時，對用戶終端在呼叫發(fā)起時申請訂閱的業(yè)務(wù)，業(yè)務(wù)控制節(jié)點可以通過SIP NOTIFY/PUBLISH消息以及可以攜帶事件包的SIP響應(yīng)碼，向用戶終端通知業(yè)務(wù)應(yīng)用成功還是失敗的信息，業(yè)務(wù)應(yīng)用結(jié)果向用戶透明，用戶的業(yè)務(wù)體驗性良好。
綜上所述，本發(fā)明具有更廣泛的適用性和通用性，使業(yè)務(wù)的實現(xiàn)變得更加簡潔，并使業(yè)務(wù)應(yīng)用結(jié)果向用戶透明，增加用戶的業(yè)務(wù)體驗性。


圖1為本發(fā)明在呼叫發(fā)起時進(jìn)行計費(fèi)通知業(yè)務(wù)訂閱的一種實現(xiàn)流程示意圖；圖2為本發(fā)明在通話中進(jìn)行計費(fèi)通知業(yè)務(wù)訂閱的實現(xiàn)流程示意圖；圖3為本發(fā)明在呼叫發(fā)起時進(jìn)行計費(fèi)通知業(yè)務(wù)訂閱的另一種實現(xiàn)流程示意圖；圖4為本發(fā)明事件發(fā)布代理不在業(yè)務(wù)控制節(jié)點時，在呼叫發(fā)起時進(jìn)行計費(fèi)通知業(yè)務(wù)訂閱的實現(xiàn)流程示意圖。
具體實施例方式
下面根據(jù)附圖和實施例對本發(fā)明作進(jìn)一步詳細(xì)說明現(xiàn)有技術(shù)通過一個獨(dú)立頭域來指示在呼叫發(fā)起時對業(yè)務(wù)的申請方法是不可取的，基于此，本發(fā)明將在SIP協(xié)議給出一種和當(dāng)前SIP訂閱/通知機(jī)制保持一致的、在呼叫發(fā)起時對業(yè)務(wù)的申請訂閱方法，通過SIPINVITE消息攜帶表示被訂閱業(yè)務(wù)信息的事件包。
從前面分析可以看出，本發(fā)明要解決的問題就是在呼叫發(fā)起時對業(yè)務(wù)的申請訂閱方法，仍然沿用當(dāng)前SIP訂閱/通知機(jī)制，仍通過事件包來表示被訂閱業(yè)務(wù)的信息。要達(dá)到這個目的，如前所述，要么使Event頭域也可以通過SIP INVITE消息攜帶；要么新擴(kuò)展一個頭域使其也可以傳遞表示被訂閱業(yè)務(wù)信息的事件包，該頭域通過SIP INVITE消息攜帶。
對前一種方法，需要改變目前SIP協(xié)議的定義，在IETF(Internetengineering task force，因特網(wǎng)工程任務(wù)組)RFC3265中，有如下定義Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT-----------------------------------------------------------------Event R - - - - - - - m m需要將其修改為
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT-----------------------------------------------------------------Event R - - - o - - - m m即表示Event頭域?qū)UBSCRIBE和NOTIFY消息是必選的(mandatory)，對INVITE消息是可選的(optional)。
對后一種方法，本發(fā)明新擴(kuò)展一個能由SUBSCRIBE消息、NOTIFY消息以及PUBLISH消息之外的其它SIP消息攜帶的、傳遞表示被訂閱業(yè)務(wù)信息的事件包的頭域，比如命名為P-SUB，參照SIP協(xié)議中Event頭域的定義格式，P-SUB的定義格式如下P-SUB ＝(″P-SUB″)HCOLON(sub-event*(COMMAsub-event))sub-event ＝event-type*(SEMI event-param)event-type＝event-package*(″.″event-template)event-package ＝token-nodotevent-template＝token-nodottoken-nodot ＝1*(alphanum/″-″/″！″/″％″/″*″/″-″/″+″/″`″/″′″/″~″)event-param ＝generic-param/(″id″EQUAL token)其中，sub-event表示P-SUB頭域中傳遞的表示被訂閱業(yè)務(wù)信息的事件包，它包含了事件包類型event-type和參數(shù)event-param，而event-type和event-param的定義和Event頭域中的完全相同，本發(fā)明不再詳細(xì)解釋。
可以看出，和Event頭域定義不一樣的地方是，P-SUB頭域中可以傳遞多個表示被訂閱業(yè)務(wù)信息的事件包，而Event頭域中只能傳遞一個事件包。這是因為，用戶在呼叫發(fā)起時，可能會申請對多個業(yè)務(wù)的訂閱，比如同時申請“計費(fèi)通知”和“主叫號碼顯示限制”。當(dāng)然，為了實現(xiàn)這個需求，也可以修改Event頭域的定義格式，使其也能傳遞多個事件包。
下面通過一個具體的實施例來說明，用戶如何在呼叫發(fā)起時申請對“計費(fèi)通知”業(yè)務(wù)的訂閱，以及在通話中申請對“計費(fèi)通知”業(yè)務(wù)的訂閱，并展示如何在SIP INVITE消息和SIP SUBSCRIBE消息中傳遞表示“計費(fèi)通知”業(yè)務(wù)訂閱信息的事件包，以達(dá)到不需要擴(kuò)展一個獨(dú)立的頭域(P-AOC)、一個業(yè)務(wù)的訂閱只有一個相應(yīng)事件包的目的。
在本實施例中，假設(shè)被申請訂閱的業(yè)務(wù)由業(yè)務(wù)控制節(jié)點這樣一個邏輯網(wǎng)元來提供業(yè)務(wù)邏輯控制和執(zhí)行環(huán)境，它可以存在于某個網(wǎng)絡(luò)實體(如應(yīng)用服務(wù)器)中，甚至也可以存在于用戶終端之中。需要說明的是，本發(fā)明中所作的流程圖示和文字說明僅為突出本發(fā)明的關(guān)鍵技術(shù)所作的解釋，并不表示一個完整的呼叫和業(yè)務(wù)控制流程，也沒有窮盡所有可能的分支流程。
如圖1所示，用戶在呼叫發(fā)起時申請對“計費(fèi)通知”業(yè)務(wù)的訂閱流程具體說明如下1)SIP終端用戶A呼叫用戶B，在呼叫發(fā)起時申請(本次通話)使用計費(fèi)通知業(yè)務(wù)，在終端發(fā)出的SIP INVITE消息中有如下內(nèi)容INVITE sipmary@tele.com SIP/2.0P-SUBaoc-message其中，P-SUB頭域即用來傳遞表示“計費(fèi)通知”業(yè)務(wù)訂閱信息的事件包aoc-message，需要說明的是，計費(fèi)通知業(yè)務(wù)事件包aoc-message是本發(fā)明的一個擴(kuò)展，P-SUB頭域和下述的Event頭域中事件類型(event-type)的取值“aoc-message”是該事件包名稱(event packagename)。如前所述，擴(kuò)展Event頭域的使用范圍，此時也可以在SIP INVITE消息中傳遞Event頭域INVITE sipmary@tele.com SIP/2.0Eventaoc-message為符合SIP協(xié)議的訂閱/通知機(jī)制，SIP終端A作為訂閱者(subscriber)需要為事件包aoc-message創(chuàng)建一個事務(wù)(transaction)。
2)業(yè)務(wù)控制節(jié)點接收SIP INVITE消息，向被叫方向發(fā)送。
3)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機(jī)應(yīng)答，發(fā)送200OK響應(yīng)碼。
4)業(yè)務(wù)控制節(jié)點接收到200OK響應(yīng)碼，向主叫方向發(fā)送。此時被叫已經(jīng)應(yīng)答，業(yè)務(wù)控制節(jié)點根據(jù)此前從SIP INVITE消息里P-SUB頭域中解析出的aoc-message事件包，判斷如果用戶A有申請使用計費(fèi)通知業(yè)務(wù)的權(quán)限，則該業(yè)務(wù)申請成功，作為通知者(notifier)創(chuàng)建該事件包的訂閱實例(subscription)，并在200OK響應(yīng)碼中通過P-SUB頭域或Event頭域攜帶訂閱成功被接受的事件包P-SUBaoc-message此時，在該200 OK響應(yīng)碼中就已經(jīng)可以通過攜帶本次通話的計費(fèi)通知信息，一般可以通過響應(yīng)碼的消息體攜帶。
5)用戶A的SIP終端接收到200 OK響應(yīng)碼，返回ACK確認(rèn)消息。SIP終端A從200 OK響應(yīng)碼中解析出aoc-message事件包，和已經(jīng)創(chuàng)建事務(wù)的事件包匹配，創(chuàng)建該事件包的訂閱實例。
若該響應(yīng)碼中已經(jīng)攜帶了本次通話的計費(fèi)通知信息，則用戶A的SIP終端還可以提取出計費(fèi)通知信息。
6)業(yè)務(wù)控制節(jié)點將ACK確認(rèn)消息向用戶B的SIP終端發(fā)送，用戶A和用戶B間的會話建立，雙方開始通話。
7)業(yè)務(wù)控制節(jié)點計算本次通話的費(fèi)率，也可能提前計算出本次通話的費(fèi)用，通過SIP NOTIFY消息的消息體攜帶計費(fèi)通知信息發(fā)送給用戶A的SIP終端，在SIP NOTIFY消息中必須指明相應(yīng)的事件包Eventaoc-message8)用戶A的SIP終端接收到SIP NOTIFY消息，從消息體中提取出本次通話的費(fèi)率或費(fèi)用，返回200 OK響應(yīng)碼。
9)SIP終端B用戶掛機(jī)釋放呼叫，發(fā)送SIP BYE消息。
10)業(yè)務(wù)控制節(jié)點接收到SIP BYE消息，向主叫方向發(fā)送。
11)SIP終端A接收到SIP BYE消息，釋放呼叫，返回200 OK響應(yīng)碼。
12)業(yè)務(wù)控制節(jié)點接收到200 OK響應(yīng)碼，向被叫方向發(fā)送。
13)業(yè)務(wù)控制節(jié)點判斷該呼叫的相關(guān)信息將被完全釋放，用戶訂閱的計費(fèi)通知業(yè)務(wù)也隨之結(jié)束，則計算已經(jīng)發(fā)生的通話費(fèi)用，通過SIPNOTIFY消息的消息體攜帶計費(fèi)通知信息發(fā)送給用戶A的SIP終端，在SIP NOTIFY消息中必須指明相應(yīng)的事件包，并通過Subscription-State頭域取值為“terminated”指明業(yè)務(wù)應(yīng)用結(jié)束，釋放訂閱實例Eventaoc-messageSubscription-Stateterminated在Subscription-State頭域中還可以通過reason參數(shù)來設(shè)置業(yè)務(wù)應(yīng)用結(jié)束的原因?？梢钥吹?，本實施例中，計費(fèi)通知業(yè)務(wù)的有效期開始于通話建立時，結(jié)束于通話釋放時，業(yè)務(wù)訂閱實例的釋放由業(yè)務(wù)控制節(jié)點決定。
14)用戶A的SIP終端接收到SIP NOTIFY消息，從消息體中提取出本次通話的費(fèi)用，釋放訂閱實例，返回200 OK響應(yīng)碼。
可以看到，在實施例流程圖1中，用戶終端和業(yè)務(wù)控制節(jié)點之間是通過在針對INVITE消息的SIP響應(yīng)碼(實施例中為200 OK響應(yīng)碼，還可以是183 Session Progress等響應(yīng)碼)中攜帶的事件包來指示哪些事件包已經(jīng)被業(yè)務(wù)控制節(jié)點接受訂閱，用戶終端只為SIP響應(yīng)碼中攜帶的事件包創(chuàng)建訂閱實例。實際上，按照這個約定，在實施例流程圖1的步驟1中，用戶終端為事件包創(chuàng)建事務(wù)也可以不是必須的，即，在步驟5中，用戶終端既使不將SIP響應(yīng)碼中攜帶的事件包和已經(jīng)創(chuàng)建事務(wù)的事件包相匹配，也可以就根據(jù)SIP響應(yīng)碼中攜帶的事件包來創(chuàng)建相應(yīng)的訂閱實例。
顯然，這里用戶終端是根據(jù)業(yè)務(wù)控制節(jié)點返回的、已經(jīng)同意訂閱的事件包，來創(chuàng)建該事件包的訂閱實例，這樣，既使SIP響應(yīng)碼中不通過擴(kuò)展來攜帶事件包(此時如果需要的話，SIP響應(yīng)碼也仍然可以攜帶業(yè)務(wù)應(yīng)用信息，如圖1的步驟4中攜帶計費(fèi)通知信息)，用戶終端還可以直接根據(jù)業(yè)務(wù)控制節(jié)點發(fā)送的第一個的、表示訂閱請求已被接受的NOTIFY消息(如實施例流程圖1中步驟7發(fā)送的NOTIFY消息)中攜帶的事件包，來創(chuàng)建該事件包的訂閱實例。即業(yè)務(wù)控制節(jié)點返回的事件包(通過SIP響應(yīng)碼或NOTIFY消息)，將表明該事件包已經(jīng)被業(yè)務(wù)控制節(jié)點同意訂閱并創(chuàng)建了相應(yīng)的訂閱實例，因此用戶終端可以根據(jù)業(yè)務(wù)控制節(jié)點返回的事件包來創(chuàng)建相應(yīng)的訂閱實例。
此外，需要說明的是，由于呼叫發(fā)起時對業(yè)務(wù)的申請訂閱依附于SIPINVITE消息，而SIP INVITE消息作為一個會話消息必須要創(chuàng)建一個dialog(對話)，因此用戶終端上創(chuàng)建的訂閱實例也只能依附于該dialog，即呼叫和訂閱將共用一個dialog。
這里需要進(jìn)一步說明的是，由于dialog是端到端建立的，而訂閱實例只存在于SIP終端A和業(yè)務(wù)控制節(jié)點之間，因此業(yè)務(wù)控制節(jié)點將作為B2BUA(Back to Back User Agent，背靠背用戶代理)位于SIP INVITE消息建立的呼叫信令路徑中，即實施例流程圖1的步驟1中，SIP終端A和業(yè)務(wù)控制節(jié)點建立了一個dialog，步驟2中，業(yè)務(wù)控制節(jié)點和業(yè)務(wù)控制節(jié)點建立了另一個dialog，所述訂閱實例使用的是SIP終端A和業(yè)務(wù)控制節(jié)點之間建立的dialog。
此外，在上述實施例中，訂閱和呼叫共用了一個dialog，如果訂閱和呼叫不共用一個dialog，即訂閱單獨(dú)建立一個dialog，此時則需要SIP終端A在步驟1發(fā)送SIP INVITE消息中，單獨(dú)指明訂閱的dialog，如擴(kuò)展P-SUB頭域，以攜帶創(chuàng)建dialog所必須的Call-ID參數(shù)和From-tag參數(shù)，消息示例如下INVITE sipmary@tele.com SIP/2.0
Fromsipalice@tele.com；tag＝889defP-SUBaoc-message；Call-ID＝5678@example.com；From-tag＝123aa9Call-ID1234@example.com其中，F(xiàn)rom頭域中的“889def”和Call-ID頭域中的“1234@example.com”將用來創(chuàng)建呼叫的dialog，而P-SUB頭域中的“123aa9”和“5678@example.com”將用來創(chuàng)建訂閱的dialog。
而業(yè)務(wù)控制節(jié)點則可以在步驟4，通過返回的P-SUB頭域攜帶To-tag參數(shù)，消息示例如下SIP/2.0200OKFromsipalice@tele.com；tag＝889defTosipmary@tele.com；tag＝xyzqqqP-SUBaoc-message；Call-ID＝5678@example.com；From-tag＝123aa9；To-tag＝abcmmnCall-ID1234@example.com其中，To頭域中的“xyzqqq”屬于呼叫的dialog，P-SUB頭域中的“abcmmn”屬于訂閱的dialog。Call-ID、From-tag、To-tag都是屬于dialog的參數(shù)，可以看到，訂閱和呼叫的dialog分別不同，訂閱的dialog通過新擴(kuò)展的頭域攜帶，當(dāng)然也可以通過其它方式攜帶。
此時，雖然訂閱dialog的路由集重用SIP終端A到業(yè)務(wù)控制節(jié)點間呼叫建立的路由集，即相同的信令路徑，但訂閱和呼叫卻分別建立了兩個dialog，該方法同樣適用于后面的實施例。
另外，由于每個事件包都有自己的訂閱實例，因此當(dāng)INVITE消息中攜帶一個以上的事件包時，若這些事件包不共用呼叫的dialog，則需要為每個事件包對應(yīng)的訂閱實例創(chuàng)建一個dialog，即對上述的P-SUB頭域來說，每個事件包都要有其對應(yīng)的dialog參數(shù)。
如圖2所示，在通話中申請對“計費(fèi)通知”業(yè)務(wù)的訂閱流程具體說明如下1)SIP終端用戶A呼叫用戶B，發(fā)出SIP INVITE消息。
2)業(yè)務(wù)控制節(jié)點接收SIP INVITE消息，向被叫方向發(fā)送。
3)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機(jī)應(yīng)答，發(fā)送200 OK響應(yīng)碼。
4)業(yè)務(wù)控制節(jié)點接收到200 OK響應(yīng)碼，向主叫方向發(fā)送。
5)用戶A的SIP終端接收到200 OK響應(yīng)碼，返回ACK確認(rèn)消息。
6)業(yè)務(wù)控制節(jié)點將ACK確認(rèn)消息向用戶B的SIP終端發(fā)送，用戶A和用戶B間的會話建立，雙方開始通話。
7)用戶A在和用戶B通話，經(jīng)過一段時間后，希望申請使用計費(fèi)通知業(yè)務(wù)，看看當(dāng)前已經(jīng)產(chǎn)生了多少話費(fèi)，則用戶A在SIP終端上發(fā)起對計費(fèi)通知業(yè)務(wù)的訂閱申請，發(fā)出SIP SUBSCRIBE消息，消息中有如下內(nèi)容Eventaoc-messageSIP終端A作為訂閱者為事件包aoc-message創(chuàng)建事務(wù)。
8)業(yè)務(wù)控制節(jié)點接收SIP SUBSCRIBE消息，從Event頭域中解析aoc-message事件包，如果用戶A有申請使用計費(fèi)通知業(yè)務(wù)的權(quán)限，則該業(yè)務(wù)申請成功，業(yè)務(wù)控制節(jié)點作為通知者創(chuàng)建訂閱實例，返回200 OK響應(yīng)碼。
SIP終端A接收到同意訂閱的200 OK響應(yīng)碼，為事件包aoc-message創(chuàng)建訂閱實例。
9)業(yè)務(wù)控制節(jié)點計算當(dāng)前通話已經(jīng)發(fā)生的費(fèi)用，通過SIP NOTIFY消息的消息體攜帶發(fā)送給用戶A的SIP終端，也可能還攜帶本次通話的費(fèi)率。在SIP NOTIFY消息中也必須指明相應(yīng)的事件包Eventaoc-message10)用戶A的SIP終端接收到SIP NOTIFY消息，從消息體中提取出本次通話的費(fèi)用或費(fèi)率，返回200 OK響應(yīng)碼。
需要指出的是，在呼叫發(fā)起時申請對業(yè)務(wù)的訂閱的實現(xiàn)方法，在上述實施例中，是由用戶主動在發(fā)出的INVITE消息中攜帶表示被訂閱業(yè)務(wù)信息的事件包，但也可能用戶始發(fā)的INVITE消息中沒有攜帶相關(guān)事件包，而是由網(wǎng)絡(luò)在收到用戶始發(fā)的INVITE消息后，根據(jù)用戶的業(yè)務(wù)簽約信息以及當(dāng)前的呼叫狀況，在INVITE消息中插入表示被訂閱業(yè)務(wù)信息的事件包，再發(fā)送給后續(xù)的業(yè)務(wù)控制節(jié)點以處理被訂閱業(yè)務(wù)的訂閱申請。
比如，被叫用戶簽約了彩鈴業(yè)務(wù)，主叫用戶發(fā)起呼叫，網(wǎng)絡(luò)中某網(wǎng)元(第一網(wǎng)元)收到用戶始發(fā)的INVITE消息后，根據(jù)被叫用戶的彩鈴簽約信息以及主叫用戶號碼，判斷要對這次呼叫申請應(yīng)用彩鈴，則在INVITE消息中插入表示申請訂閱彩鈴業(yè)務(wù)的事件包，發(fā)送給后續(xù)提供彩鈴的業(yè)務(wù)控制節(jié)點。這里不太一樣的地方是，表示訂閱業(yè)務(wù)的事件包的訂閱實例創(chuàng)建于該網(wǎng)元(訂閱者)和該業(yè)務(wù)控制節(jié)點(通知者)上，用戶終端作為INVITE消息的始發(fā)者上沒有訂閱實例，相當(dāng)于該網(wǎng)元替用戶終端創(chuàng)建了一個業(yè)務(wù)的訂閱實例。此時，若該網(wǎng)元收到來自該業(yè)務(wù)控制節(jié)點的SIP NOTIFY訂閱通知消息，若需要通知用戶業(yè)務(wù)的應(yīng)用情況，則可以將該消息轉(zhuǎn)換成SIP PUBLISH消息或某個合適的響應(yīng)碼，發(fā)送給用戶終端；當(dāng)然若該網(wǎng)元收到的就是攜帶業(yè)務(wù)應(yīng)用信息的SIPPUBLISH消息，則可以轉(zhuǎn)發(fā)給用戶終端，或轉(zhuǎn)換成某個合適的響應(yīng)碼發(fā)送給用戶終端。
此外，可以看到，本發(fā)明的技術(shù)方案和當(dāng)前SIP訂閱/通知機(jī)制保持一致，對用戶在呼叫發(fā)起時申請訂閱的業(yè)務(wù)，業(yè)務(wù)控制節(jié)點會和收到SIPSUBSCRIBE消息一樣，向用戶發(fā)送SIP NOTIFY訂閱通知消息，通過針對SIP INVITE消息的SIP響應(yīng)碼中攜帶的表示訂閱業(yè)務(wù)的事件包以及SIP NOTIFY消息，業(yè)務(wù)控制節(jié)點就可以向用戶通知業(yè)務(wù)應(yīng)用成功還是失敗的信息。
在前述的技術(shù)方案中，沿用了現(xiàn)有的SIP訂閱/通知機(jī)制，用戶發(fā)起呼叫時攜帶表示被訂閱業(yè)務(wù)信息的事件包，在用戶終端和業(yè)務(wù)控制節(jié)點上創(chuàng)建該事件包的訂閱實例，網(wǎng)絡(luò)向該用戶終端發(fā)送SIP NOTIFY訂閱通知消息攜帶被訂閱業(yè)務(wù)的相關(guān)應(yīng)用內(nèi)容。
我們知道，在SIP協(xié)議中，除了SIP NOTIFY訂閱通知消息外，還有一個SIP PUBLISH消息同樣可以攜帶事件包并指示該事件包的相關(guān)內(nèi)容。因此，也可以使用戶發(fā)起呼叫時攜帶表示被訂閱業(yè)務(wù)信息的事件包，網(wǎng)絡(luò)向用戶終端發(fā)送SIP PUBLISH消息攜帶被訂閱業(yè)務(wù)的相關(guān)應(yīng)用內(nèi)容，此時，用戶終端上不需要創(chuàng)建該事件包的訂閱實例。
在SIP協(xié)議中，PUBLISH消息的應(yīng)用更多的是用戶終端向網(wǎng)絡(luò)發(fā)送，在本實施例中，將要求SIP終端支持對PUBLISH消息的接收和對PUBLISH狀態(tài)的維護(hù)。采用本方法，前述的用戶在呼叫發(fā)起時申請對“計費(fèi)通知”業(yè)務(wù)的訂閱的實施例描述如圖3所示，流程解釋如下1)SIP終端用戶A呼叫用戶B，在呼叫發(fā)起時申請(本次通話)使用計費(fèi)通知業(yè)務(wù)，在終端發(fā)出的SIP INVITE消息中有如下內(nèi)容INVITE sipmary@tele.com SIP/2.0P-SUBaoc-message2)業(yè)務(wù)控制節(jié)點接收SIP INVITE消息，從P-SUB頭域中解析aoc-message事件包，如果用戶A有申請使用計費(fèi)通知業(yè)務(wù)的權(quán)限，則該業(yè)務(wù)申請成功。
3)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機(jī)應(yīng)答，發(fā)送200 OK響應(yīng)碼。
4)業(yè)務(wù)控制節(jié)點接收到200 OK響應(yīng)碼，向主叫方向發(fā)送。
5)用戶A的SIP終端接收到200 OK響應(yīng)碼，返回ACK確認(rèn)消息。
6)業(yè)務(wù)控制節(jié)點將ACK確認(rèn)消息向用戶B的SIP終端發(fā)送，用戶A和用戶B間的會話建立，雙方開始通話。
7)業(yè)務(wù)控制節(jié)點計算本次通話的費(fèi)率，也可能提前計算出本次通話的費(fèi)用，通過SIP PUBLISH消息的消息體攜帶發(fā)送給用戶A的SIP終端，在SIP PUBLISH消息中必須指明相應(yīng)的事件包，并通過Expires頭域指明維護(hù)PUBLISH狀態(tài)的監(jiān)視時長Eventaoc-messageExpires36008)用戶A的SIP終端接收到SIP PUBLISH消息，從消息體中提取出本次通話的費(fèi)率或費(fèi)用，啟動對PUBLISH狀態(tài)的維護(hù)，維護(hù)狀態(tài)的監(jiān)視時長來自于SIP PUBLISH消息中攜帶的Expires頭域取值(3600秒)，返回200 OK響應(yīng)碼。
9)SIP終端B用戶掛機(jī)釋放呼叫，發(fā)送SIP BYE消息。
10)業(yè)務(wù)控制節(jié)點接收到SIP BYE消息，向主叫方向發(fā)送。
11)SIP終端A接收到SIP BYE消息，釋放呼叫，返回200 OK響應(yīng)碼。
12)業(yè)務(wù)控制節(jié)點接收到200 OK響應(yīng)碼，向被叫方向發(fā)送。
13)業(yè)務(wù)控制節(jié)點判斷該呼叫的相關(guān)信息將被完全釋放，用戶訂閱的計費(fèi)通知業(yè)務(wù)也隨之結(jié)束，則計算已經(jīng)發(fā)生的通話費(fèi)用，通過SIPPUBLISH消息的消息體攜帶發(fā)送給用戶A的SIP終端，在SIP PUBLISH消息中必須指明相應(yīng)的事件包，并通過Expires頭域取值為“0”指明業(yè)務(wù)應(yīng)用結(jié)束Eventaoc-messageExpires014)用戶A的SIP終端接收到SIP PUBLISH消息，從消息體中提取出本次通話的費(fèi)用，停止對PUBLISH狀態(tài)的維護(hù)，返回200 OK響應(yīng)碼。
可以看到，用戶A的SIP終端和業(yè)務(wù)控制節(jié)點一對訂閱者和通知者，并沒有為訂閱的事件包創(chuàng)建訂閱實例，而只是維護(hù)了事件包的PUBLISH狀態(tài)。
在實施例圖3中，通過發(fā)送SIP PUBLISH消息發(fā)布事件的事件發(fā)布代理(Event Publication Agent)就位于業(yè)務(wù)控制節(jié)點上，我們知道，在很多情況下，事件發(fā)布代理可能并不位于業(yè)務(wù)控制節(jié)點上(即業(yè)務(wù)控制節(jié)點不具有發(fā)送SIP PUBLISH消息發(fā)布事件的能力)，而是位于另一個獨(dú)立網(wǎng)元(第二網(wǎng)元)上，此時將會有如圖4所示的實施流程，流程解釋如下1)SIP終端用戶A呼叫用戶B，在呼叫發(fā)起時申請(本次通話)使用計費(fèi)通知業(yè)務(wù)，在終端發(fā)出的SIP INVITE消息中有如下內(nèi)容INVITE sipmary@tele.com SIP/2.0P-SUBaoc-message2)事件發(fā)布代理接收SIP INVITE消息，從P-SUB頭域中解析aoc-message事件包，為該事件包創(chuàng)建事務(wù)，將SIP INVITE消息向業(yè)務(wù)控制節(jié)點發(fā)送。
3)業(yè)務(wù)控制節(jié)點接收SIP INVITE消息，向被叫方向發(fā)送。
4)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機(jī)應(yīng)答，發(fā)送200OK響應(yīng)碼。
5)事件發(fā)布代理接收到200 OK響應(yīng)碼，向主叫方向發(fā)送。
6)業(yè)務(wù)控制節(jié)點接收到200 OK響應(yīng)碼，向主叫方向發(fā)送。
7)用戶A的SIP終端接收到200 OK響應(yīng)碼，返回ACK確認(rèn)消息。
8)事件發(fā)布代理接收到ACK確認(rèn)消息，向被叫方向發(fā)送。
9)業(yè)務(wù)控制節(jié)點將ACK確認(rèn)消息向用戶B的SIP終端發(fā)送，用戶A和用戶B間的會話建立，雙方開始通話。
10)會話建立，業(yè)務(wù)控制節(jié)點根據(jù)從P-SUB頭域中解析出的aoc-message事件包，判斷如果用戶A有申請使用計費(fèi)通知業(yè)務(wù)的權(quán)限，則該業(yè)務(wù)申請成功，業(yè)務(wù)控制節(jié)點創(chuàng)建該事件包的訂閱實例(subscription)。業(yè)務(wù)控制節(jié)點計算本次通話的費(fèi)率，也可能提前計算出本次通話的費(fèi)用，通過SIP NOTIFY消息的消息體攜帶向主叫方向發(fā)送，在SIP NOTIFY消息中必須指明相應(yīng)的事件包Eventaoc-message11)事件發(fā)布代理接收到SIPNOTIFY消息，從P-SUB頭域中解析出aoc-message事件包，和已經(jīng)創(chuàng)建的事務(wù)匹配，創(chuàng)建該事件包的訂閱實例。事件發(fā)布代理將SIP NOTIFY消息轉(zhuǎn)換成SIP PUBLISH消息攜帶本次通話的費(fèi)率和/或費(fèi)用，在消息中必須指明相應(yīng)的事件包，并通過Expires頭域指明維護(hù)PUBLISH狀態(tài)的監(jiān)視時長Eventaoc-messageExpires360012)用戶A的SIP終端接收到SIP PUBLISH消息，從消息體中提取出本次通話的費(fèi)率或費(fèi)用，啟動對PUBLISH狀態(tài)的維護(hù)，維護(hù)狀態(tài)的監(jiān)視時長來自于SIP PUBLISH消息中攜帶的Expires頭域取值(3600秒)，返回200 OK響應(yīng)碼。
13)事件發(fā)布代理接收到對SIP PUBLISH消息的200 OK響應(yīng)碼，向業(yè)務(wù)控制節(jié)點發(fā)送對SIP NOTIFY消息的200 OK響應(yīng)碼。
可以看到，在實施例圖4流程中，由于業(yè)務(wù)控制節(jié)點不具有事件發(fā)布能力，因此只能由事件發(fā)布代理和業(yè)務(wù)控制節(jié)點創(chuàng)建對事件包的訂閱實例，業(yè)務(wù)控制節(jié)點將SIP NOTIFY訂閱通知消息發(fā)送給事件發(fā)布代理，后者將SIP NOTIFY消息轉(zhuǎn)換成SIP PUBLISH消息發(fā)送給用戶，當(dāng)然如前所述，也可以轉(zhuǎn)換成合適的響應(yīng)碼發(fā)送給用戶。即對用戶A的SIP終端來說，事件發(fā)布代理具有事件發(fā)布能力，用戶A的SIP終端和事件發(fā)布代理構(gòu)成一對訂閱者和通知者，維護(hù)事件包的PUBLISH狀態(tài)；對業(yè)務(wù)控制節(jié)點(通知者)來說，事件發(fā)布代理就是對事件包的訂閱者，這對訂閱者和通知者為事件包創(chuàng)建了訂閱實例。此外，類似的，此時事件發(fā)布代理(第二網(wǎng)元)還可以為所述事件包對應(yīng)的訂閱和所述呼叫創(chuàng)建一個dialog，或分別創(chuàng)建不同的dialog，前述的第一網(wǎng)元也是如此，這里不再詳細(xì)描述。
在上述的兩個技術(shù)方案中，發(fā)起呼叫時申請業(yè)務(wù)訂閱的用戶，其終端既可以為事件包創(chuàng)建訂閱實例(技術(shù)方案一，實施例圖1和圖2)，也可以不創(chuàng)建訂閱實例(技術(shù)方案二，實施例圖3和圖4)，當(dāng)整個網(wǎng)絡(luò)都采用同一種技術(shù)方案時顯然沒有問題，但當(dāng)整個網(wǎng)絡(luò)不是采用同一種技術(shù)方案時則會出現(xiàn)配合上的問題，比如用戶終端采用技術(shù)方案二，而網(wǎng)絡(luò)設(shè)備取采用技術(shù)方案一，用戶終端在收到攜帶了事件包的SIP響應(yīng)碼后，并沒有創(chuàng)建訂閱實例，這樣它將無法接收后續(xù)網(wǎng)絡(luò)發(fā)送的SIPNOTIFY消息，顯然，業(yè)務(wù)應(yīng)用將因配合差錯而失敗。
因此，需要用戶終端在發(fā)起呼叫申請業(yè)務(wù)訂閱時，在SIP INVITE消息中指明其支持的技術(shù)方案，通過消息中的Supported頭域的內(nèi)容notifing或publishing，指明用戶終端是支持技術(shù)方案一還是支持技術(shù)方案二，網(wǎng)絡(luò)將據(jù)此進(jìn)行相應(yīng)的處理，比如Supported頭域的內(nèi)容為publishing，則網(wǎng)絡(luò)將需要啟動事件發(fā)布的能力，將呼叫INVITE消息路由到一個具有事件發(fā)布代理能力的網(wǎng)絡(luò)實體上，并且發(fā)送SIP PUBLISH消息而不是SIP NOTIFY消息給用戶終端。
此外，在SIP協(xié)議中，用戶之間建立通信聯(lián)系，除了可以用SIPINVITE消息外，還可以用SIP MESSAGE消息(會話發(fā)起協(xié)議即時消息)，本發(fā)明呼叫消息包括SIP INVITE消息和SIP MESSAGE消息，即同樣可以在SIP MESSAGE消息中通過一個固定的頭域傳遞表示被訂閱業(yè)務(wù)信息的事件包，比如，用戶A向用戶B發(fā)送一個即時消息，同時請求“計費(fèi)通知”業(yè)務(wù)，以了解該即時消息所發(fā)生的費(fèi)用，用戶A發(fā)送的SIP消息示例如下MESSAGE sipmary@tele.com SIP/2.0P-SUBaoc-message或INVITE sipmary@tele.com SIP/2.0Eventaoc-message此外，還需要說明的是，本發(fā)明中所述的用戶終端，可以是支持SIP協(xié)議的終端設(shè)備，如SIP話機(jī)、SIP手機(jī)等，也可以是支持SIP協(xié)議的、管理傳統(tǒng)終端設(shè)備的SIP用戶代理設(shè)備，如SIP IAD(Integrated AccessDevice，綜合接入設(shè)備)等，該SIP用戶代理設(shè)備可以將不支持SIP協(xié)議的傳統(tǒng)終端設(shè)備接入到以SIP協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中。
此外，還需要說明的是，除了前述的實施例中用戶發(fā)起呼叫外，本發(fā)明同樣適用于網(wǎng)絡(luò)發(fā)起的呼叫，在呼叫中通過攜帶的事件包表示對業(yè)務(wù)的訂閱。
通過本發(fā)明的方案，在用戶或網(wǎng)絡(luò)發(fā)起呼叫的SIP INVITE消息或SIP MESSAGE消息中通過一個固定的頭域傳遞表示被訂閱業(yè)務(wù)信息的事件包，對一種被訂閱業(yè)務(wù)只需要定義一個事件包，而不需要擴(kuò)展不同的獨(dú)立頭域，仍沿用SIP協(xié)議的現(xiàn)有機(jī)制，保持了SIP協(xié)議現(xiàn)有機(jī)制的完整性。
同時，該事件包同樣可以在SIP SUBSCRIBE消息中通過Event頭域傳遞，即對那些既可在呼叫發(fā)起時申請，也可以不在呼叫發(fā)起時申請的業(yè)務(wù)，定義同一個事件包就能在不同應(yīng)用場景下使用，業(yè)務(wù)申請訂閱成功后的流程基本一致。
同時，對用戶在呼叫發(fā)起時申請訂閱的業(yè)務(wù)，業(yè)務(wù)控制節(jié)點會可以通過SIP NOTIFY/PUBLISH消息以及SIP響應(yīng)碼，向用戶通知業(yè)務(wù)應(yīng)用成功還是失敗的信息，業(yè)務(wù)應(yīng)用結(jié)果向用戶透明，用戶的業(yè)務(wù)體驗性良好。
本發(fā)明同時保護(hù)在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，以會話發(fā)起協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中包括訂閱者，用于在其發(fā)出的非訂閱消息的會話發(fā)起協(xié)議會話消息中通過攜帶一個或一個以上、表示與當(dāng)前所述呼叫相關(guān)業(yè)務(wù)被訂閱信息的事件包；通知者，用于接收所述事件包，向所述訂閱者發(fā)送攜帶所述業(yè)務(wù)應(yīng)用信息的通知消息。系統(tǒng)的工作原理和方法同前面對于呼叫時進(jìn)行業(yè)務(wù)訂閱方法的描述，這里不再贅述。
本發(fā)明的方案具有更廣泛的適用性和通用性，使業(yè)務(wù)的實現(xiàn)變得更加簡潔，并使業(yè)務(wù)應(yīng)用結(jié)果向用戶透明，增加用戶的業(yè)務(wù)體驗性。本領(lǐng)域技術(shù)人員不脫離本發(fā)明的實質(zhì)和精神，可以有多種變形方案實現(xiàn)本發(fā)明，以上所述僅為本發(fā)明較佳可行的實施例而已，并非因此局限本發(fā)明的權(quán)利范圍，凡運(yùn)用本發(fā)明說明書及附圖內(nèi)容所作的等效變化，均包含于本發(fā)明的權(quán)利范圍之內(nèi)。
權(quán)利要求
1.一種在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于包括以下步驟在以會話發(fā)起協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中，用戶終端或網(wǎng)絡(luò)在其發(fā)起的非訂閱消息的會話發(fā)起協(xié)議會話消息中，通過一個頭域攜帶一個或一個以上、表示與當(dāng)前所述會話發(fā)起協(xié)議會話相關(guān)業(yè)務(wù)被訂閱信息的事件包；所述業(yè)務(wù)的業(yè)務(wù)控制節(jié)點接收所述事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理。
2.根據(jù)權(quán)利要求1所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述頭域為事件頭域，并使事件頭域能由訂閱消息和通知消息之外的其它會話發(fā)起協(xié)議消息攜帶。
3.根據(jù)權(quán)利要求2所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述頭域為事件頭域，并使其可以傳遞多個所述事件包。
4.根據(jù)權(quán)利要求1所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述頭域為新擴(kuò)展的一個會話發(fā)起協(xié)議頭域，使其能由訂閱消息和通知消息之外的其它會話發(fā)起協(xié)議消息攜帶。
5.根據(jù)權(quán)利要求4所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述頭域為新擴(kuò)展的一個會話發(fā)起協(xié)議頭域，使其可以傳遞多個所述事件包。
6.根據(jù)權(quán)利要求1所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述非訂閱消息的會話發(fā)起協(xié)議會話消息為呼叫消息，包括會話發(fā)起協(xié)議邀請消息或會話發(fā)起協(xié)議即時消息。
7.根據(jù)權(quán)利要求6所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于用戶終端發(fā)起攜帶所述事件包的所述呼叫消息，所述業(yè)務(wù)控制節(jié)點接收到所述的事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理，若允許用戶終端對所述業(yè)務(wù)的訂閱申請，則在條件滿足時，發(fā)送包含所述業(yè)務(wù)應(yīng)用相關(guān)信息的通知消息。
8.根據(jù)權(quán)利要求7所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述通知消息為會話發(fā)起協(xié)議通知消息、或會話發(fā)起協(xié)議發(fā)布消息、或會話發(fā)起協(xié)議響應(yīng)碼消息。
9.根據(jù)權(quán)利要求6所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述業(yè)務(wù)在呼叫建立后申請訂閱，該申請訂閱由會話發(fā)起協(xié)議訂閱消息中通過事件頭域攜帶所述事件包來完成，所述業(yè)務(wù)的業(yè)務(wù)控制節(jié)點接收到所述的事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理。
10.根據(jù)權(quán)利要求6所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于用戶終端發(fā)起未攜帶所述事件包的所述呼叫消息，網(wǎng)絡(luò)中第一網(wǎng)元在收到該呼叫消息后，根據(jù)業(yè)務(wù)的預(yù)置信息和當(dāng)前會話情況，在該呼叫消息中插入所述事件包，發(fā)送至業(yè)務(wù)控制節(jié)點；或者，用戶終端發(fā)起攜帶所述事件包的所述呼叫消息，經(jīng)過網(wǎng)絡(luò)中第二網(wǎng)元發(fā)送至業(yè)務(wù)控制節(jié)點。
11.根據(jù)權(quán)利要求10所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述第一網(wǎng)元或第二網(wǎng)元收到包含所述業(yè)務(wù)應(yīng)用相關(guān)信息的通知消息，如果該通知消息是會話發(fā)起協(xié)議通知消息，則將該通知消息轉(zhuǎn)換成會話發(fā)起協(xié)議發(fā)布消息或會話發(fā)起協(xié)議響應(yīng)碼消息，向用戶終端發(fā)送；如果該通知消息是會話發(fā)起協(xié)議發(fā)布消息，則將該消息向用戶終端轉(zhuǎn)發(fā)，或轉(zhuǎn)換成會話發(fā)起協(xié)議響應(yīng)碼消息向用戶終端發(fā)送。
12.根據(jù)權(quán)利要求10所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于對業(yè)務(wù)控制節(jié)點接受訂閱的所述事件包，所述第一網(wǎng)元或第二網(wǎng)元為其創(chuàng)建訂閱實例。
13.根據(jù)權(quán)利要求7所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于用戶終端發(fā)起攜帶所述事件包的所述呼叫消息，在收到所述通知消息后，為該通知消息中攜帶的事件包創(chuàng)建訂閱實例。
14.根據(jù)權(quán)利要求8所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述會話發(fā)起協(xié)議響應(yīng)碼消息中攜帶的事件包通過新擴(kuò)展的會話發(fā)起協(xié)議頭域或事件頭域傳遞。
15.根據(jù)權(quán)利要求7或10所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述用戶終端、或第一網(wǎng)元、或第二網(wǎng)元發(fā)起攜帶所述事件包的所述呼叫消息，為所述事件包對應(yīng)的訂閱和所述呼叫創(chuàng)建一個對話，或分別創(chuàng)建不同的對話。
16.根據(jù)權(quán)利要求15所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于若所述訂閱和所述呼叫被分別創(chuàng)建不同的對話，則在所述頭域中攜帶所述訂閱對應(yīng)的對話參數(shù)。
17.根據(jù)權(quán)利要求6所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于用戶終端發(fā)起攜帶所述事件包的所述呼叫消息中指示用戶終端是否為所述事件包創(chuàng)建訂閱實例。
18.根據(jù)權(quán)利要求17所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，其特征在于所述呼叫消息中通過支持頭域的內(nèi)容來指示用戶終端是否為所述事件包創(chuàng)建訂閱實例。
19.一種在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于，以會話發(fā)起協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中包括訂閱者，用于在其發(fā)出的非訂閱消息的會話發(fā)起協(xié)議會話消息中通過攜帶一個或一個以上、表示與當(dāng)前所述呼叫相關(guān)業(yè)務(wù)被訂閱信息的事件包；通知者，用于接收所述事件包，向所述訂閱者發(fā)送攜帶所述業(yè)務(wù)應(yīng)用信息的通知消息。
20.根據(jù)權(quán)利要求19所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述事件包通過會話發(fā)起協(xié)議頭域攜帶，該頭域是事件頭域或新擴(kuò)展頭域。
21.根據(jù)權(quán)利要求19或20所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述非訂閱消息的會話發(fā)起協(xié)議會話消息為呼叫消息，包括會話發(fā)起協(xié)議邀請消息或會話發(fā)起協(xié)議即時消息。
22.根據(jù)權(quán)利要求19或20所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述通知消息為會話發(fā)起協(xié)議通知消息、或會話發(fā)起協(xié)議發(fā)布消息、或會話發(fā)起協(xié)議響應(yīng)碼消息。
23.根據(jù)權(quán)利要求22所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述會話發(fā)起協(xié)議響應(yīng)碼消息攜帶所述事件包。
24.根據(jù)權(quán)利要求21所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述訂閱者為所述事件包對應(yīng)的訂閱和所述呼叫創(chuàng)建一個對話，或分別創(chuàng)建不同的對話。
25.根據(jù)權(quán)利要求24所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于若所述訂閱和所述呼叫被分別創(chuàng)建不同的對話，則在所述頭域中攜帶所述訂閱對應(yīng)的對話參數(shù)。
26.根據(jù)權(quán)利要求21所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述通知者為所述事件包創(chuàng)建對應(yīng)的訂閱實例，或維護(hù)發(fā)布狀態(tài)。
27.根據(jù)權(quán)利要求21所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于如果所述訂閱者不是所述呼叫消息的始發(fā)者，該訂閱者收到的通知消息是會話發(fā)起協(xié)議通知消息，則將該通知消息轉(zhuǎn)換成會話發(fā)起協(xié)議發(fā)布消息或會話發(fā)起協(xié)議響應(yīng)碼消息，向所述呼叫消息的始發(fā)者發(fā)送；如果該通知消息是會話發(fā)起協(xié)議發(fā)布消息，則將該消息向所述呼叫消息的始發(fā)者轉(zhuǎn)發(fā)，或轉(zhuǎn)換成會話發(fā)起協(xié)議響應(yīng)碼消息向所述呼叫消息的始發(fā)者發(fā)送。
28.根據(jù)權(quán)利要求21所述的在呼叫時進(jìn)行業(yè)務(wù)訂閱的系統(tǒng)，其特征在于所述呼叫消息中指示所述訂閱者是否為所述事件包創(chuàng)建訂閱實例。
全文摘要
一種在呼叫時進(jìn)行業(yè)務(wù)訂閱的方法，在以SIP協(xié)議提供業(yè)務(wù)的網(wǎng)絡(luò)中，用戶終端或網(wǎng)絡(luò)在用戶終端發(fā)起的非訂閱消息的SIP會話消息中，通過一個頭域攜帶一個或一個以上、表示與當(dāng)前所述SIP會話相關(guān)業(yè)務(wù)被訂閱信息的事件包；業(yè)務(wù)的業(yè)務(wù)控制節(jié)點接收所述事件包，進(jìn)行相應(yīng)的業(yè)務(wù)處理，若允許用戶終端對所述業(yè)務(wù)的訂閱申請，則在條件滿足時，發(fā)送包含業(yè)務(wù)應(yīng)用相關(guān)信息的通知消息。本發(fā)明克服了現(xiàn)有技術(shù)通過SIP INVITE消息攜帶一個獨(dú)立頭域來指示在呼叫發(fā)起時申請的業(yè)務(wù)信息，會使SIP協(xié)議變得不可控、實現(xiàn)流程不統(tǒng)一以及帶來資源浪費(fèi)的缺點，使訂閱流程仍沿用SIP協(xié)議的現(xiàn)有機(jī)制，并使業(yè)務(wù)應(yīng)用結(jié)果向用戶透明，增加用戶的業(yè)務(wù)體驗性。
文檔編號H04W8/18GK1976529SQ20061010090
公開日2007年6月6日 申請日期2006年7月26日 優(yōu)先權(quán)日2005年11月29日
發(fā)明者施有鑄, 王嘯 申請人:華為技術(shù)有限公司