ONVIF enforcing 'default' device requirement for discovery?

[bsriramprasad]

Background/Context

Device vendors communicate with integrator via 'Interface guide' with below information

• How ONVIF can be enabled OR
• Process to check/confirm if ONVIF is enabled by default.

If ONVIF is not enabled by default, the test operator does same steps as in interface guide to setup the device before conformance process is started in DTT.

Main issue comes with the requirement below

Ref: https://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf, Section 7.2

• The devices default behaviour shall be the discoverable mode.
• In order to thwart denial-of-service attacks, it shall be possible to set a device into non-discoverable mode through the operation defined in 8.3.19. (SetDiscoveryMode)

Problem Scenario

• Assume "device being NOT discoverable" is device "default" behavior
• Operator needs to set some configuration so that device becomes discoverable
  • like creating a user or some proprietary operation
• Then ONVIF is enabled on device for any further onvif API interactions.

For such a device setup/scenario, DTT test DEVICE-3-1-7 : SYSTEM COMMAND FACTORY DEFAULT SOFT does

1. Triggers SetSystemFactoryDefault with FactoryDefaultType as "Soft"
2. Expects device to be discoverable in 30 sec

But SetSystemFactoryDefault operation clears away all configs except IP settings and hence step 2 expecting the device to be discoverable (the setting operator made before conformance test start) seems to device default behavior as discoverable, which is again vendor/implementation dependent (some devices may be discoverable after soft reset and some may be not)

Workaround - 1

Modify test so that test doesn't fail even if device is NOT discoverable after soft reset

• Confirmed from test execution sequence that, this is the last test carried out in conformance process and device not discoverable can be ignored as test failure.

Workaround - 2

• Modify the technical spec to modify requirement as
  • The devices default behaviour SHOULD be the discoverable mode. OR
  • The devices default discoverable behaviour mode is vendor/implementation dependent.

Additional Note

• There is NO requirement in SetSystemFactoryDefault interface to expect device to continue in the discovery mode.

[kieran242]

@bsriramprasad Have you raised this also to @madhurao68 in the Testing WG to get Feed back from GRSE?

GRSE feed back is often very useful and vital input before we address this issue that you have raised.

Personally I feel that each ONVIF device that is being tested by the DTT should be in discoverable mode under WS-DISCOVERY if being tested by DTT or Taken out of a shrink wrapped box and switched on for the first time.

If you are saying that "SetSystemFactoryDefault" does not set the discoverable flag after being called then that is a bug that should be resolved on the Vendor side not in the DTT. The DTT tests ONVIF Conformance regardless of Vendor.

[bsriramprasad]

@kieran242

GRSE doesn't act independently and needs guidance from WG to do any test modification or spec clarifications and hence raised it here to enable discussion.

DTT should be in discoverable mode under WS-DISCOVERY if being tested by DTT

• Putting the DTT in discoverable mode can be a test operator setup step and need not be mandated from spec as that seems a bit encroaching into the vendor domain of what's the default behavior of a device after factory reset.
• Such setup steps are supposed to be clearly identified in the vendor's interface guide, otherwise ONVIF itself can make an interface guide (like a spec) that all members can adhere to?

"SetSystemFactoryDefault" does not set the discoverable flag after being called.

• Can you identify/point where does the spec say/clarify we need to do anything with discovery flag with this interface?

[kieran242]

@bsriramprasad While I respect your opinion and have agreed with you on many issues openly. I feel my opinion is valid and does count as per stated above in response to your issue.

"GRSE doesn't act independently and needs guidance from WG to do any test modification or spec clarifications and hence raised it here to enable discussion."

I am not a stranger to GRSE's function Sir!. And yes I feel a wider discussion is valuable and admirable.
While GRSE generally implement the request of the WG, TC and TSC, they very often offer a very good perspective upon issues of this nature that are not often thought about at the higher level when discussed and also have a unique perspective on the the DTT testing. I believe there opinion is very valuable.

"SetSystemFactoryDefault" does not set the discoverable flag after being called.

As you have stated it does not say explicitly! about discoverable flag but when a device is taken out of the box or set for discovery testing with DTT is is often switched on as a default hard setting (A basic customer expectation!.) so a device can be discoverable and thus should be maintained as a factory default on most devices as indicated as part of the command definition within the Core Specification. Again may be it requires that explicit clarification what are hard and soft values.

