摘要：會(huì)話啟動(dòng)協(xié)議研究工作組提出3種協(xié)議功能擴(kuò)展方式：方法擴(kuò)展、頭部擴(kuò)展和消息體擴(kuò)展。文章深入探討了包含這3種擴(kuò)展方法的事件通告機(jī)制，給出了基于這一機(jī)制的自動(dòng)回叫業(yè)務(wù)實(shí)例，并討論了該機(jī)制的安全性。
關(guān)鍵詞：會(huì)話啟動(dòng)協(xié)議；事件通告機(jī)制；IP通信網(wǎng)協(xié)議；增值業(yè)務(wù)
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
眾所周知，會(huì)話啟動(dòng)協(xié)議(SIP)是建立、修改和終結(jié)多媒體會(huì)話或呼叫的應(yīng)用層控制協(xié)議。自1999年至今，會(huì)話啟動(dòng)協(xié)議基礎(chǔ)協(xié)議已從最初的RFC 2543發(fā)展到了現(xiàn)在的RFC 3261，協(xié)議內(nèi)容得到了很大的擴(kuò)充，其描述的信令框架也更加完善。隨著會(huì)話啟動(dòng)協(xié)議被第3代移動(dòng)通信合作計(jì)劃和微軟公司正式采用，人們已不再滿足于使用會(huì)話啟動(dòng)協(xié)議完成基本的呼叫控制，更多的是關(guān)注如何利用會(huì)話啟動(dòng)協(xié)議靈活實(shí)現(xiàn)增值業(yè)務(wù)。在此背景下，會(huì)話啟動(dòng)協(xié)議研究工作組提出了3種會(huì)話啟動(dòng)協(xié)議功能擴(kuò)展方式：消息(方法)擴(kuò)展、頭部擴(kuò)展和消息體擴(kuò)展。本文討論的異步請求事件通告機(jī)制就是由上述3種擴(kuò)展方式構(gòu)成的，可以應(yīng)用于如自動(dòng)回叫、在席、代答等多種富有市場前景的增值業(yè)務(wù)，是有代表性的會(huì)話啟動(dòng)協(xié)議功能擴(kuò)展技術(shù)，體現(xiàn)了會(huì)話啟動(dòng)協(xié)議實(shí)現(xiàn)增值業(yè)務(wù)的基本思路和方法。
1 基于會(huì)話啟動(dòng)協(xié)議的事件通告機(jī)制
1.1 事件通告機(jī)制的概念
所謂事件通告機(jī)制是指網(wǎng)絡(luò)中的一些實(shí)體可以訂閱網(wǎng)絡(luò)中某些資源或呼叫的狀態(tài)信息，當(dāng)那些被訂閱的資源的狀態(tài)發(fā)生改變時(shí)，負(fù)責(zé)這一資源的網(wǎng)絡(luò)實(shí)體將向訂閱者發(fā)送通告，通報(bào)當(dāng)前資源狀態(tài)的變化情況。
為了實(shí)現(xiàn)這一機(jī)制，因特網(wǎng)工程任務(wù)組(IETF)的SIP工作組對基本的會(huì)話啟動(dòng)協(xié)議進(jìn)行了擴(kuò)充，提出了基于會(huì)話啟動(dòng)協(xié)議的事件通告機(jī)制規(guī)范：RFC 3265[1]。 在規(guī)范中定義了兩個(gè)擴(kuò)展方法：訂閱(SUBSCRIBE)和通告(NOTIFY)。SUBSCRIBE方法用于發(fā)起訂閱請求，NOTIFY方法用于通告當(dāng)前資源狀態(tài)。
會(huì)話啟動(dòng)協(xié)議事件通告機(jī)制涉及以下幾個(gè)概念：
(1)訂閱者
訂閱者負(fù)責(zé)接收NOTIFY消息的會(huì)話啟動(dòng)協(xié)議用戶代理(SIP UA)[2]。這些NOTIFY消息中包含訂閱者訂閱的資源信息。訂閱者典型的動(dòng)作是向通告者發(fā)送SUBSCRIBE消息以請求創(chuàng)建一次訂閱關(guān)系。
(2)通告者
通告者負(fù)責(zé)產(chǎn)生NOTIFY請求的SIP UA。通告者在NOTIFY消息中向訂閱者回饋當(dāng)前資源的狀態(tài)。通告者典型的動(dòng)作是接收SUBSCRIBE消息并創(chuàng)建相應(yīng)的訂閱關(guān)系。
(3)訂閱
所謂訂閱就是一組與某個(gè)對話相關(guān)聯(lián)的應(yīng)用狀態(tài)的集合。訂閱關(guān)系既存在于訂閱者中，又存在于通告者中。
(4)事件包
事件包是通告者向訂閱者發(fā)送的一組資源的狀態(tài)信息。RFC 3265中給出了抽象的事件包模板定義，對應(yīng)具體業(yè)務(wù)可定義相應(yīng)的事件包類型，例如：在席事件包、對話事件包等，這些事件包可使用不同的語法并具有各自的語義。這種框架賦予會(huì)話啟動(dòng)協(xié)議事件通告機(jī)制極大的生命力和靈活性，有助于快速提供新的業(yè)務(wù)。
1.2 事件通告機(jī)制的流程
典型的會(huì)話啟動(dòng)協(xié)議事件通告機(jī)制流程如圖1所示。
SUBSCRIBE方法和會(huì)話啟動(dòng)協(xié)議基本規(guī)范[3-4]中定義的邀請(INVITE)方法都可以創(chuàng)建一個(gè)對話。當(dāng)訂閱者想得到網(wǎng)絡(luò)中某一資源的狀態(tài)時(shí)，便向負(fù)責(zé)這一資源的會(huì)話啟動(dòng)協(xié)議實(shí)體發(fā)起SUBSCRIBE請求，如圖1中的F1所示。SUBSCRIBE消息中的請求統(tǒng)一資源標(biāo)識(shí)符(Request-URI)就是所要請求的資源的統(tǒng)一資源標(biāo)識(shí)符(URI)，這一URI同時(shí)還為會(huì)話啟動(dòng)協(xié)議代理服務(wù)器路由請求提供線索。SUBSCRIBE請求中必須包含一個(gè)擴(kuò)展的Event頭部，其中注明要訂閱的事件類型，即事件包標(biāo)記，如，dialog(用于代答業(yè)務(wù))、refer(用于呼叫轉(zhuǎn)交)等。還可包含擴(kuò)展的Allowed-Event頭部，指示本節(jié)點(diǎn)能夠支持的事件包類型。如果在一個(gè)對話中有多次訂閱，則如圖2所示，在Event頭部還要增設(shè)標(biāo)識(shí)參數(shù)id予以區(qū)分。
對于訂閱者來說，它總是在一定的時(shí)間段內(nèi)對它感興趣的某一資源進(jìn)行觀察，因此，SUBSCRIBE消息中應(yīng)包含expires頭部，這一頭部值表明訂閱者期望的有效訂閱時(shí)長。為了延長某一訂閱的時(shí)間，訂閱者可以在有效期內(nèi)再次發(fā)送SUBSCRIBE消息來刷新這一訂閱。具體某次訂閱的有效時(shí)長，最終是由對SUBSCRIBE請求的2XX響應(yīng)中的expires頭部值或NOTIFY消息中的Subscription-State頭部的expires參數(shù)決定的。expires頭部值等于0的SUBSCRIBE請求表示撤消訂閱。如果訂閱關(guān)系能夠建立，SUBSCRIBE消息將會(huì)觸發(fā)通告資源狀態(tài)的NOTIFY消息立即回送。訂閱者想要獲得的資源狀態(tài)信息封裝在后繼通告消息NOTIFY的消息體中，為了能夠正確地解釋這部分信息，訂閱者應(yīng)該向通告者指明自己支持的消息體格式，因此，在SUBSCRIBE消息中應(yīng)攜帶Accept頭部，比如：Accept: application/dialog-info+xml，這表明訂閱者支持用可擴(kuò)展標(biāo)識(shí)語言(XML)描述的對話事件包[5]，實(shí)際上就是一種通用Internet郵件擴(kuò)展(MIME)格式消息體。如果SUBSCRIBE消息中沒有攜帶Accept頭部，則通告者根據(jù)SUBSCRIBE消息中Event頭部指明的事件包標(biāo)記選擇默認(rèn)的格式傳送資源狀態(tài)信息。
SUBSCRIBE請求通過2XX響應(yīng)確認(rèn)，如圖1中的F2所示。不同的2XX響應(yīng)具有不同的語義：
(1)200 OK表示訂閱已被接受且用戶已被授權(quán)訂閱請求的資源。
(2)202 Accepted(接受)是事件通知機(jī)制擴(kuò)展的響應(yīng)碼，表示訂閱請求已被理解，但是否授權(quán)給訂閱者未確定。
2XX響應(yīng)中必須包含expires頭部，這個(gè)值指明通告者確定的此次訂閱的有效時(shí)長，且必須滿足：expires 200 OK <= expires SUBSCRIBE，即禁止通告者延長訂閱時(shí)長。如果返回非2XX響應(yīng)，則表示訂閱失敗，將沒有后繼的NOTIFY消息。
通告者收到SUBSCRIBE請求時(shí)，首先判定是否理解消息中的Event頭部，如果不理解，則通告者返回?cái)U(kuò)展的“489 Bad Event”(錯(cuò)誤事件)響應(yīng)。通告者還會(huì)檢查消息中的expires頭部，如果其值滿足：(0 < expires SUBSCRIBE < 1 hour) && ( 0 < expires SUBSCRIBE < Min 通告者- config)，其中，Min通告者- config為通告者最小配置訂閱時(shí)長，則通告者向訂閱者返回“423 Interval too small”(時(shí)間間隔太短)響應(yīng)，表示提出的訂閱時(shí)長太短。此外，通告者還應(yīng)根據(jù)本地策略對提出SUBSCRIBE請求的用戶進(jìn)行鑒權(quán)。
與訂閱相關(guān)的信息由NOTIFY消息傳送。通告者在成功創(chuàng)建訂閱關(guān)系后，必須立即發(fā)送NOTIFY消息，向訂閱者通告當(dāng)前訂閱資源的狀態(tài)，如圖1中的F3所示。通告者使用SUBSCRIBE消息中Accept頭部明確允許的或者Event頭部隱含指明的消息體格式將資源的狀態(tài)信息或指向該資源狀態(tài)的URI封裝在消息中。消息也可包含擴(kuò)展的Allowed-Events頭部，指示本節(jié)點(diǎn)能夠支持的事件包類型。NOTIFY消息中必須包含擴(kuò)展的Subscription-State頭部，指示創(chuàng)建的訂閱的狀態(tài)。共有3種訂閱狀態(tài)，分別是：
(1)active：訂閱已被接受且授權(quán)成功。
(2)pending：SUBSCRIBE請求已收到，但還沒有足夠的信息決定接受或拒絕此次訂閱。
(3)terminated：訂閱未激活，或創(chuàng)建的訂閱關(guān)系終止。
對應(yīng)active狀態(tài)或peding狀態(tài)，該頭部還帶有expires參數(shù)指示此次訂閱的有效時(shí)長。對應(yīng)terminated狀態(tài)，該頭部應(yīng)包含reason參數(shù)指示訂閱被終止的原因，或者包含Retry-After參數(shù)，指示訂閱者過一段時(shí)間后重新發(fā)起訂閱請求。
訂閱者收到通告者NOTIFY請求后，將進(jìn)行匹配檢查。
如果找到相應(yīng)的匹配，且NOTIFY消息中的Subscription-State頭部指示的訂閱狀態(tài)是active或pending，訂閱者創(chuàng)建新的訂閱或?qū)υ挘OTIFY請求回送200 OK響應(yīng)，如圖1中的F4所示。如果匹配失敗，則發(fā)送“481 Subscription does not exist”(訂閱不存在)響應(yīng)。
在訂閱有效期內(nèi)，如果資源狀態(tài)發(fā)生變化，則通告者使用NOTIFY請求及時(shí)將變化信息通告訂閱者，如圖1中的F5和F6所示。
擴(kuò)展的SUBSCRIBE方法和基本的INVITE方法都可以創(chuàng)建對話。在某一對話中，SUBSCRIBE請求將創(chuàng)建和該對話關(guān)聯(lián)的訂閱，而該對話有可能是由INVITE建立起來的。因此，如果訂閱終止，且當(dāng)前無其他應(yīng)用狀態(tài)(如由INVITE請求建立起來的應(yīng)用狀態(tài))和該對話關(guān)聯(lián)，則該對話結(jié)束。如果仍有訂閱和該對話關(guān)聯(lián)，雖然其他的應(yīng)用狀態(tài)已結(jié)束，但該對話并沒有結(jié)束。換句話說，由INVITE創(chuàng)建的對話并不會(huì)因?yàn)槭盏交虬l(fā)送了再見請求而結(jié)束，因?yàn)槿杂杏嗛嗞P(guān)系和此對話相關(guān)聯(lián)。與此類似，當(dāng)多個(gè)訂閱和同一對話關(guān)聯(lián)時(shí)，必須當(dāng)與此對話相關(guān)聯(lián)的所有訂閱都結(jié)束時(shí)，該對話才結(jié)束。這一概念非常類似于程序設(shè)計(jì)里對文件描述符的引用，其中文件描述符相當(dāng)于對話，對文件描述符引用的進(jìn)程相當(dāng)于建立的訂閱關(guān)系。
SUBSCRIBE請求可以觸發(fā)通告者對其資源狀態(tài)的立即回送，因此，訂閱者可以利用這一特性實(shí)現(xiàn)對資源狀態(tài)的輪詢。當(dāng)訂閱處于激活狀態(tài)時(shí)，訂閱者在SUBSCRIBE請求的expires頭部寫入當(dāng)前剩下的訂閱有效時(shí)長的秒數(shù)，這樣，能夠立即觸發(fā)通告者產(chǎn)生NOTIFY消息，將當(dāng)前資源的狀態(tài)通告給訂閱者。需要指出的是，這種對資源的輪詢會(huì)導(dǎo)致網(wǎng)絡(luò)、通告者和訂閱者負(fù)荷的增加。在如移動(dòng)通信這樣的特定應(yīng)用中，訂閱者一般是數(shù)據(jù)處理能力較慢、需要額外供電的移動(dòng)終端設(shè)備，隨著事件通告頻度的增加和通告事件包的增大，將消耗很多寶貴的帶寬資源，造成網(wǎng)絡(luò)擁塞和訂閱者的過載。因此，訂閱者需要對通告者的狀態(tài)通告頻率作出限制[6]。另外，訂閱者還可以在SUBSCRIBE消息中指定一些事件包的過濾規(guī)則，使得通告者能夠根據(jù)這一過濾規(guī)則產(chǎn)生通告事件，而不是任何狀態(tài)發(fā)生變化時(shí)都發(fā)起通告。
一般說來，訂閱者使用SUBSCRIBE請求建立一次訂閱，稱為顯式訂閱創(chuàng)建，與此相對應(yīng)的還有一種隱式的訂閱創(chuàng)建，即訂閱者不是通過SUBSCRIBE請求來創(chuàng)建訂閱。而是通過轉(zhuǎn)交(REFER)方法[3]，一種由RFC 3515定義的用于實(shí)現(xiàn)呼叫轉(zhuǎn)交等業(yè)務(wù)的方法。REFER請求隱式地在被轉(zhuǎn)交用戶處創(chuàng)建訂閱，所要觀察的資源是轉(zhuǎn)交請求的狀態(tài)。
2 自動(dòng)回叫業(yè)務(wù)示例
如前所述，會(huì)話啟動(dòng)協(xié)議的事件通告機(jī)制非常靈活，針對不同的應(yīng)用可以定義不同的事件包，事件包被封裝在NOTIFY消息中通告資源狀態(tài)，這一機(jī)制為實(shí)現(xiàn)各種功能強(qiáng)大的業(yè)務(wù)提供了堅(jiān)實(shí)的基礎(chǔ)?，F(xiàn)給出使用這一機(jī)制實(shí)現(xiàn)的自動(dòng)回叫業(yè)務(wù)流程。
(1)業(yè)務(wù)描述
用戶Ａ呼叫用戶B，而B正在會(huì)話，A希望B在通話結(jié)束后能夠立刻通知他，這樣A就能夠及時(shí)地和B建立會(huì)話了。這里，A使用事件通告機(jī)制來獲取B的會(huì)話狀態(tài)。
(2)業(yè)務(wù)流程
如圖3所示，用戶A向用戶B發(fā)起呼叫請求INVITE(F1)，此時(shí)B正在通話，因此返回“486 Busy Here”(現(xiàn)在正忙)響應(yīng)(F2)。A希望B能夠在通話結(jié)束后通知他，于是A向B發(fā)起SUBSCRIBE請求(F4)，其Event頭部指明事件類型為dialog，即訂閱B正在進(jìn)行中的對話狀態(tài)；Accept頭部指明A支持使用XML語言封裝的dialog事件包。SUBSCRIBE的消息片斷如下：
SUBSCRIBE sip: userB@foo.bar SIP/2.0
……
Event: dialog
Accept: application/dialog-info+xml
……
B的通告者根據(jù)本地策略對A進(jìn)行鑒權(quán)后授權(quán)A訂閱這一資源，返回200 OK(F5)，并立即回送通告當(dāng)前對話狀態(tài)的NOTIFY消息。當(dāng)B結(jié)束通話時(shí)，A訂閱的對話資源狀態(tài)發(fā)生了變化，從確認(rèn)狀態(tài)遷移至了終結(jié)狀態(tài)，B的通告者生成NOTIFY消息，向A通告當(dāng)前B的對話狀態(tài)(F8)。A得到這一信息后，立即向B發(fā)起INVITE請求，與B建立新的會(huì)話。
3 事件通告機(jī)制的安全性考慮
(1)接納控制
在事件通告機(jī)制中，通告者需要將資源的狀態(tài)信息通告給訂閱者，然而在通告的事件包中，有些信息對于用戶來說是敏感的或者是隱私，因此，通告者應(yīng)能夠根據(jù)訂閱者的身份，選擇性地拒絕某些用戶的訂閱請求，并使用標(biāo)準(zhǔn)的會(huì)話啟動(dòng)協(xié)議鑒權(quán)機(jī)制[2]對用戶進(jìn)行鑒權(quán)。訂閱請求的最終決定權(quán)應(yīng)該由用戶(自然人)作出。
(2)通告者的策略安全
在某些情況下，對SUBSCRIBE請求回應(yīng)200 OK或4XX、6XX響應(yīng)可能會(huì)導(dǎo)致通告者某些敏感策略信息的泄漏。因此，在這些情況下，通告者應(yīng)總是對SUBSCRIBE請求回送202 Accepted響應(yīng)。后繼的NOTIFY中可能并不攜帶真正的資源狀態(tài)，但從訂閱者的角度來看，這并無任何異常。例如，在“在席”應(yīng)用中，用戶A向用戶B發(fā)送SUBSCRIBE請求獲取用戶B是否在席的信息，B在席，但他拒絕了A的訂閱請求，因?yàn)锽并不想讓A知道他正在網(wǎng)上。如果B直接使用4XX或6XX響應(yīng)拒絕，則會(huì)泄漏B的策略。為此，B可對SUBSCRIBE回送202 Acceptted響應(yīng)，在隨后的NOTIFY消息的Subscription-State頭部指明訂閱終結(jié)，原因?yàn)闆]有資源，即A想訂閱的資源不存在，其Subscription-State頭部為：Subscription-State：terminated；reason=noresource，這樣既拒絕訂閱請求又不會(huì)暴露通告者的策略信息。
(3)防止惡意攻擊
隨著事件通告機(jī)制的進(jìn)一步應(yīng)用，要逐步考慮應(yīng)對各種Internet上慣用的惡意攻擊。比如，拒絕服務(wù)(DoS)攻擊，在當(dāng)前的基于會(huì)話啟動(dòng)協(xié)議的事件通告模型中，一個(gè)SUBSCRIBE請求將觸發(fā)一個(gè)或多個(gè)通告資源狀態(tài)的NOTIFY消息，通告者接收到SUBSCRIBE請求，要?jiǎng)?chuàng)建相應(yīng)的狀態(tài)，消耗一定的系統(tǒng)資源。有惡意的訂閱者會(huì)利用這一點(diǎn)發(fā)起過多的訂閱請求，就有可能使通告者因創(chuàng)建過多的訂閱而資源耗盡。為了減少這種攻擊的機(jī)會(huì)，通告者的實(shí)現(xiàn)必須包含鑒權(quán)，以過濾惡意的訂閱請求。
4 結(jié)束語
IETF通過引入SUBSCRIBE和NOTIFY兩個(gè)擴(kuò)展方法，Event、Allowed-Events和Subscription-State 3個(gè)擴(kuò)展頭部，并在定義事件包引入必要的擴(kuò)展消息體，形成了會(huì)話啟動(dòng)協(xié)議事件通知機(jī)制，基于此機(jī)制可以靈活地實(shí)現(xiàn)許多新的增值業(yè)務(wù)。
5 參考文獻(xiàn)
[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.
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=674622
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報(bào)。
