diff --git a/doc/Core.xml b/doc/Core.xml index 660e7f93c..9238b7bcb 100644 --- a/doc/Core.xml +++ b/doc/Core.xml @@ -295,6 +295,14 @@ Add support for JSON Web Tokens + + 25.06 + Jun-2025 + + Ottavio Campana + + Add support for user roles + @@ -435,8 +443,8 @@ Shinichi Hatae Canon Inc - Masashi Tonomura - Sony Corporation + + Takahiro Iwasaki @@ -507,74 +515,74 @@ Normative references IEEE 1003.1, The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition - <> + <> RFC 2131, Dynamic Host Configuration Protocol - <> + <> RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE) - <> + <> RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 - <> + <> RFC 2617, HTTP Authentication: Basic and Digest Access Authentication - <> + <> RFC 7616, HTTP Digest Access Authentication - <> + <> RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - <> + <> RFC 3548, The Base16, Base32, and Base64 Data Encodings - <> + <> RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses - <> + <> RFC 3986, Uniform Resource Identifier (URI): Generic Syntax - <> + <> RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace - <> + <> RFC 4702, The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option - <> + <> RFC 4861, Neighbor Discovery for IP version 6 (IPv6) - <> + <> RFC 4862, IPv6 Stateless Address Auto configuration - <> + <> RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage <> RFC 7519, JSON Web Token (JWT) <> W3C SOAP Message Transmission Optimization Mechanism, - <> + <> W3C SOAP 1.2, Part 1, Messaging Framework <> W3C SOAP Version 1.2 Part 2: Adjuncts (Second Edition) - <> + <> W3C Web Services Addressing 1.0 – Core <> WS-I Basic Profile Version 2.0 <> OASIS Web Services Base Notification 1.3 - <> + <> XMLSOAP, Web Services Dynamic Discovery (WS-Discovery)”, J. Beatty et al., April 2005. - <> - Mirror: + <> + Mirror: OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) - <> + <> OASIS Web Services Topics 1.3 - <> + <> OASIS Web Services Security UsernameToken Profile 1.0 - <> + <> W3C Web Services Description Language (WSDL) 1.1 - <> + <> W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures - <> + <> W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes - <> + <> W3C XML-binary Optimized Packaging - <> + <> W3C XML Path Language (XPath) Version 1.0 - <​> + <​> IEEE 802.11, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - <> + <> WGS1984, National Geospatial Intelligence Agency: DoD World Geodetic System 1984 - < > + < > JSON-LD 1.1 A JSON-based Serialization for Linked Data - <> + <> Terms and Definitions @@ -582,8 +590,8 @@ Definitions - - + + @@ -673,8 +681,8 @@ Abbreviations - - + + @@ -1114,12 +1122,12 @@ Web Services based development principles - + - gives an overview of the basic principles for development based on Web Services. The service provider (device) implements the ONVIF service or services. The service is described using the XML-based WSDL. Then, the WSDL is used as the basis for the service requester (client) implementation/integration. Client-side integration is simplified through the use of WSDL compiler tools that generate platform specific code that can be used by the client side developer to integrate the Web Service into an application. + gives an overview of the basic principles for development based on Web Services. The service provider (device) implements the ONVIF service or services. The service is described using the XML-based WSDL. Then, the WSDL is used as the basis for the service requester (client) implementation/integration. Client-side integration is simplified through the use of WSDL compiler tools that generate platform specific code that can be used by the client side developer to integrate the Web Service into an application. The Web Service provider and requester communicate using the SOAP message exchange protocol. SOAP is a lightweight, XML-based messaging protocol used to encode the information in a Web Service request and in a response message before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols. This ONVIF standard defines conformant transport protocols for the SOAP messages for the described Web Services. The Web Service overview section introduces into the general ONVIF service structure, the command definition syntax in the specification, error handling principles and the adopted Web Service security mechanisms. To ensure interoperability, all ONVIF services follow the Web Services Interoperability Organization (WS-I) basic profile 2.0 recommendations and use the document/literal wrapped pattern. @@ -1143,7 +1151,7 @@ Device discovery The configuration interfaces defined in this standard are Web Services interfaces that are based on the WS-Discovery standard. This use of this standard makes it possible to reuse a suitable existing Web Service discovery framework, instead of requiring a completely new service or service addressing definition. This standard introduces a specific discovery behaviour suitable for e.g. video surveillance purposes. For example, a fully interoperable discovery requires a well defined service definition and a service searching criteria. The specification covers device type and scopes definitions in order to achieve this. - A successful discovery provides the device service address. Once a client has the device service address it can receive detailed device information through the device service, see section below. + A successful discovery provides the device service address. Once a client has the device service address it can receive detailed device information through the device service, see section below.
Profiles and Addons @@ -1305,23 +1313,23 @@
Geo Location - Interface to describes the location of the device and its entities. A two level approach allows to model both outdoor and indoor situations. See for the orientation of the axis. The position on earth is defined via the angles lon and lat in degrees as well as the hight in meter.The model is coined ENU for (East, North, Up). The mapping of the coordinate system is defined by [WGS1984] and the base for GPS. + Interface to describes the location of the device and its entities. A two level approach allows to model both outdoor and indoor situations. See for the orientation of the axis. The position on earth is defined via the angles lon and lat in degrees as well as the hight in meter.The model is coined ENU for (East, North, Up). The mapping of the coordinate system is defined by [WGS1984] and the base for GPS.
Location on earth<footnote xml:id="__FN1__"><para>Source: https://en.wikipedia.org/wiki/Axes_conventions.</para></footnote> - +
The range for longitude is between -180 and +180 degrees, while the range for the latitude is between -90 and +90 degrees. The range for elevation is un unbounded signed value, to deal not only with points above the sea level, but also under the world ellipsoid, such as points under water or points in depressions. - describes the three orientation angles called roll, pitch and yaw. + describes the three orientation angles called roll, pitch and yaw.
Orientation on earth surface<footnote xml:id="__FN2__"><para>Source: By Qniemiec, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10893168</para></footnote> - +
@@ -1345,14 +1353,14 @@ A typical ONVIF network system does have multiple clients that handle device configuration and device management operations for numerous devices. Additionally a device providing services may also act as a client. Web Services also require a common way to discover service providers. This discovery is achieved using the Universal Discovery, Description and Integration Registry (UDDI) specifications [UDDI API ver2], [UDDI Data Structure ver2]. The UDDI specifications utilize service brokers for service discovery. This specification targets devices while the UDDI model is not device oriented. Consequently, UDDI and service brokers are outside the scope of this specification. - According to this specification, devices (service providers) are discovered using WS-Discovery [WS-Discovery] based techniques. The service discovery principles are described in section . + According to this specification, devices (service providers) are discovered using WS-Discovery [WS-Discovery] based techniques. The service discovery principles are described in section . Web Services allow developers the freedom to define services and message exchanges, which may cause interoperability problems. The Web Services interoperability organization (WS-I) develops standard profiles and guidelines to create interoperable Web Services. The devices and the clients shall follow the guidelines in the WS-I Basic Profile 2.0 [WS-I BP 2.0], except for Requirement R2729 (ONVIF defines some shared response wrapper names) and Requirement R2801 (ONVIF references XML Schema 1.1 rather than XML Schema 1.0).
Services overview
General An ONVIF compliant device shall support a number of Web Services which are defined in this and related specifications. - The device management service is the entry point for all other services of the device and therefore also the target service for the ONVIF defined WS-Discovery behaviour, see chapter . + The device management service is the entry point for all other services of the device and therefore also the target service for the ONVIF defined WS-Discovery behaviour, see chapter . The entry point for the device management service is fixed to: @@ -1363,7 +1371,7 @@ If an ONVIF compliant device supports a certain service, the device shall respond to all commands defined in the corresponding service WSDL. If the specific command is not required for that service and the device does not support the command, the device should respond to a request with the error codes: env:Receiver, ter:ActionNotSupported, - see for the definitions of the error codes. + see for the definitions of the error codes.
@@ -1397,9 +1405,9 @@ Defined namespaces in this specification - - - + + + @@ -1498,9 +1506,9 @@
Referenced namespaces (with prefix) - - - + + + @@ -1665,8 +1673,8 @@
Referenced namespaces (without prefix) - - + + @@ -1797,7 +1805,7 @@ Subcode and FaultDetail elements information items are intended for carrying application specific error information. - The ONVIF specifications use a separate name space for specific faults (see ): + The ONVIF specifications use a separate name space for specific faults (see ): ter = “http://www.onvif.org/ver10/error”. SOAP fault messages for different Web Services are defined as part of the different Web Services definitions. Server and client shall use SOAP 1.2 fault message handling as specified in this specification and shall follow the WS-I Basic Profile 2.0 fault handling recommendations. The following example is an error message (SOAP 1.2 fault message over HTTP). The values in italics are placeholders for actual values. @@ -1843,10 +1851,10 @@ DATE: when response was generated
Generic faults - - - - + + + + @@ -2132,9 +2140,9 @@ DATE: when response was generated
HTTP errors - - - + + + @@ -2228,7 +2236,7 @@ DATE: when response was generated Authentication of a WS request by a server over HTTP and HTTPS - + @@ -2242,12 +2250,12 @@ DATE: when response was generated Authentication over SCTP The services defined in this standard, whenever consumed overt SCTP, shall be protected using digest authentication according to [WS-BinarySecurityToken]. Since HTTP headers are not present when consuming the services over SCTP, upon authentication failure the device shall return only the a SOAP:Fault env:Sender ter:NotAuthorized error on the WS level. - summarizes the authentication of a web service request by a server over SCTP. + summarizes the authentication of a web service request by a server over SCTP.
Authentication of a WS request by a server over SCTP - +
@@ -2260,9 +2268,9 @@ DATE: when response was generated
Device authentication Behavior - - - + + + @@ -2387,10 +2395,17 @@ X-Frame-Options: SAMEORIGIN]]> User + + Extended + Anonymous + For users with Extended user level, device will authenticate requests as for other + user levels, but authorization will depend on the informazion configured in the + corresponding Extension field of the corresponding + User element. Unauthenticated users are placed into the anonymous category and a device shall not allow users to be added to the anonymous user level category.
@@ -2423,19 +2438,19 @@ X-Frame-Options: SAMEORIGIN]]> - defines for each access class which user levels are allowed access. A user of level c shall be granted access to a service request associated to access class r if and only if an "X" is present in the cell at column c and row r. + defines for each access class which user levels are allowed access. A user of level c shall be granted access to a service request associated to access class r if and only if an "X" is present in the cell at column c and row r.
Default Access Policy Definition - - - - - + + + + + - + Administrator @@ -2479,7 +2494,7 @@ X-Frame-Options: SAMEORIGIN]]> X - + @@ -2491,8 +2506,8 @@ X-Frame-Options: SAMEORIGIN]]> X - - + + @@ -2501,9 +2516,9 @@ X-Frame-Options: SAMEORIGIN]]> X - - - + + + @@ -2512,9 +2527,9 @@ X-Frame-Options: SAMEORIGIN]]> X - - - + + + @@ -2523,9 +2538,9 @@ X-Frame-Options: SAMEORIGIN]]> X - - - + + + @@ -2540,7 +2555,7 @@ X-Frame-Options: SAMEORIGIN]]> X - + @@ -2552,8 +2567,8 @@ X-Frame-Options: SAMEORIGIN]]> X - - + + @@ -2562,14 +2577,47 @@ X-Frame-Options: SAMEORIGIN]]>
Default Access Policy By default, the device should enforce the following default access policy, which gives an acceptable level of security in many systems. - The default access policy builds upon the access classes that are associated to the services and grants access rights in the following way. A user of level c shall be granted access to a service associated to access class r if and only if an "X" is present in the cell at column c and row r in . + The default access policy builds upon the access classes that are associated to the services and grants access rights in the following way. A user of level c shall be granted access to a service associated to access class r if and only if an "X" is present in the cell at column c and row r in . A device that signals support for the Default Access Policy via the respective capability shall support at least one user of each user level Administrator, Operator and User.
+
+ User roles + To have finer control of invokable functions, extended users levels may be + associated to one or more roles, see . + Devices supporting user roles shall predefine the following non editable + roles: + + + onvif:Administrator : the predefined role corresponding to + the Administrator user level. Users with Administrator user level and extended users + with onvif:Administrator role shall be idempotent. + + + onvif:Operator : the predefined role corresponding to the + Operator user level. Users with Operator user level and extended users with + onvif:Operator role shall be idempotent. + + + onvif:User : the predefined role corresponding to the User + user level. Users with User user level and extended users with onvif:User role shall + be idempotent. + + + The usage of the onvif: prefix for new roles is reserved and + shall not be used to create custom user roles. Roles with the + onvif: prefix are fixed and cannot be edited. + The name of custom user roles shall not include spaces. + Unlike user levels, more than one role may be associated with an Extended User. As + an example, in this way it is possibile to define a new set of credentials with + onvif:User and PTZControl roles, to give a user the possibility of accessing a camera + and to only control the PTZ, without altering any other state of the device, such as + I/Os. +
Username token profile A client shall use both nonce and timestamps as defined in [WS-UsernameToken]. The server shall reject any Username Token not using both nonce and creation timestamps. - This specification defines a set of commands for managing the user credentials, see . These commands allow associating users with the different user levels defined in . + This specification defines a set of commands for managing the user credentials, see . These commands allow associating users with the different user levels defined in .
@@ -2587,14 +2635,14 @@ X-Frame-Options: SAMEORIGIN]]> IP configuration - The device and client communicate over an open or closed IP network. This standard does not place any general restrictions or requirements on the network type. It shall be possible, however, to establish communication links between the entities according to the architectural framework specified in . Device IP configuration includes parameters such as IP addresses and a default gateway. + The device and client communicate over an open or closed IP network. This standard does not place any general restrictions or requirements on the network type. It shall be possible, however, to establish communication links between the entities according to the architectural framework specified in . Device IP configuration includes parameters such as IP addresses and a default gateway. An ONVIF compliant device shall have at least one network interface that gives it IP network connectivity. Similarly, the client shall have at least one network interface that gives IP connectivity and allows data communication between the device and the client. Both device and client shall support IPv4 based network communication. The device and client should support IPv6 based network communication. It shall be possible to make static IP configuration on the device using a network or local configuration interface. An ONVIF compliant device should support dynamic IP configuration of link-local addresses according to [RFC 3927]. A device that supports IPv6 shall support stateless IP configuration according to [RFC 4862] and neighbour discovery according to [RFC 4861]. The device shall support dynamic IP configuration according to [RFC 2131]. A device that supports IPv6 shall support stateful IP configuration via DHCPv6 according to [RFC3315] if signaled via the corresponding capability. The device may support any additional IP configuration mechanism. - Network configuration of a device shall be provided via the ONVIF device management service as specified in section and may additionally be provided through local interfaces. The latter is outside the scope of this specification. + Network configuration of a device shall be provided via the ONVIF device management service as specified in section and may additionally be provided through local interfaces. The latter is outside the scope of this specification. The default device configuration shall have both DHCP and dynamic link-local (stateless) address configuration enabled. Even if the device is configured through a static address configuration it should have the link-local address default enabled. When a device is connected to an IPv4 network, address assignment priorities (link local versus routable address) should be done as recommended in [RFC 3927]. Note that the network interface should set up an explicit IPv4 route for multicast traffic to ensure that WS-Discovery is successful, whether a default route is present or not. In a linux environment, this can be done with a command line like: @@ -2609,7 +2657,7 @@ X-Frame-Options: SAMEORIGIN]]> protocol [WS-Discovery]. A device compliant with this specification shall implement the Target Service role as specified in [WS-Discovery] unless it signals DiscoveryNotSupported via its capabilities. - [WS-Discovery] describes the Universally Unique Identifier (UUID): URI format recommendation for endpoint references in Section 2.6, but this specification overrides this recommendation. Instead, the Uniform Resource Name: Universally Unique Identifier (URN:UUID) format is used [RFC 4122] (see Section ). + [WS-Discovery] describes the Universally Unique Identifier (UUID): URI format recommendation for endpoint references in Section 2.6, but this specification overrides this recommendation. Instead, the Uniform Resource Name: Universally Unique Identifier (URN:UUID) format is used [RFC 4122] (see Section ).
Modes of operation @@ -2623,7 +2671,7 @@ X-Frame-Options: SAMEORIGIN]]> A device in discoverable mode sends multicast Hello messages once connected to the network or sends its Status changes according to [WS-Discovery]. In addition it always listens for Probe and Resolve messages and sends responses accordingly. A device in non-discoverable shall not listen to [WS-Discovery] messages or send such messages. - 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 . + 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 .
Discovery definitions @@ -2655,13 +2703,13 @@ X-Frame-Options: SAMEORIGIN]]> ]]> A device may have other scope URIs. These URIs are not restricted to ONVIF defined scopes. - defines a set of scope parameters. Apart from these standardized parameters, it shall be possible to set any scope parameter as defined by the device owner. Scope parameters can be listed and set through the commands defined in Section . + defines a set of scope parameters. Apart from these standardized parameters, it shall be possible to set any scope parameter as defined by the device owner. Scope parameters can be listed and set through the commands defined in Section .
Scope parameters - - - + + + @@ -2774,14 +2822,14 @@ onvif://www.onvif.org/name/ARV-453 Addresses A device shall include the <d:XAddrs> element with the address(es) for the device service in the Hello message. A URI shall be provided for each protocol (http, https) and externally available IP address. The device should provide a port 80 device service entry in order to allow firewall traversal. - The IP addressing configuration principles for a device are defined in . + The IP addressing configuration principles for a device are defined in .
Probe and Probe Match - For the device probe match types, scopes and addresses definitions, see Hello. + For the device probe match types, scopes and addresses definitions, see Hello. An ONVIF compliant device shall at least support the http://schemas.xmlsoap.org/ws/2005/04/discovery/rfc3986 scope matching rule. This scope matching definitions differs slightly from the definition in [WS-Discovery] as [RFC 2396] is replaced by [RFC 3986]. - A device shall include the <d:XAddrs> element with the addresses for the device service in a matching probe match message. The <d:XAddrs> element will in most cases only contain one address to the device management service as defined in . + A device shall include the <d:XAddrs> element with the addresses for the device service in a matching probe match message. The <d:XAddrs> element will in most cases only contain one address to the device management service as defined in .
Resolve and Resolve Match @@ -2866,7 +2914,7 @@ onvif://www.onvif.org/name/ARV-453
GetServices Returns a collection of the devices services and possibly their available capabilities. The returned capability response message is untyped to allow future addition of services, service revisions and service capabilities. All returned service capabilities shall be structured by different namespaces which are supported by a device. - A device shall implement this method if any of the ONVIF compliant services implements the GetServiceCapabilities. For making sure about the structure of GetServices response with capabilities, please refer to . + A device shall implement this method if any of the ONVIF compliant services implements the GetServiceCapabilities. For making sure about the structure of GetServices response with capabilities, please refer to . The version in GetServicesResponse shall contain the specification version number of the corresponding service that is implemented by a device. For the returned XAddr a device shall match the scheme and IP part of the one used in the GetServices request. Note that if device is behind a NAT that device may return the local address and not the external address used by the client. @@ -2904,7 +2952,7 @@ onvif://www.onvif.org/name/ARV-453 GetServiceCapabilities This command returns the capabilities of the device service. The service shall implement this method if the device supports the GetServices method. - describes how to interpret the indicated capabilities. + describes how to interpret the indicated capabilities. request @@ -2937,9 +2985,9 @@ onvif://www.onvif.org/name/ARV-453 The capabilities in the GetServiceCapabilities command - - - + + +
@@ -2962,7 +3010,7 @@ onvif://www.onvif.org/name/ARV-453 IPFilter - Indication if the device supports IP filtering control using the commands in Section , , and . + Indication if the device supports IP filtering control using the commands in Section , , and . @@ -2970,7 +3018,7 @@ onvif://www.onvif.org/name/ARV-453 ZeroConfiguration - Indication if the device supports zero configuration according to the commands in Section and Section . + Indication if the device supports zero configuration according to the commands in Section and Section . @@ -2986,7 +3034,7 @@ onvif://www.onvif.org/name/ARV-453 DynDNS - Indication if the device supports Dynamic DNS configuration according to Section and Section . + Indication if the device supports Dynamic DNS configuration according to Section and Section . @@ -2994,7 +3042,7 @@ onvif://www.onvif.org/name/ARV-453 Dot11Configuration - Indication if the device supports IEEE802.11 configuration as specified in Section + Indication if the device supports IEEE802.11 configuration as specified in Section @@ -3037,7 +3085,7 @@ onvif://www.onvif.org/name/ARV-453 DiscoveryResolve - Indication if the device responses to resolve requests as described in Section . + Indication if the device responses to resolve requests as described in Section . @@ -3045,7 +3093,7 @@ onvif://www.onvif.org/name/ARV-453 DiscoveryBye - Indication if the device sends bye messages as described in Section + Indication if the device sends bye messages as described in Section @@ -3065,7 +3113,7 @@ onvif://www.onvif.org/name/ARV-453 SystemBackup - Indication if the device supports system backup and restore as specified in Section and Section + Indication if the device supports system backup and restore as specified in Section and Section @@ -3073,7 +3121,7 @@ onvif://www.onvif.org/name/ARV-453 FirmwareUpgrade - Indication if the device supports firmware upgrade as specified in Section . + Indication if the device supports firmware upgrade as specified in Section . @@ -3081,7 +3129,7 @@ onvif://www.onvif.org/name/ARV-453 SystemLogging - Indication if the device supports system log retrieval as specified in Section . + Indication if the device supports system log retrieval as specified in Section . @@ -3105,7 +3153,7 @@ onvif://www.onvif.org/name/ARV-453 HTTPSystemLogging - Indication if the device supports retrieval of system log using HTTP Get, see section . + Indication if the device supports retrieval of system log using HTTP Get, see section . @@ -3113,7 +3161,7 @@ onvif://www.onvif.org/name/ARV-453 HTTPSupportInformation - Indication if the device supports retrieval of support information using HTTP Get, see section . + Indication if the device supports retrieval of support information using HTTP Get, see section . @@ -3121,7 +3169,7 @@ onvif://www.onvif.org/name/ARV-453 StorageConfiguration - Indication if the device supports storage configuration interfaces as specified in Section Storage Configuration. + Indication if the device supports storage configuration interfaces as specified in Section Storage Configuration. @@ -3129,7 +3177,7 @@ onvif://www.onvif.org/name/ARV-453 GeoLocationEntities - Indicates the number of geo location entities supported. See section and . + Indicates the number of geo location entities supported. See section and . @@ -3137,7 +3185,7 @@ onvif://www.onvif.org/name/ARV-453 AutoGeo - Indicates the support for automatic retrieval of geo location. See section and . + Indicates the support for automatic retrieval of geo location. See section and . @@ -3167,14 +3215,14 @@ onvif://www.onvif.org/name/ARV-453 - + Security AccessPolicyConfig - Indication if the device supports retrieving and loading device access control policy according to Section and Section . + Indication if the device supports retrieving and loading device access control policy according to Section and Section . @@ -3182,7 +3230,7 @@ onvif://www.onvif.org/name/ARV-453 DefaultAccessPolicy - Indicates if the device supports the default access policies as defined in . + Indicates if the device supports the default access policies as defined in . @@ -3254,7 +3302,7 @@ onvif://www.onvif.org/name/ARV-453 RemoteUserHandling - Indication if device supports remote user handling and the corresponding methods defined in section and . + Indication if device supports remote user handling and the corresponding methods defined in section and . @@ -3297,7 +3345,7 @@ onvif://www.onvif.org/name/ARV-453 Maximum number of passwords that the device can remember for each user. If the device does not support the password history this attribute should be zero or not present - + HashingAlgorithms @@ -3305,6 +3353,16 @@ onvif://www.onvif.org/name/ARV-453 Indicates which hashing algorithms are supported as part of HTTP and RTSP digest authentication. + + + MaxUserRoles + + + Whenever set to an integer greater than zero, it signals that the device + supports user roles, as described in section . + It indicates the maximum number of editable user levels. + + Misc @@ -3724,7 +3782,7 @@ onvif://www.onvif.org/name/ARV-453
SetNetworkInterfaces This operation sets the network interface configuration on a device. The device shall support network configuration of supported network interfaces through the SetNetworkInterfaces command. - If a device responds with RebootNeeded set to false, the device can be reached via the new IP address without further action. A client should be aware that a device may not be responsive for a short period of time until it signals availability at the new address via the discovery Hello messages as defined in . + If a device responds with RebootNeeded set to false, the device can be reached via the new IP address without further action. A client should be aware that a device may not be responsive for a short period of time until it signals availability at the new address via the discovery Hello messages as defined in . If a device responds with RebootNeeded set to true, it will be further available under its previous IP address. The settings will only be activated when the device is rebooted via the SystemReboot command. For interoperability with a client unaware of the IEEE 802.11 extension a device shall retain its IEEE 802.11 configuration if the IEEE 802.11 configuration element isn’t present in the request. @@ -4250,7 +4308,7 @@ onvif://www.onvif.org/name/ARV-453
GetDot11Capabilities - This operation returns the IEEE802.11 capabilities, see . The device shall support this operation. + This operation returns the IEEE802.11 capabilities, see . The device shall support this operation. request @@ -4281,8 +4339,8 @@ onvif://www.onvif.org/name/ARV-453
IEEE802.11 capabilities - - + + @@ -4530,7 +4588,7 @@ onvif://www.onvif.org/name/ARV-453
GetSystemBackup - This interface has been deprecated. A device shall implement this command if the capability SystemBackup is signaled. For a replacement method see section and . + This interface has been deprecated. A device shall implement this command if the capability SystemBackup is signaled. For a replacement method see section and . This operation retrieves system backup configuration file(s) from a device. The backup is returned with reference to a name and mime-type together with binary data. The format of the backup configuration data is vendor specific. It is expected that after completion of the restore operation the device is working on the same configuration as that of the time the configuration was backed up. Note that the configuration of static IP addresses may differ. Device vendors may put restrictions on the functionality to be restored. The detailed behavior is outside the scope of this specification. The backup configuration file(s) are transmitted through MTOM [MTOM]. @@ -4565,7 +4623,7 @@ onvif://www.onvif.org/name/ARV-453
RestoreSystem - This interface has been deprecated. A device shall implement this command if the capability SystemBackup is signaled. For a replacement method see section and . + This interface has been deprecated. A device shall implement this command if the capability SystemBackup is signaled. For a replacement method see section and . This operation restores the system backup configuration files(s) previously retrieved from a device. The exact format of the backup configuration file(s) is outside the scope of this standard. If the command is supported, it shall accept backup files returned by the GetSystemBackup command. The back up configuration file(s) are transmitted through MTOM [MTOM]. @@ -4637,7 +4695,7 @@ onvif://www.onvif.org/name/ARV-453 faults - + No command-specific faults. @@ -4858,7 +4916,7 @@ onvif://www.onvif.org/name/ARV-453 faults - + No command-specific faults. @@ -4977,7 +5035,7 @@ onvif://www.onvif.org/name/ARV-453
GetScopes - This operation requests the scope parameters of a device. The scope parameters are used in the device discovery to match a probe message, see Section . The Scope parameters are of two different types: + This operation requests the scope parameters of a device. The scope parameters are used in the device discovery to match a probe message, see Section . The Scope parameters are of two different types: Fixed @@ -5019,7 +5077,7 @@ onvif://www.onvif.org/name/ARV-453
SetScopes - This operation sets the scope parameters of a device. The scope parameters are used in the device discovery to match a probe message, see Section . + This operation sets the scope parameters of a device. The scope parameters are used in the device discovery to match a probe message, see Section . This operation replaces all existing configurable scope parameters (not fixed parameters). If this shall be avoided, one should use the scope add command instead. The device shall support configuration of discovery scope parameters through the SetScopes command. @@ -5053,7 +5111,7 @@ onvif://www.onvif.org/name/ARV-453
AddScopes - This operation adds new configurable scope parameters to a device. The scope parameters are used in the device discovery to match a probe message, see Section . The device shall support addition of discovery scope parameters through the AddScopes command. + This operation adds new configurable scope parameters to a device. The scope parameters are used in the device discovery to match a probe message, see Section . The device shall support addition of discovery scope parameters through the AddScopes command. request @@ -5086,7 +5144,7 @@ onvif://www.onvif.org/name/ARV-453
RemoveScopes - This operation deletes scope-configurable scope parameters from a device. The scope parameters are used in the device discovery to match a probe message, see Section . The device shall support deletion of discovery scope parameters through the RemoveScopes command. + This operation deletes scope-configurable scope parameters from a device. The scope parameters are used in the device discovery to match a probe message, see Section . The device shall support deletion of discovery scope parameters through the RemoveScopes command. Note that the response message always will match the request or an error will be returned. The use of the response is for that reason deprecated. @@ -5124,7 +5182,7 @@ onvif://www.onvif.org/name/ARV-453
GetDiscoveryMode - This operation gets the discovery mode of a device. See Section for the definition of the different device discovery modes. The device shall support retrieval of the discovery mode setting through the GetDiscoveryMode command. + This operation gets the discovery mode of a device. See Section for the definition of the different device discovery modes. The device shall support retrieval of the discovery mode setting through the GetDiscoveryMode command. request @@ -5156,8 +5214,7 @@ onvif://www.onvif.org/name/ARV-453
SetDiscoveryMode - This operation sets the discovery mode operation of a device. See Section for the definition of the different device discovery modes. A + This operation sets the discovery mode operation of a device. See Section for the definition of the different device discovery modes. A device shall support configuration of the discovery mode setting through the SetDiscoveryMode command unless it signals DiscoveryNotSupported via its capabilities. @@ -5336,10 +5393,10 @@ onvif://www.onvif.org/name/ARV-453
Security - This section contains a set of security management operations. Such operations are sensitive to network attacks and shall be protected using appropriate authorization levels in order not to compromise the device. + This section contains a set of security management operations. Such operations are sensitive to network attacks and shall be protected using appropriate authorization levels in order not to compromise the device.
Get access policy - Access to different services and sub-sets of services should be subject to access control. Section gives the prerequisite for end-point authentication. Authorization decisions can then be taken using an access security policy. This standard does not mandate any particular policy description format or security policy but this is up to the device manufacturer or system provider to choose policy and policy description format of choice. However, an access policy (in arbitrary format) can be requested using this command. If the device supports access policy settings, then the device shall support this command. + Access to different services and sub-sets of services should be subject to access control. Section gives the prerequisite for end-point authentication. Authorization decisions can then be taken using an access security policy. This standard does not mandate any particular policy description format or security policy but this is up to the device manufacturer or system provider to choose policy and policy description format of choice. However, an access policy (in arbitrary format) can be requested using this command. If the device supports access policy settings, then the device shall support this command. request @@ -5372,7 +5429,7 @@ onvif://www.onvif.org/name/ARV-453
Set access policy - This command sets the device access security policy (for more details on the access security policy see the Get command, Section ). If the device supports access policy settings based on WS-Security authentication, then the device shall support this command. + This command sets the device access security policy (for more details on the access security policy see the Get command, Section ). If the device supports access policy settings based on WS-Security authentication, then the device shall support this command. request @@ -5437,7 +5494,7 @@ onvif://www.onvif.org/name/ARV-453
Create users - This operation creates new device users and corresponding credentials on a device for authentication, see Section for details. A device shall support this command unless support signalled via the UserConfigNotSupported capability is ‘True’. The device shall support creation of device users and their credentials for authentication through the CreateUsers command as long as the number of existing users does not exceed the capability value MaxUsers. Either all users are created successfully or a fault message shall be returned without creating any user. + This operation creates new device users and corresponding credentials on a device for authentication, see Section for details. A device shall support this command unless support is signalled via the UserConfigNotSupported capability is ‘True’. The device shall support creation of device users and their credentials for authentication through the CreateUsers command as long as the number of existing users does not exceed the capability value MaxUsers. Either all users are created successfully or a fault message shall be returned without creating any user. ONVIF compliant devices are recommended to support password length of at least 28 bytes. @@ -5517,7 +5574,7 @@ onvif://www.onvif.org/name/ARV-453
SetUser - This operation updates the settings for one or several users on a device for authentication, see Sect. for details. The device shall support update of device users and their credentials through the SetUser command. A device shall support this command unless support signalled via the UserConfigNotSupported capability is ‘True’. Either all change requests are processed successfully or a fault message shall be returned and no change requests be processed. + This operation updates the settings for one or several users on a device for authentication, see Sect. for details. The device shall support update of device users and their credentials through the SetUser command. A device shall support this command unless support signalled via the UserConfigNotSupported capability is ‘True’. Either all change requests are processed successfully or a fault message shall be returned and no change requests be processed. In case the optional password value is omitted the device will consider to clear the password. If the device can not accept the password of zero length, the fault message of "ter:PasswordTooWeak" will be returned. If the device signals support for "ModifyPassword" in the SecurityPolicies capability, an authorized user shall be entitled to change his own password independently of the default access policy. In this case a device shall ignore the UserLevel field for any client not fulfilling access class WRITE_SYSTEM. @@ -5655,6 +5712,125 @@ onvif://www.onvif.org/name/ARV-453
+
+ User roles + A device that signals support for user roles handling via the Security Capability + MaxUserRoles shall support these operations. +
+ Get user roles + This operation returns the user roles configured in the device, including the + pre-defined onvif ones corresponding to the Administrator, Operator and User levels. + Whenever the name of a user role is passed in the request, information only about that + level is returned. + + + request + + Name - optional [xs:string] + If a value is defined for Name, then only the information for the + user role matching that name is returned. + + + + response + + UserRoles - optional unbounded [tt:UserRole] + Information about one or more user roles. + + + + faults + + env:Sender - ter:InvalidArgVal - ter:InvalidUserRole + The specified user role does not exist. + + + + access class + + READ_SYSTEM + + + +
+
+ Set user role + This operation configures a user role in the device. If the name passed in the + UserRole argument already exists in the device, its configuration will be overwritten. + Otherwise, a new role will be created. + A client is expected to use the capabilities of the device to request only functions + that are implemented in the device. In case a client requests an unknown or not + implemented function, the device must return an error. + + + request + + UserRole - [tt:UserRole] + The user role to be created or overwritten. + + + + response + + This is an empty message. + + + + faults + + env:Receiver - ter:Action - ter:TooManyUserRoles + Maximum number of supported user roles exceeded. + env:Receiver - ter:Action - ter:FunctionNotImplemented + One or more requested functions are not implemented in the + device. + env:Sender - ter:OperationProhibited - ter:OnvifPrefix + The client cannot create or edit roles starting with the onvif: + prefix. + + + + access class + + WRITE_SYSTEM + + + +
+
+ Delete user role + This operation deletes a user role in the device. + + + request + + Name - [xs:string] + The user role that has to be deleted. + + + + response + + This is an empty message. + + + + faults + + env:Sender - ter:InvalidArgVal - ter:InvalidUserRole + The specified user role does not exist. + env:Sender - ter:OperationProhibited - ter:OnvifPrefix + The client delete roles starting with the onvif: prefix. + + + + access class + + WRITE_SYSTEM + + + +
+
Security Policies @@ -6042,8 +6218,8 @@ onvif://www.onvif.org/name/ARV-453 The physical idle state of a relay output can be configured by setting the IdleState to ‘open’ or ‘closed’ (inversion of the relay behaviour). - Idle State ‘open’ means that the relay is open when the relay state is set to ‘inactive’ through the trigger command (see Section ) and closed when the state is set to ‘active’ through the same command. - Idle State ‘closed’ means that the relay is closed when the relay state is set to ‘inactive’ through the trigger command (see Section ) and open when the state is set to ‘active’ through the same command. + Idle State ‘open’ means that the relay is open when the relay state is set to ‘inactive’ through the trigger command (see Section ) and closed when the state is set to ‘active’ through the same command. + Idle State ‘closed’ means that the relay is closed when the relay state is set to ‘inactive’ through the trigger command (see Section ) and open when the state is set to ‘active’ through the same command. The Duration parameter of the Properties field “DelayTime” describes the time after which the relay returns to its idle state if it is in monostable mode. If the relay is set to bistable mode the value of the parameter shall be ignored. @@ -6116,7 +6292,7 @@ onvif://www.onvif.org/name/ARV-453
SendAuxiliaryCommand This section describes operations to manage auxiliary commands supported by a device, such as controlling an Infrared (IR) lamp, a heater or a wiper or a thermometer that is connected to the device. - The commands supported by the device is reported in the AuxiliaryCommands attribute returned by the capabilities commands, see section . The command transmitted by using this command should match one of the commands supported by the device. If for example the capability command response lists only irlampon command, then the SendAuxiliaryCommand argument will be irlampon, which may indicate turning the connected IR lamp on. + The commands supported by the device is reported in the AuxiliaryCommands attribute returned by the capabilities commands, see section . The command transmitted by using this command should match one of the commands supported by the device. If for example the capability command response lists only irlampon command, then the SendAuxiliaryCommand argument will be irlampon, which may indicate turning the connected IR lamp on. Although the name of the auxiliary commands can be freely defined, commands starting with the prefix tt: are reserved to define frequently used commands and these reserved commands shall all share the "tt:command|parameter" syntax. @@ -6674,9 +6850,9 @@ Event description: Event handling - An event is an action or occurrence detected by a device that a client can subscribe to. Events are handled through the event service. This specification defines event handling based on the [WS-BaseNotification] and [WS-Topics] specifications. It extends the event notion to allow clients to track object properties (such as digital input and motion alarm properties) through events. Properties are defined in section . - The description of event payload and their filtering within subscriptions is discussed in section . Section describes how a synchronization point can be requested by clients using one of the three notification interfaces. Section describes the integration of Topics and section discusses the handling of faults. - Section demonstrates the usage of the Real-Time Pull-Point Notification Interface including Message Filtering and Topic Set. Examples for the basic notification interface can be found in the corresponding [WS-BaseNotification] specification. + An event is an action or occurrence detected by a device that a client can subscribe to. Events are handled through the event service. This specification defines event handling based on the [WS-BaseNotification] and [WS-Topics] specifications. It extends the event notion to allow clients to track object properties (such as digital input and motion alarm properties) through events. Properties are defined in section . + The description of event payload and their filtering within subscriptions is discussed in section . Section describes how a synchronization point can be requested by clients using one of the three notification interfaces. Section describes the integration of Topics and section discusses the handling of faults. + Section demonstrates the usage of the Real-Time Pull-Point Notification Interface including Message Filtering and Topic Set. Examples for the basic notification interface can be found in the corresponding [WS-BaseNotification] specification. Both device and client shall support [WS-Addressing] for event services.
Real-time Pull-Point Notification Interface @@ -6690,14 +6866,14 @@ Event description: The device evaluates the subscription request and returns either a CreatePullPointSubscriptionResponse or one of the Fault codes. - If the subscription is accepted, the response contains a WS-EndpointReference to the instantiated pull point. This WS-Endpoint provides a PullMessages operation, which is used by the client to retrieve Notifications. Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface. The sequence diagram of the interaction is shown in . + If the subscription is accepted, the response contains a WS-EndpointReference to the instantiated pull point. This WS-Endpoint provides a PullMessages operation, which is used by the client to retrieve Notifications. Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface. The sequence diagram of the interaction is shown in .
Sequence diagram for the Real-time Pull-Point Notification Interface - +
@@ -6707,7 +6883,7 @@ Event description: For a device implementation it is important to support multiple pull points (including multiple pullpoints per client) in order to allow precise event generation. If a device would only support one subscription at a time a client would need to subscribe without any scope restriction, because changing of event subscription is not possible. Hence this would require the device to serve all available events for which the device would have to activate all subsystems that generate events. This may cause unnecessary load by e.g. activating multiple motion detectors and similar without need. Additionally the traffic produced by all these events may cause a substantial network load. - If the device supports persistent notification storage, see , the WS-Endpoint also provides a Seek operation. This operation allows to reposition the pull pointer into the past. With the Seek operation it is also possible to reverse the pull direction. There is also a BeginOfBuffer event, as defined in , that signals the start of the buffer. + If the device supports persistent notification storage, see , the WS-Endpoint also provides a Seek operation. This operation allows to reposition the pull pointer into the past. With the Seek operation it is also possible to reverse the pull direction. There is also a BeginOfBuffer event, as defined in , that signals the start of the buffer. An ONVIF compliant device shall implement the Real Time Pull-Point Notification Interface.
Create pull point subscription @@ -6721,7 +6897,7 @@ Event description: tev:ChangedOnly A pullpoint should not provide Initialized nor Deleted events for Properties. - Both request and response message contain the same elements as the SubscriptionRequest and Response of [WS-BaseNotification] without the ConsumerReference. + Both request and response message contain the same elements as the SubscriptionRequest and Response of [WS-BaseNotification] without the ConsumerReference. request @@ -6747,7 +6923,7 @@ Event description: faults - + The same faults as for Subscription Request of the [WS-BaseNotification] are used. @@ -6810,7 +6986,7 @@ Event description: faults - + No specific fault codes. @@ -6864,7 +7040,7 @@ Event description: faults - + No specific fault codes. @@ -6906,7 +7082,7 @@ Event description: faults - + No specific fault codes. @@ -6920,7 +7096,7 @@ Event description:
Seek - A device supporting persistent notification storage as defined in section shall provide the following Seek command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. + A device supporting persistent notification storage as defined in section shall provide the following Seek command for all SubscriptionManager endpoints returned by the CreatePullPointSubscription command. On a Seek a pullpoint shall abort any event delivery including any initial states of properties. Furthermore the pullpoint should flush events not already queued for transmission from the transmit queue. After a Seek request a pullpoint shall ignore the behavior described in section 9.6 for properties. A device shall only set the subscription in reverse pull mode if the Reverse argument is present and set to “true”. @@ -6947,7 +7123,7 @@ Event description: faults - + No specific fault codes. @@ -6962,13 +7138,13 @@ Event description:
Pull Point Lifecycle - depicts the basic operation of a pull point. This chapter states the requirements on the pull point lifecycle. + depicts the basic operation of a pull point. This chapter states the requirements on the pull point lifecycle. A device shall create a new pull point on each CreatePullPointSubscription command as long as the number of instantiated pull points does not exceed the capability MaxPullPoints. Each pull point shall have a unique endpoint reference to which the client can direct its consecutive operations on the pull point. A pull point shall exist until either its termination time has elapsed or the client has requested its disposal via an Unsubscribe request. There are no requirements regarding persistency of a pull point across a power cycle of a device.
Persistent notification storage - To ensure that no notifications are lost by a client a device may store its notifications. The stored notifications can at any time be retrieved by a client. The device shall indicate if its support persistent notification storage with the PersistentNotificationStorage capability. See section . + To ensure that no notifications are lost by a client a device may store its notifications. The stored notifications can at any time be retrieved by a client. The device shall indicate if its support persistent notification storage with the PersistentNotificationStorage capability. See section . This specification defines that the interface to the persistent storage allows linear access via the originating message event time. This holds also for events that are delivered out of order in the live streaming case due to e.g. computational delay. The details of what notification and how and where those notifications actually are stored are outside the scope of this specification. Removal policy of stored notifications to get room for new ones is also out of scope.
@@ -6991,7 +7167,7 @@ Event description:
Basic Notification Interface - Section briefly introduces the Basic Notification Interface of the [WS-BaseNotification] specification. Section summarizes the mandatory and the optional interfaces of the [WS-BaseNotification] specification. Please refer for a full documentation of the Basic Notification Interface to the [WS-BaseNotification] specification. + Section briefly introduces the Basic Notification Interface of the [WS-BaseNotification] specification. Section summarizes the mandatory and the optional interfaces of the [WS-BaseNotification] specification. Please refer for a full documentation of the Basic Notification Interface to the [WS-BaseNotification] specification.
Introduction The following logical entities participate in the notification pattern: @@ -6999,7 +7175,7 @@ Event description: Event Service: implements the NotificationProducer interface. Subscription Manager: implements the BaseSubscriptionManager interface. The Event Service and the Subscription Manager should be instantiated on a device. - Typical messages exchanged between the entities are shown in the sequence diagram in . First, the client establishes a connection to the Event Service. The client can then subscribe for certain notifications by sending a SubscriptionRequest. If the Event Service accepts the Subscription, it dynamically instantiates a SubscriptionManager representing the Subscription. The Event Service shall return the WS-Endpoint-Address of the SubscriptionManager in the SubscriptionResponse. + Typical messages exchanged between the entities are shown in the sequence diagram in . First, the client establishes a connection to the Event Service. The client can then subscribe for certain notifications by sending a SubscriptionRequest. If the Event Service accepts the Subscription, it dynamically instantiates a SubscriptionManager representing the Subscription. The Event Service shall return the WS-Endpoint-Address of the SubscriptionManager in the SubscriptionResponse. In order to transmit notifications matching the Subscription, another connection is established from the Event Service to the client. Via this connection, the Event Service sends a one-way Notify message to the NotificationConsumer interface of the client. Corresponding notifications can be sent at any time by the Event Service to the client, while the Subscription is active. To control the Subscription, the client directly addresses the SubscriptionManager returned in the SubscriptionResponse. In the SubscriptionRequest the client can specify a termination time. The SubscriptionManager is automatically destroyed when the termination time is reached. RenewRequests can be initiated by the client in order to postpone the termination time. The client can also explicitly terminate the SubscriptionManager by sending an UnsubscribeRequest. After a successful Unsubscription, the SubscriptionManager no longer exists. The interaction between EventService and SubscriptionManager is not further specified by the [WS-BaseNotification] and is up to the implementation of the device. @@ -7007,7 +7183,7 @@ Event description: Sequence diagram for the Base Notification Interface - + @@ -7015,7 +7191,7 @@ Event description:
Requirements This section details those interfaces of the [WS-BaseNotification] that a device shall provide. - An ONVIF compliant device shall support the NotificationProducer Interface of the [WS-BaseNotification] if the capability MaxNotificationProducers is non-zero. The device shall support TopicExpression filters with the dialects described in . The support for MessageContent filters is signalled via the GetEventProperties method. If the device does not accept the InitialTerminationTime of a subscription, it shall provide a valid InitialTerminationTime within the Fault Message. The device shall be able to provide notifications using the Notify wrapper of the [WS-BaseNotification] specification. The SubscriptionPolicy wsnt:UseRaw is optional for the device. Although the [WS-BaseNotification] has CurrentTime and TerminationTime as optional elements in a SubscribeResponse and RenewResponse, an ONVIF compliant device shall list them in both SubscribeResponses and RenewResponse. The device may respond to any GetCurrentMessage request with a Fault message indicating that no current message is available on the requested topic. + An ONVIF compliant device shall support the NotificationProducer Interface of the [WS-BaseNotification] if the capability MaxNotificationProducers is non-zero. The device shall support TopicExpression filters with the dialects described in . The support for MessageContent filters is signalled via the GetEventProperties method. If the device does not accept the InitialTerminationTime of a subscription, it shall provide a valid InitialTerminationTime within the Fault Message. The device shall be able to provide notifications using the Notify wrapper of the [WS-BaseNotification] specification. The SubscriptionPolicy wsnt:UseRaw is optional for the device. Although the [WS-BaseNotification] has CurrentTime and TerminationTime as optional elements in a SubscribeResponse and RenewResponse, an ONVIF compliant device shall list them in both SubscribeResponses and RenewResponse. The device may respond to any GetCurrentMessage request with a Fault message indicating that no current message is available on the requested topic. The implementation of the Pull-Point Interface of the [WS-BaseNotification] on a device is optional. An ONVIF compliant device shall implement the Base Subscription Manager Interface of the [WS-BaseNotification] specification consisting of the Renew and Unsubscribe operations. The Pausable Subscription Manager Interface is optional. The implementation of Subscriptions as WS-Resources is optional. An ONVIF compliant device shall support time values in request parameters that are given in utc with the 'Z' indicator and respond all time values as utc including the 'Z' indicator. @@ -7054,7 +7230,7 @@ Event description: ]]> - Section gives a detailed formatting of the Message payload, and Section introduces a description language for the Message payload. Section defines the grammar used in a subscription to filter notifications by their Message content. + Section gives a detailed formatting of the Message payload, and Section introduces a description language for the Message payload. Section defines the grammar used in a subscription to filter notifications by their Message content.
Notification Message Format The main information elements of a notification message are: @@ -7075,7 +7251,7 @@ Event description: Source, Data and Key are structured as item lists. Each can hold an arbitrary number of items of type SimpleItem or ElementItem. Each Item has a name and a value. In the case of an ElementItem, the value is expressed by one XML element within the ElementItem element. In the case of a SimpleItem, the value shall be specified by the value attribute. The name of all Items shall be unique within all Items contained in any group of this Message. ElementItem should not be used in the Source and Key elements. Vendor specific extensions shall express the SimpleItem and ElementItem Name attribute as QName. This avoids potential name clashes between Vendor specific extensions and future ONVIF extensions. - It is recommended to use SimpleItems instead of ElementItems whenever applicable, since SimpleItems ease the integration of Messages into a generic client. The exact type information of both Simple and ElementItems can be extracted from the TopicSet (see section ), where each topic can be augmented by a description of the message payload. + It is recommended to use SimpleItems instead of ElementItems whenever applicable, since SimpleItems ease the integration of Messages into a generic client. The exact type information of both Simple and ElementItems can be extracted from the TopicSet (see section ), where each topic can be augmented by a description of the message payload. The subsequent example demonstrates the different parts of the notification: ... @@ -7106,13 +7282,13 @@ Event description: Property event state chart - + - When a client subscribes to a topic representing certain properties, the device shall provide notifications informing the client of all objects with the requested property, which are alive at the time of the subscription. After all existing objects have been reported the device shall send notifications when a property has changed, is deleted or a new one created. A client may also request the values of all currently alive properties the client has subscribed to at any time by asking for a synchronization point (see section ). + When a client subscribes to a topic representing certain properties, the device shall provide notifications informing the client of all objects with the requested property, which are alive at the time of the subscription. After all existing objects have been reported the device shall send notifications when a property has changed, is deleted or a new one created. A client may also request the values of all currently alive properties the client has subscribed to at any time by asking for a synchronization point (see section ). A notification message of a property event shall include the PropertyOperation attribute. The operation mode “Initialized” shall be used to inform a client about the creation of a property. The operation mode “Initialized” shall also be used when a synchronization point has been requested. - The property interface is defined in this standard in order to group all property related events together and to present uniformly to clients. It is recommended to use the property interface wherever applicable. Section explains the structure of events and properties in detail. + The property interface is defined in this standard in order to group all property related events together and to present uniformly to clients. It is recommended to use the property interface wherever applicable. Section explains the structure of events and properties in detail.
Property Example The following video analytics example demonstrates the dynamic behaviour of properties: The rule engine interface of the video analytics detector can define fields. Such a detector field is described by a polygon in the image plane. For each object in the scene, the rule engine determines which objects are within the polygon. A client can access this information by subscribing to the corresponding ObjectsInside property of the detector field. Each time an object appears in the scene, a new ObjectsInside property is created. The client is informed by a corresponding “property created” notification indicating if the object appeared inside or outside the polygon. Each time an object enters or leaves the polygon, a “property changed” notification is produced indicating that the ObjectsInside property for this object has changed. When an object leaves the scene, the corresponding ObjectsInside property is deleted and the client is informed via a “property deleted” notification. @@ -7220,10 +7396,10 @@ Event description: ]]> The Name attribute of an Item shall be unique within all Items independent from the group (Source, Key, Data) they are coming from. The IsProperty attribute shall be set to true when the described Message relates to a property. If the Message, however, does not relate to a property, the Key group shall not be present. The Type attribute of a SimpleItemDescriptor shall use simple type defined in XML schema (built in simple types), ONVIF schemas, or vendor schemas. Similarly, the Type attribute of an ElementItemDescriptor shall match a global element declaration of an XML schema. The Message Description Language does not mandate the order of the Items in each of the categories Source, Key and Data. Additionally Items documented as optional by an ONVIF Event definition are not required to be present to in a message. This applies also to optional Items that are described in the related MessageDescription. - The location of all schema files used to describe Message payloads are listed in the GetEventPropertiesResponse message in Section . + The location of all schema files used to describe Message payloads are listed in the GetEventPropertiesResponse message in Section .
Message Description Example - The following code is an example of a Message Description corresponding to the Property example of Section : + The following code is an example of a Message Description corresponding to the Property example of Section :
Message Content Filter - In the Subscription request, a client can filter notifications by TopicExpression (see Section ) and by MessageContent. For the latter, the [WS-BaseNotification] proposes the XPath 1.0 dialect. Due to the specific Message structure required by this specification, the specification requires a subset of the XPath 1.0 syntax. The corresponding dialect can be referenced with the following URI: + In the Subscription request, a client can filter notifications by TopicExpression (see Section ) and by MessageContent. For the latter, the [WS-BaseNotification] proposes the XPath 1.0 dialect. Due to the specific Message structure required by this specification, the specification requires a subset of the XPath 1.0 syntax. The corresponding dialect can be referenced with the following URI: Precedence and associativity: @@ -7281,8 +7457,8 @@ Event description:
SetSynchronizationPoint - Note that section defines rules for devices supporting persistent notification storage that override the behavior defined in this section. - Properties, introduced in section , inform a client about property creation, changes and deletion in a uniform way. When a client wants to synchronize its properties with the properties of the device, it can request a synchronization point which repeats the current status of all properties to which a client has subscribed. The PropertyOperation of all produced notifications is set to “Initialized” (see Section ). The Synchronization Point is requested directly from the SubscriptionManager which was returned in either the SubscriptionResponse or in the CreatePullPointSubscriptionResponse. The property update is transmitted via the notification transportation of the notification interface. The following operation shall be provided by all Subscription Manager Endpoints: + Note that section defines rules for devices supporting persistent notification storage that override the behavior defined in this section. + Properties, introduced in section , inform a client about property creation, changes and deletion in a uniform way. When a client wants to synchronize its properties with the properties of the device, it can request a synchronization point which repeats the current status of all properties to which a client has subscribed. The PropertyOperation of all produced notifications is set to “Initialized” (see Section ). The Synchronization Point is requested directly from the SubscriptionManager which was returned in either the SubscriptionResponse or in the CreatePullPointSubscriptionResponse. The property update is transmitted via the notification transportation of the notification interface. The following operation shall be provided by all Subscription Manager Endpoints: request @@ -7314,17 +7490,17 @@ Event description:
Topic Structure This standard extends the Topic framework defined in the [WS-Topics] specification. - Section describes the ONVIF Topic Namespace. Section incorporates the Message Description Language defined in section into the TopicSet structure, furthermore section defines an interface that allows a client to get this information. A Topic Expression Dialects to be supported by a device is defined in section . + Section describes the ONVIF Topic Namespace. Section incorporates the Message Description Language defined in section into the TopicSet structure, furthermore section defines an interface that allows a client to get this information. A Topic Expression Dialects to be supported by a device is defined in section . Concrete event definitions are specified in the Events sections of the service specifications.
ONVIF Topic Namespace The [WS-Topics] specification distinguishes between the definition of a Topic Tree belonging to a certain Topic Namespace and the Topic Set supported by a certain Web Service. This distinction allows vendors to refer to a common Topic Namespace while only using a portion of the defined Topics. If the Topic Tree of an existing Topic Namespace covers only a subset of the topics available by a device, the Topic Tree can be grown by defining a new Topic Namespace. A new Topic Namespace is defined by appending a new topic to an existing Topic Namespace as described in the [WS-Topics] specification. - All notifications referring to topics in the ONVIF topic namespace shall use the Message Format as described in Section . + All notifications referring to topics in the ONVIF topic namespace shall use the Message Format as described in Section .
Topic Type Information - A device shall add a MessageDescription element, of type MessageDescriptionType defined in Section ‎, below all elements representing topics in the topic set supported by the device. Furthermore a device shall, in accordance with the notification specification, identify all element representing topics in the topic set by including the wstop:topic attribute with value "true". + A device shall add a MessageDescription element, of type MessageDescriptionType defined in Section ‎, below all elements representing topics in the topic set supported by the device. Furthermore a device shall, in accordance with the notification specification, identify all elements representing topics in the topic set by including the wstop:topic attribute with value "true". The following example demonstrates how Topics of a TopicSet are augmented with Message Descriptions: @@ -7453,13 +7629,13 @@ tns1:RuleEngine/FieldDetector//.|tns1:RuleEngine/LineDetector//. An ONVIF compliant device shall respond and declare if its TopicSet is fixed or not, which Topics are provided, and which Dialects are supported. - The following TopicExpressionDialects are mandatory for an ONVIF compliant device (see Section ): + The following TopicExpressionDialects are mandatory for an ONVIF compliant device (see Section ): A device that does not support any MessageContentFilterDialect shall return a single empty url. This specification does not require the support of any ProducerPropertiesDialect by a device. - The Message Content Description Language, introduced in Section , allows referencing of vendor-specific types. In order to ease the interpretation of types, the response element MessageContentSchemaLocation shall list all URI locations to schema files needed to understand vendor specific types. + The Message Content Description Language, introduced in Section , allows referencing of vendor-specific types. In order to ease the interpretation of types, the response element MessageContentSchemaLocation shall list all URI locations to schema files needed to understand vendor specific types.
Capabilities @@ -7467,7 +7643,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet WSSubscriptionPolicySupport - Indication if the device supports the WS Subscription policy according to Section + Indication if the device supports the WS Subscription policy according to Section WSPullPointSupport @@ -7881,15 +8057,15 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet PublishFilter - Concrete Topic Expression to select specific event topics to publish, see section . Example TopicExpression: "tns1:VideoAnalytics//.|tns1:RuleEngine//." - If PublishFilter is empty, then device shall send all events but not metadata, for e.g. "MyDevice/onvif-ej//." . + Concrete Topic Expression to select specific event topics to publish, see section . Example TopicExpression: "tns1:VideoAnalytics//.|tns1:RuleEngine//." + If PublishFilter is empty, then device shall send all events but not metadata, for e.g. "MyDevice/onvif-ej//." . MetadataFilter - Concrete Topic Expression to select specific metadata topics to publish, see section . Example TopicExpression: "tns1:VideoAnalytics//. |tns1:AudioAnalytics//. |tns1:PTZ//." - If MetadataFilter is empty, then device shall send metadata from all active providers, for e.g. "MyDevice/onvif-mj//." . + Concrete Topic Expression to select specific metadata topics to publish, see section . Example TopicExpression: "tns1:VideoAnalytics//. |tns1:AudioAnalytics//. |tns1:PTZ//." + If MetadataFilter is empty, then device shall send metadata from all active providers, for e.g. "MyDevice/onvif-mj//." . @@ -8022,8 +8198,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet AddEventBroker command in the Event service. It shall not be empty. - PayloadPrefix - signals in what format the data is published. See below for + PayloadPrefix - signals in what format the data is published. See below for possible values. @@ -8125,8 +8300,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet The output shall be generated according above described rules.
Example - The XML example response from PullMessages listed in Section contains two messages which are mapped to the following + The XML example response from PullMessages listed in Section contains two messages which are mapped to the following corresponding MQTT topics and JSON payload. In these examples TopicPrefix has been set to "MyDevice". Topic for the first message: @@ -8191,7 +8365,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
Payload for deleted properties - For property events, ONVIF compatible devices shall send a notification with PropertyOperation=Deleted when a property is deleted as explained in section . To achieve same behavior, the device shall send a zero byte payload to the MQTT event broker. This will delete any retained messages in the broker for that specific topic. + For property events, ONVIF compatible devices shall send a notification with PropertyOperation=Deleted when a property is deleted as explained in section . To achieve same behavior, the device shall send a zero byte payload to the MQTT event broker. This will delete any retained messages in the broker for that specific topic.
@@ -8204,11 +8378,11 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet Capability List of GetCapabilities (normative) This annex describes a legacy interface to signal capabilities for a certain service or function using the GetCapabilities method.
- + <tgroup cols="3"> - <colspec colname="c1" colwidth="31*" /> - <colspec colname="c2" colwidth="33*" /> - <colspec colname="c3" colwidth="36*" /> + <colspec colname="c1" colwidth="31*"/> + <colspec colname="c2" colwidth="33*"/> + <colspec colname="c3" colwidth="36*"/> <thead> <row> <entry> @@ -8269,7 +8443,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>IPFilter</para> </entry> <entry> - <para>Indication if the device supports IP filtering control using the commands in Section <xref linkend="_Toc213907655" />, <xref linkend="_Toc213907656" />, <xref linkend="_Toc213907657" /> and <xref linkend="_Toc213907658" />.</para> + <para>Indication if the device supports IP filtering control using the commands in Section <xref linkend="_Toc213907655"/>, <xref linkend="_Toc213907656"/>, <xref linkend="_Toc213907657"/> and <xref linkend="_Toc213907658"/>.</para> </entry> </row> <row> @@ -8277,7 +8451,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>ZeroConfiguration</para> </entry> <entry> - <para>Indication if the device supports zero configuration according to the commands in Section <xref linkend="_Toc213907653" /> and Section <xref linkend="_Toc213907654" />. </para> + <para>Indication if the device supports zero configuration according to the commands in Section <xref linkend="_Toc213907653"/> and Section <xref linkend="_Toc213907654"/>. </para> </entry> </row> <row> @@ -8293,16 +8467,16 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>DynDNS</para> </entry> <entry> - <para>Indication if the device supports Dynamic DNS configuration according to Section <xref linkend="_Toc213907645" />and Section <xref linkend="_Toc214944184" /> .</para> + <para>Indication if the device supports Dynamic DNS configuration according to Section <xref linkend="_Toc213907645"/>and Section <xref linkend="_Toc214944184"/> .</para> </entry> </row> <row> - <entry /> + <entry/> <entry> <para>Dot11Configuration</para> </entry> <entry> - <para>Indication if the device supports IEEE802.11 configuration as specified in Section <xref linkend="_Toc213907659" /></para> + <para>Indication if the device supports IEEE802.11 configuration as specified in Section <xref linkend="_Toc213907659"/></para> </entry> </row> <row> @@ -8313,7 +8487,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>DiscoveryResolve</para> </entry> <entry> - <para>Indication if the device responses to resolve requests as described in Section <xref linkend="_Toc204774617" />.</para> + <para>Indication if the device responses to resolve requests as described in Section <xref linkend="_Toc204774617"/>.</para> </entry> </row> <row> @@ -8321,7 +8495,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>DiscoveryBye</para> </entry> <entry> - <para>Indication if the device sends bye messages as described in Section <xref linkend="_Toc204774618" /></para> + <para>Indication if the device sends bye messages as described in Section <xref linkend="_Toc204774618"/></para> </entry> </row> <row> @@ -8345,7 +8519,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>SystemBackup</para> </entry> <entry> - <para>Indication if the device supports system backup and restore as specified in Section <xref linkend="_Ref276040129" /> and Section <xref linkend="_Toc213907663" /></para> + <para>Indication if the device supports system backup and restore as specified in Section <xref linkend="_Ref276040129"/> and Section <xref linkend="_Toc213907663"/></para> </entry> </row> <row> @@ -8353,7 +8527,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>FirmwareUpgrade</para> </entry> <entry> - <para>Indication if the device supports firmware upgrade as specified in Section <xref linkend="_Toc213907666" />.</para> + <para>Indication if the device supports firmware upgrade as specified in Section <xref linkend="_Toc213907666"/>.</para> </entry> </row> <row> @@ -8361,7 +8535,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>SystemLogging</para> </entry> <entry> - <para>Indication if the device supports system log retrieval as specified in Section <xref linkend="_Ref482093370" />. </para> + <para>Indication if the device supports system log retrieval as specified in Section <xref linkend="_Ref482093370"/>. </para> </entry> </row> <row> @@ -8463,7 +8637,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>AccessPolicyConfig</para> </entry> <entry> - <para>Indication if the device supports retrieving and loading device access control policy according to Section <xref linkend="_Toc213907681" /> and Section <xref linkend="_Toc213907682" />.</para> + <para>Indication if the device supports retrieving and loading device access control policy according to Section <xref linkend="_Toc213907681"/> and Section <xref linkend="_Toc213907682"/>.</para> </entry> </row> <row> @@ -8523,7 +8697,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>RemoteUserHandling</para> </entry> <entry> - <para>Indication if device supports remote user handling and the corresponding methods defined in section <xref linkend="_Toc251861725" /> and <xref linkend="_Ref247076107" />.</para> + <para>Indication if device supports remote user handling and the corresponding methods defined in section <xref linkend="_Toc251861725"/> and <xref linkend="_Ref247076107"/>.</para> </entry> </row> <row> @@ -8542,7 +8716,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>WSSubscriptionPolicySupport</para> </entry> <entry> - <para>Indication if the device supports the WS Subscription policy according to Section<xref linkend="_Toc214944387" /></para> + <para>Indication if the device supports the WS Subscription policy according to Section<xref linkend="_Toc214944387"/></para> </entry> </row> <row> @@ -8550,7 +8724,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>WSPullPointSupport</para> </entry> <entry> - <para>Indication if the device supports the WS Pull Point according to Section <xref linkend="_Toc214944387" /></para> + <para>Indication if the device supports the WS Pull Point according to Section <xref linkend="_Toc214944387"/></para> </entry> </row> <row> @@ -8558,7 +8732,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <para>WSPausableSubscription-ManagerInterfaceSupport</para> </entry> <entry> - <para>Indication if the device supports the WS Pausable Subscription Manager Interface according to Section<xref linkend="_Toc214944387" /></para> + <para>Indication if the device supports the WS Pausable Subscription Manager Interface according to Section<xref linkend="_Toc214944387"/></para> </entry> </row> <row> @@ -8730,7 +8904,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet </entry> </row> <row> - <entry /> + <entry/> <entry> <para>MetadataSearch</para> </entry> @@ -8794,7 +8968,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet </entry> </row> <row> - <entry /> + <entry/> <entry> <para>VideoSources</para> </entry> @@ -8803,7 +8977,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet </entry> </row> <row> - <entry /> + <entry/> <entry> <para>VideoOutputs</para> </entry> @@ -8812,7 +8986,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet </entry> </row> <row> - <entry /> + <entry/> <entry> <para>AudioSources</para> </entry> @@ -8821,7 +8995,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet </entry> </row> <row> - <entry /> + <entry/> <entry> <para>AudioOutputs</para> </entry> @@ -8830,7 +9004,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet </entry> </row> <row> - <entry /> + <entry/> <entry> <para>RelayOutputs</para> </entry> @@ -9105,8 +9279,7 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet <title>JSON payload format
XML to JSON conversion guidance - Instead of creating a full fledged schema for XML to JSON conversion, provides a set of generic rules to express ONVIF XML in JSON format + Instead of creating a full fledged schema for XML to JSON conversion, provides a set of generic rules to express ONVIF XML in JSON format as defined by RFC 7159.
@@ -9217,6 +9390,6 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet Revision History - + diff --git a/doc/Security.xml b/doc/Security.xml index 607dd0ecd..09f1c5d8e 100644 --- a/doc/Security.xml +++ b/doc/Security.xml @@ -1053,7 +1053,11 @@ - roles: Access class. One of the authenticated classes of the default access policy prefixed with the string onvif:, i.e. "onvif:Administrator", "onvif:Operator" or "onvif:User" as defined also within the ONVIF Core Specification. This access level will be used to authorize access to the required function. + roles: Access role. One or more user roles, either + pre-defined ones or prefixed with the string onvif: .i.e. + "onvif:Administrator", "onvif:Operator" or "onvif:User" as defined also within the + ONVIF Core Specification, or custom ones defined on the device. These access roles + will be used to authorize access to the required function. diff --git a/doc/Uplink.xml b/doc/Uplink.xml index c2e6a27bc..5f2182e03 100644 --- a/doc/Uplink.xml +++ b/doc/Uplink.xml @@ -65,6 +65,14 @@ Add support for WebSocket protocol and token authorization. + + 25.06 + June 2025 + + Ottavio Campana + + Add support for user roles. + @@ -340,8 +348,8 @@ CertificateID : ID of the certificate to be used for client authentication. - UserLevel : Authorization level that will be assigned to the uplink - connection + UserLevel : List of authorization levels and roles that will be used to restrict the + commands that will be accepted through the uplink connection. Status : Current connection status diff --git a/wsdl/ver10/device/wsdl/devicemgmt.wsdl b/wsdl/ver10/device/wsdl/devicemgmt.wsdl index 85ba53b5e..cd682699b 100644 --- a/wsdl/ver10/device/wsdl/devicemgmt.wsdl +++ b/wsdl/ver10/device/wsdl/devicemgmt.wsdl @@ -10,7 +10,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO --> - + @@ -272,6 +272,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Supported hashing algorithms as part of HTTP and RTSP Digest authentication.Example: MD5,SHA-256 + + + Whenever set to an integer greater than zero, it signals that the device supports editable user levels. It indicates the maximum number of editable user levels. + + @@ -906,6 +911,53 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -2501,6 +2553,24 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + + + + + + + + + + + + @@ -3096,6 +3166,24 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + This operation returns the editable user levels configured in the device. Whenever an editable + user level is passed in the request, information only about that level is returned. + + + + + This operation configures an editable user level in the device. If the level + passed in UserRole already exists in the device, its configuration is overwritten. Otherwise, + a new editable user level is created. + + + + + This operation deletes an editable user level in the device. + + + This operation returns the configured remote user (if any). A device supporting remote user handling shall support this operation. The user is only valid for the WS-UserToken profile or @@ -3876,6 +3964,33 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index e42a3a05d..a07b0fb40 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -3828,6 +3828,22 @@ decoding .A decoder shall decode every data it receives (according to its capabi + + + + + Name of the editable user level. + + + + + Names of the permitted function for the editable user level. The names must be prepended by the namespace and colon. + + + + + + @@ -3852,6 +3868,11 @@ decoding .A decoder shall decode every data it receives (according to its capabi + + + The names of the roles assigned to the user. + + diff --git a/wsdl/ver10/uplink/wsdl/uplink.wsdl b/wsdl/ver10/uplink/wsdl/uplink.wsdl index f3134dd86..137b41b22 100644 --- a/wsdl/ver10/uplink/wsdl/uplink.wsdl +++ b/wsdl/ver10/uplink/wsdl/uplink.wsdl @@ -81,8 +81,8 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO ID of the certificate to be used for client authentication. - - Authorization level that will be assigned to the uplink connection. + + List of authorization levels and roles that will be used to retrict the commands that will be accepted through the uplink connection. Current connection status (see tup:ConnectionStatus for possible values).