ONVIF protocol--ONVIF WS-Discovery (device discovery protocol)

1. Introduction to WS-Discovery

The full name of WS-Discovery is Web Services Dynamic Discovery. This technical specification defines a set of multicast discovery protocols to locate services. It works on TCP and UDP . The DISCOVERY_PORT is 3702 , and its IP multicast address is 239.255.255.250 (IPV4). Or FF02::C (IPV6). The mode of traditional Web Services service invocation is like this: the client knows the address (IP address or domain name) of the target service in advance at design time, and the client makes service invocation based on this address. What if the client does not know the address of the target service in advance? The WS-Discovery standard is used to solve this problem. According to this standard, the client can dynamically detect the available target service without knowing the address of the target service in advance, so as to call the service. This process is the process of "device discovery". The protagonist of this article, ONVIF, uses WS-Discovery as its device discovery protocol.

2. Introduction to unicast, multicast and broadcast

Before introducing the discovery principle of WS-Discovery, we first introduce the multicast used by WS-Discovery. The following figure shows a schematic diagram of unicast, multicast and broadcast:
Insert image description here
Unicast : Only two entities communicate with each other at a time, and the sender and receiver are uniquely determined. In an IPv4 network, 0.0.0.0 to 223.255.255.255 are unicast addresses. If you call Xiao Yueyue "Xiao Yueyue", then only Xiao Yueyue will turn around and agree to you.

Multicast : The word "multicast" is usually used to refer to IP multicast. IP multicast is a protocol that uses a multicast address to send data to multiple receivers on a TCP/IP network in an efficient manner at the same time. In addition, it is often used in combination with audio and video protocols such as RTP. Internet architect Dave Clark describes IP multicast like this: "You put packets in from one end, and the network will try to deliver them to the person who wants to get them." The destination address of the multicast message is used Class D IP address. Class D address cannot appear in the source IP address field of IP packets. If you shout "Beauty" on the street, a group of women will look back at you.

Broadcast : Usually, broadcasts are limited to LANs, such as Ethernet or Token Ring networks. Because the impact of broadcasting on a LAN is much smaller than that on a WAN. Both Ethernet and IPv4 networks use all-1 addresses to represent broadcasts, which are ff:ff:ff:ff:ff:ff and 255.255.255.255 respectively. Token Ring networks use a special value in the IEEE 802.2 control domain to represent broadcasts. If you shout "holiday" in the company, all your colleagues will respond. It's so cool to shout.

3. ONVIF WS-Discovery device discovery process

Before introducing ONVIF device discovery, we first introduce the three device roles defined in the WS-Discovery protocol. The three roles of device discovery are as follows: (1)
Target Service : This is a device that can make itself effective Discovery endpoint (the device can be IPC);
(2) Client (Client): This endpoint is mainly used to find Target Service (such as the program for NVR to discover IPC);
(3) Discovery Proxy (Discovery Proxy): Helps client discover The endpoint of Target Service, this endpoint is an optional component;

Device discovery is divided into two working modes, namely Ad hoc Mode working mode and Managed Mode working mode. The workflow of the two working modes is introduced in detail below.
Ad hoc Mode working mode:
Insert image description here
In Ad-Hoc mode, discovery messages are sent through multicast, and response information is sent through unicast; the specific workflow is as follows: (
1) When Target Service joins the multicast (239.255.255.250), then It first sends a HELLO message through multicast, and the client monitors the multicast HELLO message;
(2) The client sends a Probe message. If the Target Service matches the Probe message, then it sends a response message through unicast Probe Match (PM );
(3) The client sends a Resolve message. If the Target Service matches the Resolve message, then it sends a response message Resolve Match (RM) through unicast; (4)
When the device leaves the multicast, the Target Service needs to send a BYE information.
Through the above protocol interaction, the client device can discover the Target Service device. Of course, it mainly needs to carry enough information in the Hello signaling and Probe response to enable the client to discover itself. The specific content carried by the signaling will be introduced in detail later in the article.

When there is a discovery agent in Ad-Hoc mode, its working mode is as shown in the figure below:
Insert image description here

