Happytimesoft

1. General
A client searches for available devices using the dynamic Web Services discovery protocol [WS-Discovery].
A device compliant with this specification shall implement the Target Service role as specified in [WS-Discovery].
If necessary a client compliant with this specification shall implement the Client role as specified in [WS-Discovery].
[WS-Discovery] describes the Universally Unique Identifier (UUID): URI format recommendation for endpoint references in Section 2.6, but this specification overrides this recommendation. Instead, the Uniform Resource Name: Universally Unique Identifier (URN:UUID) format is used [RFC4122].

2. Modes of operation
The device shall be able to operate in two modes:

•  Discoverable
•  Non-discoverable

A device in discoverable mode sends multicast Hello messages once connected to the network or sends its Status changes according to [WS-Discovery]. In addition it always listens for Probe and Resolve messages and sends responses accordingly. A device in nondiscoverable shall not listen to [WS-Discovery] messages or send such messages.
The devices default behaviour shall be the discoverable mode. In order to thwart denial-of-service attacks, it shall be possible to set a device into non-discoverable mode.

3. Discovery definitions

3.1 Endpoint reference
A device or an endpoint that takes the client role should use a URN:UUID [RFC4122] as the address property of its endpoint reference.
The device or an endpoint that takes the client role shall use a stable, globally unique identifier that is constant across network interfaces as part of its endpoint reference property. The combination of an wsadis:Address and wsadis:ReferenceProperties provide a stable and globally-unique identifier.

3.2 Hello

3.2.1 Types
An ONVIF compliant device shall include the device management service port type, i.e. tds:Device, in the <d:Types> declaration. The following example shows how the type is encoded in the SOAP Hello body:

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

The Hello message may include additional types.

3.2.2 Scopes

3.2.2.1 General
An ONVIF compliant device shall include the scope <d:Scopes> attribute with the scopes of the device in the Hello message.
The device scope is set by using [RFC 3986] URIs. This specification defines scope attributes as follows:

The scheme attribute:onvif

The authority attribute:www.onvif.org

This implies that all ONVIF defined scope URIs have the following format:
onvif://www.onvif.org/

A device may have other scope URIs. These URIs are not restricted to ONVIF defined scopes.
A device shall include at least one fixed entry (defined by the device vendor) of the profile, hardware and name categories respectively in the scopes list. A device may include any other additional scope attributes in the scopes list.
A device might include an arbitrary number of scopes in its scope list. This implies that one unit might for example define several different location scopes. A probe is matched against all scopes in the list.

3.2.2.2 Example
The following example illustrates the usage of the scope value. This is just an example, and not at all an indication of what type of scope parameter to be part of a device configuration. In this example we assume that the device is configured with the following scopes:

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

A client that probes for the device with scope onvif://www.onvif.org will get a match. Similarly, a probe for the device with scope:
onvif://www.onvif.org/location/country/china

will give a match. A probe with:

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

will not give a match.

3.2.3 Addresses
A device shall include the <d:XAddrs> element with the address(es) for the device service in the Hello message. A URI shall be provided for each protocol (http, https) and externally available IP address.
The device should provide a port 80 device service entry in order to allow firewall traversal.

3.3 Probe and Probe Match
For the device probe match types, scopes and addresses definitions, see 3.2 Hello.
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].
A device shall include the <d:XAddrs> element with the addresses for the device service in a matching probe match message. The <d:XAddrs> element will in most cases only contain one address to the device management service as defined in 5.1.

3.4 Resolve and Resolve Match
This specification requires end point address information to be included into Hello and Probe Match messages. In most cases, there is no need for the resolve and resolve match exchange. To be compatible with the [WS-Discovery] specification, however, a device should implement the resolve match response.

3.5 Bye
A device should send a one-way Bye message when it prepares to leave a network as described in WS-Discovery.

3.6 SOAP Fault Messages
If an error exists with the multicast packet, the device and client should silently discard and ignore the request. Sending an error response is not recommended due to the possibility of packet storms if many devices send an error response to the same request. For completeness, unicast packet error handling is described below.
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 bound to SOAP 1.2 as follows: