From 0a009bf3074694e4c0ca749a0f3c3fc73dc2babf Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Mon, 14 Apr 2025 14:57:45 -0400 Subject: [PATCH 01/50] Added capabilities and configuration for the SRTP algorithm --- .gitignore | 1 + wsdl/ver10/schema/onvif.xsd | 59 ++++++++++++++++++++++++++++++++ wsdl/ver20/media/wsdl/media.wsdl | 2 ++ 3 files changed, 62 insertions(+) diff --git a/.gitignore b/.gitignore index 743328ec1..2178e36cd 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ *.dia~ +/.vs diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index c2a285338..a0c498ba4 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -710,6 +710,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The rtsp session timeout for the related video stream + + + The cryptographic algorithm used as defined by tr2:SrtpSecurityAlgorithms + + @@ -846,6 +851,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 tr2:SrtpSecurityAlgorithms. + + @@ -1005,6 +1015,15 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + + + @@ -1059,6 +1078,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 tr2:SrtpSecurityAlgorithms + + @@ -1156,6 +1180,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 tr2:SrtpSecurityAlgorithms. + + @@ -1260,6 +1289,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 + + + The cryptographic algorithm used as defined by tr2:SrtpSecurityAlgorithms + + @@ -1303,6 +1337,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 tr2:SrtpSecurityAlgorithms. + + @@ -1348,6 +1387,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 tr2:SrtpSecurityAlgorithms + + @@ -1373,6 +1417,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 tr2:SrtpSecurityAlgorithms. + + @@ -1430,6 +1479,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 tr2:SrtpSecurityAlgorithms + + @@ -1507,6 +1561,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 tr2:SrtpSecurityAlgorithms. + + diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 93a3e1426..026446df5 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -1814,6 +1814,8 @@ support streaming video data of such a profile.
  • RtspUnicast RTSP streaming RTP as UDP Unicast.
  • RtspMulticast RTSP streaming RTP as UDP Multicast.
    • +
  • 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.