Managed Mode working mode:
Insert image description here
The following uses the Ad hoc Mode working mode to briefly introduce the overall encoding workflow:
1. The Target Service device joins the multicast group (239.255.255.250:3702) and must send a HELLO message and start a listening thread at the same time. , monitor the data on port 3702;
the HELLO information format is as follows:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:sc="http://www.w3.org/2003/05/soap-encoding" xmlns:dn="http://www.onvif.org/ver10/network/wsdl" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <s:Header>
    <a:MessageID>uuid:9328fd5b-4c83-4e4f-9850-66549c6d9136</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
    <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Hello</a:Action>
  </s:Header>
  <s:Body>
    <d:Hello>
      <a:EndpointReference>
        <a:Address>urn:uuid:4be6bccd-81c0-436c-b55e-173b8c8ec17e</a:Address>
      </a:EndpointReference>
      <d:Types>dn:NetworkVideoTransmitter tds:Device</d:Types>
      <d:Scopes>onvif://www.onvif.org/type/NetworkVideoTransmitter onvif://www.onvif.org/Profile/Streaming onvif://www.onvif.org/location/city/hangzhou onvif://www.onvif.org/name/ONVIF onvif://www.onvif.org/Profile/Q/Operational onvif://www.onvif.org/hardware/IPC</d:Scopes>
      <d:XAddrs>http://172.16.10.6:8000/onvif/device_service</d:XAddrs>
      <d:MetadataVersion>1</d:MetadataVersion>
    </d:Hello>
  </s:Body>
</s:Envelope>

2. Target Service starts to monitor Probe and Resolve information, and responds using unicast after processing Probe and Resolve. Generally speaking, Resolve information is not processed in the ONVIF protocol and does not affect the normal discovery of the device; the ProbeMatch information responded by the Target Service endpoint is as
follows , The content of d:Scopes contains the supported specifications.

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:sc="http://www.w3.org/2003/05/soap-encoding" xmlns:dn="http://www.onvif.org/ver10/network/wsdl" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <s:Header>
    <a:MessageID>uuid:42376302-2ea7-4de4-958b-bac7946b85ee</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
    <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</a:Action>
    <a:RelatesTo>uuid:d27939ba-5280-47aa-a96b-cadc561acc46</a:RelatesTo>
  </s:Header>
  <s:Body>
    <d:ProbeMatches>
      <d:ProbeMatch>
        <a:EndpointReference>
          <a:Address>ec8e74df-3f0c-4a91-8421-4015d971f98e</a:Address>
        </a:EndpointReference>
        <d:Types>dn:NetworkVideoTransmitter tds:Device</d:Types>
        <d:Scopes>onvif://www.onvif.org/type/NetworkVideoTransmitter onvif://www.onvif.org/Profile/Streaming onvif://www.onvif.org/Profile/T onvif://www.onvif.org/hardware/yyyy onvif://www.onvif.org/name/xxxx%20yyyy  onvif://www.onvif.org/location/country/chinaonvif://www.onvif.org/location/city/hangzhou</d:Scopes>
        <d:XAddrs>http://172.16.10.6:9990/onvif/device_service</d:XAddrs>
        <d:MetadataVersion>1</d:MetadataVersion>
      </d:ProbeMatch>
    </d:ProbeMatches>
  </s:Body>
</s:Envelope>

3. The Target Service device exits the multicast group 239.255.255.250:3702 (IPV4) and needs to send a BYE message;
the details of the BYE message are as follows:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:sc="http://www.w3.org/2003/05/soap-encoding" xmlns:dn="http://www.onvif.org/ver10/network/wsdl" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <s:Header>
    <a:MessageID>uuid:a2d826b0-df8b-40f2-b8c4-9bff66a530e5</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
    <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Bye</a:Action>
  </s:Header>
  <s:Body>
    <d:Bye>
      <a:EndpointReference>
        <a:Address>161ef348-69a8-4e6f-8165-aac29b3a7e6e</a:Address>
      </a:EndpointReference>
      <d:Types>dn:NetworkVideoTransmitter tds:Device</d:Types>
      <d:Scopes>onvif://www.onvif.org/type/NetworkVideoTransmitter onvif://www.onvif.org/Profile/Streaming onvif://www.onvif.org/Profile/T onvif://www.onvif.org/hardware/yyyy onvif://www.onvif.org/name/xxxx%20yyyy onvif://www.onvif.org/location/country/chinaonvif://www.onvif.org/location/city/hangzhou</d:Scopes>
      <d:XAddrs>http://172.16.10.6:9990/onvif/device_service</d:XAddrs>
      <d:MetadataVersion>1</d:MetadataVersion>
    </d:Bye>
  </s:Body>
</s:Envelope>

References:
《ONVIF-Core-Specification.pdf》
《wsdd-discovery-1.1-spec-os.pdf》
《https://blog.csdn.net/benkaoya/article/details/72476120》