Onvif probe

Forum for questions and support relating to the 1.34.x releases only.
Post Reply
racelife
Posts: 84
Joined: Mon Mar 22, 2010 11:38 pm

Onvif probe

Post by racelife »

I'm testing a new install of 1.34 on Ubuntu 18.04 server installed via "the easy way" script. When I click Onvif to probe for cameras to add it doesn't show any available could that happen because they are already associated or connected with other servers? I assumed that since the cameras can have multiple connections they would still show... I can add them manually but wanted to know if there is something else going on.
User avatar
iconnor
Posts: 2879
Joined: Fri Oct 29, 2010 1:43 am
Location: Toronto
Contact:

Re: Onvif probe

Post by iconnor »

ONVIF can be troublesome. Reasons for not detecting cameras are as follows:

#1 camera doesn't support ONVIF or does so in some weird way that we havn't coded for.
#2 the probe uses multicast. If your network doesn't support multicast, it won't work. (a network involving multiple cisco switches may not work for example).
#3 If your ZM server has multiple network cards, the multicast probe will only go out the one with a default route. I have added some code to specify which network card to use in master 1.35 but this is a work in progress.
racelife
Posts: 84
Joined: Mon Mar 22, 2010 11:38 pm

Re: Onvif probe

Post by racelife »

Probably something to do with the network... using a ubiquity router. I currently have 5 servers on the network, two running 1.30.4, one running 1..4, one running 1.34.6, and one running 1.35. the older versions tend to find the cameras via Onvif better than the newer installs which is half the reason I keep them around. The newest installs tend to be hit and miss on what comes up when probing Onvif if they find anything at all

Thanks for the help
jeremyenos
Posts: 10
Joined: Sat Apr 04, 2020 2:01 am

Re: Onvif probe

Post by jeremyenos »

This mention of multicast might be the hint I needed. I've been wondering why my Probe ONVIF never returns any cameras, while Tinycam on my phone, and ONVIF DM on my Windows PC seem to find them and function just fine.