From ee2e1a189b893ccf584b259a6d7e5c602777dfb8 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Fri, 30 May 2025 14:11:03 -0400 Subject: [PATCH 02/50] AES-GCM Streaming xml first draft. --- doc/Streaming.xml | 247 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 244 insertions(+), 3 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a680744cb..3ce802c1e 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -235,8 +235,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 @@ -381,6 +380,22 @@ + + MIKEY + + + Multimedia Internet KEYing + + + + + MKI + + + Master Key Identifier + + + MPEG-4 @@ -590,7 +605,233 @@
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. + This mode allows secure transmission of RTP packets via UDP unicast and multicast. Related documents are RFC 3711, RFC 7714 for transmission and RFC 3830, RFC 4567 for key exchange. + + The device must list whether or not it supports SRTP streaming through the GetServiceCapabilities action's response. If the device supports SRTP streaming, the device must indicate it through the SecureRTSPStreaming parameter in the StreamingCapabilities. + +
+ Cryptographic algorithm negotiation + + The device may list which SRTP cryptographic algorithms it supports through the Media2 wsdl. + Each encoder can list the algorithms it supports through the SecureStreamingProtocolAlgorithms element present in: + + + AudioEncoder2ConfigurationOptions + + + VideoEncoder2ConfigurationOptions + + + MetadataConfigurationOptions + + + + If the SecureStreamingProtocolAlgorithms parameter is present, the device must support a least one of the following algorithms: + + + NONE + NONE is a special case, where the media is listed as RTP/AVP instead of RTP/SAVP and where MIKEY is unused altogether. + This it to allow the use of RTSPS without using an SRTP encrypted media stream. + + + AES_CM_128_HMAC_SHA1_80 + + + AEAD_AES_128_GCM + + + AEAD_AES_256_GCM + + + If the device supports SRTP streaming through the SecureRTSPStreaming parameter, but does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. + + + + The client may choose to configure a device to use a specific algorithm. To do so, it must set the SecureStreamingProtocolAlgorithm attribute through the following actions: + + + SetAudioEncoder2Configuration + + + SetVideoEncoder2Configuration + + + SetMetadataConfiguration + + + + + + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support the ConfigurationOptions and the actions listed above. + This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. + + + + 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. + + + The MIKEY message must contain the following payloads: + + + 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 must be concatenated and sent in the Key data section of the payload. + If the key type is TEK+SALT and a salt must be provided, the SALT must be in the Salt data section. + The device and client must support TEK for AES_CM_128_SHA1_80 and TEK+SALT for other encryption algorithms. + To keep track of key validity, The SPI/MKI must be set in the KV data. Each SRTP packet must include the MKI. + + + Security Policy Payload + + Specifies the encryption parameters to be used by the streams. + + + AES_CM_128_HMAC_SHA1_80 + Encryption Algorithm: AES-CM + Session Encryption Key Length: 128 bits + Authentication Algorithm: HMAC-SHA-1 + Session Auth Key Length: 160 bits + Session Salt Key Length: 112 bits + SRTP Encryption: On + SRTCP Encryption: On + Authnetication Tag Length: 80 bits + SRTP PRF: AES-CM + + + AEAD_AES_128_GCM + Encryption Algorithm: AES-GCM + Session Encryption Key Length: 128 bits + Authentication Algorithm: NULL + Session Auth Key Length: N/A + Session Salt Key Length: 96 bits + SRTP Encryption: On + SRTCP Encryption: On + AEAD Authnetication Tag Length: 16 octets + SRTP PRF: AES-CM + + + AEAD_AES_256_GCM + Encryption Algorithm: AES-GCM + Session Encryption Key Length: 256 bits + Authentication Algorithm: NULL + Session Auth Key Length: N/A + Session Salt Key Length: 96 bits + SRTP Encryption: On + SRTCP Encryption: On + AEAD Authnetication Tag Length: 16 octets + SRTP PRF: AES-CM + + + + + + + +
+ Key management through RTSP + + The key management extensions for SDP and RTSP (RFC 4567) allow for key management through RTSP. + +
+ 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. + It's permitted to have two media fields, one with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted stream. + + + + When the client is providing the key, it will add a KeyMgmt header containing the MIKEY with transport type RTP/SAVP in the SETUP. + The client may 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 may not change the encryption algorithm after the stream has been started. + 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" +]]> + +
+
+ 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 device must not reset the ROC when changing keys. + 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 must be able to retreive changing keys as well as the SSRC and ROC of the stream. + A new GET_PARAMETER request has been added to retreive the MIKEY, which must contain the SSRC and ROC. + + + Request: + RTSP/1.0 +CSeq: 4 +Session: 15405670 +User-Agent: OmnicastRTSPClient/1.0 +Content-Type: text/parameters +Content-Length: 9 + +mikey +]]> + + + Response: + + + +
+
+ Error management + + If an error occurs during the key management, the device must return an status code 463 Key management failure as defined in RFC 4567. + +
+
+ +
RTP/RTSP/HTTP/TCP From 8c4fb58ce6b6d7fb798183d02f005e613c870512 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Fri, 30 May 2025 15:13:44 -0400 Subject: [PATCH 03/50] Added SSRC clarification and onvif-mgmt attribute --- doc/Streaming.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 3ce802c1e..0330df094 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -745,6 +745,7 @@ When the device is providing the key, the SDP is required to have a media of type RTP/SAVP and a MIKEY message. It's permitted to have two media fields, one with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted stream. + The device may advertise that it supports the key management defined in this specification by adding the onvif-mgmt attribute to the SDP. + + The SSRC is a required component for SRTP encryption and must be specified during the RTSP session setup. + The SSRC shall be provided in the transport header of the RTSP SETUP response as described in RFC 2326 Section 12.39. +
Client Re-Keying with MIKEY From e643c7e6ec4cc9e10b05c69532965d25b142b216 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Mon, 2 Jun 2025 16:50:08 -0400 Subject: [PATCH 04/50] Added clarifications to MIKEY and fixed typos --- doc/Streaming.xml | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 0330df094..bbb862982 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -626,7 +626,7 @@ - If the SecureStreamingProtocolAlgorithms parameter is present, the device must support a least one of the following algorithms: + If the SecureStreamingProtocolAlgorithms parameter is present, the device must support at least one of the following algorithms: NONE @@ -647,7 +647,7 @@ - The client may choose to configure a device to use a specific algorithm. To do so, it must set the SecureStreamingProtocolAlgorithm attribute through the following actions: + The client may choose to configure a device to use a specific algorithm. To do so, it must set the SecureStreamingProtocolAlgorithm attribute through the following methods: SetAudioEncoder2Configuration @@ -662,7 +662,7 @@ - If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support the ConfigurationOptions and the actions listed above. + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support the ConfigurationOptions and the methods listed above. This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. @@ -736,6 +736,7 @@ Key management through RTSP The key management extensions for SDP and RTSP (RFC 4567) allow for key management through RTSP. + Note: All MIKEY messages must not contain line breaks. The examples below are formatted for readability.
Stream Initialization @@ -745,7 +746,7 @@ When the device is providing the key, the SDP is required to have a media of type RTP/SAVP and a MIKEY message. It's permitted to have two media fields, one with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted stream. - The device may advertise that it supports the key management defined in this specification by adding the onvif-mgmt attribute to the SDP. + The device may advertise that it supports the key management defined in this specification by adding the onvif-keymgmt attribute to the SDP. 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 SET_PARAMETER method shall be used with a MIKEY parameter to set the new encryption keys. The device must not reset the ROC when changing keys. + When rekeying, the RAND value and the SP (Security Policy) payload may be omitted by the client. RTSP/1.0 CSeq: 6 Session: 15405670 @@ -803,8 +805,9 @@ AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA
Multicast considerations - When in multicast, multiple RTSP clients must be able to retreive changing keys as well as the SSRC and ROC of the stream. - A new GET_PARAMETER request has been added to retreive the MIKEY, which must contain the SSRC and ROC. + When in multicast, multiple RTSP clients must 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 must contain the current ROC, meaning the server cannot send a cached MIKEY message. Request: @@ -832,7 +835,7 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0
Error management - If an error occurs during the key management, the device must return an status code 463 Key management failure as defined in RFC 4567. + If an error occurs during the key management, the device must return a status code 463 Key management failure as defined in RFC 4567.
From 2d9394a282545d4ec0cc5448ac2863a5796c91f7 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Mon, 2 Jun 2025 16:52:04 -0400 Subject: [PATCH 05/50] Added additional clarification to RAND value and the SP payload --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index bbb862982..163a2cbbe 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -788,7 +788,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA 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 device must not reset the ROC when changing keys. - When rekeying, the RAND value and the SP (Security Policy) payload may be omitted by the client. + When rekeying, the RAND value and the SP (Security Policy) payload may be omitted by the client as defined in RFC 3830 section 4.5. RTSP/1.0 CSeq: 6 Session: 15405670 From c5a1b7fd587319e58f3c55f46e4c128f830fec5a Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Mon, 16 Jun 2025 12:07:10 -0400 Subject: [PATCH 06/50] Replaced must with shall. --- doc/Streaming.xml | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 163a2cbbe..a0b6702f8 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -607,7 +607,7 @@ SRTP data transfer via UDP This mode allows secure transmission of RTP packets via UDP unicast and multicast. Related documents are RFC 3711, RFC 7714 for transmission and RFC 3830, RFC 4567 for key exchange. - The device must list whether or not it supports SRTP streaming through the GetServiceCapabilities action's response. If the device supports SRTP streaming, the device must indicate it through the SecureRTSPStreaming parameter in the StreamingCapabilities. + The device shall list whether or not it supports SRTP streaming through the GetServiceCapabilities action's response. If the device supports SRTP streaming, the device shall indicate it through the SecureRTSPStreaming parameter in the StreamingCapabilities.
Cryptographic algorithm negotiation @@ -626,7 +626,7 @@ - If the SecureStreamingProtocolAlgorithms parameter is present, the device must support at least one of the following algorithms: + If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: NONE @@ -647,7 +647,7 @@ - The client may choose to configure a device to use a specific algorithm. To do so, it must set the SecureStreamingProtocolAlgorithm attribute through the following methods: + The client may choose to configure a device to use a specific algorithm. To do so, it shall set the SecureStreamingProtocolAlgorithm attribute through the following methods: SetAudioEncoder2Configuration @@ -662,7 +662,7 @@ - If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support the ConfigurationOptions and the methods listed above. + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it shall also support the ConfigurationOptions and the methods listed above. This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. @@ -672,7 +672,7 @@ MIKEY-PK should not be used for ONVIF SRTP. - The MIKEY message must contain the following payloads: + The MIKEY message shall contain the following payloads: Common Header Payload @@ -680,10 +680,10 @@ 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 must be concatenated and sent in the Key data section of the payload. - If the key type is TEK+SALT and a salt must be provided, the SALT must be in the Salt data section. - The device and client must support TEK for AES_CM_128_SHA1_80 and TEK+SALT for other encryption algorithms. - To keep track of key validity, The SPI/MKI must be set in the KV data. Each SRTP packet must include the MKI. + 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. + 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_SHA1_80 and TEK+SALT for other encryption algorithms. + To keep track of key validity, The SPI/MKI shall be set in the KV data. Each SRTP packet shall include the MKI. Security Policy Payload @@ -778,7 +778,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA ]]> - The SSRC is a required component for SRTP encryption and must be specified during the RTSP session setup. + 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 as described in RFC 2326 Section 12.39.
@@ -787,7 +787,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA 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 device must not reset the ROC when changing keys. + 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 as defined in RFC 3830 section 4.5. RTSP/1.0 CSeq: 6 @@ -805,9 +805,9 @@ AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA
Multicast considerations - When in multicast, multiple RTSP clients must be able to retrieve changing keys as well as the SSRC and ROC of the stream. + 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 must contain the current ROC, meaning the server cannot send a cached MIKEY message. + This MIKEY message shall contain the current ROC, meaning the server cannot send a cached MIKEY message. Request: @@ -835,7 +835,7 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0
Error management - If an error occurs during the key management, the device must return a status code 463 Key management failure as defined in RFC 4567. + If an error occurs during the key management, the device shall return a status code 463 Key management failure as defined in RFC 4567.
From 95537d15528004de049b4f9a45a12f2a369ed29c Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Tue, 17 Jun 2025 09:39:29 -0400 Subject: [PATCH 07/50] Changed bits to octets in Security Policy Payload --- doc/Streaming.xml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a0b6702f8..b45e4b326 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -693,37 +693,37 @@ AES_CM_128_HMAC_SHA1_80 Encryption Algorithm: AES-CM - Session Encryption Key Length: 128 bits + Session Encryption Key Length: 16 octets Authentication Algorithm: HMAC-SHA-1 - Session Auth Key Length: 160 bits - Session Salt Key Length: 112 bits + Session Auth Key Length: 20 octets + Session Salt Key Length: 14 octets SRTP Encryption: On SRTCP Encryption: On - Authnetication Tag Length: 80 bits + Authentication Tag Length: 10 octets SRTP PRF: AES-CM AEAD_AES_128_GCM Encryption Algorithm: AES-GCM - Session Encryption Key Length: 128 bits + Session Encryption Key Length: 16 octets Authentication Algorithm: NULL Session Auth Key Length: N/A - Session Salt Key Length: 96 bits + Session Salt Key Length: 12 octets SRTP Encryption: On SRTCP Encryption: On - AEAD Authnetication Tag Length: 16 octets + AEAD Authentication Tag Length: 16 octets SRTP PRF: AES-CM AEAD_AES_256_GCM Encryption Algorithm: AES-GCM - Session Encryption Key Length: 256 bits + Session Encryption Key Length: 32 octets Authentication Algorithm: NULL Session Auth Key Length: N/A - Session Salt Key Length: 96 bits + Session Salt Key Length: 12 octets SRTP Encryption: On SRTCP Encryption: On - AEAD Authnetication Tag Length: 16 octets + AEAD Authentication Tag Length: 16 octets SRTP PRF: AES-CM From 5ccde48e3ec0be5e1585724d4435f47feee7abc7 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Tue, 17 Jun 2025 10:32:59 -0400 Subject: [PATCH 08/50] Fixed typo --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index b45e4b326..ac6d134f7 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -766,7 +766,7 @@ a=control:rtsp://movie.example.com/action/rtp_video When the client is providing the key, it will add a KeyMgmt header containing the MIKEY with transport type RTP/SAVP in the SETUP. - The client may a different encryption algorithm than what is configured with SetAudioEncoderConfiguration, SetMetadataConfiguration and SetVideoEncoderConfiguration for legacy reasons. + 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 may not change the encryption algorithm after the stream has been started. RTSP/1.0 From 7359f163b01cc58b690545e46b9758ee1c855119 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:27:43 -0400 Subject: [PATCH 09/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index a0c498ba4..ebf215f28 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -712,7 +712,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - The cryptographic algorithm used as defined by tr2:SrtpSecurityAlgorithms + The cryptographic algorithm used as defined by tt:SrtpSecurityAlgorithms From dff3305eaaae766218e948999ebbe7d7791bbfd2 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:27:53 -0400 Subject: [PATCH 10/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index ebf215f28..7a0b4bb44 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -853,7 +853,7 @@ 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 tr2:SrtpSecurityAlgorithms. + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. From bbd28eb1474940edc31d0b172558a91f7aa16057 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:28:05 -0400 Subject: [PATCH 11/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 7a0b4bb44..74ae10494 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1080,7 +1080,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms + Defines the cryptographic algorithm to use as defined by tt:SrtpSecurityAlgorithms From 3b5b77aeda4513a620bd4a213db7d6ba9e6b376c Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:28:16 -0400 Subject: [PATCH 12/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 74ae10494..592871356 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1182,7 +1182,7 @@ 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 tr2:SrtpSecurityAlgorithms. + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. From e553ca1620e7b9cc594c11f55f662edb5cc03ea9 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:28:25 -0400 Subject: [PATCH 13/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 592871356..78df04d9a 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1291,7 +1291,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - The cryptographic algorithm used as defined by tr2:SrtpSecurityAlgorithms + The cryptographic algorithm used as defined by tt:SrtpSecurityAlgorithms From 7eae5a8c208f003bbe1f70e57e300d57e94f7621 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:28:31 -0400 Subject: [PATCH 14/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 78df04d9a..f1f79b7d7 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1339,7 +1339,7 @@ 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 tr2:SrtpSecurityAlgorithms. + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. From ea03dc5c108532d14483741586e81703a8ab3b07 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:30:16 -0400 Subject: [PATCH 15/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index f1f79b7d7..554d5c09b 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1419,7 +1419,7 @@ 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 tr2:SrtpSecurityAlgorithms. + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. From 99e8b31c9ff64ff885e159d3d5bfaab19b855a36 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:30:42 -0400 Subject: [PATCH 16/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 554d5c09b..143e98b61 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1481,7 +1481,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - The cryptographic algorithm used as defined by tr2:SrtpSecurityAlgorithms + The cryptographic algorithm used as defined by tt:SrtpSecurityAlgorithms From 6fd6e57a1c5428f9679205b37dfb62384957b230 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:33:03 -0400 Subject: [PATCH 17/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 143e98b61..826fb8d3d 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1563,7 +1563,7 @@ 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 tr2:SrtpSecurityAlgorithms. + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms. From 9df24f047aa3fcd12f6124bd311a968f80b23490 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Tue, 17 Jun 2025 11:34:12 -0400 Subject: [PATCH 18/50] Update wsdl/ver10/schema/onvif.xsd Co-authored-by: Sriram Bhetanabottla --- wsdl/ver10/schema/onvif.xsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 826fb8d3d..21a3f04cb 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1389,7 +1389,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms + Defines the cryptographic algorithm to use as defined by tt:SrtpSecurityAlgorithms From 46396ae289b88ed2a6d4990f0e47b33b8c5c465c Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Tue, 17 Jun 2025 15:25:35 -0400 Subject: [PATCH 19/50] Added clarification for RTSPS interleaved with encryption type "NONE" --- doc/Streaming.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index ac6d134f7..4adedf172 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -631,7 +631,10 @@ NONE NONE is a special case, where the media is listed as RTP/AVP instead of RTP/SAVP and where MIKEY is unused altogether. - This it to allow the use of RTSPS without using an SRTP encrypted media stream. + + This it 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 From b66ae674ded625d106f1901c33a0e19f70938877 Mon Sep 17 00:00:00 2001 From: Sriram Bhetanabottla Date: Thu, 19 Jun 2025 14:08:01 +0200 Subject: [PATCH 20/50] fixed docbook xml validation error (#599) * fixed docbook xml validation error * removed extra spacing * removed redundant spacing in CDATA --- doc/Streaming.xml | 228 +++++++++++++++++++++------------------------- 1 file changed, 105 insertions(+), 123 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 4adedf172..d185dc20c 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -606,15 +606,15 @@
SRTP data transfer via UDP This mode allows secure transmission of RTP packets via UDP unicast and multicast. Related documents are RFC 3711, RFC 7714 for transmission and RFC 3830, RFC 4567 for key exchange. - - The device shall list whether or not it supports SRTP streaming through the GetServiceCapabilities action's response. If the device supports SRTP streaming, the device shall indicate it through the SecureRTSPStreaming parameter in the StreamingCapabilities. - + The device shall list whether or not it supports SRTP streaming through the + GetServiceCapabilities action's response. If the device supports SRTP streaming, the + device shall indicate it through the SecureRTSPStreaming parameter in the + StreamingCapabilities.
Cryptographic algorithm negotiation - - The device may list which SRTP cryptographic algorithms it supports through the Media2 wsdl. - Each encoder can list the algorithms it supports through the SecureStreamingProtocolAlgorithms element present in: - + The device may list which SRTP cryptographic algorithms it supports through the + Media2 wsdl. Each encoder can list the algorithms it supports through the + SecureStreamingProtocolAlgorithms element present in: AudioEncoder2ConfigurationOptions @@ -624,17 +624,15 @@ MetadataConfigurationOptions - - - If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: - + If the SecureStreamingProtocolAlgorithms parameter is present, the + device shall support at least one of the following algorithms: NONE - NONE is a special case, where the media is listed as RTP/AVP instead of RTP/SAVP and where MIKEY is unused altogether. - - This it 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. - + NONE is a special case, where the media is listed as RTP/AVP instead of + RTP/SAVP and where MIKEY is unused altogether. + This it 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 @@ -645,13 +643,14 @@ AEAD_AES_256_GCM - - If the device supports SRTP streaming through the SecureRTSPStreaming parameter, but does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. - + If the device supports SRTP streaming through the SecureRTSPStreaming + parameter, but does not list any supported SRTP cryptographic algorithms through the + SecureStreamingProtocolAlgorithms parameter, the device shall support the + AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. - - The client may choose to configure a device to use a specific algorithm. To do so, it shall set the SecureStreamingProtocolAlgorithm attribute through the following methods: - + The client may choose to configure a device to use a specific algorithm. To do + so, it shall set the SecureStreamingProtocolAlgorithm attribute through the following + methods: SetAudioEncoder2Configuration @@ -661,8 +660,7 @@ SetMetadataConfiguration - - + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it shall also support the ConfigurationOptions and the methods listed above. @@ -674,83 +672,81 @@ 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. - - The MIKEY message shall contain the following payloads: - + The MIKEY message shall contain the following payloads: 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. - 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_SHA1_80 and TEK+SALT for other encryption algorithms. - To keep track of key validity, The SPI/MKI shall be set in the KV data. Each SRTP packet shall include the MKI. + 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. + 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_SHA1_80 and TEK+SALT + for other encryption algorithms. + To keep track of key validity, The SPI/MKI shall be set in the KV data. Each + SRTP packet shall include the MKI. Security Policy Payload - - Specifies the encryption parameters to be used by the streams. - - - AES_CM_128_HMAC_SHA1_80 - 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 - 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 - 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 - - - + Specifies the encryption parameters to be used by the streams. + + AES_CM_128_HMAC_SHA1_80 + 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 + 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 + 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) allow for key management through RTSP. - Note: All MIKEY messages must not contain line breaks. The examples below are formatted for readability. - + The key management extensions for SDP and RTSP (RFC 4567) allow for key + management through RTSP. Note: All MIKEY messages must not contain line breaks. The + examples below are formatted 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. - It's permitted to have two media fields, one with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted stream. - The device may advertise that it supports the key management defined in this specification by adding the onvif-keymgmt attribute to the SDP. - 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. It's permitted to have two media fields, one + with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted + stream. The device may advertise that it supports the key management defined in + this specification by adding the onvif-keymgmt attribute to + the SDP. - - - When the client is providing the key, it will add a KeyMgmt header containing the MIKEY with transport type RTP/SAVP in the SETUP. - 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 may not change the encryption algorithm after the stream has been started. - RTSP/1.0 +]]> + When the client is providing the key, it will add a KeyMgmt header + containing the MIKEY with transport type RTP/SAVP in the SETUP. 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 may not change the encryption algorithm after the stream has + been started. 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 as described in RFC 2326 Section 12.39. - +]]> 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 as described in 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 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 as defined in RFC 3830 section 4.5. - RTSP/1.0 + 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 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 as defined in RFC 3830 section 4.5. RTSP/1.0 CSeq: 6 Session: 15405670 User-Agent: OmnicastRTSPClient/1.0 @@ -801,9 +794,7 @@ Content-Length: 145 mikey: AQAFAGgCr8EBAADSvxgkAAAAAAoAAdOOK7UihqIBAAAAGAABAQEBEAIBAQMBFAcBAQgBAQoBAQsBCgA AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA -]]> - - +]]>
Multicast considerations @@ -812,9 +803,7 @@ AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA 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. - - Request: - RTSP/1.0 + Request: RTSP/1.0 CSeq: 4 Session: 15405670 User-Agent: OmnicastRTSPClient/1.0 @@ -822,18 +811,12 @@ Content-Type: text/parameters Content-Length: 9 mikey -]]> - - - Response: - Response: - - +]]>
Error management @@ -842,7 +825,6 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0
-
From 2d1091ba9e377b3a505f56fde67f2e141382c1bc Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Tue, 22 Jul 2025 11:40:47 -0400 Subject: [PATCH 21/50] AES-GCM code review comments on formatting and clarifications --- doc/Streaming.xml | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 4adedf172..6ecf5f9ac 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -607,13 +607,12 @@ SRTP data transfer via UDP This mode allows secure transmission of RTP packets via UDP unicast and multicast. Related documents are RFC 3711, RFC 7714 for transmission and RFC 3830, RFC 4567 for key exchange. - The device shall list whether or not it supports SRTP streaming through the GetServiceCapabilities action's response. If the device supports SRTP streaming, the device shall indicate it through the SecureRTSPStreaming parameter in the StreamingCapabilities. - + The device shall indicate SRTP streaming support through the SecureRTSPStreaming parameter within StreamingCapabilities in the GetServiceCapabilities response. +
Cryptographic algorithm negotiation - The device may list which SRTP cryptographic algorithms it supports through the Media2 wsdl. - Each encoder can list the algorithms it supports through the SecureStreamingProtocolAlgorithms element present in: + 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: AudioEncoder2ConfigurationOptions @@ -646,17 +645,27 @@ AEAD_AES_256_GCM - If the device supports SRTP streaming through the SecureRTSPStreaming parameter, but does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. + If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. - The client may choose to configure a device to use a specific algorithm. To do so, it shall set the SecureStreamingProtocolAlgorithm attribute through the following methods: + If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80 (as specified in RFC 3711), it shall: + + + Provide a list of the supported algorithms through the ConfigurationOptions structure. + + + Allow a specific algorithm to be configured using the SecureStreamingProtocolAlgorithm attribute. + + + + The specific algorithim shall be configurable through the following methods: - SetAudioEncoder2Configuration + SetAudioEncoderConfiguration - SetVideoEncoder2Configuration + SetVideoEncoderConfiguration SetMetadataConfiguration @@ -665,7 +674,6 @@ - If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it shall also support the ConfigurationOptions and the methods listed above. This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. From 644296815b58df558ff4f72590ce316d79f08fea Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Tue, 22 Jul 2025 11:51:56 -0400 Subject: [PATCH 22/50] Added PRF and KEMAC in abbreviations list --- doc/Streaming.xml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 15f5baa43..8c3b1dace 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -379,6 +379,14 @@ Joint Photographic Expert Group + + + KEMAC + + + Key Encryption and Message Authentication Code + + MIKEY @@ -403,6 +411,14 @@ Moving Picture Experts Group - 4 + + + PRF + + + Pseudo-Random Function + + PTZ From 170f478545cb4e7fec668e4a28498feb1cc5a01d Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Mon, 18 Aug 2025 15:28:09 -0400 Subject: [PATCH 23/50] Removed new SRTP methods for media 1 --- wsdl/ver10/schema/onvif.xsd | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 21a3f04cb..5e8cd5905 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -710,11 +710,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The rtsp session timeout for the related video stream - - - The cryptographic algorithm used as defined by tt:SrtpSecurityAlgorithms - - @@ -851,11 +846,6 @@ 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. - - @@ -1289,11 +1279,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The rtsp session timeout for the related audio stream - - - The cryptographic algorithm used as defined by tt:SrtpSecurityAlgorithms - - @@ -1336,12 +1321,7 @@ 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. - - + > From e5324e984cc1e7f9a97139d0c5523f31b56c4c6d Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Tue, 19 Aug 2025 09:56:26 -0400 Subject: [PATCH 24/50] Added footnotes --- doc/Streaming.xml | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 8c3b1dace..8395cab05 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -628,7 +628,7 @@
Cryptographic algorithm negotiation - 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: + 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 @@ -642,7 +642,7 @@ If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: - NONE + NONE NONE is a special case, where the media is listed as RTP/AVP instead of RTP/SAVP and where MIKEY is unused altogether. This it to allow the use of RTSPS without using an SRTP encrypted media @@ -650,20 +650,20 @@ same TLS protected channel as the RTSP control messages. - AES_CM_128_HMAC_SHA1_80 + AES_CM_128_HMAC_SHA1_80As defined in RFC 3711. - AEAD_AES_128_GCM + AEAD_AES_128_GCMAs defined in RFC 7714. - AEAD_AES_256_GCM + AEAD_AES_256_GCM If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. - If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80 (as specified in RFC 3711), it shall: + If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80 (as specified in RFC 3711), it shall: Provide a list of the supported algorithms through the ConfigurationOptions structure. @@ -691,9 +691,9 @@ - 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. + 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. The MIKEY message shall contain the following payloads: @@ -709,15 +709,15 @@ 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_SHA1_80 and TEK+SALT - for other encryption algorithms. + for other encryption algorithms. To keep track of key validity, The SPI/MKI shall be set in the KV data. Each - SRTP packet shall include the MKI. + SRTP packet shall include the MKI. Security Policy Payload Specifies the encryption parameters to be used by the streams. - AES_CM_128_HMAC_SHA1_80 + AES_CM_128_HMAC_SHA1_80 Encryption Algorithm: AES-CM Session Encryption Key Length: 16 octets Authentication Algorithm: HMAC-SHA-1 @@ -729,7 +729,7 @@ SRTP PRF: AES-CM - AEAD_AES_128_GCM + AEAD_AES_128_GCM Encryption Algorithm: AES-GCM Session Encryption Key Length: 16 octets Authentication Algorithm: NULL @@ -741,7 +741,7 @@ SRTP PRF: AES-CM - AEAD_AES_256_GCM + AEAD_AES_256_GCM Encryption Algorithm: AES-GCM Session Encryption Key Length: 32 octets Authentication Algorithm: NULL From ab71b900f8d87b710ce3c20fcec9f7b92fcfacc2 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Wed, 20 Aug 2025 14:06:51 -0400 Subject: [PATCH 25/50] Added footnotes --- doc/Streaming.xml | 49 +++++++++++++++++++++++++---------------------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 8395cab05..55c1ed2aa 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -628,7 +628,7 @@
Cryptographic algorithm negotiation - 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. + 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 @@ -642,7 +642,7 @@ If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: - NONE + NONEONVIF 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 it to allow the use of RTSPS without using an SRTP encrypted media @@ -650,20 +650,20 @@ same TLS protected channel as the RTSP control messages. - AES_CM_128_HMAC_SHA1_80As defined in RFC 3711. + AES_CM_128_HMAC_SHA1_80As defined in RFC 3711. - AEAD_AES_128_GCMAs defined in RFC 7714. + AEAD_AES_128_GCMAs defined in RFC 7714. - AEAD_AES_256_GCM + AEAD_AES_256_GCMAs defined in RFC 7714. If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. - If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80 (as specified in RFC 3711), it shall: + If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80, it shall:ONVIF specification. Provide a list of the supported algorithms through the ConfigurationOptions structure. @@ -693,9 +693,10 @@ 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. + MIKEY-PK should not be used for ONVIF SRTP.ONVIF specification. - The MIKEY message shall contain the following payloads: + The MIKEY message shall contain the following payloads:RFC 3830 MIKEY specification. + Common Header Payload @@ -705,19 +706,19 @@ 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. + 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_SHA1_80 and TEK+SALT - for other encryption algorithms. + 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. + 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 + AES_CM_128_HMAC_SHA1_80As defined in RFC 3711. Encryption Algorithm: AES-CM Session Encryption Key Length: 16 octets Authentication Algorithm: HMAC-SHA-1 @@ -729,7 +730,7 @@ SRTP PRF: AES-CM - AEAD_AES_128_GCM + AEAD_AES_128_GCMAs defined in RFC 7714. Encryption Algorithm: AES-GCM Session Encryption Key Length: 16 octets Authentication Algorithm: NULL @@ -741,7 +742,7 @@ SRTP PRF: AES-CM - AEAD_AES_256_GCM + AEAD_AES_256_GCMAs defined in RFC 7714. Encryption Algorithm: AES-GCM Session Encryption Key Length: 32 octets Authentication Algorithm: NULL @@ -757,7 +758,7 @@
Key management through RTSP - The key management extensions for SDP and RTSP (RFC 4567) allow for key + The key management extensions for SDP and RTSP (RFC 4567) allows for key management through RTSP. Note: All MIKEY messages must not contain line breaks. The examples below are formatted for readability.
@@ -769,7 +770,8 @@ with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted stream. The device may advertise that it supports the key management defined in this specification by adding the onvif-keymgmt attribute to - the SDP. 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. The client may - request a different encryption algorithm than what is configured with + containing the MIKEY with transport type RTP/SAVP in the SETUP.As defined in 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 may not change the encryption algorithm after the stream has - been started. RTSP/1.0 + been started.ONVIF specification. + RTSP/1.0 CSeq: 2 User-Agent: OmnicastRTSPClient/1.0 Transport: RTP/SAVP/UDP;unicast @@ -800,7 +803,7 @@ KeyMgmt: prot=mikey;uri="";data="AQAFAP1td9ABAADCD1UcAAAAAAoAAdOOGc75XD0BAAAAGAA 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 as described in RFC 2326 Section 12.39. + of the RTSP SETUP response.As described in RFC 2326 Section 12.39.
Client Re-Keying with MIKEY @@ -808,7 +811,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA SET_PARAMETER method shall be used with a MIKEY parameter to set the new encryption keys. 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 as defined in RFC 3830 section 4.5. RTSP/1.0 + the client.As defined in RFC 3830 section 4.5. RTSP/1.0 CSeq: 6 Session: 15405670 User-Agent: OmnicastRTSPClient/1.0 @@ -824,7 +827,7 @@ AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA 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. + This MIKEY message shall contain the current ROC, meaning the server cannot send a cached MIKEY message.ONVIF specification. Request: RTSP/1.0 CSeq: 4 @@ -844,7 +847,7 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0
Error management - If an error occurs during the key management, the device shall return a status code 463 Key management failure as defined in RFC 4567. + If an error occurs during the key management, the device shall return a status code 463 Key management failure.As described in RFC 4567.
From 0e8566d798611cff90bb2bd80702edef1e4528f5 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Wed, 10 Sep 2025 16:33:45 -0400 Subject: [PATCH 26/50] Added clarification to rekeying --- doc/Streaming.xml | 2 +- wsdl/ver10/schema/onvif.xsd | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 55c1ed2aa..1b3ca1082 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -809,7 +809,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA 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 device shall not reset the ROC when changing keys. When + 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.As defined in RFC 3830 section 4.5. RTSP/1.0 CSeq: 6 diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 5e8cd5905..1e845d6f3 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -1321,7 +1321,7 @@ 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 - > + From 9c12725790e0f7d782d4f4a6f8d8d5c6fee5eff2 Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Wed, 10 Sep 2025 16:43:36 -0400 Subject: [PATCH 27/50] Fixed typo in streaming spec Co-authored-by: Kieran McCartan <70752937+kieran242@users.noreply.github.com> --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 1b3ca1082..d66458595 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -645,7 +645,7 @@ NONEONVIF 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 it to allow the use of RTSPS without using an SRTP encrypted media + 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. From ed2aa59b14e03578e996dd2f2c356fb7a264025c Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Thu, 11 Sep 2025 08:49:17 -0400 Subject: [PATCH 28/50] Updated reference from AES_CM_128_SHA1_80 to AES_CM_128_HMAC_SHA1_80 --- doc/Streaming.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index d66458595..734f4c8f9 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -659,7 +659,7 @@ AEAD_AES_256_GCMAs defined in RFC 7714. - If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_SHA1_80 algorithm as defined in RFC 3711. + If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711. @@ -709,7 +709,7 @@ 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_SHA1_80 and TEK+SALT + 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. From ce1b8250035be63c73035b0b650ca18f2dfb3e4f Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Thu, 11 Sep 2025 09:01:21 -0400 Subject: [PATCH 29/50] Correct MIKEY from lowercase to uppercase --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 734f4c8f9..824c359ac 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -809,7 +809,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA 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 + 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.As defined in RFC 3830 section 4.5. RTSP/1.0 CSeq: 6 From d8058fd6ad57d6bd60c3cc65d14b5ed1a812f801 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Thu, 11 Sep 2025 09:51:19 -0400 Subject: [PATCH 30/50] Added clarification for rekeying in multicast --- doc/Streaming.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 824c359ac..d9c0f0675 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -827,7 +827,8 @@ AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA 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.ONVIF specification. + 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 From b3018e67d2405134868a079132df5149cce64d21 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Thu, 11 Sep 2025 10:06:59 -0400 Subject: [PATCH 31/50] Clarified MIKEY line breaks --- doc/Streaming.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index d9c0f0675..a22a1fc68 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -758,9 +758,11 @@
Key management through RTSP - The key management extensions for SDP and RTSP (RFC 4567) allows for key - management through RTSP. Note: All MIKEY messages must not contain line breaks. The - examples below are formatted for readability. + + The key management extensions for SDP and RTSP (RFC 4567) allows for key management through RTSP. + Note: According to RFC 3830 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 From 5bd26cb145aa61c4ed40932e6e1dcca89d9685d6 Mon Sep 17 00:00:00 2001 From: jcbeaulieu Date: Fri, 12 Sep 2025 09:26:52 -0400 Subject: [PATCH 32/50] Changed SRTP reference from RTF 3830 to RFC 4567 --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a22a1fc68..010df453f 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -760,7 +760,7 @@ Key management through RTSP The key management extensions for SDP and RTSP (RFC 4567) allows for key management through RTSP. - Note: According to RFC 3830 a MIKEY message does not contain line breaks, + Note: According to RFC 4567 a MIKEY message does not contain line breaks, they have been included in the examples below for readability.
From 790fa3604f4f04e34530e1a47182a180848fd824 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 10:26:44 -0400 Subject: [PATCH 33/50] Removed footnotes in SRTP section --- doc/Streaming.xml | 70 +++++++++++++++++++++++------------------------ 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 010df453f..0e49c20eb 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -642,7 +642,7 @@ If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: - NONEONVIF specification. + 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 @@ -650,20 +650,20 @@ same TLS protected channel as the RTSP control messages. - AES_CM_128_HMAC_SHA1_80As defined in RFC 3711. + AES_CM_128_HMAC_SHA1_80 (RFC 3711) - AEAD_AES_128_GCMAs defined in RFC 7714. + AEAD_AES_128_GCM (RFC 7714) - AEAD_AES_256_GCMAs defined in RFC 7714. + AEAD_AES_256_GCM (RFC 7714) If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711. - If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80, it shall:ONVIF specification. + If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80, it shall: (ONVIF specification) Provide a list of the supported algorithms through the ConfigurationOptions structure. @@ -673,7 +673,7 @@ - The specific algorithim shall be configurable through the following methods: + The specific algorithm shall be configurable through the following methods: SetAudioEncoderConfiguration @@ -693,9 +693,9 @@ 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. + MIKEY-PK should not be used for ONVIF SRTP. (ONVIF specification) - The MIKEY message shall contain the following payloads:RFC 3830 MIKEY specification. + The MIKEY message shall contain the following payloads: (RFC 3830 MIKEY specification) Common Header Payload @@ -706,19 +706,19 @@ 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. + 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. + 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. + 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_80As defined in RFC 3711. + AES_CM_128_HMAC_SHA1_80 (RFC 3711) Encryption Algorithm: AES-CM Session Encryption Key Length: 16 octets Authentication Algorithm: HMAC-SHA-1 @@ -730,7 +730,7 @@ SRTP PRF: AES-CM - AEAD_AES_128_GCMAs defined in RFC 7714. + AEAD_AES_128_GCM (RFC 7714) Encryption Algorithm: AES-GCM Session Encryption Key Length: 16 octets Authentication Algorithm: NULL @@ -742,7 +742,7 @@ SRTP PRF: AES-CM - AEAD_AES_256_GCMAs defined in RFC 7714. + AEAD_AES_256_GCM (RFC 7714) Encryption Algorithm: AES-GCM Session Encryption Key Length: 32 octets Authentication Algorithm: NULL @@ -760,7 +760,7 @@ 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, + Note: According to RFC 4567 a MIKEY message does not contain line breaks, they have been included in the examples below for readability.
@@ -772,7 +772,7 @@ with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted stream. The device may advertise that it supports the key management defined in this specification by adding the onvif-keymgmt attribute to - the SDP.ONVIF specification. + the SDP. (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.As defined in RFC 4567. + 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 may not change the encryption algorithm after the stream has - been started.ONVIF specification. + been started. (ONVIF specification) RTSP/1.0 CSeq: 2 User-Agent: OmnicastRTSPClient/1.0 @@ -805,7 +805,7 @@ KeyMgmt: prot=mikey;uri="";data="AQAFAP1td9ABAADCD1UcAAAAAAoAAdOOGc75XD0BAAAAGAA 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.As described in RFC 2326 Section 12.39. + of the RTSP SETUP response. (RFC 2326 Section 12.39)
Client Re-Keying with MIKEY @@ -813,7 +813,7 @@ AIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAA 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.As defined in RFC 3830 section 4.5. RTSP/1.0 + the client. (RFC 3830 section 4.5) RTSP/1.0 CSeq: 6 Session: 15405670 User-Agent: OmnicastRTSPClient/1.0 @@ -830,7 +830,7 @@ AACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA 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. + 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 @@ -850,7 +850,7 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0
Error management - If an error occurs during the key management, the device shall return a status code 463 Key management failure.As described in RFC 4567. + If an error occurs during the key management, the device shall return a status code 463 Key management failure. (RFC 4567)
@@ -1480,7 +1480,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 @@ -1530,12 +1530,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; @@ -1640,28 +1640,28 @@ Server – Client: RTSP/1.0 200 OK Client – Server: SETUP rtsp://192.168.0.1/video RTSP/1.0 Cseq: 2 Transport: RTP/AVP;unicast;client_port=4588-4589 - + Server – Client: RTSP/1.0 200 OK Cseq: 2 Session: 123124;timeout=60 Transport:RTP/AVP;unicast;client_port=4588-4589; server_port=6256-6257 - + Client – Server: SETUP rtsp://192.168.0.1/audio RTSP/1.0 Cseq: 3 Session: 123124 Transport: RTP/AVP;unicast;client_port=4578-4579 - + Server – Client: RTSP/1.0 200 OK Cseq: 3 Session: 123124;timeout=60 Transport:RTP/AVP;unicast;client_port=4578-4579; server_port=6276-6277 - + Client – Server: SETUP rtsp://192.168.0.1/audioback RTSP/1.0 Cseq: 4 Session: 123124 Transport: RTP/AVP;unicast;client_port=6296-6297 Require:www.onvif.org/ver20/backchannel - + Server – Client: RTSP/1.0 200 OK Cseq: 4 Session: 123124;timeout=60 @@ -1835,7 +1835,7 @@ 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 Cseq: 1 Content-Type: application/sdp @@ -2145,10 +2145,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]. From f39885a447db4e20aebf41e46f608f45612219a7 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 10:37:50 -0400 Subject: [PATCH 34/50] Clarified legacy SRTP --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 0e49c20eb..76b04cf25 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -659,7 +659,7 @@ AEAD_AES_256_GCM (RFC 7714) - If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall support the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711. + If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall use the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711. From 7fc2b30bc3ccee6c3f92cbf5a4f4f5b368b1bf12 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 10:39:07 -0400 Subject: [PATCH 35/50] Changed NONE to RTSP_ONLY for SRTP encryption algorithms --- doc/Streaming.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 76b04cf25..a1fd218e5 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -642,9 +642,9 @@ 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. + RTSP_ONLY (ONVIF specification) + RTSP_ONLYRTSP_ONLY 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. From 848fdbeef857f9c8c300f976b60a1156fd850bbe Mon Sep 17 00:00:00 2001 From: jcbeaulieu <109600704+jcbeaulieu@users.noreply.github.com> Date: Wed, 1 Oct 2025 11:17:38 -0400 Subject: [PATCH 36/50] Update doc/Streaming.xml Co-authored-by: sirzooro --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a1fd218e5..71c5d9e48 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -643,7 +643,7 @@ device shall support at least one of the following algorithms: RTSP_ONLY (ONVIF specification) - RTSP_ONLYRTSP_ONLY is a special case, where the media is listed as RTP/AVP instead of + RTSP_ONLY 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 From e8fcdbed2b12e35b17a6a35c2f0c1d758d0a8ed0 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 12:10:40 -0400 Subject: [PATCH 37/50] Added cappentz and Sriram's suggestions. --- doc/Streaming.xml | 37 +++++++++++++------------------------ 1 file changed, 13 insertions(+), 24 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 71c5d9e48..48872e921 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -621,14 +621,16 @@
SRTP data transfer via UDP - This mode allows secure transmission of RTP packets via UDP unicast and multicast. Related documents are RFC 3711, RFC 7714 for transmission and RFC 3830, RFC 4567 for key exchange. - - The device shall indicate SRTP streaming support through the SecureRTSPStreaming parameter within StreamingCapabilities in the GetServiceCapabilities response. - -
+
+ General requirements + 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. +
+
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. + 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 @@ -659,22 +661,11 @@ AEAD_AES_256_GCM (RFC 7714) - If the device supports SRTP streaming through the SecureRTSPStreaming parameter and does not list any supported SRTP cryptographic algorithms through the SecureStreamingProtocolAlgorithms parameter, the device shall use the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711. - If the device supports encryption algorithms for secure streaming other than AES_CM_128_SHA1_80, it shall: (ONVIF specification) - - - Provide a list of the supported algorithms through the ConfigurationOptions structure. - - - Allow a specific algorithm to be configured using the SecureStreamingProtocolAlgorithm attribute. - - - - The specific algorithm shall be configurable through the following methods: - + 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 @@ -685,11 +676,9 @@ SetMetadataConfiguration - - - This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. - - +
+
+ 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. From 7498c273b61e5e367247eab363d63d569ecfc99d Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 13:59:14 -0400 Subject: [PATCH 38/50] Added ANNOUNCE to multicast group when changing MIKEY --- doc/Streaming.xml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 48872e921..da65e2172 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -832,6 +832,21 @@ mikey ]]> Response: + + + When a key is changed, the device shall send an ANNOUNCE containing the MIKEY to all clients in the multicast group. + + 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 ]]> From 00b506fd37e2f98342df372772c3789a4790f1f4 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 13:59:50 -0400 Subject: [PATCH 39/50] Added ONVIF Specification clarification --- doc/Streaming.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index da65e2172..e3b9ecb90 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -837,7 +837,7 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0 ]]> - When a key is changed, the device shall send an ANNOUNCE containing the MIKEY to all clients in the multicast group. + 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 From 715b40903c2de4df9e8f960aadc8570a11704789 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 14:04:10 -0400 Subject: [PATCH 40/50] Added mandatory RTSPS requirement for SRTP. --- doc/Streaming.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index e3b9ecb90..179bc46a6 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -625,6 +625,7 @@ General requirements 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.
Cryptographic algorithm negotiation From ab9ed1d87aee3fec8cbc8374bcd67d56a064036a Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 1 Oct 2025 14:17:40 -0400 Subject: [PATCH 41/50] Fix MIKEY ANNOUNCE indentation --- doc/Streaming.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 179bc46a6..eda12855e 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -840,8 +840,7 @@ BFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0 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 + Request: RTSP/1.0 CSeq: 4 Session: 15405670 User-Agent: OmnicastRTSPClient/1.0 From 0e91ef00b33d6e7ff7e814f4bfccc7481cdd0d5e Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Thu, 2 Oct 2025 11:14:55 -0400 Subject: [PATCH 42/50] Changed RTSP_ONLY to RTSPS_ONLY since RTSPS is used. --- doc/Streaming.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index eda12855e..ed9612761 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -645,8 +645,8 @@ If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: - RTSP_ONLY (ONVIF specification) - RTSP_ONLY is a special case, where the media is listed as RTP/AVP instead of + RTSPS_ONLY (ONVIF specification) + RTSPS_ONLY 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 From aae5d7fb8604abb24630b8dad3ebb3a69032443e Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Mon, 6 Oct 2025 10:42:54 -0400 Subject: [PATCH 43/50] Removed superfluous attributes in SDP. --- doc/Streaming.xml | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index ed9612761..138e409d2 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -757,27 +757,23 @@ 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. It's permitted to have two media fields, one - with RTP/AVP and one with RTP/SAVP. The RTP/AVP track is used for an unencrypted - stream. The device may advertise that it supports the key management defined in - this specification by adding the onvif-keymgmt attribute to - the SDP. (ONVIF specification) - + 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 RTSPS_ONLY. + 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 RTSPS_ONLY, the media should be of type RTP/AVP and it should 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) From e948ba6548a662b705738e13b59fc1fd054bf8b6 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Mon, 6 Oct 2025 10:55:16 -0400 Subject: [PATCH 44/50] Sperated the SRTP section from the Live Streaming Chapter --- doc/Streaming.xml | 508 +++++++++++++++++++++++++--------------------- 1 file changed, 275 insertions(+), 233 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 138e409d2..ed88fcd1d 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -621,240 +621,10 @@
SRTP data transfer via UDP -
- General requirements - 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. -
-
- 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: - - RTSPS_ONLY (ONVIF specification) - RTSPS_ONLY 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 RTSPS_ONLY. - 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 RTSPS_ONLY, the media should be of type RTP/AVP and it should 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 may 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 + 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. -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) - -
-
-
RTP/RTSP/HTTP/TCP @@ -2365,6 +2135,278 @@ Sec-WebSocket-Protocol: rtsp.onvif.org
+ + 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: + + RTSPS_ONLY (ONVIF specification) + + RTSPS_ONLY 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 RTSPS_ONLY. + 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 RTSPS_ONLY, the media should be of type RTP/AVP and it should 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 may 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) + +
+
+
+ Revision History From 7b3be6530b9e49b98856382f5f20b77f206207a3 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Thu, 5 Feb 2026 07:24:16 -0500 Subject: [PATCH 45/50] Changed RTSPS_ONLY to NONE --- doc/Streaming.xml | 148 +++++++++++++++++++++++----------------------- 1 file changed, 74 insertions(+), 74 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index ed88fcd1d..2b7f87989 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -6,7 +6,7 @@ Streaming 23.06 - ONVIF™ + ONVIF™ www.onvif.org June, 2023 @@ -17,7 +17,7 @@ 2008-2023 - ONVIF™ All rights reserved. + ONVIF™ All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so @@ -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. @@ -634,7 +634,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. @@ -692,7 +692,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” @@ -705,7 +705,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. @@ -729,7 +729,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 ). @@ -749,7 +749,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 @@ -760,7 +760,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. @@ -786,13 +786,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: @@ -879,7 +879,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 @@ -894,7 +894,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.
@@ -1075,7 +1075,7 @@ M - Required to set media session　parameters. + Required to set media session?parameters. @@ -1234,13 +1234,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 @@ -1276,7 +1276,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 @@ -1362,31 +1362,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. - @@ -1462,12 +1462,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 -
@@ -1538,12 +1538,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 @@ -1686,7 +1686,7 @@ NVT – NVS: RTSP/1.0 200 OK - NTP timestamp… + NTP timestamp… @@ -1719,7 +1719,7 @@ NVT – NVS: RTSP/1.0 200 OK - payload… + payload… @@ -1731,7 +1731,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. @@ -1821,7 +1821,7 @@ NVT – NVS: RTSP/1.0 200 OK - NTP timestamp… + NTP timestamp… @@ -1864,7 +1864,7 @@ NVT – NVS: RTSP/1.0 200 OK - payload… + payload… @@ -1874,7 +1874,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 @@ -1897,7 +1897,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 @@ -1907,7 +1907,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]. @@ -1941,20 +1941,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. @@ -1971,13 +1971,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. @@ -2006,10 +2006,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 @@ -2026,10 +2026,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.
@@ -2044,11 +2044,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 @@ -2057,8 +2057,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 @@ -2106,7 +2106,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 @@ -2129,7 +2129,7 @@ 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.
@@ -2155,9 +2155,9 @@ Sec-WebSocket-Protocol: rtsp.onvif.org If the SecureStreamingProtocolAlgorithms parameter is present, the device shall support at least one of the following algorithms: - RTSPS_ONLY (ONVIF specification) + NONE (ONVIF specification) - RTSPS_ONLY is a special case, where the media is listed as RTP/AVP instead of + NONE is a special case, where the media is listed as RTP/AVP instead of RTP/SAVP and where MIKEY is unused altogether. @@ -2290,10 +2290,10 @@ Sec-WebSocket-Protocol: rtsp.onvif.org 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 RTSPS_ONLY. + 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 RTSPS_ONLY, the media should be of type RTP/AVP and it should not contain a MIKEY message. (ONVIF specification) + If the device stream has been configured with the NONE algorithm, the media should be of type RTP/AVP and it should not contain a MIKEY message. (ONVIF specification) Date: Mon, 16 Feb 2026 10:48:15 -0500 Subject: [PATCH 46/50] Removed duplicate SrtpSecurityAlgorims in onvif.xsd --- wsdl/ver10/schema/onvif.xsd | 113 +++++++++++++++++------------------- 1 file changed, 52 insertions(+), 61 deletions(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 43501d7cf..074c60759 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. @@ -1017,15 +1017,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - - - - @@ -1467,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.
    • @@ -2159,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. @@ -2168,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. @@ -2315,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. @@ -4444,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.
     @@ -4693,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. @@ -4944,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. @@ -4952,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. @@ -4961,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. @@ -4970,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. @@ -4980,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. @@ -4989,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. @@ -4997,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. @@ -5006,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. @@ -5555,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.
     @@ -6240,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.
     @@ -6611,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.
     @@ -7121,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. @@ -7148,7 +7139,7 @@ If set to 0.0, infinity will be used. - + @@ -8079,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. @@ -8551,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. @@ -9015,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 @@ -9535,9 +9526,9 @@ and sample rate. - + - + From 074cbb666fe939ad40a16eed152dce575133c853 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 17 Feb 2026 09:15:13 -0500 Subject: [PATCH 47/50] Fixed broken wsdl --- doc/Streaming.xml | 140 ++++++++++++++++++------------------ wsdl/ver10/schema/onvif.xsd | 8 +-- 2 files changed, 74 insertions(+), 74 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 526a32489..4b51e6688 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -6,7 +6,7 @@ Streaming 25.12 - ONVIF™ + ONVIF™ www.onvif.org December, 2025 @@ -17,7 +17,7 @@ 2008-2025 - ONVIF™ All rights reserved. + ONVIF™ All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so @@ -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. @@ -647,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. @@ -705,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” @@ -718,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. @@ -742,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 ). @@ -762,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 @@ -773,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. @@ -799,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: @@ -892,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 @@ -907,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.
