ONVIF-Core Event [1][Real-time Pull-Point Notification Interface]

9 Event handling
事件是客户端可以订阅的设备检测到的操作或事件。事件通过事件服务进行处理。该规范基于[WS-BaseNotification]和[WS-Topics]规范定义事件处理。它扩展了事件概念，以允许客户端通过事件跟踪对象属性（例如，数字输入和运动报警属性）。属性在9.4.2节中定义。

9.4节讨论了事件有效负载(payload)及其在订阅中的过滤(filtering)的描述。 第9.5节描述了客户端如何使用三个通知接口之一来请求同步点。 第9.6节描述了主题(Topics)的集成，第9.9节讨论了错误的处理。

第9.10节演示了实时Pull-Point通知接口的用法，包括消息过滤(Message Filtering)和主题集(Topic Set)。 基本通知接口的示例可以在相应的[WS-BaseNotification]规范中找到。 设备和客户端都应支持事件服务的[WS-Addressing]。

9.1 Real-time Pull-Point Notification Interface
本节介绍了实时Pull-Point通知接口。 此接口提供了防火墙友好的通知接口，该接口可启用实时轮询(polling)并初始化所有客户端通信。
该接口的使用方式如下：
1）客户端使用CreatePullPointSubscriptionRequest向设备请求pull point信息。
2）设备评估订阅请求并返回一个CreatePullPointSubscriptionResponse或故障代码之一。
3）如果预订被接受，则响应中将包含一个到实例化的pull point的WS-EndpointReference。 该WS-Endpoint提供了PullMessages操作，客户端使用该操作来检索通知。 此外，它提供基本订阅管理器接口的续订和取消订阅操作。 交互的时序图如图5所示。

Figure 5: Sequence diagram for the Real-time Pull-Point Notification Interface.

4) 设备会立即以代表所有客户端汇总(aggregated)的通知进行响应。 如果没有汇总的通知，则设备将等待响应，直到为客户端生成通知或超过指定的超时。 无论如何，响应最多包含MessageLimit参数指定的通知数。 当客户端在每个PullMessagesResponse之后立即启动新的PullMessagesRequest时，客户端可以实时轮询通知。

对于设备实现，重要的是要支持multiple pull points（每个客户端包括多个pullpoints），以便允许精确的事件生成。如果设备一次仅支持一个订阅，则客户端将需要订阅而没有任何范围(scope)限制，因为事件订阅是不可能更改的。因此，这将要求设备服务于所有可用事件，而设备将不得不为其激活所有生成事件的子系统。例如，这可能会导致不必要的负载。无需激活多个运动检测器或类似设备。此外，所有这些事件产生的流量可能会导致大量的网络负载。

如果设备支持持久性通知存储，请参阅9.1.7，WS-Endpoint还提供了Seek操作。此操作允许将拉动指针重新定位到过去。通过搜索操作，也可以重新调整拉动方向。 9.11.1中定义了一个BeginOfBuffer事件，该signals表示缓冲区的开始。

符合ONVIF的设备应实现实时Pull-Point通知接口。

9.1.1 Create pull point subscription
符合ONVIF的设备应提供CreatePullPointSubscription命令。 如果未指定Filter元素，则pullpoint应将所有发生的事件通知客户端。

默认情况下，pull point保持活动状态是通过PullMessages操作控制的。 在这种情况下，在返回PullMessages响应之后，订阅至少应在PullMessages请求中指定的超时时间内处于活动状态。

A device shall support an absolute time value specified in utc as well as a relative time value for the InitialTerminationTime parameter. A device shall respond both parameters CurrentTime and TerminationTime as utc using the ‘Z’ indicator.
设备应支持utc中指定的绝对时间值以及InitialTerminationTime参数的相对时间值。 设备应使用“ Z”指示符将参数CurrentTime和TerminationTime响应为utc。

在tev：SubscriptionPolicy中定义了以下可选的订阅策略元素：

• tev:ChangedOnly pullpoint 不应为属性提供Initialize事件或Deleted事件。

Table 80: CreatePullPointSubscription command

9.1.2 Pull messages
设备应为CreatePullPointSubscription命令返回的所有SubscriptionManager端点(endpoint)提供以下PullMessages命令。

设备应支持至少一分钟的超时。 当MessageLimit大于设备支持的范围时，设备不应以PullMessagesFaultResponse进行响应。
相反，设备应在响应中返回最多支持的消息。

