diff --git a/doc/Analytics.xml b/doc/Analytics.xml index eaef26c36..075fa0e16 100755 --- a/doc/Analytics.xml +++ b/doc/Analytics.xml @@ -4,19 +4,19 @@ Analytics Service Specification Analytics - 21.12 + 22.06 ONVIF™ www.onvif.org - December, 2021 + June, 2022 - 2008-2020 + 2008-2022 ONVIF™ All rights reserved. @@ -234,6 +234,15 @@ Added body temperature alarm rule. Clarifications for color. + + 22.06 + Jun-2022 + + Fredrik Svensson, Hans Busch, Sriram Bhetanabottla, Venki Aravapalli + + Move scene description to separate chapter and append section on JSON syntax. + Clarify color value range. Add missing Access Class for DeleteAnalyticsModule. Update license plate rule configuration. + @@ -254,6 +263,8 @@ <> ISO 3166-1:2013 Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes <> + JSON-LD 1.1 A JSON-based Serialization for Linked Data + <> Terms and Definitions @@ -488,7 +499,13 @@ This specification defines a configuration framework for the analytics engine called ONVIF Analytics Service. This framework enables a client to contact a device implementing the ONVIF Analytics Service for supported analytics modules and their configurations. Configurations of such modules can be dynamically added, removed or modified by a client, allowing a client to run multiple Analytics Modules in parallel if supported by the device. - The output from the Analytics Engine is called a Scene Description. The Scene Description represents the abstraction of the scene in terms of metadata for the objects, either static or dynamic, that are part of the scene. This specification defines an XML-based Scene Description Interface including data types. + The output from the Analytics Engine is called a Scene Description. + The Scene Description represents the abstraction of the scene in terms of metadata for the + objects, either static or dynamic, that are part of the scene. This specification defines an + XML-based Scene Description Interface including data types. For easy consumption by + non-traditional clients (e.g. cloud vendors) and to bridge gap between traditional + surveillance systems and IoT ecosystems metadata including scene description can be published + in JSON format over the MQTT protocol. Rules describe how the scene description is interpreted and how to react on that information. The specification defines standard rule syntax and methods to communicate configuration of these rules from the application to the device. A device supporting ONVIF Analytics Service shall implement the Scene Description Interface and allow events to be dispatched using the Event Service. If the device additionally supports a rule engine then it shall implement the Rules Analytics Modules Interface. Event and action engine interfaces and configuration is out of scope of this specification. The event interface is handled through the Event Service as described in the ONVIF Core specification. @@ -500,25 +517,12 @@ Radiometry types, modules and rules are defined in the RADIOMETRY Schema file http://www.onvif.org/ver20/analytics/radiometry.xsd. - Service - This section covers the following main areas of this architecture: - - - Analytics Module interface - - - Scene description - - - Rules interface - - - The analytics service allows fine-grained configuration of individual rules and individual analytics modules (see and ). introduces the XML-based scene description, which can be streamed as metadata to clients via RTP as defined in the ONVIF Streaming Specification. -
- Scene Description Interface + Scene Description
Overview - This specification defines the XML schema that shall be used to encode Scene Descriptions by a device. The scope of the Scene Description covers basic Scene Elements which can be displayed in a video overlay to the end-user as well as a framework for vendor-specific extensions. Annex A shows additional Scene Elements that may be used for processing vendor-specific rules. + This chapter defines the XML-based scene description, which can be streamed as metadata to clients via RTP as defined in the ONVIF Streaming Specification. + The scope of the Scene Description covers basic Scene Elements which can be displayed in a video overlay to the end-user as well as a framework for vendor-specific extensions. + Section defines an alternate JSON based representation.
Frame Related Content @@ -835,7 +839,7 @@
Color descriptor The optional color descriptor allows to describe the representative colors of the - detected object or region. Each color is represented as vectors based on a color space. + detected object or region. Each color is represented as a three-dimensional vector based on a color space. Its weight denotes the fraction of pixels assigned to the representative color in the range [0 .. 1]. Color covariance describes the variation of color values around the representative color value in color space thus representative color denotes a region in @@ -946,6 +950,41 @@ + lists the acceptable value ranges for prominent color + spaces. + + Colorspace value ranges + + + + + + Colorspace + + Range + + + + + + + YCbCr + + + Y [16 to 235] and Cb/Cr[16 to 240] + + + + + RGB + + + For all component values [0...255] + + + + +
Object Class descriptor @@ -2169,7 +2208,484 @@
+
+ JSON over MQTT +
+ Metadata publish sequence + MQTT is a pub/sub messaging protocol centered around topics. + Consumers can subscribe to topics published by producers to get + continuous updates on the data content. ONVIF metadata, like video + analytics scene descriptions, can be published to an MQTT broker and + subscribed to by a consumer. + This is sequence of operations to set up the metadata flow: + + An ONVIF client calls AddEventBroker in the device's Event + service to set up: + + Address and credentials to the MQTT broker to use + + + + A unique TopicPrefix for the device + + + + A MetadataFilter listing topics to which the device + shall publish + + + + + + The producer (ONVIF device) connects to the MQTT broker and starts publishing + data on the selected topics. + + + + The consumer connects to the MQTT broker, specifying which topics + that it wants to subscribe to. A consumer can be any MQTT capable + client, for example, an event engine like Node-RED, IoT cloud + platforms, VSaaS platforms, etc. Multiple comsumers using + different topics are possible. + + + + The consumer receives updates on subscribed topics and can + implement actions like statistics aggregation and complex + analytics rules with data from multiple sources. + + + + The following sections describe how topics and payload shall be + structured by an ONVIF metadata producer when published to an MQTT + broker. +
+
+ MQTT topic structure + + This section describes how an MQTT topic is structured based on + metadata type and source expressed as ABNF rules according to RFC + 5234. + + Topic = TopicPrefix "/" PayloadPrefix "/" MetadataType "/" MetadataProducer + Note that special characters like, ‘/’, ‘#’ and ‘+’ shall be omitted from the topic. + with + + TopicPrefix - uniquely identifies the producer and is + configurable through the AddEventBroker command in the Event + service. It shall not be empty. + + + + PayloadPrefix - signals in what format the data is + published. See below for + possible values. + + + + MetadataType - signals what type of metadata it is. See + below for possible + values. + + + + MetadataProducer - specifies additional source information for the metadata. The + format depends on the metadata type. See below + for definition. + + + + + PayloadPrefix types + + + + + Prefix + + Description + + + + + + "onvif-mj" + + ONVIF metadata with JSON payload + + + +
+ + + MetadataType categories with corresponding MetadataProducer + + + + + MetadataType + + MetadataProducer (template in ABNF) + + Description + + + + + + "VideoAnalytics" + + ProfileToken "/" + AnalyticsModuleName + + ONVIF metadata from a VideoAnalytics module + active via VideoAnalyticsConfiguration included in Profile + configuration + + + + "AudioAnalytics" + + ProfileToken "/" + AnalyticsModuleName + + ONVIF metadata from an AudioAnalytics module + active via AudioAnalyticsConfiguration included in Profile + configuration + + + + "PTZ" + + ProfileToken "/" PTZConfigurationToken + + ONVIF metadata from a PTZ node included in + Profile configuration + + + +
+ + with + + ProfileToken = The media profile token + + + + AnalyticsModuleName = The name of the analytics + module + + + + PTZConfigurationToken = The PTZ configuration token + + +
+ +
+ JSON payload format + + Instead of creating a full fledged schema for XML to JSON + conversion, provides a set of generic rules that devices + shall need to implement to express ONVIF metadata in JSON + format. + + + ONVIF Metadata XML to JSON conversion + + + + + ONVIF XML Element + + ONVIF JSON + Representation + + Description + + + + + + <xmltag/> + + “xmltag”: null + + Null tag + + + + <xmltag>text</xmltag> + + “xmltag”: "text" + + Simple tag with value + + + + < xmltag name="value" /> + + “xmltag”:{"@name": "value"} + + Tag with attribute + + + + <xmltag name="value">text</ + xmltag> + + “xmltag”: { "@name": "value", "#text": "text" + } + + Tag with attribute and value + + + + <xmltag> <tag1>text</tag1> + <tag2>text</tag2> </xmltag + + “xmltag”: { "tag1": "text", "tag2": "text" + } + + Tag with multiple child tags + + + + <xmltag> <tag1>text</tag1> + <tag1>text</tag1> </ xmltag> + + “xmltag”: { "tag1": ["text", "text"] + } + + Tag with multiple child tags of same type + (similar to minOccurs > 1) + + + +
+ + All extension elements and attributes shall be included within + the same parent JSON object. + + Namespace prefixes for ONVIF defined namespaces shall be + dropped, i.e. elements and attributes that belong to the following + namespaces: + + + + http://www.onvif.org/ver10/schema + + + + http://www.onvif.org/ver20/analytics/humanface + + + + http://www.onvif.org/ver20/analytics/humanbody + + + + http://www.onvif.org/ver20/analytics/radiometry + + + + XML elements and attributes that belong to a different namespace + shall have their names prepended with their corresponding namespace + prefix joined by a ':' as shown in the example while defining + the namespace in the "context" object as per JSON-LD specification.. See specifically the acme:ColorName + exampe. +
+ +
+ Example + + Sample metadata frame in XML format: + + <?xml version="1.0" encoding="UTF-8"?> +<tt:MetadataStream xmlns:tt="http://www.onvif.org/ver10/schema" +xmlns:fc="http://www.onvif.org/ver20/analytics/humanface" +xmlns:bd="http://www.onvif.org/ver20/analytics/humanbody" +xmlns:acme="http://www.acme.com/schema"> + <tt:VideoAnalytics> + <tt:Frame UtcTime="2021-10-05T15:13:27.321" Source="MyClassifier"> + <tt:Transformation> + <tt:Translate x="-1.0" y="-1.0"/> + <tt:Scale x="0.003125" y="0.00416667"/> + </tt:Transformation> + <tt:Object ObjectId="15"> + <tt:Appearance> + <tt:Shape> + <tt:BoundingBox left="20.0" top="80.0" right="100.0" bottom="30.0"/> + <tt:CenterOfGravity x="60.0" y="50.0"/> + <tt:Polygon> + <tt:Point x="20.0" y="30.0"/> + <tt:Point x="100.0" y="30.0"/> + <tt:Point x="100.0" y="80.0"/> + <tt:Point x="20.0" y="80.0"/> + </tt:Polygon> + </tt:Shape> + <tt:Color> + <tt:ColorCluster> + <tt:Color X="213" Y="135" Z="126" /> + <tt:Weight>0.9</tt:Weight> + <acme:ColorName>White</acme:ColorName> + </tt:ColorCluster> + <tt:ColorCluster> + <tt:Color X="102" Y="176" Z="119" /> + <tt:Weight>0.5</tt:Weight> + <acme:ColorName>Blue</acme:ColorName> + </tt:ColorCluster> + </tt:Color> + <tt:Class> + <tt:Type Likelihood="0.8">Human</tt:Type> + </tt:Class> + <tt:HumanFace> + <fc:Gender>Male</fc:Gender> + <fc:Age> + <tt:Min>20</tt:Min> + <tt:Max>30</tt:Max> + </fc:Age> + <fc:Accessory> + <fc:Opticals> + <fc:Wear>True</fc:Wear> + </fc:Opticals> + <fc:Hat> + <fc:Wear>True</fc:Wear> + </fc:Hat> + </fc:Accessory> + </tt:HumanFace> + <tt:HumanBody> + <bd:Clothing> + <bd:Tops> + <bd:Category>LongSleeve</bd:Category> + </bd:Tops> + <bd:Bottoms> + <bd:Category>Shorts</bd:Category> + </bd:Bottoms> + </bd:Clothing> + <bd:Belonging> + <bd:Bag> + <bd:Category>Backpack</bd:Category> + </bd:Bag> + </bd:Belonging> + </tt:HumanBody> + </tt:Appearance> + </tt:Object> + </tt:Frame> + </tt:VideoAnalytics> +</tt:MetadataStream> + + This data will be published under this topic: + + MyDevice/onvif-mj/VideoAnalytics/1/MyClassifier + + Where "MyDevice" is the given TopicPrefix and "1" is the + profile token. Shown below is how the sample metadata + frame is formatted in JSON: + + { + "Frame": [{ + "@UtcTime": "2021-10-05T15:13:27.321", + "@Source": "MyClassifier", + "@context": { + "acme": "http://www.acme.com/schema" + }, + "Transformation": { + "Translate": { + "@x": "-1.0", "@y": "-1.0" + }, + "Scale": { + "@x": "0.003125", "@y": "0.00416667" + } + }, + "Object": [{ + "@ObjectId": "15", + "Appearance": { + "Shape": { + "BoundingBox": { + "@left": "20.0", "@top": "20.0", "@right": "100.0", "@bottom": "30.0" + }, + "CenterOfGravity": { + "@x": "60.0", "@y": "50.0" + }, + "Polygon": [{ + "@x": "20.0", "@y": "30.0" + }, { + "@x": "100.0", "@y": "30.0" + }, { + "@x": "100.0", "@y": "80.0" + }, { + "@x": "20.0", "@y": "80.0" + }] + }, + "Color": { + "ColorCluster": [{ + "Color": { + "@X": "213", "@Y": "135", "@Z": "126" + }, + "Weight": 0.9, + "acme:ColorName": "White" + }, { + "Color": { + "@X": "102", "@Y": "176", "@Z": "119" + }, + "Weight": 0.5, + "acme:ColorName": "Blue" + }] + }, + "Class": { + "@Likelihood": "0.8", + "#text": "Human" + }, + "HumanFace": { + "Gender:": "Male", + "Age": { + "@Min": "20", "@Max": "30" + }, + "Accessory": { + "Opticals": { + "Wear": "true" + }, + "Hat": { + "Wear": "true" + } + } + }, + "HumanBody": { + "Clothing": { + "Tops": { + "Category": "LongSleeve" + }, + "Bottoms": { + "Category": "Shorts" + } + }, + "Belonging": { + "Bag": { + "Category": "Backpack" + } + } + } + } + }] + }] +} +
+ + + Service + This section covers the following main areas of this architecture: + + + Analytics Module interface + + + Rules interface + + + The analytics service allows fine-grained configuration of individual rules and individual analytics modules (see and ).
Configuration description language This specification introduces a description language which is used to configure rules and analytics modules. Beside configuration parameters the config description additionally contains an event description according to the OASIS topic notification. @@ -2402,7 +2918,7 @@
Example - This examples explains the options for an analytics module called myModule in namesapce nn with four simple parameters: + This examples explains the options for an analytics module called myModule in namespace nn with four simple parameters: @@ -2968,6 +3484,12 @@ The device cannot delete the modules without creating a conflicting configuration. + + access class + + ACTUATE + +
@@ -3050,8 +3572,8 @@
-
- Capabilities +
+ GetServiceCapabilities The capabilities reflect optional functions and functionality of a service. The information is static and does not change during device operation. The following capabilites are available: @@ -6233,6 +6755,17 @@ Optional + + + + Threshold + + + The level of confidence required for the detection/recognition. + + + Optional + @@ -6420,6 +6953,12 @@ + + + + + + @@ -6498,6 +7037,61 @@ Optional + + + + Country + + + Specifies the country for which LPR should be processed. + + + Optional + + + + + Sensitivity + + + Detection sensitivity which provides compromise between detection rate and false alarms.Higher the sensitivity, more License plates are detected at the cost of increasing false alarms number. + + + Optional + + + + + PlateMinWidth + + + Minimum width of the license plate in percentage to be detected/recognized with respect to Scene Image. + + + Optional + + + + + PlateMaxWidth + + + Maximum width of the license plate in percentage to be detected/recognized with respect to Scene Image. + + + Optional + + + + + EventInterval + + + Minimum interval between event notification when same license plate is recognized. + + + Optional + diff --git a/doc/AppMgmt.xml b/doc/AppMgmt.xml index 82b52052b..5fe398848 100644 --- a/doc/AppMgmt.xml +++ b/doc/AppMgmt.xml @@ -4,19 +4,19 @@ Application Management Service Specification App Mgmt - 21.12 + 22.06 ONVIF™ www.onvif.org - December, 2021 + June, 2022 - 2008-2021 + 2008-2022 ONVIF™ All rights reserved. @@ -64,6 +64,14 @@ Fix inconsistencies between appmgmt schema and doc. + + 22.06 + Jun-2022 + + Sujith Raman + + Correct namespace of event State member. + @@ -584,7 +592,7 @@ - + ]]> diff --git a/doc/Core.xml b/doc/Core.xml index 0853733c0..f8bf74431 100644 --- a/doc/Core.xml +++ b/doc/Core.xml @@ -4,19 +4,19 @@ ONVIF Core Specification ONVIF Core Spec - 21.12 + 22.06 ONVIF™ www.onvif.org - December, 2021 + June, 2022 - 2008-2020 + 2008-2022 ONVIF™ All rights reserved. @@ -263,6 +263,14 @@ Add security policy configuration APIs. + + 22.06 + Jun-2022 + + Fredrik Svensson, Michael Adam, Sergey Bogdanov, Sriram Bhetanabottla + + Restructure MQTT topic and payload sections. Include metadata filter. Add Addon capability. Rename sections to show real name of service command. + @@ -1102,9 +1110,9 @@ 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 - Device functionality can be grouped to so called profiles. The profiles themselves are defined in separate specifications. - For each profile a number of services and functions are mandatory which are defined in the respective specifications. + Profiles and Addons + Device functionality can be grouped to so called profiles and addons. Profiles and addons themselves are defined in separate specifications. Addons complement profiles, and you must declare support for one or more profiles to use an addon. + For each profile or addon, a number of services and functions are mandatory which are defined in the respective specifications.
Device management @@ -1214,6 +1222,9 @@ Get and set device discovery parameters. + + Get supported addons. +
@@ -2820,7 +2831,7 @@ onvif://www.onvif.org/name/ARV-453 - + System @@ -2948,6 +2959,14 @@ onvif://www.onvif.org/name/ARV-453 UserConfigNotSupported Indicates no support for user configuration. + + + Addons + + + Indicates support for ONVIF Addons. Strings for each specific addon can be found in its respective specification document. + + Security @@ -5289,7 +5308,7 @@ onvif://www.onvif.org/name/ARV-453
- Set users settings + 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. 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. @@ -5887,7 +5906,7 @@ onvif://www.onvif.org/name/ARV-453
- Auxiliary operation + 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 capabilites 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. @@ -7004,7 +7023,7 @@ Event description:
- Synchronization Point + 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: @@ -7220,6 +7239,10 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet MaxEventBrokers Maxiumum number of event broker configurations that can be added to the device. + + + MetadataOverMQTT + Indicates that metadata streaming over MQTT is supported. @@ -7468,10 +7491,8 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet - - + + @@ -7487,10 +7508,8 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet - - + + @@ -7599,8 +7618,16 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet PublishFilter - Concrete Topic Expression to select specific topics to publish, see section . + 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//." . + QoS @@ -7721,14 +7748,48 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
Topic Structure - Topics are published according to the following structure: - <TopicPrefix>/<PayloadPrefix>/<LocalTopic>[/&<Source>[/<Key>]] - ONVIF topics are are only locally unique within the device so they must be prefixed with a TopicPrefix to become globally unique. The TopicPrefix is configurable through the AddEventBroker command. The TopicPrefix shall not be empty. The PayloadPrefix signals what kind of data that is published. The following prefixes are defined. - + Topics are published according to the following structure, expressed as ABNF rules + according to RFC 5234. Note that special characters like, '#' and '+' shall be omitted + from the topic. For an example, see section . + Topic = TopicPrefix "/" PayloadPrefix "/" LocalTopic [ "&" Source ] + Source = *("/" SVALUE) + with + + TopicPrefix - uniquely identifies the producer and is configurable through the + AddEventBroker command in the Event service. It shall not be empty. + + + PayloadPrefix - signals in what format the data is published. See below for + possible values. + + + LocalTopic is the same as the ONVIF topic, but because MQTT does not support + namespaces, the namespace prefix for ONVIF topics shall be dropped, so that for + example, "tns1:Device/HardwareFailure/StorageFailure" becomes + "Device/HardwareFailure/StorageFailure". This means that the default topic namespace + is ONVIF, i.e. "http://www.onvif.org/ver10/topics". If an event uses another topic + namespace this should be signalled using the syntax: + "tns:{namespace-alias}/<topic>". Vendor specific extensions should choose a + suitable namespace alias to avoid name clashes. As an example, consider the ONVIF + topic "tns1:Device/HardwareFailure/acme:LensFailure" where + tns1="http://www.onvif.org/ver10/topics" and acme="http://www.acme.com/topics". This + should be translated to the MQTT topic + "Device/HardwareFailure/tns:acme/LensFailure". + + + SVALUE being the value of the Value attribute of a SimpleItem in the Source part + of the message. All SimpleItem values shall be listed in the SOURCE sequentially in + the same order as they are listed in the response to GetEventProperties. These + values are added to the topic to make it unique so that it can be cached by the + broker individually. See for an example. + + +
Prefix definitions - - + + @@ -7751,23 +7812,21 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
- The LocalTopic is the same as the ONVIF topic, but because MQTT does not support namespaces, the namespace prefix for ONVIF topics shall be dropped, so that for example, “tns1:Device/HardwareFailure/StorageFailure” becomes “Device/HardwareFailure/StorageFailure”. This means that the default topic namespace is ONVIF, i.e. “​http://www.onvif.org/ver10/topics”. If an event uses another topic namespace this should be signalled using the syntax: "tns:{namespace-alias}/<topic>". Vendor specific extensions should choose a suitable namespace alias to avoid name clashes. As an example, consider the ONVIF topic "tns1:Device/HardwareFailure/acme:LensFailure" where tns1="​http://www.onvif.org/ver10/topics" and acme="​http://www.acme.com/topics". This should be translated to the MQTT topic "Device/HardwareFailure/tns:acme/LensFailure". - The Source and Key are taken from the payload, preceded by a '&' character. For property events, they are added to the topic to make it unique so that they can be cached by the broker individually. For each SimpleItem name/value pair in the Source/Key a ‘/’ character plus the value shall be appended to the topic. The values shall be added in the same order as they are listed in the response to GetEventProperties. Note that special characters like, ‘/’, ‘#’ and ‘+’ shall be omitted from the topic. For an example, see section .
JSON Event Payload This section describes how an ONVIF event is mapped to the JSON data format when published using the "onvif-ej" payload definition. Mapping definition from XML to JSON according to RFC 5234: - MESSAGE ::= "{" TIMEINFO "," SOURCE ["," DATA ] "}" - TIMEINFO ::= DQUOTE "UtcTime" DQUOTE ":" TIMESTAMP - SOURCE ::= DQUOTE "Source" DQUOTE ":" "{" *(ITEM) "}" - DATA ::= DQUOTE "Data" DQUOTE ":" "{" *(ITEM) "}" - ITEM ::= SIMPLEITEM / ELEMENTITEM - SIMPLEITEM ::= DQUOTE SNAME DQUOTE ":" DQUOTE SVALUE DQUOTE - ELEMENTITEM ::= DQUOTE ENAME DQUOTE ": {" [ TYPE *("," TYPE)] "}" - TYPE ::= ATTRIBUTE / SIMPLETYPE / COMPLEXTYPE - ATTRIBUTE ::= DQUOTE ANAME DQUOTE ": " DQUOTE AVALUE DQUOTE - SIMPLETYPE ::= DQUOTE NAME DQUOTE ": " DQUOTE VALUE DQUOTE - COMPLEXTYPE ::= DQUOTE NAME DQUOTE ": {" [TYPE *("," TYPE)] "}" + MESSAGE = "{" TIMEINFO "," SOURCE ["," DATA ] "}" + TIMEINFO = DQUOTE "UtcTime" DQUOTE ":" TIMESTAMP + SOURCE = DQUOTE "Source" DQUOTE ":" "{" *(ITEM) "}" + DATA = DQUOTE "Data" DQUOTE ":" "{" *(ITEM) "}" + ITEM = SIMPLEITEM / ELEMENTITEM + SIMPLEITEM = DQUOTE SNAME DQUOTE ":" DQUOTE SVALUE DQUOTE + ELEMENTITEM = DQUOTE ENAME DQUOTE ": {" [ TYPE *("," TYPE)] "}" + TYPE = ATTRIBUTE / SIMPLETYPE / COMPLEXTYPE + ATTRIBUTE = DQUOTE ANAME DQUOTE ": " DQUOTE AVALUE DQUOTE + SIMPLETYPE = DQUOTE NAME DQUOTE ": " DQUOTE VALUE DQUOTE + COMPLEXTYPE = DQUOTE NAME DQUOTE ": {" [TYPE *("," TYPE)] "}" with @@ -7802,36 +7861,36 @@ 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 corresponding MQTT topics and JSON payload: - Topic: - MyDevice/onvif-ej/RuleEngine/LineDetector/Crossed/&1/2/MyImportantFence1 -Payload: -{ + 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: + MyDevice/onvif-ej/RuleEngine/LineDetector/Crossed&/1/2/MyImportantFence1 + Payload for the first message: + { "UtcTime": "2008-10-10T12:24:57.321Z", "Source": { "VideoSource": "1", "AnalyticsConfiguration": "2", "Rule": "MyImportantFence1" - }, + }, "Data": { "ObjectId": "15" } -} - -Topic: - MyDevice/onvif-ej/RuleEngine/LineDetector/Crossed/&1/2/MyImportantFence2Payload: -Payload: -{ +} + Topic for the second message: + MyDevice/onvif-ej/RuleEngine/LineDetector/Crossed&/1/2/MyImportantFence2 "UtcTime": "2008-10-10T12:24:57.789Z "Source": { "VideoSource": "1", + "AnalyticsConfiguration": "2", "Rule": "MyImportantFence2" - }, + }, "Data": { "ObjectId": "19" } -} - +}
diff --git a/doc/DeviceIo.xml b/doc/DeviceIo.xml index ef3177ce7..2a7b7bbbf 100644 --- a/doc/DeviceIo.xml +++ b/doc/DeviceIo.xml @@ -4,19 +4,19 @@ Device IO Service Specification Device-IO - 19.06 + 22.06 ONVIF™ www.onvif.org - June, 2019 + June, 2022 - 2008-2020 + 2008-2022 ONVIF™ All rights reserved. @@ -147,6 +147,14 @@ Change Request 2065 Change Request 2454 + + 22.06 + Jun-2022 + + Sergey Bogdanov + + Rename sections to show real name of service command. + @@ -967,7 +975,7 @@ Change Request 2065
- Send ReceiveSerialCommand + SendReceiveSerialCommand This section describes operations to transmit/receive generic controlling data to/from a serial device that is connected to the serial port of the device. This operation can be used for the following purposes. @@ -1041,7 +1049,7 @@ Change Request 2065
- Capabilities + GetServiceCapabilities The capabilities reflect optional functions and functionality of a service. The information is static and does not change during device operation. diff --git a/doc/ExportFileFormat.xml b/doc/ExportFileFormat.xml index 803093fc3..ba049ea6f 100644 --- a/doc/ExportFileFormat.xml +++ b/doc/ExportFileFormat.xml @@ -4,19 +4,19 @@ Export File Format Specification ExportFileFormat - 21.12 + 22.06 ONVIF™ www.onvif.org - December, 2021 + June, 2022 - 2013-2021 + 2013-2022 ONVIF™ All rights reserved. @@ -102,6 +102,14 @@ Add timed metadata. + + 22.06 + Jun-2022 + + Hans Busch + + Add location information. + @@ -124,6 +132,8 @@ <> ISO/IEC 14888-2 Information technology – Security techniques – Digital signatures with appendix – Part 2: Integer factorization based mechanisms <> + ETSI TS 126 244 3GPP file format + <> PKCS#1, v2.1 RSA Cryptographic Standard NIST FIPS 186 Digital Signature Standard (DSS) <> @@ -178,6 +188,30 @@ The ISO Base File Format has been mainly designed for storing movies and music clips. It defines a media timeline relative to the beginning which is defined as time zero. For Video Surveillance purposes it is important that the file preserves the absolute time of the captured frames. This specification refers to ISO 23000-10 for storing the absolute start time. All other times can be derived using the relative time data defined in ISO/IEC 14496-12. Additional to this time information time corrections can be stored during the sealing process. In order to improve random access the ISOM baseline requires the movie fragment table at the end of the file. This redundant information does not require the protection seal.
+
+ Location + Three mechanism for storing location information are defined for MP4 files by the mobile + industry. + This specification refers to the ETSI standard which has defined means for textual and + spherical representation using the so called 'loci' box. + Beside the ETSI standard two defacto standards exist for Android and iOS based mobile + phones: + + + Android phones use the '©xyz' box holding an alphanumeric string with lon and lat + degrees. + + Mobile phones based on iOS store similar information in sub atoms of the meta box. + Note that this meta box is incompatible with the ISO Base File Format + specification. + + + The location information is designated to provide a best effort for the video location + in order to be able to geo-locate the video. For fixed cameras the location should + approximate to the intersection of the camera axis with the ground location. For moving + cameras such an appoach may not be feasible and a fallback to the camera location may be + more suitable. +
Sealing All data that a user wishes to carry away separately are put into a metaphorical bag. The bag is then sealed to enable tamper detection. Anyone wanting to use the data from the bag first examines the seal. The data in the bag are identical with the original data as long as the seal is intact. Here, the metaphorical bag is represented by a file and the seal is represented by a signature over all data in the file. @@ -348,6 +382,52 @@ class CorrectStartTimeBox extends Box (‘cstb’) {
+
+ Location information + When available, the location of the camera view shall be provided as 'loci' box + according to ETSI TS 126 244. See below informal repetition of the definition. + + Location Box + + Box Types: 'loci' +Container: User Data Box (‘udta’) +Mandatory: No +Quantity: Zero or one + + Syntax + + + All characters of string based fields shall be encoded as UTF-8. The following semantics apply: + + + Role + Shall be '1' - real location + + + Name + Human readable street address of the location, optionally including building internal addressing. + + + Longitude and Latitude + 16.16 bit fixed point angle in degree. + + + Altitude + Height of the location in meter. + + +
Timed metadata ONVIF metadata supports transport of frame related scene description, events and PTZ @@ -655,6 +735,8 @@ class AdditionalUserInformationBox stts1 Sample index by time stsc1 Sample to chunk mapping stco1 List of Chunk offsets inside 'mdat' relative to file begin + udta1 User data + loci4 Geo location information trak1 Third track with timed metadata tkhd1 Track header with creation time, timescale, duration, track ID mdia1 @@ -708,6 +790,8 @@ class AdditionalUserInformationBox 2 ISO/IEC 23000-10 3 This specification + + 4 ETSI TS 126 244 Revision History diff --git a/doc/Imaging.xml b/doc/Imaging.xml index bbd7133c6..8f8d6f97a 100644 --- a/doc/Imaging.xml +++ b/doc/Imaging.xml @@ -4,19 +4,19 @@ Imaging Service Specification Imaging - 19.06 + 22.06 ONVIF™ www.onvif.org - June, 2019 + June, 2022 - 2008-2020 + 2008-2022 ONVIF™ All rights reserved. @@ -126,6 +126,14 @@ Change Request 1843 Added Focus Modes Change Request 2384, 2431, 2477, 2478 + + 22.06 + June-2022 + + Fredrik Svensson + + Change the "role" attribute for request access class. + @@ -569,9 +577,13 @@ Change Request 2384, 2431, 2477, 2478 The requested video source does not support imaging settings. + + access class + + READ_MEDIA + + - Access Class: - READ_MEDIA If the video source supports any of the imaging settings as defined by the ImagingSettings type in the [ONVIF Schema], then it should be possible to retrieve the imaging settings from the device through the GetImagingSettings command.
@@ -644,9 +656,13 @@ Change Request 2384, 2431, 2477, 2478 The requested VideoSource does not support imaging settings. + + access class + + READ_MEDIA + + - Access Class: - READ_MEDIA
diff --git a/doc/RecordingSearch.xml b/doc/RecordingSearch.xml index afd5d21e7..e6840df9a 100644 --- a/doc/RecordingSearch.xml +++ b/doc/RecordingSearch.xml @@ -4,12 +4,12 @@ Recording Search Specification RecordingSearch - 21.12 + 22.06 ONVIF™ www.onvif.org - December, 2021 + June, 2022 @@ -149,6 +149,14 @@ Change Request 1843, 2050, 2053, 2055, 2065 Change the "role" attribute for request access class. + + 22.06 + June-2022 + + Fredrik Svensson + + Change the "role" attribute for request access class. + @@ -1337,13 +1345,13 @@ http://www.onvif.org/ver10/tptz/ZoomSpaces/PositionGenericSpace The search token is invalid. + + access class + + READ_MEDIA + + - ACCES CLASS: - - - READ_MEDIA - -
GetServiceCapabilities diff --git a/doc/Security.xml b/doc/Security.xml index c3308851c..3a187a1ff 100644 --- a/doc/Security.xml +++ b/doc/Security.xml @@ -4,19 +4,19 @@ Advanced Security Service Specification Security Configuration - 21.12 + 22.06 ONVIF™ www.onvif.org - December 2021 + June 2022 - 2008-2020 + 2008-2022 ONVIF™ All rights reserved. @@ -119,6 +119,14 @@ Added certificate-based client authentication Fix typo in commands names. Fix inconsistency in Security NoMatchingPrivateKey + + 22.06 + June-2022 + + Hans Busch + + Fix fault namespace prefix and remove requirement to accept missing MAC when passphrase is present. + @@ -1652,19 +1660,19 @@ Added certificate-based client authentication faults - ter:Receiver - tas:Action - ter:MaximumNumberOfCertificatesReached + ter:Receiver - ter:Action - ter:MaximumNumberOfCertificatesReached The device does not have enough storage space to store the certificate to be uploaded. - ter:Receiver - tas:Action - ter:MaximumNumberOfKeysReached + ter:Receiver - ter:Action - ter:MaximumNumberOfKeysReached The device does not have enough storage space to store the key pair to be uploaded. - ter:Receiver - tas:Action - ter:NoMatchingPrivateKey + ter:Receiver - ter:Action - ter:NoMatchingPrivateKey The keystore does not contain a key pair with a private key that matches the public key in the uploaded certificate. - ter:Sender - tas:InvalidArgVal - ter:BadCertificate + ter:Sender - ter:InvalidArgVal - ter:BadCertificate The supplied certificate file cannot be processed by the device. - ter:Sender - tas:InvalidArgVal - ter:UnsupportedPublicKeyAlgorithm + ter:Sender - ter:InvalidArgVal - ter:UnsupportedPublicKeyAlgorithm The public key algorithm of the public key in the certificate is not supported by the device. - ter:Sender - tas:InvalidArgVal - ter:UnsupportedSignatureAlgorithm + ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm The specified signature algorithm is not supported by the device. - ter:Sender - tas:InvalidArgVal - ter:InvalidKeyStatus + ter:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus The key with the requested KeyID has an inappropriate status. @@ -1693,7 +1701,7 @@ Added certificate-based client authentication If an integrity passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to check the integrity of the supplied PKCS#12 PFX. If an integrity passphrase ID is supplied, but the supplied PKCS#12 PFX has no integrity protection, the device shall produce a BadPKCS12File fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. If an encryption passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. If an EncryptionPassphraseID is supplied, but a CertBag is not encrypted, the device shall ignore the supplied EncryptionPassphraseID when processing this CertBag. If an EncryptionPassphraseID is supplied, but a KeyBag is provided instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied EncryptionPassphraseID when processing the KeyBag. - If a passphrase is supplied, the device shall ignore an eventually supplied integrity passphrase ID and an eventually supplied encryption passphrase ID, and the device shall use the supplied passphrase to check the integrity of the PKCS#12 PFX and to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. If a passphrase is supplied, but the supplied PKCS#12 PFX has no integrity protection, the device shall not check the integrity of the PKCS#12 PFX. If a passphrase is supplied, but a CertBag is not encrypted, the device shall ignore the supplied passphrase when processing this CertBag. If a passphrase is supplied, but a KeyBag is supplied instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied passphrase when processing the KeyBag. + If a passphrase is supplied, the device shall ignore an eventually supplied integrity passphrase ID and an eventually supplied encryption passphrase ID, and the device shall use the supplied passphrase to check the integrity of the PKCS#12 PFX and to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. If a passphrase is supplied, but a CertBag is not encrypted, the device shall ignore the supplied passphrase when processing this CertBag. If a passphrase is supplied, but a KeyBag is supplied instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied passphrase when processing the KeyBag. If decryption of either the PKCS8ShroudedKeyBag or an encrypted CertBag failed, the device shall produce a DecryptionFailed fault and shall not store the uploaded certificates nor key pair in the keystore. If the signature algorithm of a supplied certificate is not supported by the device, the device shall produce an UnsupportedSignatureAlgorithm fault and shall not upload a certificate nor key pair. If the supplied key pair cannot be processed by the device, the device shall produce an UnsupportedPublicKeyAlgorithm fault and shall not store the uploaded key pair nor the uploaded certificates in the keystore. @@ -2609,7 +2617,7 @@ Added certificate-based client authentication
- Set Common Name Maps to User + SetCnMapsToUser This operation enables or disables mapping of the Common Name present in the TLS client certificate to an existing user name in the device. The TLS server on the device shall perform mapping if parameter clientAuthenticationRequired is set to true. @@ -2640,7 +2648,7 @@ Added certificate-based client authentication
- Get Common Name Mapping to User + GetCnMapsToUser This operation returns whether the Common Name Mapping to User is enabled. diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 310f1c227..867dd4218 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -4,19 +4,19 @@ Streaming Specification Streaming - 21.12 + 22.06 ONVIF™ www.onvif.org - December, 2021 + June, 2022 - 2008-2021 + 2008-2022 ONVIF™ All rights reserved. @@ -193,6 +193,14 @@ Remove obsolete exi default compression. + + 22.06 + June-2022 + + Hans Busch + + Fix empty links. + @@ -205,60 +213,60 @@ ISO/IEC 14496-3:2005, Information technology -- Coding of audio-visual objects -- Part 3: Audio ISO/IEC 14496-10:2008, Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding ISO/IEC 23008-2:2015, Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding - ITU-T G.711, Pulse code modulation (PCM) of voice frequencies < http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.711-198811-I!!PDF-E&type=items> + ITU-T G.711, Pulse code modulation (PCM) of voice frequencies <> ITU-T G.726, 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) - <http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.726-199012-I!!PDF-E&type=items> + <> RSA Laboratories, PKCS #10 v1.7: Certification Request Syntax Standard, RSA Laboratories - <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf> + <> IETF RFC 2246, The TLS Protocol Version 1.0 - <http://www.ietf.org/rfc/rfc2246.txt> + <> IETF RFC 2326, Real Time Streaming Protocol (RTSP) - <http://www.ietf.org/rfc/rfc2326.txt> + <> IETF RFC 2396, Uniform Resource Identifiers (URI): General Syntax - <http://www.ietf.org/rfc/rfc2396.txt> + <> IETF RFC 2435, RFC2435 - RTP Payload Format for JPEG-compressed Video - <http://www.ietf.org/rfc/rfc2435.txt> + <> IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications - <http://www.ietf.org/rfc/rfc3550.txt> + <> IETF RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control - <http://www.ietf.org/rfc/rfc3551.txt> + <> IETF RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams - <http://www.ietf.org/rfc/rfc3640.txt> + <> IETF RFC 3984, RTP Payload Format for H.264 Video - <http://www.ietf.org/rfc/rfc3984> + <> IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams - <http://www.ietf.org/rfc/rfc3016> + <> IETF RFC 4566, SDP: Session Description Protocol - <http://www.ietf.org/rfc/rfc4566.txt> + <> IETF RFC 4571, Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport - <http://www.ietf.org/rfc/rfc4571.txt> + <> IETF RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) - <http://www.ietf.org/rfc/rfc4585.txt> + <> IETF 5104, Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) - <http://www.ietf.org/rfc/rfc5104.txt> + <> IETF RFC 5888 The Session Description Protocol (SDP) Grouping Framework - <https:/tools.ietf.org/html/rfc5888> + <> IETF RFC 6455, The WebSocket Protocol - <http://www.ietf.org/rfc/rfc6455.txt> + <> IETF RFC 7798, RTP Payload Format for High Efficiency Video Coding (HEVC) - <http://www.ietf.org/rfc/rfc7798.txt> + <> IETF RFC 7826, Real-Time Streaming Protocol Version 2.0 - <http://www.ietf.org/rfc/rfc7826.txt> + <> GZIP file format specification version 4.3 - <http://tools.ietf.org/html/rfc1952> + <> Apple Computer Inc. RTSP over HTTP, Tunneling QuickTime RTSP and RTP over HTTP - <https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf> + <> ONVIF Core Specification - <http://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf> + <> ONVIF Media Service Specification - <http://www.onvif.org/specs/srv/media/ONVIF-Media-Service-Spec.pdf> + <> ONVIF Media2 Service Specification - <http://www.onvif.org/specs/srv/media/ONVIF-Media2-Service-Spec.pdf> + <> ONVIF Replay Control Service Specification - <https://www.onvif.org/specs/srv/replay/ONVIF-ReplayControl-Service-Spec.pdf> + <> Terms and Definitions diff --git a/doc/Thermal.xml b/doc/Thermal.xml index 92bd89290..7f64492b5 100644 --- a/doc/Thermal.xml +++ b/doc/Thermal.xml @@ -2,21 +2,21 @@ - ONVIF Thermal Service Specification + Thermal Service Specification Thermal - 17.06 + 22.06 ONVIF™ www.onvif.org - June, 2017 + June, 2022 - 2008-2020 + 2008-2022 ONVIF™ All rights reserved. @@ -49,6 +49,14 @@ Change Request 2058, 2115, 2141 Added Radiometry Configuration related API and types + + 22.06 + June-2022 + + Sergey Bogdanov + + Rename sections to show real name of service command. + @@ -237,7 +245,15 @@ Added Radiometry Configuration related API and types Thermal Configuration The thermal service provides operations to get or set thermal imaging parameters and the valid ranges for those parameters. Most parameters are common to all thermal video sources, with the exception of the Cooler Options, which are specific of thermal imaging devices which contain this kind of component. The following settings are available through the thermal imaging service operations: - Color Palette: Indicates the color map currently used to represent temperatures in each pixel. + Color Palette: indicates the color map currently used to represent temperatures in each pixel. Defined types are: + + + Grayscale, BlackHot, WhiteHot, Sepia, ... . See ColorPaletteType for a full list of definitions. + + + Custom shall be used when color palette name does not match any of the definitions in ColorPaletteType. + + Polarity: Adjusts the image polarity to represent hot or cold objects in the high or low end of the histogram: @@ -540,7 +556,7 @@ Added Radiometry Configuration related API and types
- Capabilities + GetServiceCapabilities The capabilities reflect optional functions and functionality of a service. The information is static and does not change during device operation. diff --git a/doc/Uplink.xml b/doc/Uplink.xml index 0ae7212ce..384b60af2 100644 --- a/doc/Uplink.xml +++ b/doc/Uplink.xml @@ -2,14 +2,14 @@ - ONVIF Uplink Service Specification + Uplink Specification Uplink - 18.12 + 22.06 ONVIF™ www.onvif.org - December, 2018 + June, 2022 @@ -33,6 +33,14 @@ First release + + 22.06 + June 2022 + + Hans Busch + + Add section on media streaming + @@ -49,8 +57,16 @@ <> IETF RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) <> + IETF RFC 8441 - Bootstrapping WebSockets with HTTP/2 + <> ONVIF Core Specification <> + ONVIF Media2 Service Specification + <> + ONVIF Streaming Specification + <> + Apple Computer Inc. RTSP over HTTP, Tunneling QuickTime RTSP and RTP over HTTP + <> Terms and Definitions @@ -190,6 +206,32 @@ HTTP Transactions The uplink shall be used in reverse direction for http requests and responses. The remote client shall send requests that are served in a standard http manner by the local service.
+
+ Media Streaming +
+ Introduction + The ONVIF Media Service Specification and the ONVIF Streaming Specification define + various mechanism for streaming Video, Audio and Metadata. This specification defines how + to apply streaming over http. Usage of other communication mechanism like UDP unicast and + multicast are outside of the scope of this specification. +
+
+ RTSP over HTTP + The underlying RTSP over HTTP specification requires to open separate communication + channels for continously sending and receiving data. For sending media from RTSP server to + client the communication channel is opened with a GET request and a response without + content-length. For sending media to the server a POST request is used. The specification + notes that a content-length must be sent. Most applications use the value 32767 from the + example given in the specification. Since http/2 streams may be closed by either side when + the content-length has been reached clients shall use a value large enough for the + connection life time. +
+
+ RTSP over WebSockets + A device signaling support for websockets over RTSP via its capabilities shall support + RFC 8441 on the uplink. +
+
Configuration Interface @@ -208,47 +250,68 @@ Status Current connection status + + CertPathValidationPolicyID ID of Certificate Validation policy to validate the remote uplink server certficate. If not configured, server certificate shall not be validated. + Field RemoteAddress is used as key of the list of uplink configurations.
GetUplinks A device supporting uplinks shall support this command to retrieve the configured uplink configurations. The Status field shall signal whether a connection is Offline, Connecting or Online. - REQUEST - <empty> - RESPONSE - - - Configuration – optional, unbounded [Configuration] - List of configurations - - + + + request + + This message is empty + + + + response + + Configuration – optional, unbounded [Configuration] + List of configurations. + + +
SetUplink A device supporting uplinks shall support this command to add or modify an uplink configuration. The Status property of the UplinkConfiguration shall be ignored by the device. A device shall use the field RemoteAddress to decide whether to update an existing entry or create a new entry. - REQUEST - + + + request + + Configuration – [UplinkConfiguration] + Configuration to be added or modified. + + + + response - Configuration – [UplinkConfiguration] - Configuration to be added or modified. + This message is empty - - RESPONSE - <empty> + +
DeleteUplink A device supporting uplinks shall support this command to remove an uplink configuration. - REQUEST - - - RemoteAddress – [xs:anyURI] - Configuration to be deleted. - - - RESPONSE - <empty> + + + request + + RemoteAddress – [xs:anyURI] + Configuration to be deleted. + + + + response + + This message is empty + + +
Capabilities diff --git a/wsdl/ver10/device/wsdl/devicemgmt.wsdl b/wsdl/ver10/device/wsdl/devicemgmt.wsdl index 1b1ae2125..6e8b60645 100644 --- a/wsdl/ver10/device/wsdl/devicemgmt.wsdl +++ b/wsdl/ver10/device/wsdl/devicemgmt.wsdl @@ -1,7 +1,7 @@ - + @@ -356,6 +356,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates no support for user configuration. + + + List of supported Addons by the device. + + @@ -376,7 +381,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Automatic adjustment of the deviation from the horizon also called pitch and roll. - + diff --git a/wsdl/ver10/events/wsdl/event-vs.wsdl b/wsdl/ver10/events/wsdl/event-vs.wsdl index 302c7b4c8..aebf51246 100644 --- a/wsdl/ver10/events/wsdl/event-vs.wsdl +++ b/wsdl/ver10/events/wsdl/event-vs.wsdl @@ -2,7 +2,7 @@ + - + @@ -79,6 +80,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Maxiumum number of event broker configurations that can be added to the device. + + + Indicates that metadata streaming over MQTT is supported + + @@ -364,7 +370,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Concrete Topic Expression to select specific topics to publish. + Concrete Topic Expression to select specific event topics to publish. @@ -377,6 +383,16 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Current connection status (see tev:ConnectionStatus for possible values). + + + The ID of the certification path validation policy used to validate the broker certificate. In case encryption is used but no validation policy is specified, the device shall not validate the broker certificate. + + + + + Concrete Topic Expression to select specific metadata topics to publish. + + @@ -855,7 +871,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + diff --git a/wsdl/ver10/events/wsdl/event.wsdl b/wsdl/ver10/events/wsdl/event.wsdl index 208d77b76..5509a9672 100644 --- a/wsdl/ver10/events/wsdl/event.wsdl +++ b/wsdl/ver10/events/wsdl/event.wsdl @@ -2,7 +2,7 @@ + - + @@ -79,6 +80,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Maxiumum number of event broker configurations that can be added to the device. + + + Indicates that metadata streaming over MQTT is supported + + @@ -364,7 +370,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Concrete Topic Expression to select specific topics to publish. + Concrete Topic Expression to select specific event topics to publish. @@ -382,6 +388,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The ID of the certification path validation policy used to validate the broker certificate. In case encryption is used but no validation policy is specified, the device shall not validate the broker certificate. + + + Concrete Topic Expression to select specific metadata topics to publish. + + diff --git a/wsdl/ver10/schema/common.xsd b/wsdl/ver10/schema/common.xsd index 0d47bb7c8..7b7540da2 100644 --- a/wsdl/ver10/schema/common.xsd +++ b/wsdl/ver10/schema/common.xsd @@ -1,14 +1,14 @@ - + @@ -190,6 +190,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + @@ -205,6 +206,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + @@ -216,6 +218,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + diff --git a/wsdl/ver10/uplink/wsdl/uplink.wsdl b/wsdl/ver10/uplink/wsdl/uplink.wsdl index b513940ca..fa1c56aef 100644 --- a/wsdl/ver10/uplink/wsdl/uplink.wsdl +++ b/wsdl/ver10/uplink/wsdl/uplink.wsdl @@ -1,7 +1,7 @@ - + @@ -65,6 +65,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Current connection status (see tup:ConnectionStatus for possible values). + + + CertPathValidationPolicyID used to validate the uplink server certificate. If CertPathValidationPolicyID is not configured, uplink server certificate shall not be validated. + + diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 1202b65f3..fbc522224 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -1,7 +1,7 @@ - + @@ -1070,7 +1070,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Token of the mask. - +