相关文章：
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 所在的网路，可以将网路环境区分为四种。
- The device resides in one administrative domain (private) and the client resides in a public network.
- The device resides in a public network and the client resides in one administrative domain (private).
- The device resides in one administrative domain (private) and the client resides in another administrative domain (private).
- Both the device and the client reside in a public network.
原本的 WS-Discovery 并无法在上述的所有网路环境中都正常运作，因此 ONVIF 为了增加互通性(穿透NAT或Firewall)，对于 DP(Discovery Proxy)的定义做了下列扩充：
- DP 应该架设于 public network，
- Client 可以透过事先指定的ip位址或是透过 DNS 找到 DP，若是使用 DNS SRV lookup，则应使用 _onvifdiscover._tcp
- DP 主要的两种功能
- 接收 Device Hello/Bye 并回复，原本的 WS-Discovery并无此部分。
- 代替 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.