ONVIF Core Client Test Specification

Transcription

1 ONVIF Core Client Test Specification Version June

2 2017 ONVIF, Inc. All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. 2

3 REVISION HISTORY Vers. Date Description Jun 8, 2017 Profile T Normative Reference and Profile T Requirement Level were added according to #201 in the following secrion: NTP Test Cases May 20, 2017 EVENTHANDLING-3 METADATA STREAMING profiles references were updated according #115. Normative references were updated according # May 16, 2017 Requirement level for Profile S, Profile G, and Profile Q was added into Event Handling feature Mar 31, 2017 Relay Outputs Test Cases were changed according to #188 Get Services Test Cases were added according to #70 EVENTHANDLING-3 METADATA STREAMING test was updated according to #168 Profile T Normative Reference was added for the Capabilities Test Cases Mar 24, 2017 Advanced Event Handling Test Cases added. Auxiliary Commands Test Cases added. Scope section updated Mar 20, 2017 HTTP Digest Authentication for RTSP Test Cases added Mar 17, 2017 Profile T Normative Reference were added for the following features: Security, Event Handling, Keep Alive for Pull Point Event Handling Mar 02, 2017 The follwing test cases were updated according to #84: USERHANDLING-1 CREATE USERS USERHANDLING-3 SET USER USERHANDLING-4 DELETE USERS Okt 18, 2016 Features requirement level was added for all features Jun 14, 2016 EVENTHANDLING-3 METADATA STREAMING test case has been updated. Test steps sequence was changed May 11, 2016 Profile Q requirement level was updated for the following test cases: ZEROCONFIGURATION-1, ZEROCONFIGURATION-2 Hostname Configuration Test Cases were added. DNS Configuration Test Cases were added. Network Protocols Configuration Test Cases were added Apr 19, 2016 Test cases about specific event were removed: MONITORINGNOTIFICATIONS-1, MONITORINGNOTIFICATIONS-2, 3

4 MONITORINGNOTIFICATIONS-3, MONITORINGNOTIFICATIONS-4, DEVICEMANAGEMENTNOTIFICATIONS-1, DEVICEMANAGEMENTNOTIFICATIONS-2, DEVICEMANAGEMENTNOTIFICATIONS-3, DEVICEMANAGEMENTNOTIFICATIONS-4, DEVICEMANAGEMENTNOTIFICATIONS-5. Monitoring Notifications scenario updated Device Management Notifications scenario updated Apr 18, 2016 System Date and Time Configuration test cases were updated: Normative References for Profile S, Profile A, Profile C, and Profile G were updated. Step description in Test Procedure was updated for the EVENTHANDLING-3 test case. Old description: Device response has code RTSP 200 OK if it is detected New description: If Device sends response to RTSP TEARDOWN, it has code RTSP 200 OK Mar 18, 2016 Checking of TEARDOWN response was changed in Test Procedure and PASS criteria for the EVENTHANDLING-3 test case. Old description of checking of TEARDOWN response in Test Procedure: Device responds with code RTSP 200 OK. New description of checking of TEARDOWN response in Test Procedure: Device response has code RTSP 200 OK if it is detected. Old description of checking of TEARDOWN response in PASS criteria: Device response on the RTSP TEARDOWN request fulfills the following requirements: New description of checking of TEARDOWN response in PASS criteria: If there is Device response on the RTSP TEARDOWN request then it fulfills the following requirements: Mar 16, 2016 Docbook stylesheets were updated Mar 14, was removed from Сopyright section Feb 26, 2016 The following steps were removed because the requirements are fullfield by XML Schemas validation: SET NTP SETTINGS: [S2] "<SetNTP>" includes tag: "<FromDHCP>" with "TRUE" OR "FALSE" value AND SET ZERO CONFIGURATION SETTINGS: [S3] "<SetZeroConfiguration>" includes tag: "<Enabled>" with "TRUE" OR "FALSE" value AND 4

5 GET SERVICES: [S2] (Client request does not contain "<IncludeCapability>" tag OR "<GetServices>" includes tag: "<IncludeCapability>" with either "TRUE" OR "FALSE" values) AND Jan 28, 2016 HTTP System Backup Test Cases and HTTP System Restore Test Cases were added Jan 27, 2016 Remote User Handling Test Cases were moved into ONVIF Postponed Test Specification since this functionality was removed from Profile Q Jan 21, 2016 RFC 2617 was added to normative reference. OASIS Web Services Security UsernameToken Profile 1.0 was added to normative reference. WS-Discovery was added to normative reference. The following namespaces were added to the list: The description about structure and hierarchy was replaced for the test cases: SECURITY-1, CAPABILITIES-1, CAPABILITIES-2, EVENTHANDLING-1, EVENTHANDLING-2, DISCOVERY-1, NETWORKCONFIGURATION-1, NETWORKCONFIGURATION-2, NETWORKCONFIGURATION-3, NETWORKCONFIGURATION-4, SYSTEM-1, USERHANDLING-1, USERHANDLING-2, USERHANDLING-3, USERHANDLING-4, RELAYOUTPUTS-1, RELAYOUTPUTS-2, RELAYOUTPUTS-3, RELAYOUTPUTS-4, NTP-1, NTP-2, DYNAMICDNS-1, DYNAMICDNS-2, ZEROCONFIGURATION-1, ZEROCONFIGURATION-2, IPADDRESSFILTERING-1, IPADDRESSFILTERING-2, IPADDRESSFILTERING-3, IPADDRESSFILTERING-4, IPADDRESSFILTERING-5, IPADDRESSFILTERING-6, IPADDRESSFILTERING-7, PERSISTENTNOTIFICATIONSTORAGERETRIEVAL-1 Old description: Client %COMMAND NAME% request message is a well-formed SOAP request (refer to onvif.xsd) AND Client %COMMAND NAME% request message has a proper hierarchy (refer to %SERVICE%.wsdl) AND New description: Client %COMMAND NAME% request messages are valid according to XML Schemas listed in Namespaces AND Client %COMMAND NAME% request in Test Procedure fulfills the following requirements: The following steps was removed because the requirements are fullfield by XML Schemas validation: EVENTHANDLING-1: 5

6 [S5] "<PullMessages>" includes tag: "<Timeout>" AND [S6] "<PullMessages>" includes tag: "<MessageLimit>" AND EVENTHANDLING-2: [S2] "<Subscribe>" includes tag: "<ConsumerReference>" AND [S3] "<ConsumerReference>" includes tag: "<Address>" AND EVENTHANDLING-2: [S2] "<Subscribe>" includes tag: "<ConsumerReference>" AND [S3] "<ConsumerReference>" includes tag: "<Address>" AND NETWORKCONFIGURATION-2: [S3] "<SetNetworkInterfaces>" includes tag: "<NetworkInterface>" AND USERHANDLING-1: [S5] "<User>" includes tag: "<UserLevel>" with non-empty string value AND USERHANDLING-3: [S4] "<User>" includes tag: "<UserLevel>" with non-empty string value AND RELAYOUTPUTS-2: [S3] "<SetRelayOutputState>" includes tag: "<LogicalState>" with "Active" OR "Inactive" value AND RELAYOUTPUTS-3: [S3] "<SetRelayOutputSettings>" includes tag: "<Properties>" AND [S5] "<Properties>" includes tag: "<DelayTime>" AND [S6] "<Properties>" includes tag: "<IdleState>" with "Closed" OR "Open" value AND RELAYOUTPUTS-4: [S3] "<SetRelayOutputSettings>" includes tag: "<Properties>" AND [S5] "<Properties>" includes tag: "<DelayTime>" AND [S6] "<Properties>" includes tag: "<IdleState>" with "Closed" OR "Open" value AND DYNAMICDNS-2: [S2] "<SetDynamicDNS>" includes tag: "<Type>" with value EITHER "NoUpdate" OR "ClientUpdates" OR "ServerUpdates" AND IPADDRESSFILTERING-2: [S2] "<SetIPAddressFilter>" includes tag: "<Type>" with "Allow" OR "Deny" value AND IPADDRESSFILTERING-3: [S2] "<SetIPAddressFilter>" includes tag: "<Type>" with "Allow" OR "Deny" value AND IPADDRESSFILTERING-4: 6

7 [S2] "<AddIPAddressFilter>" includes tag: "<Type>" with "Allow" OR "Deny" value AND IPADDRESSFILTERING-5: [S2] "<AddIPAddressFilter>" includes tag: "<Type>" with "Allow" OR "Deny" value AND IPADDRESSFILTERING-6: [S2] "<RemoveIPAddressFilter>" includes tag: "<Type>" with "Allow" OR "Deny" value AND IPADDRESSFILTERING-7: [S2] "<RemoveIPAddressFilter>" includes tag: "<Type>" with "Allow" OR "Deny" value AND PERSISTENTNOTIFICATIONSTORAGERETRIEVAL-1: [S5] "<Seek>" includes tag: "<UtcTime>" with non-empty value of date and time AND [S9] "<PullMessages>" includes tag: "<Timeout>" AND [S10] "<PullMessages>" includes tag: "<MessageLimit>" AND Dec 30, 2015 METADATA STREAMING test case was updated to check of media type in RTSP SETUP requests and to check of corresponding between RTSP session and GetStreamUri. Device Management Notifications was added Dec 24, 2015 Monitoring Notifications was added Dec 23, 2015 System Date and Time Configuration was added. Remote User Handling was added. HTTP Firmware Upgrade was added. Normative references were updated Dec 08, 2015 Keep Alive for Pull Point Event Handling Test Cases feture failed criteria were updated New precondition was added to GETSERVICES Dec 03, 2015 General item (Test Owerview) was added Minor updates in formatting, typos and terms. Keep Alive for Pull Point Event Handling Test Cases was updated to remove verification of Action and ReferenceParameters Jen 08, 2016 Advanced Pull Point Event Handling was added. Profile A requirement level was added for old test cases. Get Services with Capabilities was added Jun 10, 2015 No major changes were made, just minor formatting fixes May 20, 2015 No major changes were made, just minor grammatical corrections Mar 20, 2015 Added new Test Cases sections: Discovery, Network Configuration, System, User Handling, Relay Outputs, NTP, Dynamic DNS, Zero Configuration, IP Address Filtering and Persistent Notification Storage Retrieval. 7

