From d40607a4902499b8ae9b05d02cc3f03e0ae27679 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 7 May 2024 11:58:33 -0400 Subject: [PATCH 01/17] Proposal to add support for RFC 7714 SRTP with AES-GCM with security protocol negotiation --- doc/Streaming.xml | 2 +- wsdl/ver20/media/wsdl/media.wsdl | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a680744cb..01a0922ac 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -590,7 +590,7 @@
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. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the authentication tag is present. For RFC 7714, it is expected that the authentication tag is not present. It is expeced that the optional MKI is present in all cases.
RTP/RTSP/HTTP/TCP diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index ab382a7d1..63f5e1c14 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -147,6 +147,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates support for live media streaming via RTSPS and SRTP. + + + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tr2:SrtpSecurityAlgorithms. + + @@ -712,6 +717,14 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + + @@ -775,6 +788,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Defines the network protocol for streaming as defined by tr2:TransportProtocol + + + Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms + + The ProfileToken element indicates the media profile to use and will define the configuration of the content of the stream. From 1841d6b589c628d8079bf46b5937002ac922507e Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Fri, 14 Jun 2024 09:06:29 -0400 Subject: [PATCH 02/17] Revert "Proposal to add support for RFC 7714 SRTP with AES-GCM with security protocol negotiation" This reverts commit d40607a4902499b8ae9b05d02cc3f03e0ae27679. --- doc/Streaming.xml | 2 +- wsdl/ver20/media/wsdl/media.wsdl | 18 ------------------ 2 files changed, 1 insertion(+), 19 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 01a0922ac..a680744cb 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -590,7 +590,7 @@
SRTP data transfer via UDP - This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the authentication tag is present. For RFC 7714, it is expected that the authentication tag is not present. It is expeced that the optional MKI is present in all cases. + This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 for transmission and RFC 4567 for key exchange.
RTP/RTSP/HTTP/TCP diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 63f5e1c14..ab382a7d1 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -147,11 +147,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates support for live media streaming via RTSPS and SRTP. - - - If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tr2:SrtpSecurityAlgorithms. - - @@ -717,14 +712,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - - - @@ -788,11 +775,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Defines the network protocol for streaming as defined by tr2:TransportProtocol - - - Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms - - The ProfileToken element indicates the media profile to use and will define the configuration of the content of the stream. From 9a6ee0cec0f7f079ea53904423bade972b74a647 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Fri, 4 Oct 2024 11:29:52 -0400 Subject: [PATCH 03/17] Added section on SRTP encryption algorithm negotiation --- doc/Streaming.xml | 100 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 94 insertions(+), 6 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a680744cb..7a3b969c2 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 @@ -247,8 +246,6 @@ <> IETF RFC 3984, RTP Payload Format for H.264 Video <> - IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams - <> IETF RFC 4566, SDP: Session Description Protocol <> IETF RFC 4567, Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) @@ -260,9 +257,11 @@ IETF 5104, Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) <> IETF RFC 5888 The Session Description Protocol (SDP) Grouping Framework - <> + <> IETF RFC 6455, The WebSocket Protocol <> + IETF RFC 7714, AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) + <> IETF RFC 7798, RTP Payload Format for High Efficiency Video Coding (HEVC) <> IETF RFC 7826, Real-Time Streaming Protocol Version 2.0 @@ -380,6 +379,22 @@ Joint Photographic Expert Group + + + MIKEY + + + Multimedia Internet KEYing + + + + + MKI + + + Master Key Identifier + + MPEG-4 @@ -590,7 +605,80 @@
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. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the SRTP authentication tag be present. For RFC 7714, it is expected that the SRTP authentication tag is not present. The optional MKI is expected to be present in SRTP packets regardless of the algorithm used. +
+ Cryptographic algorithm negotiation + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 defined in RFC 3711, it must also support the ONVIF SRTP algorithm negotiation mechanism to allow the device to use additional encryption algorithms. This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. + + + In the RTSP DESCRIBE, the device may list the supported encryption algorithms using the "onvif-crypto" attribute + (e.g., a=onvif-crypto: AEAD_AES_256_GCM). + + + The "onvif-crypto" attribute can be defined at the session or media level. + The value of the attribute must be one of the encryption algorithms specified in the ONVIF SRTP Security Extensions (TODO). + If no "onvif-crypto" attribute is present in the SDP, the client must treat RTP/SAVP media as AES_CM_128_SHA1_80. + + + For every "onvif-crypto" attribute, one MIKEY attribute must be present, as the MIKEY Security Protocol Parameters + are specific to each encryption algorithm. The MIKEY parameters are explained in [RFC 7714] Section 14.3. + It is recommended to define the MIKEY at the media level and use a different MIKEY for each media to reduce the risk of nonce reuse. + + + In the RTSP SETUP, the device may include the "onvif-crypto" header to select the encryption algorithm. + The value must be one of the values provided in the SDP. + + + Example: + + + 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 + Content-Length: XXX + v=0 + o=- 2890844256 2890842807 IN IP4 172.16.2.93 + s=RTSP Session + m=audio 0 RTP/SAVP 0 + a=onvif-crypto: AEAD_AES_256_GCM + a=onvif-crypto: AES_CM_128_HMAC_SHA1_80 + a=key-mgmt: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... + a=key-mgmt: mikey BQBFhN1YgmBCBBBBBBBBBBBBBBBtBz... + a=control:rtsp://example.com/onvif_camera/audio + m=video 0 RTP/SAVP 26 + a=onvif-crypto: AEAD_AES_256_GCM + a=onvif-crypto: AES_CM_128_HMAC_SHA1_80 + a=key-mgmt: mikey CQCGiO2ZhnCDCCCCCCCCCCCCCCCuC0... + a=key-mgmt: mikey DQDHjP3AioDEDDDDDDDDDDDDDvD1... + a=control:rtsp://example.com/onvif_camera/video + m=application 0 RTP/SAVP 107 + a=onvif-crypto: AEAD_AES_256_GCM + a=onvif-crypto: AES_CM_128_HMAC_SHA1_80 + a=key-mgmt: mikey EQCGiO2ZhnEDEEEEEEEEEEEEEuC0... + a=key-mgmt: mikey FQDHjP3AioFEFFFFFFFFFFFFFvD1... + a=control:rtsp://example.com/onvif_camera/metadata + a=recvonly + a=rtpmap:107 vnd.onvif.metadata/90000 + +client->server: SETUP rtsp://example.com/onvif_camera/audio RTSP/1.0 + Cseq: 2 + Transport: RTP/SAVP/TCP;unicast;interleaved=0-1 + keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; + data="GQCGiO2ZhnGDGGGGGGGGGGGuC3..." + onvif-crypto: AEAD_AES_256_GCM + +server->client: RTSP/1.0 200 OK + Cseq: 2 + Transport: RTP/SAVP;unicast;client_port=8002-8003; + server_port=9004-9005 + Session: 12345678; timeout=60 +]]> + +
RTP/RTSP/HTTP/TCP From 03c5e3caa3a4821f67184bd94b7ee710fc746137 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Thu, 5 Dec 2024 09:16:25 -0500 Subject: [PATCH 04/17] Removed reference to security extensions and added reference to the IANA SRTP Crypto Suite Registrations. --- doc/Streaming.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 7a3b969c2..04a2ab62f 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -278,6 +278,8 @@ <> ONVIF Replay Control Service Specification <> + IANA SRTP Crypto Suite Registrations + <> Terms and Definitions @@ -616,7 +618,7 @@ The "onvif-crypto" attribute can be defined at the session or media level. - The value of the attribute must be one of the encryption algorithms specified in the ONVIF SRTP Security Extensions (TODO). + The value of the attribute must be one of the encryption algorithms specified in the IANA SRTP Crypto Suite Registrations. If no "onvif-crypto" attribute is present in the SDP, the client must treat RTP/SAVP media as AES_CM_128_SHA1_80. From 83d515acbda8abed8f4e2e4bb3c9bafca12b95a0 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 11 Feb 2025 10:47:34 -0500 Subject: [PATCH 05/17] Revert "Removed reference to security extensions and added reference to the IANA SRTP Crypto Suite Registrations." This reverts commit 03c5e3caa3a4821f67184bd94b7ee710fc746137. --- doc/Streaming.xml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 04a2ab62f..7a3b969c2 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -278,8 +278,6 @@ <> ONVIF Replay Control Service Specification <> - IANA SRTP Crypto Suite Registrations - <> Terms and Definitions @@ -618,7 +616,7 @@ The "onvif-crypto" attribute can be defined at the session or media level. - The value of the attribute must be one of the encryption algorithms specified in the IANA SRTP Crypto Suite Registrations. + The value of the attribute must be one of the encryption algorithms specified in the ONVIF SRTP Security Extensions (TODO). If no "onvif-crypto" attribute is present in the SDP, the client must treat RTP/SAVP media as AES_CM_128_SHA1_80. From a6e9d1d75fc1e5ed627d101e5e333a514a44486f Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 11 Feb 2025 10:48:22 -0500 Subject: [PATCH 06/17] Revert "Added section on SRTP encryption algorithm negotiation" This reverts commit 9a6ee0cec0f7f079ea53904423bade972b74a647. --- doc/Streaming.xml | 100 +++------------------------------------------- 1 file changed, 6 insertions(+), 94 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 7a3b969c2..a680744cb 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -235,7 +235,8 @@ 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 @@ -246,6 +247,8 @@ <> IETF RFC 3984, RTP Payload Format for H.264 Video <> + IETF RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams + <> IETF RFC 4566, SDP: Session Description Protocol <> IETF RFC 4567, Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) @@ -257,11 +260,9 @@ IETF 5104, Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) <> IETF RFC 5888 The Session Description Protocol (SDP) Grouping Framework - <> + <> IETF RFC 6455, The WebSocket Protocol <> - IETF RFC 7714, AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) - <> IETF RFC 7798, RTP Payload Format for High Efficiency Video Coding (HEVC) <> IETF RFC 7826, Real-Time Streaming Protocol Version 2.0 @@ -379,22 +380,6 @@ Joint Photographic Expert Group - - - MIKEY - - - Multimedia Internet KEYing - - - - - MKI - - - Master Key Identifier - - MPEG-4 @@ -605,80 +590,7 @@
SRTP data transfer via UDP - This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the SRTP authentication tag be present. For RFC 7714, it is expected that the SRTP authentication tag is not present. The optional MKI is expected to be present in SRTP packets regardless of the algorithm used. -
- Cryptographic algorithm negotiation - If a device supports encryption algorithms other than AES_CM_128_SHA1_80 defined in RFC 3711, it must also support the ONVIF SRTP algorithm negotiation mechanism to allow the device to use additional encryption algorithms. This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. - - - In the RTSP DESCRIBE, the device may list the supported encryption algorithms using the "onvif-crypto" attribute - (e.g., a=onvif-crypto: AEAD_AES_256_GCM). - - - The "onvif-crypto" attribute can be defined at the session or media level. - The value of the attribute must be one of the encryption algorithms specified in the ONVIF SRTP Security Extensions (TODO). - If no "onvif-crypto" attribute is present in the SDP, the client must treat RTP/SAVP media as AES_CM_128_SHA1_80. - - - For every "onvif-crypto" attribute, one MIKEY attribute must be present, as the MIKEY Security Protocol Parameters - are specific to each encryption algorithm. The MIKEY parameters are explained in [RFC 7714] Section 14.3. - It is recommended to define the MIKEY at the media level and use a different MIKEY for each media to reduce the risk of nonce reuse. - - - In the RTSP SETUP, the device may include the "onvif-crypto" header to select the encryption algorithm. - The value must be one of the values provided in the SDP. - - - Example: - - - 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 - Content-Length: XXX - v=0 - o=- 2890844256 2890842807 IN IP4 172.16.2.93 - s=RTSP Session - m=audio 0 RTP/SAVP 0 - a=onvif-crypto: AEAD_AES_256_GCM - a=onvif-crypto: AES_CM_128_HMAC_SHA1_80 - a=key-mgmt: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... - a=key-mgmt: mikey BQBFhN1YgmBCBBBBBBBBBBBBBBBtBz... - a=control:rtsp://example.com/onvif_camera/audio - m=video 0 RTP/SAVP 26 - a=onvif-crypto: AEAD_AES_256_GCM - a=onvif-crypto: AES_CM_128_HMAC_SHA1_80 - a=key-mgmt: mikey CQCGiO2ZhnCDCCCCCCCCCCCCCCCuC0... - a=key-mgmt: mikey DQDHjP3AioDEDDDDDDDDDDDDDvD1... - a=control:rtsp://example.com/onvif_camera/video - m=application 0 RTP/SAVP 107 - a=onvif-crypto: AEAD_AES_256_GCM - a=onvif-crypto: AES_CM_128_HMAC_SHA1_80 - a=key-mgmt: mikey EQCGiO2ZhnEDEEEEEEEEEEEEEuC0... - a=key-mgmt: mikey FQDHjP3AioFEFFFFFFFFFFFFFvD1... - a=control:rtsp://example.com/onvif_camera/metadata - a=recvonly - a=rtpmap:107 vnd.onvif.metadata/90000 - -client->server: SETUP rtsp://example.com/onvif_camera/audio RTSP/1.0 - Cseq: 2 - Transport: RTP/SAVP/TCP;unicast;interleaved=0-1 - keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; - data="GQCGiO2ZhnGDGGGGGGGGGGGuC3..." - onvif-crypto: AEAD_AES_256_GCM - -server->client: RTSP/1.0 200 OK - Cseq: 2 - Transport: RTP/SAVP;unicast;client_port=8002-8003; - server_port=9004-9005 - Session: 12345678; timeout=60 -]]> - -
+ This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 for transmission and RFC 4567 for key exchange.
RTP/RTSP/HTTP/TCP From 8da15d8d848ca3ab168ba854babe5bddff420cc6 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 11 Feb 2025 17:11:30 -0500 Subject: [PATCH 07/17] Changed SRTP streaming negotiation from RTSP to Media2 wsdl --- doc/Streaming.xml | 76 ++++++++++++++++++++++++++-- wsdl/ver20/media/wsdl/media.wsdl | 87 +++++++++++++++++++++++++++++++- 2 files changed, 158 insertions(+), 5 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index a680744cb..8758ad95d 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,62 @@
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. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the SRTP authentication tag be present. For RFC 7714, it is expected that the SRTP authentication tag is not present. The optional MKI is expected to be present in SRTP packets regardless of the algorithm used. + + The client may set a different key management protocol in the keymgmt attribute of the SETUP. + If the keymgmt header is present in the SETUP, the device shall use the key management protocol and key specified in the keymgmt header. + + + Example RTSP session: + + + 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 + Content-Length: XXX + v=0 + o=- 2890844256 2890842807 IN IP4 172.16.2.93 + s=RTSP Session + m=audio 0 RTP/SAVP 0 + a=key-mgmt: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... + a=control:rtsp://example.com/onvif_camera/audio + m=video 0 RTP/SAVP 26 + a=key-mgmt: mikey CQCGiO2ZhnCDCCCCCCCCCCCCCCCuC0... + a=control:rtsp://example.com/onvif_camera/video + m=application 0 RTP/SAVP 107 + a=key-mgmt: mikey EQCGiO2ZhnEDEEEEEEEEEEEEEuC0... + a=control:rtsp://example.com/onvif_camera/metadata + a=recvonly + a=rtpmap:107 vnd.onvif.metadata/90000 + +client->server: SETUP rtsp://example.com/onvif_camera/audio RTSP/1.0 + Cseq: 2 + Transport: RTP/SAVP/TCP;unicast;interleaved=0-1 + keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; + data="GQCGiO2ZhnGDGGGGGGGGGGGuC3..." + +server->client: RTSP/1.0 200 OK + Cseq: 2 + Transport: RTP/SAVP;unicast;client_port=8002-8003; + server_port=9004-9005 + Session: 12345678; timeout=60 +]]> + +
+
+ Cryptographic algorithm negotiation + + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support Media2, the SecureRTSPStreamingAlgorithms attribute of the GetServiceCapabilities response and the GetStreamUri2 action. + This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. + + + To configure which algorithm should be used by the streaming device, the client must get the list of supported SecureRTSPStreamingAlgorithms through the GetServiceCapabilities action. + The client can then choose the algorithm to use and set it in the SecurityProtocolAlgorithm attribute of the GetStreamUri2 action. +
RTP/RTSP/HTTP/TCP diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index ab382a7d1..2395c6ed8 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -147,6 +147,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates support for live media streaming via RTSPS and SRTP. + + + If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tr2:SrtpSecurityAlgorithms. + + @@ -705,13 +710,21 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - + + + + + + + + + + @@ -794,6 +807,41 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + Defines the network protocol for streaming as defined by tr2:TransportProtocol + + + + + The ProfileToken element indicates the media profile to use and will define the configuration of the content of the stream. + + + + + Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms + + + + + + + + + + + + Stable Uri to be used for requesting the media stream + + + + + + @@ -1484,6 +1532,12 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + @@ -1793,6 +1847,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.
@@ -1802,6 +1858,33 @@ support streaming video data of such a profile.
+ + + This operation requests a URI that can be used to initiate a live media stream using RTSP as + the control protocol. The returned URI shall remain valid indefinitely even if the profile is changed.
+ Defined stream types are +
    +
  • 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.
    • +
