With Profile Q, a device will not have any default password and when one first connects, in a default state, you are then required to setup a password.
ONVIF Profile Q Aims To Change Discovery and Default Passwords
ONVIF is gearing up to release a new profile, called Q.
They market it as providing "quick configuration and installation, providing innate discoverability and reliable device monitoring and event management capabilities."
- How is Profile Q different than the current Profile S?
- What are the big changes / additions in Profile Q?
- How will requirements in discovery and default passwords impact manufacturers and systems?
Inside, we answer these questions based on a discussion with the engineers contributing to this upcoming Profile.
Just a question and a few notes:
question: "Eliminates requirement of time synchronization which has caused connectivity issues." - are you talking about requirement to device to have NTP ON, or requirement to use HTTP-Digest (that is not so fragile to time syncronisation), or something else?
note1: from ONVIF press-release they say about 6 month validation period, and keeping in mind (a) their tick-tack scheme of releases winter/summer and (b) their practice of having something implemented by key players before releasing drafts, there is a high probability that there will be devices with official Profile Q conformance at the end of this summer.
note2: ONVIF-style Discovery is also an obligatory part of Profile S, but Profile Q requires it to be turned ON by default and after so-called "hard factory reset". In conunction with DHCP/ZeroConf, ONVIF client can reliably discover all new devices and there is no need for manual IP assignment
note3: the easiest position have manufactures that have no own VMS - they do not need any significant changes (as all features of Profile Q should be already in-place). Issues that you are highlighting are more not about devices itself, but about infrastructure/ecosystem.
is ONVIF manufacturer driven?
the short answer is yes.
long answer: It is driven by a small group of active members (about 20 companies - if you look into most of onvif specs, you will find the same names), and direction appoved by all full and contributing members (about 50 companies). Details can be found on their site, in rules of membership and in organizational structure.
Regarding ZeroConf and the "169.xxx.xxx.xxx" addressing point. They are not the same thing. The "169.xxx.xxx.xxx" is called "Link-Local" and is the self-assigned address you get when no DHCP server is availablea and you don't have a static addess.
ZeroConf is a way to announce and/or discover what address you DO have, whether it's DHCP, Static, or Link-Local, using multicast DNS (mDNS). However, before ZeroConf, Link-Local addresses were, in my opinion, not useful, because what good was having a device get an address on the local network if you couldn't find out what it was.
does it require hostname to resolve ip address? - seems yes.
how common for cameras to be shipped with different hostnames? - seems no.
and onvif cliens are using ws-discovery to navigate local network devices, and it know nothing about ip address origin.
so from onvif perspective - zeroconf is just linklocal, moreover their specs sometimes refer it as linklocal instead of zeroconf.
i am even not sure that devices that are claiming zeroconf functionality have mdns inside.
Zeroconf is, at its core, network service advertisement and discovery using multicast-DNS.
Link-local addressing predates Zeroconf discovery by almost a decade. Windows has supported it since Windows 98. I would say that most people's first exposure to it was when their Windows machines couldn't connect to the network, they checked their settings and saw an address beinging with 169.xxx. I know I did, I did not know what the 169 meant until years later. Link-local is often thought to be part of Zeroconf, because they're often used together. That, and link-local addresses are useless unless there is some discovery method in use, so I think that's why they are often confused.
A few years back, I implemented Zeroconf on Mercury's access control boards. I would be very interested in how other devices implemented it. That said without mDNS, a device should not be claiming Zeroconf support.
practically the same for me. Never heard about it until now, while seen 169... quite frequently.
but let me repeat - onvif is using ws-discovery which is MS way of doing the same thing using multicast but with xml flavour. And it is not using hostname but is using service uid, which is unique (typically MAC-based). Which toheter are doing profile q magic - working just from the shelf.
i have an ssh access for a few cameras from different vendors - so tomorrow i will check them for mdns support.
I'm surprised that there's no mention in the article about Profile Q's support for Transport Layer Security with secure communication via certificate/key authentication between device/client.
Any reason for this omission? I was under the impression that secure comms was a big part of Profile Q.
imho because tls is optional for this profile. Practically, profile q is focusing on device first 5 minutes after first out-of-the-shelf power up. So if device support tls, profile q dictate howto exchange/create keys.
if you need tls - please wait for profile a, that is focusing on really secure communications.
Profile Q requires the manufacturer to enable TLS if the device supports it. It is known as a CONDITIONAL requirement. We expect all future profiles will also be able to also leverage Profile Q conformant to allow the quick install elements and the advanced security elements that are available there.
Ah, that would make sense. Thanks for the info.
Official ONVIF Response:
Q: Does it require hostname to resolve ip address?
A: This is DNS. Covered in section 7.2.1. So, yes.
Q: How common for cameras to be shipped with different hostnames? - seems no.
A: Regardless of how a camera is shipped, hostname -> IP address is dependent on an installer setting up DNS records.
Many manufacturs ship cameras with the hostname set to model-serial (e.g. MODEL-SERIAL).
Q: ONVIF clients are using ws-discovery to navigate local network devices, and it know nothing about ip address origin. How does Profile Q help?
ONVIF clients broadcast a WS-Discovery PROBE request over multicast. Cameras respond with their scopes.
When a WS-Discovery device joins the network (boot, CAT5 connection, etc.), it broadcasts a WS-Discovery HELLO over multicast. Clients can listen for these packets, and immediately send a PROBE to the specific device to determine if it’s of interest.
Q: So from an ONVIF perspective - zeroconf is just linklocal, moreover their specs sometimes refer it as linklocal instead of zeroconf. Whats the difference?
A: ZeroConfiguration and IPv4 LinkLocal are used interchangeably, although technically IPv4 LinkLocal is just a subset of ZeroConfiguration. The ProfileQ spec intends for ZeroConfiguration to be defined as IPv4 LinkLocal (from Section 9: “… IPv4 Link Local Address (defined as ZeroConfiguration capability) …”).
Q: Do devices that are claiming zeroconf functionality have mdns inside?
ZeroConfiguration includes the concept of multicast DNS. IPv4 LinkLocal does not. Profile Q intends the latter.
Let us know if you have any more questions!
Thank you A for official clarification. I was not hoping that my rhetoric excersise about mdns redundancy will have a such direct reaction.
btw, as you are representing manufacturer and you are undisclosed: may you put the light on the real pain level of upgrading existent product to profile Q? was it hard/easy for you? or maybe you are not aiming this profile at all?
Manufacturers who have a good ONVIF Profile S, G or C implementation already may find Profile Q a very incremental addition to their product's capabilities. In other words they may very well be supporting the majority of functions specified already.