"SetSystemFactoryDefault". This operation reloads parameters of a device to their factory default values. The device shall support hard and soft factory default through the SetSystemFactoryDefault command.

[bsriramprasad]

@kieran242 Accept apologies if my comment sounded a bit rude.

Though I have no objection in seeking inputs from GRSE, I have seen from my earlier interactions they might come back to say 'What's WG opinion on this?' Anyways we can bring this topic to discussion to both tables.

When a device is taken out of the box or set for discovery testing with DTT is is often switched on as a default hard setting

• How such a setting is made/enabled (using proprietary interface or any means outside of onvif) is vendor specific and described in interface guide.

From the same section you quoted in core spec 8.3.8 SetSystemFactoryDefault, please find below text

The meaning of soft factory default is device product-specific and vendor-specific. The effect of a soft
factory default operation is not fully defined. However, it shall be guaranteed that after a soft reset the
device is reachable on the same IP address as used before the reset. This means that basic network
settings like IP address, subnet and gateway or DHCP settings are kept unchanged by the soft reset.

• DTT is testing 'soft factory reset' in DEVICE-3-1-7 : SYSTEM COMMAND FACTORY DEFAULT SOFT
• DTT can 'reach' the same IP accessing it, if needed.
• Discovery settings should stay on in soft reset is not defined and cannot be expected/enforced.

Given that ONVIF is gravitating towards cloud profile and pretty much the whole onboarding sequence falls into the vendor purview, we should be open to identifying these grey areas to make sure ONVIF doesn't stretch into vendor domain.

[MariaYa0091]

Hello!

The test was developed by Testing WG long ago, not by the test tool vendor. So it was the interpretation of specification from ONVIF.

In general my understanding is the following.

According to section 7.2 Modes of operation:
"The devices default behaviour shall be the discoverable mode."

It means default state: discoverable mode.

According section 8.3.8 SetSystemFactoryDefault:
"This operation reloads parameters of a device to their factory default values."

The scope of the soft reset is not defined clearly. But for my interpretation device parameters shall behave according on one of the following scenario:

• be reverted to factory default values, because it is in the scope of soft factory default
• stay unchanged, because it is out of the scope of soft factory default

So device suppose to be discoverable if it was discoverable before soft reset.

And even if DTT currently do not test hard reset due to inability to do this without manual action (there was such test before with manual actions). Camara shall support this as required by putting camera to discoverable mode. If it does not happened device probably could pass DTT, but will not be conformant. Make sure that device is conformant is also Device vendor responsibility.

See ONVIF Conformance Process Specification, 4.1 Role and responsibility:
"Successful testing using [ONVIF Device Test Tool] or [ONVIF Client Test Tool] is necessary but not
sufficient for claiming ONVIF Conformance. The Member is solely responsible for ensuring proper
implementation of [ONVIF Interface Spec] in accordance with the [ONVIF Profile Specs]. The
[ONVIF Test Spec] and the accompanying [ONVIF Device Test Tool] and [ONVIF Client Test Tool]
are available to assist in the conformance process but do not guarantee complete conformance."

I would suggest to change ONVIF Core specification so future profiles could go without such requirements. But for existing profiles test shall stay as is, because profiles have link to exact ONVIF specification version. From DTT point of view we could keep the test running only for devices that supports old profiles.

If changes to be done without ONVIF Specification update then we would like to have formal approval from TTWG to incorporate changes.

Hope this feedback will help you.

[sujithhanwha]

@bsriramprasad,
In my opinion, altering or removing the requirement stating, "The device's default behavior shall be the discoverable mode," may lead to issues with some client expectations. Changing this could force clients to rely on vendor-specific protocols or manual intervention for the initial setup, which we aim to avoid.

If any device vendor wishes to disable discovery by default and encounters issues with the conformance tool, they can consider making the discovery mode reset only during a hard factory reset and not during a soft factory reset? This approach may not affect the conformance testing.

[bsriramprasad]

consider making the discovery mode reset only during a hard factory reset and not during a soft factory reset.

If members are strongly against any update to spec, this is an acceptable and only workaround as we see.
Thanks for the suggestion @sujithhanwha