What Would You Like To Ask ONVIF?

Our ONVIF tutorial generated a lot of (frustrated) feedback about using ONVIF, including our own about their historic poor communication.

ONVIF is setting up a call with us to talk details. What questions do you have? What would you like us to ask?

Some topics we definitely plan to raise:

  • How does one know which combinations will work?
  • How can we troubleshoot or identify what makes an ONVIF integration not work?
  • What differences exist between ONVIF versions (like 1.01, 1.02, 2.20, etc.) and what impact does that have?
  • Where is ONVIF going and how is recording support working?

What else?

[UPDATE: March 7th - The ONVIF call is on for next week. Here is the list of 19 questions we plan to ask, based on your input.]


Is that a question for us or for ONVIF? Also, can we have questions that contain at least a verb and a noun?

Careful what you ask for...

Never mind. I was thinking of a verb and a pronoun ;>)

Now you guys are all shy??? Come on, speak up. Seriously.

Oh man. Where do I start? Good question. I would love to see Onvif really push ahead and become mainstream, in my opinion if they could get all Onvif products to work with motion detection, audio, PTZ, alarm config, and most of the other basic stuff then that would be great for the IP camera market. Everything is so up in the air right now whether one product will work with another. It would be nice to just know if they work. I cant trust that a camera will work with an NVR just because they both say they are "Onvif". Its no guarantee that they will work, and this pisses me off. This is a great topic.

My questions:

#1) Why dont you make/push your Onvif members require that they stay up to date with their Onvif Compliance. AKA: make people push carry Onvif 2.2 instead of just lingering around with 2.0 or 1.xx. Either that, or atleast tell your members to explain which Onvif version they are using on a particular product so we will know what features will work.

#2) Are you making this easy enough for manufacturers to implement?

#3) What are you doing to market this standard to manufacturers? Are you sure you are marketing it aggresively enough and thoroughly communicating with your members about updates?

Sean, good questions. #1, to me, is the most critical, as it likely gets at the specific root causes of interoperability issues.

My questions: How often does ONVIF communicate with camera manufacturers? Does ONVIF actually fail any cameras from being branded ONVIF "compliant"?

Steve, good questions. I'll ask. As for #2, about failing, my understanding is that manufacturers self certify. There's a tool used to connect / verify ONVIF conformance. The device needs to pass the verification test. If it does the manufacturer fills out a report, confirms that the device passed the test, and ONVIF adds it to the conformant list.

That's my understanding of it. You can see these documents via links from the individual supported devices pages. This is an example from Bosch's 1080p Dinion. Note how few parameters it lists there: PTZ, Audio, and I/O.

Ethan, I thought Profile S forced them to test/verify more device features than that, e.g., motion detection.

Other question that document raises is the significant of the "ONVIF Device Test Tool Version". The Bosch test lists 11.12 which begs the question what happens for devices tested with 11.11 or 11.13, etc.?

What, if anything, are they doing in regard to integrations with access control and burglar alarm systems?

Why one more item to integrate, update ,change with versions , and have soft lock ups with? Make it ease to update, easy to make changes, and easier to use. Fewer the the steps the better. Pt. , Click , Complete

Rick, good question. We'll ask them about status and timetable on access control / alarms.

Christopher, the reason for 'one more item' is because that item is supposed to eliminate the need to worry about lots of other items that update, change, have issues, etc. Obviously, the question is can they deliver on that across the board.

When will ONVIF support NVR and IP Camera under different segment of network, like different subnet, or IP camera connected via WAN?

Alex, you can certainly connect cameras and NVRs across networks. Just enter in the IP address of the camera into the NVR and it will find and connect to the camera as long as it can be reached.

That said, I suspect you are asking about device discovery, yes? ONVIF uses WS-discovery and like pretty much all discovery protocols I am aware of, they only work on the local network as routers drop though packets. Does that make sense? Are you asking about something different?

Alex - I believe I saw a discovery proxy mechanism described in the spec. So technically discovery across subnets should bo doable, however the use case is probably pretty narrrow (enterprise deployments and widely distributed networks).

I think John and Sean covered it...I'd like to hear their pitch to a manufacturer to spend $20K to come on as a supporting member of their board. I would think that to found something like this requires a good pitch to get a manufacturer involved. That is a lot of commitment from a manufacturer and their R&D team to really contribute and make a difference.

These are skelton questions...

- Does ONVIF have the ability to enforce any part of their business? If yes are they enforcing now?

- What method of enforcement does ONVIF have to correct manufacturers who are claiming to have a full implementation versus not having done so?

- Will the ONVIF board consider a secondary test lab to certify products as ONVIF S such as a lab that certifies an appliance for U.L. conformance?

David, good questions, we will add them to the list.

Btw, here's what I could find about membership levels, pricing and status.

Of the 436 members listed today, there are:

  • 18 full members paying $20,000 each
  • 22 contributing members paying $10,000 each
  • 396 user members paying $1,000 each

This page deliniates the 'privileges' for each level. Key diferentiators include: full gets you on to the steering committee, contributing lets you have input into the specification details and user justs lets you use it.

I would like to know if they plan on changing the way PTZ works. Currently, ONVIF communication uses SOAP communication, which is fine when you are just setting parameters on a camera.

