Indicates if the service capabilities (untyped) should be included in the response. Each Service element contains information about one service. Namespace of the service being described. This parameter allows to match the service capabilities to the service. Note that only one set of capabilities is supported per namespace. The transport addresses where the service can be reached. The scheme and IP part shall match the one used in the request (i.e. the GetServices request). The placeholder for the service capabilities. The service capability element shall be returned here. For example for the device service that would be the tds:DeviceServiceCapabilities element (not complextype). The version of the service (not the ONVIF core spec version). The capabilities for the device service is returned in the Capabilities element. Network capabilities. Security capabilities. System capabilities. Capabilities that do not fit in any of the other categories. Indicates support for IP filtering. Indicates support for zeroconf. Indicates support for IPv6. Indicates support for dynamic DNS configuration. Indicates support for IEEE 802.11 configuration. Indicates the maximum number of Dot1X configurations supported by the device Indicates support for retrieval of hostname from DHCP. Maximum number of NTP servers supported by the devices SetNTP command. Indicates support for Stateful IPv6 DHCP. Indicates support for TLS 1.0. Indicates support for TLS 1.1. Indicates support for TLS 1.2. Indicates support for onboard key generation. Indicates support for access policy configuration. Indicates support for the ONVIF default access policy. Indicates support for IEEE 802.1X configuration. Indicates support for remote user configuration. Used when accessing another device. Indicates support for WS-Security X.509 token. Indicates support for WS-Security SAML token. Indicates support for WS-Security Kerberos token. Indicates support for WS-Security Username token. Indicates support for WS over HTTP digest authenticated communication layer. Indicates support for WS-Security REL token. EAP Methods supported by the device. The int values refer to the IANA EAP Registry. The maximum number of users that the device supports. Maximum number of characters supported for the username by CreateUsers. Maximum number of characters supported for the password by CreateUsers and SetUser. Indicates support for WS Discovery resolve requests. Indicates support for WS-Discovery Bye. Indicates support for remote discovery. Indicates support for system backup through MTOM. Indicates support for retrieval of system logging through MTOM. Indicates support for firmware upgrade through MTOM. Indicates support for firmware upgrade through HTTP. Indicates support for system backup through HTTP. Indicates support for retrieval of system logging through HTTP. Indicates support for retrieving support information through HTTP. Indicates support for storage configuration interfaces. Indicates maximum number of storage configurations supported. If present signals support for geo location. The value signals the supported number of entries. List of supported automatic GeoLocation adjustment supported by the device. Valid items are defined by tds:AutoGeoMode. Enumerates the supported StorageTypes, see tds:StorageType. Automatic adjustment of the device location. Automatic adjustment of the device orientation relative to the compass also called yaw. Automatic adjustment of the deviation from the horizon also called pitch and roll. Lists of commands supported by SendAuxiliaryCommand. The manufactor of the device. The device model. The firmware version in the device. The serial number of the device. The hardware ID of the device. Defines if the date and time is set via NTP or manually. Automatically adjust Daylight savings if defined in TimeZone. The time zone in POSIX 1003.1 format Date and time in UTC. If time is obtained via NTP, UTCDateTime has no meaning Contains information whether system date and time are set manually or by NTP, daylight savings is on or off, time zone in POSIX 1003.1 format and system date and time in UTC and also local system date and time. Specifies the factory default action type. Contains the reboot message sent by the device. Contains the arbitary device diagnostics information. Specifies the type of system log to get. Contains the system log information. Contains a list of URI definining the device scopes. Scope parameters can be of two types: fixed and configurable. Fixed parameters can not be altered. Contains a list of scope parameters that will replace all existing configurable scope parameters. Contains a list of new configurable scope parameters that will be added to the existing configurable scope. Contains a list of URIs that should be removed from the device scope.
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. Contains a list of URIs that has been removed from the device scope Indicator of discovery mode: Discoverable, NonDiscoverable. Indicator of discovery mode: Discoverable, NonDiscoverable. Indicator of discovery mode: Discoverable, NonDiscoverable. Indicator of discovery mode: Discoverable, NonDiscoverable. Contains a list of the onvif users and following information is included in each entry: username and user level. Creates new device users and corresponding credentials. Each user entry includes: username, password and user level. Either all users are created successfully or a fault message MUST be returned without creating any user. If trying to create several users with exactly the same username the request is rejected and no users are created. If password is missing, then fault message Too weak password is returned. Deletes users on an device and there may exist users that cannot be deleted to ensure access to the unit. Either all users are deleted successfully or a fault message MUST be returned and no users be deleted. If a username exists multiple times in the request, then a fault message is returned. Updates the credentials for one or several users on an device. Either all change requests are processed successfully or a fault message MUST be returned. If the request contains the same username multiple times, a fault message is returned. List of categories to retrieve capability information on. Capability information. Contains the hostname information. The hostname to set. True if the hostname shall be obtained via DHCP. Indicates whether or not a reboot is required after configuration updates. DNS information. Indicate if the DNS address is to be retrieved using DHCP. DNS search domain. DNS address(es) set manually. NTP information. Indicate if NTP address information is to be retrieved using DHCP. Manual NTP settings. Dynamic DNS information. Dynamic DNS type. DNS name. DNS record time to live. List of network interfaces. Symbolic network interface name. Network interface name. Indicates whether or not a reboot is required after configuration updates. 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. 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. Contains an array of defined protocols supported by the device. There are three protocols defined; HTTP, HTTPS and RTSP. The following parameters can be retrieved for each protocol: port and enable/disable. Configures one or more defined network protocols supported by the device. There are currently three protocols defined; HTTP, HTTPS and RTSP. The following parameters can be set for each protocol: port and enable/disable. Gets the default IPv4 and IPv6 gateway settings from the device. Sets IPv4 gateway address used as default setting. Sets IPv6 gateway address used as default setting. Contains the zero-configuration. Unique identifier referencing the physical interface. Specifies if the zero-configuration should be enabled or not. Certificate id. Identification of the entity associated with the public-key. Certificate validity start date. Certificate expiry start date. base64 encoded DER representation of certificate. Id and base64 encoded DER representation of all available certificates. Indicates if a certificate is used in an optional HTTPS configuration of the device. Indicates if a certificate is to be used in an optional HTTPS configuration of the device. List of ids of certificates to delete. List of ids of certificates to delete. Relative Dinstinguished Name(RDN) CommonName(CN). Optional base64 encoded DER attributes. base64 encoded DER representation of certificate. Optional id and base64 encoded DER representation of certificate. Indicates whether or not client certificates are required by device. Indicates whether or not client certificates are required by device. User name optional password NFS protocol CIFS protocol CDMI protocol FTP protocol local path Storage server address User credential for the storage server StorageType lists the acceptable values for type attribute Returns information about services on the device. Returns the capabilities of the device service. The result is returned in a typed answer. This operation gets basic device information from the device. This operation sets the device system date and time. The device shall support the configuration of the daylight saving setting and of the manual system date and time (if applicable) or indication of NTP time (if applicable) through the SetSystemDateAndTime command.
If system time and date are set manually, the client shall include UTCDateTime in the request.
A TimeZone token which is not formed according to the rules of IEEE 1003.1 section 8.3 is considered as invalid timezone.
The DayLightSavings flag should be set to true to activate any DST settings of the TimeZone string. Clear the DayLightSavings flag if the DST portion of the TimeZone settings should be ignored. This operation gets the device system date and time. The device shall support the return of the daylight saving setting and of the manual system date and time (if applicable) or indication of NTP time (if applicable) through the GetSystemDateAndTime command.
A device shall provide the UTCDateTime information. This operation reloads the parameters on the device to their factory default values. This operation upgrades a device firmware version. After a successful upgrade the response message is sent before the device reboots. The device should support firmware upgrade through the UpgradeSystemFirmware command. The exact format of the firmware data is outside the scope of this standard. This operation reboots the device. This operation restores the system backup configuration files(s) previously retrieved from a device. The device should support restore of backup configuration file(s) through the RestoreSystem command. 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. This operation is retrieves system backup configuration file(s) from a device. The device should support return of back up configuration file(s) through the GetSystemBackup command. The backup is returned with reference to a name and mime-type together with binary data. The exact format of the backup configuration files is outside the scope of this standard. This operation gets a system log from the device. The exact format of the system logs is outside the scope of this standard. This operation gets arbitary device diagnostics information from the device. 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 7. The Scope parameters are of two different types:

