專利名稱：在呼叫時進行業務訂閱的方法及系統的制作方法
技術領域：
本發明涉及通信技術領域，尤其涉及一種在呼叫時進行業務訂閱的方法及系統。
背景技術：
在SIP(Session Initiation Protocol，即會話發起協議)中，提供了一種訂閱/通知(SUBSCRIBE/NOTIFY)的機制，訂閱者可以向被訂閱者(通知者)發送SIP SUBSCRIBE消息(會話發起協議訂閱消息)，消息中攜帶表示訂閱信息的事件包(event package)，被訂閱者向訂閱者發送SIP NOTIFY消息(會話發起協議通知消息)，消息中攜帶被訂閱的內容。目前，按照SIP協議的定義，表示訂閱信息的事件包由Event header(事件頭域)負責傳遞，而Event頭域只能通過SIP SUBSCRIBE消息、SIPNOTIFY消息以及一種SIP PUBLISH消息(會話發起協議發布消息)攜帶。
SIP協議的訂閱/通知機制向用戶提供了一種非常靈活的業務申請的方法，用戶在自己終端上可以申請訂閱各種各樣的業務，比如某個好朋友的在線狀態、天氣預報、對某個惡意騷擾電話的追查等待。
但是如前所述，用戶的訂閱只能通過SIP SUBSCRIBE消息來實現，這類申請訂閱的業務是和呼叫無關的，不需要和某個具體呼叫相關聯。而我們又知道，某些申請訂閱的業務是和呼叫相關的，即該業務的申請訂閱只在某個呼叫中有效。用戶發起某個呼叫，希望在這個呼叫中應用某種業務，則可以臨時申請訂閱該業務應用于該特定呼叫中，比如，用戶發起一次呼叫，希望臨時申請“計費通知(Advice of Charge)”業務，使網絡可以通知他/她這次呼叫所發生的費用；再如，用戶發起一次呼叫，希望臨時申請“主叫號碼顯示限制”業務，使這次呼叫建立過程中網絡不將他/她的號碼顯示給被叫用戶。
顯然，用戶發起呼叫，終端將發送SIP INVITE消息(會話發起協議邀請消息)，而傳遞用戶訂閱信息的事件包的Event頭域只能在SIPSUBSCRIBE消息中傳遞，因此目前SIP協議的訂閱機制無法實現用戶“臨時”申請訂閱業務作用在某個特定呼叫上的需求。
當前，為了解決這個問題，一般的方法是在SIP INVITE消息中采用一個獨立的頭域(header)來指示上述的在呼叫發起時申請的業務信息，比如在ETSI(European Telecommunications Standards Institute，歐洲電信標準協會)的TISPAN(Telecommunications and Internet ConvergedServices and Protocols for Advanced Networking)系列標準中，采用一個P-AOC頭域來指示呼叫發起時對“計費通知”業務的申請，采用一個Privacy頭域來指示呼叫發起時對“主叫號碼顯示限制”業務的申請。
但是，我們也知道，用戶在呼叫發起時“臨時”申請訂閱的此類業務是會有很多種的，具體數目是由用戶需求決定的，當前是無法預知的，如果這類業務實現時都采用一個獨立頭域的方式，缺乏統一的機制，將會使SIP協議變得不可控，不具有可預見性。再如，已經激活了呼叫等待業務的用戶發起一次呼叫時，希望申請“臨時撤消呼叫等待”業務，使這次呼叫建立的通話不受新呼入來話的影響。
特別是，某些業務既可在呼叫發起時申請，也可以不在呼叫發起時申請，比如前述的“計費通知”業務，用戶在呼叫發起時沒有申請該業務，而是在通話中想查詢一下已經發生了多少費用，則用戶在通話中申請訂閱“計費通知”業務，顯然，這時的訂閱仍然是利用SIP SUBSCRIBE消息攜帶事件包來完成的。
這樣，同一個業務的申請在不同應用場景下將會分別通過一個獨立頭域、一個訂閱事件包來實現，造成實現流程不統一以及帶來的資源浪費。
此外，在SIP INVITE消息中通過一個獨立頭域來指示對業務的申請，很難向用戶反饋業務應用成功還是失敗的信息，因為SIP INVITE消息的目的是為了建立呼叫進行通話，它的SIP會話建立過程都是為這個目的服務的，沒有更多的考慮這類和呼叫相關的業務的應用狀況，顯然即使業務應用失敗，也不能因此而拒絕此次呼叫的建立。比如前述的“主叫號碼顯示限制”業務，網絡對這個業務應用成功還是失敗，按目前的標準流程，申請業務的主叫用戶都不得而知。
從上述分析可以看出，在用戶發起呼叫時，現有技術通過SIPINVITE消息攜帶一個獨立頭域來指示在呼叫發起時申請的業務信息主要有如下三個缺點1、用戶在呼叫發起時“臨時”申請訂閱的業務是會有很多種的，具體數目是由用戶需求決定的，當前是無法預知的，采用一個獨立頭域的實現方式缺乏統一的機制，將會使SIP協議變得不可控，不具有可預見性。
2、對某些既可在呼叫發起時申請，也可以不在呼叫發起時申請的業務，同一個業務的申請在不同應用場景下將會分別通過一個獨立頭域、一個訂閱事件包來實現，造成實現流程不統一以及帶來的資源浪費。
3、用戶在呼叫發起時申請業務后，很難知道該業務的應用成功還是失敗的信息，業務應用結果對用戶不透明，用戶體驗性不好。
發明內容
本發明所要解決的技術問題是克服現有技術通過SIP INVITE消息攜帶一個獨立頭域來指示在呼叫發起時申請的業務信息，會使SIP協議變得不可控、實現流程不統一以及帶來資源浪費的缺點，提供一種在呼叫時進行業務訂閱的方法及系統，仍沿用SIP協議的現有機制，保持SIP協議現有機制的完整性，并使業務應用結果向用戶透明，增加用戶的業務體驗性。
本發明為解決上述技術問題所采用的技術方案為這種在呼叫時進行業務訂閱的方法，包括以下步驟在以會話發起協議提供業務的網絡中，用戶終端或網絡在其發起的非訂閱消息的會話發起協議會話消息中，通過一個頭域攜帶一個或一個以上、表示與當前所述會話發起協議會話相關業務被訂閱信息的事件包；所述業務的業務控制節點接收所述事件包，進行相應的業務處理。
所述頭域可以為事件頭域，并使事件頭域能由訂閱消息和通知消息之外的其它會話發起協議消息攜帶。所述頭域為事件頭域時，并使其可以傳遞多個所述事件包。
所述頭域可以為新擴展的一個會話發起協議頭域，使其能由訂閱消息和通知消息之外的其它會話發起協議消息攜帶。所述頭域為新擴展的一個會話發起協議頭域時，使其可以傳遞多個所述事件包。
所述非訂閱消息的會話發起協議會話消息可以為呼叫消息，包括會話發起協議邀請消息或會話發起協議即時消息。
用戶終端發起攜帶所述事件包的所述呼叫消息，所述業務控制節點接收到所述的事件包，進行相應的業務處理，若允許用戶終端對所述業務的訂閱申請，則在條件滿足時，發送包含所述業務應用相關信息的通知消息。
所述通知消息可以為會話發起協議通知消息、或會話發起協議發布消息、或會話發起協議響應碼消息。
所述業務在呼叫建立后申請訂閱，該申請訂閱可由會話發起協議訂閱消息中通過事件頭域攜帶所述事件包來完成，所述業務的業務控制節點接收到所述的事件包，進行相應的業務處理。
用戶終端發起未攜帶所述事件包的所述呼叫消息，網絡中第一網元在收到該呼叫消息后，根據業務的預置信息和當前會話情況，在該呼叫消息中插入所述事件包，發送至業務控制節點；或者，用戶終端發起攜帶所述事件包的所述呼叫消息，經過網絡中第二網元發送至業務控制節點。
所述第一網元或第二網元收到包含所述業務應用相關信息的通知消息，如果該通知消息是會話發起協議通知消息，則將該通知消息轉換成會話發起協議發布消息或會話發起協議響應碼消息，向用戶終端發送；如果該通知消息是會話發起協議發布消息，則將該消息向用戶終端轉發，或轉換成會話發起協議響應碼消息向用戶終端發送。
對業務控制節點接受訂閱的所述事件包，所述第一網元或第二網元為其創建訂閱實例。
用戶終端發起攜帶所述事件包的所述呼叫消息，在收到所述通知消息后，為該通知消息中攜帶的事件包創建訂閱實例。
所述會話發起協議響應碼消息中攜帶的事件包通過新擴展的會話發起協議頭域或事件頭域傳遞。
所述用戶終端、或第一網元、或第二網元發起攜帶所述事件包的所述呼叫消息，為所述事件包對應的訂閱和所述呼叫創建一個對話，或分別創建不同的對話。
若所述訂閱和所述呼叫被分別創建不同的對話，則在所述頭域中攜帶所述訂閱對應的對話參數。
用戶終端發起攜帶所述事件包的所述呼叫消息中指示用戶終端是否為所述事件包創建訂閱實例。
所述呼叫消息中通過支持頭域的內容來指示用戶終端是否為所述事件包創建訂閱實例。
相應的一種在呼叫時進行業務訂閱的系統，以會話發起協議提供業務的網絡中包括訂閱者，用于在其發出的非訂閱消息的會話發起協議會話消息中通過攜帶一個或一個以上、表示與當前所述呼叫相關業務被訂閱信息的事件包；通知者，用于接收所述事件包，向所述訂閱者發送攜帶所述業務應用信息的通知消息。
本發明的有益效果為本發明在SIP協議給出一種和當前SIP訂閱/通知機制保持一致的、在呼叫發起時對業務的申請訂閱方法，可以通過呼叫消息攜帶表示被訂閱業務信息的事件包。在用戶終端發起的呼叫消息中通過一個固定的頭域傳遞表示被訂閱業務信息的事件包，對一種被訂閱業務只需要定義一個事件包，而不需要擴展不同的獨立頭域，仍沿用SIP協議的現有機制，保持了SIP協議現有機制的完整性。
同時，該事件包同樣可以在SIP SUBSCRIBE消息中通過Event頭域傳遞，即對那些既可在呼叫發起時申請，也可以不在呼叫發起時申請的業務，定義同一個事件包就能在不同應用場景下使用，業務申請訂閱成功后的流程基本一致。
同時，對用戶終端在呼叫發起時申請訂閱的業務，業務控制節點可以通過SIP NOTIFY/PUBLISH消息以及可以攜帶事件包的SIP響應碼，向用戶終端通知業務應用成功還是失敗的信息，業務應用結果向用戶透明，用戶的業務體驗性良好。
綜上所述，本發明具有更廣泛的適用性和通用性，使業務的實現變得更加簡潔，并使業務應用結果向用戶透明，增加用戶的業務體驗性。
圖1為本發明在呼叫發起時進行計費通知業務訂閱的一種實現流程示意圖；圖2為本發明在通話中進行計費通知業務訂閱的實現流程示意圖；圖3為本發明在呼叫發起時進行計費通知業務訂閱的另一種實現流程示意圖；圖4為本發明事件發布代理不在業務控制節點時，在呼叫發起時進行計費通知業務訂閱的實現流程示意圖。
具體實施例方式
下面根據附圖和實施例對本發明作進一步詳細說明現有技術通過一個獨立頭域來指示在呼叫發起時對業務的申請方法是不可取的，基于此，本發明將在SIP協議給出一種和當前SIP訂閱/通知機制保持一致的、在呼叫發起時對業務的申請訂閱方法，通過SIPINVITE消息攜帶表示被訂閱業務信息的事件包。
從前面分析可以看出，本發明要解決的問題就是在呼叫發起時對業務的申請訂閱方法，仍然沿用當前SIP訂閱/通知機制，仍通過事件包來表示被訂閱業務的信息。要達到這個目的，如前所述，要么使Event頭域也可以通過SIP INVITE消息攜帶；要么新擴展一個頭域使其也可以傳遞表示被訂閱業務信息的事件包，該頭域通過SIP INVITE消息攜帶。
對前一種方法，需要改變目前SIP協議的定義，在IETF(Internetengineering task force，因特網工程任務組)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頭域對SUBSCRIBE和NOTIFY消息是必選的(mandatory)，對INVITE消息是可選的(optional)。
對后一種方法，本發明新擴展一個能由SUBSCRIBE消息、NOTIFY消息以及PUBLISH消息之外的其它SIP消息攜帶的、傳遞表示被訂閱業務信息的事件包的頭域，比如命名為P-SUB，參照SIP協議中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頭域中傳遞的表示被訂閱業務信息的事件包，它包含了事件包類型event-type和參數event-param，而event-type和event-param的定義和Event頭域中的完全相同，本發明不再詳細解釋。
可以看出，和Event頭域定義不一樣的地方是，P-SUB頭域中可以傳遞多個表示被訂閱業務信息的事件包，而Event頭域中只能傳遞一個事件包。這是因為，用戶在呼叫發起時，可能會申請對多個業務的訂閱，比如同時申請“計費通知”和“主叫號碼顯示限制”。當然，為了實現這個需求，也可以修改Event頭域的定義格式，使其也能傳遞多個事件包。
下面通過一個具體的實施例來說明，用戶如何在呼叫發起時申請對“計費通知”業務的訂閱，以及在通話中申請對“計費通知”業務的訂閱，并展示如何在SIP INVITE消息和SIP SUBSCRIBE消息中傳遞表示“計費通知”業務訂閱信息的事件包，以達到不需要擴展一個獨立的頭域(P-AOC)、一個業務的訂閱只有一個相應事件包的目的。
在本實施例中，假設被申請訂閱的業務由業務控制節點這樣一個邏輯網元來提供業務邏輯控制和執行環境，它可以存在于某個網絡實體(如應用服務器)中，甚至也可以存在于用戶終端之中。需要說明的是，本發明中所作的流程圖示和文字說明僅為突出本發明的關鍵技術所作的解釋，并不表示一個完整的呼叫和業務控制流程，也沒有窮盡所有可能的分支流程。
如圖1所示，用戶在呼叫發起時申請對“計費通知”業務的訂閱流程具體說明如下1)SIP終端用戶A呼叫用戶B，在呼叫發起時申請(本次通話)使用計費通知業務，在終端發出的SIP INVITE消息中有如下內容INVITE sipmary@tele.com SIP/2.0P-SUBaoc-message其中，P-SUB頭域即用來傳遞表示“計費通知”業務訂閱信息的事件包aoc-message，需要說明的是，計費通知業務事件包aoc-message是本發明的一個擴展，P-SUB頭域和下述的Event頭域中事件類型(event-type)的取值“aoc-message”是該事件包名稱(event packagename)。如前所述，擴展Event頭域的使用范圍，此時也可以在SIP INVITE消息中傳遞Event頭域INVITE sipmary@tele.com SIP/2.0Eventaoc-message為符合SIP協議的訂閱/通知機制，SIP終端A作為訂閱者(subscriber)需要為事件包aoc-message創建一個事務(transaction)。
2)業務控制節點接收SIP INVITE消息，向被叫方向發送。
3)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機應答，發送200OK響應碼。
4)業務控制節點接收到200OK響應碼，向主叫方向發送。此時被叫已經應答，業務控制節點根據此前從SIP INVITE消息里P-SUB頭域中解析出的aoc-message事件包，判斷如果用戶A有申請使用計費通知業務的權限，則該業務申請成功，作為通知者(notifier)創建該事件包的訂閱實例(subscription)，并在200OK響應碼中通過P-SUB頭域或Event頭域攜帶訂閱成功被接受的事件包P-SUBaoc-message此時，在該200 OK響應碼中就已經可以通過攜帶本次通話的計費通知信息，一般可以通過響應碼的消息體攜帶。
5)用戶A的SIP終端接收到200 OK響應碼，返回ACK確認消息。SIP終端A從200 OK響應碼中解析出aoc-message事件包，和已經創建事務的事件包匹配，創建該事件包的訂閱實例。
若該響應碼中已經攜帶了本次通話的計費通知信息，則用戶A的SIP終端還可以提取出計費通知信息。
6)業務控制節點將ACK確認消息向用戶B的SIP終端發送，用戶A和用戶B間的會話建立，雙方開始通話。
7)業務控制節點計算本次通話的費率，也可能提前計算出本次通話的費用，通過SIP NOTIFY消息的消息體攜帶計費通知信息發送給用戶A的SIP終端，在SIP NOTIFY消息中必須指明相應的事件包Eventaoc-message8)用戶A的SIP終端接收到SIP NOTIFY消息，從消息體中提取出本次通話的費率或費用，返回200 OK響應碼。
9)SIP終端B用戶掛機釋放呼叫，發送SIP BYE消息。
10)業務控制節點接收到SIP BYE消息，向主叫方向發送。
11)SIP終端A接收到SIP BYE消息，釋放呼叫，返回200 OK響應碼。
12)業務控制節點接收到200 OK響應碼，向被叫方向發送。
13)業務控制節點判斷該呼叫的相關信息將被完全釋放，用戶訂閱的計費通知業務也隨之結束，則計算已經發生的通話費用，通過SIPNOTIFY消息的消息體攜帶計費通知信息發送給用戶A的SIP終端，在SIP NOTIFY消息中必須指明相應的事件包，并通過Subscription-State頭域取值為“terminated”指明業務應用結束，釋放訂閱實例Eventaoc-messageSubscription-Stateterminated在Subscription-State頭域中還可以通過reason參數來設置業務應用結束的原因。可以看到，本實施例中，計費通知業務的有效期開始于通話建立時，結束于通話釋放時，業務訂閱實例的釋放由業務控制節點決定。
14)用戶A的SIP終端接收到SIP NOTIFY消息，從消息體中提取出本次通話的費用，釋放訂閱實例，返回200 OK響應碼。
可以看到，在實施例流程圖1中，用戶終端和業務控制節點之間是通過在針對INVITE消息的SIP響應碼(實施例中為200 OK響應碼，還可以是183 Session Progress等響應碼)中攜帶的事件包來指示哪些事件包已經被業務控制節點接受訂閱，用戶終端只為SIP響應碼中攜帶的事件包創建訂閱實例。實際上，按照這個約定，在實施例流程圖1的步驟1中，用戶終端為事件包創建事務也可以不是必須的，即，在步驟5中，用戶終端既使不將SIP響應碼中攜帶的事件包和已經創建事務的事件包相匹配，也可以就根據SIP響應碼中攜帶的事件包來創建相應的訂閱實例。
顯然，這里用戶終端是根據業務控制節點返回的、已經同意訂閱的事件包，來創建該事件包的訂閱實例，這樣，既使SIP響應碼中不通過擴展來攜帶事件包(此時如果需要的話，SIP響應碼也仍然可以攜帶業務應用信息，如圖1的步驟4中攜帶計費通知信息)，用戶終端還可以直接根據業務控制節點發送的第一個的、表示訂閱請求已被接受的NOTIFY消息(如實施例流程圖1中步驟7發送的NOTIFY消息)中攜帶的事件包，來創建該事件包的訂閱實例。即業務控制節點返回的事件包(通過SIP響應碼或NOTIFY消息)，將表明該事件包已經被業務控制節點同意訂閱并創建了相應的訂閱實例，因此用戶終端可以根據業務控制節點返回的事件包來創建相應的訂閱實例。
此外，需要說明的是，由于呼叫發起時對業務的申請訂閱依附于SIPINVITE消息，而SIP INVITE消息作為一個會話消息必須要創建一個dialog(對話)，因此用戶終端上創建的訂閱實例也只能依附于該dialog，即呼叫和訂閱將共用一個dialog。
這里需要進一步說明的是，由于dialog是端到端建立的，而訂閱實例只存在于SIP終端A和業務控制節點之間，因此業務控制節點將作為B2BUA(Back to Back User Agent，背靠背用戶代理)位于SIP INVITE消息建立的呼叫信令路徑中，即實施例流程圖1的步驟1中，SIP終端A和業務控制節點建立了一個dialog，步驟2中，業務控制節點和業務控制節點建立了另一個dialog，所述訂閱實例使用的是SIP終端A和業務控制節點之間建立的dialog。
此外，在上述實施例中，訂閱和呼叫共用了一個dialog，如果訂閱和呼叫不共用一個dialog，即訂閱單獨建立一個dialog，此時則需要SIP終端A在步驟1發送SIP INVITE消息中，單獨指明訂閱的dialog，如擴展P-SUB頭域，以攜帶創建dialog所必須的Call-ID參數和From-tag參數，消息示例如下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其中，From頭域中的“889def”和Call-ID頭域中的“1234@example.com”將用來創建呼叫的dialog，而P-SUB頭域中的“123aa9”和“5678@example.com”將用來創建訂閱的dialog。
而業務控制節點則可以在步驟4，通過返回的P-SUB頭域攜帶To-tag參數，消息示例如下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的參數，可以看到，訂閱和呼叫的dialog分別不同，訂閱的dialog通過新擴展的頭域攜帶，當然也可以通過其它方式攜帶。
此時，雖然訂閱dialog的路由集重用SIP終端A到業務控制節點間呼叫建立的路由集，即相同的信令路徑，但訂閱和呼叫卻分別建立了兩個dialog，該方法同樣適用于后面的實施例。
另外，由于每個事件包都有自己的訂閱實例，因此當INVITE消息中攜帶一個以上的事件包時，若這些事件包不共用呼叫的dialog，則需要為每個事件包對應的訂閱實例創建一個dialog，即對上述的P-SUB頭域來說，每個事件包都要有其對應的dialog參數。
如圖2所示，在通話中申請對“計費通知”業務的訂閱流程具體說明如下1)SIP終端用戶A呼叫用戶B，發出SIP INVITE消息。
2)業務控制節點接收SIP INVITE消息，向被叫方向發送。
3)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機應答，發送200 OK響應碼。
4)業務控制節點接收到200 OK響應碼，向主叫方向發送。
5)用戶A的SIP終端接收到200 OK響應碼，返回ACK確認消息。
6)業務控制節點將ACK確認消息向用戶B的SIP終端發送，用戶A和用戶B間的會話建立，雙方開始通話。
7)用戶A在和用戶B通話，經過一段時間后，希望申請使用計費通知業務，看看當前已經產生了多少話費，則用戶A在SIP終端上發起對計費通知業務的訂閱申請，發出SIP SUBSCRIBE消息，消息中有如下內容Eventaoc-messageSIP終端A作為訂閱者為事件包aoc-message創建事務。
8)業務控制節點接收SIP SUBSCRIBE消息，從Event頭域中解析aoc-message事件包，如果用戶A有申請使用計費通知業務的權限，則該業務申請成功，業務控制節點作為通知者創建訂閱實例，返回200 OK響應碼。
SIP終端A接收到同意訂閱的200 OK響應碼，為事件包aoc-message創建訂閱實例。
9)業務控制節點計算當前通話已經發生的費用，通過SIP NOTIFY消息的消息體攜帶發送給用戶A的SIP終端，也可能還攜帶本次通話的費率。在SIP NOTIFY消息中也必須指明相應的事件包Eventaoc-message10)用戶A的SIP終端接收到SIP NOTIFY消息，從消息體中提取出本次通話的費用或費率，返回200 OK響應碼。
需要指出的是，在呼叫發起時申請對業務的訂閱的實現方法，在上述實施例中，是由用戶主動在發出的INVITE消息中攜帶表示被訂閱業務信息的事件包，但也可能用戶始發的INVITE消息中沒有攜帶相關事件包，而是由網絡在收到用戶始發的INVITE消息后，根據用戶的業務簽約信息以及當前的呼叫狀況，在INVITE消息中插入表示被訂閱業務信息的事件包，再發送給后續的業務控制節點以處理被訂閱業務的訂閱申請。
比如，被叫用戶簽約了彩鈴業務，主叫用戶發起呼叫，網絡中某網元(第一網元)收到用戶始發的INVITE消息后，根據被叫用戶的彩鈴簽約信息以及主叫用戶號碼，判斷要對這次呼叫申請應用彩鈴，則在INVITE消息中插入表示申請訂閱彩鈴業務的事件包，發送給后續提供彩鈴的業務控制節點。這里不太一樣的地方是，表示訂閱業務的事件包的訂閱實例創建于該網元(訂閱者)和該業務控制節點(通知者)上，用戶終端作為INVITE消息的始發者上沒有訂閱實例，相當于該網元替用戶終端創建了一個業務的訂閱實例。此時，若該網元收到來自該業務控制節點的SIP NOTIFY訂閱通知消息，若需要通知用戶業務的應用情況，則可以將該消息轉換成SIP PUBLISH消息或某個合適的響應碼，發送給用戶終端；當然若該網元收到的就是攜帶業務應用信息的SIPPUBLISH消息，則可以轉發給用戶終端，或轉換成某個合適的響應碼發送給用戶終端。
此外，可以看到，本發明的技術方案和當前SIP訂閱/通知機制保持一致，對用戶在呼叫發起時申請訂閱的業務，業務控制節點會和收到SIPSUBSCRIBE消息一樣，向用戶發送SIP NOTIFY訂閱通知消息，通過針對SIP INVITE消息的SIP響應碼中攜帶的表示訂閱業務的事件包以及SIP NOTIFY消息，業務控制節點就可以向用戶通知業務應用成功還是失敗的信息。
在前述的技術方案中，沿用了現有的SIP訂閱/通知機制，用戶發起呼叫時攜帶表示被訂閱業務信息的事件包，在用戶終端和業務控制節點上創建該事件包的訂閱實例，網絡向該用戶終端發送SIP NOTIFY訂閱通知消息攜帶被訂閱業務的相關應用內容。
我們知道，在SIP協議中，除了SIP NOTIFY訂閱通知消息外，還有一個SIP PUBLISH消息同樣可以攜帶事件包并指示該事件包的相關內容。因此，也可以使用戶發起呼叫時攜帶表示被訂閱業務信息的事件包，網絡向用戶終端發送SIP PUBLISH消息攜帶被訂閱業務的相關應用內容，此時，用戶終端上不需要創建該事件包的訂閱實例。
在SIP協議中，PUBLISH消息的應用更多的是用戶終端向網絡發送，在本實施例中，將要求SIP終端支持對PUBLISH消息的接收和對PUBLISH狀態的維護。采用本方法，前述的用戶在呼叫發起時申請對“計費通知”業務的訂閱的實施例描述如圖3所示，流程解釋如下1)SIP終端用戶A呼叫用戶B，在呼叫發起時申請(本次通話)使用計費通知業務，在終端發出的SIP INVITE消息中有如下內容INVITE sipmary@tele.com SIP/2.0P-SUBaoc-message2)業務控制節點接收SIP INVITE消息，從P-SUB頭域中解析aoc-message事件包，如果用戶A有申請使用計費通知業務的權限，則該業務申請成功。
3)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機應答，發送200 OK響應碼。
4)業務控制節點接收到200 OK響應碼，向主叫方向發送。
5)用戶A的SIP終端接收到200 OK響應碼，返回ACK確認消息。
6)業務控制節點將ACK確認消息向用戶B的SIP終端發送，用戶A和用戶B間的會話建立，雙方開始通話。
7)業務控制節點計算本次通話的費率，也可能提前計算出本次通話的費用，通過SIP PUBLISH消息的消息體攜帶發送給用戶A的SIP終端，在SIP PUBLISH消息中必須指明相應的事件包，并通過Expires頭域指明維護PUBLISH狀態的監視時長Eventaoc-messageExpires36008)用戶A的SIP終端接收到SIP PUBLISH消息，從消息體中提取出本次通話的費率或費用，啟動對PUBLISH狀態的維護，維護狀態的監視時長來自于SIP PUBLISH消息中攜帶的Expires頭域取值(3600秒)，返回200 OK響應碼。
9)SIP終端B用戶掛機釋放呼叫，發送SIP BYE消息。
10)業務控制節點接收到SIP BYE消息，向主叫方向發送。
11)SIP終端A接收到SIP BYE消息，釋放呼叫，返回200 OK響應碼。
12)業務控制節點接收到200 OK響應碼，向被叫方向發送。
13)業務控制節點判斷該呼叫的相關信息將被完全釋放，用戶訂閱的計費通知業務也隨之結束，則計算已經發生的通話費用，通過SIPPUBLISH消息的消息體攜帶發送給用戶A的SIP終端，在SIP PUBLISH消息中必須指明相應的事件包，并通過Expires頭域取值為“0”指明業務應用結束Eventaoc-messageExpires014)用戶A的SIP終端接收到SIP PUBLISH消息，從消息體中提取出本次通話的費用，停止對PUBLISH狀態的維護，返回200 OK響應碼。
可以看到，用戶A的SIP終端和業務控制節點一對訂閱者和通知者，并沒有為訂閱的事件包創建訂閱實例，而只是維護了事件包的PUBLISH狀態。
在實施例圖3中，通過發送SIP PUBLISH消息發布事件的事件發布代理(Event Publication Agent)就位于業務控制節點上，我們知道，在很多情況下，事件發布代理可能并不位于業務控制節點上(即業務控制節點不具有發送SIP PUBLISH消息發布事件的能力)，而是位于另一個獨立網元(第二網元)上，此時將會有如圖4所示的實施流程，流程解釋如下1)SIP終端用戶A呼叫用戶B，在呼叫發起時申請(本次通話)使用計費通知業務，在終端發出的SIP INVITE消息中有如下內容INVITE sipmary@tele.com SIP/2.0P-SUBaoc-message2)事件發布代理接收SIP INVITE消息，從P-SUB頭域中解析aoc-message事件包，為該事件包創建事務，將SIP INVITE消息向業務控制節點發送。
3)業務控制節點接收SIP INVITE消息，向被叫方向發送。
4)用戶B的SIP終端接收到SIP INVITE消息，用戶B摘機應答，發送200OK響應碼。
5)事件發布代理接收到200 OK響應碼，向主叫方向發送。
6)業務控制節點接收到200 OK響應碼，向主叫方向發送。
7)用戶A的SIP終端接收到200 OK響應碼，返回ACK確認消息。
8)事件發布代理接收到ACK確認消息，向被叫方向發送。
9)業務控制節點將ACK確認消息向用戶B的SIP終端發送，用戶A和用戶B間的會話建立，雙方開始通話。
10)會話建立，業務控制節點根據從P-SUB頭域中解析出的aoc-message事件包，判斷如果用戶A有申請使用計費通知業務的權限，則該業務申請成功，業務控制節點創建該事件包的訂閱實例(subscription)。業務控制節點計算本次通話的費率，也可能提前計算出本次通話的費用，通過SIP NOTIFY消息的消息體攜帶向主叫方向發送，在SIP NOTIFY消息中必須指明相應的事件包Eventaoc-message11)事件發布代理接收到SIPNOTIFY消息，從P-SUB頭域中解析出aoc-message事件包，和已經創建的事務匹配，創建該事件包的訂閱實例。事件發布代理將SIP NOTIFY消息轉換成SIP PUBLISH消息攜帶本次通話的費率和/或費用，在消息中必須指明相應的事件包，并通過Expires頭域指明維護PUBLISH狀態的監視時長Eventaoc-messageExpires360012)用戶A的SIP終端接收到SIP PUBLISH消息，從消息體中提取出本次通話的費率或費用，啟動對PUBLISH狀態的維護，維護狀態的監視時長來自于SIP PUBLISH消息中攜帶的Expires頭域取值(3600秒)，返回200 OK響應碼。
13)事件發布代理接收到對SIP PUBLISH消息的200 OK響應碼，向業務控制節點發送對SIP NOTIFY消息的200 OK響應碼。
可以看到，在實施例圖4流程中，由于業務控制節點不具有事件發布能力，因此只能由事件發布代理和業務控制節點創建對事件包的訂閱實例，業務控制節點將SIP NOTIFY訂閱通知消息發送給事件發布代理，后者將SIP NOTIFY消息轉換成SIP PUBLISH消息發送給用戶，當然如前所述，也可以轉換成合適的響應碼發送給用戶。即對用戶A的SIP終端來說，事件發布代理具有事件發布能力，用戶A的SIP終端和事件發布代理構成一對訂閱者和通知者，維護事件包的PUBLISH狀態；對業務控制節點(通知者)來說，事件發布代理就是對事件包的訂閱者，這對訂閱者和通知者為事件包創建了訂閱實例。此外，類似的，此時事件發布代理(第二網元)還可以為所述事件包對應的訂閱和所述呼叫創建一個dialog，或分別創建不同的dialog，前述的第一網元也是如此，這里不再詳細描述。
在上述的兩個技術方案中，發起呼叫時申請業務訂閱的用戶，其終端既可以為事件包創建訂閱實例(技術方案一，實施例圖1和圖2)，也可以不創建訂閱實例(技術方案二，實施例圖3和圖4)，當整個網絡都采用同一種技術方案時顯然沒有問題，但當整個網絡不是采用同一種技術方案時則會出現配合上的問題，比如用戶終端采用技術方案二，而網絡設備取采用技術方案一，用戶終端在收到攜帶了事件包的SIP響應碼后，并沒有創建訂閱實例，這樣它將無法接收后續網絡發送的SIPNOTIFY消息，顯然，業務應用將因配合差錯而失敗。
因此，需要用戶終端在發起呼叫申請業務訂閱時，在SIP INVITE消息中指明其支持的技術方案，通過消息中的Supported頭域的內容notifing或publishing，指明用戶終端是支持技術方案一還是支持技術方案二，網絡將據此進行相應的處理，比如Supported頭域的內容為publishing，則網絡將需要啟動事件發布的能力，將呼叫INVITE消息路由到一個具有事件發布代理能力的網絡實體上，并且發送SIP PUBLISH消息而不是SIP NOTIFY消息給用戶終端。
此外，在SIP協議中，用戶之間建立通信聯系，除了可以用SIPINVITE消息外，還可以用SIP MESSAGE消息(會話發起協議即時消息)，本發明呼叫消息包括SIP INVITE消息和SIP MESSAGE消息，即同樣可以在SIP MESSAGE消息中通過一個固定的頭域傳遞表示被訂閱業務信息的事件包，比如，用戶A向用戶B發送一個即時消息，同時請求“計費通知”業務，以了解該即時消息所發生的費用，用戶A發送的SIP消息示例如下MESSAGE sipmary@tele.com SIP/2.0P-SUBaoc-message或INVITE sipmary@tele.com SIP/2.0Eventaoc-message此外，還需要說明的是，本發明中所述的用戶終端，可以是支持SIP協議的終端設備，如SIP話機、SIP手機等，也可以是支持SIP協議的、管理傳統終端設備的SIP用戶代理設備，如SIP IAD(Integrated AccessDevice，綜合接入設備)等，該SIP用戶代理設備可以將不支持SIP協議的傳統終端設備接入到以SIP協議提供業務的網絡中。
此外，還需要說明的是，除了前述的實施例中用戶發起呼叫外，本發明同樣適用于網絡發起的呼叫，在呼叫中通過攜帶的事件包表示對業務的訂閱。
通過本發明的方案，在用戶或網絡發起呼叫的SIP INVITE消息或SIP MESSAGE消息中通過一個固定的頭域傳遞表示被訂閱業務信息的事件包，對一種被訂閱業務只需要定義一個事件包，而不需要擴展不同的獨立頭域，仍沿用SIP協議的現有機制，保持了SIP協議現有機制的完整性。
同時，該事件包同樣可以在SIP SUBSCRIBE消息中通過Event頭域傳遞，即對那些既可在呼叫發起時申請，也可以不在呼叫發起時申請的業務，定義同一個事件包就能在不同應用場景下使用，業務申請訂閱成功后的流程基本一致。
同時，對用戶在呼叫發起時申請訂閱的業務，業務控制節點會可以通過SIP NOTIFY/PUBLISH消息以及SIP響應碼，向用戶通知業務應用成功還是失敗的信息，業務應用結果向用戶透明，用戶的業務體驗性良好。
本發明同時保護在呼叫時進行業務訂閱的系統，以會話發起協議提供業務的網絡中包括訂閱者，用于在其發出的非訂閱消息的會話發起協議會話消息中通過攜帶一個或一個以上、表示與當前所述呼叫相關業務被訂閱信息的事件包；通知者，用于接收所述事件包，向所述訂閱者發送攜帶所述業務應用信息的通知消息。系統的工作原理和方法同前面對于呼叫時進行業務訂閱方法的描述，這里不再贅述。
本發明的方案具有更廣泛的適用性和通用性，使業務的實現變得更加簡潔，并使業務應用結果向用戶透明，增加用戶的業務體驗性。本領域技術人員不脫離本發明的實質和精神，可以有多種變形方案實現本發明，以上所述僅為本發明較佳可行的實施例而已，并非因此局限本發明的權利范圍，凡運用本發明說明書及附圖內容所作的等效變化，均包含于本發明的權利范圍之內。
權利要求
1.一種在呼叫時進行業務訂閱的方法，其特征在于包括以下步驟在以會話發起協議提供業務的網絡中，用戶終端或網絡在其發起的非訂閱消息的會話發起協議會話消息中，通過一個頭域攜帶一個或一個以上、表示與當前所述會話發起協議會話相關業務被訂閱信息的事件包；所述業務的業務控制節點接收所述事件包，進行相應的業務處理。
2.根據權利要求1所述的在呼叫時進行業務訂閱的方法，其特征在于所述頭域為事件頭域，并使事件頭域能由訂閱消息和通知消息之外的其它會話發起協議消息攜帶。
3.根據權利要求2所述的在呼叫時進行業務訂閱的方法，其特征在于所述頭域為事件頭域，并使其可以傳遞多個所述事件包。
4.根據權利要求1所述的在呼叫時進行業務訂閱的方法，其特征在于所述頭域為新擴展的一個會話發起協議頭域，使其能由訂閱消息和通知消息之外的其它會話發起協議消息攜帶。
5.根據權利要求4所述的在呼叫時進行業務訂閱的方法，其特征在于所述頭域為新擴展的一個會話發起協議頭域，使其可以傳遞多個所述事件包。
6.根據權利要求1所述的在呼叫時進行業務訂閱的方法，其特征在于所述非訂閱消息的會話發起協議會話消息為呼叫消息，包括會話發起協議邀請消息或會話發起協議即時消息。
7.根據權利要求6所述的在呼叫時進行業務訂閱的方法，其特征在于用戶終端發起攜帶所述事件包的所述呼叫消息，所述業務控制節點接收到所述的事件包，進行相應的業務處理，若允許用戶終端對所述業務的訂閱申請，則在條件滿足時，發送包含所述業務應用相關信息的通知消息。
8.根據權利要求7所述的在呼叫時進行業務訂閱的方法，其特征在于所述通知消息為會話發起協議通知消息、或會話發起協議發布消息、或會話發起協議響應碼消息。
9.根據權利要求6所述的在呼叫時進行業務訂閱的方法，其特征在于所述業務在呼叫建立后申請訂閱，該申請訂閱由會話發起協議訂閱消息中通過事件頭域攜帶所述事件包來完成，所述業務的業務控制節點接收到所述的事件包，進行相應的業務處理。
10.根據權利要求6所述的在呼叫時進行業務訂閱的方法，其特征在于用戶終端發起未攜帶所述事件包的所述呼叫消息，網絡中第一網元在收到該呼叫消息后，根據業務的預置信息和當前會話情況，在該呼叫消息中插入所述事件包，發送至業務控制節點；或者，用戶終端發起攜帶所述事件包的所述呼叫消息，經過網絡中第二網元發送至業務控制節點。
11.根據權利要求10所述的在呼叫時進行業務訂閱的方法，其特征在于所述第一網元或第二網元收到包含所述業務應用相關信息的通知消息，如果該通知消息是會話發起協議通知消息，則將該通知消息轉換成會話發起協議發布消息或會話發起協議響應碼消息，向用戶終端發送；如果該通知消息是會話發起協議發布消息，則將該消息向用戶終端轉發，或轉換成會話發起協議響應碼消息向用戶終端發送。
12.根據權利要求10所述的在呼叫時進行業務訂閱的方法，其特征在于對業務控制節點接受訂閱的所述事件包，所述第一網元或第二網元為其創建訂閱實例。
13.根據權利要求7所述的在呼叫時進行業務訂閱的方法，其特征在于用戶終端發起攜帶所述事件包的所述呼叫消息，在收到所述通知消息后，為該通知消息中攜帶的事件包創建訂閱實例。
14.根據權利要求8所述的在呼叫時進行業務訂閱的方法，其特征在于所述會話發起協議響應碼消息中攜帶的事件包通過新擴展的會話發起協議頭域或事件頭域傳遞。
15.根據權利要求7或10所述的在呼叫時進行業務訂閱的方法，其特征在于所述用戶終端、或第一網元、或第二網元發起攜帶所述事件包的所述呼叫消息，為所述事件包對應的訂閱和所述呼叫創建一個對話，或分別創建不同的對話。
16.根據權利要求15所述的在呼叫時進行業務訂閱的方法，其特征在于若所述訂閱和所述呼叫被分別創建不同的對話，則在所述頭域中攜帶所述訂閱對應的對話參數。
17.根據權利要求6所述的在呼叫時進行業務訂閱的方法，其特征在于用戶終端發起攜帶所述事件包的所述呼叫消息中指示用戶終端是否為所述事件包創建訂閱實例。
18.根據權利要求17所述的在呼叫時進行業務訂閱的方法，其特征在于所述呼叫消息中通過支持頭域的內容來指示用戶終端是否為所述事件包創建訂閱實例。
19.一種在呼叫時進行業務訂閱的系統，其特征在于，以會話發起協議提供業務的網絡中包括訂閱者，用于在其發出的非訂閱消息的會話發起協議會話消息中通過攜帶一個或一個以上、表示與當前所述呼叫相關業務被訂閱信息的事件包；通知者，用于接收所述事件包，向所述訂閱者發送攜帶所述業務應用信息的通知消息。
20.根據權利要求19所述的在呼叫時進行業務訂閱的系統，其特征在于所述事件包通過會話發起協議頭域攜帶，該頭域是事件頭域或新擴展頭域。
21.根據權利要求19或20所述的在呼叫時進行業務訂閱的系統，其特征在于所述非訂閱消息的會話發起協議會話消息為呼叫消息，包括會話發起協議邀請消息或會話發起協議即時消息。
22.根據權利要求19或20所述的在呼叫時進行業務訂閱的系統，其特征在于所述通知消息為會話發起協議通知消息、或會話發起協議發布消息、或會話發起協議響應碼消息。
23.根據權利要求22所述的在呼叫時進行業務訂閱的系統，其特征在于所述會話發起協議響應碼消息攜帶所述事件包。
24.根據權利要求21所述的在呼叫時進行業務訂閱的系統，其特征在于所述訂閱者為所述事件包對應的訂閱和所述呼叫創建一個對話，或分別創建不同的對話。
25.根據權利要求24所述的在呼叫時進行業務訂閱的系統，其特征在于若所述訂閱和所述呼叫被分別創建不同的對話，則在所述頭域中攜帶所述訂閱對應的對話參數。
26.根據權利要求21所述的在呼叫時進行業務訂閱的系統，其特征在于所述通知者為所述事件包創建對應的訂閱實例，或維護發布狀態。
27.根據權利要求21所述的在呼叫時進行業務訂閱的系統，其特征在于如果所述訂閱者不是所述呼叫消息的始發者，該訂閱者收到的通知消息是會話發起協議通知消息，則將該通知消息轉換成會話發起協議發布消息或會話發起協議響應碼消息，向所述呼叫消息的始發者發送；如果該通知消息是會話發起協議發布消息，則將該消息向所述呼叫消息的始發者轉發，或轉換成會話發起協議響應碼消息向所述呼叫消息的始發者發送。
28.根據權利要求21所述的在呼叫時進行業務訂閱的系統，其特征在于所述呼叫消息中指示所述訂閱者是否為所述事件包創建訂閱實例。
全文摘要
一種在呼叫時進行業務訂閱的方法，在以SIP協議提供業務的網絡中，用戶終端或網絡在用戶終端發起的非訂閱消息的SIP會話消息中，通過一個頭域攜帶一個或一個以上、表示與當前所述SIP會話相關業務被訂閱信息的事件包；業務的業務控制節點接收所述事件包，進行相應的業務處理，若允許用戶終端對所述業務的訂閱申請，則在條件滿足時，發送包含業務應用相關信息的通知消息。本發明克服了現有技術通過SIP INVITE消息攜帶一個獨立頭域來指示在呼叫發起時申請的業務信息，會使SIP協議變得不可控、實現流程不統一以及帶來資源浪費的缺點，使訂閱流程仍沿用SIP協議的現有機制，并使業務應用結果向用戶透明，增加用戶的業務體驗性。
文檔編號H04W8/18GK1976529SQ20061010090
公開日2007年6月6日 申請日期2006年7月26日 優先權日2005年11月29日
發明者施有鑄, 王嘯 申請人:華為技術有限公司