Secure Reliable Transport
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
Secure Reliable Transport (SRT) is an open source video transport protocol that utilises the UDP transport protocol. The SRT Protocol specification is available as an Internet Draft from the IETF.[1]
Overview
SRT provides connection and control, reliable transmission similar to TCP; however, it does so at the application layer, using UDP protocol as an underlying transport layer. It supports packet recovery while maintaining low latency (default: 120 ms). SRT also supports encryption using AES.
The protocol was derived from the UDT project,[2] which was designed for fast file transmission. It provided the reliability mechanism by utilising similar methods for connection, sequence numbers, acknowledgements and re-transmission of lost packets. It utilises selective and immediate (NAK-based) re-transmission.
SRT added several features on top of that in order to support live streaming mode:
- Controlled latency, with source time transmission (timestamp-based packet delivery)
- Relaxed sender speed control
- Conditional "too late" packet dropping (prevents head-of-line blocking caused by a lost packet that wasn't recovered on time)
- Eager packet re-transmission (periodic NAK-report)
Packet header
SRT packets are created at the application layer and handed to the transport layer for delivery. Each unit of SRT media or control data created by an application begins with the SRT packet header.[1]
| Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit[lower-alpha 1] | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | F | Field meaning depends on the packet type | ||||||||||||||||||||||||||||||
| 4 | 32 | Field meaning depends on the packet type | |||||||||||||||||||||||||||||||
| 8 | 64 | Timestamp | |||||||||||||||||||||||||||||||
| 12 | 96 | Destination Socket ID | |||||||||||||||||||||||||||||||
| ... | ... | Packet Contents (depends on the packet type) | |||||||||||||||||||||||||||||||
Data packet
| Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit[lower-alpha 1] | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | 0 | Packet Sequence Number | ||||||||||||||||||||||||||||||
| 4 | 32 | PP | O | KK | R | Message Number | |||||||||||||||||||||||||||
| 8 | 64 | Timestamp | |||||||||||||||||||||||||||||||
| 12 | 96 | Destination Socket ID | |||||||||||||||||||||||||||||||
| ... | ... | Data | |||||||||||||||||||||||||||||||
The fields in the header are as follows:
- Packet Sequence Number (31 bits)
- PP (2 bits): Packet Position Flag
- O (1 bit): Order Flag
- KK (2 bits): Key-based Encryption Flag
- R (1 bit): Retransmitted Packet Flag
- Message Number (26 bits)
- Data (variable length)
Control packet
| Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit[lower-alpha 1] | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | 1 | Control Type | Subtype | |||||||||||||||||||||||||||||
| 4 | 32 | Type-specific Information | |||||||||||||||||||||||||||||||
| 8 | 64 | Timestamp | |||||||||||||||||||||||||||||||
| 12 | 96 | Destination Socket ID | |||||||||||||||||||||||||||||||
| ... | ... | Control Information Field (CIF) | |||||||||||||||||||||||||||||||
The fields in the header are as follows:
- Control Type (15 bits): Control Packet Type
- Subtype (16 bits)
- Type-specific Information (32 bits)
- Control Information Field (variable length)
History
Secure Reliable Transport is an open source video transport protocol developed originally by Haivision. According to SRT Alliance, an organisation that promotes the technology, it optimises streaming performance. This helps minimise effects of jitter and bandwidth changes, while error-correction mechanisms help minimise packet loss. SRT supports end-to-end encryption with AES.[3] When performing retransmissions, SRT only attempts to retransmit packets for a limited amount of time based on the latency as configured by the application.[4]
According to Marc Cymontkowski, the architect of SRT, in addition to sending MPEG transport streams over the public internet, it is also being used for IoT connectivity, metadata exchange, as a communication protocol, as well as for uncompressed data delivery.[5]
The reference implementation of the protocol was originally published under the Lesser General Public License version 2.1,[6] but was relicensed under the Mozilla Public License on 22 March 2018.[7]
SRT is supported in the free software multimedia frameworks GStreamer, FFmpeg, OBS Studio and in VLC free software media player.[4][8]
The UDP-based Data Transfer Protocol (UDT) project has been a base for the SRT project.[9] The SRT C API is largely based in design on the UDT API[10]
SRT was designed for low-latency live video transmission.[9][3]
Haivision released the SRT protocol and reference implementation as open source at the 2017 NAB Show.[9]
In March 2020, an individual Internet-Draft, draft-sharabayko-mops-srt,[1] was submitted for consideration to the Media OPerationS (MOPS) working group of the Internet Engineering Task Force.
SRT Alliance
SRT Alliance is an organisation whose members develop, use and promote the Secure Reliable Transport protocol and software based on it. The founding members of the alliance are Haivision and Wowza Streaming Engine.[11]
Implementations
There's currently one available implementation, which is the open-source SRT library.
The C language API is mainly based on the previous UDT API, with further changes as new features are added. The API is very similar to the one of TCP.
SRT offers actually three working modes, of which the first two were derived from UDT:
- File-stream mode: like TCP
- File-message mode: similar to SCTP protocol – sending blocks of data with clearly defined boundaries
- Live mode: the data should be sent in small packets (usually up to 1316 bytes, if the transmitted stream is MPEG-TS) with already appropriate time intervals between them. The same single packets with the same time intervals between them are then delivered at the receiver side.
The SRT library also offers these features:
- Encryption using a pre-shared key. Encryption support was originally provided by OpenSSL, now also alternatively, Nettle (GNU TLS) or mbedTLS can be used.
- SRT Access Control (aka "StreamID") can be used by applications to identify resources and use user-password access method while using the same service port number for multiple purposes.[12]
- The optional Forward Error Correction mechanism.
Further and more detailed documentation can be found in the Source code documentation.
See also
- Reliable Internet Stream Transport, intended to fill a gap in the market for professional protocols as opposed to the 'prosumer' SRT.[13]
Notes
- ↑ 1.0 1.1 1.2 Bits are ordered most significant to least significant; bit offset 0 is the most significant bit of the first octet. Octets are transmitted in network order. Bit transmission order is medium dependent.
References
- ↑ 1.0 1.1 1.2 Sharabayko, M.P; Sharabayko, M.A (2021), The SRT Protocol, IETF, I-D draft-sharabayko-srt-01, https://tools.ietf.org/html/draft-sharabayko-srt-01, retrieved 20 October 2023
- ↑ "UDT: Breaking the Data Transfer Bottleneck". https://udt.sourceforge.io/.
- ↑ 3.0 3.1 Haivision (26 September 2021). "Secure, Reliable, Transport". GitHub. https://github.com/Haivision/srt.
- ↑ 4.0 4.1 Olivier Crête (16 February 2018). "SRT in GStreamer". https://www.collabora.com/news-and-blog/blog/2018/02/16/srt-in-gstreamer/.
- ↑ "It glues everything together: an interview with Marc Cymontkowski, evangelist of SRT". 5 November 2019. https://blog.medialooks.com/it-glues-everything-together-an-interview-with-marc-cymontkowski-evangelist-of-srt-ad1d08790bd0.
- ↑ Michael Larabel (24 April 2017). "SRT Video Transport Protocol Open-Sourced". Phoronix. https://www.phoronix.com/scan.php?page=news_item&px=SRT-Open-Sourced.
- ↑ Roman rndi (22 March 2018). "Change License to MPLv2.0 · Haivision/srt@a75d4c4". GitHub. https://github.com/Haivision/srt/commit/a75d4c40cd6e140ffa0491fe93fe4d759085877d#diff-9879d6db96fd29134fc802214163b95a.
- ↑ Olivier Crête (June 2018). "Secure Video Comes of Age". Linux Format magazine (237). https://www.collabora.com/news-and-blog/blog/2018/06/25/secure-video-comes-of-age/.
- ↑ 9.0 9.1 9.2 Marc Cymontkowski. "Why We Created SRT and the Difference Between SRT and UDT".
- ↑ "Haivision srt API docs"
- ↑ "Microsoft Joins SRT Open Source Streaming Project". 17 September 2018. https://www.thebroadcastbridge.com/content/entry/12014/microsoft-joins-srt-open-source-streaming-project.
- ↑ "SRT Access Control Guidelines". 7 November 2019. https://github.com/Haivision/srt/blob/master/docs/AccessControl.md.
- ↑ "5 Reasons You Should Pick RIST over SRT" (in en-US). https://www.rist.tv/articles-and-deep-dives/2020/5/27/5-reasons-you-should-pick-rist-over-srt.
External links
 |  |