@@ -1088,7 +1088,7 @@ M - Required to set media session?parameters. + Required to set media session parameters. @@ -1247,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 @@ -1289,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 @@ -1375,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. - @@ -1475,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 -
@@ -1551,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 @@ -1699,7 +1699,7 @@ NVT – NVS: RTSP/1.0 200 OK - NTP timestamp… + NTP timestamp… @@ -1732,7 +1732,7 @@ NVT – NVS: RTSP/1.0 200 OK - payload… + payload… @@ -1744,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. @@ -1834,7 +1834,7 @@ NVT – NVS: RTSP/1.0 200 OK - NTP timestamp… + NTP timestamp… @@ -1877,7 +1877,7 @@ NVT – NVS: RTSP/1.0 200 OK - payload… + payload… @@ -1887,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 @@ -1910,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 @@ -1920,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]. @@ -1954,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. @@ -1984,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. @@ -2019,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 @@ -2039,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.
@@ -2057,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 @@ -2070,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 @@ -2119,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 @@ -2142,7 +2142,7 @@ 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.
diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 074c60759..ef2c8fca4 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -391,7 +391,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO 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 + 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. @@ -428,7 +428,7 @@ 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 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. @@ -4972,7 +4972,7 @@ 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 + 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. From d9845baa4cca60431ee020474d2b6bd6ba7f8bdf Mon Sep 17 00:00:00 2001 From: Ottavio Campana Date: Tue, 17 Feb 2026 16:22:06 +0100 Subject: [PATCH 48/50] Fixing most of the encoding issues --- doc/Core.xml | 2 +- doc/Streaming.xml | 134 ++++++++++++++++++------------------ wsdl/ver10/schema/onvif.xsd | 18 ++--- 3 files changed, 77 insertions(+), 77 deletions(-) diff --git a/doc/Core.xml b/doc/Core.xml index 8d8bc1174..25d99679c 100644 --- a/doc/Core.xml +++ b/doc/Core.xml @@ -6483,7 +6483,7 @@ onvif://www.onvif.org/name/ARV-453
Configuration Renewal - The configuration allows for a renewal endpoint to be set. If the device supports this feature, it shall automatically renew the credentials + 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. diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 4b51e6688..a33541562 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. @@ -647,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. @@ -705,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" @@ -718,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. @@ -742,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 ). @@ -762,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 @@ -773,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. @@ -799,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: @@ -892,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 @@ -907,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.
@@ -1247,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 @@ -1289,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 @@ -1375,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. - @@ -1475,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 -
@@ -1551,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 @@ -1699,7 +1699,7 @@ NVT - NTP timestamp… + NTP timestamp... @@ -1732,7 +1732,7 @@ NVT - payload… + payload... @@ -1744,7 +1744,7 @@ NVT 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. @@ -1834,7 +1834,7 @@ NVT - NTP timestamp… + NTP timestamp... @@ -1877,7 +1877,7 @@ NVT - payload… + payload... @@ -1887,7 +1887,7 @@ NVT
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 @@ -1910,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 @@ -1920,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]. @@ -1954,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. @@ -1984,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. @@ -2019,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 @@ -2039,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.
@@ -2057,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 @@ -2070,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 @@ -2119,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 @@ -2142,7 +2142,7 @@ 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.
diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index ef2c8fca4..abd7b6f5c 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -4435,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.
 @@ -4684,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. @@ -5546,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.
 @@ -6231,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.
 @@ -6602,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.
 From aa6da11301f85cce8195fd02b360e913e393a319 Mon Sep 17 00:00:00 2001 From: Ottavio Campana Date: Tue, 17 Feb 2026 16:32:31 +0100 Subject: [PATCH 49/50] Cleaned up the trademark symbol --- doc/Streaming.xml | 4 ++-- wsdl/ver20/media/wsdl/media.wsdl | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a33541562..5a910f8ae 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -6,7 +6,7 @@ Streaming 25.12 - ONVIF™ + ONVIF™ www.onvif.org December, 2025 @@ -17,7 +17,7 @@ 2008-2025 - ONVIF™ All rights reserved. + ONVIF™ All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 6cef330e7..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 - + @@ -2268,7 +2268,7 @@ support streaming video data of such a profile.
  • RtspMulticast RTSP streaming RTP as UDP Multicast.
  • RtspsUnicast Secure RTSP streaming with SRTP as UDP Unicast.
  • RtspsMulticast Secure RTSP streaming with SRTP as UDP Multicast.
    • -
  • RTSP RTSP streaming RTP over TCP.
    • +
  • 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.
    From 3ec6a8da505b291b949a3a49d75ed75ea791ae5c Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Thu, 19 Feb 2026 16:33:23 -0500 Subject: [PATCH 50/50] Changed should and may to shall --- doc/Streaming.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 5a910f8ae..9e8fecbf0 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -2306,7 +2306,7 @@ Sec-WebSocket-Protocol: rtsp.onvif.org 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 should be of type RTP/AVP and it should not contain a MIKEY message. (ONVIF specification) + 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) RTSP/1.0 CSeq: 2