SRT and RIST contribution streaming

SRT and RIST transport media across networks with packet loss and delay. Check the required protocol, recovery settings and compatible endpoints.

Overview#

Secure Reliable Transport (SRT) and Reliable Internet Stream Transport (RIST) are UDP based contribution transport families designed to carry media across lossy or variable networks with retransmission and bounded playout delay. They can be useful between an authorised camera gateway, mobile unit, operations centre, cloud ingest, or recorder edge. They aren't camera management profiles and don't replace ONVIF, RTSP control, WebRTC signalling, recording policy, event semantics, or evidence management.

SRT and RIST are separate protocol families. Similar goals don't make their endpoints interoperable.

Standards and status boundary#

The expired SRT Internet Draft and the separate srt-rfc repository can help explain protocol design, but neither may be cited as an IETF standard. Pin the implementation/library release and supported feature set alongside protocol documentation. SRT DRAFT SRT RFC

SRT library 1.5.6, released on 20 July 2026, included security relevant fixes. That release baseline doesn't prove a vendor appliance incorporates the same code, build options, patches, or behaviour. Obtain the product software bill of materials or vendor release evidence and track later advisories. SRT RELEASES

Contribution path and system boundary#

camera / encoder
      |
      v
authorized contribution sender
  packetization + bounded recovery + optional protection
      |
      v
untrusted or variable IP path
      |
      v
authorized contribution receiver
  bounded reorder/recovery + payload validation
      |
      v
VMS / recorder / media gateway

The contribution sender and receiver are security endpoints. If a gateway terminates RTSP, SRT/RIST, MPEG transport, encryption, or tenancy, it can access and alter media and timing. Document every termination and don't describe the path as end to end protected across a component that decrypts or repacketizes it.

What reliable means#

SRT and RIST use sequence aware packet recovery and retransmission to improve delivery over networks with loss, jitter, and reordering. Recovery is constrained by the configured latency/recovery window and available bandwidth. Packets that can't be recovered before their usefulness deadline can still be dropped.

Reliable contribution does not mean:

• lossless delivery under unlimited loss or outage;
• exactly once frame or event processing;
• authenticated media origin unless the selected security/profile design establishes it;
• guaranteed decoder recovery after missing codec dependencies;
• recorder commit, retention, or evidentiary integrity;
• physical camera health or live scene visibility.

A protocol recovered packet can still contain malformed or malicious media. Validate the inner MPEG transport stream, RTP, elementary stream, codec, metadata, and container at their own trust boundaries.

SRT model#

SRT is built over UDP and commonly carries continuous live media such as MPEG transport streams. Implementations expose connection roles often described as caller, listener, and rendezvous. These are connection establishment roles, not user or tenant authorisation roles.

Core engineering dimensions include:

• socket/connection role and exact local/remote address policy;
• live/message/file mode supported by the product and the chosen payload contract;
• latency/recovery settings in both directions and their negotiation behaviour;
• packet sequence, retransmission, late drop, reordering, and timestamp based delivery behaviour;
• bandwidth overhead allowance and congestion response;
• stream routing identifier syntax and trust treatment;
• encryption capability, key length/profile, key rotation, and authentication surrounding the session;
• reconnect, peer change, failover, and statistics reset behaviour.

Latency and recovery#

The receiver needs enough buffering for path round trip time, jitter, reordering, retransmission, and processing. Too little latency turns recoverable loss into late loss. Excessive latency delays operator awareness and can increase memory use. Measure the complete path under expected and adverse conditions, including asymmetric routes and congestion; don't copy one vendor's latency value into a different topology.

Bound socket buffers, recovery queues, maximum bitrate, packet size, retransmission overhead, connection count, and CPU. A loss burst can increase both retransmissions and inner decoder work at the worst moment.

Stream identifier#

SRT's stream identifier can convey application routing or admission metadata under deployment defined conventions. It is untrusted client input until the receiving application authenticates and authorises it. Don't place permanent credentials, personal data, internal topology, or access decisions in a stream identifier; it can appear in diagnostics and intermediary logs. Define length, character/encoding, duplicate key, normalisation, tenancy, and unknown field rules.

Encryption and identity#

SRT implementations can provide payload encryption based on a shared secret/passphrase configuration. Encryption support and a matching passphrase don't establish a named user, device inventory record, tenant, purpose, or stream authorisation. Define peer admission separately, use unique scoped secrets, protect them at rest, rotate them, and decide fail closed behaviour. Reject empty, default, or downgraded protection when encryption is required.

RIST profiles#

RIST is standardised through Video Services Forum TR 06 Technical Recommendations. The profiles establish interoperable subsets and add capabilities in stages. Don't infer Main or Advanced support from “RIST,” and don't infer that an implementation supports every optional feature in a profile.

Simple Profile#

The Simple Profile defines the baseline interoperable media transport and packet recovery behaviour. Record payload/RTP expectations, recovery timing, feedback path, addressing, multicast/unicast use, and any redundancy feature actually supported. Its simplicity doesn't supply application identity, recording semantics, or a universal security policy.

Main and Advanced Profiles#

The Main and Advanced Profiles add standardised capabilities for more complex contribution systems. Security, tunneling, stream multiplexing, link behaviour, and management expectations must be taken from the selected TR 06 edition and product conformance statement; they shouldn't be back projected onto a Simple Profile endpoint. Where the selected profile uses DTLS, pre shared material, certificates, or another protection mechanism, record the exact role, identity, trust, algorithm, renewal, and failure behaviour.

Profile names aren't performance tiers. A later profile doesn't remove the need to agree payload, bitrate, latency, retransmission window, protection, network path, failover, and monitoring.

Addressing and ports#

