---這章應該沒翻譯完，也沒檢查，先放着
Chapter 13:SIP-Specific Event Notification
13.1 Introduction
SIP事件指定通知的定義在RFC265“Session Initiation Protocol(SIP)-Specific Event Notification”。核心的協議是定義了兩種SIP的方法來建立事件的訂閱，如SUBSCRIBE和NOTIFY，但是也可以定義其他的方法來創建訂閱（REFER）。
這章描述PJSIP在基本對話框架基礎上來設計和實現創建基本和一般事件通知框架，並可以用來實現更高層的事件包，例如presence和call transfer（通過REFER）。
PISIP事件通知框架的實現打包作爲一個靜態庫pjsip-simple，在pjsip目錄下。爲了它的功能，應用必須包含頭文件<pjsip_simple.h> 並且鏈接pjsip_simple靜態庫。
這章描述了基本事件訂閱框架。出席和呼叫轉移將在下章描述。
13.1.1 Basic Concept
所有PJSIP事件通知會話的類型都在對象pjsip_evsub中。這個對象管理訂閱的生命週期，並將傳入的請求和響應轉換爲適當的回調調用。
PJSIP事件通知會話使用基本對話框架（10 UA）。因爲基本對話框架的設計允許對話可被多會話共用，多個事件訂閱會話可能使用同一個對話，它還可以與invite會話共享這個對話。
爲了訂閱一個事件通知，應用需要創建一個事件訂閱對象，指定底層對話和回調來接收訂閱事件。
對話或者應用都會有傳入的訂閱請求（比如SUBSCRIBE or REFER），這取決於請求時對話內還是外。應用必須檢查請求中的事件ID，然後使用相應的API來處理訂閱。比如，當傳入的消息是REFER，應用通過調用pjsip_xfer_create_uas()來創建服務器訂閱，當SUBSCRIBE請求中的Event id是“presence”，應用通過調用pjsip_pres_create_uas()創建服務器訂閱。
13.1.2 Event Package
事件包描述事件訂閱的語義。在PJSIP中，事件包必須在訂閱會話創建了指定的event id之前先註冊到事件框架。事件包通過調用pjsip_evsub_register_pkg()來註冊到框架。這個函數通常在實現事件包的PJSIP模塊初始化時已經完成。
事件包的主要作用是提供NOTIFY請求的消息體。比如，PJSIP出席事件包使用content type“application/pidf+xml”或“application/xpidf+xml”來爲發出的NOTIFY請求創建消息體。
13.1.3 Header Fields
事件框架管理髮出請求中的Accept，Allow-Events，Event，Expires和Subscription-State頭字段的content，根據註冊的事件包中的信息。同樣也會檢查收到的請求中的Expires和Subscription-State頭字段，並相應的更新狀態。
所有其他頭字段（和對話之外的頭字段）必須被事件包或者應用處理。比如，refer事件包管理髮出的REFER請求的Refer-To字段。
13.2 Basic Operation
這部分描述怎麼使用核心的PJSIP事件訂閱框架。之後章節會看到更高層事件包（presence，call transfer）的操作和核心事件框架的相似之處。
Note：爲了節省空間，圖中省略了API調用中的“pjsip_”前綴，這應該在實際程序中指定。例如，當圖中顯示dlg_create_uac()和evsub_create_uac()時，實際的函數名是pjsip_dlg_create_uac()和pjsip_evsub_create_uac()
13.2.1 Client Initiating Subscription
客戶端通過構造和發送訂閱請求來啓動訂閱以建立對話框。客戶端應在對話中放入適當的憑證，以便訂閱事件模塊能夠自動處理身份驗證。客戶端還應該在對話框設置適當的路由。
描述：
- 應用（或事件包）通過第一次創建一個UAC（1a）對話後創建客戶端訂閱會話（1b）來初始化客戶端訂閱。應用可能在1a和1b步驟中設置授權和路由集。
- 應用程序通過創建請求(2a)和發送請求(2b)發送初始訂閱(或其他方法建立訂閱，例如reference)。
- 在上面的步驟2中發送SUBSCRIBE請求將觸發on_evsub_state()回調函數。這甚至會在evsub_send_request()函數返回之前發生。
- 應用程序在步驟4中的on_tsx_state()回調中接收任何事務狀態進展。這個回調是可選的，且僅僅是參考的目的。如果請求被要求驗證，並且認證信息已經在對話中設置了，事件框架將用適當的認證來重新確認請求。
- 當收到初始化SUBSCRIBE請求（或者其他請求建立的請求）的2xx的響應，調用on_evsub_state()回調函數。應用程序可以通過調用pjsip_evsub_get_state()函數獲取訂閱狀態，當收到2xx響應的後返回PJSIP_EVSUB_STATE_ACCEPTED。如果收到了非2xx的最終響應，訂閱狀態將置爲PJSIP_EVSUB_STATE_TERMINATED。
13.2.2 Server Receiving Incoming Subscription
描述：
- 對話外的任何傳入請求都會傳到應用，最終決定怎麼處理請求。對於傳入的SUBSCRIBE請求，如果應用想要認證請求，可以用401、407來響應響應請求（1a），有狀態或無狀態無狀態的。這必須在創建任何對話或服務器訂閱實例之前完成。當應用驗證過請求（1b），就可以創建服務器訂閱實例（2a，2b）。
如果請求來自對話（比如REFER請求），應用在對話框的on_tsx_state()回調中接收請求。這種情形下步驟1-2a不需要，應用直接到步驟2b。
- 服務器側事件訂閱需要一個用來操作的對話實例。應用可能會爲訂閱創建一個新的UAS對話（2a）或者可能使用一個已存在的對話（比如在對話中處理傳入的REFER請求）。之後應用創建服務器側事件訂閱，傳遞對話實例。
- 應用調用pjsip_evsub_accept()來發送訂閱請求的響應（3），傳遞放入響應的一個一個狀態碼。這個狀態碼必須是2xx類的狀態。
- 以上步驟3發送2xx響應講觸發回調函數on_evsub_state()的調用（4）。
之後服務器必須立即發送初始NOTIFY請求，下面描述。
13.2.3 Server Activating Subscription (Sending NOTIFY)
服務器發送NOTIFY請求（下面的步驟5）來啓動服務器訂閱。如果服務器希望NOTIFY請求被驗證，必須在創建UAS對話中設置認證信息。如果NOTIFY請求被鑑權，只要對話中有正確的認證信息，evsub模塊就會就會使用相應認證來重新確認NOTIFY（6）。
13.2.4 Client Receiving NOTIFY Requests
當收到傳入NOTIFY請求，應用可以通過在on_rx_notify()回調函數中返回401來鑑權請求(參見下面的步驟5)。客戶端之後等待NOTIFY的立即確認。默認情況下，訂閱框架等待重確認5秒，之後通過發送0週期的SUBSCRIBE來終止訂閱如果NOTIFY沒有收到。
on_rx_notify()回調是可選的。默認行爲是用200個響應響應傳入通知。
注意事件框僅更新狀態（根據傳入的NOTIFY請求的狀態）如果應用以2xx響應來應答NOTIFY請求。
13.2.5 Server Terminating Subscription
服務器通過發送NOTIFY終止訂閱，並將訂閱狀態設置爲terminated(下面的步驟8)。服務器可以在接收到建立會話的初始請求後隨時發送NOTIFY請求。
特別是，當訂閱超時時，服務器應該發送狀態置爲terminated的NOTIFY。
無論NOTIFY請求的響應如何，將訂閱狀態設置爲terminated的NOTIFY請求發送將觸發on_evsub_state()回調函數(步驟8b)。但是，當NOTIFY被鑑權，框架重新發送帶有正確認證的的請求。