+ If a multicast stream is requested at least one of VideoEncoder2Configuration, AudioEncoder2Configuration and MetadataConfiguration shall have a valid multicast setting.
+ The SecurityProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
+ Defined security protocol algorithms are +
    +
  • AES_CM_128_HMAC_SHA1_80
    • +
  • AEAD_AES_128_GCM
    • +
  • AEAD_AES_256_GCM
    • +
+ For full compatibility with other ONVIF services a device should not generate Uris longer than + 128 octets. + + + + This command starts multicast streaming using a specified media profile of a device. Streaming continues until StopMulticastStreaming is called for the same Profile. The From e83014db0146cc51c30817e80dde9323fc10d227 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 11 Feb 2025 17:14:07 -0500 Subject: [PATCH 08/17] Changed tabs to spaces --- wsdl/ver20/media/wsdl/media.wsdl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 2395c6ed8..fee17345b 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -1866,7 +1866,7 @@ 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.
    • +
  • 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 1b8b3fc7c9f602734bfbb6e817ff6832660824ef Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 12 Feb 2025 09:27:58 -0500 Subject: [PATCH 09/17] Fixed tabs vs spaces indentation --- wsdl/ver20/media/wsdl/media.wsdl | 260 +++++++++++++++---------------- 1 file changed, 130 insertions(+), 130 deletions(-) diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index fee17345b..7725d073c 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -77,8 +77,8 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Indicates that privacy masks are only supported at the video source level and not the video source configuration level. - If this is true any addition, deletion or change of a privacy mask done for one video source configuration will automatically be + Indicates that privacy masks are only supported at the video source level and not the video source configuration level. + If this is true any addition, deletion or change of a privacy mask done for one video source configuration will automatically be applied by the device to a corresponding privacy mask for all other video source configuration associated with the same video source. @@ -147,11 +147,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates support for live media streaming via RTSPS and SRTP. - - - 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 tr2:SrtpSecurityAlgorithms. + + @@ -182,10 +182,10 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Reference token of an existing configuration. - Token shall be included in the AddConfiguration request along with the type. - Token shall be included in the CreateProfile request when Configuration elements are included and type is selected. - Token is optional for RemoveConfiguration request. If no token is provided in RemoveConfiguration request, device shall - remove the configuration of the type included in the profile. + Token shall be included in the AddConfiguration request along with the type. + Token shall be included in the CreateProfile request when Configuration elements are included and type is selected. + Token is optional for RemoveConfiguration request. If no token is provided in RemoveConfiguration request, device shall + remove the configuration of the type included in the profile. @@ -203,7 +203,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - A set of media configurations. + A set of media configurations. @@ -265,7 +265,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - A media profile consists of a set of media configurations. + A media profile consists of a set of media configurations. @@ -342,7 +342,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Lists all profiles that exist in the media service. The response provides the requested types of Configurations as far as available. + Lists all profiles that exist in the media service. The response provides the requested types of Configurations as far as available. If a profile doesn't contain a type no error shall be provided. @@ -376,7 +376,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -399,7 +399,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -437,7 +437,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -551,7 +551,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -563,7 +563,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -717,14 +717,14 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - - - + + + + + + + + @@ -741,7 +741,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Video Media Subtype for the video format. For definitions see tt:VideoEncodingMimeNames and IANA Media Types. + Video Media Subtype for the video format. For definitions see tt:VideoEncodingMimeNames and IANA Media Types. @@ -750,7 +750,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -807,41 +807,41 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - - Defines the network protocol for streaming as defined by tr2:TransportProtocol - - - - - The ProfileToken element indicates the media profile to use and will define the configuration of the content of the stream. - - - - - Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms - - - - - - - - - - - - Stable Uri to be used for requesting the media stream - - - - - - + + + + + + + Defines the network protocol for streaming as defined by tr2:TransportProtocol + + + + + The ProfileToken element indicates the media profile to use and will define the configuration of the content of the stream. + + + + + Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms + + + + + + + + + + + + Stable Uri to be used for requesting the media stream + + + + + + @@ -949,7 +949,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -983,7 +983,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicate token for video source mode. - + Indication of whether this mode is active. If active this value is true. In case of non-indication, it means as false. The value of true shall be had by only one video source mode. @@ -1184,7 +1184,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -1221,7 +1221,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -1307,14 +1307,14 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + - + @@ -1532,12 +1532,12 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - + + + + + + @@ -1656,7 +1656,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - This operation creates a new media profile. + This operation creates a new media profile. A created profile created via this method may be deleted via the DeleteProfile method. Optionally Configurations can be assinged to the profile on creation. For details regarding profile assignement check also the method AddConfiguration. @@ -1677,9 +1677,9 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO This operation adds one or more Configurations to an existing media profile. If a -configuration exists in the media profile, it will be replaced. A device shall -support adding a compatible Configuration to a Profile containing a VideoSourceConfiguration and shall -support streaming video data of such a profile.
    + configuration exists in the media profile, it will be replaced. A device shall + support adding a compatible Configuration to a Profile containing a VideoSourceConfiguration and shall + support streaming video data of such a profile.
    Note that OSD elements must be added via the CreateOSD command.     @@ -1792,10 +1792,10 @@ support streaming video data of such a profile.
     - This operation returns the available options (supported values and ranges for video encoder + This operation returns the available options (supported values and ranges for video encoder configuration parameters) when the video encoder parameters are reconfigured.
    - This response contains the available video encoder configuration options. If a video encoder configuration is specified, - the options shall concern that particular configuration. If a media profile is specified, the options shall be + This response contains the available video encoder configuration options. If a video encoder configuration is specified, + the options shall concern that particular configuration. If a media profile is specified, the options shall be compatible with that media profile. If no tokens are specified, the options shall be considered generic for the device.     @@ -1844,47 +1844,47 @@ support streaming video data of such a profile.
    This operation requests a URI that can be used to initiate a live media stream using RTSP as the control protocol. The returned URI shall remain valid indefinitely even if the profile is changed.
    Defined stream types are -
      -
    • 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.
      • -
    +
      +
    • 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.
      • +
    If a multicast stream is requested at least one of VideoEncoder2Configuration, AudioEncoder2Configuration and MetadataConfiguration shall have a valid multicast setting.
    For full compatibility with other ONVIF services a device should not generate Uris longer than 128 octets.         - - - This operation requests a URI that can be used to initiate a live media stream using RTSP as - the control protocol. The returned URI shall remain valid indefinitely even if the profile is changed.
    - Defined stream types are -
      -
    • 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.
      • -
    - If a multicast stream is requested at least one of VideoEncoder2Configuration, AudioEncoder2Configuration and MetadataConfiguration shall have a valid multicast setting.
    - The SecurityProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
    - Defined security protocol algorithms are + + + This operation requests a URI that can be used to initiate a live media stream using RTSP as + the control protocol. The returned URI shall remain valid indefinitely even if the profile is changed.
    + Defined stream types are
      -
    • AES_CM_128_HMAC_SHA1_80
      • -
    • AEAD_AES_128_GCM
      • -
    • AEAD_AES_256_GCM
      • +
    • 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.
      • +
    + If a multicast stream is requested at least one of VideoEncoder2Configuration, AudioEncoder2Configuration and MetadataConfiguration shall have a valid multicast setting.
    + The SecurityProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
    + Defined security protocol algorithms are +
      +
    • AES_CM_128_HMAC_SHA1_80
      • +
    • AEAD_AES_128_GCM
      • +
    • AEAD_AES_256_GCM
    For full compatibility with other ONVIF services a device should not generate Uris longer than - 128 octets. -     - - -     + 128 octets. +     + + +     This command starts multicast streaming using a specified media profile of a device. Streaming continues until StopMulticastStreaming is called for the same Profile. The @@ -1902,26 +1902,26 @@ support streaming video data of such a profile.
     Synchronization points allow clients to decode and correctly use all data after the -synchronization point. -For example, if a video stream is configured with a large I-frame distance and a client loses a -single packet, the client does not display video until the next I-frame is transmitted. In such -cases, the client can request a Synchronization Point which enforces the device to add an I-Frame as soon as possible. Clients can request Synchronization Points for profiles. The device -shall add synchronization points for all streams associated with this profile. -Similarly, a synchronization point is used to get an update on full PTZ or event status through -the metadata stream. -If a video stream is associated with the profile, an I-frame shall be added to this video stream. -If a PTZ metadata stream is associated to the profile, -the PTZ position shall be repeated within the metadata stream. + synchronization point. + For example, if a video stream is configured with a large I-frame distance and a client loses a + single packet, the client does not display video until the next I-frame is transmitted. In such + cases, the client can request a Synchronization Point which enforces the device to add an I-Frame as soon as possible. Clients can request Synchronization Points for profiles. The device + shall add synchronization points for all streams associated with this profile. + Similarly, a synchronization point is used to get an update on full PTZ or event status through + the metadata stream. + If a video stream is associated with the profile, an I-frame shall be added to this video stream. + If a PTZ metadata stream is associated to the profile, + the PTZ position shall be repeated within the metadata stream. A client uses the GetSnapshotUri command to obtain a JPEG snapshot from the -device. The returned URI shall remain valid indefinitely even if the profile is changed. The URI can be used for -acquiring a JPEG image through a HTTP GET operation. The image encoding will always be -JPEG regardless of the encoding setting in the media profile. The Jpeg settings -(like resolution or quality) may be taken from the profile if suitable. The provided -image will be updated automatically and independent from calls to GetSnapshotUri. + device. The returned URI shall remain valid indefinitely even if the profile is changed. The URI can be used for + acquiring a JPEG image through a HTTP GET operation. The image encoding will always be + JPEG regardless of the encoding setting in the media profile. The Jpeg settings + (like resolution or quality) may be taken from the profile if suitable. The provided + image will be updated automatically and independent from calls to GetSnapshotUri. From d2a0c63a0198f9a6749ffb3abe2f91262a1c512d Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 12 Feb 2025 09:33:06 -0500 Subject: [PATCH 10/17] Additional formatting fixes in streaming.xml --- doc/Streaming.xml | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index 8758ad95d..d0b34093e 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -607,11 +607,11 @@ SRTP data transfer via UDP This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the SRTP authentication tag be present. For RFC 7714, it is expected that the SRTP authentication tag is not present. The optional MKI is expected to be present in SRTP packets regardless of the algorithm used. - The client may set a different key management protocol in the keymgmt attribute of the SETUP. - If the keymgmt header is present in the SETUP, the device shall use the key management protocol and key specified in the keymgmt header. + The client may set a different key management protocol in the keymgmt attribute of the SETUP. + If the keymgmt header is present in the SETUP, the device shall use the key management protocol and key specified in the keymgmt header. - Example RTSP session: + Example RTSP session: client: RTSP/1.0 200 OK server_port=9004-9005 Session: 12345678; timeout=60 ]]> - +