Neither family has one universal deployment port that safely identifies every SRT or RIST stream. Products, orchestration systems, examples, unicast paths, multicast groups, and multiplexed/tunneled profiles vary. Even where a service name registration or vendor default exists, a port number isn't proof of protocol, encryption, peer identity, or authorised content.

Maintain an explicit flow inventory containing source/destination identities, address families, UDP ports, direction, expected bitrate/packet rate, payload, profile, protection, and owner. Allowlist those flows; avoid wide inbound UDP ranges or Internet exposed listeners without a designed admission and denial of service boundary.

Payload and codec contract#

Agree the complete inner contract:

• MPEG transport stream, RTP, or other supported payload;
• program, PID, stream, SSRC, payload type, codec, profile/level, resolution, rate, and audio layout as applicable;
• continuity counters, PCR/timestamp/clock basis, jitter and discontinuity behaviour;
• codec parameter sets and keyframe/random access strategy;
• metadata, captions, ancillary data, encryption, and unsupported stream policy;
• maximum aggregate bitrate, burst, packet, elementary unit, frame, and decoded dimensions.

The contribution protocol can't compensate for a missing keyframe, invalid continuity, incompatible codec, clock discontinuity, or decoder resource exhaustion. Treat payload metadata and declared dimensions/rates as untrusted until bounded.

Failover and path diversity#

Multi path, bonding, redundant senders, or receiver failover can improve availability, but they also change duplicate, reordering, identity, and cost behaviour. Verify whether paths are truly diverse or share power, carrier, NAT, firewall, or cloud region dependencies.

Define:

• active/active versus active/standby behaviour;
• packet/stream deduplication scope and sequence continuity;
• acceptable skew and payload identity between redundant senders;
• authorisation when source address, receiver, or orchestration owner changes;
• whether failback is automatic and how flapping is suppressed;
• how gaps, duplicates, codec reset, timestamps, and recording continuity are surfaced.

A reconnected stream with the same label isn't automatically the same authenticated source or continuous evidence record.

Security and privacy#

• Authenticate the sender/receiver or surrounding orchestration with device/workload identities, not a stream label alone.
• Authorise tenant, site, camera, purpose, destination, time window, and payload profile.
• Use supported confidentiality and integrity protection appropriate to the selected SRT implementation or RIST profile; prohibit silent downgrade.
• Segment contribution ingress from camera management, VMS administration, storage, and general corporate networks.
• Rate limit handshakes, invalid packets, retransmission feedback, stream ID parsing, and connection attempts before expensive allocation.
• Protect management APIs, metrics, debug dumps, packet captures, orchestration tokens, shared secrets, and certificates.
• Minimize topology, credential, camera identity, and personal information in stream identifiers and logs.
• Patch protocol libraries and appliances using vendor/SBOM evidence; the SRT 1.5.6 fixes illustrate why the embedded library baseline matters.

Network encryption doesn't decide whether a user may view, record, export, or retain the media. Apply privacy, recording notice, retention, redaction, and evidence policy at the application and recorder layers.

Observability and evidence#

Useful per direction metrics include connection state, authenticated peer, uptime, bitrate/packet rate, round trip time, configured/effective latency, packets lost/recovered/retransmitted/late/dropped, reorder depth, send/receive buffer occupancy, payload continuity errors, decoder health, reconnects, and failover path.

Keep metric labels bounded. A client controlled stream identifier shouldn't become an unrestricted high cardinality or log injection field. Correlate transport health with source encoder, network path, receiver, decoder, and recorder commit; green contribution transport alone can coexist with a frozen camera image or failed recording.

SRT/RIST delivery doesn't create evidentiary authenticity. For evidence, preserve source provenance, original bitstream where required, hashes/signatures, trusted time and uncertainty, transformations, gap/discontinuity records, authorisation, chain of custody, and player/decoder requirements.

Safe review and acceptance model#

Documentation review can establish a proposed compatibility contract without contacting an endpoint. Use vendor capability statements, selected SRT release or RIST TR 06 profile, sanitised configuration exports, network flow design, payload samples approved for offline review, and security/evidence controls. Operational packet loss, jitter, failover, codec, encryption, interoperability, and performance acceptance belongs in an owner controlled environment under a separate validation record.

Design and evidence checklist#

• SRT implementation/library release or RIST TR 06 profile/edition and product subset pinned
• SRT never represented as an IETF Standard; expired draft status recorded where cited
• Connection roles, endpoint identity, flow direction, address/port, admission, and tenancy explicit
• Payload/container/RTP, codec, timing, metadata, bitrate, packet, frame, and decoder limits defined
• Latency/recovery window derived from measured path budget and operator requirement
• Retransmission overhead, buffers, connection count, CPU, and denial of service limits bounded
• Encryption/integrity mode, authenticated identity, secret/certificate lifecycle, and downgrade policy defined
• Stream identifiers treated as untrusted routing metadata, not credentials
• Redundant path, deduplication, failover/failback, sequence, clock, and recording continuity behaviour documented
• Contribution termination and every plaintext/media trust boundary shown
• Transport statistics correlated with encoder, payload/decoder, and recorder health
• Privacy, view/record authorisation, retention, export, and evidentiary controls applied independently

Sources#

• SRT ALLIANCE, SRT Alliance, protocol ecosystem and public resources, accessed 25 August 2026.
• SRT RELEASES, Haivision SRT releases, including SRT 1.5.6 released 20 July 2026.
• SRT DRAFT, Expired IETF Internet Draft: The Secure Reliable Transport Protocol, IETF Datatracker; never published as an RFC.
• SRT RFC, SRT protocol specification repository, Haivision, work maintained outside the IETF standards stream.
• VSF TR, VSF Technical Recommendations, including RIST TR-06-1:2020, TR-06-2:2024, and TR-06-3:2024.

Section overview · Wiki home