專利名稱：一種會話發(fā)起協(xié)議資源事件包獲取方法
技術領域：
本發(fā)明涉及通信技術領域，尤其涉及一種會話發(fā)起協(xié)議(SIP)資源事件包獲取方法。
背景技術：
SIP(Session Initiation Protocol，即會話發(fā)起協(xié)議)是IETF(The InternetEngineering Task Force，即Internet工程任務組)制定的多媒體通信系統(tǒng)框架協(xié)議之一，它是一個基于文本的應用層控制協(xié)議，獨立于底層協(xié)議，用于建立、修改和終止IP網(wǎng)上的雙方或多方多媒體會話。SIP實現(xiàn)了事件通知框架，引入了SUBSCRIBE(訂閱)和NOTIFY(通知)方法，SUBSCRIBE方法用于訂閱，而NOTIFY方法用于傳遞一個事件的任何變化的通知。所謂事件通知就是，一個用戶或資源向其它資源發(fā)起訂閱，由于后者有前者感興趣的事件，之后前者會接收到有關該事件的狀態(tài)和任何變化的通知。如圖1所示為SIP事件訂閱處理流程，標準流程如下(1)、Subscriber(訂閱者)向Notifier(通知者，即資源的擁有者)發(fā)送一個訂閱(SUBSCRIBE)消息，請求訂閱感興趣的資源狀態(tài)；(2)Notifier允許Subscriber訂閱，向Subscriber發(fā)送一個200 OK響應確認，在Subscriber和Notifier間建立一個訂閱的dialog和訂閱實例；dialog也就是對話，是通信雙方之間的一種SIP關系，它提供了在通信雙方之間進行路由和消息排序時所依據(jù)的必要的狀態(tài)信息；(3)Notifier向Subscriber發(fā)送一個NOTIFY(通知)消息，在NOTIFY消息的消息體中攜帶Subscriber訂閱的資源狀態(tài)；
(4)Subscriber收到NOTIFY消息后，向Notifier發(fā)送一個200 OK響應，表示成功接收了NOTIFY消息。
由上述訂閱的流程可知，標準的訂閱流程(見RFC3265)，是由Subscriber(對于用戶終端來說就是UA)發(fā)出訂閱請求，Notifier(通常是Event Server，作為訂閱服務器)接收Subscriber的訂閱請求，并向Subscriber發(fā)送NOTIFY消息。訂閱會在訂閱者和通知者間建立一個訂閱的dialog，并且還需要訂閱者和通知者創(chuàng)建訂閱的實例。
SIP擴展協(xié)議RFC3903定義了狀態(tài)發(fā)布機制，定義了客戶端向狀態(tài)代理發(fā)布事件狀態(tài)，這是通過PUBLISH(發(fā)布)方法來實現(xiàn)的。狀態(tài)發(fā)布機制與事件訂閱機制使用相同定義的Event(事件)消息頭和消息包格式來指示事件的狀態(tài)。不同的是，狀態(tài)發(fā)布機制不需要創(chuàng)建dialog。
本文中的Event Server，即事件服務器，具有訂閱服務器功能和事件發(fā)布服務器功能，也可單獨具有訂閱服務器功能，或事件發(fā)布服務器功能。
在實際的應用中，用戶SIP終端啟動時，需要同時向服務器發(fā)出多個訂閱請求，會在用戶端產(chǎn)生多個訂閱事務，這樣會加大用戶終端的負擔，延遲啟動過程，于是出現(xiàn)了一種將注冊和訂閱關聯(lián)的技術方案，該方案在注冊消息中攜帶訂閱的事件包列表，在注冊的同時進行訂閱，不需要用戶終端單獨的向服務器發(fā)送訂閱請求，減少終端啟動時消息交互的數(shù)量，參見IETF的Draft文稿“draft-rosenberg-sipping-reg-sub-00.txt”。
現(xiàn)有的將注冊和訂閱關聯(lián)的技術方案有如下三種實現(xiàn)方法1、現(xiàn)有技術一如圖2所示，現(xiàn)有技術一的這種技術方案所采用的方法是將注冊和訂閱關聯(lián)，通過UA(用戶終端)在注冊消息中攜帶一個Subscription(訂閱)頭域，該頭域包括了一個UA希望訂閱的事件包的列表。在Registrar(注冊服務器)返回的200 OK中攜帶Subscription頭域，指示UA被允許訂閱的事件包，并在UA和Registrar間建立一個訂閱的dialog。Event Server作為一個事件發(fā)布服務器，將資源的最新狀態(tài)通過PUBLISH方法發(fā)布給Registrar。Registrar通過NOTIFY消息將UA訂閱的資源狀態(tài)發(fā)送給UA。
如圖3所示，該技術方案的實現(xiàn)流程如下步驟(1)-(2)UA通過注冊消息攜帶關聯(lián)的訂閱事件包向Registrar發(fā)起注冊，Registrar向UA發(fā)送一個200 OK響應；步驟(3)-(4)Event Server作為一個事件發(fā)布服務器，通過PUBLISH消息將Event Server上維護的資源的最新狀態(tài)發(fā)布給Registrar，Registrar回送一個200 OK響應；步驟(5)-(6)Registrar上需要維護同Event Server相同的資源，并根據(jù)資源狀態(tài)的變化構造NOTIFY消息發(fā)送給UA，并且UA與Registrar間需要建立訂閱的dialog和訂閱實例，UA向Registrar回送一個200 OK響應。
上述現(xiàn)有技術一存在以下缺點(1)Event Server通過發(fā)布機制向Registrar通知資源的狀態(tài)，將會導致多余的資源狀態(tài)也被發(fā)布處理，占用網(wǎng)絡帶寬和Registrar的處理存儲能力，造成資源浪費；(2)UA與Registrar間需要建立和維護訂閱的dialog和訂閱的實例，但dialog和訂閱的實例的建立不符合已有的標準(見RFC3265或圖1的流程描述)，需要擴展已有的標準的操作方式；2、現(xiàn)有技術二如圖4所示，現(xiàn)有技術二實現(xiàn)流程如下步驟(1)-(4)Event Server向Registrar訂閱UA的注冊事件包；步驟(5)-(6)當UA攜帶關聯(lián)的訂閱事件包向Registrar注冊；步驟(7)-(8)Registrar通過NOTIFY消息通知Event Server UA注冊，并在NOTIFY消息中攜帶UA訂閱的相關信息；步驟(9)-(10)Event Server作為訂閱服務器直接向UA發(fā)送NOTIFY消息，并在UA與Event Server間建立和維護訂閱的dialog和訂閱的實例。
現(xiàn)有技術二的缺點如下(1)該流程需要在UA與Event Server間建立訂閱的dialog和訂閱的實例，如果UA關聯(lián)注冊的訂閱是多個事件包，UA將與多個Event Server間建立訂閱的dialog和訂閱的實例，UA在維護訂閱dialog和訂閱實例的開銷比現(xiàn)有技術一還大；(2)、UA與Event Server之間建立的訂閱也是不符合已有的標準(見RFC3265或圖1的流程描述)，需要擴展已有的標準的操作方式。
3、現(xiàn)有技術三現(xiàn)有技術三實現(xiàn)流程如下步驟(1)-(4)Event Server向Registrar訂閱UA的注冊事件包；步驟(5)-(6)UA攜帶關聯(lián)的訂閱事件包向Registrar注冊；步驟(7)-(8)Registrar通過NOTIFY消息通知Event Server UA注冊，并在NOTIFY消息中攜帶UA訂閱的相關信息；步驟(9)-(10)Event Server作為事件發(fā)布服務器，通過PUBLISH消息將UA訂閱的資源的最新狀態(tài)發(fā)送給Registrar；步驟(11)-(12)Registrar與UA之間建立訂閱的dialog和訂閱實例，通過NOTIFY消息通知UA。
現(xiàn)有技術三的缺點是UA與Registrar間需要建立和維護訂閱的dialog和訂閱的實例，且dialog和訂閱的實例的建立不符合已有的標準(見RFC3265或圖1的流程描述)，需要擴展已有的標準的操作方式。
通過上述分析，可以發(fā)現(xiàn)現(xiàn)有技術方案存在兩個共同的缺點1、在UA與Registrar或Event Server間需要建立訂閱關系，維護訂閱dialog和訂閱實例，增加了UA的開銷；2、通過這種關聯(lián)注冊的訂閱方式不符合已有的訂閱協(xié)議的標準，需要擴展已有的標準的操作方式。