• Fixed
• Configurable

Fixed scope parameters are permanent device characteristics and cannot be removed through the device management interface. The scope type is indicated in the scope list returned in the get scope parameters response. A device shall support retrieval of discovery scope parameters through the GetScopes command. As some scope parameters are mandatory, the device shall return a non-empty scope list in the response. This operation sets the scope parameters of a device. The scope parameters are used in the device discovery to match a probe message. 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. This operation adds new configurable scope parameters to a device. The scope parameters are used in the device discovery to match a probe message. The device shall support addition of discovery scope parameters through the AddScopes 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 7. The device shall support deletion of discovery scope parameters through the RemoveScopes command. Table This operation gets the discovery mode of a device. See Section 7.2 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 sets the discovery mode operation of a device. See Section 7.2 for the definition of the different device discovery modes. The device shall support configuration of the discovery mode setting through the SetDiscoveryMode command. This operation gets the remote discovery mode of a device. See Section 7.4 for the definition of remote discovery extensions. A device that supports remote discovery shall support retrieval of the remote discovery mode setting through the GetRemoteDiscoveryMode command. This operation sets the remote discovery mode of operation of a device. See Section 7.4 for the definition of remote discovery remote extensions. A device that supports remote discovery shall support configuration of the discovery mode setting through the SetRemoteDiscoveryMode command. This operation gets the remote DP address or addresses from a device. If the device supports remote discovery, as specified in Section 7.4, the device shall support retrieval of the remote DP address(es) through the GetDPAddresses command. This operation sets the remote DP address or addresses on a device. If the device supports remote discovery, as specified in Section 7.4, the device shall support configuration of the remote DP address(es) through the SetDPAddresses command. A client can ask for the device service endpoint reference address property that can be used to derive the password equivalent for remote user operation. The device shall support the GetEndpointReference command returning the address property of the device service endpoint reference. 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 as a HTTP / RTSP user.
The algorithm to use for deriving the password is described in section 5.12.2.1 of the core specification. This operation sets the remote user. A device supporting remote user handling shall support this operation. The user is only valid for the WS-UserToken profile or as a HTTP / RTSP user.
The password that is set shall always be the original (not derived) password.
If UseDerivedPassword is set password derivation shall be done by the device when connecting to a remote device.The algorithm to use for deriving the password is described in section 5.12.2.1 of the core specification.
To remove the remote user SetRemoteUser should be called without the RemoteUser parameter. This operation lists the registered users and corresponding credentials on a device. The device shall support retrieval of registered device users and their credentials for the user token through the GetUsers command. This operation creates new device users and corresponding credentials on a device for authentication purposes. The device shall support creation of device users and their credentials through the CreateUsers command. 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, as clients may follow the password derivation mechanism which results in 'password equivalent' of length 28 bytes, as described in section 3.1.2 of the ONVIF security white paper. This operation deletes users on a device. The device shall support deletion of device users and their credentials through the DeleteUsers command. A device may have one or more fixed users that cannot be deleted to ensure access to the unit. Either all users are deleted successfully or a fault message shall be returned and no users be deleted. This operation updates the settings for one or several users on a device for authentication purposes. The device shall support update of device users and their credentials through the SetUser command. Either all change requests are processed successfully or a fault message shall be returned and no change requests be processed. It is possible for an endpoint to request a URL that can be used to retrieve the complete schema and WSDL definitions of a device. The command gives in return a URL entry point where all the necessary product specific WSDL and schema definitions can be retrieved. The device shall provide a URL for WSDL and schema download through the GetWsdlUrl command. Any endpoint can ask for the capabilities of a device using the capability exchange request response operation. The device shall indicate all its ONVIF compliant capabilities through the GetCapabilities command. The capability list includes references to the addresses (XAddr) of the service implementing the interface operations in the category. Apart from the addresses, the capabilities only reflect optional functions. This operation is used by an endpoint to get the hostname from a device. The device shall return its hostname configurations through the GetHostname command. This operation sets the hostname on a device. It shall be possible to set the device hostname configurations through the SetHostname command.
A device shall accept string formated according to RFC 1123 section 2.1 or alternatively to RFC 952, other string shall be considered as invalid strings. This operation controls whether the hostname is set manually or retrieved via DHCP. This operation gets the DNS settings from a device. The device shall return its DNS configurations through the GetDNS command. This operation sets the DNS settings on a device. It shall be possible to set the device DNS configurations through the SetDNS command. This operation gets the NTP settings from a device. If the device supports NTP, it shall be possible to get the NTP server settings through the GetNTP command. This operation sets the NTP settings on a device. If the device supports NTP, it shall be possible to set the NTP server settings through the SetNTP command.
A device shall accept string formated according to RFC 1123 section 2.1 or alternatively to RFC 952, other string shall be considered as invalid strings.
Changes to the NTP server list will not affect the clock mode DateTimeType. Use SetSystemDateAndTime to activate NTP operation. This operation gets the dynamic DNS settings from a device. If the device supports dynamic DNS as specified in [RFC 2136] and [RFC 4702], it shall be possible to get the type, name and TTL through the GetDynamicDNS command. This operation sets the dynamic DNS settings on a device. If the device supports dynamic DNS as specified in [RFC 2136] and [RFC 4702], it shall be possible to set the type, name and TTL through the SetDynamicDNS command. This operation gets the network interface configuration from a device. The device shall support return of network interface configuration settings as defined by the NetworkInterface type through the GetNetworkInterfaces command. This operation sets the network interface configuration on a device. The device shall support network configuration of supported network interfaces through the SetNetworkInterfaces 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. This operation gets defined network protocols from a device. The device shall support the GetNetworkProtocols command returning configured network protocols. This operation configures defined network protocols on a device. The device shall support configuration of defined network protocols through the SetNetworkProtocols command. This operation gets the default gateway settings from a device. The device shall support the GetNetworkDefaultGateway command returning configured default gateway address(es). This operation sets the default gateway settings on a device. The device shall support configuration of default gateway through the SetNetworkDefaultGateway command. This operation gets the zero-configuration from a device. If the device supports dynamic IP configuration according to [RFC3927], it shall support the return of IPv4 zero configuration address and status through the GetZeroConfiguration command.
Devices supporting zero configuration on more than one interface shall use the extension to list the additional interface settings. This operation sets the zero-configuration. Use GetCapalities to get if zero-zero-configuration is supported or not. This operation gets the IP address filter settings from a device. If the device supports device access control based on IP filtering rules (denied or accepted ranges of IP addresses), the device shall support the GetIPAddressFilter command. This operation sets the IP address filter settings on a device. If the device supports device access control based on IP filtering rules (denied or accepted ranges of IP addresses), the device shall support configuration of IP filtering rules through the SetIPAddressFilter command. This operation adds an IP filter address to a device. If the device supports device access control based on IP filtering rules (denied or accepted ranges of IP addresses), the device shall support adding of IP filtering addresses through the AddIPAddressFilter command. This operation deletes an IP filter address from a device. If the device supports device access control based on IP filtering rules (denied or accepted ranges of IP addresses), the device shall support deletion of IP filtering addresses through the RemoveIPAddressFilter command. Access to different services and sub-sets of services should be subject to access control. The WS-Security framework 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 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). If the device supports access policy settings based on WS-Security authentication, then the device shall support this command. This operation generates a private/public key pair and also can create a self-signed device certificate as a result of key pair generation. The certificate is created using a suitable onboard key pair generation mechanism.
If a device supports onboard key pair generation, the device that supports TLS shall support this certificate creation command. And also, if a device supports onboard key pair generation, the device that support IEEE 802.1X shall support this command for the purpose of key pair generation. Certificates and key pairs are identified using certificate IDs. These IDs are either chosen by the certificate generation requester or by the device (in case that no ID value is given). This operation gets all device server certificates (including self-signed) for the purpose of TLS authentication and all device client certificates for the purpose of IEEE 802.1X authentication. This command lists only the TLS server certificates and IEEE 802.1X client certificates for the device (neither trusted CA certificates nor trusted root certificates). The certificates are returned as binary data. A device that supports TLS shall support this command and the certificates shall be encoded using ASN.1 [X.681], [X.682], [X.683] DER [X.690] encoding rules. This operation is specific to TLS functionality. This operation gets the status (enabled/disabled) of the device TLS server certificates. A device that supports TLS shall support this command. This operation is specific to TLS functionality. This operation sets the status (enable/disable) of the device TLS server certificates. A device that supports TLS shall support this command. Typically only one device server certificate is allowed to be enabled at a time. This operation deletes a certificate or multiple certificates. The device MAY also delete a private/public key pair which is coupled with the certificate to be deleted. The device that support either TLS or IEEE 802.1X shall support the deletion of a certificate or multiple certificates through this command. Either all certificates are deleted successfully or a fault message shall be returned without deleting any certificate. This operation requests a PKCS #10 certificate signature request from the device. The returned information field shall be either formatted exactly as specified in [PKCS#10] or PEM encoded [PKCS#10] format. In order for this command to work, the device must already have a private/public key pair. This key pair should be referred by CertificateID as specified in the input parameter description. This CertificateID refers to the key pair generated using CreateCertificate command.
A device that support onboard key pair generation that supports either TLS or IEEE 802.1X using client certificate shall support this command. TLS server certificate(s) or IEEE 802.1X client certificate(s) created using the PKCS#10 certificate request command can be loaded into the device using this command (see Section 8.4.13). The certificate ID in the request shall be present. The device may sort the received certificate(s) based on the public key and subject information in the certificate(s). The certificate ID in the request will be the ID value the client wish to have. The device is supposed to scan the generated key pairs present in the device to identify which is the correspondent key pair with the loaded certificate and then make the link between the certificate and the key pair.
A device that supports onboard key pair generation that support either TLS or IEEE 802.1X shall support this command.
The certificates shall be encoded using ASN.1 [X.681], [X.682], [X.683] DER [X.690] encoding rules.
This command is applicable to any device type, although the parameter name is called for historical reasons NVTCertificate. This operation is specific to TLS functionality. This operation gets the status (enabled/disabled) of the device TLS client authentication. A device that supports TLS shall support this command. This operation is specific to TLS functionality. This operation sets the status (enabled/disabled) of the device TLS client authentication. A device that supports TLS shall support this command. This operation gets a list of all available relay outputs and their settings.
This method has been depricated with version 2.0. Refer to the DeviceIO service. This operation sets the settings of a relay output.
This method has been depricated with version 2.0. Refer to the DeviceIO service. This operation sets the state of a relay output.
This method has been depricated with version 2.0. Refer to the DeviceIO service. 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 supported commands can be retrieved via the AuxiliaryCommands capability.
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.

