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.