Secure Streaming in ONVIF is not automatically synonymous with SRTP. Understand its meaning in Profile T, RTP/RTSP/HTTPS/TCP transport, and the evolution toward SecureRTSPStreaming with RTSPS and SRTP.
Check it out!
Secure Streaming, in the context of ONVIF Profile T, should be interpreted based on the transport function defined by the profile itself: streaming over RTP/RTSP/HTTPS/TCP. In the Profile T v1.0 specification, published in September 2018, this function is classified as conditional. Therefore, a device’s conformity with Profile T does not, by itself, establish that it supports this protected streaming mode.
This definition should also not be confused with SRTP — Secure Real-time Transport Protocol. In more recent ONVIF specifications, there is a distinct capability called SecureRTSPStreaming, associated with RTSPS and SRTP. The difference is architectural: in the HTTPS streaming referenced by Profile T, protection is provided by TLS on the HTTPS channel; in modern SecureRTSPStreaming, RTSP control uses TLS and the media can be protected directly by SRTP.
This distinction is especially important in design, technical specifications, procurement, and qualification of cameras and VMS platforms. Requiring only “ONVIF Profile T” is not the same as requiring the HTTPS streaming feature; likewise, finding “Secure Streaming” in the conformity declaration of a Profile T product should not automatically be interpreted as proof of SRTP support.
Why Does the Term Secure Streaming Cause Confusion in ONVIF?
“Secure Streaming” is an intuitive expression, but technically broad. Outside a normative context, it can be used to describe virtually any mechanism that protects a media stream in transit. Within the ONVIF ecosystem, however, it is necessary to identify which specification, profile, capability, or function is being considered.
The first point is that Secure Streaming is not the name of a network protocol. The mechanisms used by ONVIF are built on existing protocols and services such as RTP, RTCP, RTSP, HTTP, HTTPS, TCP, UDP, TLS, and, in newer specifications, SRTP.
The second point is that an ONVIF Profile is not a protocol either. A profile defines a fixed set of functions so that devices and clients from different manufacturers have a predictable interoperability baseline. The underlying functions are detailed in the ONVIF Network Interface Specifications.
Therefore, three expressions that appear similar need to be kept separate:
| Expression | Technical meaning |
| ONVIF Profile T | ONVIF profile for advanced IP video functions and interoperability between device and client |
| Streaming over RTP/RTSP/HTTPS/TCP | HTTPS/TLS-protected transport function referenced by Profile T |
| SecureRTSPStreaming | Newer Media2 capability for secure streaming via RTSPS and SRTP |
Mixing these three layers leads to specification errors. The most common is to state that “Profile T Secure Streaming is SRTP.” That statement does not match how Profile T v1.0 defines its secure-streaming function.
What Does ONVIF Profile T Establish About Secure Streaming?
Profile T was published for IP-based video systems and includes functions related to H.264/H.265, image configuration, events, metadata streaming, and other video capabilities. To understand Secure Streaming, however, the most important reference is Section 7.9 — Video streaming of the Profile T v1.0 specification.
For a device, the specification establishes, among other requirements, support for streaming over RTP/UDP and over RTP/RTSP/HTTP/TCP. It then establishes that, if supported, the device should be capable of streaming video over RTP/RTSP/HTTPS/TCP using the selected Media Profile.
In the Profile T Function List, the distinction is explicit:
| Streaming function | Profile T device |
| Streaming over RTP/UDP | M — Mandatory |
| Streaming over RTP/RTSP/HTTP/TCP | M — Mandatory |
| Streaming over RTP/RTSP/HTTPS/TCP | C — Conditional |
| Streaming over RTP/UDP Multicast | M — Mandatory |
| Streaming over RTP/RTSP/TCP/WebSocket | C — Conditional |
For clients, Streaming over RTP/RTSP/HTTPS/TCP also appears as a conditional function.
This produces an important practical consequence: Profile T and HTTPS streaming support are not equivalent. A product can conform to Profile T without this conditional function being present. When the design requirement is to actually use the protected stream, it is necessary to verify the conformity declaration and features applicable to the model and firmware being offered.
What Does “Conditional” Mean in Profile T?
The specification itself defines requirement levels. A conditional feature or function must be implemented according to ONVIF when the device or client supports that functionality under the conditions defined by the profile. It does not simply become mandatory for every Profile T product.
This differs from a function marked as M — Mandatory, which forms part of the minimum required for the corresponding conformity.
For specification engineering, this distinction is decisive. A statement such as “the equipment shall be ONVIF Profile T” does not demonstrate compliance with every conditional capability in the profile.
Before Security: How Is Video Streaming Organized?
To understand where HTTPS, TLS, and SRTP operate, it is necessary to separate encoding, transport, session control, and cryptographic protection.
H.264 and H.265 are video coding formats. They define how visual information is compressed and represented, but they are not responsible for transporting video across the network or establishing a session between a camera and VMS.
Real-time transport is normally performed by RTP — Real-time Transport ProtocolThe RTSP — Real Time Streaming Protocol is used to control the streaming session. In a simplified representation:
Captured image ↓ H.264 / H.265 ↓ RTP ↓ RTSP control ↓ IP networkRTP — Media Transport
RTP organizes real-time media transmission. Its header includes information used to interpret the stream, such as sequence number, timestamp, and payload type. In IP video systems, it is the protocol that actually carries the media encapsulated according to the applicable formats.
RTP by itself should not be treated as an encryption mechanism. A conventional RTP stream does not gain confidentiality simply because it is transported over a closed IP network.
RTCP — Control Associated with RTP
RTCP is the control protocol associated with RTP and can carry quality and session-synchronization information. It should not be confused with RTSP.
RTCP and RTSP are different protocols. RTCP accompanies RTP operation; RTSP is used to establish and control the streaming session.
RTSP — Session Control
RTSP enables operations such as session establishment, description, playback, and termination. Methods such as DESCRIBE, SETUP, PLAY and TEARDOWN are part of this logic.
Therefore, simply saying that “RTSP transports the video” is an imprecise simplification. In a conventional session, RTSP controls the session while RTP transports the media.
Main Transport Methods Considered by ONVIF
The ONVIF Streaming Specifications describe different transport methods for different network scenarios.
RTP over UDP
RTP can use UDP directly. This arrangement has low overhead and is particularly suited to the time-sensitive nature of audio and video, but it does not provide cryptographic confidentiality by itself.
RTP ↓ UDP ↓ IPInterleaved RTP over RTSP/TCP
RTP media can also be transported within the TCP channel associated with RTSP using the interleaved binary-data mechanism.
RTP ↓ RTSP / TCP ↓ IPRTP/RTSP over HTTP/TCP
ONVIF also specifies tunneling via HTTP, traditionally useful for traversing environments in which HTTP traffic is more readily allowed through firewalls and proxies.
RTP ↓ RTSP ↓ HTTP ↓ TCPRTP/RTSP over HTTPS/TCP
When this tunneling is performed over HTTPS, the HTTP connection is protected by TLS:
Video / audio / metadata ↓ RTP ↓ RTSP ↓ HTTP tunneling ↓ HTTPS ↓ TLS ↓ TCP ↓ IPThis is the arrangement — RTP/RTSP/HTTPS/TCP — that should be associated with the conditional secure/HTTPS streaming function in Profile T.
Where Is the Security in RTP/RTSP/HTTPS/TCP?
In the mechanism referenced by Profile T, protection does not result from transforming RTP into SRTP. It results from TLS used by HTTPS.
In simplified terms, HTTPS can be understood as HTTP operating over a TLS session. TLS provides protection mechanisms for data traversing that channel, including confidentiality and integrity in transit, as well as endpoint-authentication mechanisms depending on the certificate and trust configuration used.
This means the architectural model differs from protecting each RTP packet directly with SRTP.
TLS Is Not an Encryption Algorithm
Another frequent mistake is treating TLS as synonymous with AES. TLS is a security protocol that establishes a protected session and negotiates the applicable cryptographic mechanisms. AES may be part of the cipher suites used, but it is not correct to define “TLS = AES.”
Likewise, the mere presence of the term HTTPS should not be taken as proof of a specific cipher suite without verifying the TLS version and configuration actually used by the endpoints.
Certificates and Trust
The security of a TLS session also depends on how the client validates the endpoint’s identity. Digital certificates, the trust chain, and validation policies are part of the design of a secure deployment.
A self-signed certificate can provide encryption, but it requires a coherent trust model so that the client knows it is communicating with the intended device. In corporate environments, certificate management should be treated as part of the security architecture, not merely as a camera web-interface option.
Profile T Secure Streaming Is Not Synonymous with SRTP
This is the most important distinction in this topic.
In Profile T v1.0, the conditional secure-transport function is described as:
Streaming over RTP/RTSP/HTTPS/TCP.
It is not described as “SRTP.” RTP media remains within the RTSP/HTTP tunneling architecture while TLS protects the HTTPS channel.
In a simplified representation:
SRTP operates differently:
In both cases there is protection of media in transit, but the point at which protection is applied and the protocol architecture are not the same.
Therefore, the expression “Profile T with Secure Streaming” should not be used as automatic proof of SRTP support.
What Is SecureRTSPStreaming in More Recent ONVIF Specifications?
The evolution of the ONVIF Network Interface Specifications introduced a distinct capability called SecureRTSPStreaming.
In the Media2 Service Specification 26.06, the capability is described as indicating support for live media streaming via RTSPS and SRTP. This definition clearly separates the modern mechanism from the HTTPS streaming referenced by Profile T.
Media2 also distinguishes among different streaming capabilities, such as:
RTSPStreaming— live streaming via RTSP;SecureRTSPStreaming— live streaming via RTSPS and SRTP;RTPMulticast— support for UDP multicast;RTP_RTSP_TCP— support for RTP/RTSP/TCP;RTSPWebSocketUri— support for RTSP/RTP transport over WebSocket, according to the applicable specification.
The difference in naming is relevant: SecureRTSPStreaming is a specific capability, not merely an alternate way of writing the conditional HTTPS function in Profile T.
What Is RTSPS?
RTSPS represents RTSP operating over a TLS-protected connection.
In simplified form:
RTSP ↓ TLS ↓ TCPIn current secure-streaming specifications with SRTP, the secure RTSP channel matters because session-establishment and management information cannot be transmitted insecurely while attempting to create cryptographically protected media.
ONVIF Streaming Specification 26.06 establishes that TLS must be used for RTSP when SRTP is used. The specification also determines that a device should not return RTP/SAVP or MIKEY information in SDP if the RTSP channel is not secure.
This detail demonstrates that there are two distinct protection surfaces:
- control plane — RTSP commands and negotiation protected by TLS;
- media plane — RTP media protected by SRTP.
How Does SRTP Work?
SRTP — Secure Real-time Transport Protocol is a security extension for RTP. Instead of relying on an external TLS tunnel to protect the media, SRTP applies cryptographic mechanisms directly to the RTP stream.
Conceptually:
Conventional RTP ↓ SRTP protection ↓ SRTP / UDP ↓ IP networkSRTP provides confidentiality protection, media integrity/authentication according to the negotiated algorithm, and mechanisms related to replay protection. The associated control protocol, SRTCP, applies corresponding protection to RTP control traffic.
RTP/AVP and RTP/SAVP
Conventional RTP sessions may use the profile RTP/AVP. For sessions protected by SRTP, RTP/SAVP, indicating use of the Secure Audio/Video Profile.
This distinction is relevant during SDP negotiation of a secure session.
SRTP Algorithms Defined by ONVIF Specification 26.06
Streaming Specification 26.06 defines mechanisms for negotiating the cryptographic algorithms used by SRTP. Listed algorithms include:
| Identifier | Primary protection |
AES_CM_128_HMAC_SHA1_80 | AES in counter mode + HMAC-SHA-1 with an 80-bit authentication tag |
AEAD_AES_128_GCM | AES-128-GCM in AEAD mode |
AEAD_AES_256_GCM | AES-256-GCM in AEAD mode |
NONE | configuration case without SRTP media protection, under the conditions provided by the specification |
Another common mistake must be avoided here: the existence of NONE does not mean ONVIF classifies completely unprotected media as equivalent to secure SRTP. The specification allows scenarios in which secure RTSP remains in operation and the media may traverse a TLS channel depending on the selected transport.
Therefore, implementation analysis should consider capability, the transport actually selected, and the negotiated algorithm, not merely an interface label.
MIKEY: Key Management for SRTP
To encrypt media with SRTP, the device and client need to share or establish the key material used by the session. ONVIF uses MIKEY — Multimedia Internet KEYing for this purpose within the architecture defined for Secure RTSP Streaming.
The current Streaming Specification establishes MIKEY support for key exchange and key management in devices that signal SecureRTSPStreaming.
The conceptual flow can be represented as follows:
The specification also addresses key renewal during the session. This is important for long-running operations, where key lifecycle management should not depend on a single static initial configuration.
Comparison: Conventional Streaming, HTTPS Streaming, and SecureRTSPStreaming
The table below summarizes architectures that should not be confused.
| Architecture | Control | Media transport | Primary protection layer | ONVIF relationship |
| RTP/RTSP/UDP | RTSP | RTP/UDP | no inherent cryptographic protection | conventional streaming |
| RTP/RTSP/TCP | RTSP | interleaved RTP/TCP | no inherent cryptographic protection | conventional streaming |
| RTP/RTSP/HTTPS/TCP | tunneled RTSP | tunneled RTP | TLS on HTTPS | conditional function referenced by Profile T |
| RTSPS + SRTP | RTSP over TLS | SRTP, typically over UDP | TLS on control + SRTP on media | SecureRTSPStreaming in current specifications |
This table provides the safest way to interpret the term in technical documentation: first identify which architecture is in use; then evaluate the security properties of that architecture.
What Does “Secure Streaming: Yes” Mean in an ONVIF Declaration?
When evaluating equipment in the conformant-products database, it is common to find information that a given model supports Profile T and, separately, a feature identified as Secure Streaming.
Within the Profile T feature set, this information should be correlated with the HTTPS streaming function defined in the profile, namely RTP/RTSP/HTTPS/TCP.
The presence of two separate pieces of information is intentionally important for procurement:
Profile T: conformant + Secure Streaming: Yesis not the same statement as:
Profile T: conformantby itself.
Likewise, Secure Streaming: Yes in the context of Profile T should not be transformed into:
SRTP: provenwithout additional technical evidence of the corresponding modern capability.
How to Correctly Verify Conformity of a Camera or VMS
ONVIF recommends using the official Conformant Products database to confirm product conformity. A generic commercial statement that the brand “is ONVIF” is not sufficient.
The analysis should consider at least:
1. manufacturer; 2. exact model; 3. firmware version associated with the declaration; 4. declared profiles; 5. relevant conditional features; 6. capability and implementation documentation; 7. corresponding support in the client/VMS.
This last step is frequently overlooked. Interoperability is a property of the relationship between device and client. The camera may provide a secure mode that the VMS does not implement, or the VMS may implement the function while the offered device does not provide it.
In engineering terms:
device support + client support + compatible configuration = operational functionalityHow to Specify Secure Streaming in a Design, Technical Specification, or Terms of Reference
When the technical objective is to protect transport between the camera and VMS, the specification should state the intended capability. Using only the profile name can produce an incomplete requirement.
A specification that states only:
> “The camera shall be ONVIF Profile T compliant.”
establishes a relevant interoperability requirement, but does not specifically demonstrate the presence of RTP/RTSP/HTTPS/TCP, because this function is conditional in Profile T.
When the design requires the HTTPS streaming function, the requirement should be stated more precisely, for example:
> The equipment shall be ONVIF Profile T compliant and support streaming over RTP/RTSP/HTTPS/TCP, demonstrated by official conformity documentation and/or features applicable to the offered model and firmware.
This wording should be adapted to the contracting context and the evidence model adopted in the document.
When the Requirement Is Specifically SRTP
If the project’s cybersecurity architecture requires the RTP media itself to be protected by SRTP, it is not sufficient to write only “Profile T with Secure Streaming.”
In that case, the specification should explicitly establish the requirement for RTSPS/SRTP or SecureRTSPStreaming, together with evidence mechanisms and compatibility between device and client.
It is also advisable to verify:
- supported algorithms;
- support for Media2/applicable capabilities;
- actual interoperability with the VMS;
- TLS certificate management;
- key-management behavior;
- impact on unicast/multicast and the adopted topology;
- commissioning procedures.
What Does Secure Streaming Protect — and What Does It Not Protect?
Transport encryption is an important security layer, but it should not be presented as complete protection for the video-surveillance system.
Confidentiality in Transit
A central objective is to reduce the possibility that media can be understood by a third party that gains access to the network path, provided that the session and endpoints are configured correctly.
Transport Integrity
TLS and SRTP include mechanisms intended to detect unauthorized changes to protected data during transport, within the security models of each protocol.
Endpoint Authentication
TLS can use certificates for authentication and establishment of trust. This property depends on correct certificate validation and the client’s trust policy.
User Authentication and Authorization Are Another Layer
Encrypting the stream does not replace identity and access controls. Weak passwords, shared credentials, excessive privileges, or compromised administrative accounts remain independent risks.
| Security issue | Related mechanism |
| Traffic confidentiality | TLS / SRTP |
| Integrity in transit | TLS / SRTP |
| Endpoint identity | TLS/certificates, depending on implementation |
| User authentication | system authentication mechanisms |
| Authorization | privilege policy and access control |
| Integrity/authenticity of stored recordings | specific evidence/media-signing mechanisms |
| Segmentation and containment | network architecture, VLAN, ACL, firewall |
Secure Streaming Is Not Media Signing
Another concept that needs to remain separate is Media Signing.
Secure Streaming concerns protection of communications in transit. Media Signing, in turn, is related to the ability to verify media authenticity and integrity properties according to the specific signing architecture defined by ONVIF.
The fact that a recording was transmitted over a secure channel does not automatically mean it has a verifiable signature capable of later demonstrating its origin or absence of modification. Likewise, a media-signing solution does not replace the need to protect transport while media traverses the network.
They are complementary controls for different problems.
Secure Streaming Also Does Not Replace Network Security
Even when video and control traffic use appropriate cryptographic mechanisms, the system still needs to be designed as cyber-physical infrastructure.
Complementary controls include:
- logical network segmentation;
- VLANs and policies between segments;
- ACLs and firewall;
- restriction of management interfaces;
- certificate management;
- device hardening;
- firmware updates and lifecycle management;
- disabling unnecessary services;
- individualized accounts and least privilege;
- event and log monitoring.
Path encryption reduces one category of risk. It does not make compromised endpoints trustworthy or correct a permissive network architecture.
Architecture Impacts: TLS/TCP and SRTP/UDP Are Not Equivalent
Transport design also has operational implications.
An RTP/RTSP/HTTPS/TCP session uses TCP and TLS. This involves session establishment, cryptographic processing, and TCP’s reliable-delivery behavior. Under certain conditions, packet loss may result in retransmissions and head-of-line blocking.
SRTP, in turn, can preserve the time-sensitive behavior of RTP over UDP while adding cryptographic protection to the media. This does not mean, however, that SRTP is universally “faster” or that HTTPS streaming necessarily produces perceptible delay.
Actual behavior depends on factors such as:
- device processing capacity;
- cryptographic acceleration;
- number of simultaneous streams;
- bitrate;
- resolution and frame rate;
- network conditions;
- recording architecture;
- VMS capacity;
- unicast or multicast strategy.
These factors should be evaluated through sizing and testing, not through generic performance claims.
ONVIF Evolution: From HTTPS Streaming to Formal SRTP Support
It is important to interpret the evolution of the specifications without retroactively rewriting the meaning of Profile T.
2018 — Profile T v1.0
Profile T consolidated the use of Media2 and included Streaming over RTP/RTSP/HTTPS/TCP as a conditional video function. This is the appropriate reference when interpreting Secure Streaming associated with Profile T.
Later Generations of Media2
Media2 specifications began exposing the capability SecureRTSPStreaming, explicitly related to RTSPS and SRTP.
June 2026 — Network Interface Specifications 26.06
ONVIF’s official history records, in version 26.06, the addition of SRTP support in the Streaming Specification. The current specification details SRTP transport over UDP, algorithm negotiation, mandatory use of TLS on the RTSP channel when SRTP is used, and key management through MIKEY.
The correct formulation, therefore, is not to say that “ONVIF changed the meaning of Profile T Secure Streaming.” The correct statement is that the Network Interface Specifications evolved and now also specify Secure RTSP Streaming based on RTSPS and SRTP, coexisting with the HTTPS streaming function that is part of Profile T.
Common Errors About Secure Streaming and ONVIF
| Claim | Correct interpretation |
| “Secure Streaming is SRTP.” | Not as the definition of the Profile T function. In Profile T, the reference is RTP/RTSP/HTTPS/TCP. |
| “Every Profile T product has Secure Streaming.” | No. The HTTPS function is conditional. |
| “Profile T + Secure Streaming proves SRTP.” | No. SRTP must be demonstrated by the specific capability/implementation. |
| “HTTPS and SRTP provide the same protection.” | No. HTTPS protects a TLS channel; SRTP protects RTP media. |
| “RTSP is the protocol that carries the video.” | RTSP controls the session; RTP is the media protocol. |
| “TLS is AES.” | TLS is a security protocol that negotiates cryptographic mechanisms. |
| “Encrypted streaming guarantees camera security.” | No. Endpoints, credentials, firmware, and the network remain within the threat model. |
| “Secure streaming guarantees forensic validity or authenticity of the recording.” | No. Transport protection and evidence management/authenticity are different problems. |
Engineering Checklist for Procurement and Commissioning
When requiring Secure Streaming in a video-surveillance system, analysis should not end with the commercial datasheet. The engineering process can use the following checklist:
1. confirm the product in the official ONVIF Conformant Products database; 2. verify the exact model and declared firmware version; 3. confirm Profile T when it is part of the interoperability requirement; 4. specifically verify the HTTPS streaming function when required; 5. do not infer SRTP solely from Profile T; 6. for SRTP, verify the capability SecureRTSPStreaming and applicable technical documentation; 7. confirm equivalent support in the VMS/client; 8. define certificate and TLS trust policy; 9. test session establishment and reconnection; 10. validate the transport actually used during commissioning; 11. assess performance impacts using the actual number of streams; 12. document configuration, firmware, and test evidence in the As-Built documentation.
In higher-criticality environments, commissioning may include controlled traffic capture to verify the transport mode, without turning this activity into an attempt to bypass the system’s security controls.
Secure Streaming Should Be Treated as a Verifiable Engineering Requirement
The main lesson is that profile names and commercial labels do not replace technical requirements.
In the context of ONVIF Profile T, Secure Streaming should be associated with the conditional function RTP/RTSP/HTTPS/TCP, in which protection in transit is provided by HTTPS/TLS. This function is not mandatory for all Profile T devices and clients and therefore needs to be verified when it is part of the design requirements.
SecureRTSPStreaming, on the other hand, is a newer capability in the ONVIF Network Interface Specifications and is associated with RTSPS and SRTP. In this architecture, TLS protects the RTSP control channel and SRTP protects the media, with negotiation and key-management mechanisms defined by the specification.
In video-surveillance specifications, procurement, and Owner’s Engineering, the correct approach is to require the required capability and evidence of compliance, linking device, client, firmware, configuration, and interoperability testing. This approach prevents expressions such as “ONVIF Profile T,” “Secure Streaming,” and “SRTP” from being treated as equivalent when they technically represent different elements of the architecture.
Technical References
[1] ONVIF. ONVIF Profile T Specification v1.0. September 2018. https://www.onvif.org/wp-content/uploads/2018/09/ONVIF_Profile_T_Specification_v1-0.pdf
[2] ONVIF. Profile T — For advanced video streaming. https://www.onvif.org/profiles/profile-t/
[3] ONVIF. Streaming Specification, Version 26.06. June 2026. https://www.onvif.org/specs/2606/ONVIF-Streaming-Spec-v2606.pdf
[4] ONVIF. Media2 Service Specification, Version 26.06. June 2026. https://www.onvif.org/specs/2606/ONVIF-Media2-Service-Spec-v2606.pdf
[5] ONVIF. Specification History — Version 26.06. https://www.onvif.org/profiles/specifications/specification-history/
[6] ONVIF. Profiles Conformance Device Test Specification 26.06. June 2026. https://www.onvif.org/wp-content/uploads/2026/07/ONVIF_Profiles_Conformance_Device_Test_Specification_26.06.pdf
[7] IETF / RFC Editor. RFC 3711 — The Secure Real-time Transport Protocol (SRTP). https://www.rfc-editor.org/rfc/rfc3711
[8] IETF / RFC Editor. RFC 3830 — MIKEY: Multimedia Internet KEYing. https://www.rfc-editor.org/rfc/rfc3830
Frequently Asked Questions
No. In the Profile T v1.0 specification, Streaming over RTP/RTSP/HTTPS/TCP is a conditional function. Therefore, Profile T conformity by itself does not demonstrate this capability.
No. In Profile T v1.0, the function associated with secure streaming is RTP/RTSP/HTTPS/TCP, protected by HTTPS/TLS. SRTP is part of the newer SecureRTSPStreaming capability.
In Media2 Service Specification 26.06, SecureRTSPStreaming indicates support for live media streaming via RTSPS and SRTP.
It is RTSP operating over TLS. In the current ONVIF architecture for SRTP, TLS protects the RTSP channel used to establish and manage the secure session.
No. The Secure Streaming feature associated with Profile T should be interpreted in the context of HTTPS streaming. If SRTP is required, it must be explicitly verified in the capability and applicable documentation.
Verify the model and firmware in the official ONVIF Conformant Products database, the declared profiles, and the applicable features/capabilities. In design, corresponding support from the VMS/client also needs to be confirmed.
No. Secure streaming protects communications in transit. Verifiable integrity and authenticity of stored media involve other mechanisms, such as media signing and evidence-management controls.