• tt:Wiper|On – Request to start the wiper.
• tt:Wiper|Off – Request to stop the wiper.
• tt:Washer|On – Request to start the washer.
• tt:Washer|Off – Request to stop the washer.
• tt:WashingProcedure|On – Request to start the washing procedure.
• tt: WashingProcedure |Off – Request to stop the washing procedure.
• tt:IRLamp|On – Request to turn ON an IR illuminator attached to the unit.
• tt:IRLamp|Off – Request to turn OFF an IR illuminator attached to the unit.
• tt:IRLamp|Auto – Request to configure an IR illuminator attached to the unit so that it automatically turns ON and OFF.

A device that indicates auxiliary service capability shall support this command. CA certificates will be loaded into a device and be used for the sake of following two cases. The one is for the purpose of TLS client authentication in TLS server function. The other one is for the purpose of Authentication Server authentication in IEEE 802.1X function. This operation gets all CA certificates loaded into a device. A device that supports either TLS client authentication or IEEE 802.1X shall support this command and the returned certificates shall be encoded using ASN.1 [X.681], [X.682], [X.683] DER [X.690] encoding rules. There might be some cases that a Certificate Authority or some other equivalent creates a certificate without having PKCS#10 certificate signing request. In such cases, the certificate will be bundled in conjunction with its private key. This command will be used for such use case scenarios. The certificate ID in the request is optionally set to the ID value the client wish to have. If the certificate ID is not specified in the request, device can choose the ID accordingly.
This operation imports a private/public key pair into the device. The certificates shall be encoded using ASN.1 [X.681], [X.682], [X.683] DER [X.690] encoding rules.
A device that does not support onboard key pair generation and support either TLS or IEEE 802.1X using client certificate shall support this command. A device that support onboard key pair generation MAY support this command. The security policy of a device that supports this operation should make sure that the private key is sufficiently protected. This operation requests the information of a certificate specified by certificate ID. The device should respond with its “Issuer DN”, “Subject DN”, “Key usage”, "Extended key usage”, “Key Length”, “Version”, “Serial Number”, “Signature Algorithm” and “Validity” data as the information of the certificate, as long as the device can retrieve such information from the specified certificate.
A device that supports either TLS or IEEE 802.1X should support this command. This command is used when it is necessary to load trusted CA certificates or trusted root certificates for the purpose of verification for its counterpart i.e. client certificate verification in TLS function or server certificate verification in IEEE 802.1X function.
A device that support either TLS or IEEE 802.1X shall support this command. As for the supported certificate format, either DER format or PEM format is possible to be used. But a device that support this command shall support at least DER format as supported format type. The device may sort the received certificate(s) based on the public key and subject information in the certificate(s). Either all CA certificates are loaded successfully or a fault message shall be returned without loading any CA certificate. This operation newly creates IEEE 802.1X configuration parameter set of the device. The device shall support this command if it supports IEEE 802.1X. If the device receives this request with already existing configuration token (Dot1XConfigurationToken) specification, the device should respond with 'ter:ReferenceToken ' error to indicate there is some configuration conflict. While the CreateDot1XConfiguration command is trying to create a new configuration parameter set, this operation modifies existing IEEE 802.1X configuration parameter set of the device. A device that support IEEE 802.1X shall support this command. This operation gets one IEEE 802.1X configuration parameter set from the device by specifying the configuration token (Dot1XConfigurationToken).
A device that supports IEEE 802.1X shall support this command. Regardless of whether the 802.1X method in the retrieved configuration has a password or not, the device shall not include the Password element in the response. This operation gets all the existing IEEE 802.1X configuration parameter sets from the device. The device shall respond with all the IEEE 802.1X configurations so that the client can get to know how many IEEE 802.1X configurations are existing and how they are configured.
A device that support IEEE 802.1X shall support this command.
Regardless of whether the 802.1X method in the retrieved configuration has a password or not, the device shall not include the Password element in the response. This operation deletes an IEEE 802.1X configuration parameter set from the device. Which configuration should be deleted is specified by the 'Dot1XConfigurationToken' in the request. A device that support IEEE 802.1X shall support this command. This operation returns the IEEE802.11 capabilities. The device shall support this operation. This operation returns the status of a wireless network interface. The device shall support this command. This operation returns a lists of the wireless networks in range of the device. A device should support this operation. This operation is used to retrieve URIs from which system information may be downloaded using HTTP. URIs may be returned for the following system information:
System Logs. Multiple system logs may be returned, of different types. The exact format of the system logs is outside the scope of this specification.
Support Information. This consists of arbitrary device diagnostics information from a device. The exact format of the diagnostic information is outside the scope of this specification.
System Backup. The received file is a backup file that can be used to restore the current device configuration at a later date. The exact format of the backup configuration file is outside the scope of this specification.
If the device allows retrieval of system logs, support information or system backup data, it should make them available via HTTP GET. If it does, it shall support the GetSystemUris command. This operation initiates a firmware upgrade using the HTTP POST mechanism. The response to the command includes an HTTP URL to which the upgrade file may be uploaded. The actual upgrade takes place as soon as the HTTP POST operation has completed. The device should support firmware upgrade through the StartFirmwareUpgrade command. The exact format of the firmware data is outside the scope of this specification. Firmware upgrade over HTTP may be achieved using the following steps:

