问题
I have a unit running python that needs to use ws-discovery to locate onvif cameras that may be on different logical networks. Does anyone know if this is possible?
(I got discovery on same logical networks working using this library: https://github.com/hlamer/python-ws-discovery/blob/master/WSDiscovery.py)
After a bit of searching, I came across 'remote discovery proxies' which sounds promising, but I cant figure out what they are exactly.
回答1:
ONVIF Core specification Section 7.4.2 Discovery Proxy describes how to set up an DP. However, in my experience, I have not found any ONVIF cameras that support remote discovery, most likely because, to do so, the camera would have to act as a gateway supporting the proxy protocol. So, at present, in practice, ONVIF remote discovery is not possible.
回答2:
I stumbled upon this question by accident and was disturbed that only answer by Ron Woods is incorrect and plain misleading but still marked as accepted answer. So despite that this question is three years old I decided to provide correct answer for anyone who is going to read it in the future.
ONVIF Core Specification provides condensed description about what Discovery Proxy is and does not provide full details about its operation. Reason for it is quite simple: ONVIF spec DOES NOT define it. ONVIF is mere user of another standard: Web Services Dynamic Discovery (WS-Discovery) Version 1.1 . In turn that specification uses another standard: SOAP-over-UDP Version 1.1 . And as ONVIF has nothing to do with Discovery Proxy (apart from using it) no camera is required to act as a gateway for the proxy protocol. Discovery Proxy in reality is just another service which runs on some system on local network.
Let's see why Discovery Proxy may be needed and is good solution if you want to discover Web Services (and ONVIF is just one of them) across boundaries of local networks.
At the heart of WS-Discovery lies SOAP-over-UDP protocol using multicast IP address. Choice of this technology is simple: UDP is lightweight and does not require connection establishment, IP multicast is very efficient way of delivering a datagram from one sender to multiple recipients. Unfortunately IP multicast packets generally are not routed and stay inside local network. Additionally multicasting may put a strain on a local network if it is over used. But despite down sides we have what we have: end devices required to listen to multicast messages delivered by UDP/IP and respond accordingly. This limits WS-Discovery to local networks only.
In addition every end device is required to send multicast message "Hello" when it joins multicast group and expected (but not required) to send multicast message "Bye" when it leaves multicast group.
It makes all natural to have some service on a local network which tracks these "Hello" and "Bye" messages and may probe local network periodically but not too often to keep network load to a minimum. This service is known as Discovery Proxy.
In fact Discovery Proxy is pretty much the WS-Discovery client but with two major additions:
Discovery Proxy is required to send "Hello" message immediately as it receives multicast probe message. This allows new clients know that there Discovery Proxy available on the network and client may save some resources and ask Discovery Proxy instead of doing multicast probing next time.
Make available information about all devices (those which were discovered by Discovery Proxy before hand) to anyone who requests it but this time it uses SOAP over HTTP (and thus over unicast TCP/IP). This reduces load by end clients because all they need to do is connect to Discovery Proxy over reliable TCP connection and scoop up list of all available end devices in one go.
As side effect use of HTTP by Discovery Proxy makes it possible to execute WS Discovery probes over internet. Discovery Proxy is just another web server!
Discovery Proxy uses exactly the same SOAP WSDL as any end device and so all is required from WS-Discovery client is to use HTTP SOAP binding instead of UDP SOAP binding to achieve the same result but much more efficiently and across the internet.
So where you can get Discovery Proxy you would ask. Ways to have it are:
- It may be a service in your router (not really common these days unless you have high-end router)
- You may create your own easily (you have made your own WS-Discovery client using WSDiscovery.py already). In this case you already have a list of all locally discovered services. Now all you need to do is make HTTP bound SOAP server which will send out these discovered services to your WS-Discovery client running elsewhere.
来源：https://stackoverflow.com/questions/29370598/ws-discovery-for-cameras-on-different-logical-network