Questions about ONVIF metadata streaming

[xtrdustin]

Hello,

I'm looking at using ONVIF metadata streaming to get real time PTZ status from our new Axis Q6215-LE camera, and have a few questions.

Backround

We have been using the ONVIF GetStatus command to get the camera's current orientation and zoom level. However, ONVIF requests seem to be rate limited to one request per second per client. Anything more than that (including trying to send an AbsoluteMove command to pan/tilt/zoom the camera in the same second) will result in one of the requests getting an error saying we're not authorized -- but we can retry the AbsoluteMove command and it works fine, so it's not really an authorization issue.

However, we need to show the camera's orientation in real time, and such a low polling rate makes our direction indicator look choppy, and having to retry the AbsoluteMove command can introduce lag for the user. In order to make it smoother and more responsive, we're looking into using ONVIF's metadata streaming capabilities. But I wanted to check before implementing it to make sure it was supported by the camera.

Questions

So I thought I'd ask a few questions before spending time implementing it:

1. Does the Axis camera support ONVIF metadata (specifically PTZ) streaming?
2. What rate does it allow streaming of PTZ status at?
3. Any tips on implementing client support for it in Java? Currently looking at the GStreamer library, but I'm open to suggestions.
4. Also, is there any way to increase the allowed ONVIF request rate?

Thanks in advance!

[svefredrik]

Hi,
We don't have any specific throttling of SOAP requests that I'm aware of. There is a limit on WS discovery requests to prevent using our cameras as a base for DDoS attacks but that should not affect normal SOAP request.

The "Not Authorized" error that you are getting leads me to believe that there is something else that is wrong. Are you using Username-Token Authentication by any chance? If that is the case the clocks between the client and the camera must be closely synchronized. If they are not well synchronized you could get the behavior you are describing where some requests are allowed and some not. Try to sync the clocks between the client and the camera and see if the "Not Authorized" goes away. Another way to fix this is to use HTTP Digest Authentication instead which is a good idea anyway since it's more secure and used in newer ONVIF Profiles like T and M.

Now to your other questions

1. Yes we support it. You need to enable this in the Metadata Configuration by setting PTZStatus=true.
2. Not sure, several times per second I think.
3. GStreamer has just gotten support for ONVIF metadata. It's in the main branch of GStreamer mainly in gst-plugins-rs (RUST plugins).
4. As I mentioned we don't have a limit.

BR /Fredrik

[xtrdustin]

Thanks! The information regarding the metadata streaming should be helpful. I'll take a look at that plugin.

Regarding the errors, the time difference was something I thought might be a problem, as that was the initial problem we had when we first started using the camera with ONVIF. However, we now get the camera's time with a call to GetSystemDateAndTime, and calculate an offset from the client's time, which we add in calls to future requests, so the time we send should be consistent with the camera's time.

I can look to see if we have a bug related to the offset calculation, but I don't think that's it, because it really does seem to be related to the rate of requests. If we sleep for 1100 milliseconds between GetStatus calls, we'll almost never see errors (except when we happen to send an AbsoluteMove request in the same second). If the sleep time is betweeen 750-900 milliseconds we see about 1 in 5 requests get the errors. And if we sleep for 100-500 ms, it will be more like a 50% error rate.

I'll look into HTTP Digest authentication as well.

[xtrdustin]

Another way to fix this is to use HTTP Digest Authentication instead which is a good idea anyway since it's more secure and used in newer ONVIF Profiles like T and M.

Why do you think HTTP Digest authentication would solve the problem? Doesn't it contain the same information?

Is it that HTTP authentication is handled by the camera's web server rather than its ONVIF/SOAP software?

[svefredrik]

HTTP Digest doesn't depend on the clocks being synchronized.

[xtrdustin]

I put in a support request for the HTTP 400 issue. There are packet captures at different polling rates in case you want to take a look. The case # is 02015133. Let me know if I should create a separate forum post for it, since this one was originally about metadata streaming.

[xtrdustin]

It sounds like you think HTTP Digest authentication is the way to go. I'll pursue that unless there's a better idea.

[xtrdustin]

We figured out the issue we were having. It wasn't the timestamp that was the problem, it was the nonce value. Under System -> Plain Config -> Web Service, we temporarily disabled "Enable replay attack protection", and that eliminated the errors. It turned out we were using the same nonce value generated at program startup. Now that we updated the code to generate a new nonce value per request, I'm no longer seeing the errors with the setting turned back on.

[svefredrik]

Good that you solved it. Just a note on security. Replay attack protection is really needed when using Username-Token Auth as CVE-2022-30563 has shown it's easy to make an exploit if it's not enabled. I still recommend that you use HTTP Digest though.