When you are sending commands that you want responded to in real time (Pan, Tilt, and Zoom commands come to mind), then forcing the camera to parse a move command sent using SOAP is very inefficient and can lead to bigger lag. Some cameras, especially when using most of their processor already, have a hard time paring the command quickly. When using Axis and Sony, there is a difference in response times using ONVIF vs the native control protocol.

Also, I would like to know when they plan on having a real conformance test for VMSs:

Currently, the conformance test is to connect to two different ONVIF compatible cameras. But you can only connect to two cameras that are already on the conformance list, you have to use the same firmware that's listed in that cameras Declaration of Conformance, and you can then only declare the level of conformance that is equivalent to that cameras DoC.

This leads to a lag in adoption: Once ONVIF publishes a spec, it takes up to 6 months to release a new camera test tool. Once this is released, it still takes months before manufacturers begin adopting it. Since NVRs can't declare until there are cameras in the marketplace, it can take an NVR a year or more to fully update their ONVIF compliance. By then there's a new ONVIF specification version to work on.

Can this process be streamlined?

Things I think ONVIF should do:

  • Be extensible, expandable, and forward and backward compatible.
  • Release new versions on a specific schedule like Ubuntu does.
  • Release draft specs so we can get cameras and systems that support the new standard at a specific date, like 3 months after the spec is released.
  • List the differences between terms like supported, compliant, and actually useful.
  • Include motion detection, WDR, iris, color, saturation, firmware update, etc. Make it so that I never have to log into the camera interface again.

Can ONVIF comment on these?

Can they require VMS and camera makers to specify in the firmware/software what the ONVIF version is. So if I configure a camera channel in a VMS, and select ONVIF as the interface, I'd like to be able to immediately see the ONVIF version listed. Same if I log into the cameras interface with a webb browser or setup utility- I'd like it to display the ONVIF version.

Michael, Luis, Undisclosed, great questions. I am not sure what the answers are for these but I'd like to know myself as well!

- fill the need for a lightweight P/T telemetry mechanism (with mfgs building HD PTZs at varied price points, I am definitely seeing wide disparities in response times from web service calls, especially when the camera gets loaded down on the resource side)

- continue the focus on standard event definitions (2.2 and beyond), I believe the variance here was the root cause of many ONVIF VMD interoperability complaints in the past

Jon, thanks - very helpful!

Outside of the PT telemetry issues, are there any other specific performance problems with other functions via ONVIF?

Can you elaborate on standard vs non standard event definitions?

Don't count on discovery across subnets. It creates a level of traffic that most IT people don't like on their subnets, and many routers and smart switches may drop. (NetBIOS brodcasts, etc.) And if it's a closed camera or general security system network, wouldn't likely be needed anyways.

From an IT perspective, I think it would be asking a little much.

P/T telemetry is currently the biggest performance issue my team has seen. Specifically we're integrating an analog CCTV keyboard and the variance in the speed of the HEX commands coming out compared with the processing time of the HD IP dome is forcing us to do quite a bit of high level command buffer management (ex. clearing command buffer when the control stock goes back to 0 spot vs having the dome continue to process everything out). While in general there is no way of getting around this, the variance in response time to WS calls (200 - 1000 ms) makes it tricky. Load the dome down with HD compression, edge VMD, multiple streams and the situation gets worse.

While I don't have any syntax examples at the moment, my dev team has made several small tweaks in the past to accommodate variances between mfgs in event definition for VMD.

We have confirmed a call with ONVIF next week. We will be compiling a list of questions based on your recommendations (thank you - very helpful!).

Before the end of this week, I will post that list here for final feedback. In the meantime, if there is anything else you want to see covered, let us know.

Does ONVIF plan on leaving alarm and access integration to PSIA? OR do they have any plans on working in conjunction with PSIA? Why stop at cameras to VMS integration? Eventually I think it makes sense if standards, whichever one it is, embraces all levels from cameras, to recorders, or access, to alarm to environmental to monitoring. There's no reason why you can't have a common, standard intercommunication protocol between them.

We're going to ask them this, but in answer to your question, no, they're not going to leave it to PSIA. If I had to guess, what you just described is exactly what they're going to do. An input on a camera and an input on an access control panel are going to look the same. Metadata and Wiegand data are going to be transported the same way. I think it makes sense, and it can open up some doors (ha, punny access control joke) to simple integration. the problem is going to be getting access incumbents to jump on that bandwagon.

Ethan, Luis, what's challenging here is what they actually implement and how aggressive they are. Almost certainly the answer is that they are not going to leave it to the PSIA but how much are they going to do? They've been talking about it for a while but is it really a priority for them?

Are the problems and potential around Profile S going to be addressed in your call?

Testing Report Verification of performance increase vs. previous versions?

Lack of VMS Support? Estimates on adoption over previous versions & time-frame?

Tom, can you elaborate on 'test report verification of performance increase vs previous versions'?

A feature matrix of Profile S vs. previous versions.

Here's the 19 questions we plan to ask ONVIF next week, based on your input. Thanks again, please review and let us know if there is anything else to add.

Update - we had the call last week. It was very informative with a lot of interesting technical details explained. We are writing up the report and plan to release it next week (eta March 25th).

Thanks everyone for the great questions. We have released Detailed Technical Answers from ONVIF that provides important insights into a number of key issues.

If they are going to do integration than inputs and outputs is not an accepted method any more for serious projects. It has to be IP or RS232 or maybe one of the real building automation protocols like bacnet or modbus.