摘要： 會話啟動協定研究工作組提出3種協定功能擴充方式：方法擴充、頭部擴充和消息體擴充。文章深入探讨了包含這3種擴充方法的事件通告機制，給出了基于這一機制的自動回叫業務執行個體，并讨論了該機制的安全性。
關鍵詞： 會話啟動協定；事件通告機制；IP通信網協定；增值業務
Abstract: IETF SIPPING (Session Initiation Protocol Investigation) working group has proposed 3 approaches to extend the base functions of SIP: method extension, header extension and body extension. The article goes deeply into the SIP event notification mechanism involving these three approaches. An example is given to illustrate the automatic "call-back" service based on this mechanism. Considerations on the security of the mechanism are also included.
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.