响应行为应为以下三种类型之一：

•如果在请求到达时有一个或多个消息正在等待（即汇总(aggregated)），则设备应立即以等待的消息进行响应，直至MessageLimit。 设备不得丢弃未发送的消息，而应等待下一个PullMessages请求发送剩余消息。

when receiving a PullMessages request for a subscription where a blocking PullMessage request already exists.

•如果没有消息等待，并且设备在达到超时之前生成一条消息（或多条同时发生的消息），则设备应立即以生成的消息进行响应，直至MessageLimit。在返回响应之前，设备不得(shall not)等待其他消息。

•如果没有消息等待，并且设备在达到超时之前未生成任何消息，则设备应以零消息作为响应。在达到超时之前，设备不得返回零消息响应。

设备应使用“ Z”指示符将参数CurrentTime和TerminationTime响应为utc。

搜索(seek)操作后，设备应按照严格的消息utc时间顺序返回消息。请注意，此要求不适用于标准实时消息传递(standard realtime message delivery)，在该标准中，传递顺序可能会受到设备内部计算的影响。

当接收到已存在的阻塞(blocking)PullMessage请求的订阅的PullMessages请求时(when receiving a PullMessages request for a subscription where a blocking PullMessage request already exists.)，设备应返回错误（UnableToGetMessagesFault）。

9.1.3 Renew
如果兼容ONVIF的设备通过MaxNotificationProducers功能发出对[WS-Base Notification]的支持信号，则应支持此命令。

该命令至少应支持一分钟的超时。 设备应使用“ Z”指示符将参数CurrentTime和TerminationTime响应为utc。

9.1.4 Unsubscribe
设备应为CreatePullPointSubscription命令返回的所有SubscriptionManager端点提供以下Unsubscribe命令。 该命令在[OASIS Web Services Base Notification 1.3]的6.1.2节中定义。

该命令将终止pull point的lifetime。

9.1.5 Seek
支持第9.1.7节中定义的持久性通知存储的设备应为CreatePullPointSubscription命令返回的所有SubscriptionManager端点提供以下Seek命令。

在Seek时，pullpoint将中止任何事件传递，包括属性的任何初始状态。此外，pullpoint应该清除尚未进入传输队列等待传输的事件。

在Seek请求之后，拉点将忽略第9.6节中描述的属性行为。

如果存在Reverse参数并将其设置为“ true”，则设备仅应在reverse pull mode下设置订阅(subscription)。

Seek请求的UtcTime参数应与持久性通知存储中的通知的UtcTime属性进行匹配。

当在前向模式(forward mode)下使用Seek时，设备应该(position)定位pull pointer到，包含永久性存储(persistent storage)中所有UtcTime属性大于或等于Seek参数的NotificationMessage。
当在反向模式(reverse mode)下使用Seek时，设备应该(position)定位pull pointer到，包含永久性存储(persistent storage)中所有UtcTime属性小于或等于Seek参数的NotificationMessage。

设备不应提供初始生成属性状态的信息作为对Seek方法调用的响应。

9.1.6 Pull Point Lifecycle
图5描述了pull point的基本操作。 本章陈述了对pull point生命周期（lifecycle）的要求。

设备必须在每个CreatePullPointSubscription命令上创建一个新的pull point，只要实例化的pull point的数量不超过MaxPullPoints的capability即可。 每个pull point都应有一个唯一的端点（endpoint）引用，客户端可以将其连续的操作引导(direct)到该pull point.上。

pull point将一直存在，直到终止时间(termination time)过去或客户端通过退订(Unsubscribe)请求请求处理为止。 对于设备整个电源周期( power cycle)中pull point的持久性没有要求。

9.1.7 Persistent notification storage
为了确保客户端不会丢失任何通知，设备可以存储其通知。 客户端可以随时检索存储的通知。 设备应使用PersistentNotificationStorage功能指示其是否支持持久通知存储。 请参阅第9.8节。

该规范定义持久性存储的接口允许通过原始消息事件时间进行线性访问。 这也适用于各种原因(例如计算延迟)导致在实时流(live streaming)传输情况下乱序发送的事件

什么通知(notification)以及这些通知的实际存储方式和位置的详细信息不在本规范的范围之内。 删除存储的通知以为新通知腾出空间的策略也超出了范围。