| sip中的subscribe和notify擴充應用技術 會話發起協定研究工作組提出3種協定功能擴充方式：方法擴充、頭部擴充和消息體擴充。文章深入探讨了包含這3種擴充方法的事件通告機制，給出了基于這一機制的自動回叫業務執行個體，并讨論了該機制的安全性。 摘要：會話啟動協定研究工作組提出3種協定功能擴充方式：方法擴充、頭部擴充和消息體 擴充。文章深入探讨了包含這3種擴充方法的事件通告機制，給出了基于這一機制的自動回 叫業務執行個體，并讨論了該機制的安全性。 關鍵詞：會話啟動協定；事件通告機制；IP通信網協定；增值業務 Key words:SIP; event notification mechanism; IP communication network protocol; value-added service 衆所周知，會話啟動協定(SIP)是建立、修改和終結多媒體會話或呼叫的應用層控制協定。 自1999年至今，會話啟動協定基礎協定已從最初的RFC 2543發展到了現在的RFC 3261， 協定内容得到了很大的擴充，其描述的信令架構也更加完善。随着會話啟動協定被第3代移動 通信合作計劃和微軟公司正式采用，人們已不再滿足于使用會話啟動協定完成基本的呼叫控制 ，更多的是關注如何利用會話啟動協定靈活實作增值業務。在此背景下，會話啟動協定研究工 作組提出了3種會話啟動協定功能擴充方式：消息(方法)擴充、頭部擴充和消息體擴充。本文 讨論的異步請求事件通告機制就是由上述3種擴充方式構成的，可以應用于如自動回叫、在席 、代答等多種富有市場前景的增值業務，是有代表性的會話啟動協定功能擴充技術，展現了會 話啟動協定實作增值業務的基本思路和方法。 1 基于會話啟動協定的事件通告機制 1.1 事件通告機制的概念 所謂事件通告機制是指網絡中的一些實體可以訂閱網絡中某些資源或呼叫的狀态資訊， 當那些被訂閱的資源的狀态發生改變時，負責這一資源的網絡實體将向訂閱者發送通告 ，通報目前資源狀态的變化情況。 為了實作這一機制，網際網路工程任務組(IETF)的SIP工作組對基本的會話啟動協定進行了擴充 ，提出了基于會話啟動協定的事件通告機制規範：RFC 3265[1]。 在規範中定義了兩個擴充方法 ：訂閱(SUBSCRIBE)和通告(NOTIFY)。SUBSCRIBE方法用于發起訂閱請求，NOTIFY方法用于通告 目前資源狀态。 會話啟動協定事件通告機制涉及以下幾個概念： (1)訂閱者 訂閱者負責接收NOTIFY消息的會話啟動協定使用者代理(SIP UA)[2]。這些NOTIFY消息中包含訂 閱者訂閱的資源資訊。訂閱者典型的動作是向通告者發送SUBSCRIBE消息以請求建立一次訂閱 關系。 (2)通告者 通告者負責産生NOTIFY請求的SIP UA。通告者在NOTIFY消息中向訂閱者回饋目前資源的狀 态。通告者典型的動作是接收SUBSCRIBE消息并建立相應的訂閱關系。 (3)訂閱 所謂訂閱就是一組與某個對話相關聯的應用狀态的集合。訂閱關系既存在于訂閱者中，又存 在于通告者中。 (4)事件包 事件包是通告者向訂閱者發送的一組資源的狀态資訊。RFC 3265中給出了抽象的事件包模闆 定義，對應具體業務可定義相應的事件包類型，例如：在席事件包、對話事件包等，這些事 件包可使用不同的文法并具有各自的語義。這種架構賦予會話啟動協定事件通告機制極大的生 命力和靈活性，有助于快速提供新的業務。 1.2 事件通告機制的流程 典型的會話啟動協定事件通告機制流程如圖1所示。 SUBSCRIBE方法和會話啟動協定基本規範[3-4]中定義的邀請(INVITE)方法都可以建立一個 對話。當訂閱者想得到網絡中某一資源的狀态時，便向負責這一資源的會話啟動協定實體發 起SUBSCRIBE請求，如圖1中的F1所示。SUBSCRIBE消息中的請求統一資源辨別符 (Request-URI)就是所要請求的資源的統一資源辨別符(URI)，這一URI同時還為會話啟動協 議代理伺服器路由請求提供線索。SUBSCRIBE請求中必須包含一個擴充的Event頭部，其中 注明要訂閱的事件類型，即事件包标記，如，dialog(用于代答業務)、refer(用于呼叫轉交) 等。還可包含擴充的Allowed-Event頭部，訓示本節點能夠支援的事件包類型。如果在一個對 話中有多次訂閱，則如圖2所示，在Event頭部還要增設辨別參數id予以區分。 對于訂閱者來說，它總是在一定的時間段内對它感興趣的某一資源進行觀察，是以，SUBSCRIBE 消息中應包含expires頭部，這一頭部值表明訂閱者期望的有效訂閱時長。為了延長某一訂閱 的時間，訂閱者可以在有效期内再次發送SUBSCRIBE消息來重新整理這一訂閱。具體某次訂閱的有 效時長，最終是由對SUBSCRIBE請求的2XX響應中的expires頭部值或NOTIFY消息中的 Subscription-State頭部的expires參數決定的。expires頭部值等于0的SUBSCRIBE請求表 示撤消訂閱。如果訂閱關系能夠建立，SUBSCRIBE消息将會觸發通告資源狀态的NOTIFY消息立 即回送。訂閱者想要獲得的資源狀态資訊封裝在後繼通告消息NOTIFY的消息體中，為了能夠正 确地解釋這部分資訊，訂閱者應該向通告者指明自己支援的消息體格式，是以，在SUBSCRIBE 消息中應攜帶Accept頭部，比如：Accept: application/dialog-info+xml，這表明訂閱者支 持用可擴充辨別語言(XML)描述的對話事件包[5]，實際上就是一種通用Internet郵件擴充 (MIME)格式消息體。如果SUBSCRIBE消息中沒有攜帶Accept頭部，則通告者根據SUBSCRIBE 消息中Event頭部指明的事件包标記選擇預設的格式傳送資源狀态資訊。 SUBSCRIBE請求通過2XX響應确認，如圖1中的F2所示。不同的2XX響應具有不同的語義： (1)200 OK表示訂閱已被接受且使用者已被授權訂閱請求的資源。 (2)202 Accepted(接受)是事件通知機制擴充的響應碼，表示訂閱請求已被了解，但是否授 權給訂閱者未确定。 2XX響應中必須包含expires頭部，這個值指明通告者确定的此次訂閱的有效時長，且必須 滿足：expires 200 OK <= expires SUBSCRIBE，即禁止通告者延長訂閱時長。如果傳回非2XX 響應，則表示訂閱失敗，将沒有後繼的NOTIFY消息。 通告者收到SUBSCRIBE請求時，首先判定是否了解消息中的Event頭部，如果不了解，則通告者 傳回擴充的“489 Bad Event”(錯誤事件)響應。通告者還會檢查消息中的expires頭部，如果其 值滿足：(0 < expires SUBSCRIBE < 1 hour) && ( 0 < expires SUBSCRIBE < Min 通告者- config)，其中，Min通告者- config為通告者最小配置訂閱時長，則通告者向 訂閱者傳回“423 Interval too small”(時間間隔太短)響應，表示提出的訂閱時長太短。 此外，通告者還應根據本地政策對提出SUBSCRIBE請求的使用者進行鑒權。 與訂閱相關的資訊由NOTIFY消息傳送。通告者在成功建立訂閱關系後，必須立即發送NOTIFY 消息，向訂閱者通告目前訂閱資源的狀态，如圖1中的F3所示。通告者使用SUBSCRIBE消息中 Accept頭部明确允許的或者Event頭部隐含指明的消息體格式将資源的狀态資訊或指向該資源 狀态的URI封裝在消息中。消息也可包含擴充的Allowed-Events頭部，訓示本節點能夠支援的 事件包類型。NOTIFY消息中必須包含擴充的Subscription-State頭部，訓示建立的訂閱的狀 态。共有3種訂閱狀态，分别是： (1)active：訂閱已被接受且授權成功。 (2)pending：SUBSCRIBE請求已收到，但還沒有足夠的資訊決定接受或拒絕此次訂閱。 (3)terminated：訂閱未激活，或建立的訂閱關系終止。 對應active狀态或peding狀态，該頭部還帶有expires參數訓示此次訂閱的有效時長。 對應terminated狀态，該頭部應包含reason參數訓示訂閱被終止的原因，或者包含 Retry-After參數，訓示訂閱者過一段時間後重新發起訂閱請求。 訂閱者收到通告者NOTIFY請求後，将進行比對檢查。 如果找到相應的比對，且NOTIFY消息中的Subscription-State頭部訓示的訂閱狀态是 active或pending，訂閱者建立新的訂閱或對話，并對NOTIFY請求回送200 OK響應， 如圖1中的F4所示。如果比對失敗，則發送“481 Subscription does not exist” (訂閱不存在)響應。 在訂閱有效期内，如果資源狀态發生變化，則通告者使用NOTIFY請求及時将變化資訊通告 訂閱者，如圖1中的F5和F6所示。 擴充的SUBSCRIBE方法和基本的INVITE方法都可以建立對話。在某一對話中，SUBSCRIBE請求 将建立和該對話關聯的訂閱，而該對話有可能是由INVITE建立起來的。是以，如果訂閱終止， 且目前無其他應用狀态(如由INVITE請求建立起來的應用狀态)和該對話關聯，則該對話結束 。如果仍有訂閱和該對話關聯，雖然其他的應用狀态已結束，但該對話并沒有結束。換句話說 ，由INVITE建立的對話并不會因為收到或發送了再見請求而結束，因為仍有訂閱關系和此對 話相關聯。與此類似，當多個訂閱和同一對話關聯時，必須當與此對話相關聯的所有訂閱都結 束時，該對話才結束。這一概念非常類似于程式設計裡對檔案描述符的引用，其中檔案描述符 相當于對話，對檔案描述符引用的程序相當于建立的訂閱關系。 SUBSCRIBE請求可以觸發通告者對其資源狀态的立即回送，是以，訂閱者可以利用這一特性實作 對資源狀态的輪詢。當訂閱處于激活狀态時，訂閱者在SUBSCRIBE請求的expires頭部寫入當 前剩下的訂閱有效時長的秒數，這樣，能夠立即觸發通告者産生NOTIFY消息，将目前資源的狀 态通告給訂閱者。需要指出的是，這種對資源的輪詢會導緻網絡、通告者和訂閱者負荷的增加。 在如移動通信這樣的特定應用中，訂閱者一般是資料處理能力較慢、需要額外供電的移動終端 裝置，随着事件通告頻度的增加和通告事件包的增大，将消耗很多寶貴的帶寬資源，造成網絡擁 塞和訂閱者的過載。是以，訂閱者需要對通告者的狀态通告頻率作出限制[6]。另外，訂閱者還 可以在SUBSCRIBE消息中指定一些事件包的過濾規則，使得通告者能夠根據這一過濾規則産生 通告事件，而不是任何狀态發生變化時都發起通告。 一般說來，訂閱者使用SUBSCRIBE請求建立一次訂閱，稱為顯式訂閱建立，與此相對應的還有 一種隐式的訂閱建立，即訂閱者不是通過SUBSCRIBE請求來建立訂閱。而是通過轉交(REFER)方法 [3]，一種由RFC 3515定義的用于實作呼叫轉交等業務的方法。REFER請求隐式地在被轉交使用者 處建立訂閱，所要觀察的資源是轉交請求的狀态。 2 自動回叫業務示例 如前所述，會話啟動協定的事件通告機制非常靈活，針對不同的應用可以定義不同的事件包，事 件包被封裝在NOTIFY消息中通告資源狀态，這一機制為實作各種功能強大的業務提供了堅實的 基礎。現給出使用這一機制實作的自動回叫業務流程。 (1)業務描述 使用者Ａ呼叫使用者B，而B正在會話，A希望B在通話結束後能夠立刻通知他，這樣A就能夠及時 地和B建立會話了。這裡，A使用事件通告機制來擷取B的會話狀态。 (2)業務流程 如圖3所示，使用者A向使用者B發起呼叫請求INVITE(F1)，此時B正在通話，是以傳回“486 Busy Here”(現在正忙)響應(F2)。A希望B能夠在通話結束後通知他，于是A向B發起SUBSCRIBE 請求(F4)，其Event頭部指明事件類型為dialog，即訂閱B正在進行中的對話狀态；Accept頭 部指明A支援使用XML語言封裝的dialog事件包。SUBSCRIBE的消息片斷如下： SUBSCRIBE sip: [email protected] SIP/2.0 …… Event: dialog Accept: application/dialog-info+xml …… B的通告者根據本地政策對A進行鑒權後授權A訂閱這一資源，傳回200 OK(F5)，并立即回送 通告目前對話狀态的NOTIFY消息。當B結束通話時，A訂閱的對話資源狀态發生了變化，從确 認狀态遷移至了終結狀态，B的通告者生成NOTIFY消息，向A通告目前B的對話狀态(F8)。A 得到這一資訊後，立即向B發起INVITE請求，與B建立新的會話。 3 事件通告機制的安全性考慮 (1)接納控制 在事件通告機制中，通告者需要将資源的狀态資訊通告給訂閱者，然而在通告的事件包中，有 些資訊對于使用者來說是敏感的或者是隐私，是以，通告者應能夠根據訂閱者的身份，選擇性地 拒絕某些使用者的訂閱請求，并使用标準的會話啟動協定鑒權機制[2]對使用者進行鑒權。訂閱請求 的最終決定權應該由使用者(自然人)作出。 (2)通告者的政策安全 在某些情況下，對SUBSCRIBE請求回應200 OK或4XX、6XX響應可能會導緻通告者某些敏感政策 資訊的洩漏。是以，在這些情況下，通告者應總是對SUBSCRIBE請求回送202 Accepted響應。 後繼的NOTIFY中可能并不攜帶真正的資源狀态，但從訂閱者的角度來看，這并無任何異常。例 如，在“在席”應用中，使用者A向使用者B發送SUBSCRIBE請求擷取使用者B是否在席的資訊，B在 席，但他拒絕了A的訂閱請求，因為B并不想讓A知道他正在網上。如果B直接使用4XX或6XX 響應拒絕，則會洩漏B的政策。為此，B可對SUBSCRIBE回送202 Acceptted響應，在随後的 NOTIFY消息的Subscription-State頭部指明訂閱終結，原因為沒有資源，即A想訂閱的資源不 存在，其Subscription-State頭部為：Subscription-State：terminated； reason=noresource，這樣既拒絕訂閱請求又不會暴露通告者的政策資訊。 (3)防止惡意攻擊 随着事件通告機制的進一步應用，要逐漸考慮應對各種Internet上慣用的惡意攻擊。比如， 拒絕服務(DoS)攻擊，在目前的基于會話啟動協定的事件通告模型中，一個SUBSCRIBE請求将觸 發一個或多個通告資源狀态的NOTIFY消息，通告者接收到SUBSCRIBE請求，要建立相應的狀态 ，消耗一定的系統資源。有惡意的訂閱者會利用這一點發起過多的訂閱請求，就有可能使通告者 因建立過多的訂閱而資源耗盡。為了減少這種攻擊的機會，通告者的實作必須包含鑒權，以過濾 惡意的訂閱請求。 4 結束語 IETF通過引入SUBSCRIBE和NOTIFY兩個擴充方法，Event、Allowed-Events和 Subscription-State 3個擴充頭部，并在定義事件包引入必要的擴充消息體，形成了會 話啟動協定事件通知機制，基于此機制可以靈活地實作許多新的增值業務。 5 參考文獻 [1] IETF RFC 3265. Session Initiation Protocol SIP Specific Event Notification [S]. [2] IETF RFC 3261. SIP: Session Initiation Protocol [S]. [3] IETF RFC 3515. The Session Initiation Protocol (SIP) Refer Method [S]. [4] Alan Johnston. Session Initiation Protocol Service Examples [EB/OL]． http://www1.ietf.org/mail-archive/working-groups/sip-ping/current/msg04068.html. [5] Jonathan Rosenberg. An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP) [EB/OL]. http://www1.ietf.org/mail-archive/ietf-announce/current/msg23154.html. [6] Niemi A. Requirements for Limiting the Rate of Event Notifications [EB/OL]. http://www1.ietf.org/mail-archive/ietf-announce/current/msg23061.html. |