diff --git a/.gitignore b/.gitignore index 743328ec1..2178e36cd 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ *.dia~ +/.vs diff --git a/doc/Core.xml b/doc/Core.xml index 465a5d9e3..984fa2226 100644 --- a/doc/Core.xml +++ b/doc/Core.xml @@ -6482,7 +6482,10 @@ onvif://www.onvif.org/name/ARV-453
Configuration Renewal - The configuration allows for a renewal endpoint to be set. + + The configuration allows for a renewal endpoint to be set. If the device supports this feature, it shall automatically renew the credentials + when they are about to expire. + The device shall do a GET request to the configured RenewalEndpoint with the access token retrieved from the configured AuthorizationServer. The endpoint shall respond with a JSON payload with the following structure: diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 92a7d7ca8..9e8fecbf0 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -34,7 +34,7 @@ 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 + 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. @@ -244,8 +244,7 @@ IETF RFC 2435, RFC2435 - RTP Payload Format for JPEG-compressed Video <> IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams - + <> IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications <> IETF RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control @@ -394,6 +393,30 @@ + + KEMAC + + + Key Encryption and Message Authentication Code + + + + + MIKEY + + + Multimedia Internet KEYing + + + + + MKI + + + Master Key Identifier + + + MPEG-4 @@ -401,6 +424,14 @@ Moving Picture Experts Group - 4 + + + PRF + + + Pseudo-Random Function + + PTZ @@ -603,7 +634,10 @@
SRTP data transfer via UDP - This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 for transmission and RFC 4567 for key exchange. + A device signaling support for SecureRTSPStreaming parameter within StreamingCapabilities shall support SRTP as defined in RFC 3711, furthermore it shall support MIKEY for key exchange and management as defined in section MIKEY. + A device listing any supported SRTP cryptographic algorithms via the SecureStreamingProtocolAlgorithms structure included in the Media2 service shall behave as defined in section Cryptographic algorithm negotiation, a device not listing supported SRTP cryptographic algorithms shall use the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711. + TLS shall be used for RTSP when SRTP is used. The device shall never return RTP/SAVP or the MIKEY in the SDP if the RTSP channel is not secure. +
RTP/RTSP/HTTP/TCP @@ -613,7 +647,7 @@
RTP/RTSP/TCP/WebSocket - The device indicating support for RTSP over WebSocket, as explained in section 5.11 of the ONVIF Media2 Service Specification and section 5.5 of the ONVIF Replay Control Service Specification, shall support streaming media using WebSocket protocol according to this specification. The provided URI shall set the hierarchical part (hier_part) to absolute path (abs_path) [RFC 2396]. For example, if the WebSocket URI with network path is “ws://1.2.3.4/my-websocket-uri”, the provided URI shall be “ws:/my-websocket-uri”. + The device indicating support for RTSP over WebSocket, as explained in section 5.11 of the ONVIF Media2 Service Specification and section 5.5 of the ONVIF Replay Control Service Specification, shall support streaming media using WebSocket protocol according to this specification. The provided URI shall set the hierarchical part (hier_part) to absolute path (abs_path) [RFC 2396]. For example, if the WebSocket URI with network path is "ws://1.2.3.4/my-websocket-uri", the provided URI shall be "ws:/my-websocket-uri". For RTSP tunneling over WebSocket a device shall support RTP/RTSP/TCP interleaved binary data as defined in [RFC 2326] Section 10.12. WebSocket protocol implementation shall conform to [RFC 6455] - The WebSocket Protocol. The mechanism to be used for establishing a WebSocket connection between a client and server is explained in detail in Section 7. @@ -671,7 +705,7 @@ 0/1 - If the payload includes padding octet, this should be set to “1” + If the payload includes padding octet, this should be set to "1" @@ -684,7 +718,7 @@ Depends on the use of extension of RTP header. The specification defines two scenarios where a RTP header extension could be used to transmit additional information: - 1) “JPEG over RTP” (see Section ). + 1) "JPEG over RTP" (see Section ). 2) Replay (see Section ) If the header extension is used the Extension bit shall be set. @@ -708,7 +742,7 @@ 0/1 - The usage shall be conform to related RFCs (e.g. [RFC 3984] for H.264 Video) or to this standard e.g “JPEG over RTP” (see Section ) or RTP streaming of metadata (see Section ). + The usage shall be conform to related RFCs (e.g. [RFC 3984] for H.264 Video) or to this standard e.g "JPEG over RTP" (see Section ) or RTP streaming of metadata (see Section ). @@ -728,7 +762,7 @@ - The initial value of the “sequence number” should be random (unpredictable) to make known-plaintext attacks on encryption more difficult. + The initial value of the "sequence number" should be random (unpredictable) to make known-plaintext attacks on encryption more difficult. This number increments by one for each RTP data packet sent @@ -739,7 +773,7 @@ - The initial value of the “timestamp” should be random (unpredictable) to make known-plaintext attacks on encryption more difficult. + The initial value of the "timestamp" should be random (unpredictable) to make known-plaintext attacks on encryption more difficult. See Section for further details of Media Synchronization. The usage of the timestamp is dependent on the codec. @@ -765,13 +799,13 @@ A dynamic payload type (96-127) shall be used for payload type which is assigned in the process of a RTSP session setup. - The RTP marker bit shall be set to “1” when the XML document is closed. + The RTP marker bit shall be set to "1" when the XML document is closed. It is RECOMMENDED to use an RTP timestamp representing the creation time of the RTP packet with a RTP clock rate of 90000 Hz. Only UTC timestamps shall be used within the metadata stream. The synchronization of video and audio data streams is done using RTCP. - The Metadata payload is an XML document with root node tt:MetaDataStream. There is no limitation on the size of the XML document. If GZIP compression is used, the payload starts with a GZIP header according to RFC 1952 followed by the compressed data. A marker bit signals the end of the compressed data. When a synchronization point (see section “Synchronization Points” of the ONVIF Media Service Specification) is requested for the stream, the previous XML document shall be closed and a new one started. It is RECOMMENDED to start new XML documents after 1 second, at the longest. The RTP timestamp of the Metadata stream has no specific meaning. The Metadata stream multiplexes Metadata from different sources. This specification defines placeholders for the Scene Description of the Video Analytics, the PTZ Status of the PTZ controller and the Notifications of the Event Configuration. A device can select which of these parts should be multiplexed into the Metadata during the Media Configuration (see seciont “Metadata Configuration” of the ONVIF Media Service Specification). Each part can appear multiple times in arbitrary order within the document. A Metadata connection can be bi-directional using the backchannel mechanism (see Section ). + The Metadata payload is an XML document with root node tt:MetaDataStream. There is no limitation on the size of the XML document. If GZIP compression is used, the payload starts with a GZIP header according to RFC 1952 followed by the compressed data. A marker bit signals the end of the compressed data. When a synchronization point (see section "Synchronization Points" of the ONVIF Media Service Specification) is requested for the stream, the previous XML document shall be closed and a new one started. It is RECOMMENDED to start new XML documents after 1 second, at the longest. The RTP timestamp of the Metadata stream has no specific meaning. The Metadata stream multiplexes Metadata from different sources. This specification defines placeholders for the Scene Description of the Video Analytics, the PTZ Status of the PTZ controller and the Notifications of the Event Configuration. A device can select which of these parts should be multiplexed into the Metadata during the Media Configuration (see seciont "Metadata Configuration" of the ONVIF Media Service Specification). Each part can appear multiple times in arbitrary order within the document. A Metadata connection can be bi-directional using the backchannel mechanism (see Section ). Metadata stream contains the following elements: @@ -858,7 +892,7 @@ The wall clock should be common in the device and each timestamp value should be determined properly. The client can synchronize different media streams at the appropriate timing based on the RTP clock and wall clock timestamps (see ). - In case of multiple devices, the NTP timestamp should be common to all devices, and the NTP server should be required in the system The client can get information about “NTP server availability” from the devices by using the GetNTP command. Refer to Section 8.2.5. + In case of multiple devices, the NTP timestamp should be common to all devices, and the NTP server should be required in the system The client can get information about "NTP server availability" from the devices by using the GetNTP command. Refer to Section 8.2.5.
Media Synchronization @@ -873,7 +907,7 @@
Synchronization Point Synchronization points allow clients to decode and correctly use data after the synchronization point. A synchronization point MAY be requested by a client in case of decoder error (e.g. in consequence of packet loss) to enforce the device to add an I-Frame as soon as possible or to request the current ptz or event status. - The WebService based methods require to support the Synchronization Point request as defined in the section “Synchronization Point” of the ONVIF Media Service Specification. + The WebService based methods require to support the Synchronization Point request as defined in the section "Synchronization Point" of the ONVIF Media Service Specification. In addition it is recommended to support the PLI messages as described in [RFC 4585] in order to allow receivers as defined in the ONVIF Receiver Service Specification to request a Synchronization Point. For H.264 and H.265 Video the SPS/PPS header shall be sent in-band if these have been changed during the transmission.
@@ -1054,7 +1088,7 @@ M - Required to set media session　parameters. + Required to set media session parameters. @@ -1213,13 +1247,13 @@ server->client: RTSP/1.0 200 OK
RTSP session for a metadata stream - In the case of a metadata stream, the SDP description “application” shall be used in the DESCRIBE response for media type and one of these encoding a names shall be used + In the case of a metadata stream, the SDP description "application" shall be used in the DESCRIBE response for media type and one of these encoding a names shall be used - “vnd.onvif.metadata” for uncompressed + "vnd.onvif.metadata" for uncompressed - “vnd.onvif.metadata+gzip” for GZIP compressed + "vnd.onvif.metadata+gzip" for GZIP compressed "vnd.onvif.metadata.exi.ext" for EXI using compression parameters that are sent in-band @@ -1229,7 +1263,7 @@ server->client: RTSP/1.0 200 OK server: DESCRIBE rtsp://example.com/onvif_camera RTSP/1.0 Cseq: 1 - + server->client: RTSP/1.0 200 OK Cseq: 1 Content-Type: application/sdp @@ -1255,7 +1289,7 @@ server->client: RTSP/1.0 200 OK
RTSP message example - This example shows the message transfer between an RTSP client (client) and an RTSP server (server). The client requests one audio and one video stream from the device. The Stream Uri “rtsp://example.com/onvif_camera” can be retrieved using the GetStreamUri command. Refer to Section „Stream URI“ of the ONVIF Media Service Specification. + This example shows the message transfer between an RTSP client (client) and an RTSP server (server). The client requests one audio and one video stream from the device. The Stream Uri "rtsp://example.com/onvif_camera" can be retrieved using the GetStreamUri command. Refer to Section "Stream URI" of the ONVIF Media Service Specification. server: DESCRIBE rtsp://example.com/onvif_camera RTSP/1.0 Cseq: 1 server->client: RTSP/1.0 200 OK @@ -1279,12 +1313,12 @@ server->client: RTSP/1.0 200 OK Transport: RTP/AVP;unicast;client_port=8002-8003; server_port=9004-9005 Session: 12345678; timeout=60 - + client->server: SETUP rtsp://example.com/onvif_camera/video RTSP/1.0 Cseq: 3 Transport: RTP/AVP;unicast;client_port=8004-8005 Session: 12345678 - + server->client: RTSP/1.0 200 OK Cseq: 3 Transport: RTP/AVP;unicast;client_port=8004-8005; @@ -1341,31 +1375,31 @@ server->client: RTSP/1.0 200 OK
Connection setup for a bi- directional connection - A client shall include the feature tag in it’s DESCRIBE request to indicate that a bidirectional data connection shall be established. + A client shall include the feature tag in it's DESCRIBE request to indicate that a bidirectional data connection shall be established. A server that understands this Require tag shall include an additional media stream in its SDP file as configured in its Media Profile. An RTSP server that does not understand the backchannel feature tag or does not support bidirectional data connections shall respond with an error code 551 Option not supported according to the RTSP standard. The client can then try to establish an RTSP connection without backchannel. A SDP file is used to describe the session. To indicated the direction of the media data the server shall include the a=sendonly in each media section representing media being sent from the client to the server and a=recvonly attributes in each media section representing media being sent from the server to the client. The server shall list all supported decoding codecs as own media section and the client chooses which one is used. The payload type and the encoded bitstream shall be matched with one of the a=rtpmap fields provided by the server so that the server can properly determine the audio decoder.
Describe example for a server without backchannel support: -
Describe example for a server with Onvif backchannel support: - This SDP file completely describes the RTSP session. The Server gives the client its control URLs to setup the streams. In the next step the client can setup the sessions: The third setup request establishes the audio backchannel connection. In the next step the client starts the session by sending a PLAY request. - After receiving the OK response to the PLAY request the client can start sending audio data to the server. It shall not start sending data to the server before it has received the response. The Require-header indicates that a special interpretation of the PLAY command is necessary. The command covers both starting of the video and audio stream from NVT to the client and starting the audio connection from client to server. To terminate the session the client sends a TEARDOWN request. - @@ -1441,12 +1475,12 @@ Session: 123124
Describe example in case of backchannel support with multiple decoding capability If a device supports multiple audio decoders as backchannel, it can signal such capability by listing multiple a=rtpmap fields illustrated as follows. - Note that multicast streaming for Audio Backchannel is outside of the scope of this specification.
Example: Multicast Setup -
@@ -1517,12 +1551,12 @@ Transport:RTP/AVP;multicast;destination=224.2.1.1;port=60000-60001;ttl=128;mode=
Example This section provides as example a camera with three sensors. For this example, the SDP information sent to client uses the Real Time Streaming Protocol (RTSP). - When the client sends the describle command to server, the server generates the response information and the track to be sent in one session will be chosen. According to [RFC 5888], the fields “group” and “mid” are provided in the sdp information. The attribute “group” represents that the following “mid” stream can be sent in one session. To clearly notify the client which URL uses for setup, we use the attribute “control” with absolute path. - When the client sends the describle command to server, the server generates the response information and the track to be sent in one session will be chosen. According to [RFC 5888], the fields "group" and "mid" are provided in the sdp information. The attribute "group" represents that the following "mid" stream can be sent in one session. To clearly notify the client which URL uses for setup, we use the attribute "control" with absolute path. + a:x-onvif-track:<TrackReference> For example: -NVS – NVT: DESCRIBE rtsp://192.168.0.1 RTSP/1.0 +NVS - NVT: DESCRIBE rtsp://192.168.0.1 RTSP/1.0 Cseq: 1 User-Agent: ONVIF Rtsp client Accept: application/sdp - -NVT – NVS: RTSP/1.0 200 OK + +NVT - NVS: RTSP/1.0 200 OK Cseq: 1 Content-Type: application/sdp Content-Length: xxx @@ -1665,7 +1699,7 @@ NVT – NVS: RTSP/1.0 200 OK - NTP timestamp… + NTP timestamp... @@ -1698,7 +1732,7 @@ NVT – NVS: RTSP/1.0 200 OK - payload… + payload... @@ -1710,7 +1744,7 @@ NVT – NVS: RTSP/1.0 200 OK NTP timestamp. An NTP [RFC 1305] timestamp indicating the absolute UTC time associated with the access unit. - C: 1 bit. Indicates that this access unit is a synchronization point or “clean point”, e.g. the start of an intra-coded frame in the case of video streams. + C: 1 bit. Indicates that this access unit is a synchronization point or "clean point", e.g. the start of an intra-coded frame in the case of video streams. E: 1 bit. Indicates the end of a contiguous section of recording. The last access unit in each track before a recording gap, or at the end of available footage, shall have this bit set. When replaying in reverse, the E flag shall be set on the last frame at the end of the contiguous section of recording. @@ -1800,7 +1834,7 @@ NVT – NVS: RTSP/1.0 200 OK - NTP timestamp… + NTP timestamp... @@ -1843,7 +1877,7 @@ NVT – NVS: RTSP/1.0 200 OK - payload… + payload... @@ -1853,7 +1887,7 @@ NVT – NVS: RTSP/1.0 200 OK
RTSP Feature Tag - The Replay Service uses the “onvif-replay” feature tag to indicate that it supports the RTSP extensions described in this standard. This allows clients to query the server’s support for these extensions using the Require header as described in [RFC 2326] section . + The Replay Service uses the "onvif-replay" feature tag to indicate that it supports the RTSP extensions described in this standard. This allows clients to query the server's support for these extensions using the Require header as described in [RFC 2326] section . Example: C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 @@ -1876,7 +1910,7 @@ Require: onvif-replay Range: clock=20090615T114900.440Z- Rate-Control: no - The ReversePlayback capability defined in the ONVIF Replay Control Service Specification signals if a device supports reverse playback. Reverse playback is indicated using the Scale header field with a negative value. For example to play in reverse without no data loss a value of –1.0 would be used. + The ReversePlayback capability defined in the ONVIF Replay Control Service Specification signals if a device supports reverse playback. Reverse playback is indicated using the Scale header field with a negative value. For example to play in reverse without no data loss a value of -1.0 would be used. PLAY rtsp://192.168.0.1/path/to/recording RTSP/1.0 Cseq: 123 @@ -1886,7 +1920,7 @@ Range: clock=20090615T114900.440Z- Rate-Control: no Scale: -1.0 - If a device supports reverse playback it shall accept a Scale header with a value of –1.0. A device MAY accept other values for the Scale parameter. Unless the Rate-Control header is set to “no” (see below), the Scale parameter is used in the manner described in [RFC 2326]. If Rate-Control is set to “no”, the Scale parameter, if it is present, shall be either 1.0 or –1.0, to indicate forward or reverse playback respectively. If it is not present, forward playback is assumed. + If a device supports reverse playback it shall accept a Scale header with a value of -1.0. A device MAY accept other values for the Scale parameter. Unless the Rate-Control header is set to "no" (see below), the Scale parameter is used in the manner described in [RFC 2326]. If Rate-Control is set to "no", the Scale parameter, if it is present, shall be either 1.0 or -1.0, to indicate forward or reverse playback respectively. If it is not present, forward playback is assumed.
Range header field A device shall support the Range field expressed using absolute times as defined by [RFC 2326]. Absolute times are expressed using the utc-range from [RFC 2326]. @@ -1894,10 +1928,10 @@ Scale: -1.0 In all cases, the first point of the range indicates the starting point for replay. The time itsel shall be given as -utc-range = "clock" ["=" utc-range-spec] -utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) -utc-time = utc-date "T" utc-clock "Z" -utc-date = 8DIGIT +utc-range = "clock" ["=" utc-range-spec] +utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) +utc-time = utc-date "T" utc-clock "Z" +utc-date = 8DIGIT utc-clock = 6DIGIT [ "." 1*9DIGIT ] as defined in [RFC2326]. @@ -1920,20 +1954,20 @@ Scale: -1.0
Rate-Control header field - This specification introduces the Rate-Control header field, which may be either “yes” or “no”. If the field is not present, “yes” is assumed, and the stream is delivered in real time using standard RTP timing mechanisms. If this field is “no”, the stream is delivered as fast as possible, using only the flow control provided by the transport to limit the delivery rate. - The important difference between these two modes is that with “Rate-Control=yes”, the server is in control of the playback speed, whereas with “Rate-Control=no” the client is in control of the playback speed. Rate-controlled replay will typically only be used by non-ONVIF specific clients as they will not specify “Rate-Control=no”. + This specification introduces the Rate-Control header field, which may be either "yes" or "no". If the field is not present, "yes" is assumed, and the stream is delivered in real time using standard RTP timing mechanisms. If this field is "no", the stream is delivered as fast as possible, using only the flow control provided by the transport to limit the delivery rate. + The important difference between these two modes is that with "Rate-Control=yes", the server is in control of the playback speed, whereas with "Rate-Control=no" the client is in control of the playback speed. Rate-controlled replay will typically only be used by non-ONVIF specific clients as they will not specify "Rate-Control=no". When replaying multiple tracks of a single recording, started by a single RTSP PLAY command and not using rate-control, the data from the tracks should be multiplexed in time in the same order as they were recorded. - An ONVIF compliant RTSP server shall support operation with “Rate-Control=no” for playback. + An ONVIF compliant RTSP server shall support operation with "Rate-Control=no" for playback.
Frames header field The Frames header field may be used to reduce the number of frames that are transmitted, for example to lower bandwidth or processing load. Three modes are possible: - Intra frames only. This is indicated using the value “intra”, optionally followed by a minimum interval between successive intra frames in the stream. The latter can be used to limit the number of frames received even in the presence of “I-frame storms” caused by many receivers requesting frequent I-frames. + Intra frames only. This is indicated using the value "intra", optionally followed by a minimum interval between successive intra frames in the stream. The latter can be used to limit the number of frames received even in the presence of "I-frame storms" caused by many receivers requesting frequent I-frames. - Intra frames and predicted frames only. This is indicated using the value “predicted”. This value can be used to eliminate B-frames if the stream includes them. + Intra frames and predicted frames only. This is indicated using the value "predicted". This value can be used to eliminate B-frames if the stream includes them. All frames. This is the default. @@ -1950,13 +1984,13 @@ Scale: -1.0 Frames: predicted To request all frames (note that it is not necessary to explicitly specify this mode but the example is included for completeness): Frames: all - The interval argument used with the “intra” option refers to the recording timeline, not playback time; thus for any given interval the same frames are played regardless of playback speed. The interval argument shall NOT be present unless the Frames option is “intra”. + The interval argument used with the "intra" option refers to the recording timeline, not playback time; thus for any given interval the same frames are played regardless of playback speed. The interval argument shall NOT be present unless the Frames option is "intra". The server shall support the Frames header field. This does not preclude the use of the Scale header field as an alternative means of limiting the data rate. The implementation of the Scale header field may vary between different server implementations, as stated by [RFC 2326]. - An ONVIF compliant RTSP server shall support the Frames parameters “intra” and “all” for playback. + An ONVIF compliant RTSP server shall support the Frames parameters "intra" and "all" for playback.
Synchronization points - The transmitted video stream shall begin at a synchronization point (see section “Synchronization Point” of the ONVIF Media Service Specificaton). The rules for choosing the starting frame are as follows: + The transmitted video stream shall begin at a synchronization point (see section "Synchronization Point" of the ONVIF Media Service Specificaton). The rules for choosing the starting frame are as follows: If the requested start time is within a section of recorded footage, the stream starts with the first clean point at or before the requested start time. This is the case regardless of playback direction. @@ -1985,10 +2019,10 @@ Scale: -1.0 The order in which video packets are transmitted during reverse replay is based on GOPs, where a GOP consists of a clean point followed by a sequence of non-cleanpoint packets. - During reverse playback, GOPs shall be sent in reverse order, but packets within a GOP shall be sent in forward order. The first packet of each GOP shall have the “discontinuity” bit set in its RTP extension header. The last frame of a GOP immediately following a gap (or the beginning of available footage) shall have the E bit set in its RTP extension header. + During reverse playback, GOPs shall be sent in reverse order, but packets within a GOP shall be sent in forward order. The first packet of each GOP shall have the "discontinuity" bit set in its RTP extension header. The last frame of a GOP immediately following a gap (or the beginning of available footage) shall have the E bit set in its RTP extension header. When transmitting only key frames, or when the codec is not motion-based (e.g. JPEG), a GOP is considered to consist of a single frame, but may still be composed of multiple packets. In this case the packets within each frame shall be again sent in forward order, while the frames themselves shall be sent in reverse order. Audio and metadata streams MAY be transmitted in an order mirroring that of the video stream. Thus packets from these streams are sent in forward playback order until the occurrence of a packet (generally a video packet) with the D bit set in the extension header, at which point they jump back to a point before the discontinuity. - Note that reverse playback of Audio packet isn’t useful. Threfore Audio packets should generally not be transmitted during reverse playback. + Note that reverse playback of Audio packet isn't useful. Threfore Audio packets should generally not be transmitted during reverse playback. The example of shows for the same recording as depicted in how packets are transmitted during reverse forward playback. As shown all packets are transmitted in recording order.
Packet transmission during reverse playback @@ -2005,10 +2039,10 @@ Scale: -1.0
RTP timestamps - The use of RTP timestamps depends on the value of the Rate-Control header. If the value of this header is “no” (i.e. the client controls playback speed), the RTP timestamps are derived from the original sampling times of the recorded frames. If the Rate-Control header is not present or has the value “yes” (i.e. the server controls playback speed), the RTP timestamps correspond to playback timing as described in [RFC 2326] Appendix B. - If Rate-Control is “no”, the RTP timestamps of packets transmitted during reverse playback shall be the same as they would be if those same packets were being transmitted in the forwards direction. Unlike the sequence numbers, the RTP timestamps correspond to the original recording order, not the delivery order. The server MAY use the same RTP timestamps that were originally received when the stream was recorded. + The use of RTP timestamps depends on the value of the Rate-Control header. If the value of this header is "no" (i.e. the client controls playback speed), the RTP timestamps are derived from the original sampling times of the recorded frames. If the Rate-Control header is not present or has the value "yes" (i.e. the server controls playback speed), the RTP timestamps correspond to playback timing as described in [RFC 2326] Appendix B. + If Rate-Control is "no", the RTP timestamps of packets transmitted during reverse playback shall be the same as they would be if those same packets were being transmitted in the forwards direction. Unlike the sequence numbers, the RTP timestamps correspond to the original recording order, not the delivery order. The server MAY use the same RTP timestamps that were originally received when the stream was recorded. This means that successive RTP packets of a single GOP will always have increasing RTP timestamps (see transmission order above), but that the timestamp on index frames of successively received GOPs will decrease during reverse replay. - If Rate-Control is “yes”, the RTP timestamps of packets transmitted during reverse playback shall indicate the times at which each frame should be rendered at the client. Thus successive packets of a single GOP will have decreasing RTP timestamps (since the first one delivered should be played last), and the timestamps on index frames will increase. In this mode the interval between successive timestamps depends on the values of the Speed and Scale headers, as described in [RFC 2326] Appendix B. + If Rate-Control is "yes", the RTP timestamps of packets transmitted during reverse playback shall indicate the times at which each frame should be rendered at the client. Thus successive packets of a single GOP will have decreasing RTP timestamps (since the first one delivered should be played last), and the timestamps on index frames will increase. In this mode the interval between successive timestamps depends on the values of the Speed and Scale headers, as described in [RFC 2326] Appendix B. Note that strict decreasing order of RTP timestamps does not apply for GOPs with B-Frames.
@@ -2023,11 +2057,11 @@ Scale: -1.0
End of footage - If playback reaches a point after which there is no further data in one or more of the streams being sent, it stops transmitting data but does not enter the “paused” state. If the server resumes recording after this has happened, delivery will resume with the new data as it is received. + If playback reaches a point after which there is no further data in one or more of the streams being sent, it stops transmitting data but does not enter the "paused" state. If the server resumes recording after this has happened, delivery will resume with the new data as it is received.
Go To Time - As stated in [RFC 2326] section 10.5, a PLAY command received when replay is already in progress will not take effect until the existing play operation has completed. This specification adds a new RTSP header, “Immediate”, which overrides this behaviour for the PLAY command that it is used with: + As stated in [RFC 2326] section 10.5, a PLAY command received when replay is already in progress will not take effect until the existing play operation has completed. This specification adds a new RTSP header, "Immediate", which overrides this behaviour for the PLAY command that it is used with: PLAY rtsp://192.168.0.1/path/to/recording RTSP/1.0 CSeq: 123 @@ -2036,8 +2070,8 @@ Require: onvif-replay Range: clock=20090615T114900.440Z- Rate-Control: no Immediate: yes - If the server receives a PLAY command with the Immediate header set to “yes”, it will immediately start playing from the new location, cancelling any existing PLAY command. The first packet sent from the new location shall have the D (discontinuity) bit set in its RTP extension header. - An ONVIF compliant RTSP server shall support the immediate header field for playback with value “yes”. The behavior without immediate header or value “no” is not defined by the specification. + If the server receives a PLAY command with the Immediate header set to "yes", it will immediately start playing from the new location, cancelling any existing PLAY command. The first packet sent from the new location shall have the D (discontinuity) bit set in its RTP extension header. + An ONVIF compliant RTSP server shall support the immediate header field for playback with value "yes". The behavior without immediate header or value "no" is not defined by the specification.
Use of RTCP @@ -2085,7 +2119,7 @@ Immediate: yes
Example: WebSocket Handshake - This example shows the message transfer between an Web client (client) and an Web server (server). The client requests server to initiate a WebSocket connection using the WebSocket URI. The WebSocket Uri can be retrieved using the GetServiceCapabilities command of the ONVIF Media2 Service. An example WebSocket URI may look like, “ws:/webSocketServer” + This example shows the message transfer between an Web client (client) and an Web server (server). The client requests server to initiate a WebSocket connection using the WebSocket URI. The WebSocket Uri can be retrieved using the GetServiceCapabilities command of the ONVIF Media2 Service. An example WebSocket URI may look like, "ws:/webSocketServer" server: GET /webSocketServer HTTP/1.1 Host: 192.168.0.1 Upgrade: websocket @@ -2108,51 +2142,331 @@ Sec-WebSocket-Protocol: rtsp.onvif.org Device supporting live streaming and playback streaming over WebSocket provides the WebSocket streaming URI in the GetServiceCapabilities of Media2 Service Section 5.11 and Replay Service Section 5.4.1 respectively.
WebSocket Message Frame Format - The basic units of data transmitted over WebSocket connection are referred as “messages” in the RFC 6455. The messages are composed of one or more frames and each frame has an associated data type. There are different type of frames like text frames and data frames. + The basic units of data transmitted over WebSocket connection are referred as "messages" in the RFC 6455. The messages are composed of one or more frames and each frame has an associated data type. There are different type of frames like text frames and data frames. The device shall only use data frames for transmitting the RTP/RTSP/TCP data over the WebSocket.
+ + SRTP +
+ Cryptographic algorithm negotiation + This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. + + The device shall list supported SRTP cryptographic algorithms via the SecureStreamingProtocolAlgorithms structure included in the Media2 service video encoder, audio encoder and metadata configuration elements as listed below: (ONVIF specification) + + + AudioEncoder2ConfigurationOptions + + + VideoEncoder2ConfigurationOptions + + + MetadataConfigurationOptions + + If the SecureStreamingProtocolAlgorithms parameter is present, the + device shall support at least one of the following algorithms: + + NONE (ONVIF specification) + + NONE is a special case, where the media is listed as RTP/AVP instead of + RTP/SAVP and where MIKEY is unused altogether. + + + This is to allow the use of RTSPS without using an SRTP encrypted media + stream. It can also be used for RTSPS interleaved where media is sent over the + same TLS protected channel as the RTSP control messages. + + + + AES_CM_128_HMAC_SHA1_80 (RFC 3711) + + + AEAD_AES_128_GCM (RFC 7714) + + + AEAD_AES_256_GCM (RFC 7714) + + + + + + A device shall allow a specific algorithm to be configured using the SecureStreamingProtocolAlgorithm attribute. The specific algorithm shall be configurable through the following methods: (ONVIF specification) + + + SetAudioEncoderConfiguration + + + SetVideoEncoderConfiguration + + + SetMetadataConfiguration + + + +
+
+ MIKEY + + MIKEY is used for key management with SRTP. The device shall support MIKEY as defined in RFC 3830 for key management. + One exception is that, in RFC 3830, support for MIKEY-PSK and MIKEY-PK are listed mandatory. For ONVIF SRTP, only MIKEY-PSK support is defined and mandatory. + MIKEY-PK should not be used for ONVIF SRTP. (ONVIF specification) + + + The MIKEY message shall contain the following payloads: (RFC 3830 MIKEY specification) + + + Common Header Payload + + + KEMAC Payload + + The KEMAC payload should not be encrypted since TLS already encrypts the + RTSPS channel. + + + If the key type is TEK without salt and a salt must be provided, the key and + the salt shall be concatenated and sent in the Key data section of the + payload. (ONVIF specification) + + + If the key type is TEK+SALT and a salt must be provided, the SALT shall be + in the Salt data section. + + + The device and client shall support TEK for AES_CM_128_HMAC_SHA1_80 and TEK+SALT + for other encryption algorithms. (ONVIF specification) + + + To keep track of key validity, The SPI/MKI shall be set in the KV data. Each + SRTP packet shall include the MKI. (ONVIF specification) + + + + Security Policy Payload + + Specifies the encryption parameters to be used by the streams. + + AES_CM_128_HMAC_SHA1_80 (RFC 3711) + Encryption Algorithm: AES-CM + Session Encryption Key Length: 16 octets + Authentication Algorithm: HMAC-SHA-1 + Session Auth Key Length: 20 octets + Session Salt Key Length: 14 octets + SRTP Encryption: On + SRTCP Encryption: On + Authentication Tag Length: 10 octets + SRTP PRF: AES-CM + + + AEAD_AES_128_GCM (RFC 7714) + Encryption Algorithm: AES-GCM + Session Encryption Key Length: 16 octets + Authentication Algorithm: NULL + Session Auth Key Length: N/A + Session Salt Key Length: 12 octets + SRTP Encryption: On + SRTCP Encryption: On + AEAD Authentication Tag Length: 16 octets + SRTP PRF: AES-CM + + + AEAD_AES_256_GCM (RFC 7714) + Encryption Algorithm: AES-GCM + Session Encryption Key Length: 32 octets + Authentication Algorithm: NULL + Session Auth Key Length: N/A + Session Salt Key Length: 12 octets + SRTP Encryption: On + SRTCP Encryption: On + AEAD Authentication Tag Length: 16 octets + SRTP PRF: AES-CM + + + + + + +
+ Key management through RTSP + + The key management extensions for SDP and RTSP (RFC 4567) allows for key management through RTSP. + Note: According to RFC 4567 a MIKEY message does not contain line breaks, + they have been included in the examples below for readability. + +
+ Stream Initialization + + Key management extensions for SDP and RTSP (RFC 4567) defines stream + initialization. + + + When the device is providing the key, the SDP is required to have a media of + type RTP/SAVP and a MIKEY message, unless the device stream has been configured with the NONE SrtpSecurityAlgorithm. + The MIKEY message shall contain the key information for the algorithm that was configured with SetAudioEncoderConfiguration, SetMetadataConfiguration and + SetVideoEncoderConfiguration. + If the device stream has been configured with the NONE algorithm, the media shall be of type RTP/AVP and it shall not contain a MIKEY message. (ONVIF specification) + + + + + When the client is providing the key, it will add a KeyMgmt header + containing the MIKEY with transport type RTP/SAVP in the SETUP. (RFC 4567) + The client may request a different encryption algorithm than what is configured with + SetAudioEncoderConfiguration, SetMetadataConfiguration and + SetVideoEncoderConfiguration for legacy reasons. Newer clients should respect the + encryption algorithm set in the configuration and avoid overriding it in the SETUP + request. The client shall not change the encryption algorithm after the stream has + been started. (ONVIF specification) + RTSP/1.0 +CSeq: 2 +User-Agent: OmnicastRTSPClient/1.0 +Transport: RTP/SAVP/UDP;unicast +KeyMgmt: prot=mikey;uri="";data="AQAFAP1td9ABAADCD1UcAAAAAAoAAdOOGc75XD0BAAAAGAABAQEBE +AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAAC8A" +]]> + The SSRC is a required component for SRTP encryption and shall be specified + during the RTSP session setup. The SSRC shall be provided in the transport header + of the RTSP SETUP response. (RFC 2326 Section 12.39) + +
+
+ Client Re-Keying with MIKEY + + The client may request the use of new keys for stream encryption. The + SET_PARAMETER method shall be used with a MIKEY parameter to set the new + encryption keys. The client shall only send the new key in the MIKEY message, it should not send the current key. The device shall not reset the ROC when changing keys. When + rekeying, the RAND value and the SP (Security Policy) payload may be omitted by + the client. (RFC 3830 section 4.5) + RTSP/1.0 +CSeq: 6 +Session: 15405670 +User-Agent: OmnicastRTSPClient/1.0 +Content-Type: text/parameters +Content-Length: 145 + +mikey: AQAFAGgCr8EBAADSvxgkAAAAAAoAAdOOK7UihqIBAAAAGAABAQEBEAIBAQMBFAcBAQgBAQoBAQsBCgA +AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA +]]> + + +
+
+ Multicast considerations + + When in multicast, multiple RTSP clients shall be able to retrieve changing keys as well as the SSRC and ROC of the stream. + A new GET_PARAMETER request has been added to retrieve the MIKEY. + This MIKEY message shall contain the current ROC, meaning the server cannot send a cached MIKEY message. + When rekeying occurs, multicast clients are notified of the key change via the MKI value and can use the GET_PARAMETER request to retrieve the updated MIKEY message containing the key. (ONVIF specification) + + + Request: + RTSP/1.0 +CSeq: 4 +Session: 15405670 +User-Agent: OmnicastRTSPClient/1.0 +Content-Type: text/parameters +Content-Length: 9 + +mikey +]]> + + Response: + + + + + + When a key is changed, the device shall send an ANNOUNCE containing the MIKEY to all clients in the multicast group. (ONVIF Specification) + + + Request: + RTSP/1.0 +CSeq: 4 +Session: 15405670 +User-Agent: OmnicastRTSPClient/1.0 +Content-Type: text/parameters +Content-Length: 9 + +mikey: AQAFAGrVolgBAADdBcAoAAAAAAsA2/K83QArhBIKEGrVolg1GZvp7DPyFCdYmXABAAAAGwABAQEBEAIBAQM +BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0A +]]> + + +
+
+ Error management + + If an error occurs during the key management, the device shall return a status code 463 Key management failure. (RFC 4567) + +
+
+
+ MulticastAudioDecoder SRTP Packet Format - The following diagram illustrates the structure of an SRTP packet used by the MulticastAudioDecoder. - It includes the RTP header, a header extension carrying the Roll-Over Counter (ROC), the encrypted RTP payload, - and the SRTP authentication tag. The header extension format adheres to the one-byte extension mechanism defined in RFC 8285. - Encryption and authentication are handled via SRTP, as specified in RFC 3711 for AES_CM_128_HMAC_SHA1_80, - and in RFC 7714 for AEAD_AES_128_GCM and AEAD_AES_256_GCM modes. + The following diagram illustrates the structure of an SRTP packet used by the MulticastAudioDecoder. + It includes the RTP header, a header extension carrying the Roll-Over Counter (ROC), the encrypted RTP payload, + and the SRTP authentication tag. The header extension format adheres to the one-byte extension mechanism defined in RFC 8285. + Encryption and authentication are handled via SRTP, as specified in RFC 3711 for AES_CM_128_HMAC_SHA1_80, + and in RFC 7714 for AEAD_AES_128_GCM and AEAD_AES_256_GCM modes.
- Diagram of SRTP packet format with ROC extension - - - - - + Diagram of SRTP packet format with ROC extension + + + + +
SRTP (Informative) When implementing SRTP functionality, implementers should be aware of specific library requirements that may affect packet data handling.
- libsrtp Implementation Considerations - If libsrtp is used for SRTP implementation, proper alignment is required for packet data. The libsrtp library documentation specifies the following alignment assumptions: - - - The srtp_protect method assumes that the RTP packet is aligned on a 32-bit boundary. - - - The srtp_protect_rtcp method assumes that the RTCP packet is aligned on a 32-bit boundary. - - - The srtp_unprotect method assumes that the SRTP packet is aligned on a 32-bit boundary. - - - The srtp_unprotect_rtcp method assumes that the SRTCP packet is aligned on a 32-bit boundary. - - - Implementers should ensure that packet buffers are properly aligned on 32-bit boundaries before passing them to libsrtp functions. Failure to maintain proper alignment may result in performance degradation or runtime errors on some platforms. It is recommended to consult the libsrtp documentation for specific alignment requirements of the version being used. + libsrtp Implementation Considerations + If libsrtp is used for SRTP implementation, proper alignment is required for packet data. The libsrtp library documentation specifies the following alignment assumptions: + + + + The srtp_protect method assumes that the RTP packet is aligned on a 32-bit boundary. + + + + + The srtp_protect_rtcp method assumes that the RTCP packet is aligned on a 32-bit boundary. + + + + + The srtp_unprotect method assumes that the SRTP packet is aligned on a 32-bit boundary. + + + + + The srtp_unprotect_rtcp method assumes that the SRTCP packet is aligned on a 32-bit boundary. + + + + Implementers should ensure that packet buffers are properly aligned on 32-bit boundaries before passing them to libsrtp functions. Failure to maintain proper alignment may result in performance degradation or runtime errors on some platforms. It is recommended to consult the libsrtp documentation for specific alignment requirements of the version being used.
diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index d1737ffa3..abd7b6f5c 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -390,8 +390,8 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Optional element to configure rotation of captured image. What resolutions a device supports shall be unaffected by the Rotate parameters.
If a device is configured with Rotate=AUTO, the device shall take control over the Degree parameter and automatically update it so that a client can query current rotation.
- The device shall automatically apply the same rotation to its pan/tilt control direction depending on the following condition: - if Reverse=AUTO in PTControlDirection or if the device doesn’t support Reverse in PTControlDirection + The device shall automatically apply the same rotation to its pan/tilt control direction depending on the following condition: + if Reverse=AUTO in PTControlDirection or if the device doesn't support Reverse in PTControlDirection @@ -405,7 +405,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Optional element describing the geometric lens distortion. Multiple instances for future variable lens support. - Optional element describing the scene orientation in the camera’s field of view. + Optional element describing the scene orientation in the camera's field of view. @@ -427,8 +427,8 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - When enabled, the video will be flipped horizontally. If applied alongside rotation, the mirror effect shall be executed after the rotation. Additionally,
- when Mirror is enabled and Reverse=Auto is set in PTControlDirection or if the device doesn’t support Reverse in PTControlDirection, the device shall automatically adjust the pan direction. + When enabled, the video will be flipped horizontally. If applied alongside rotation, the mirror effect shall be executed after the rotation. Additionally,
+ when Mirror is enabled and Reverse=Auto is set in PTControlDirection or if the device doesn't support Reverse in PTControlDirection, the device shall automatically adjust the pan direction. @@ -487,8 +487,8 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Offset of the lens center to the imager center in normalized coordinates. - Radial description of the projection characteristics. The resulting curve is defined by the B-Spline interpolation - over the given elements. The element for Radius zero shall not be provided. The projection points shall be ordered with ascending Radius. + Radial description of the projection characteristics. The resulting curve is defined by the B-Spline interpolation + over the given elements. The element for Radius zero shall not be provided. The projection points shall be ordered with ascending Radius. Items outside the last projection Radius shall be assumed to be invisible (black). @@ -615,13 +615,13 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Parameter to assign the way the camera determines the scene orientation. - + - Assigned or determined scene orientation based on the Mode. When assigning the Mode to AUTO, this field - is optional and will be ignored by the device. When assigning the Mode to MANUAL, this field is required - and the device will return an InvalidArgs fault if missing. + Assigned or determined scene orientation based on the Mode. When assigning the Mode to AUTO, this field + is optional and will be ignored by the device. When assigning the Mode to MANUAL, this field is required + and the device will return an InvalidArgs fault if missing. @@ -1079,6 +1079,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Relative value for the video quantizers and the quality of the video. A high value within supported quality range means higher quality + + + Defines the cryptographic algorithm to use as defined by tt:SrtpSecurityAlgorithms + + @@ -1183,6 +1188,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Supported range of encoded bitrate in kbps. + + + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. + + @@ -1380,6 +1390,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The output sample rate in kHz. + + + Defines the cryptographic algorithm to use as defined by tt:SrtpSecurityAlgorithms + + @@ -1405,6 +1420,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO List of supported Sample Rates in kHz for the specified Encoding + + + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. + + @@ -1438,7 +1458,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Optional element to configure the streaming of events. A client might be interested in receiving all, + Optional element to configure the streaming of events. A client might be interested in receiving all, none or some of the events produced by the device:
  • To get all events: Include the Events element but do not include a filter.
  • To get no events: Do not include the Events element.
    • @@ -1462,6 +1482,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The rtsp session timeout for the related audio stream (when using Media2 Service, this value is deprecated and ignored) + + + The cryptographic algorithm used as defined by tt:SrtpSecurityAlgorithms + + @@ -1539,6 +1564,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. + + @@ -2120,8 +2150,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi Defines the RTP payload type used for the audio stream. To ensure compatibility, it is recommended to use dynamic payload types (96 and above), as specified in RFC 3551. - Standard payload types (0-95) should only be used for predefined audio formats matching the audio encoding as defined in - IANA RTP Payload Types, + Standard payload types (0-95) should only be used for predefined audio formats matching the audio encoding as defined in + IANA RTP Payload Types, as using them for non-standard media may lead to unexpected errors or interoperability issues. @@ -2129,7 +2159,7 @@ decoding .A decoder shall decode every data it receives (according to its capabi - Indicates the priority level when multiple configurations are active. + Indicates the priority level when multiple configurations are active. A higher value signifies a higher priority. If several configurations have the same priority value the order between those configurations is undefined. @@ -2276,7 +2306,7 @@ decoding .A decoder shall decode every data it receives (according to its capabi - Optional element for specifying the RTP payload type, + Optional element for specifying the RTP payload type, particularly when it is fixed for a specific audio encoding as defined in IANA RTP Payload Types. @@ -4405,8 +4435,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi 'Bistable' or 'Monostable'
      -
    • Bistable – After setting the state, the relay remains in this state.
      • -
    • Monostable – After setting the state, the relay returns to its idle state after the specified time.
      • +
    • Bistable - After setting the state, the relay remains in this state.
      • +
    • Monostable - After setting the state, the relay returns to its idle state after the specified time.
     @@ -4654,7 +4684,7 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The Pan/Tilt limits element should be present for a PTZ Node that supports an absolute Pan/Tilt. If the element is present it signals the support for configurable Pan/Tilt limits. If limits are enabled, the Pan/Tilt movements shall always stay within the specified range. The Pan/Tilt limits are disabled by setting the limits to –INF or +INF. + The Pan/Tilt limits element should be present for a PTZ Node that supports an absolute Pan/Tilt. If the element is present it signals the support for configurable Pan/Tilt limits. If limits are enabled, the Pan/Tilt movements shall always stay within the specified range. The Pan/Tilt limits are disabled by setting the limits to -INF or +INF. @@ -4905,7 +4935,7 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The Generic Pan/Tilt Position space is provided by every PTZ node that supports absolute Pan/Tilt, since it does not relate to a specific physical range. + The Generic Pan/Tilt Position space is provided by every PTZ node that supports absolute Pan/Tilt, since it does not relate to a specific physical range. Instead, the range should be defined as the full range of the PTZ unit normalized to the range -1 to 1 resulting in the following space description. @@ -4913,8 +4943,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The Generic Zoom Position Space is provided by every PTZ node that supports absolute Zoom, since it does not relate to a specific physical range. - Instead, the range should be defined as the full range of the Zoom normalized to the range 0 (wide) to 1 (tele). + The Generic Zoom Position Space is provided by every PTZ node that supports absolute Zoom, since it does not relate to a specific physical range. + Instead, the range should be defined as the full range of the Zoom normalized to the range 0 (wide) to 1 (tele). There is no assumption about how the generic zoom range is mapped to magnification, FOV or other physical zoom dimension. @@ -4922,8 +4952,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The Generic Pan/Tilt translation space is provided by every PTZ node that supports relative Pan/Tilt, since it does not relate to a specific physical range. - Instead, the range should be defined as the full positive and negative translation range of the PTZ unit normalized to the range -1 to 1, + The Generic Pan/Tilt translation space is provided by every PTZ node that supports relative Pan/Tilt, since it does not relate to a specific physical range. + Instead, the range should be defined as the full positive and negative translation range of the PTZ unit normalized to the range -1 to 1, where positive translation would mean clockwise rotation or movement in right/up direction resulting in the following space description. @@ -4931,9 +4961,9 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The Generic Zoom Translation Space is provided by every PTZ node that supports relative Zoom, since it does not relate to a specific physical range. - Instead, the corresponding absolute range should be defined as the full positive and negative translation range of the Zoom normalized to the range -1 to1, - where a positive translation maps to a movement in TELE direction. The translation is signed to indicate direction (negative is to wide, positive is to tele). + The Generic Zoom Translation Space is provided by every PTZ node that supports relative Zoom, since it does not relate to a specific physical range. + Instead, the corresponding absolute range should be defined as the full positive and negative translation range of the Zoom normalized to the range -1 to1, + where a positive translation maps to a movement in TELE direction. The translation is signed to indicate direction (negative is to wide, positive is to tele). There is no assumption about how the generic zoom range is mapped to magnification, FOV or other physical zoom dimension. This results in the following space description. @@ -4941,8 +4971,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The generic Pan/Tilt velocity space shall be provided by every PTZ node, since it does not relate to a specific physical range. - Instead, the range should be defined as a range of the PTZ unit’s speed normalized to the range -1 to 1, where a positive velocity would map to clockwise + The generic Pan/Tilt velocity space shall be provided by every PTZ node, since it does not relate to a specific physical range. + Instead, the range should be defined as a range of the PTZ unit's speed normalized to the range -1 to 1, where a positive velocity would map to clockwise rotation or movement in the right/up direction. A signed speed can be independently specified for the pan and tilt component resulting in the following space description. @@ -4950,7 +4980,7 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The generic zoom velocity space specifies a zoom factor velocity without knowing the underlying physical model. The range should be normalized from -1 to 1, + The generic zoom velocity space specifies a zoom factor velocity without knowing the underlying physical model. The range should be normalized from -1 to 1, where a positive velocity would map to TELE direction. A generic zoom velocity space description resembles the following. @@ -4958,8 +4988,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The speed space specifies the speed for a Pan/Tilt movement when moving to an absolute position or to a relative translation. - In contrast to the velocity spaces, speed spaces do not contain any directional information. The speed of a combined Pan/Tilt + The speed space specifies the speed for a Pan/Tilt movement when moving to an absolute position or to a relative translation. + In contrast to the velocity spaces, speed spaces do not contain any directional information. The speed of a combined Pan/Tilt movement is represented by a single non-negative scalar value. @@ -4967,8 +4997,8 @@ decoding .A decoder shall decode every data it receives (according to its capabi - The speed space specifies the speed for a Zoom movement when moving to an absolute position or to a relative translation. - In contrast to the velocity spaces, speed spaces do not contain any directional information. + The speed space specifies the speed for a Zoom movement when moving to an absolute position or to a relative translation. + In contrast to the velocity spaces, speed spaces do not contain any directional information. @@ -5516,8 +5546,8 @@ If set to 0.0, infinity will be used. Exposure Mode
      -
    • Auto – Enabled the exposure algorithm on the NVT.
      • -
    • Manual – Disabled exposure algorithm on the NVT.
      • +
    • Auto - Enabled the exposure algorithm on the NVT.
      • +
    • Manual - Disabled exposure algorithm on the NVT.
     @@ -6201,8 +6231,8 @@ If set to 0.0, infinity will be used. Exposure Mode
      -
    • Auto – Enabled the exposure algorithm on the device.
      • -
    • Manual – Disabled exposure algorithm on the device.
      • +
    • Auto - Enabled the exposure algorithm on the device.
      • +
    • Manual - Disabled exposure algorithm on the device.
     @@ -6572,8 +6602,8 @@ If set to 0.0, infinity will be used. Exposure Mode
      -
    • Auto – Enabled the exposure algorithm on the device.
      • -
    • Manual – Disabled exposure algorithm on the device.
      • +
    • Auto - Enabled the exposure algorithm on the device.
      • +
    • Manual - Disabled exposure algorithm on the device.
     @@ -7082,21 +7112,21 @@ If set to 0.0, infinity will be used. - + - + - + Entering represents object coming into the polygon boundary. Exiting represents object going out of the polygon boundary. Approaching represents distance of object to camera sensor decreasing over time. - Departing represents distance of object to camera sensor increasing over time. + Departing represents distance of object to camera sensor increasing over time. @@ -7109,7 +7139,7 @@ If set to 0.0, infinity will be used. - + @@ -8040,8 +8070,8 @@ and sample rate. - Frequency at which the device shall generate a new key to encrypt a new segment. - If not specified, key rotation is disabled. + Frequency at which the device shall generate a new key to encrypt a new segment. + If not specified, key rotation is disabled. KeyRotationDuration must be a positive duration value. @@ -8512,8 +8542,8 @@ and sample rate. - This attribute adds an additional requirement for activating the recording job. - If this optional field is provided the job shall only record if the schedule exists and is active. + This attribute adds an additional requirement for activating the recording job. + If this optional field is provided the job shall only record if the schedule exists and is active. @@ -8976,7 +9006,7 @@ and sample rate. Indicates audio class label - +     A likelihood/probability that the corresponding audio event belongs to this class. The sum of the likelihoods shall NOT exceed 1 @@ -9496,9 +9526,9 @@ and sample rate. - + - + diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 670b0daf3..6496f997d 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -804,7 +804,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -2266,7 +2266,9 @@ support streaming video data of such a profile.
    • RtspUnicast RTSP streaming RTP as UDP Unicast.
    • RtspMulticast RTSP streaming RTP as UDP Multicast.
      • -
    • RTSP RTSP streaming RTP over TCP.
      • +
    • RtspsUnicast Secure RTSP streaming with SRTP as UDP Unicast.
      • +
    • RtspsMulticast Secure RTSP streaming with SRTP as UDP Multicast.
      • +
    • RTSP RTSP streaming RTP over TCP.
    • RtspOverHttp Tunneling both the RTSP control channel and the RTP stream over HTTP or HTTPS.
    If a multicast stream is requested at least one of VideoEncoder2Configuration, AudioEncoder2Configuration and MetadataConfiguration shall have a valid multicast setting.