- Cryptographic algorithm negotiation - - If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support Media2, the SecureRTSPStreamingAlgorithms attribute of the GetServiceCapabilities response and the GetStreamUri2 action. - This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. - - - To configure which algorithm should be used by the streaming device, the client must get the list of supported SecureRTSPStreamingAlgorithms through the GetServiceCapabilities action. - The client can then choose the algorithm to use and set it in the SecurityProtocolAlgorithm attribute of the GetStreamUri2 action. - + Cryptographic algorithm negotiation + + If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support Media2, the SecureRTSPStreamingAlgorithms attribute of the GetServiceCapabilities response and the GetStreamUri2 action. + This mechanism allows the client to choose the encryption algorithm used by the device for SRTP. + + + To configure which algorithm should be used by the streaming device, the client must get the list of supported SecureRTSPStreamingAlgorithms through the GetServiceCapabilities action. + The client can then choose the algorithm to use and set it in the SecurityProtocolAlgorithm attribute of the GetStreamUri2 action. +
RTP/RTSP/HTTP/TCP From 8310d9b74ea3860dffc2ec80bd8d70ff45f6ca2f Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 12 Feb 2025 10:11:43 -0500 Subject: [PATCH 11/17] Added NONE option to RTSPS streaming --- wsdl/ver20/media/wsdl/media.wsdl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 7725d073c..ca0b92c75 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -719,6 +719,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + @@ -1875,6 +1876,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO The SecurityProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
Defined security protocol algorithms are
    +
  • NONE
  • AES_CM_128_HMAC_SHA1_80
  • AEAD_AES_128_GCM
  • AEAD_AES_256_GCM
    • From 87bda26b609cc3ce37dd57ce0988c44d0371ec04 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 11 Mar 2025 17:12:19 -0400 Subject: [PATCH 12/17] Moved srtp configuration to encoder configurations --- wsdl/ver10/schema/onvif.xsd | 64 ++++++++++++++++++++++++++++++++ wsdl/ver20/media/wsdl/media.wsdl | 51 +------------------------ 2 files changed, 65 insertions(+), 50 deletions(-) diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index c2a285338..66ccaaa21 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. + + @@ -868,6 +878,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. + + @@ -1004,6 +1019,15 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO + + + + + + + + + @@ -1059,6 +1083,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 +1185,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 +1294,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 +1342,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 +1392,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 +1422,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 +1484,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 +1566,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 ff558d684..1b5300fb6 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -152,11 +152,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates support for live media streaming via RTSPS and SRTP. - - - If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tr2:SrtpSecurityAlgorithms. - - @@ -734,15 +729,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - - - - @@ -826,41 +812,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - Defines the network protocol for streaming as defined by tr2:TransportProtocol - - - - - The ProfileToken element indicates the media profile to use and will define the configuration of the content of the stream. - - - - - Defines the cryptographic algorithm to use as defined by tr2:SrtpSecurityAlgorithms - - - - - - - - - - - - Stable Uri to be used for requesting the media stream - - - - - - - @@ -1894,7 +1845,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO
  • 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.
