ONVIF專題--Onvif標準解讀(2)--Core Spec::Device Discovery(1)

相關文章：
ONVIF專題--Onvif標準解讀(2)--Core Spec::Device Discovery(2)
ONVIF專題--Onvif標準解讀(2)--Core Spec::Device Discovery(3)

ONVIF--WS-Discovery spec

WS-Discovery 全名爲 Web Service Dynamic Discovery

本篇針對 WS-Discovery spec 作一整理，並介紹 ONVIF 使用 WS-Discovery 時，需做的一些變更，另外此處也介紹該如何使用 gSOAP 來進行實作。

1 WS-Discovery 定義三個角色

Client	客戶端，服務請求方
Target Service	目標服務端，服務提供方
Discovery Proxy	服務發現代理，服務統一代理

2 WS-Discovery 定義四種訊息

Hello
Bye
Probe
Resolve

這邊只針對 Probe 作一說明，Probe 會帶兩個 optional 的參數 "Types" 和 "Scopes"，Target Service在收到此訊息後，會比對 Type 與 Scope 是否符合，若符合便回覆 ProbeMatch，否則便不作回覆。 

注意：WS-Discovery中定義的Scope 概念，用於描述服務的作用範圍。如下例，ONVIF設備中設定的scope，簡單理解就是爲了方便找到設備，給設備（服務）設置的各種頭銜，本質上就是對服務進行多維度的分類。

Scope Example

   onvif://www.onvif.org/Profile/Streaming   #指明服務用於流數據

   onvif://www.onvif.org/hardware/D1-566   #指明服務硬件信息

   onvif://www.onvif.org/location/country/china  #指明服務所在地

   onvif://www.onvif.org/location/city/bejing  #指明服務所在地

   onvif://www.onvif.org/location/building/headquarter  #指明服務部署地點

   onvif://www.onvif.org/location/floor/R5 #指明服務樓層

   onvif://www.onvif.org/name/ARV-453   #指明服務名稱

 

此處需要注意的是，其比較 Scope 的規則有多種方式，例如：

• 比對字串是否需要區分大小寫
• 是否部分字串相同，就可以視爲相同的 Scope

比較規則須根據其對應的 MatchBy 關鍵字而定，可能的規則有下列五種：

• http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986 （預設值）
• http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/uuid
• http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ldap
• http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/strcmp0
• http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/none

 

若 Scope Tag 內沒有 MatchBy，則將其視爲預設值

注：ONVIF 定義的 Types 值，舊版本定義爲 "dn:NetworkVideoTransmitter" ，新版本定義爲 "tds:Device"，ONVIF 建議是兩種 Types 都送。

 

摘錄 ONVIF-NVT-Definition-v210.pdf chapter 5.2如下：

```

5.2.1 Types

Section "Discovery definitions" of the ONVIF Core Specification defines a generic tds:Device for the Types declaration.

For backward compatibility reason an ONVIF compliant NVT shall also include dn:NetworkVideoTransmitter in the declaration. 

```

3 WS-Discovery 定義兩種運作模式

3.1 ad hoc mode

簡答說就是客戶端直接發多播包搜索服務、或者直接嚮明確IP地址確認服務

In an ad hoc mode discovery messages are sent multicast and response messages are sent unicast. 

In an ad hoc mode, to find a target service by the type of the target service,

a scope in which the target service resides, or both, a client sends a probe message to a multicast group; target services that match the probe send a response directly to the client.   

To locate a target service by name, a client sends a resolution request message to the same multicast group, and again, the target service that matches sends a response directly to the client.

 

3.2 managed mode

通過服務發現代理

In a managed mode discovery messages are sent unicast to a Discovery Proxy. 

To operate in a managed mode a Target Service and a Client need an Endpoint Reference of the Discovery Proxy.

 

3.3 Dynamic Mode Switching

爲了減少網路上傳送的 multicast 封包量， 

Client 可以自動切換上述兩種 mode。預設 Client 會使用 ad hoc mode，發現網路上存在 DP(Discovery Proxy)，便可以切換至 managed mode，若發現 Discovery Proxy 無法信任，便切換回 ad hoc mode。 

Target Service 因爲只會在開關機時送出 (multicast) Hello and Bye，不會產生大量的 multicast 網路封包，因此直接使用 ad hoc mode 即可。

注1：若 Client 收到 unicast hello，且此訊息內的 type = "d:DiscoveryProxy"，表示此時網路存在 DP。

注2：若 Client 收到的 hello 中帶有 /s:Envelope/s:Body/d:Hello/d:XAddrs tag，便可由此處得知 transport address，用於 unicast 使用。 

4 不同模式下的運作方式

在 ad hoc mode 與 manage mode 下，各個角色所可以送出的訊息是相同的，主要的差異處在於 transport layer的使用，以下整理兩張表方便對照其差別。 

ad hoc mode

ad hoc mode	Client	Target Service	Discovery Proxy
Hello	multicast (+)	multicast	multicast
Bye	multicast	multicast	multicast
Probe	multicast	x	unicast
ProbeMatch	x	unicast	unicast
Resolve	multicast	x	unicast
ResolveMatch	x	unicast	unicast

