Camera not discovered because it uses the prober's message id for its response message id

[tom24]

I ran into a camera that did not show up when I ran the command line tool wsdiscover.

On further investigation I found that when the camera responds to the probe it uses the same uuid for messageID as that used in the probe! I don't think this is right but then again there is no absolute guarantee that uuid's will not clash. [I did mod the code to change the uuid and saw the response also had the change].

In the current code, in threaded.py, on line 181, commenting out the continue allows the camera to be discovered. A side effect is that the probe echo gets processed as a response and results in

WARNING:daemon:could not find handler for: _handle_probe

for that particular message.

The seen Ids are kept in _knownMessageIds which is "preloaded" with the Id of the probe message. At first I thought the fix could be just to prefix the address and port to the Id similar to what you do for the instanceId. But the preloaded value to the _knownMessageIds set has address of the destination (239.255.255.250) and the response has the address of the local interface, Thus they do not match and you still get the warning.

I don't have experience with many different cameras and this is the only one I saw this problem on. However, it can be successfully discovered by other tools.

The solution i envision is.

• Don't bother with preloading _knownMessageIds.
• Prefix address and port to messageId before adding to _knowMessageId (in case there are two of these cameras out there)
• "continue" on any message that is not a probe type

[andreikop]

Hi @tom24
Are there some instructions how to handle such cases in the WS-Discovery standard?

[jjehl]

I can't tell you about ws-Discovery standart but a lot of Chinese camera seems to behave like in the description of tom24 (Jeinu first price Chinese camera does, maybe not a standart for sure ...).

[gbrchill]

Just run into similar problems discovering my cheepo Chinese PTZ dome camera. A message is coming back without an instance ID. This causes the message ID to become known and then the next message that is the one that has the instance ID gets ignored. Commenting out that continue, as referenced above allows the camera to be discovered. I am also seeing the discovery failing with DataVideo PTC140 cameras too (possibly for the same reason, that is harder to diagnose as I don't have regular physical access to those cameras.

Adding a stub _handle_probe() method to the Discovery class is enough to make the unknown handler message go away. However, that is quite possibly the wrong place to be solving that wrinkle.

[wpyoga]

This seems to be related to #66

I'm not super familiar with the WS-Discovery standard, but I'm assuming these cameras are violating the standard. However, in practice we should be able to work around this somehow.

@gbrchill (and also others) Is it possible to run a network capture and upload the responses coming in from your cameras?

[gbrchill]

I shall try to get the network capture, it may take a few days.

[wpyoga]

I've submitted a PR #75 . It adds an option --rt / --relates-to, which enables the use of the RelatesTo tag to recognize incoming messages (which are replies to our initial multicast message).

The problem is, some cameras respond to our probe with a wrong MessageId. Say our probe has MessageId of XYZ. The reply has MessageId of XYZ and RelatesTo of XYZ. Thus the RelatesTo tag contains the correct value, even though the MessageId is wrong. Also see my comment on the other issue: #66 (comment)

In my case, when testing without the --rt option, only 3 cameras are discovered:

$ wsdiscover -s onvif://www.onvif.org/Profile/Streaming | grep address:
 address: 192.168.202.78:8899
 address: 192.168.202.77:8899
 address: 192.168.202.71:80

With PR #75 applied and the --rt option specified, 9 cameras are discovered:

$ wsdiscover -rt -s onvif://www.onvif.org/Profile/Streaming | grep address:
 address: 192.168.202.61:2020
 address: 192.168.202.78:8899
 address: 192.168.202.77:8899
 address: 192.168.202.51:2020
 address: 192.168.202.50:2020
 address: 192.168.202.92:2020
 address: 192.168.202.90:2020
 address: 192.168.202.60:2020
 address: 192.168.202.71:80

Note that I have to specify the scope when discovering the cameras. This is due to #56 .

Also note that some cameras are still not responding properly, but that's another issue.

[gbrchill]

ONVIF Discovery.zip

Packet capture of the discovery process occuring from the application I am developing, showing a number of broadcast discovery attempts and the responses from the camera.

[wpyoga]

As of this writing, the current master should work for your camera. This is due to the merging of PR #75 .

If using the CLI, use this flag:

  -rt, --relates-to               Also use RelatesTo tag to recognize incoming messages.

If using the library directly, initialize the WSDiscovery object like this:

    wsd = WSDiscovery(relates_to=True)

You can find a more comprehensive example in cmdline.py.

So basically what the flag does is: for an incoming message, if its MessageId has been seen before, ignore it and check its RelatesTo tag.

Edit: Your camera responds to probes with an empty Probe tag. Its response is basically OK except for the wrong MessageId, and the \r\n in the returned Scopes tag content. Since it is just whitespace, it should be ignored by wsdiscover.

[gbrchill]

Thanks I shall go and give that a try shortly.

[gbrchill]

That has fixed my problem and I am now seeing the camera that wasn't discoverable previously.

[wpyoga]

Thanks! You might want to test it on other cameras that you have access too, as well.

[gbrchill]

I shall give it a test drive on the other cameras as soon as I have an opportunity, but that may take a while.

[gbrchill]

I can confirm that, with the fix, discovery is now working for DataVideo PTC-140 cameras too. Thank you.