- The SecurityProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
+ The SecureStreamingProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
Defined security protocol algorithms are
  • NONE
    • From 5fc82a4cad879311f309ad3ea48809a7dbd2f5d8 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 12 Mar 2025 09:34:50 -0400 Subject: [PATCH 13/17] Remove changes to formatting --- wsdl/ver20/media/wsdl/media.wsdl | 70 ++++++++++++++++---------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 1b5300fb6..1b3ad6516 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -194,10 +194,10 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Reference token of an existing configuration. - Token shall be included in the AddConfiguration request along with the type. - Token shall be included in the CreateProfile request when Configuration elements are included and type is selected. - Token is optional for RemoveConfiguration request. If no token is provided in RemoveConfiguration request, device shall - remove the configuration of the type included in the profile. + Token shall be included in the AddConfiguration request along with the type. + Token shall be included in the CreateProfile request when Configuration elements are included and type is selected. + Token is optional for RemoveConfiguration request. If no token is provided in RemoveConfiguration request, device shall + remove the configuration of the type included in the profile. @@ -215,7 +215,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - A set of media configurations. + A set of media configurations. @@ -277,7 +277,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - A media profile consists of a set of media configurations. + A media profile consists of a set of media configurations. @@ -388,7 +388,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -411,7 +411,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -563,7 +563,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -575,7 +575,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -745,7 +745,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Video Media Subtype for the video format. For definitions see tt:VideoEncodingMimeNames and IANA Media Types. + Video Media Subtype for the video format. For definitions see tt:VideoEncodingMimeNames and IANA Media Types. @@ -754,7 +754,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -918,7 +918,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -952,7 +952,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicate token for video source mode. - + Indication of whether this mode is active. If active this value is true. In case of non-indication, it means as false. The value of true shall be had by only one video source mode. @@ -1153,7 +1153,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -1190,7 +1190,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + @@ -1280,14 +1280,14 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - + - + @@ -1629,7 +1629,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - This operation creates a new media profile. + This operation creates a new media profile. A created profile created via this method may be deleted via the DeleteProfile method. Optionally Configurations can be assinged to the profile on creation. For details regarding profile assignement check also the method AddConfiguration. @@ -1650,9 +1650,9 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO This operation adds one or more Configurations to an existing media profile. If a - configuration exists in the media profile, it will be replaced. A device shall - support adding a compatible Configuration to a Profile containing a VideoSourceConfiguration and shall - support streaming video data of such a profile.
    +configuration exists in the media profile, it will be replaced. A device shall +support adding a compatible Configuration to a Profile containing a VideoSourceConfiguration and shall +support streaming video data of such a profile.
    Note that OSD elements must be added via the CreateOSD command.     @@ -1765,10 +1765,10 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO     - This operation returns the available options (supported values and ranges for video encoder + This operation returns the available options (supported values and ranges for video encoder configuration parameters) when the video encoder parameters are reconfigured.
    - This response contains the available video encoder configuration options. If a video encoder configuration is specified, - the options shall concern that particular configuration. If a media profile is specified, the options shall be + This response contains the available video encoder configuration options. If a video encoder configuration is specified, + the options shall concern that particular configuration. If a media profile is specified, the options shall be compatible with that media profile. If no tokens are specified, the options shall be considered generic for the device.     @@ -1876,16 +1876,16 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO     Synchronization points allow clients to decode and correctly use all data after the - synchronization point. - For example, if a video stream is configured with a large I-frame distance and a client loses a - single packet, the client does not display video until the next I-frame is transmitted. In such - cases, the client can request a Synchronization Point which enforces the device to add an I-Frame as soon as possible. Clients can request Synchronization Points for profiles. The device - shall add synchronization points for all streams associated with this profile. - Similarly, a synchronization point is used to get an update on full PTZ or event status through - the metadata stream. - If a video stream is associated with the profile, an I-frame shall be added to this video stream. - If a PTZ metadata stream is associated to the profile, - the PTZ position shall be repeated within the metadata stream. +synchronization point. +For example, if a video stream is configured with a large I-frame distance and a client loses a +single packet, the client does not display video until the next I-frame is transmitted. In such +cases, the client can request a Synchronization Point which enforces the device to add an I-Frame as soon as possible. Clients can request Synchronization Points for profiles. The device +shall add synchronization points for all streams associated with this profile. +Similarly, a synchronization point is used to get an update on full PTZ or event status through +the metadata stream. +If a video stream is associated with the profile, an I-frame shall be added to this video stream. +If a PTZ metadata stream is associated to the profile, +the PTZ position shall be repeated within the metadata stream. From be79f84a5d6911ff0b3ace7240e94e9d3521d48f Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 12 Mar 2025 09:36:34 -0400 Subject: [PATCH 14/17] Removed references to GetStreamUri2 --- wsdl/ver20/media/wsdl/media.wsdl | 34 -------------------------------- 1 file changed, 34 deletions(-) diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index 1b3ad6516..b01959471 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -1505,12 +1505,6 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - - - - - - @@ -1831,34 +1825,6 @@ support streaming video data of such a profile.
    - - - This operation requests a URI that can be used to initiate a live media stream using RTSP as - the control protocol. The returned URI shall remain valid indefinitely even if the profile is changed.
    - Defined stream types are -
      -
    • 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.
      • -
    - If a multicast stream is requested at least one of VideoEncoder2Configuration, AudioEncoder2Configuration and MetadataConfiguration shall have a valid multicast setting.
    - The SecureStreamingProtocolAlgorithm must not be defined if a non-SRTP stream protocol is selected.
    - Defined security protocol algorithms are -
      -
    • NONE
      • -
    • AES_CM_128_HMAC_SHA1_80
      • -
    • AEAD_AES_128_GCM
      • -
    • AEAD_AES_256_GCM
      • -
    - For full compatibility with other ONVIF services a device should not generate Uris longer than - 128 octets. -     - - -     This command starts multicast streaming using a specified media profile of a device. Streaming continues until StopMulticastStreaming is called for the same Profile. The From 67a12c166edeaf50e73f270926b9a6b472c5a286 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Wed, 12 Mar 2025 09:39:10 -0400 Subject: [PATCH 15/17] Removed more formatting changes --- wsdl/ver20/media/wsdl/media.wsdl | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/wsdl/ver20/media/wsdl/media.wsdl b/wsdl/ver20/media/wsdl/media.wsdl index b01959471..794ee24b8 100644 --- a/wsdl/ver20/media/wsdl/media.wsdl +++ b/wsdl/ver20/media/wsdl/media.wsdl @@ -82,8 +82,8 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Indicates that privacy masks are only supported at the video source level and not the video source configuration level. - If this is true any addition, deletion or change of a privacy mask done for one video source configuration will automatically be + Indicates that privacy masks are only supported at the video source level and not the video source configuration level. + If this is true any addition, deletion or change of a privacy mask done for one video source configuration will automatically be applied by the device to a corresponding privacy mask for all other video source configuration associated with the same video source. @@ -354,7 +354,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Lists all profiles that exist in the media service. The response provides the requested types of Configurations as far as available. + Lists all profiles that exist in the media service. The response provides the requested types of Configurations as far as available. If a profile doesn't contain a type no error shall be provided. @@ -449,7 +449,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO     - + @@ -745,7 +745,7 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO - Video Media Subtype for the video format. For definitions see tt:VideoEncodingMimeNames and IANA Media Types. + Video Media Subtype for the video format. For definitions see tt:VideoEncodingMimeNames and IANA Media Types. @@ -1857,11 +1857,11 @@ the PTZ position shall be repeated within the metadata stream. A client uses the GetSnapshotUri command to obtain a JPEG snapshot from the - device. The returned URI shall remain valid indefinitely even if the profile is changed. The URI can be used for - acquiring a JPEG image through a HTTP GET operation. The image encoding will always be - JPEG regardless of the encoding setting in the media profile. The Jpeg settings - (like resolution or quality) may be taken from the profile if suitable. The provided - image will be updated automatically and independent from calls to GetSnapshotUri. +device. The returned URI shall remain valid indefinitely even if the profile is changed. The URI can be used for +acquiring a JPEG image through a HTTP GET operation. The image encoding will always be +JPEG regardless of the encoding setting in the media profile. The Jpeg settings +(like resolution or quality) may be taken from the profile if suitable. The provided +image will be updated automatically and independent from calls to GetSnapshotUri. From 959c3f30517ac39150892d4be49a81830ebed1c4 Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Thu, 13 Mar 2025 13:16:23 -0400 Subject: [PATCH 16/17] Added SecureRTSPStreaming to media1 Fixed optional attribute for SecureStreamingProtocolAlgorithms --- wsdl/ver10/media/wsdl/media.wsdl | 5 +++++ wsdl/ver10/schema/onvif.xsd | 7 +------ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/wsdl/ver10/media/wsdl/media.wsdl b/wsdl/ver10/media/wsdl/media.wsdl index dfdb86457..4b6687268 100644 --- a/wsdl/ver10/media/wsdl/media.wsdl +++ b/wsdl/ver10/media/wsdl/media.wsdl @@ -120,6 +120,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO Indicates the device does not support live media streaming via RTSP. + + + Indicates support for live media streaming via RTSPS and SRTP. + + diff --git a/wsdl/ver10/schema/onvif.xsd b/wsdl/ver10/schema/onvif.xsd index 66ccaaa21..b2a2f277b 100755 --- a/wsdl/ver10/schema/onvif.xsd +++ b/wsdl/ver10/schema/onvif.xsd @@ -851,7 +851,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. @@ -878,11 +878,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 tr2:SrtpSecurityAlgorithms. - - From 680af5e4b4c1b091b97bad140dc4ef357aff5dfc Mon Sep 17 00:00:00 2001 From: Jordan Careau-Beaulieu Date: Tue, 27 May 2025 11:07:20 -0400 Subject: [PATCH 17/17] Streaming spec draft --- doc/Streaming.xml | 227 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 180 insertions(+), 47 deletions(-) diff --git a/doc/Streaming.xml b/doc/Streaming.xml index d0b34093e..fcee967e1 100644 --- a/doc/Streaming.xml +++ b/doc/Streaming.xml @@ -605,62 +605,195 @@
SRTP data transfer via UDP - This mode allows secure transmission of RTP packets via UDP unicast and multicast. See RFC 3711 and RFC 7714 for transmission and RFC 4567 for key exchange. For RFC 3711, it is expected that the SRTP authentication tag be present. For RFC 7714, it is expected that the SRTP authentication tag is not present. The optional MKI is expected to be present in SRTP packets regardless of the algorithm used. + 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 client may set a different key management protocol in the keymgmt attribute of the SETUP. - If the keymgmt header is present in the SETUP, the device shall use the key management protocol and key specified in the keymgmt header. - + 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 + - Example RTSP session: + The device may list which SRTP cryptographic algorithms it supports through the Media1 and Media2 wsdls. + Each encoder can list the algorithms it supports through the SecureStreamingProtocolAlgorithms element present in: + + + AudioEncoderConfigurationOptions + + + MetadataConfigurationOptions + + + VideoEncoderConfigurationOptions + + + AudioEncoder2ConfigurationOptions + + + VideoEncoder2ConfigurationOptions + + + + 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 to authenticate with the camera without using encrypted media streams. + + + 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. - - 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 - Content-Length: XXX - v=0 - o=- 2890844256 2890842807 IN IP4 172.16.2.93 - s=RTSP Session - m=audio 0 RTP/SAVP 0 - a=key-mgmt: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... - a=control:rtsp://example.com/onvif_camera/audio - m=video 0 RTP/SAVP 26 - a=key-mgmt: mikey CQCGiO2ZhnCDCCCCCCCCCCCCCCCuC0... - a=control:rtsp://example.com/onvif_camera/video - m=application 0 RTP/SAVP 107 - a=key-mgmt: mikey EQCGiO2ZhnEDEEEEEEEEEEEEEuC0... - a=control:rtsp://example.com/onvif_camera/metadata - a=recvonly - a=rtpmap:107 vnd.onvif.metadata/90000 -client->server: SETUP rtsp://example.com/onvif_camera/audio RTSP/1.0 - Cseq: 2 - Transport: RTP/SAVP/TCP;unicast;interleaved=0-1 - keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; - data="GQCGiO2ZhnGDGGGGGGGGGGGuC3..." + + 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: + + + SetAudioEncoderConfiguration + + + SetMetadataConfiguration + + + SetVideoEncoderConfiguration + + + -server->client: RTSP/1.0 200 OK - Cseq: 2 - Transport: RTP/SAVP;unicast;client_port=8002-8003; - server_port=9004-9005 - Session: 12345678; timeout=60 -]]> - -
-
- Cryptographic algorithm negotiation - If a device supports encryption algorithms other than AES_CM_128_SHA1_80 as defined in RFC 3711, it must also support Media2, the SecureRTSPStreamingAlgorithms attribute of the GetServiceCapabilities response and the GetStreamUri2 action. + 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. + - To configure which algorithm should be used by the streaming device, the client must get the list of supported SecureRTSPStreamingAlgorithms through the GetServiceCapabilities action. - The client can then choose the algorithm to use and set it in the SecurityProtocolAlgorithm attribute of the GetStreamUri2 action. - + MIKEY is used for key management for 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. + (To verify, some cameras return RTP packets when this is done?)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. The SRTP packets must also 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 + + + + + + + + The key management extensions for SDP and RTSP (RFC 4567) allow for key management through RTSP. +
+ 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 unencrypted streaming. + + + + 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 use a different encryption algorithm than what is configured with SetAudioEncoderConfiguration, SetMetadataConfiguration and SetVideoEncoderConfiguration. + The GetAudioEncoderConfiguration, GetMetadataConfiguration and GetVideoEncoderConfiguration responses shall not be affected by the encryption algorithm configured through RTSP with MIKEY. + SetAudioEncoderConfiguration, SetMetadataConfiguration and SetVideoEncoderConfiguration shall only be used to configure the device for the default encryption algorithm sent in the DESCRIBE. + 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 client may use a different encryption algorithm than what is configured with the SetAudioEncoderConfiguration, SetMetadataConfiguration and SetVideoEncoderConfiguration actions. + +
+
+ Multicast considerations +
+
+ +
RTP/RTSP/HTTP/TCP