1. Client calls StartFirmwareUpgrade.
2. Server responds with upload URI and optional delay value.
3. Client waits for delay duration if specified by server.
4. Client transmits the firmware image to the upload URI using HTTP POST.
5. Server reprograms itself using the uploaded image, then reboots.

If the firmware upgrade fails because the upgrade file was invalid, the HTTP POST response shall be “415 Unsupported Media Type”. If the firmware upgrade fails due to an error at the device, the HTTP POST response shall be “500 Internal Server Error”.
The value of the Content-Type header in the HTTP POST request shall be “application/octetstream”. This operation initiates a system restore from backed up configuration data using the HTTP POST mechanism. The response to the command includes an HTTP URL to which the backup file may be uploaded. The actual restore takes place as soon as the HTTP POST operation has completed. Devices should support system restore through the StartSystemRestore command. The exact format of the backup configuration data is outside the scope of this specification.
System restore over HTTP may be achieved using the following steps:

1. Client calls StartSystemRestore.
2. Server responds with upload URI.
3. Client transmits the configuration data to the upload URI using HTTP POST.
4. Server applies the uploaded configuration, then reboots if necessary.

If the system restore fails because the uploaded file was invalid, the HTTP POST response shall be “415 Unsupported Media Type”. If the system restore fails due to an error at the device, the HTTP POST response shall be “500 Internal Server Error”.
The value of the Content-Type header in the HTTP POST request shall be “application/octetstream”. This operation lists all existing storage configurations for the device. This operation creates a new storage configuration. The configuration data shall be created in the device and shall be persistent (remain after reboot). This operation retrieves the Storage configuration associated with the given storage configuration token. This operation modifies an existing Storage configuration. This operation deletes the given storage configuration and configuration change shall always be persistent. This operation lists all existing geo location configurations for the device. This operation allows to modify one or more geo configuration entries. This operation deletes the given geo location entries.