8 14.12 Dec 11, 2014 Fixed typos and inconsistencies Nov 21, 2014 Fixed typos and inconsistencies. Removed examples of expected Requests and Responses from all Test Cases. Removed unnecessary PASS criteria from all Test Cases. EVENTHANDLING-1 and EVENTHANDLING-3 test cases have been updated. "3. Terms and Definitions" section has been updated. Introduced YY.MM method of version numbering 1.4 Sep 04, 2014 The SECURITY-1 USER TOKEN PROFILE test case has been updated. The SECURITY-2 DIGEST AUTHENTICATION test case has been updated. The CAPABILITIES-1 GET SERVICES test case has been updated. The CAPABILITIES-2 GET CAPABILITIES test case has been updated. The EVENTHANDLING-1 PULLPOINT test case has been updated. The EVENTHANDLING-2 BASE NOTIFICATION test case has been updated. The EVENTHANDLING-3 METADATA STREAMING test case has been updated. "Scope", "Security", "Capabilities" and "Event Handling" sections have been updated. 1.3 Jul 31, 2014 The SECURITY-1 USER TOKEN PROFILE test case has been updated. The SECURITY-2 DIGEST AUTHENTICATION test case has been updated. Section "Test Policy" has been removed. "Introduction", "Scope", "Security", "Capabilities", "Event Handling", "Normative references", "Definition" and "Test Setup" sections have been updated. The CAPABILITIES-1 GET SERVICES test case has been added. The CAPABILITIES-2 GET CAPABILITIES test case has been added. The EVENTHANDLING-1 PULLPOINT test case has been added. The EVENTHANDLING-2 BASE NOTIFICATION test case has been added. The EVENTHANDLING-3 METADATA STREAMING test case has been added. 1.2 Jun 27, 2014 Subsections "Capabilities" and "Event Handling" have been added to "Introduction" section. 8

9 "Definition" section has been updated. "Test Setup" section has been updated. Subsections "Capabilities" and "Event Handling" have been added to "Test Policy" section. Tests "GET SERVICES" and "GET CAPABILITIES" have been added to "Capabilities Test Cases" section. Tests "PULLPOINT", "BASE NOTIFICATION" and "METADATA STREAMING" have been added to "Event Handling Test Cases" section. Examples of expected Requests and Responses have been updated for "Security Test Cases" section. 1.1 Jun 16, 2014 Changes were made in the Security Test Cases specification. 1.0 Jun 11, 2014 Initial version The new section "Normative references" has been added. "Introduction", "Scope" and "Security" sections have been updated. "Definition" section has been updated. 9

10 Table of Contents 1 Introduction Scope Security Capabilities Get Services with Capabilities Event Handling Advanced Event Handling Keep Alive for Pull Point Event Handling Discovery Network Configuration System User Handling Relay Outputs NTP Dynamic DNS Zero Configuration IP Address Filtering Persistent Notification Storage Retrieval System Date and Time Configuration HTTP Firmware Upgrade HTTP System Backup HTTP System Restore Monitoring Notifications Device Management Notifications Hostname Configuration DNS Configuration Network Protocols Configuration HTTP Digest Authentication for RTSP Auxiliary Commands Normative references

11 3 Terms and Definitions Conventions Definitions Abbreviations Namespaces Test Overview General Feature Level Requirement Expected Scenarios Under Test Test Cases Test Setup Prerequisites Security Test Cases Feature Level Requirement: Expected Scenarios Under Test: USER TOKEN PROFILE HTTP DIGEST AUTHENTICATION Capabilities Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET SERVICES GET CAPABILITIES Get Services Test Cases Feature Level Requirement: Expected Scenarios Under Test: Get Services with Capabilities Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET SERVICES Event Handling Test Cases Feature Level Requirement:

12 9.2 Expected Scenarios Under Test: PULLPOINT BASE NOTIFICATION METADATA STREAMING Advanced Event Handling Test Cases Expected Scenarios Under Test: SET SYNCHRONIZATION POINT UNSUBSCRIBE Keep Alive for Pull Point Event Handling Test Cases Feature Level Requirement: Expected Scenarios Under Test: RENEW PULL MESSAGES AS KEEP ALIVE Discovery Test Cases Feature Level Requirement: Expected Scenarios Under Test: WS-DISCOVERY Network Configuration Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET NETWORK INTERFACES SET NETWORK INTERFACES GET NETWORK DEFAULT GATEWAY SET NETWORK DEFAULT GATEWAY System Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET DEVICE INFORMATION User Handling Test Cases Feature Level Requirement: Expected Scenarios Under Test:

13 15.3 CREATE USERS GET USERS SET USER DELETE USERS Relay Outputs Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET RELAY OUTPUTS SET RELAY OUTPUT STATE SET RELAY OUTPUT SETTINGS BISTABLE MODE SET RELAY OUTPUT SETTINGS MONOSTABLE MODE NTP Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET NTP SET NTP Dynamic DNS Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET DYNAMIC DNS SETTINGS SET DYNAMIC DNS SETTINGS Zero Configuration Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET ZERO CONFIGURATION SET ZERO CONFIGURATION IP Address Filtering Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET IP ADDRESS FILTER SET IPv4 ADDRESS FILTER

