---这章应该没翻译完,也没检查,先放着
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目录下。为了它的功能,应用必须包含头文件
这章描述了基本事件订阅框架。出席和呼叫转移将在下章描述。
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
客户端通过构造和发送订阅请求来启动订阅以建立对话框。客户端应在对话中放入适当的凭证,以便订阅事件模块能够自动处理身份验证。客户端还应该在对话框设置适当的路由。
描述:
13.2.2 Server Receiving Incoming Subscription
描述:
如果请求来自对话(比如REFER请求),应用在对话框的on_tsx_state()回调中接收请求。这种情形下步骤1-2a不需要,应用直接到步骤2b。
之后服务器必须立即发送初始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被鉴权,框架重新发送带有正确认证的的请求。