onvif----两种notify方式解读----pullpoint

最新推荐文章于 2024-06-14 07:28:31 发布

划过星空20216

最新推荐文章于 2024-06-14 07:28:31 发布

阅读量4.9k

点赞数

分类专栏： onvif 文章标签： onvif pullpoint

本文链接：https://blog.csdn.net/no_pao_spite/article/details/72821186

版权

onvif 专栏收录该内容

10 篇文章 3 订阅

订阅专栏

 
  pullpoint 
 
   1.client通过CreatePullPointSubscriptionRequest向device申请PullPointSubscription(拉订阅点)。这个request包含了此订阅的详细描述信息。并且与the Basic Notification Interface不同之处就是此处需要省略consumerReference。 
 
   2.当subscribe被接受的时候device评估此订阅后返回CreatePullPointSubscriptionResponse 
 
   或者返回一个错误代码。 
 
   3.订阅被接受后，反馈的response需要包含SubscriptionManager的WS-EndpointReference. 
 
  WS-Endpoint必须提供PullMessage操作，Pullmessage用于客户端检索通知信息，以及由订阅管理manager接口去描述WS-BaseeNotification。Base Subscription Manager 接口包含PullMessage, 
 
   Renew,Unsubscribe 等操作。交互序列如上图。 
  PullMessage包含Timeout以及MessageLimit 参数 
 
   4.一旦有来自client的查询通知则device必须立即响应，如果没有则device一直保持等待client所订阅的通知到来或者等待超时发生。一般情况下至少包括response，且通知个数是被指定的。 
  client在发出的一个PullMessagesRequest并收到PullMessagesResponse后既可以实时轮询通知接口(类似于一问一答式的服务) 
 
   5 
  .如果在CreatePullPointSubscriptionRequest中未指定结束或者相关结束时间，则每个PullMessagesRequest理解为保持激活状态等待相应的PullPointSubscription.并且结束时间会根据相关联的结束时间或者装置内置数值进行再计算。 
  为了通知client去更新结束时PullMessageResponse必须包含CurrentTime以及terminalTime选项。当PullMessagesRequest处于激活状态并等待相应的PullPointSubscription，此时由WS-BaseNotification定义的RenewRequest不能被Client,因此device需要支持PullPointSubscription。 
 
  （在没有订阅的前提下发送PullMessagesRequest,需要等待PullPointSubscription去创建订阅完成才能继续运行） 
 
   6.如果device支持通知持续保存，则WS-Endpoint必须支持Seek操作，其支持将pull指针重新拉回原位置。为防止将指针的放置位置超出了buffer的起始位置，第一次调用PullMessage要从buffer的起始位置开始。(9.12.9)SeekRequest包含了UtcTime参数，UtcTime参数必须NotificationMessage中的属性相匹配。当使用seek，则pull指针要放置在包含NotificationMessage的且其UtcTime少于等于seek参数的buffer中。SeekRequest包含一个可选的对立参数，这个参数可以将PullMessageResquest的pull方向反向。 
 
   device应该支持多拉点以便去允许精确事件产生以及多客户端使用。对client的实现来说试下单client实现多拉点去允许精确事件产生是很重要的。如果device仅仅支持在同一时间单订阅则client便不需要带有限制的subscribe，因为事件变化不发生。因此徐奥device能为所有的有效事件提供服务，因为device必须激活所有子系统去产生事件。这或许会引起激活移动侦测以及相似的不需要的服务。另外这些事件的产生或许导致子网络瘫痪。 
 
   通常一个网络device可以互不影响的服务多个client，通常每一个client对于它必须订阅的事件感兴趣。 
 
  Create pull point subscription 
 
   device必须提供CreatePullpointSubscription命令。如果没有指定的过滤器元素，则这个pullpoint必须通知所有client 
 
   device必须支持一个在InitialTerminationtime中定义的utc以及相关time值的确定的时间值。device必须使用Z预示回应CurrentTime和TerminationTime 
 
  Pull Message 
 
   device必须提供PullMessages命令，因为所有的SubscriptionManager的endpoint均由CreatePullPointSubscription命令返回 
 
   此命令至少支持的Timeout是1分钟。如果一个device支持搜索message而不是request，它将不产生错误的返回信息。 
 
   device需要用Z作为标识去反应 Current time 和terminationTime这两个参数 
 
  seek 
 
   支持连续通知存储的device应该提供seek命令，因为所有的SubscriptionManager的endpoint均由CreatePullPointSubscription命令返回 
 
   设备不得提供初始生成属性的设备状态的信息给调用seek的函数。 
 
  连续通知存储 
 
   保证不丢失通知，使decice或者client去存储通知，存储的信息可以在认识时间被client去搜索。deveice必须表明它是否具有连续通知存储的能力去进行连续事件存储。 
 
   通知必须以一定的顺序逻辑上通知是存储在缓冲区中；消息通知是什么，这些消息通知存储在哪里是超出本规范的范围。删除存储策略通知去获得新的空间同样是超出范围以外 
 
  Capabilities 
 
   能力反映了服务的功能以及可选功能，这些信息在设备操作过程中是不会变的，具体功能如下： 
 
 pullpoint

   1.client通过CreatePullPointSubscriptionRequest向device申请PullPointSubscription(拉订阅点)。这个request包含了此订阅的详细描述信息。并且与the Basic Notification Interface不同之处就是此处需要省略consumerReference。 
 

   2.当subscribe被接受的时候device评估此订阅后返回CreatePullPointSubscriptionResponse 
 

   或者返回一个错误代码。 
 

   3.订阅被接受后，反馈的response需要包含SubscriptionManager的WS-EndpointReference. 
 

 
  WS-Endpoint必须提供PullMessage操作，Pullmessage用于客户端检索通知信息，以及由订阅管理manager接口去描述WS-BaseeNotification。Base Subscription Manager 接口包含PullMessage, 
 

   Renew,Unsubscribe 等操作。交互序列如上图。 
  PullMessage包含Timeout以及MessageLimit 参数 
 

   4.一旦有来自client的查询通知则device必须立即响应，如果没有则device一直保持等待client所订阅的通知到来或者等待超时发生。一般情况下至少包括response，且通知个数是被指定的。 
  client在发出的一个PullMessagesRequest并收到PullMessagesResponse后既可以实时轮询通知接口(类似于一问一答式的服务) 
 

   5 
  .如果在CreatePullPointSubscriptionRequest中未指定结束或者相关结束时间，则每个PullMessagesRequest理解为保持激活状态等待相应的PullPointSubscription.并且结束时间会根据相关联的结束时间或者装置内置数值进行再计算。 
  为了通知client去更新结束时PullMessageResponse必须包含CurrentTime以及terminalTime选项。当PullMessagesRequest处于激活状态并等待相应的PullPointSubscription，此时由WS-BaseNotification定义的RenewRequest不能被Client,因此device需要支持PullPointSubscription。 
 

 
  （在没有订阅的前提下发送PullMessagesRequest,需要等待PullPointSubscription去创建订阅完成才能继续运行） 
 

   6.如果device支持通知持续保存，则WS-Endpoint必须支持Seek操作，其支持将pull指针重新拉回原位置。为防止将指针的放置位置超出了buffer的起始位置，第一次调用PullMessage要从buffer的起始位置开始。(9.12.9)SeekRequest包含了UtcTime参数，UtcTime参数必须NotificationMessage中的属性相匹配。当使用seek，则pull指针要放置在包含NotificationMessage的且其UtcTime少于等于seek参数的buffer中。SeekRequest包含一个可选的对立参数，这个参数可以将PullMessageResquest的pull方向反向。 
 

   device应该支持多拉点以便去允许精确事件产生以及多客户端使用。对client的实现来说试下单client实现多拉点去允许精确事件产生是很重要的。如果device仅仅支持在同一时间单订阅则client便不需要带有限制的subscribe，因为事件变化不发生。因此徐奥device能为所有的有效事件提供服务，因为device必须激活所有子系统去产生事件。这或许会引起激活移动侦测以及相似的不需要的服务。另外这些事件的产生或许导致子网络瘫痪。 
 

   通常一个网络device可以互不影响的服务多个client，通常每一个client对于它必须订阅的事件感兴趣。 
 

 
  Create pull point subscription 
 

   device必须提供CreatePullpointSubscription命令。如果没有指定的过滤器元素，则这个pullpoint必须通知所有client 
 

   device必须支持一个在InitialTerminationtime中定义的utc以及相关time值的确定的时间值。device必须使用Z预示回应CurrentTime和TerminationTime 
 

 
  Pull Message 
 

   device必须提供PullMessages命令，因为所有的SubscriptionManager的endpoint均由CreatePullPointSubscription命令返回 
 

   此命令至少支持的Timeout是1分钟。如果一个device支持搜索message而不是request，它将不产生错误的返回信息。 
 

   device需要用Z作为标识去反应 Current time 和terminationTime这两个参数 
 

 
  seek 
 

   支持连续通知存储的device应该提供seek命令，因为所有的SubscriptionManager的endpoint均由CreatePullPointSubscription命令返回 
 

   设备不得提供初始生成属性的设备状态的信息给调用seek的函数。 
 

 
  连续通知存储 
 

   保证不丢失通知，使decice或者client去存储通知，存储的信息可以在认识时间被client去搜索。deveice必须表明它是否具有连续通知存储的能力去进行连续事件存储。 
 

   通知必须以一定的顺序逻辑上通知是存储在缓冲区中；消息通知是什么，这些消息通知存储在哪里是超出本规范的范围。删除存储策略通知去获得新的空间同样是超出范围以外 
 

 
  Capabilities 
 

   能力反映了服务的功能以及可选功能，这些信息在设备操作过程中是不会变的，具体功能如下： 
 