14 20.5 SET IPv6 ADDRESS FILTER ADD IPv4 ADDRESS FILTER ADD IPv6 ADDRESS FILTER REMOVE IPv4 ADDRESS FILTER REMOVE IPv6 ADDRESS FILTER Persistent Notification Storage Retrieval Test Cases Feature Level Requirement: Expected Scenarios Under Test: SEEK System Date and Time Configuration Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET SYSTEM DATE AND TIME SET SYSTEM DATE AND TIME HTTP Firmware Upgrade Test Cases Feature Level Requirement: Expected Scenarios Under Test: FIRMWARE UPGRADE VIA HTTP HTTP System Backup Test Cases Feature Level Requirement: Expected Scenarios Under Test: HTTP SYSTEM BACKUP HTTP System Restore Test Cases Feature Level Requirement: Expected Scenarios Under Test: HTTP SYSTEM RESTORE Monitoring Notifications Test Cases Feature Level Requirement: Expected Scenarios Under Test: Device Management Notifications Test Cases Feature Level Requirement:

15 27.2 Expected Scenarios Under Test: Hostname Configuration Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET HOSTNAME SET HOSTNAME DNS Configuration Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET DNS SET DNS Network Protocols Configuration Test Cases Feature Level Requirement: Expected Scenarios Under Test: GET NETWORK PROTOCOLS SET NETWORK PROTOCOLS HTTP Digest Authentication for RTSP Test Cases Feature Level Requirement: Expected Scenarios Under Test: HTTP DIGEST AUTHENTICATION FOR RTSP Auxiliary Commands Test Cases Feature Level Requirement: Expected Scenarios Under Test: SEND AUXILIARY COMMAND

16 1 Introduction The goal of the ONVIF Test Specification set is to make it possible to realize fully interoperable IP physical security implementations from different vendors. This specification also acts as an input document to the development of a test tool which will be used to test the ONVIF Client implementation conformance towards ONVIF standard. This Client Test Tool analyzes network communications between ONVIF Devices and Clients being tested and determines whether a specific Client is ONVIF conformant (see ONVIF Conformance Process Specification). This particular document defines test cases required for testing Core features of a Client application e.g. EventHandling, Security and Capabilities. Also the test cases are to be basic inputs for some Profile specification requirements. It also describes the test framework, test setup, pre-requisites, test policies needed for the execution of the described test cases. 1.1 Scope This ONVIF Core Client Test Specification defines and regulates the conformance testing procedure for the ONVIF conformant Clients in the scope of Core features. Conformance testing is meant to be black-box network traces analysis and verification. The objective of this specification is to provide the test cases to test individual requirements of ONVIF Clients in the scope of Core features according to ONVIF Profile Specifications. The principal intended purposes are: Provide self-assessment tool for implementations. Provide comprehensive test suite coverage for Core features. This specification does not address the following: Product use cases and non-functional (performance and regression) testing and analysis. SOAP Implementation Interoperability test i.e. Web Services Interoperability Basic Profile version 2.0 (WS-I BP2.0). Network protocol implementation Conformance test for HTTPS, HTTP, RTP and RTSP protocols. The following sections cover test cases needed for the verification of relevant features as mentioned in the ONVIF Profile Specifications. 16

17 1.2 Security Security section defines security mechanism for two different authentication methods: Digest Authentication and Username Token Profile. The scope of this specification is limited to Message level security. 1.3 Capabilities Capabilities section specifies Client ability to retrieve available services and advanced functionalities which are offered by a Device. 1.4 Get Services with Capabilities Get Services with Capabilities section specifies Client ability to retrieve capabilities of services with using GetServices operation. 1.5 Event Handling Event Handling section defines Client ability to initiate and receive notifications (events) from a Device. The event handling test cases cover the following mandatory interfaces: Pull Point Notification Interface This test specification provides test cases to verify the implementation of the PullPoint Interface of a Client. Basic Notification Interface This test specification provides test cases to verify the implementation of the Basic Notification Interface of a Client. Metadata Streaming Interface This test specification provides test cases to verify the implementation of the Metadata Streaming Interface of a Client. 1.6 Advanced Event Handling Advanced Event Handling section defines Client ability to synchronize its properties with the properties of the device using SetSynchronizationPoint operation and terminete subscription using Unsubscribe operation. 17

18 1.7 Keep Alive for Pull Point Event Handling Keep Alive for Pull Point Event Handling section specifies Client ability to use keep alive for Pull Point Event Handling using PullMessages or Renew approach. 1.8 Discovery Discovery section defines Client ability to locate services on a local network using Web Services Dynamic Discovery (WS-Discovery) protocol. It uses IP multicast address and TCP and UDP port 3702 and SOAP-over-UDP standard for communication between nodes. 1.9 Network Configuration Network Configuration section defines Client ability to obtain and configure of network settings on Device System System section defines Client ability to obtain Device information and configure of system settings on Device User Handling User Handling section defines Client ability to manage users on Device Relay Outputs Relay Outputs section defines Client ability to list, configure and trigger relay outputs on Device NTP NTP section defines Client ability to configure synchronization of time using NTP servers on Device Dynamic DNS Dynamic DNS section defines Client ability to configure dynamic DNS settings on Device Zero Configuration Zero Configuration section defines Client ability to enable or disable zero configuration on Device. 18

