Do services need to have capabilities?

[bartbutenaers]

Hey guys,

I'm having quite some troubles with users since I upgraded to the 0.6.5 version, and I 'think' it is related to this pull request. I created a workaround for most issues, but it would be nice if you could give me some feedback about below question. Just to make sure that I interpret the data correctly ...

At the moment, I am getting a mix of different configs:

1. My (older) Panasonic camera's only have capabilities (and no services), like they always did:

   

2. Another user has an unknown HiSilicon camera. This one has services (and undefined capabilities), and those services in turn have capabilities:

   

3. And yet another user has a ReoLink RLC-410W camera, which has services but those services have no capabilities:

   

Is case 3 normal? I would expect that all services have capabilities? Or is that not required perhaps?

Thanks again !!!
Bart

[bartbutenaers]

I now take into account in my code all the above situations, and everything seems to be functioning properly for all users (that had reported camera problems with the latest version). So I will close this issue...

[RogerHardiman]

Hi there
I was involved in some of the changes to use GetServices.
With GetCapabilities you cannot get access to the MEDIA-2 API which means you cannot get H.265 video which all my new cameras have.

You can read the XML definitions with this link [http://www.onvif.org/ver10/device/wsdl/devicemgmt.wsdl]
It tells me that the Capabilities field is Optional.
If you want the capabilities of each service, you have to call the GetServiceCapabilities API.
Those are called
getEventServiceCapabilities
getImagingServiceCapabilities
getMediaServiceCapabilities (that handles Media and Media 2)
getServiceCapabilities (which really means getDeviceServiceCapabilities)

So it is now a two step method needed.

[RogerHardiman]

We could automate this and generate a load of differenr getServiceCapabilities ONVIF requests for each event in GetServices.
Is that any use to anyone?

[bartbutenaers]

Hi @RogerHardiman,
Thanks for coming back on this!

It tells me that the Capabilities field is Optional.
If you want the capabilities of each service, you have to call the GetServiceCapabilities API.

I understand that. But by looking at the connect function code:

Which means a request is send, with a parameter to include the capabilities:

So I would expect the capabilities to be in the response message:

So it seems to me that the HiSilicon cam does it like that (see second screenshot in my original question above). But then I don't understand why the Reolink cams don't have capabilities per service...

We could automate this and generate a load of differenr getServiceCapabilities ONVIF requests for each event in GetServices.

So that would result in extra data to be loaded, compared to the ìncludeCapability parameter?

Perhaps it might be useful to introduce a new boolean option so developers can activate or deactivate automatic calling of getServiceCapabilities per service, to avoid an overload of requests for use cases that don't require this data?

[RogerHardiman]

Hi there
Thanks for spotting that flag for includeCapabilities.
I'd missed that when reading the ONVIF spec yesterday.
So there must be a bug in the Reolink camera.

We have a design decision now. We can either say "this camera is rubbish" and leave the library like it is.
Or we can check if GetServices provided the Capabilities and if it failed (due to a camera bug) we can go and get them all manually by looking over each service in GetServices and calling GetServiceCapabilites on each XAddr and adding the reply into GetServices.

I don't have time to implement anything like this myself at the moment, unlesss I hit a buggy camera on one of my own projects.

But if someone wants to implement the fix, I'd happily review a Pull Request and merge it.

We've got so many cheap cameras on the market now that at some point we have to work with what our customers and end users have, rather than tell them to go and buy a camera listed on the ONVIF web site.

[bartbutenaers]

Yes indeed the number of cheap camera's is increasing, which probably won't implement the entire Onvif spec correctly. And if we decide to stick to the standard, we won't be able to support all those users. Which would be a pitty...

I will add this to my (long) todo list. But probably won't be soon. So if anybody else has time meanwhile, please be my guest!

[bartbutenaers]

Hi guys,
Only for completeness, if anybody ever needs it.

Got a complaint yesterday that (for TP-Link Tapo C200 camera's) my application didn't detected the services correctly.
After connecting to the remote cam and some debugging, it appeared that those cams return their service names in the namespace instead of the XAddr field:

So for these camera's all the XAddr fields contain the same content....

[RogerHardiman]

Having the exact same "service" field may be correct.
What it tells you is that you can send any ONVIF command to http://yourIP:2020/onvif/service
You don't have to send ONVIF commands off to different URLs depending on PTZ or Imaging or Device features.

As the XML contains the full ONVIF command and namespace the http server can easily work out what the ONVIF command is.
It does not need to be 'listening' on lots of different URLs.

So where you put "no service name", actually they do look like Service URLs and they look fine but just happen to be all the same.
May be worth me having a look at a C200 with you for some debugging.

[bartbutenaers]

Hey Roger,
Thanks for the clarification! Now it makes sense.
The user has already disconnected his cam from the web, and it works fine now.
So no need for you to debug. But thanks for the offer !!!

[RogerHardiman]

So is the C200 working fine with the library now?

Just checking as I was thinking of getting one for a little indoor camera
Roger

[bartbutenaers]

Yes he told me it was fine now. I was doing an incorrect check on the namespace/XAddr fields, but after fixing that bug in my code it seemed to be fine. Was only mentioning it above for completeness...

[RogerHardiman]

Did we still need to do something for the cameras mentioned in the original post?

I've lost track of where we are with this problem report

[bartbutenaers]

Hey Roger,
I think we can close this issue. There are lots of differences between the cams, but I think this library works fine. I have done some updates on my side, and now this lib does a good job.
Thanks for the follow-up!
Bart

[RogerHardiman]

thanks for the update. If there is anything you want to push down into the library, we are always happy to receive contributions.