Understanding ONVIF specifications and versions

Question

My goal is to write a client for onvif ptz cameras such that I can view data (pan/tilt/camera/lens values), send control commands, and view the video. I was somewhat successful using C++/gsoap with an Axis camera. Then I tried it with a camera from a different company and it didn't work. I believe the problem is because that other camera uses a different version of "something" - I'm not sure if it is a different schema, different profile version, a different version of ONVIF, or a different version of soap.

I want to make a client that supports any ONVIF camera, or at least the vast majority of them. I don't want to have to say "Sorry, your camera is 1 year old and that protocol is no longer supported".

I was using onvifcpplib, which seems to have been abandoned for a bit and now its gitbhub project forwards to rapidonvif which looks completely different.

For almost two days now I have been researching ONVIF and trying to make heads or tails of what this will take. If I go here: https://www.onvif.org/profiles/specifications/specification-history/ I see no less than 18 different spec versions!

This version seems to affect wsdl file verions, so for example I can see there is a version 1.0 for the media wsdl here: http://www.onvif.org/ver10/media/wsdl/media.wsdl ... but there is also a version 2.0 of the same file here: http://www.onvif.org/ver20/media/wsdl/media.wsdl .

And I don't think they are backward compatible. But I cannot find one for 2.6 - so: http://www.onvif.org/ver26/media/wsdl/media.wsdl does not exist.

And this is just one of 15 wsdl files that I need to use gsoap with.

I'm really confused on what to do. Is there an ONVIF expert out there that can help me with some of these questions?

Question 1) Is there a master list or something that tells me as a client writer which wsdl versions I must support and which ones are not backward compatible?? Trying every possible permutation of all 18 versions with all 15 wsdl files would take forever! Some of them might be backward compatible and others not - how do I know which are which?

Question 2) On top of the network interface specifications, there are different profile versions. Are some of these not backwards compatible as well?

Question 3) On top of the network interfaces specifications AND profile versions, there are multiple versions of SOAP - 1.1 and 1.2. Do I need to worry about some cameras using 1.1, or does ONVIF always use 1.2?

Question 4) How am I supposed to compile with multiple versions using gsoap? If I use wsdl2h followed by soapcpp2 for version 1.0 and 2.0 of the ptz wsdl for example, and then try to include both into the same project there will be conflicts. I don't want to say to users... sorry, but you will have to research and find out if your camera uses ONVIF version such-and-such so you have to use this other executable or plugin.

Question 5) Even if I was able to get multiple versions to compile within the same app, how will I know which version to use when connecting to a particular camera? Do I query the camera and say "Which version are you? OK, you're using this particular version and profile, so I'll use this set of commands"?

Question 6) With so many variations and versions, how on earth can one be expected to write an ONVIF client that supports most cameras without spending months to years on development? Is there any third party library or sdk that abstracts all this versioning voodoo?

Thanks for any help you can provide!

Answer 1

1+2) A client can support whichever set of wsdl documents it chooses to, because only additions are made and no changes to types and operations are made. If I remember correctly, this is specified in the Core document.

3) Only SOAP 1.2 is used as far as I am aware.

4) I don't have a good answer, I wrote my own C++ code generator which dealt with these problems.

5) GetServices will return the version of the service the device provides.

6) It's not that bad... I think most features can be determined one way or another. There is definitely a lot of confusion prior to version 2.0. The main issues I have found are with implementations of the devices not following the specification.