Open gregksurveillus opened 6 years ago
Would you happen to know why Wi-Fi connected devices fail to appear on ONVIF WS-Discovery? I am not able to figure it out. In order to detect wifi cameras I had to implement IP scanning in conjunction with WS-Discovery.
Any help not having to use ip scanning would be lovely :)
Make sure all the right ports and protocols are enabled on your Wi-Fi router.
We are probably going to roll our own implementation. This implementation does not appear robust enough to use in a production environment (we have installations with a large number of cameras).
We have had other issues that we can't specifically pin on this module, but when we remove it, the issues don't appear (things having to do with cameras on the network we're not trying to use, etc.).
@gregksurveillus do you mean open port 3702? I wonder why it works fine for ethernet connected devices but not WiFi...
Don't open ports to the outside on your router. Your firewalls on your computers need those ports open so the packets can get out. There are UDP AND TCP ports involved in ONVIF.
This is where the discovery service is documented on Wikipedia: https://en.wikipedia.org/wiki/WS-Discovery
To see if your network is set up right and working, you can use the ONVIF Device Manager (which is what the ONVIF standards suggests in some places within their own documentation -- it's a pretty rough standard when they have to write an implementation guide). https://sourceforge.net/projects/onvifdm/
Hmm thanks. I am developing cross-platform to support mac/windows. I looked at that source code and can't see anything special. I think my WS-Discovery is correct, but maybe my router needs some adjustments or the cameras change ONVIF ports when in WiFi mode. I will broadcast to all the ONVIF ports now and see if that helps at all.
The ONVIF Device Manager is your friend. If you can see it and manipulate it with this tool, your software should work if it's written correctly.
I can confirm I have similar problems as described above. I have two NIC's. This was perplexing because the very first time I ran, I discovered my (only) camera running on my ethernet connection. However all subsequent runs failed. I did try the patch suggested by @gregksurveillus - binding to my ethernet NIC. Again it worked once but never again.
I have resorted to @patrickmichalina solution (thank you for that!)
@jimudall if you find any issues with that library please file an issues ticket. Thanks for checking it out!
@jimudall How did the ONVIF Device Manager work? Did you try it?
@patrickmichalina We did like your implementation. I am suspicious there is something going on between libraries that neither of us control, or other unusual behavior that was causing us problems. We've come down to pinning versions of everything such that we never get a different version of a module unless we want to change it. I have built node from source, but I haven't had time to look for specific things within it at run time like putting out a request on all the ports (which is what is documented in the node documentation, but not what is observed).
Are your problems on Windows or Linux. Windows is a pain when it comes to multicast and which adapter to use. Under Linux you can bind to All but windows you have to bind to an IP/adapter. In effect you have to workout the "best" adapter/IP to use or bind an instance on each adapter/IP.
works great !!! thanks a lot !!!
I have a machine with multiple network interfaces.
For UDP Datagrams the Node Documentation states for socket.bind([port][, address][, callback]): "If address is not specified, the operating system will attempt to listen on all addresses. "
Notices the word "attempt." They may "attempt" to do that in the case of your software implementation, but it appears their "attempt" failed.
If I modify the code in Onvif.prototype.startProbe = function(callback) {
To make it look like this:
Where the desired interface is at "10.1.254.55", the software can find cameras, etc.
We could plagiarize the "onvif" package (their _udp socket is called socket) to provide options for discovery/probe (note that Array.prototype.some probably only calls bind once, but the end result is that the socket is indeed bound to an interface that seems to work):
Note that the "10.1.254.55" above is the value of address.address from the other onvif package.