19 1.16 IP Address Filtering IP Address Filtering section defines Client ability to manage IP address filters on Device Persistent Notification Storage Retrieval Persistent Notification Storage Retrieval section defines Client ability to seek stored events in Device System Date and Time Configuration System Date and Time Configuration section defines Client ability to configure Device system date and time using GetSystemDateAndTime and SetSystemDateAndTime operations HTTP Firmware Upgrade HTTP Firmware Upgrade section defines Client ability to upgrade Device firmware over HTTP using StartFirmwareUpgrad operation and HTTP POST HTTP System Backup HTTP System Backup section defines Client ability to backup system configurations over HTTP using GetSystemUris operation and HTTP GET HTTP System Restore HTTP System Restore section defines Client ability to restore system configurations over HTTP using StartSystemRestore operation and HTTP POST Monitoring Notifications Monitoring Notifications section specifies Client ability to receive from Device monitoring notifications Device Management Notifications Device Management Notifications section specifies Client ability to receive from Device device management notifications. 19

20 1.24 Hostname Configuration Hostname Configuration section defines Client ability to obtain and configure of hostname settings on Device DNS Configuration DNS Configuration section defines Client ability to obtain and configure of DNS settings on Device Network Protocols Configuration Network Protocols Configuration section defines Client ability to obtain and configure of network protocols settings on Device HTTP Digest Authentication for RTSP HTTP Digest Authentication for RTSP section defines security mechanism for Digest Authentication for RTSP Auxiliary Commands Auxiliary Commands section defines Client ability to manage auxiliary commands supported by the Device. 20

21 2 Normative references ONVIF Conformance Process Specification: ONVIF Profile Policy: ONVIF Core Specifications: ONVIF Streaming Specification: ONVIF Profile S Specification: ONVIF Profile G Specification: ONVIF Profile C Specification: ONVIF Profile Q Specification: ONVIF Profile A Specification: ONVIF Core Client Test Specification: ISO/IEC Directives, Part 2, Annex H: ISO : Annex P:

22 WS-BaseNotification: W3C SOAP 1.2, Part 1, Messaging Framework: W3C XML Schema Part 1: Structures Second Edition: W3C XML Schema Part 2: Datatypes Second Edition: " [ W3C Web Services Addressing 1.0 Core: OASIS Web Services Security UsernameToken Profile 1.0: IETF RFC 2617, HTTP Authentication: XMLSOAP, Web Services Dynamic Discovery (WS-Discovery), J. Beatty et al., April

23 3 Terms and Definitions 3.1 Conventions The key words "shall", "shall not", "should", "should not", "may", "need not", "can", "cannot" in this specification are to be interpreted as described in [ISO/IEC Directives Part 2]. 3.2 Definitions This section describes terms and definitions used in this document. Address Profile ONVIF Device ONVIF Client Capability Metadata Conversation An address refers to a URI. See ONVIF Profile Policy. Computer appliance or software program that exposes one or multiple ONVIF Web Services. Computer appliance or software program that uses ONVIF Webservices. List of services and features supported by an ONVIF Device. All streaming data except video and audio, including video analytics results, PTZ position data and other metadata (such as textual data from POS applications). A conversation is all exchanges between two MAC addresses that contains SOAP request and response. Network A network is an interconnected group of devices communicating using the Internet protocol. Network Trace Capture file SOAP Data file created by a network protocol analyzer software (such as Wireshark). Contains network packets data recorded during a live network communications. SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. Client Test Tool ONVIF Client Test Tool that tests ONVIF Client implementation towards the ONVIF Test Specification set. NO SOAP ERROR Valid Device Response WS-Discovery Indication of absence of a SOAP Fault element (which is used to indicate error messages). If a Fault element is present, it shall appear as a child element of the Body element. A Fault element can only appear once in a SOAP message. Device has responded to specific request with code HTTP or RTSP 200 OK and SOAP fault message has not appeared. Web service specification defines a multicast discovery protocol to locate services. By default, Client sends probes 23

