---这章应该没翻译完，也没检查，先放着
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被鉴权，框架重新发送带有正确认证的的请求。