Discovery methods supported by ONVIF devices

The very first operation required after connecting a brand new unit to the network is the IP address configuration.

By factory default, the unit can use either a static IP address (e.g. 192.168.0.100) or it can be DHCP enabled. In the second option, the device will send a request as soon as it is plugged to the network, asking the DHCP server to provide all the network configuration parameters to be used (typically: IP Address, Subnet Mask, Default Gateway, DNS Server, NTP Server).
What if no DHCP server is available? The unit can fall back to use a factory-default static address, or it can use a ZeroConf IP address in the 169.254.0.0/16 subnet.

More and more devices are both DHCP and ZeroConf enabled as a standard setting. This is going to avoid network conflicts when many identical units are powered-on at the same time for the first time after the installation. If a DHCP server is configured on the network, it will take care about all the requests, assigning the devices with a different address. If not, the units will set themselves with their own 169.254.x.x address, using the self-configuration ZeroConf algorithm.

Both DHCP or ZeroConf lead the devices to use an unknown set of addresses, which needs to be discovered to go on with the system configuration. Typically a unit must be accessed using a web browser to set additional parameters, or it has to be added to a Video Management Software (VMS).

Such operations require the device's IP address to be well known. That's why a discovery tool is usually necessary to find out which address the machine is accessible from.

All Videotec's ONVIF devices provide two standard discovery protocols: WS-Discovery (Web Services Dynamic Discovery) and UPnP (Universal Plug-n-Play).

Such protocols are both based on SSDP (Simple Service Discovery Protocol), which works over UDP and Multicast.

With WS-Discovery, the discovery tool puts SSDP queries on the network from its unicast address to 239.255.255.250 multicast address, sending them to the well-known UDP port 3702. The device receives the query, and answers to the discovery tool's unicast IP address from its unicast IP address. The reply contains information about the Web Services (WS) available on the device, let alone the device's IP address itself.

The ONVIF Device Manager and the PTZ Assistant both use WS-Discovery to show the devices available on the local network.

UPnP works in a very similar way, but on a different UDP port (1900). Compared to the WS-Discovery, the UPnP is intended for a general use (data sharing, communication, entertainment).

Both protocols have a limitation that could impact on the ability to find the devices: discoveries are sent over multicast, replies are sent over unicast. It means that the device will receive the discovery query, but it will not be able to answer back to the discovery tool if the peers are working on different subnets.

Let's suppose that the PC running the discovery tool is configured on a static IP address (e.g. 192.168.0.127) because of the unavailability of a DHCP server; once powered, the devices will work on 169.254.x.x, with no default gateway set; to notify themselves, they should send a UDP packet from the 169.254.x.x to an address belonging to an external subnet (192.168.0.x). That's not possible without going through a gateway of course. With such conditions, probably the PC will find no devices on the network.

To avoid such occurrences, it is necessary to set the host where the discovery tool is running on the same devices' network conditions.

If the devices are supposed to use a ZeroConf address because no DHCP exists on the network, it is necessary to enable the PC with the DHCP as well, which leads to a ZeroConf address on that side also. Doing this, the PC and the devices will be set on the same subnet, they will be able to communicate using unicast, and the discovery tools will be able to find the devices properly.

Note that if your PC is configured with a static IP, it is not a good idea to add a 169.254.x.x as additional address: since the destination address for SSDP discoveries is a multicast, the source address selected by the network driver can be the wrong one, again leading to the impossibility for the device to send replies back.

Compared to WS-Discovery, UPnP has an advantage that can be exploited to find the devices on the network: UPnP-enabled devices send announcements using the multicast address on the network, and therefore it is enough to listen to such announcements to know which devices are currently active.

This can be easily done using Wireshark, configuring a capture filter as follows:
host 239.255.255.250 and udp port 1900

Announcements are received by the PC no matter how the network interface is configured.

Freeware UPnP discovery tools are available on-line also; check out this suite for example: UPnP Tools
It includes the Device Spy, which finds devices on the same subnet (for the above reasons...), and the Device Sniffer, which captures UPnP notifications (same job Wireshark does, made easier).

A final note: multicast packets are propagated inside a broadcast domain without particular configuration on the network appliances. It instead requires a specific configuration whether they need to go across a router, to reach a different destination network.
Therefore, it is always better run discovery procedures inside a broadcast domain.