manage mode

manage mode	Client	Target Service	Discovery Proxy
Hello	multicast	multicast	multicast
Bye	multicast	multicast	multicast
Probe	unicast	x	unicast
ProbeMatch	x	unicast	unicast
Resolve	unicast	x	unicast
ResolveMatch	x	unicast	unicast

當使用 managed mode，Client 可以根據 Hello 內的 transport address，當成 Probe 或 Resolve 的 target address，如此可以減少網路上的 multicast packet。

Multicast 時使用的 address/port 定義如下： 

DISCOVERY_PORT: port 3702 [IANA] 

IPv4 multicast address: 239.255.255.250

IPv6 multicast address: FF02::C (link-local scope)

5 ONVIF 組織定義的 Discovery 所定義的變更 (ONVIF-Core-Specification-v240.pdf)

5.1 Local Discovery

原則上與 WS-Discovery 相同，但針對各類 message 所帶的資訊做一規範，或舉例說明。

摘錄如後 ：

(1) Type

  <d:Types>tds:Device</d:Types> ， 

 

(2) Scope Example

  onvif://www.onvif.org/Profile/Streaming

  onvif://www.onvif.org/hardware/D1-566

  onvif://www.onvif.org/location/country/china

  onvif://www.onvif.org/location/city/bejing

  onvif://www.onvif.org/location/building/headquarter

  onvif://www.onvif.org/location/floor/R5

  onvif://www.onvif.org/name/ARV-453 

 

(3) <d:XAddrs>

  The device should provide a port 80 device service entry in order to allow firewall traversal. 

 

(4) Scope matching rule

最起碼需要能夠支援http://schemas.xmlsoap.org/ws/2005/04/discovery/rfc3986    

若是 unicast Probe 內的 scope 不帶 MatchBy，則回錯誤。原本的 WS-Discovery則是定義不回。

原文如下：

If a device receives a unicast Probe message and it does not support the matching rule, then the device may choose not to send a Probe Match, and instead generate a SOAP fault.

 

5.2 Remote Discovery

若要支援 ONVIF 定義的 remote service discovery，便需要擴充DP(Discovery Proxy)的定義，說明如後 

根據 device 與 client 所在的網路，可以將網路環境區分爲四種。

1. The device resides in one administrative domain (private) and the client resides in a public network.
2. The device resides in a public network and the client resides in one administrative domain (private).
3. The device resides in one administrative domain (private) and the client resides in another administrative domain (private).
4. Both the device and the client reside in a public network. 

 

原本的 WS-Discovery 並無法在上述的所有網路環境中都正常運作，因此 ONVIF 爲了增加互通性(穿透NAT或Firewall)，對於 DP(Discovery Proxy)的定義做了下列擴充：

1. DP 應該架設於 public network， 
2. Client 可以透過事先指定的ip位址或是透過 DNS 找到 DP，若是使用 DNS SRV lookup，則應使用 _onvifdiscover._tcp 
3. DP 主要的兩種功能
   1. 接收 Device Hello/Bye 並回覆，原本的 WS-Discovery並無此部分。
   2. 代替 device 回覆 client 所發出的 probe

 

修改後的 Hello, Bye, Probe 分別稱爲 Remote Hello, Remote Bye, Remote Probe。原文摘錄如後：

Remote Hello 

This message(Hello) is sent as a Web Services request operation from the device to the DP using the HTTP binding as defined in [ONVIF DP WSDL]. The remote Hello shall include its scope list in the Hello message. 

Once the home DP receives a Hello message from any device, it responds with a Hello response message confirming the device registration through the hello message. 

 

Remote Bye 

Similarly, when a device prepares for leaving a network it should send a Bye request to the remote DP. The DP acknowledges the Bye request through a Bye response message. 

 

Remote Probe 

An client configured for remote discovery sends probe requests directly to its home DP.The probe message is sent as a Web Services request operation from the client to the DP using the http binding (see [ONVIF DP WSDL]). 

Once the home DP receives a Probe message from any client, it responses with corresponding Probe Match message according to the normal WS-Discovery message exchange pattern,

 

5.3 MatchBy 

WS-Discovery 定義 MatchBy 至少應該要支援 

http://schemas.xmlsoap.org/ws/2005/04/discovery/rfc2396

但 ONVIF Core spec 修改此部分定義爲至少應該支援

http://schemas.xmlsoap.org/ws/2005/04/discovery/rfc3986

 

原文如下

 http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf P.21 :

/s:Envelope/s:Bo dy/d:Probe/d:Scopes/@MatchBy If omitted, implied value is "http://schemas.xmlsoap.org/ws/2005/04/discovery/rfc2396".

 

http://www.onvif.org/specs/core/ONVIF-Core-Specification-v250.pdf P.41 :

An ONVIF compliant device shall at least support the http://schemas.xmlsoap.org/ws/2005/04/discovery/rfc3986 scope matching rule. This scope matching definitions differs slightly from the definition in [WS-Discovery] as [RFC 2396] is replaced by [RFC 3986].

 

參考：

[1] ONVIF-Core-Specification-v240.pdf chapter 7  
[2] wsdd-discovery-1.1-spec.