some problems of search cam

[agsh]

some problems of search cam

[RogerHardiman]

I checked the source of ONVIF Device Manager on SourceForge to see how they do Discovery.

The correct procedure on Windows is to make some calls to the Microsoft System.ServiceModel.Discovery service API. Microsoft then handle port 239.255.255.250 data and pass results back via the Microsoft API.

So right now there is no way that Discovery will work reliably on Windows without a lot of Microsoft specific code.

As a result I'm going to close this issue.

[agsh]

Hello!
Probably you should use events because camera can send response later than timeout is over.
Another way is to run probe several times, maybe the problem in your network?

[RogerHardiman]

I would like to add to this Issue Report

1. Windows 10 machine.
   I am using the code below.
   First time I execute it I can find the ONVIF devices on my network (3 of them).
   Next time I execute it it does not find any devices.
   I can run it over and over and it never finds any more devices, but then after a while it does get replies from devices but then no longer receives any more replies. Clearing the ARP cache (arp -d *) made no difference for me.
   Tested with node 0.12 and node 4.4.4

2. At the same time I run the example on my Raspberry Pi and it detects the devices every time.
   (with devices detected within 2 seconds)

So something related to Windows.

var onvif = require('./lib/onvif');
onvif.Discovery.on('device', function(cam){
    // function would be called as soon as NVT responses 
    console.log('received discovery message');
    console.log(cam.hostname);
    console.log(cam.port);
    console.log(cam.path);
})
onvif.Discovery.probe();

[agsh]

This is very interesting. As you can see in the code, there is nothing else sending udp packet and listening the response. I haven't got any Windows machine, so let this issue being open.

[RogerHardiman]

I have looked at the source of another node wsdiscovery package. One thing they do a close of the udp socket when discovery is over. Will need to try it.

[agsh]

But there is close method at line 142 in discovery.js. I don't know where to dig.

[RogerHardiman]

sorry, I had missed the close on line 142. It was just a guess.

Anyway I ran wireshark. The first time I run my test program I can see that Windows transmits the UDP broadcast packet to 239.255.255.0 and the test program gets a reply from ONVIF devices.

Next time I run the program there is no reply from ONVIF devices and wireshark tells me the UDP broadcast packet was not sent.

Windows does do WS-Discovery too, so perhaps something in windows is preventing port 3702 from being used,

[RogerHardiman]

I've written a really small program to send UDP packets on 3702 239.255.255.0.
Some times the packets leave. Some times they do not. It looks like some other process in Windows is causing problems.

[RogerHardiman]

I wrote a small C# program to send UDP packets on 239.255.255.0. On my Win10 box they are transmitted for a while, then stop being transmitted.
So there is something windows specific here. I wonder if the proper Windows way is to register with some MS discovery service and let it handle the packets.

I think we can close this and simply say that Discovery does not work on Windows right now