24 to a multicast group, and target services that match return a response directly to the requester. Zero Configuration Technology that allows automatically create a computer network over TCP/IP protocol suite between interconnected network units. 3.3 Abbreviations This section describes abbreviations used in this document. HTTP HTTPS IP Hyper Text Transport Protocol. Hyper Text Transport Protocol over Secure Socket Layer. Internet Protocol. IPv4 Internet Protocol version 4. RTCP RTSP SDP TCP UDP URI WSDL RTP Control Protocol. Real Time Streaming Protocol. Session Description Protocol. Transport Control Protocol. User Datagram Protocol. Uniform Resource Identifier. Web Services Description Language. WS-I BP 2.0 Web Services Interoperability Basic Profile version 2.0. XML extensible Markup Language. 3.4 Namespaces Prefix and namespaces used in this test specification are listed in Table 1. These prefixes are not part of the standard and an implementation can use any prefix. Table 3.1. Defined namespaces in this specification Prefix Namespace URI Description soapenv Envelope namespace as defined by SOAP 1.2 [SOAP 1.2, Part 1]. ter The namespace for ONVIF defined faults. Schema, Part1] and [XMLSchema,Part 2]. xsi xs Instance namespace as defined by XS [XML- XML schema instance namespace. 24

25 Prefix Namespace URI Description tns1 The namespace for the ONVIF topic namespace. tt ONVIF XML schema descriptions. tds The namespace for the WSDL device service. tev The namespace for the WSDL event service. tas advancedsecurity/wsdl The namespace for the WSDL advanced security service. wsse wsu d wsadis wsnt Schema namespace of the [WS- BaseNotification] specification. wsa Device addressing namespace as defined by [WS-Addressing]. wss/2004/01/oasis wsswssecurity-secext-1.0.xsd wss/2004/01/oasis wsswssecurity-utility-1.0.xsd ws/2005/04/discovery ws/2004/08/addressing Web Services Security UsernameToken Profile namespace as defined by [OASIS Web Services Security UsernameToken Profile 1.0]. Web Services Security utility namespace as defined by [OASIS Web Services Security UsernameToken Profile 1.0]. Device discovery namespace as defined by [WS- Discovery]. Device addressing namespace referred in WS- Discovery [WS-Discovery]. 25

26 4 Test Overview This section provides information for the test setup procedure and required prerequisites that should be followed during test case execution. Conformance to ONVIF Core Client Test Specification is a prerequisite which is required for testing Client to conformance with Profile S, G and C. 4.1 General Test Cases are grouped depending on features. Each Test Cases group provides description of feature requirement level for Profiles, expected scenario under test and related test cases: Feature Level Requirement Expected Scenarios Under Test List of Test Cases Feature Level Requirement Feature Level Requirement item contains a feature ID and feature requirement level for the Profiles, which will be used for Profiles conformance. If Feature Level Requirement is defined as Mandatory for some Profile, Client shall pass Expected Scenario Under Test for each Device with this Profile support to claim this Profile Conformance. If Feature Level Requirement is defined as Conditional, Optional for some Profile, Client shall pass Expected Scenario Under Test for at least one Device with this Profile support to claim feature as supported Expected Scenarios Under Test Expected Scenarios Under Test item contains expected scenario under test, conditions when the feature will be defined as supported and as not supported Test Cases Test Case items contain list of test cases which are related to feature. Test cases provide exact procedure of testing feature support conditions. Each Test Case contains the following parts: 26

27 Test Label - Unique label for each test Test Case ID - Unique ID for each test Profile Normative References - Requirement level for the feature under test is defined in Profile Specification. This reference is informative and will not be used in conformance procedure. Feature Under Test - Feature which is under current test. Typically a particular command or an event. Test Purpose - The purpose of current test case. Pre-Requisite - The pre-requisite defines when the test should be performed. In case if prereqiusite does not match, the test result will be NOT DETECTED. Test Procedure - scenario expected to be reflected in network trace file. Test Result - Passed and failed criteria of the test case. Depending on these criteria test result will be defined as PASSED or FAILED. Validated Feature List - list of features ID related to this test case. 4.2 Test Setup Collect Network Traces files required by the test cases. Collect Feature List XML files for Devices detected in the Network Trace files. Client shall support all mandatory and conditional features listed in the Device Feature List XML file supplied for the Profiles supported by the Client. For compatibility with the Core Features, the ONVIF Client shall follow the requirements of the conformance process. For details please see the latest ONVIF Conformance Process Specification. 4.3 Prerequisites The pre-requisites for executing the test cases described in this Test Specification include: The Device shall be configured with an IPv4 address. The Device shall be able to be discovered by the Client. 27

28 5 Security Test Cases 5.1 Feature Level Requirement: Validated Feature: Security Profile A Requirement: Mandatory Profile C Requirement: Mandatory Profile G Requirement: Mandatory Profile Q Requirement: Mandatory Profile S Requirement: Mandatory Profile T Requirement: Mandatory 5.2 Expected Scenarios Under Test: 1. Client invokes a specific command which is under testing without any user credentials (no UsernameToken, no HTTP Digest authentication header). IF Device returns a correct response, THEN Client determines that Device does not require any user authentication toward the command according to the configured security policy. 2. Client shall provide with the proper level of user credential to continue the test procedure in the following cases: IF Device returns HTTP 401 Unauthorized error along with WWW-Authentication: Digest header, THEN Client determines that Device supports HTTP Digest authentication. IF Device returns SOAP fault (Sender/NotAuthorized) message, THEN Client determines that UsernameToken is supported by Device. 3. Client is considered as supporting Security User Authentication if the following conditions are met: Device returns a valid response to specific request with UsernameToken authentication header OR Device returns a valid response to specific request with HTTP Digest authentication header. 28

29 4. Client is considered as NOT supporting Security (User Authentication) if the following is TRUE: All HTTP Digest attempts detected are failed AND All UsernameToken attempts detected are failed. 5.3 USER TOKEN PROFILE Test Label: Security - User token profile Test Case ID: SECURITY-1 Profile S Normative Reference: Mandatory Profile G Normative Reference: Optional Profile C Normative Reference: Optional Profile Q Normative Reference: None Profile A Normative Reference: None Profile T Normative Reference: None Feature Under Test: Security Test Purpose: To verify that the Client supports the User Token Profile for Message level security. Pre-Requisite: The Network Trace Capture files contains at least one Conversation between Client and Device with UsernameToken Authentication present. Test Procedure (expected to be reflected in network trace file): 1. Client sends a request (e.g. GetUsers) to the Device with correctly formatted UsernameToken. 2. Verify that the Device accepts the correct request. Test Result: PASS - Client request messages are valid according to XML Schemas listed in Namespaces AND 29

30 Client request that contains UsernameToken authentication in SOAP header fulfills the following requirements: [S1] Client request contains "<Security>" tag after the "<Header>" tag AND [S2] "<Security>" includes tag: "<UsernameToken>" AND [S3] "<UsernameToken>" includes tag: "<Username>" AND [S4] "<UsernameToken>" includes tag: "<Password>" AND [S5] "<UsernameToken>" includes tag: "<Nonce>" AND [S6] "<UsernameToken>" includes tag: "<Created>" AND [S7] Device response contains "HTTP/* 200 OK" AND [S8] Device response does NOT contain "<Fault>" tag. FAIL - The Client failed PASS criteria. Validated Feature List: Security.UsernameToken 5.4 HTTP DIGEST AUTHENTICATION Test Label: Security - HTTP Digest Authentication. Test Case ID: SECURITY-2 Profile S Normative Reference: Mandatory Profile G Normative Reference: Mandatory Profile C Normative Reference: Mandatory Profile Q Normative Reference: Mandatory Profile A Normative Reference: Mandatory Profile T Normative Reference: Mandatory Feature Under Test: Security Test Purpose: To verify that the Client supports the HTTP Digest Authentication for HTTP level security. 30

31 Pre-Requisite: The Network Trace Capture files contains at least one Conversation between Client and Device with HTTP Digest Authentication present. Test Procedure (expected to be reflected in network trace file): 1. Client sends a request that requires authentication (e.g. GetUsers) to the Device without any authentication. 2. Device rejects the request with HTTP error code 401 AND an HTTP Digest challenge. 3. Client sends a valid request with HTTP Digest Authentication. 4. Device accepts the correct request with response code HTTP 200 OK. Test Result: PASS - [S1] Client request contains (HTTP GET method OR HTTP POST method) without any authentication AND Client HTTP GET request has a proper hierarchy (refer to [RFC 1945]) AND [S2] Device response contains "HTTP/* 401 Unauthorized" AND [S3] Device response contains "realm=*" element AND [S4] Device response contains "nonce=*" element AND [S5] Client request contains (HTTP GET method OR HTTP POST method) with "Authorization: Digest username=*" element AND Client HTTP GET request with HTTP Authentication has a proper hierarchy (refer to [RFC 1945]) AND [S6] Client request contains "realm=*" element with value from Device response AND [S7] Client request contains "nonce=*" element with value from Device response AND [S8] Client request contains "uri=*" element AND [S9] Device response contains "HTTP/* 200 OK". FAIL - The Client failed PASS criteria. 31

32 Validated Feature List: Security.HTTPDigest 32

33 6 Capabilities Test Cases 6.1 Feature Level Requirement: Validated Feature: Capabilities Profile A Requirement: Mandatory Profile C Requirement: Mandatory Profile G Requirement: Mandatory Profile Q Requirement: Mandatory Profile S Requirement: Mandatory Profile T Requirement: Mandatory 6.2 Expected Scenarios Under Test: 1. Client invokes a specific Capabilities command which is under testing. 2. Client is considered as supporting Capabilities if the following conditions are met: Device returns a valid response to GetServices request OR Device returns a valid response to GetCapabilities request. 3. Client is considered as NOT supporting Capabilities if the following is TRUE: No Valid Device Response to GetServices request AND No Valid Device Response to GetCapabilities request. 6.3 GET SERVICES Test Label: Capabilities - Determine the available Services Test Case ID: CAPABILITIES-1 Profile S Normative Reference: Mandatory Profile G Normative Reference: Mandatory Profile C Normative Reference: Mandatory 33

34 Profile Q Normative Reference: Mandatory Profile A Normative Reference: Mandatory Profile T Normative Reference: Mandatory Feature Under Test: Capabilities Test Purpose: To verify that Device Capabilities is received using GetServices request. Pre-Requisite: The Network Trace Capture files contains at least one Conversation between Client and Device with GetServices command present. Test Procedure (expected to be reflected in network trace file): 1. Client invokes GetServices request message to retrieve all services of the Device. 2. Verify that GetServicesResponse message from the Device contains code HTTP 200 OK without SOAP Fault. Test Result: PASS - Client GetServices request messages are valid according to XML Schemas listed in Namespaces AND Client GetServices request in Test Procedure fulfills the following requirements: [S1] Client request contains "<GetServices>" tag after the "<Body>" tag AND [S2] Device response contains "HTTP/* 200 OK" AND [S3] Device response contains "<GetServicesResponse>" tag. FAIL - The Client failed PASS criteria. Validated Feature List: Capabilities.GetServicesRequest 6.4 GET CAPABILITIES Test Label: Capabilities - Get Device Capabilities Test Case ID: CAPABILITIES

35 Profile S Normative Reference: Mandatory Profile G Normative Reference: Optional Profile C Normative Reference: Optional Profile T Normative Reference: None Feature Under Test: Capabilities Test Purpose: To verify that Device Capabilities is received using GetCapabilities request. Pre-Requisite: The Network Trace Capture files contains at least one Conversation between Client and Device with GetCapabilities command present. Test Procedure (expected to be reflected in network trace file): 1. Client invokes GetCapabilities request message to retrieve Device Capabilities of the Device. 2. Verify that GetCapabilitiesResponse response message from the Device contains code HTTP 200 OK without SOAP Fault. Test Result: PASS - Client GetCapabilities request messages are valid according to XML Schemas listed in Namespaces AND Client GetCapabilities request in Test Procedure fulfills the following requirements: [S1] Client request contains "<GetCapabilities>" tag after the "<Body>" tag AND [S2] Device response contains "HTTP/* 200 OK" AND [S3] Device response contains "<GetCapabilitiesResponse>" tag. FAIL - The Client failed PASS criteria. Validated Feature List: Capabilities.GetCapabilities 35

36 7 Get Services Test Cases 7.1 Feature Level Requirement: Validated Feature: GetServices Profile A Requirement: Mandatory Profile C Requirement: Mandatory Profile G Requirement: Mandatory Profile Q Requirement: Mandatory Profile T Requirement: Mandatory 7.2 Expected Scenarios Under Test: 1. Client connects to Device to retrieve a services using GetServices commad. 2. Client is considered as supporting Get Services if the following conditions are met: Client supports Capabilities.GetServicesRequest feature. 3. Client is considered as NOT supporting Get Services if ANY of the following is TRUE: Client does not support Capabilities.GetServicesRequest feature. 36

37 8 Get Services with Capabilities Test Cases 8.1 Feature Level Requirement: Validated Feature: GetServices Profile A Requirement: Optional Profile C Requirement: Optional Profile G Requirement: Optional Profile Q Requirement: Optional 8.2 Expected Scenarios Under Test: 1. Client connects to Device to retrieve a service capabilities. 2. Client is considered as supporting Get Services with Capabilities if the following conditions are met: Client is able to retrieve a services capabilities using GetServices operation. 3. Client is considered as NOT supporting Get Services with Capabilities if ANY of the following is TRUE: No valid responses for GetServices request. 8.3 GET SERVICES Test Label: Get Services with Capabilities - Get Services Test Case ID: GETSERVICES-1 Profile A Normative Reference: Optional Profile C Normative Reference: Optional Profile G Normative Reference: Optional Profile Q Normative Reference: Optional Feature Under Test: Get Services Test Purpose: To verify that services capabilities provided by Device is received by Client using the GetServices operation. 37

38 Pre-Requisite: The Network Trace Capture files contains at least one Conversation between Client and Device with GetServices operation with tds:includecapability element equal to true present. The Device supportes GetServices command. Test Procedure (expected to be reflected in network trace file): 1. Client invokes GetServices request message with tds:includecapability element equal to true to retrieve redential service capabilities from the Device. 2. Device responds with code HTTP 200 OK and GetServicesResponse message. Test Result: PASS - Client GetServices request messages are valid according to XML Schemas listed in Namespaces AND Client GetServices request in Test Procedure fulfills the following requirements: [S1] soapenv:body element has child element tds:getservices AND [S2] It contains tds:includecapability element equal to true AND Device response on the GetServices request fulfills the following requirements: [S3] It has HTTP 200 response code AND [S4] soapenv:body element has child element tds:getservicesresponse. FAIL - The Client failed PASS criteria. Validated Feature List: GetServicesWithCapabilities.GetServicesWithCapabilitiesRequest 38

39 9 Event Handling Test Cases 9.1 Feature Level Requirement: Validated Feature: EventHandling Profile S Requirement: Conditional Profile G Requirement: Conditional Profile Q Requirement: Conditional Profile A Requirement: Mandatory Profile C Requirement: Mandatory Profile T Requirement: Mandatory 9.2 Expected Scenarios Under Test: 1. Client connects to Device to initiate Event Handling. 2. Client is considered as supporting Event Handling if the following conditions are met: Client is able to handle the Pull Point Event mechanism OR Client is able to handle the Base Notification Event mechanism OR Client is able to handle the Metadata Streaming. 3. Client is considered as NOT supporting Event Handling if the following is TRUE: All Pull Point attempts detected have failed AND All Base Notification attempts detected have failed AND All Metadata Streaming attempts detected have failed. 9.3 PULLPOINT Test Label: Event Handling - Pull Point Test Case ID: EVENTHANDLING-1 Profile S Normative Reference: Conditional 39

40 Profile G Normative Reference: Conditional Profile C Normative Reference: Governed by business rule #3 Profile Q Normative Reference: Conditional Profile A Normative Reference: Mandatory Profile T Normative Reference: Mandatory Feature Under Test: Event Handling Test Purpose: To verify that the Client is able to retrieve events using Pull Point. Pre-Requisite: The Network Trace Capture files contains at least one Conversation between Client and Device with Pull Point event type. Test Procedure (expected to be reflected in network trace file): 1. Client invokes CreatePullPointSubscription message. 2. Device responds with code HTTP 200 OK and CreatePullPointSubscriptionResponse message. 3. Client invokes PullMessages command with Timeout and MessageLimit elements. 4. Device responds with code HTTP 200 OK and PullMessagesResponse message. Test Result: PASS - Client CreatePullPointSubscription request messages are valid according to XML Schemas listed in Namespaces AND Client CreatePullPointSubscription request in Test Procedure fulfills the following requirements: [S1] Client request contains "<CreatePullPointSubscription>" tag after the "<Body>" tag AND [S2] Device response contains "HTTP/* 200 OK" AND [S3] Device response contains "<CreatePullPointSubscriptionResponse>" tag AND Client PullMessages request messages are valid according to XML Schemas listed in Namespaces AND 40