發(fā)明內容
本發(fā)明所要解決的技術問題是克服現(xiàn)有技術在注冊的同時進行訂閱，需要更改已有的訂閱方式，且UA需要維護訂閱dialog和訂閱實例，UA開銷大的缺點，提供一種會話發(fā)起協(xié)議資源事件包獲取方法，減小UA開銷，并使操作方式符合標準規(guī)定。
本發(fā)明為解決上述技術問題所采用的技術方案為這種會話發(fā)起協(xié)議資源事件包獲取方法，包括以下步驟用戶終端發(fā)起關聯(lián)發(fā)布的注冊消息，在注冊消息中攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包；注冊服務器或事件服務器使用發(fā)布方式向所述用戶終端發(fā)送發(fā)布消息，攜帶所述用戶終端注冊時希望獲取的資源信息的事件包。
可以在所述注冊消息中通過頭域或消息體攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包。
所述的頭域可以為事件頭域，或者新擴展一個由所述會話發(fā)起協(xié)議的注冊消息攜帶的頭域，使其能攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包。
所述用戶終端向所述的注冊服務器發(fā)起關聯(lián)發(fā)布的注冊消息，所述的注冊服務器可以采用訂閱方式從事件服務器獲取資源信息，注冊服務器再使用發(fā)布方式向所述用戶終端發(fā)送發(fā)布消息。
所述注冊服務器采用訂閱方式從事件服務器獲取資源信息時，向事件服務器發(fā)送訂閱消息，事件服務器向所述注冊服務器發(fā)送通知消息通知所訂閱的資源信息，所述的注冊服務器再將接收到的通知消息轉換成發(fā)布消息發(fā)送到所述的用戶終端。
所述用戶終端向所述的注冊服務器發(fā)起關聯(lián)發(fā)布的注冊消息，所述的注冊服務器可以將所述注冊消息中關聯(lián)發(fā)布的事件包取出，通過通知消息通知提供相關資源服務的事件服務器；事件服務器收到通知消息后，通過發(fā)布方式直接將用戶終端訂閱的資源信息發(fā)布給用戶終端。
所述事件服務器也可以通過發(fā)布方式向所述注冊服務器通知資源信息，用戶終端發(fā)起關聯(lián)發(fā)布的注冊請求到所述注冊服務器，所述注冊服務器通過發(fā)布消息將所述用戶終端訂閱的資源信息發(fā)送給該用戶終端。
本發(fā)明的有益效果為本發(fā)明提供了一種會話發(fā)起協(xié)議資源事件包獲取方法，能克服現(xiàn)有技術進行SIP訂閱時，需要更改已有的訂閱方式，且UA需要維護訂閱dialog和訂閱實例，UA開銷大的缺點，不但減小了UA開銷，而且使資源事件包獲取操作方式符合標準規(guī)定。
本發(fā)明使UA與Registrar或Event Server通過PUBLISH機制交互用戶訂閱的資源，使UA不用建立維護訂閱dialog和訂閱實例，減輕了UA對大量訂閱和dialog狀態(tài)的維護和管理開銷；且Registrar通過向Event Server訂閱方式的獲取UA需要的資源，該方式使Registrar根據(jù)UA需求獲取資源，減少了大量不必要的資源的處理和網(wǎng)絡帶寬的浪費；并且Registrar與Event Server間只需建立一個訂閱dialog，節(jié)省了Event Server大量的dialog資源的維護和管理的開銷。且該方式符合協(xié)議，不用修改現(xiàn)有的訂閱操作方式。