I run Zoneminder out of a docker image ( https://hub.docker.com/r/dlandon/zoneminder ), which is using a bridge network. Perhaps I need to switch to macvlan to make it work?

I tried the Control Address I discovered by manually sniffing ONVIF DM, but it wouldn't work either w/ this camera brand. This method worked for my S3VC, but not this new one I've never heard of (Tyvance?) Looks a lot like a better featured YoLuke clone.

Anyway, any hint, shortcut, or workaround that would help me successfully probe without having to rebuild this whole container would be great.
I'm using version 1.34.22, and I think the container is Debian based.
jeremyenos
Posts: 10
Joined: Sat Apr 04, 2020 2:01 am

Re: Onvif probe

Post by jeremyenos »

I have results to report regarding multicast and docker. I didn't try --host=net because it's not a configuration I want, but I suspect it would work. In the meantime, where bridge networking failed, macvlan seems to get me further. I can finally run Probe ONVIF and get my cameras detected. However, after selecting a camera in the Monitor Probe panel, the next panel, Stream Probe, returns no results for one of my cameras (192.168.2.174 below).
Here are my probe results:

Code: Select all

root@0e80e4c86215:/# zmonvif-probe.pl probe
http://192.168.2.173:8080/onvif/device_service, 1.1, (type='NetworkVideoTransmitter', type='video_encoder', type='audio_encoder', type='video_analytics', type='ptz', name='IPCAM', hardware='HD-53NV1080HSD', location/country='china')
http://192.168.2.174:80/onvif/device_service, 1.2, (type='basic', type='audio_encoder', type='video_encoder', type='network_video_transmitter', name='ONVIF_CAMERA', location/country='China', type='ptz', hardware='IPG-8150PSS', Profile='Streaming', Profile='S', Profile='T')
http://192.168.2.173:8080/onvif/device_service, 1.2, (type='NetworkVideoTransmitter', type='video_encoder', type='audio_encoder', type='video_analytics', type='ptz', name='IPCAM', hardware='HD-53NV1080HSD', location/country='china')
http://192.168.2.19:80/onvif/device_service, 1.2, (type='Network_Video_Transmitter', type='video_encoder', type='audio_encoder', location/city='CSDN', name='csder', hardware='TEST_Onvif')
root@0e80e4c86215:/# 
It looks a little different than the others- perhaps that means there's a parsing failure here?
Probed on command line:

Code: Select all

root@0e80e4c86215:/# zmonvif-probe.pl profiles http://192.168.2.174:80/onvif/device_service 1.2 admin password
No results from GetCapabilities: <Fault xmlns="http://schemas.xmlsoap.org/soap/envelope/"><faultcode>SOAP-ENV:Server</faultcode><faultstring>Error deserializing message: 
syntax error at line 1, column 0, byte 0 at /usr/share/perl5/SOAP/WSDL/Expat/Base.pm line 79.
 at line 1 at /usr/share/perl5/SOAP/WSDL/Expat/Base.pm line 82.
. 
Message was: 
Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 391.
</faultstring><faultactor>urn:localhost</faultactor></Fault>
No media endpoint for client.
root@0e80e4c86215:/# 
Just to show that this command works on a different, older camera.

Code: Select all

root@0c5b783f9566:/usr/share/perl5/ONVIF# zmonvif-probe.pl profiles http://192.168.2.173:8080/onvif/device_service 1.2 admin farmer
MainStreamProfileToken, MainStreamProfile, H264, 1920, 1080, 20, rtsp://192.168.2.173:554/11
MainStreamProfileToken, MainStreamProfile, H264, 1920, 1080, 20, rtsp://192.168.2.173:554/11
MainStreamProfileToken, MainStreamProfile, H264, 1920, 1080, 20, rtsp://192.168.2.173:554/11
MainStreamProfileToken, MainStreamProfile, H264, 1920, 1080, 20, rtsp://192.168.2.173:554/11
SecondStreamProfileToken, SecondStreamProfile", H264, 640, 352, 20, rtsp://192.168.2.173:554/12
SecondStreamProfileToken, SecondStreamProfile", H264, 640, 352, 20, rtsp://192.168.2.173:554/12
SecondStreamProfileToken, SecondStreamProfile", H264, 640, 352, 20, rtsp://192.168.2.173:554/12
SecondStreamProfileToken, SecondStreamProfile", H264, 640, 352, 20, rtsp://192.168.2.173:554/12
root@0c5b783f9566:/usr/share/perl5/ONVIF#
ONVIFDM, Tinycam, etc all seem to have no problem detecting and operating PTZ on both old and new cams. Just ZM barfing on the newer one and I'm not sure why.

I'm not sure what the next step is.
User avatar
bkjaya1952
Posts: 282
Joined: Sat Aug 25, 2018 3:24 pm
Location: Sri Lanka

Re: Onvif probe

Post by bkjaya1952 »

jeremyenos wrote: Thu Jan 14, 2021 7:24 am This mention of multicast might be the hint I needed. I've been wondering why my Probe ONVIF never returns any cameras, while Tinycam on my phone, and ONVIF DM on my Windows PC seem to find them and function just fine.

I run Zoneminder out of a docker image ( https://hub.docker.com/r/dlandon/zoneminder ), which is using a bridge network. Perhaps I need to switch to macvlan to make it work?

I tried the Control Address I discovered by manually sniffing ONVIF DM, but it wouldn't work either w/ this camera brand. This method worked for my S3VC, but not this new one I've never heard of (Tyvance?) Looks a lot like a better featured YoLuke clone.

Anyway, any hint, shortcut, or workaround that would help me successfully probe without having to rebuild this whole container would be great.
I'm using version 1.34.22, and I think the container is Debian based.
When you use bridge network in docker Zoneminder , the camera probing can not be done. Instead of bridge net , if use
--network=host ,the camera probing is possible with Docker zoneminder . Please refer the following link.


https://hub.docker.com/repository/docke ... 7.4-mysql8
jeremyenos
Posts: 10
Joined: Sat Apr 04, 2020 2:01 am

Re: Onvif probe

Post by jeremyenos »

Thanks- yes, definitely doesn't work w/ bridged networking. However, as you'll see in a later post update- macvlan posed no issue and probing is working for a different camera. Just not one of them. I would assume it's the camera, except at least two other apps (ONVIFDM for windows and Tinycam for Android) have zero problem doing ONVIF PTZ control of this new camera- making Zoneminder's probe the oddball. Perhaps the SOAP parser on Linux could use an update? It's out of my depth at this point other than testing though.
Post Reply