SRT Mop
SRT Mop
SRT Mop
Sharabayko
Internet-Draft M.A. Sharabayko
Intended status: Standards Track Haivision Network Video, GmbH
Expires: 13 March 2021 J. Dube
Haivision
JS. Kim
JW. Kim
SK Telecom Co., Ltd.
9 September 2020
Abstract
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Secure Reliable Transport Protocol . . . . . . . . . . . 4
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5
3. Packet Structure . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Packets . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Control Packets . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Key Material . . . . . . . . . . . . . . . . . . . . 17
3.2.3. Keep-Alive . . . . . . . . . . . . . . . . . . . . . 21
3.2.4. ACK (Acknowledgment) . . . . . . . . . . . . . . . . 22
3.2.5. NAK (Loss Report) . . . . . . . . . . . . . . . . . . 24
3.2.6. Shutdown . . . . . . . . . . . . . . . . . . . . . . 25
3.2.7. ACKACK . . . . . . . . . . . . . . . . . . . . . . . 26
4. SRT Data Transmission and Control . . . . . . . . . . . . . . 26
4.1. Stream Multiplexing . . . . . . . . . . . . . . . . . . . 27
4.2. Data Transmission Modes . . . . . . . . . . . . . . . . . 27
4.2.1. Message Mode . . . . . . . . . . . . . . . . . . . . 27
4.2.2. Live Mode . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3. Buffer Mode . . . . . . . . . . . . . . . . . . . . . 28
4.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 28
4.3.1. Caller-Listener Handshake . . . . . . . . . . . . . . 31
4.3.2. Rendezvous Handshake . . . . . . . . . . . . . . . . 33
4.4. SRT Buffer Latency . . . . . . . . . . . . . . . . . . . 39
4.5. Timestamp-Based Packet Delivery . . . . . . . . . . . . . 40
4.5.1. Packet Delivery Time . . . . . . . . . . . . . . . . 42
4.6. Too-Late Packet Drop . . . . . . . . . . . . . . . . . . 43
4.7. Drift Management . . . . . . . . . . . . . . . . . . . . 44
4.8. Acknowledgement and Lost Packet Handling . . . . . . . . 46
4.8.1. Packet Acknowledgement (ACKs, ACKACKs) . . . . . . . 46
4.8.2. Packet Retransmission (NAKs) . . . . . . . . . . . . 47
4.9. Bidirectional Transmission Queues . . . . . . . . . . . . 49
4.10. Round-Trip Time Estimation . . . . . . . . . . . . . . . 49
4.11. Congestion Control . . . . . . . . . . . . . . . . . . . 50
5. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1. Encryption Scope . . . . . . . . . . . . . . . . . . 51
5.1.2. AES Counter . . . . . . . . . . . . . . . . . . . . . 51
5.1.3. Stream Encrypting Key (SEK) . . . . . . . . . . . . . 51
5.1.4. Key Encrypting Key (KEK) . . . . . . . . . . . . . . 52
1. Introduction
1.1. Motivation
The demand for live video streaming has been increasing steadily for
many years. With the emergence of cloud technologies, many video
processing pipeline components have transitioned from on-premises
appliances to software running on cloud instances. While real-time
streaming over TCP-based protocols like RTMP [RTMP] is possible at
low bitrates and on a small scale, the exponential growth of the
streaming market has created a need for more powerful solutions.
To improve scalability on the delivery side, content delivery
networks (CDNs) at one point transitioned to segmentation-based
technologies like HLS (HTTP Live Streaming) [RFC8216] and DASH
(Dynamic Adaptive Streaming over HTTP) [ISO23009]. This move
increased the end-to-end latency of live streaming to over 30
seconds, which makes it unattractive for many use cases. Over time,
the industry optimized these delivery methods, bringing the latency
down to 3 seconds.
RTMP became the de facto standard for contribution over the public
Internet. But there are limitations for the payload to be
transmitted, since RTMP as a media specific protocol only supports
two audio channels and a restricted set of audio and video codecs,
lacking support for newer formats such as HEVC [H.265], VP9 [VP9], or
AV1 [AV1].
Since RTMP, HLS and DASH rely on TCP, these protocols can only
guarantee acceptable reliability over connections with low RTTs, and
can not use the bandwidth of network connections to their full extent
due to limitations imposed by congestion control. Notably, QUIC
[I-D.ietf-quic-transport] has been designed to address these problems
with HTTP-based delivery protocols in HTTP/3 [I-D.ietf-quic-http].
Like QUIC, SRT [SRTSRC] uses UDP instead of the TCP transport
protocol, but assures more reliable delivery using Automatic Repeat
Request (ARQ), packet acknowledgments, end-to-end latency management,
etc.
Derived from the UDP-based Data Transfer (UDT) protocol [GHG04b], SRT
is a user-level protocol that retains most of the core concepts and
mechanisms while introducing several refinements and enhancements,
including control packet modifications, improved flow control for
handling live streaming, enhanced congestion control, and a mechanism
for encrypting packets.
SRT maintains the ability for fast file transfers introduced in UDT,
and adds support for AES encryption.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
document.
3. Packet Structure
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SrcPort | DstPort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | ChkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ SRT Packet +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRT has two types of packets distinguished by the Packet Type Flag:
data packet and control packet.
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| (Field meaning depends on the packet type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Field meaning depends on the packet type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Packet Contents |
| (depends on the packet type) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F: 1 bit. Packet Type Flag. The control packet has this flag set to
"1". The data packet has this flag set to "0".
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P P|O|K K|R| Message Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PP: 2 bits. Packet Position Flag. This field indicates the position
of the data packet in the message. The value "10b" (binary) means
the first packet of the message. "00b" indicates a packet in the
middle. "01b" designates the last packet. If a single data packet
forms the whole message, the value is "11b".
Data: variable length. The payload of the data packet. The length
of the data is the remaining length of the UDP packet.
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Control Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Control Information Field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Type: 15 bits. Control Packet Type. The use of these bits
is determined by the control packet type definition. See Table 1.
The types of SRT control packets are shown in Table 1. The value
"0x7FFF" is reserved for a user-defined type.
+===================+==============+=========+===============+
| Packet Type | Control Type | Subtype | Section |
+===================+==============+=========+===============+
| HANDSHAKE | 0x0000 | 0x0 | Section 3.2.1 |
+-------------------+--------------+---------+---------------+
| KEEPALIVE | 0x0001 | 0x0 | Section 3.2.3 |
+-------------------+--------------+---------+---------------+
| ACK | 0x0002 | 0x0 | Section 3.2.4 |
+-------------------+--------------+---------+---------------+
| NAK (Loss Report) | 0x0003 | 0x0 | Section 3.2.5 |
+-------------------+--------------+---------+---------------+
| SHUTDOWN | 0x0005 | 0x0 | Section 3.2.6 |
+-------------------+--------------+---------+---------------+
| ACKACK | 0x0006 | 0x0 | Section 3.2.7 |
+-------------------+--------------+---------+---------------+
| User-Defined Type | 0x7FFF | - | N/A |
+-------------------+--------------+---------+---------------+
3.2.1. Handshake
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Field | Extension Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Flow Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Handshake Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRT Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYN Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Peer IP Address +
| |
+ +
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extension Type | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Extension Contents +
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Encryption Field: 16 bits. Block cipher family and key size. The
values of this field are described in Table 2. The default value
is AES-128.
+=======+============================+
| Value | Cipher family and key size |
+=======+============================+
| 0 | No Encryption Advertised |
+-------+----------------------------+
|2 | AES-128 |
+-------+----------------------------+
|3 | AES-192 |
+-------+----------------------------+
|4 | AES-256 |
+-------+----------------------------+
+============+========+
| Bitmask | Flag |
+============+========+
| 0x00000001 | HSREQ |
+------------+--------+
| 0x00000002 | KMREQ |
+------------+--------+
| 0x00000004 | CONFIG |
+------------+--------+
Table 3: Handshake
Extension Flags
Maximum Flow Window Size: 32 bits. The value of this field is the
maximum number of data packets allowed to be "in flight"
(i.e. the number of sent packets for which an ACK control packet
has not yet been received).
+============+================+
| Value | Handshake type |
+============+================+
| 0xFFFFFFFD | DONE |
+------------+----------------+
| 0xFFFFFFFE | AGREEMENT |
+------------+----------------+
| 0xFFFFFFFF | CONCLUSION |
+------------+----------------+
| 0x00000000 | WAVEHAND |
+------------+----------------+
| 0x00000001 | INDUCTION |
+------------+----------------+
SRT Socket ID: 32 bits. This field holds the ID of the source SRT
socket from which a handshake packet is issued.
SYN Cookie: 32 bits. Randomized value for processing a handshake.
The value of this field is specified by the handshake message
type. See Section 4.3.
+=======+====================+===================+
| Value | Extension Type | HS Extension Flag |
+=======+====================+===================+
| 1 | SRT_CMD_HSREQ | HSREQ |
+-------+--------------------+-------------------+
| 2 | SRT_CMD_HSRSP | HSREQ |
+-------+--------------------+-------------------+
| 3 | SRT_CMD_KMREQ | KMREQ |
+-------+--------------------+-------------------+
| 4 | SRT_CMD_KMRSP | KMREQ |
+-------+--------------------+-------------------+
| 5 | SRT_CMD_SID | CONFIG |
+-------+--------------------+-------------------+
| 6 | SRT_CMD_CONGESTION | CONFIG |
+-------+--------------------+-------------------+
| 7 | SRT_CMD_FILTER | CONFIG |
+-------+--------------------+-------------------+
| 8 | SRT_CMD_GROUP | CONFIG |
+-------+--------------------+-------------------+
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRT Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRT Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver TSBPD Delay | Sender TSBPD Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+============+===============+
| Bitmask | Flag |
+============+===============+
| 0x00000001 | TSBPDSND |
+------------+---------------+
| 0x00000002 | TSBPDRCV |
+------------+---------------+
| 0x00000004 | CRYPT |
+------------+---------------+
| 0x00000008 | TLPKTDROP |
+------------+---------------+
| 0x00000010 | PERIODICNAK |
+------------+---------------+
| 0x00000020 | REXMITFLG |
+------------+---------------+
| 0x00000040 | STREAM |
+------------+---------------+
| 0x00000080 | PACKET_FILTER |
+------------+---------------+
Table 6: Handshake
Extension Message Flags
* PERIODICNAK flag set indicates the peer will send periodic NAK
packets. See Section 4.8.2.
The extension can be supplied with the Handshake Extension Type field
set to either SRT_CMD_KMREQ or SRT_CMD_HSRSP (see Table 5 in
Section 3.2.1). For more details refer to Section 4.3.
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Stream ID |
...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits. Special flags mostly reserved for the future. See
Figure 9.
* Not yet defined (reserved for future) for any other cases.
01234567
+-+-+-+-+-+-+-+
| (zero) |M|
+-+-+-+-+-+-+-+
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| V | PT | Sign | Resv1 | KK|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEKI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher | Auth | SE | Resv2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv3 | SLen/4 | KLen/4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Wrapped Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 1: initial version
* 2: AES-CTR [SP800-38A]
* 1: MPEG-TS/UDP
* 2: MPEG-TS/SRT
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Vector (ICV) +
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| xSEK |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| oSEK |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
oSEK: variable width. This field with the odd key is present only
when the message carries the two SEKs (identified by he KK field).
3.2.3. Keep-Alive
Keep-alive control packets are sent after a certain timeout from the
last time any packet (Control or Data) was sent. The purpose of this
control packet is to notify the peer to keep the connection open when
no data exchange is taking place.
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Control Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACK packets may also carry some additional information from the
receiver like RTT, bandwidth, receiving speed, etc. The CIF portion
of the ACK control packet is expanded as follows:
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Control Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Acknowledged Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packets Receiving Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Estimated Link Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packets Receiving Rate: 32 bits. The rate at which packets are being
received, in packets per second.
* A Full ACK control packet is sent every 10 ms and has all the
fields of Figure 13.
The Lite ACK and Small ACK packets are used in cases when the
receiver should acknowledge received data packets more often than
every 10 ms. This is usually needed at high data rates. It is up to
the receiver to decide the condition and the type of ACK packet to
send (Lite or Small). The recommendation is to send a Lite ACK for
every 64 packets received.
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Control Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+- CIF (Loss List) -+-+-+-+-+-+-+-+-+-+-+-+
|0| Lost packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Range of lost packets from sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Up to sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Lost packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
future definition.
3.2.6. Shutdown
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Control Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.7. ACKACK
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Control Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple SRT sockets may share the same UDP socket so that the
packets received to this UDP socket will be correctly dispatched to
those SRT sockets they are currently destined.
During the handshake, the parties exchange their SRT Socket IDs.
These IDs are then used in the Destination Socket ID field of every
control and data packet (see Section 3).
SRT has been mainly created for Live Streaming and therefore its main
and default transmission mode is "live". SRT supports, however, the
modes that the original UDT library supported, that is, buffer and
message transmission.
4.2.1. Message Mode
The first packet of a message has the first bit of the Packet
Position Flags (Section 3.1) set to 1. The last packet of the
message has the second bit of the Packet Position Flags set to 1.
Thus, a PP equal to "11b" indicates a packet that forms the whole
message. A PP equal to "00b" indicates a packet that belongs to the
inner part of the message.
The concept of the message in SRT comes from UDT ([GHG04b]). In this
mode a single sending instruction passes exactly one piece of data
that has boundaries (a message). This message may span across
multiple UDP packets (and multiple SRT data packets). The only size
limitation is that it shall fit as a whole in the buffers of the
sender and the receiver. Although internally all operations (e.g.
ACK, NAK) on data packets are performed independently, an application
must send and receive the whole message. Until the message is
complete (all packets are received) the application will not be
allowed to read it.
Live mode is a special type of message mode where only data packets
with their PP field set to "11b" are allowed.
Additionally Timestamp-Based Packet Delivery (TSBPD) (Section 4.5)
and Too-Late Packet Drop (Section 4.6) mechanisms are used in this
mode.
In this mode consecutive packets form one continuous stream that can
be read, with portions of any size.
There are two basic types of SRT handshake extensions that are
exchanged in the handshake:
When a connection process has failed before either party can send the
CONCLUSION handshake, the Handshake Type field will contain the
appropriate error value for the rejected connection. See the list of
error codes in Table 7.
+======+================+=========================================
+
| Code | Error | Description |
+======+================+=========================================
+
| 1000 | REJ_UNKNOWN | Unknown reason |
+------+----------------+-----------------------------------------+
| 1001 | REJ_SYSTEM | System function error |
+------+----------------+-----------------------------------------+
| 1002 | REJ_PEER | Rejected by peer |
+------+----------------+-----------------------------------------+
| 1003 | REJ_RESOURCE | Resource allocation problem |
+------+----------------+-----------------------------------------+
| 1004 | REJ_ROGUE | incorrect data in handshake |
+------+----------------+-----------------------------------------+
| 1005 | REJ_BACKLOG | listener's backlog exceeded |
+------+----------------+-----------------------------------------+
| 1006 | REJ_IPE | internal program error |
+------+----------------+-----------------------------------------+
| 1007 | REJ_CLOSE | socket is closing |
+------+----------------+-----------------------------------------+
| 1008 | REJ_VERSION | peer is older version than agent's min |
+------+----------------+-----------------------------------------+
| 1009 | REJ_RDVCOOKIE | rendezvous cookie collision |
+------+----------------+-----------------------------------------+
| 1010 | REJ_BADSECRET | wrong password |
+------+----------------+-----------------------------------------+
| 1011 | REJ_UNSECURE | password required or unexpected |
+------+----------------+-----------------------------------------+
| 1012 | REJ_MESSAGEAPI | Stream flag collision |
+------+----------------+-----------------------------------------+
| 1013 | REJ_CONGESTION | incompatible congestion-controller type |
+------+----------------+-----------------------------------------+
| 1014 | REJ_FILTER | incompatible packet filter |
+------+----------------+-----------------------------------------+
| 1015 | REJ_GROUP | incompatible group |
+------+----------------+-----------------------------------------+
* Encryption Field: 0
* Extension Field: 2
* Version: 5
At this point the Listener still does not know if the Caller is SRT
or UDT, and it responds with the same set of values regardless of
whether the Caller is SRT or UDT.
Once the Caller gets the SYN cookie from the Listener, it sends the
CONCLUSION handshake to the Listener.
* Version: 5
The Listener responds with the same values shown above, without the
cookie (which is not needed here), as well as the extensions for HS
Version 5 (which will probably be exactly the same).
Both parties start with WAVEAHAND and use the Version value of 5.
Legacy Version 4 clients do not look at the Version value, whereas
Version 5 clients can detect version 5. The parties only continue
with the Version 5 Rendezvous process when Version is set to 5 for
both. Otherwise the process continues exclusively according to
Version 4 rules [GHG04b].
When one party's cookie value is greater than its peer's, it wins the
cookie contest and becomes Initiator (the other party becomes the
Responder).
At this point there are two possible "handshake flows": serial and
parallel.
4.3.2.1. Serial Handshake Flow
In the serial handshake flow, one party is always first, and the
other follows. That is, while both parties are repeatedly sending
WAVEAHAND messages, at some point one party - let's say Alice - will
find she has received a WAVEAHAND message before she can send her
next one, so she sends a CONCLUSION message in response. Meantime,
Bob (Alice's peer) has missed Alice's WAVEAHAND messages, so that
Alice's CONCLUSION is the first message Bob has received from her.
* Version: 5
While Alice does not yet know if she is sending this message to a
Version 4 or Version 5 peer, the values from these fields would not
be interpreted by the Version 4 peer when the Handshake Type is
WAVEAHAND.
* Version: 5
If Bob is the Initiator and encryption is on, he will use either his
own cipher family and block size or the one received from Alice (if
she has advertised those values).
* Version: 5
Both parties always send extension flags at this point, which will
contain HSREQ if the message comes from an Initiator, or HSRSP if it
comes from a Responder. If the Initiator has received a previous
message from the Responder containing an advertised cipher family and
block size in the encryption flags field, it will be used as the key
length for key generation sent next in the KMREQ extension.
1. Bob receives Alice's CONCLUSION message, and then does one of the
following (depending on Bob's role):
The chances of the parallel handshake flow are very low, but still it
may occur if the handshake messages with WAVEAHAND are sent and
received by both peers at precisely the same time.
The resulting flow is very much like Bob's behaviour in the serial
handshake flow, but for both parties. Alice and Bob will go through
the same state transitions:
In the Attention state they know each other's cookies, so they can
assign roles. In contrast to serial flows, which are mostly based on
request-response cycles, here everything happens completely
Sharabayko, et al. Expires 13 March 2021 [Page 36]
Initiator:
1. Waving
* Switches to Attention
2. Attention
- contains no extensions:
3. Initiated
- Contains no extensions:
4. Connected
* May receive CONCLUSION and respond with AGREEMENT, but
normally by now it should already have received payload
packets.
Responder:
1. Waving
* Switches to Attention
2. Attention
3. Initiated
* Receives:
- AGREEMENT message
- Payload packet
4. Connected
* Is not expecting to receive any handshake messages anymore.
The AGREEMENT message is always sent only once or per every
final CONCLUSION message.
Note that any of these packets may be missing, and the sending party
will never become aware. The missing packet problem is resolved this
way:
On the sender, latency is the time that SRT holds a packet to give it
a chance to be delivered successfully while maintaining the rate of
the sender at the receiver. If an acknowledgment (ACK) is missing or
late for more than the configured latency, the packet is dropped from
the sender buffer. A packet can be retransmitted as long as it
remains in the buffer for the duration of the latency window. On the
receiver, packets are delivered to an application from a buffer after
the latency interval has passed. This helps to recover from
potential packet losses. See Section 4.5, Section 4.6 for details.
The SRT receiver, using the timestamp of the SRT data packet header,
delivers packets to a receiving application with a fixed minimum
delay from the time the packet was scheduled for sending on the SRT
sender side. Basically, the sender timestamp in the received packet
is adjusted to the receiver's local time (compensating for the time
drift or different time zones) before releasing the packet to the
application. Packets can be withheld by the SRT receiver for a
configured receiver delay. A higher delay can accommodate a larger
uniform packet drop rate, or a larger packet burst drop. Packets
received after their "play time" are dropped if the Too-Late Packet
Drop feature is enabled (see Section 4.6).
| Sending | | |
| Delay | ~RTT/2 | SRT Latency |
|<--------->|<------------>|<----------------->|
| | | |
| | | |
| | | |
___ Scheduled Sent Received Scheduled
/ for sending | | for delivery
Packet | | | |
State | | | |
| | | |
| | | |
----------------------------------------------------->
Time
* "Received": the packet is received and read from the UDP socket;
It is worth noting that the round-trip time (RTT) of an SRT link may
vary in time. However the actual end-to-end latency on the link
becomes fixed and is approximately equal to (RTT_0/2 + SRT Latency)
once the SRT handshake exchange happens, where RTT_0 is the actual
value of the round-trip time during the SRT handshake exchange (the
value of the round-trip time once the SRT connection has been
established).
During the transmission process, the value of TSBPD time base may be
adjusted in two cases:
When enabled on the receiver, the receiver drops packets that have
not been delivered or retransmitted in time, and delivers the
subsequent packets to the application when it is their time to play.
<CODE BEGINS>
pos = 0; /* Current receiver buffer position */
i = 0; /* Position of the next available in the receiver buffer
packet relatively to the current buffer position pos */
while(True) {
// Get the position i of the next available packet
// in the receiver buffer
i = next_avail();
// Calculate packet delivery time PktTsbpdTime
// for the next available packet
PktTsbpdTime = delivery_time(i);
pos = i + 1;
}
<CODE ENDS>
Upon receiving the full acknowledgment (ACK) control packet, the SRT
sender should acknowledge its reception to the receiver by sending an
ACKACK control packet with the sequence number of the full ACK packet
being acknowledged.
The SRT receiver also sends NAK control packets to notify the sender
about the missing packets (Section 4.8.2). The sending of a NAK
packet can be triggered immediately after a gap in sequence numbers
of data packets is detected. In addition, a Periodic NAK report
mechanism can be used to send NAK reports periodically. The NAK
packet in that case will list all the packets that the receiver
considers being lost up to the moment the Periodic NAK report is
sent.
The SRT receiver sends NAK control packets to notify the sender about
the missing packets. The NAK packet sending can be triggered
immediately after a gap in sequence numbers of data packets is
detected.
The SRT sender maintains a list of lost packets (loss list) that is
built from NAK reports. When scheduling packet transmission, it
looks to see if a packet in the loss list has priority and sends it
if so. Otherwise, it sends the next packet scheduled for the first
transmission list. Note that when a packet is transmitted, it stays
in the buffer in case it is not received by the SRT receiver.
NAK packets are processed to fill in the loss list. As the latency
window advances and packets are dropped from the sending queue, a
check is performed to see if any of the dropped or resent packets are
in the loss list, to determine if they can be removed from there as
well so that they are not retransmitted unnecessarily.
If packets in the loss list continue to block the send queue, at some
point this will cause the send queue to fill. When the send queue is
full, the sender will begin to drop packets without even sending them
the first time. An encoder (or other application) may continue to
provide packets, but there's no place for them, so they will end up
being thrown away.
This condition where packets are unsent does not happen often. There
is a maximum number of packets held in the send buffer based on the
configured latency. Older packets that have no chance to be
retransmitted and played in time are dropped, making room for newer
real-time packets produced by the sending application. See
Section 4.5, Section 4.6 for details.
SRT Periodic NAK reports are sent with a period of (RTT + 4 * RTTVar)
/ 2 (so called NAKInterval), with a 20 milliseconds floor, where RTT
and RTTVar are defined in section Section 4.10. A NAK control packet
contains a compressed list of the lost packets. Therefore, only lost
packets are retransmitted. By using NAKInterval for the NAK reports
period, it may happen that lost packets are retransmitted more than
once, but it helps maintain low latency in the case where NAK packets
are lost.
An ACKACK tells the receiver to stop sending the ACK position because
the sender already knows it. Otherwise, ACKs (with outdated
information) would continue to be sent regularly.
An ACK sent by the receiver triggers an ACKACK from the sender with
minimal processing delay. The ACKACK response is expected to arrive
at the receiver roughly one RTT after the corresponding ACK was sent.
The SRT receiver records the time when an ACK is sent out. The ACK
carries a unique sequence number (independent of the data packet
sequence number). The corresponding ACKACK also carries the same
sequence number. Upon receiving the ACKACK, SRT calculates the RTT
by comparing the difference between the ACKACK arrival time and the
ACK departure time. In the following formula, RTT is the current
value that the receiver maintains and rtt is the recent value that
was just calculated from an ACK/ACKACK pair:
Both RTT and RTTVar are measured in microseconds. The initial value
of RTT is 100 milliseconds, RTTVar is 50 milliseconds.
The sender always gets the RTT from the receiver. It does not have
an analog to the ACK/ACKACK mechanism, i.e. it can not send a message
that guarantees an immediate return without processing. Upon an ACK
reception, the SRT sender updates its own RTT and RTTVar values using
the same formulas as above, in which case rtt is the most recent
value it receives, i.e., carried by an incoming ACK.
Note that an SRT socket can both send and receive data packets. RTT
and RTTVar are updated by the socket based on algorithms for the
sender (using ACK packets) and for the receiver (using ACK-ACKACK
pairs). When an SRT socket receives data, it updates its local RTT
and RTTVar, which can be used for its own sender as well.
SRT provides certain mechanisms for the sender to get some feedback
from the receiving side through the ACK packets (Section 3.2.4).
Every 10 ms the sender receives the latest values of RTT and RTT
variance, Available Buffer Size, Packets Receiving Rate and Estimated
Link Capacity. Upon reception of the NAK packet (Section 3.2.5) the
sender can detect packet losses during the transmission. These
mechanisms provide a solid background for various congestion control
algorithms.
Given that SRT can operate in live and file transfer modes, there are
two groups of congestion control algorithms possible.
For file transfer, any known File Congestion Control algorithms like
CUBIC [RFC8312] and BBR [BBR] can apply, including the congestion
control mechanism proposed in UDT [GHG04b], [GuAnAO]. The UDT
congestion control relies on the available link capacity, packet loss
reports (NAK) and packet acknowledgements (ACKs). It then slows down
the output of packets as needed by adjusting the packet sending pace.
In periods of congestion, it can block the main stream and focus on
the lost packets.
5. Encryption
5.1. Overview
SRT encrypts only the payload of SRT data packets (Section 3.1),
while the header is left unencrypted. The unencrypted header
contains the Packet Sequence Number field used to keep the
synchronization of the cipher counter between the encrypting sender
and the decrypting receiver. No constraints apply to the payload of
SRT data packets as no padding of the payload is required by counter
mode ciphers.
The counter for AES-CTR is the size of the cipher's block, i.e. 128
bits. It is derived from a 128-bit sequence consisting of
The upper 112 bits of this sequence are XORed with an Initialization
Vector (IV) to produce a unique counter for each crypto block. The
IV is derived from the Salt provided in the Keying Material
(Section 3.2.2):
The key used for AES-CTR encryption is called the "Stream Encrypting
Key" (SEK). It is used for up to 2^25 packets with further rekeying.
The short-lived SEK is generated by the sender using a pseudo-random
number generator (PRNG), and transmitted within the stream, wrapped
with another longer-term key, the Key Encrypting Key (KEK), using a
known AES key wrap protocol.
The responder returns the same KM message to show that it has the
same information as the initiator, and that the encoded material will
be decrypted. If the responder does not return this status, this
means that it does not have the SEK. All incoming encrypted packets
5.1.6. KM Refresh
Even and odd keys are alternated during transmission the following
way. The packets with the earlier key #1 (let it be the odd key)
will continue to be sent. The receiver will receive the new key #2
(even), then decrypt and unwrap it. The receiver will reply to the
sender if it is able to understand. Once the sender gets to the
2^25th packet using the odd key (key #1), it will then start to send
packets with the even key (key #2), knowing that the receiver has
what it needs to decrypt them. This happens transparently, from one
packet to the next. At 2^25 plus 4000 packets the first key will be
decommissioned automatically.
Both keys live in parallel for two times the Pre-Announcement Period
(e.g. 4000 packets before the key switch, and 4000 packets after).
This is to allow for packet retransmission. It is possible for
packets with the older key to arrive at the receiver a bit late.
Each packet contains a description of which key it requires, so the
receiver will still have the ability to decrypt it.
On the sending side SEK, Salt and KEK are generated the following
way:
SEK = PRNG(KLen)
Salt = PRNG(128)
KEK = PBKDF2(passphrase, LSB(64,Salt), Iter, Klen)
where
The encryption of the payload of the SRT DATA packet is done with
AES-CTR
where
The decryption of the payload of the SRT data packet is done with
AES-CTR
6. Security Considerations
7. IANA Considerations
Contributors
Acknowledgments
The basis of the SRT protocol and its implementation was the UDP-
based Data Transfer Protocol [GHG04b]. The authors thank Yunhong Gu
and Robert Grossman, the authors of the UDP-based Data Transfer
Protocol [GHG04b].
TODO acknowledge.
References
Normative References
Informative References
[BBR] Cardwell, N., Cheng, Y., Gunn, C.S., Yeganeh, S.H., and V.
Jacobson, "BBR: Congestion-Based Congestion Control",
October 2016.
[GuAnAO] Gu, Y., Hong, X., and R.L. Grossman, "An Analysis of AIMD
Algorithm with Decreasing Increases", October 2004.
[I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-29, 9 June 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-quic-http-29.txt>.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-29, 9 June 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-29.txt>.
[ISO13818-1]
ISO, "Information technology -- Generic coding of moving
pictures and associated audio information: Systems", ISO/
IEC 13818-1, September 2020.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>.
Sharabayko, et al. Expires 13 March 2021 [Page 58]
[SP800-38A]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", December 2001.
For any single packet sequence number, it uses the original sequence
number in the field. The first bit MUST start with "0".
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Sequence Number a (first) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Sequence Number b (last) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: - this marks the YAML format, the only one currently used
The content format, which is either:
: - the comma-separated keys with no nesting
{ - like above, but nesting is allowed and must end with }
(Nesting means that you can have multiple level brace-enclosed parts
inside.)
key1=value1,key2=value2...
Beside the general syntax, there are several top-level keys treated
as standard keys. All single letter key definitions, including those
not listed in this section, are reserved for future use. Users can
additionally use custom key definitions with user_* or companyname_*
prefixes, where user and companyname are to be replaced with an
actual user or company name.
The existing key values MUST not be extended, and MUST not differ
from those described in this section.
Note that "m" is not required in the case where Stream ID is not used
to distinguish authorization or resources, and the caller is expected
to send the data. This is only for cases where the listener can
handle various purposes of the connection and is therefore required
to know what the caller is attempting to do.
B.3. Examples
#!::u=admin,r=bluesbrothers1_hi
#!::u=johnny,t=file,m=publish,r=results.csv
Appendix C. Changelog
Authors' Addresses
Maxim Sharabayko
Haivision Network Video, GmbH
Email: maxsharabayko@haivision.com
Maria Sharabayko
Haivision Network Video, GmbH
Email: msharabayko@haivision.com
Jean Dube
Haivision
Email: jdube@haivision.com
Jeongseok Kim
SK Telecom Co., Ltd.
Email: jeongseok.kim@sk.com
Joonwoong Kim
SK Telecom Co., Ltd.
Email: joonwoong.kim@sk.com