圖1為SIP事件訂閱處理流程；圖2為現(xiàn)有技術一訂閱處理模型示意圖；圖3為現(xiàn)有技術一訂閱處理流程圖；圖4為現(xiàn)有技術二訂閱處理流程圖；圖5為現(xiàn)有技術三訂閱處理流程圖；圖6為本發(fā)明訂閱處理方案一模型示意圖；圖7為本發(fā)明訂閱處理方案一流程圖；圖8為本發(fā)明訂閱處理方案二模型示意圖；
圖9為本發(fā)明訂閱處理方案三模型示意圖。
具體實施例方式
下面根據(jù)附圖和實施例對本發(fā)明作進一步詳細說明本發(fā)明提供一種會話發(fā)起協(xié)議資源事件包獲取方法，使UA在注冊時獲得希望的資源，不需要維護訂閱dialog和訂閱實例，并且與現(xiàn)有的協(xié)議標準相符合。
如圖6和圖7所示，在本發(fā)明的模型中，UA與Registrar的接口采用PUBLISH機制；Registrar通過SUBSCRIBE(訂閱)機制從Event Server獲取資源狀態(tài)。而現(xiàn)有技術方案中，UA與Registrar的接口采用SUBSCRIBE(訂閱)機制；Event Server通過PUBLISH機制向Registrar發(fā)布資源狀態(tài)，或EventServer直接通過非標準的SUBSCRIBE(訂閱)機制向UA通知資源狀態(tài)，或采用SUBSCRIBE(訂閱)機制和PUBLISH機制混合的方式向Registrar提供資源狀態(tài)。
本發(fā)明新擴展一個由SIP的REGISTER消息攜帶的頭域，用于傳遞UA在注冊時希望通過PUBLISH機制獲取資源的事件包的列表，比如命名為Pub-Reg，參照SIP協(xié)議中Event頭域的定義格式，Pub-Reg定義如下Pub-Reg＝(″Pub-Reg″)HCOLON(pub-event*(COMMA pub-event))Pub-event ＝event-type*(SEMI pub-event-param)event-type ＝event-package*(″.″event-template)event-package ＝token-nodotevent-template ＝token-nodottoken-nodot＝1*(alphanum/″-″/″！″/″％″/″*″/″_″/″+″/″`″/″/″～″)pub-event-param＝pub-aor/generic-parampub-aor＝″aor″EQUAL(SIP-URI/SIPS-URI)
其中，Pub-event表示Pub-Reg頭域中傳遞的希望通過PUBLISH機制獲取的事件包，它包含了事件包類型event-type和參數(shù)pub-event-param，而event-type的定義和Event頭域中的完全相同，本發(fā)明不再詳細解釋，pub-event-param包含的pub-aor表示事件包發(fā)送的目的AOR(Address-of-Record)，generic-param的定義與Event頭域中的完全相同，這里不再解釋。
可以看出，和Event頭域定義不一樣的地方是，Pub-Reg頭域中可以傳遞多個資源信息的事件包。當然也可以采用Event頭域傳遞UA在注冊時希望通過PUBLISH機制獲取資源的事件包，但這樣無法傳遞多個事件包。
同時，作為一種可選的方案，也可以通過注冊消息的消息體攜帶，用于傳遞UA在注冊時希望通過PUBLISH機制獲取資源的事件包的列表。攜該事件包列表的消息體的編碼方式可以采用文本方式或XML或其它已有的方式，本發(fā)明的實施例通過XML的編碼方式的消息體格式傳遞事件包的列表來說明，僅突出作為消息體傳遞事件包的列表的一種方案，并沒有窮盡所有可能的編碼方式，和不同的格式。
在本實施例中，假設UA關聯(lián)發(fā)布的事件包為UA的好友的呈現(xiàn)事件包，如圖7所述，處理流程如下(1)UA在注冊消息中攜帶Pub-Reg頭域發(fā)起關聯(lián)發(fā)布的注冊請求，aor是事件包請求的目的URI，事件包為presence；(2)Registrar收到注冊消息后，檢查發(fā)現(xiàn)注冊消息中帶有Pub-Reg頭域，從中取出相關信息，構造一個SUBSCRIBE請求向Event Server發(fā)起訂閱；(3)Event Server向Registrar返回200 OK表示訂閱成功；(4)Registrar向UA返回200 OK表示注冊成功，同時在200 OK中攜帶Pub-Reg頭域，其值是訂閱成功的事件包，在此為presence；(5)Event Server向Registrar發(fā)送NOTIFY消息通知Registrar訂閱的資源狀態(tài)；
(6)Registrar對Event Server發(fā)送200 OK確認接收的NOTIFY消息；(7)Registrar將接收到的NOTIFY消息轉換成PUBLISH消息發(fā)送到UA；(8)UA對PUBLISH消息回應200 OK表示確認。
如圖8所示，本發(fā)明也可以采用如下方案(1)UA發(fā)送關聯(lián)發(fā)布的注冊消息到Registrar；(2)Registrar將注冊消息中關聯(lián)的訂閱事件包取出，通過NOTIFY消息分別通知提供相關資源服務的Event Server；Event Server收到NOTIFY消息后，通過PUBLISH方式直接將UA訂閱的資源狀態(tài)發(fā)布給UA。
在上述實施例中，也可以采用XML的編碼方式通過注冊消息的消息體攜帶，用于傳遞UA在注冊時希望通過PUBLISH機制獲取資源的事件包的列表，可以采用如下的格式< xml version＝″1.0″encoding＝″UTF-8″ >
<pkglist xmlns＝″urn:ietf:params:xml:ns:pkg-list″xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>
<eventpkg name＝presence>
<aor>
sip:myfriend@pres.com</aor>
</eventpkg>
</pkglist>
如果用戶想通過該機制獲取多個資源的事件包，見下例< xml version＝″1.0″encoding＝″UTF-8″ >
<pkglist xmlns＝″urn:ietf:params:xml:ns:pkg-list″xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>
<eventpkg name＝presence>
<aor>
sip:myfriend@pres.com
</aor>
</eventpkg>
<eventpkg name＝presence>
<aor>
sip:example@example.server.com</aor>
</eventpkg>
<eventpkg name＝presence.winfo>
<aor>
sip:myfriend@pres.com</aor>
</eventpkg>
</pkglist>
在上述的XML編碼方式中，<pkglist>元素是事件包列表的根元素，其下包括多個事件包元素，<eventpkg>元素代表一個事件包，屬性“name”表示事件包名，子元素<aor>表示事件包發(fā)送的目的AOR(Address-of-Record)。為了支持這種格式的消息體，需增加一個Content-type的類型定義，為“application/pub-eventlist+xml”。
上述實施例中，UA與Registrar或Event Server通過PUBLISH機制交互用戶訂閱的資源，使UA不用建立維護訂閱dialog和訂閱實例，減輕了UA對大量訂閱和dialog狀態(tài)的維護和管理開銷；且Registrar通過向Event Server訂閱方式的獲取UA需要的資源，該方式使Registrar根據(jù)UA需求獲取資源，減少了大量不必要的資源的處理和網(wǎng)絡帶寬的浪費；并且Registrar與EventServer間只需建立一個訂閱dialog，節(jié)省了Event Server大量的dialog資源的維護和管理的開銷。且該方式符合協(xié)議，不用修改現(xiàn)有的訂閱操作方式。
上述實施例方案也可以將Event Server與Registrar的接口改為PUBLISH，如圖9所示，Event Server通過發(fā)布機制向Registrar通知資源的狀態(tài)；UA發(fā)起關聯(lián)發(fā)布的注冊請求到Registrar，Registrar通過PUBLISH消息將UA訂閱的資源狀態(tài)發(fā)送給UA。但這樣與前面的實施例相比，這種方案需要EventServer通過發(fā)布機制向Registrar通知資源的狀態(tài)，將會導致多余的資源狀態(tài)也被發(fā)布處理，占用網(wǎng)絡帶寬和Registrar的處理存儲能力，造成資源浪費。
本領域技術人員不脫離本發(fā)明的實質和精神，可以有多種變形方案實現(xiàn)本發(fā)明，以上所述僅為本發(fā)明較佳可行的實施例而已，并非因此局限本發(fā)明的權利范圍，凡運用本發(fā)明說明書及附圖內容所作的等效變化，均包含于本發(fā)明的權利范圍之內。
權利要求
1.一種會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于，包括以下步驟用戶終端發(fā)起關聯(lián)發(fā)布的注冊消息，在注冊消息中攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包；注冊服務器或事件服務器使用發(fā)布方式向所述用戶終端發(fā)送發(fā)布消息，攜帶所述用戶終端注冊時希望獲取的資源信息的事件包。
2.根據(jù)權利要求1所述的會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于在所述注冊消息中通過頭域或消息體攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包。
3.根據(jù)權利要求2所述的會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于所述的頭域為事件頭域，或者新擴展一個由所述會話發(fā)起協(xié)議的注冊消息攜帶的頭域，使其能攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包。
4.根據(jù)權利要求1、2或3所述的會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于所述用戶終端向所述的注冊服務器發(fā)起關聯(lián)發(fā)布的注冊消息，所述的注冊服務器采用訂閱方式從事件服務器獲取資源信息，注冊服務器再使用發(fā)布方式向所述用戶終端發(fā)送發(fā)布消息。
5.根據(jù)權利要求4所述的會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于所述注冊服務器采用訂閱方式從事件服務器獲取資源信息時，向事件服務器發(fā)送訂閱消息，事件服務器向所述注冊服務器發(fā)送通知消息通知所訂閱的資源信息，所述的注冊服務器再將接收到的通知消息轉換成發(fā)布消息發(fā)送到所述的用戶終端。
6.根據(jù)權利要求1、2或3所述的會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于所述用戶終端向所述的注冊服務器發(fā)起關聯(lián)發(fā)布的注冊消息，所述的注冊服務器將所述注冊消息中關聯(lián)發(fā)布的事件包取出，通過通知消息通知提供相關資源服務的事件服務器；事件服務器收到通知消息后，通過發(fā)布方式直接將用戶終端訂閱的資源信息發(fā)布給用戶終端。
7.根據(jù)權利要求1、2或3所述的會話發(fā)起協(xié)議資源事件包獲取方法，其特征在于所述事件服務器通過發(fā)布方式向所述注冊服務器通知資源信息，用戶終端發(fā)起關聯(lián)發(fā)布的注冊請求到所述注冊服務器，所述注冊服務器通過發(fā)布消息將所述用戶終端訂閱的資源信息發(fā)送給該用戶終端。
全文摘要
一種會話發(fā)起協(xié)議資源事件包獲取方法，用戶終端發(fā)起關聯(lián)發(fā)布的注冊消息，在注冊消息中攜帶至少一個表示用戶終端希望通過發(fā)布方式獲得資源信息的事件包；注冊服務器或事件服務器使用發(fā)布方式向用戶終端發(fā)送發(fā)布消息，攜帶用戶終端注冊時希望獲取的資源信息的事件包?？梢栽谧韵⒅型ㄟ^頭域或消息體攜帶所述的事件包。本發(fā)明克服了現(xiàn)有技術在注冊的同時進行訂閱，需要更改已有的訂閱方式，且UA需要維護訂閱dialog和訂閱實例，UA開銷大的缺點，使UA不用建立維護訂閱dialog和訂閱實例，減輕了UA對大量訂閱和dialog狀態(tài)的維護和管理開銷，并使操作方式符合標準規(guī)定。
文檔編號H04L29/06GK1972279SQ20051010184
公開日2007年5月30日 申請日期2005年11月25日 優(yōu)先權日2005年11月25日
發(fā)明者王嘯 申請人:華為技術有限公司