idnits 2.17.1 draft-sharabayko-mops-srt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOPS M.P. Sharabayko 3 Internet-Draft M.A. Sharabayko 4 Intended status: Standards Track Haivision Network Video, GmbH 5 Expires: 10 September 2020 J. Dube 6 Haivision 7 JS. Kim 8 JW. Kim 9 SK Telecom Co., Ltd. 10 9 March 2020 12 The SRT Protocol 13 draft-sharabayko-mops-srt-00 15 Abstract 17 This document specifies Secure Reliable Transport (SRT) protocol. 18 SRT is a user-level protocol over User Datagram Protocol and provides 19 reliability and security optimized for low latency live video 20 streaming, as well as generic bulk data transfer. For this, SRT 21 introduces control packet extension, improved flow control, enhanced 22 congestion control and a mechanism for data encryption. 24 Note to Readers 26 Source for this draft and an issue tracker can be found at 27 https://github.com/haivision/srt-rfc (https://github.com/haivision/ 28 srt-rfc). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 10 September 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Secure Reliable Transport Protocol . . . . . . . . . . . 4 66 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 67 3. Packet Structure . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Data Packets . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Control Packets . . . . . . . . . . . . . . . . . . . . . 8 70 3.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2.2. Keep-Alive . . . . . . . . . . . . . . . . . . . . . 17 72 3.2.3. ACK (Acknowledgement) . . . . . . . . . . . . . . . . 18 73 3.2.4. NAK (Loss Report) . . . . . . . . . . . . . . . . . . 20 74 3.2.5. Shutdown . . . . . . . . . . . . . . . . . . . . . . 21 75 3.2.6. ACKACK . . . . . . . . . . . . . . . . . . . . . . . 22 76 4. SRT Data Transmission and Control . . . . . . . . . . . . . . 23 77 4.1. Stream Multiplexing . . . . . . . . . . . . . . . . . . . 23 78 4.2. Data Transmission Modes . . . . . . . . . . . . . . . . . 23 79 4.2.1. Message Mode . . . . . . . . . . . . . . . . . . . . 23 80 4.2.2. Live Mode . . . . . . . . . . . . . . . . . . . . . . 24 81 4.2.3. Buffer Mode . . . . . . . . . . . . . . . . . . . . . 24 82 4.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 24 83 4.3.1. Caller-Listener Handshake . . . . . . . . . . . . . . 28 84 4.3.2. Rendezvous Handshake . . . . . . . . . . . . . . . . 30 85 4.4. SRT Buffer Latency . . . . . . . . . . . . . . . . . . . 36 86 4.5. Timestamp Based Packet Delivery . . . . . . . . . . . . . 37 87 4.5.1. Packet Delivery Time . . . . . . . . . . . . . . . . 38 88 4.6. Too-Late Packet Drop . . . . . . . . . . . . . . . . . . 40 89 4.7. Drift Management . . . . . . . . . . . . . . . . . . . . 41 90 4.8. Acknowledgement and Lost Packet Handling . . . . . . . . 42 91 4.8.1. Packet Acknowledgement (ACKs, ACKACKs) . . . . . . . 43 92 4.8.2. Packet Retransmission (NAKs) . . . . . . . . . . . . 44 93 4.9. Bidirectional Transmission Queues . . . . . . . . . . . . 45 94 4.10. Round Trip Time Estimation . . . . . . . . . . . . . . . 45 95 4.11. Congestion Control . . . . . . . . . . . . . . . . . . . 45 96 5. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 46 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 99 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 46 100 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 101 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 102 Normative References . . . . . . . . . . . . . . . . . . . . . 47 103 Informative References . . . . . . . . . . . . . . . . . . . . 47 104 Appendix A. Packet Sequence List coding . . . . . . . . . . . . 49 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 107 1. Introduction 109 1.1. Motivation 111 The demand for live video streaming has been increasing steadily for 112 many years. With the emergence of cloud technologies, many video 113 processing pipeline components have transitioned from on-premises 114 appliances to software running on cloud instances. While real-time 115 streaming over TCP-based protocols like RTMP[RTMP] is possible at low 116 bitrates and on a small scale, the exponential growth of the 117 streaming market has created a need for more powerful solutions. 119 To improve scalability on the delivery side, content delivery 120 networks (CDNs) at one point transitioned to segmentation-based 121 technologies like HLS (HTTP Live Streaming)[RFC8216] and DASH 122 (Dynamic Adaptive Streaming over HTTP)[ISO23009]. This move 123 increased the end-to-end latency of live streaming to over 30 124 seconds, which makes it unattractive for many use cases. Over time, 125 the industry optimized these delivery methods, bringing the latency 126 down to 3 seconds. 128 While the delivery side scaled up, improvements to video transcoding 129 became a necessity. Viewers watch video streams on a variety of 130 different devices, connected over different types of networks. Since 131 upload bandwidth from on-premises locations is often limited, video 132 transcoding moved to the cloud. 134 RTMP became the de facto standard for contribution over the public 135 internet. But there are limitations for the payload to be 136 transmitted, since RTMP as a media specific protocol only supports 137 two audio channels and a restricted set of audio and video codecs, 138 lacking support for newer formats such as HEVC[H.265], VP9[VP9], or 139 AV1[AV1]. 141 Since RTMP, HLS and DASH rely on TCP, these protocols can only 142 guarantee acceptable reliability over connections with low RTTs, and 143 can not use the bandwidth of network connections to their full extent 144 due to limitations imposed by congestion control. Notably, 145 QUIC[I-D.ietf-quic-transport] has been designed to address these 146 problems with HTTP-based delivery protocols in 147 HTTP/3[I-D.ietf-quic-http]. Like QUIC, SRT[SRTSRC] uses UDP instead 148 of the TCP transport protocol, but includes features which assure 149 more reliable delivery. 151 1.2. Secure Reliable Transport Protocol 153 Low latency video transmissions across reliable (usually local) IP 154 based networks typically take the form of MPEG-TS[ISO13818-1] unicast 155 or multicast streams using the UDP/RTP protocol, where any packet 156 loss can be mitigated by enabling forward error correction (FEC). 157 Achieving the same low latency between sites in different cities, 158 countries or even continents is more challenging. While it is 159 possible with satellite links or dedicated MPLS[RFC3031] networks, 160 these are expensive solutions. The use of public internet 161 connectivity, while less expensive, imposes significant bandwidth 162 overhead to achieve the necessary level of packet loss recovery. 163 Introducing selective packet retransmission (reliable UDP) to recover 164 from packet loss removes those limitations. 166 Derived from the UDP-based Data Transfer protocol (UDT), SRT is a 167 user-level protocol that retains most of the core concepts and 168 mechanisms while introducing several refinements and enhancements, 169 including control packet modifications, improved flow control for 170 handling live streaming, enhanced congestion control, and a mechanism 171 for encrypting packets. 173 SRT is a transport protocol that enables the secure, reliable 174 transport of data across unpredictable networks, such as the 175 Internet. While any data type can be transferred via SRT, it is 176 ideal for low latency (sub-second) video streaming. SRT provides 177 improved bandwidth utilization compared to RTMP, allowing much higher 178 contribution bitrates over long distance connections. 180 As packets are streamed from source to destination, SRT detects and 181 adapts to the real-time network conditions between the two endpoints, 182 and helps compensate for jitter and bandwidth fluctuations due to 183 congestion over noisy networks. Its error recovery mechanism 184 minimizes the packet loss typical of Internet connections. 186 To achieve low latency streaming, SRT had to address timing issues. 187 The characteristics of a stream from a source network are completely 188 changed by transmission over the public internet, which introduces 189 delays, jitter, and packet loss. This, in turn, leads to problems 190 with decoding, as the audio and video decoders do not receive packets 191 at the expected times. The use of large buffers helps, but latency 192 is increased. 194 SRT includes a mechanism that recreates the signal characteristics on 195 the receiver side, reducing the need for buffering. 197 Like TCP, SRT employs a listener/caller model. The data flow is bi- 198 directional and independent of the connection initiation - either the 199 sender or receiver can operate as listener or caller to initiate a 200 connection. The protocol provides an internal multiplexing 201 mechanism, allowing multiple SRT connections to share the same UDP 202 port, providing access control functionality to identify the caller 203 on the listener side. 205 Supporting forward error correction (FEC) and selective packet 206 retransmission (ARQ), SRT provides the flexibility to use either of 207 the two mechanisms or both combined, allowing for use cases ranging 208 from the lowest possible latency to the highest possible reliability. 210 SRT maintains the ability for fast file transfers introduced in UDT, 211 and adds support for AES encryption. 213 2. Conventions and Definitions 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 3. Packet Structure 223 SRT packets are transmitted in UDP packets [RFC0768]. Every UDP 224 packet carrying SRT traffic contains an SRT header (immediately after 225 the UDP header). 227 0 1 2 3 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | SrcPort | DstPort | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Len | ChkSum | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 + SRT Packet + 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1: SRT packet as UDP payload 240 SRT has two types of packets distinguished by the Packet Type Flag: 241 data packet and control packet. The structure of the SRT packet is 242 shown in Figure 2. 244 0 1 2 3 245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 246 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |F| (Field meaning depends on the packet type) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | (Field meaning depends on the packet type) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Timestamp | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Destination Socket ID | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 + Packet Contents | 257 | (depends on the packet type) + 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2: SRT packet structure 263 F (1 bit): Packet Type Flag. The control packet has this flag set 264 to "1". The data packet has this flag set to "0". 266 Timestamp (32 bits): The time stamp of the packet in microseconds. 267 The value is relative to the time the SRT connection was 268 established. Depending on the transmission mode (Section 4.2), 269 the field stores the packet send time or the packet origin time. 271 Destination Socket ID (32 bits): A fixed-width field providing the 272 SRT socket ID to which a packet should be dispatched. The field 273 may have the special value "0" when the packet is a connection 274 request. 276 3.1. Data Packets 278 The structure of the SRT data packet is shown in Figure 3. 280 0 1 2 3 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 282 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |0| Packet Sequence Number | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |P P|O|K K|R| Message Number | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Timestamp | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Destination Socket ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 + Data + 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 3: data packet structure 298 Packet Sequence Number (31 bits): The sequential number of the data 299 packet. 301 PP (2 bits): Packet Position Flag. This field indicates the 302 position of the data packet in the message. The value "10b" 303 (binary) means the first packet of the message. "00b" indicates a 304 packet in the middle. "01b" designates the last packet. If a 305 single data packet forms the whole message, the value is "11b". 307 O (1 bit): Order Flag. Indicates whether the message should be 308 delivered by the receiver in order (1) or not (0). Certain 309 restrictions apply depending on the data transmission mode used 310 (Section 4.2). 312 KK (2 bits): Key-based Encryption Flag. The flag bits indicate 313 whether or not data is encrypted. The value "00b" (binary) means 314 data is not encrypted. "01b" indicates that data is encrypted with 315 an even key, and "10b" is used for odd key encryption. Refer to 316 Section 5. The value "11b" is only used in control packets. 318 R (1 bit): Retransmitted Packet Flag. This flag is clear when a 319 packet is transmitted the first time. The flag is set to "1" when 320 a packet is retransmitted. 322 Message Number (26 bits): The sequential number of consecutive data 323 packets that form a message (see PP field). 325 Data (variable length): The payload of the data packet. The length 326 of the data is the remaining length of the UDP packet. 328 3.2. Control Packets 330 An SRT control packet has the following structure. 332 0 1 2 3 333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 334 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |1| Control Type | Subtype | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type-specific Information | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Timestamp | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Destination Socket ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 + Control Information Field + 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 4: control packet structure 350 Control Type (15 bits): Control Packet Type. The use of these bits 351 is determined by the control packet type definition. See Table 1. 353 Subtype (16 bits): This field specifies an additional subtype for 354 specific packets. See Table 1. 356 Type-specific Information (32 bits): The use of this field depends 357 on the particular control packet type. Handshake packets do not 358 use this field. 360 Control Information Field (variable length): The use of this field 361 is defined by the Control Type field of the control packet. 363 The types of SRT control packets are shown in Table 1. The value 364 "0x7ffff" is reserved for a user-defined type. 366 +-------------------+--------------+---------+---------------+ 367 | Packet Type | Control Type | Subtype | Section | 368 +===================+==============+=========+===============+ 369 | HANDSHAKE | 0x0000 | 0x0 | Section 3.2.1 | 370 +-------------------+--------------+---------+---------------+ 371 | KEEPALIVE | 0x0001 | 0x0 | Section 3.2.2 | 372 +-------------------+--------------+---------+---------------+ 373 | ACK | 0x0002 | 0x0 | Section 3.2.3 | 374 +-------------------+--------------+---------+---------------+ 375 | NAK (Loss Report) | 0x0003 | 0x0 | Section 3.2.4 | 376 +-------------------+--------------+---------+---------------+ 377 | SHUTDOWN | 0x0005 | 0x0 | Section 3.2.5 | 378 +-------------------+--------------+---------+---------------+ 379 | ACKACK | 0x0006 | 0x0 | Section 3.2.6 | 380 +-------------------+--------------+---------+---------------+ 381 | User-Defined Type | 0x7FFF | - | N/A | 382 +-------------------+--------------+---------+---------------+ 384 Table 1: SRT Control Packet Types 386 3.2.1. Handshake 388 Handshake control packets (Control Type = 0x0000) are used to 389 exchange peer configurations, to agree on connection parameters, and 390 to establish a connection. 392 The Control Information Field (CIF) of a handshake control packet is 393 shown in Figure 5. 395 0 1 2 3 396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Version | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Encryption Field | Extension Field | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Initial Packet Sequence Number | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Maximum Transmission Unit Size | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Maximum Flow Window Size | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Handshake Type | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | SRT Socket ID | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SYN Cookie | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 + + 416 | | 417 + Peer IP Address + 418 | | 419 + + 420 | | 421 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 422 | Extension Type | Extension Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 + Extension Contents + 426 | | 427 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 429 Figure 5: handshake packet structure 431 Version (32 bits): A base protocol version number. Currently used 432 values are 4 and 5. Values greater than 5 are reserved for future 433 use. 435 Encryption Field (16 bits): Block cipher family and block size. The 436 values of this field are described in Table 2. 438 +-------+------------------------------+ 439 | Value | Cipher family and block size | 440 +=======+==============================+ 441 | 0 | No Encryption | 442 +-------+------------------------------+ 443 | 2 | AES-128 | 444 +-------+------------------------------+ 445 | 3 | AES-192 | 446 +-------+------------------------------+ 447 | 4 | AES-256 | 448 +-------+------------------------------+ 450 Table 2: Handshake Encryption Field 451 Values 453 Extension Field (16 bits): This field is message specific extension 454 related to Handshake Type field. The value must be set to 0 455 except for the following cases. (1) If the handshake control 456 packet is the INDUCTION message, this field is sent back by the 457 Listener. (2) In the case of a CONCLUSION message, this field 458 value should contain a combination of Extension Type values. For 459 more details, see Section 4.3.1. 461 +------------+--------+ 462 | Bitmask | Flag | 463 +============+========+ 464 | 0x00000001 | HSREQ | 465 +------------+--------+ 466 | 0x00000002 | KMREQ | 467 +------------+--------+ 468 | 0x00000004 | CONFIG | 469 +------------+--------+ 471 Table 3: Handshake 472 Extension Flags 474 Initial Packet Sequence Number (32 bits): The sequence number of the 475 very first data packet to be sent. 477 Maximum Transmission Unit Size (32 bits): This value is typically 478 set to 1500, which is the default Maximum Transmission Unit (MTU) 479 size for Ethernet, but can be less. 481 Maximum Flow Window Size (32 bits): The value of this field is the 482 maximum number of data packets allowed to be "in flight" 484 (i.e. the number of sent packets for which an ACK control packet 485 has not yet been received). 487 Handshake Type (32 bits): This field indicates the handshake packet 488 type. The possible values are described in Table 4. For more 489 details refer to Section 4.3. 491 +------------+----------------+ 492 | Value | Handshake type | 493 +============+================+ 494 | 0xFFFFFFFD | DONE | 495 +------------+----------------+ 496 | 0xFFFFFFFE | AGREEMENT | 497 +------------+----------------+ 498 | 0xFFFFFFFF | CONCLUSION | 499 +------------+----------------+ 500 | 0x00000000 | WAVEHAND | 501 +------------+----------------+ 502 | 0x00000001 | INDUCTION | 503 +------------+----------------+ 505 Table 4: Handshake Type 507 SRT Socket ID (32 bits): This field holds the ID of the source SRT 508 socket from which a handshake packet is issued. 510 SYN Cookie (32 bits): Randomized value for processing a handshake. 511 The value of this field is specified by the handshake message 512 type. See Section 4.3. 514 Peer IP Address (128 bits): The sender's IPv4 or IPv6 address. The 515 value consists of four 32-bit fields. In the case of IPv4 516 addresses, fields 2, 3 and 4 are padded with zeroes. 518 Extension Type (16 bits): The value of this field is used to process 519 an integrated handshake. There are two extensions: Handshake 520 Extension Message (Section 3.2.1.1) and Key Material Exchange 521 (Section 3.2.1.2). Each extension can have a pair of request and 522 response types. 524 +-------+--------------------+-------------------+ 525 | Value | Extension Type | HS Extension Flag | 526 +=======+====================+===================+ 527 | 1 | SRT_CMD_HSREQ | HSREQ | 528 +-------+--------------------+-------------------+ 529 | 2 | SRT_CMD_HSRSP | HSREQ | 530 +-------+--------------------+-------------------+ 531 | 3 | SRT_CMD_KMREQ | KMREQ | 532 +-------+--------------------+-------------------+ 533 | 4 | SRT_CMD_KMRSP | KMREQ | 534 +-------+--------------------+-------------------+ 535 | 5 | SRT_CMD_SID | CONFIG | 536 +-------+--------------------+-------------------+ 537 | 6 | SRT_CMD_CONGESTION | CONFIG | 538 +-------+--------------------+-------------------+ 539 | 7 | SRT_CMD_FILTER | CONFIG | 540 +-------+--------------------+-------------------+ 541 | 8 | SRT_CMD_GROUP | CONFIG | 542 +-------+--------------------+-------------------+ 544 Table 5: Handshake Extension Type values 546 Extension Length (16 bits): The length of the Extension Contents 547 field. 549 Extension Contents (variable length): The payload of the extension. 551 3.2.1.1. Handshake Extension Message 553 In a Handshake Extension, the value of the Extension Field of the 554 handshake control packet is defined as 1 for a Handshake Extension 555 request, and 2 for a Handshake Extension response. 557 The Extension Contents field of a Handshake Extension Message is 558 structured as follows: 560 0 1 2 3 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | SRT Version | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | SRT Flags | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Receiver TSBPD Delay | Sender TSBPD Delay | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 6: Handshake Extension Message structure 572 SRT Version (32 bits): SRT library version. 574 SRT Flags (32 bits): SRT configuration flags: 576 +------------+---------------+ 577 | Bitmask | Flag | 578 +============+===============+ 579 | 0x00000001 | TSBPDSND | 580 +------------+---------------+ 581 | 0x00000002 | TSBPDRCV | 582 +------------+---------------+ 583 | 0x00000004 | CRYPT | 584 +------------+---------------+ 585 | 0x00000008 | TLPKTDROP | 586 +------------+---------------+ 587 | 0x00000010 | PERIODICNAK | 588 +------------+---------------+ 589 | 0x00000020 | REXMITFLG | 590 +------------+---------------+ 591 | 0x00000040 | STREAM | 592 +------------+---------------+ 593 | 0x00000080 | PACKET_FILTER | 594 +------------+---------------+ 596 Table 6: Handshake 597 Extension Message Flags 599 Receiver TSBPD Delay (16 bits): TimeStamp-Based Packet Delivery 600 (TSBPD) Delay of the receiver. Refer to Section 4.5. 602 Sender TSBPD Delay (16 bits): TSBPD of the sender. Refer to 603 Section 4.5. 605 3.2.1.2. Key Material Exchange 607 The Key Material Exchange portion of a Handshake packet has both 608 request and response type extensions. The value of a request is 3, 609 and the response value is 4. 611 0 1 2 3 612 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |S| V | PT | Sign | Resv | KK| 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | KEKI | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Cipher | Auth | SE | SLen | KLen | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Salt | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | | 623 + Wrapped Key + 624 | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 7: Key Material Extension structure 629 S ( ): 1 bit. Value: {0} This is a fixed-width field that is a 630 remnant from the header of a previous design. 632 Version (V): 3 bits. Value: {1} This is a fixed-width field that 633 indicates the SRT version: - 1: initial version 635 Packet Type (PT): 4 bits. Value: {2} This is a fixed-width field 636 that indicates the Packet Type: - 0: Reserved - 1: MSmsg - 2: 637 KMmsg - 7: Reserved to discriminate MPEG-TS packet (0x47=sync 638 byte) 640 Signature (Sign): 16 bits. Value: {0x2029} This is a fixed-width 641 field that contains the signature 'HAI' encoded as a PnP Vendor ID 642 ([PNPID]) (in big endian order) 644 Reserved (Resv): 6 bits. Value: {0} This is a fixed-width field 645 reserved for flag extension or other usage. 647 Key-based Data Encryption (KK): 2 bits. This is a fixed-width field 648 that indicates whether or not data is encrypted: - 00b: not 649 encrypted (data packets only) - 01b: even key - 10b: odd key 651 - 11b: even and odd keys 653 Key Encryption Key Index (KEKI): 32 bits. Value: {0} This is a 654 fixed-width field for specifying the KEK index (big endian order) 655 - 0: Default stream associated key (stream/system default) - 656 1..255: Reserved for manually indexed keys 658 Cipher ( ): 8 bits. Value: {0..2} This is a fixed-width field for 659 specifying encryption cipher and mode: - 0: None or KEKI indexed 660 crypto context - 1: AES-ECB (not supported in SRT) - 2: AES-CTR 661 [SP800-38A] 663 Authentication (Auth): 8 bits. Value: {0} This is a fixed-width 664 field for specifying a message authentication code algorithm: - 0: 665 None or KEKI indexed crypto context 667 Stream Encapsulation (SE): 8 bits. Value: {2} This is a fixed-width 668 field for describing the stream encapsulation: - 0: Unspecified or 669 KEKI indexed crypto context - 1: MPEG-TS/UDP - 2: MPEG-TS/SRT 671 Reserved (Resv1): 8 bits. Value: {0} This is a fixed-width field 672 reserved for future use. 674 Reserved (Resv2): 16 bits. Value: {0} This is a fixed-width field 675 reserved for future use. 677 Slen/4 ( ): 4 bits. Value: {0..255} This is a fixed-width field for 678 specifying salt length in bytes divided by 4. Can be zero if no 679 salt/IV present 681 Klen/4 ( ): 8 bits. Value: {4,6,8} This is a fixed-width field for 682 specifying SEK length in bytes divided by 4. Size of one key even 683 if two keys present. 685 Salt (Slen): Slen*8 bits. Value: { } This is a variable-width field 686 for specifying a salt key 688 Wrap ( ): (64+n * Klen * 8) bits. Value: { } This is a variable- 689 width field for specifying Wrapped key(s), where n = 1 or 2 NOTE 690 1: n = (KK + 1)/2 NOTE 2: size in bytes = (((KK+1/2) * Klen) + 8) 692 0 1 2 3 693 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | | 696 + Integrity Check Vector (ICV) + 697 | | 698 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 699 | xSEK | 700 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 701 | oSEK | 702 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 704 Figure 8: Unwrapped key structure 706 ICV (64 bits): 64-bit Integrity Check Vector(AES key wrap 707 integrity). 709 xSEK (variable length): This field identifies an odd or even SEK. 710 If both keys are present, then this field is eSEK (even key) and 711 the next one is the odd key. The length of this field is 712 calculated by KLen * 4 * 8. 714 oSEK (variable length): This field is present only when the message 715 carries the two SEKs. 717 3.2.2. Keep-Alive 719 Keep-Alive control packets are sent after a certain timeout from the 720 last time any packet (Control or Data) was sent. The purpose of this 721 control packet is to notify the peer to keep the connection open when 722 no data exchange is taking place. 724 The default timeout for a Keep-Alive packet to be sent is 1 second. 726 An SRT Keep-Alive packet is formatted as follows: 728 0 1 2 3 729 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 730 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |1| Control Type | Reserved | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Type-specific Information | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Time Stamp | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Destination Socket ID | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | CIF (none) | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 9: Keep-Alive structure 744 Packet Type ( ): 1 bit. Value: 1 The type value of a Keep-Alive 745 control packet is "1". 747 Control Type ( ): 15 bits. Value: KEEPALIVE{1} This is a fixed- 748 width field used to indicate message type 750 Reserved ( ): 16 bits. Value: ??? This is a fixed-width field 751 reserved for future use. 753 Type-specific Information: This field is reserved for future 754 definition. 756 Time Stamp (TS): 32 bits. Value: ??? This is a fixed-width field 757 usually containing the time (in microseconds) when a packet was 758 sent, although the real interpretation may vary depending on the 759 type. 761 Destination Socket ID (DestSockID): 32 bits. Value: ??? This is a 762 fixed-width field providing the socket ID to which a packet should 763 be dispatched, although it may have the special value 0 when the 764 packet is a connection request. 766 Control Information Field (CIF): n bits. Value: {none} This field 767 must not appear in Keep-Alive control packets. 769 3.2.3. ACK (Acknowledgement) 771 Acknowledgement control packets are used to provide delivery status 772 of data packets. These packets may also carry some additional 773 information from the receiver like RTT, bandwidth, receiving speed, 774 etc. The CIF portion of the ACK control packet is expanded as 775 follows: 777 0 1 2 3 778 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 779 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 |1| Control Type | Reserved | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type-specific Information | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Time Stamp | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Destination Socket ID | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Last Acknowledged Packet Sequence Number | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | RTT | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | RTT variance | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Available Buffer Size | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Packets Receiving Rate | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Estimated Link Capacity | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Receiving Rate | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Figure 10: ACK control packet 805 Type-specific Information (32 bits): The time-specific Information 806 (Figure 4) of the ACK packet stores the sequential number of the 807 full ACK packet starting from 1. 809 Last Acknowledged Packet Sequence Number (32 bits): The sequence 810 number of the last acknowledged data packet +1. 812 RTT (32 bits): RTT value (in microseconds) estimated by the receiver 813 based on the previous ACK-ACKACK packet exchange. 815 RTT variance (32 bits): The variance of the RTT estimation (in 816 microseconds). 818 Available Buffer Size (32 bits): Available size of the receiver's 819 buffer (in packets). 821 Packets Receiving Rate (32 bits): The rate at which packets are 822 being received (in packets per second). 824 Estimated Link Capacity (32 bits): Estimated bandwidth of the link 825 (in packets per second). 827 Receiving Rate (32 bits): Estimated receiving rate (in bytes per 828 second). 830 There are several types of ACK packets: 832 * A Full ACK control packet is sent every 10 ms and has all the 833 fields of Figure 10. 835 * A Lite ACK control packet includes only the Last Acknowledged 836 Packet Sequence Number field. The Type-specific Information field 837 should be set to 0. 839 * A Small ACK includes the fields up to and including the Available 840 Buffer Size field. The Type-specific Information field should be 841 set to 0. 843 The sender only acknowledges the receipt of Full ACK packets (see 844 ACKACK). 846 The Lite ACK and Small ACK packets are used in cases when the 847 receiver should acknowledge received data packets more often than 848 every 10 ms. This is usually needed at high data rates. It is up to 849 the receiver to decide the condition and the type of ACK packet to 850 send (Lite or Small). The recommendation is to send a Lite ACK for 851 every 64 packets received. 853 3.2.4. NAK (Loss Report) 855 Negative acknowledgement (NAK) control packets are used to signal 856 failed data packet deliveries. The receiver notifies the sender 857 about lost data packets by sending a NAK packet that contains a list 858 of sequence numbers for those lost packets. 860 An SRT NAK packet is formatted as follows: 862 0 1 2 3 863 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 864 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 |1| Control Type | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Type-specific Information | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Time Stamp | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Destination Socket ID | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |0| Lost packet sequence number | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 |1| List of lost packets | 876 +-+-+-+-+-+-+-+-+-+-+-+- CIF (Loss List) -+-+-+-+-+-+-+-+-+-+-+-+ 877 |0| Up to | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 |0| Lost packet sequence number | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Figure 11: NAK control packet 884 Control Type: The type value of a NAK control packet is "3". 886 Type-specific Information: This field is reserved for future 887 definition. 889 Control Information Field (CIF): A single value or a list of lost 890 packets sequence numbers. See packet sequence number coding in 891 Appendix A. 893 3.2.5. Shutdown 895 Shutdown control packets are used to initiate the closing of an SRT 896 connection. 898 An SRT SHUTDOWN Control packet is formatted as follows: 900 0 1 2 3 901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 902 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 |1| Control Type | Reserved | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Type-specific Information | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Time Stamp | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Destination Socket ID | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | None | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 12: SHUTDOWN control packet 916 Control Type: The type value of Shutdown control packet is "5". 918 Type-specific Information: This field is reserved for future 919 definition. 921 Control Information Field: This field must not appear in shutdown 922 control packets. 924 3.2.6. ACKACK 926 ACKACK control packets are sent to acknowledge the reception of a 927 Full ACK, and are used in the calculation of RTT by the receiver. 929 An SRT ACKACK Control packet is formatted as follows: 931 0 1 2 3 932 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 933 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 |1| Control Type | Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Type-specific Information | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Time Stamp | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Destination Socket ID | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | None | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Figure 13: ACKACK control packet 947 Control Type: The type value of ACKACK control packet is "6". 949 Type-specific Information: ACK Sequence Number. This field is used 950 for the sequence number of the ACK packet being acknowledged. 952 Control Information Field: This field must not appear in ACKACK 953 control packets. 955 4. SRT Data Transmission and Control 957 This section describes key concepts related to the handling of 958 control and data packets during the transmission process. 960 After the handshake and exchange of capabilities is completed, packet 961 data can be sent and received over the established connection. To 962 fully utilize the features of low latency and error recovery provided 963 by SRT, the sender and receiver MUST handle control packets, timers, 964 and buffers for the connection as specified in this section. 966 4.1. Stream Multiplexing 968 Multiple SRT sockets may share the same UDP socket so that the 969 packets received to this UDP socket will be correctly dispatched to 970 the SRT socket they are currently destined. 972 During the handshake, the parties exchange their SRT Socket IDs. 973 These IDs are then used in the Destination Socket ID field of every 974 control and data packet (see Section 3). 976 4.2. Data Transmission Modes 978 SRT has been mainly created for Live Streaming and therefore its main 979 and default transmission mode is "live". SRT supports, however, the 980 modes that the original UDT library supported, that is, buffer and 981 message transmission. 983 4.2.1. Message Mode 985 When the STREAM flag of the handshake Extension Message 986 Section 3.2.1.1 is set to 0, the protocol operates in Message mode, 987 characterized as follows: 989 * Every packet has its own Packet Sequence Number. 991 * One or several consecutive SRT Data packets can form a message. 993 * All the packets belonging to the same message have a similar 994 message number set in the Message Number field. 996 The first packet of a message has the first bit of the Packet 997 Position Flags (Section 3.1) set to 1. The last packet of the 998 message has the second bit of the Packet Position Flags set to 1. 999 Thus, a PP equal to "11b" indicates a packet that forms the whole 1000 message. A PP equal to "00b" indicates a packet that belongs to the 1001 inner part of the message. 1003 The concept of the message in SRT comes from UDT ([GHG04b]). In this 1004 mode a single sending instruction passes exactly one piece of data 1005 that has boundaries (a message). This message may span across 1006 multiple UDP packets (and multiple SRT data packets). The only size 1007 limitation is that it shall fit as a whole in the buffers of the 1008 sender and the receiver. Although internally all operations (e.g. 1009 ACK, NAK) on data packets are performed independently, an application 1010 MUST send and receive the whole message. Until the message is 1011 complete (all packets are received) the application will not be 1012 allowed to read it. 1014 When the Order Flag of a Data packet is set to 1, this imposes a 1015 sequential reading order on messages. An Order Flag set to 0 allows 1016 an application to read messages that are already fully available, 1017 before any preceding messages that may have some packets missing. 1019 4.2.2. Live Mode 1021 Live mode is a special type of message mode where only data packets 1022 with their PP field set to "11b" are allowed. 1024 Additionally Timestamp Based Packet Delivery (TSBPD) (Section 4.5) 1025 and Too-Late Packet Drop (Section 4.6) mechanisms are used in this 1026 mode. 1028 4.2.3. Buffer Mode 1030 Buffer mode is negotiated during the Handshake by setting the STREAM 1031 flag of the handshake Extension Message Flags to 1. 1033 In this mode consecutive packets form one continuous stream that can 1034 be read, with portions of any size. 1036 4.3. Handshake Messages 1038 SRT is a connection protocol. It embraces the concepts of 1039 "connection" and "session". The UDP system protocol is used by SRT 1040 for sending data and control packets. 1042 An SRT connection is characterized by the fact that it is: 1044 * first engaged by a handshake process; 1046 * maintained as long as any packets are being exchanged in a timely 1047 manner; 1049 * considered closed when a party receives the appropriate close 1050 command from its peer (connection closed by the foreign host), or 1051 when it receives no packets at all for some predefined time 1052 (connection broken on timeout). 1054 SRT supports two connection configurations: 1056 1. Caller-Listener, where one side waits for the other to initiate a 1057 connection 1059 2. Rendezvous, where both sides attempt to initiate a connection 1061 The handshake is performed between two parties: "Initiator" and 1062 "Responder": 1064 * Initiator starts the extended SRT handshake process and sends 1065 appropriate SRT extended handshake requests. 1067 * Responder expects the SRT extended handshake requests to be sent 1068 by the Initiator and sends SRT extended handshake responses back. 1070 There are two basic types of SRT handshake extensions that are 1071 exchanged in the handshake: 1073 * Handshake Extension Message exchanges the basic SRT information; 1075 * Key Material Exchange exchanges the wrapped stream encryption key 1076 (used only if encryption is requested). 1078 * Stream ID extension exchanges some stream-specific information 1079 that can be used by the application to identify the incoming 1080 stream connection. 1082 The Initiator and Responder roles are assigned depending on the 1083 connection mode. 1085 For Caller-Listener connections: the Caller is the Initiator, the 1086 Listener is the Responder. For Rendezvous connections: the Initiator 1087 and Responder roles are assigned based on the initial data 1088 interchange during the handshake. 1090 The Handshake Type field in the Handshake Structure (see Figure 5) 1091 indicates the handshake message type. 1093 Caller-Listener handshake exchange has the following order of 1094 Handshake Types: 1096 1. Caller to Listener: INDUCTION 1098 2. Listener to Caller: INDUCTION (reports cookie) 1100 3. Caller to Listener: CONCLUSION (uses previously returned cookie) 1102 4. Listener to Caller: CONCLUSION (confirms connection established) 1104 Rendezvous handshake exchange has the following order of Handshake 1105 Types: 1107 1. After starting the connection: WAVEAHAND. 1109 2. After receiving the above message from the peer: CONCLUSION. 1111 3. After receiving the above message from the peer: AGREEMENT. 1113 When a connection process has failed before either party can send the 1114 CONCLUSION handshake, the Handshake Type field will contain the 1115 appropriate error value for the rejected connection. See the list of 1116 error codes in Table 7. 1118 +------+----------------+-----------------------------------------+ 1119 | Code | Error | Description | 1120 +======+================+=========================================+ 1121 | 1000 | REJ_UNKNOWN | Unknown reason | 1122 +------+----------------+-----------------------------------------+ 1123 | 1001 | REJ_SYSTEM | System function error | 1124 +------+----------------+-----------------------------------------+ 1125 | 1002 | REJ_PEER | Rejected by peer | 1126 +------+----------------+-----------------------------------------+ 1127 | 1003 | REJ_RESOURCE | Resource allocation problem | 1128 +------+----------------+-----------------------------------------+ 1129 | 1004 | REJ_ROGUE | incorrect data in handshake | 1130 +------+----------------+-----------------------------------------+ 1131 | 1005 | REJ_BACKLOG | listener's backlog exceeded | 1132 +------+----------------+-----------------------------------------+ 1133 | 1006 | REJ_IPE | internal program error | 1134 +------+----------------+-----------------------------------------+ 1135 | 1007 | REJ_CLOSE | socket is closing | 1136 +------+----------------+-----------------------------------------+ 1137 | 1008 | REJ_VERSION | peer is older version than agent's min | 1138 +------+----------------+-----------------------------------------+ 1139 | 1009 | REJ_RDVCOOKIE | rendezvous cookie collision | 1140 +------+----------------+-----------------------------------------+ 1141 | 1010 | REJ_BADSECRET | wrong password | 1142 +------+----------------+-----------------------------------------+ 1143 | 1011 | REJ_UNSECURE | password required or unexpected | 1144 +------+----------------+-----------------------------------------+ 1145 | 1012 | REJ_MESSAGEAPI | Stream flag collision | 1146 +------+----------------+-----------------------------------------+ 1147 | 1013 | REJ_CONGESTION | incompatible congestion-controller type | 1148 +------+----------------+-----------------------------------------+ 1149 | 1014 | REJ_FILTER | incompatible packet filter | 1150 +------+----------------+-----------------------------------------+ 1151 | 1015 | REJ_GROUP | incompatible group | 1152 +------+----------------+-----------------------------------------+ 1154 Table 7: Handshake Rejection Reason Codes 1156 The specification of the cipher family and block size is decided by 1157 the Sender. When the transmission is bidirectional, this value must 1158 be agreed upon at the outset because when both are set the Responder 1159 wins. For Caller-Listener connections it is reasonable to set this 1160 value on the Listener only. In the case of Rendezvous the only 1161 reasonable approach is to decide upon the correct value from the 1162 different sources and to set it on both parties (note that *AES-128* 1163 is the default). 1165 4.3.1. Caller-Listener Handshake 1167 This section describes the handshaking process where a Listener is 1168 waiting for an incoming Handshake request on a bound UDP port from a 1169 Caller. The process has two phases: induction and conclusion. 1171 4.3.1.1. The Induction Phase 1173 The Caller begins by sending the INDUCTION handshake, which contains 1174 the following (significant) fields: 1176 * Version: must always be 4 1178 * Encryption Field: 0 1180 * Extension Field: 2 1182 * Handshake Type: INDUCTION 1184 * SRT Socket ID: SRT Socket ID of the Caller 1186 * SYN Cookie: 0 1188 The Destination Socket ID of the SRT packet header in this message is 1189 0, which is interpreted as a connection request. 1191 The handshake version number is set to 4 in this initial handshake. 1192 This is due to the initial design of SRT that was to be compliant 1193 with the UDT protocol ([GHG04b]) on which it is based. 1195 This phase serves only to set a cookie on the Listener so that it 1196 doesn't allocate resources, thus mitigating a potential DoS attack 1197 that might be perpetrated by flooding the Listener with handshake 1198 commands. 1200 The Listener responds with the following: 1202 * Version: 5 1204 * Encryption Field: Advertised cipher family and block size. 1206 * Extension Field: SRT magic code 0x4A17 1208 * Handshake Type: INDUCTION 1210 * SRT Socket ID: Socket ID of the Listener 1211 * SYN Cookie: a cookie that is crafted based on host, port and 1212 current time with 1 minute accuracy 1214 At this point the Listener still doesn't know if the Caller is SRT or 1215 UDT, and it responds with the same set of values regardless of 1216 whether the Caller is SRT or UDT. 1218 If the party is SRT, it does interpret the values in Version and 1219 Extension Field. If it receives the value 5 in Version, it 1220 understands that it comes from an SRT party, so it knows that it 1221 should prepare the proper handshake messages phase. It also checks 1222 the following: 1224 * whether the Extension Flags contains the magic value 0x4A17; 1225 otherwise the connection is rejected. This is a contingency for 1226 the case where someone who, in an attempt to extend UDT 1227 independently, increases the Version value to 5 and tries to test 1228 it against SRT. 1230 * whether the Encryption Flags contain a non-zero value, which is 1231 interpreted as an advertised cipher family and block size. 1233 A legacy UDT party completely ignores the values reported in Version 1234 and Handshake Type. It is, however, interested in the SYN Cookie 1235 value, as this must be passed to the next phase. It does interpret 1236 these fields, but only in the "conclusion" message. 1238 4.3.1.2. The Conclusion Phase 1240 Once the Caller gets the SYN cookie from the Listener, it sends the 1241 CONCLUSION handshake to the Listener. 1243 The following values are set by the compliant caller: 1245 * Version: 5 1247 * Handshake Type: CONCLUSION 1249 * SRT Socket ID: Socket ID of the Caller 1251 * SYN Cookie: the cookie previously received in the induction phase 1253 The Destination Socket ID in this message is the socket ID that was 1254 previously received in the induction phase in the SRT Socket ID field 1255 of the handshake structure. 1257 * Encryption Flags: advertised cipher family and block size. 1259 * Extension Flags: A set of flags that define the extensions 1260 provided in the handshake. 1262 The Listener responds with the same values shown above, without the 1263 cookie (which is not needed here), as well as the extensions for HS 1264 Version 5 (which will probably be exactly the same). 1266 There is not any "negotiation" here. If the values passed in the 1267 handshake are in any way not acceptable by the other side, the 1268 connection will be rejected. The only case when the Listener can 1269 have precedence over the Caller is the advertised Cipher Family and 1270 Block Size (Table 2) in the Encryption Field of the Handshake. 1272 The value for latency is always agreed to be the greater of those 1273 reported by each party. 1275 4.3.2. Rendezvous Handshake 1277 The Rendezvous process uses a state machine. It is slightly 1278 different from UDT Rendezvous handshake [GHG04b], although it is 1279 still based on the same message request types. 1281 Both parties start with WAVEAHAND and use the Version value of 5. 1282 Legacy Version 4 clients do not look at the Version value, whereas 1283 Version 5 clients can detect version 5. The parties only continue 1284 with the Version 5 Rendezvous process when Version is set to 5 for 1285 both. Otherwise the process continues exclusively according to 1286 Version 4 rules [GHG04b]. 1288 With Version 5 Rendezvous, both parties create a cookie for a process 1289 called the "cookie contest". This is necessary for the assignment of 1290 Initiator and Responder roles. Each party generates a cookie value 1291 (a 32-bit number) based on the host, port, and current time with 1 1292 minute accuracy. This value is scrambled using an MD5 sum 1293 calculation. The cookie values are then compared with one another. 1295 Since it is impossible to have two sockets on the same machine bound 1296 to the same NIC and port and operating independently, it is virtually 1297 impossible that the parties will generate identical cookies. 1298 However, this situation may occur if an application tries to "connect 1299 to itself" - that is, either connects to a local IP address, when the 1300 socket is bound to INADDR_ANY, or to the same IP address to which the 1301 socket was bound. If the cookies are identical (for any reason), the 1302 connection will not be made until new, unique cookies are generated 1303 (after a delay of up to one minute). In the case of an application 1304 "connecting to itself", the cookies will always be identical, and so 1305 the connection will never be established. 1307 When one party's cookie value is greater than its peer's, it wins the 1308 cookie contest and becomes Initiator (the other party becomes the 1309 Responder). 1311 At this point there are two possible "handshake flows": _serial_ and 1312 _parallel_. 1314 4.3.2.1. Serial Handshake Flow 1316 In the serial handshake flow, one party is always first, and the 1317 other follows. That is, while both parties are repeatedly sending 1318 WAVEAHAND messages, at some point one party - let's say Alice - will 1319 find she has received a WAVEAHAND message before she can send her 1320 next one, so she sends a CONCLUSION message in response. Meantime, 1321 Bob (Alice's peer) has missed Alice's WAVEAHAND messages, so that 1322 Alice's CONCLUSION is the first message Bob has received from her. 1324 This process can be described easily as a series of exchanges between 1325 the first and following parties (Alice and Bob, respectively): 1327 1. Initially, both parties are in the _waving_ state. Alice sends a 1328 handshake message to Bob: 1330 * Version: 5 1332 * Type: Extension field: 0, Encryption field: advertised 1333 "PBKEYLEN". 1335 * Handshake Type: WAVEAHAND 1337 * SRT Socket ID: Alice's socket ID 1339 * SYN Cookie: Created based on host/port and current time. 1341 While Alice doesn't yet know if she is sending this message to a 1342 Version 4 or Version 5 peer, the values from these fields would not 1343 be interpreted by the Version 4 peer when the Handshake Type is 1344 WAVEAHAND. 1346 1. Bob receives Alice's WAVEAHAND message, switches to the 1347 "attention" state. Since Bob now knows Alice's cookie, he 1348 performs a "cookie contest" (compares both cookie values). If 1349 Bob's cookie is greater than Alice's, he will become the 1350 Initiator. Otherwise, he will become the Responder. 1352 The resolution of the Handshake Role (Initiator or Responder) is 1353 essential for further processing. 1355 Then Bob responds: 1357 * Version: 5 1359 * Extension field: appropriate flags if Initiator, otherwise 0 1361 * Encryption field: advertised PBKEYLEN 1363 * Handshake Type: CONCLUSION 1365 If Bob is the Initiator and encryption is on, he will use either his 1366 own cipher family and block size or the one received from Alice (if 1367 she has advertised those values). 1369 1. Alice receives Bob's CONCLUSION message. While at this point she 1370 also performs the "cookie contest", the outcome will be the same. 1371 She switches to the "fine" state, and sends: 1373 * Version: 5 1375 * Appropriate extension flags and encryption flags 1377 * Handshake Type: CONCLUSION 1379 Both parties always send extension flags at this point, which will 1380 contain HSREQ if the message comes from an Initiator, or HSRSP if it 1381 comes from a Responder. If the Initiator has received a previous 1382 message from the Responder containing an advertised cipher family and 1383 block size in the encryption flags field, it will be used as the key 1384 length for key generation sent next in the KMREQ extension. 1386 1. Bob receives Alice's CONCLUSION message, and then does one of the 1387 following (depending on Bob's role): 1389 * If Bob is the Initiator (Alice's message contains HSRSP), he: 1391 - switches to the "*connected" state 1393 - sends Alice a message with Handshake Type AGREEMENT, but 1394 containing no SRT extensions (Extension Flags field should 1395 be 0) 1397 * If Bob is the Responder (Alice's message contains HSREQ), he: 1399 - switches to "initiated" state 1401 - sends Alice a message with Handshake Type CONCLUSION that 1402 also contains extensions with HSRSP 1403 o awaits a confirmation from Alice that she is also 1404 connected (preferably by AGREEMENT message) 1406 2. Alice receives the above message, enters into the "connected" 1407 state, and then does one of the following (depending on Alice's 1408 role): 1410 * If Alice is the Initiator (received CONCLUSION with HSRSP), 1411 she sends Bob a message with Handshake Type = URQ_AGREEMENT. 1413 * If Alice is the Responder, the received message has Handshake 1414 Type AGREEMENT and in response she does nothing. 1416 3. At this point, if Bob was Initiator, he is connected already. If 1417 he was a Responder, he should receive the above AGREEMENT 1418 message, after which he switches to the "connected" state. In 1419 the case where the UDP packet with the agreement message gets 1420 lost, Bob will still enter the _connected_ state once he receives 1421 anything else from Alice. If Bob is going to send, however, he 1422 has to continue sending the same CONCLUSION until he gets the 1423 confirmation from Alice. 1425 4.3.2.2. Parallel Handshake Flow 1427 The chances of the parallel handshake flow are very low, but still it 1428 may occur if the handshake messages with WAVEAHAND are sent and 1429 received by both peers at precisely the same time. 1431 The resulting flow is very much like Bob's behavior in the serial 1432 handshake flow, but for both parties. Alice and Bob will go through 1433 the same state transitions: 1435 Waving -> Attention -> Initiated -> Connected 1437 In the Attention state they know each other's cookies, so they can 1438 assign roles. In contrast to serial flows, which are mostly based on 1439 request-response cycles, here everything happens completely 1440 asynchronously: the state switches upon reception of a particular 1441 handshake message with appropriate contents (the Initiator must 1442 attach the HSREQ extension, and Responder must attach the "HSRSP" 1443 extension). 1445 Here's how the parallel handshake flow works, based on roles: 1447 Initiator: 1449 1. Waving 1450 * Receives WAVEAHAND message 1452 * Switches to Attention 1454 * Sends CONCLUSION + HSREQ 1456 2. Attention 1458 * Receives CONCLUSION message, which: 1460 - contains no extensions: 1462 o switches to Initiated, still sends URQ_CONCLUSION + 1463 HSREQ 1465 - contains "HSRSP" extension: 1467 o switches to Connected, sends AGREEMENT 1469 3. Initiated 1471 * Receives CONCLUSION message, which: 1473 - Contains no extensions: 1475 o REMAINS IN THIS STATE, still sends URQ_CONCLUSION + 1476 HSREQ 1478 - contains "HSRSP" extension: 1480 o switches to Connected, sends AGREEMENT 1482 4. Connected 1484 * May receive CONCLUSION and respond with AGREEMENT, but 1485 normally by now it should already have received payload 1486 packets. 1488 Responder: 1490 1. Waving 1492 * Receives WAVEAHAND message 1494 * Switches to Attention 1496 * Sends CONCLUSION message (with no extensions) 1498 2. Attention 1500 * Receives CONCLUSION message with HSREQ This message might 1501 contain no extensions, in which case the party shall simply 1502 send the empty CONCLUSION message, as before, and remain in 1503 this state. 1505 * Switches to Initiated and sends CONCLUSION message with HSRSP 1507 3. Initiated 1509 * Receives: 1511 - CONCLUSION message with HSREQ 1513 o responds with CONCLUSION with HSRSP and remains in this 1514 state 1516 - AGREEMENT message 1518 o responds with AGREEMENT and switches to Connected 1520 - Payload packet 1522 o responds with AGREEMENT and switches to Connected 1524 4. Connected 1526 * Is not expecting to receive any handshake messages anymore. 1527 The AGREEMENT message is always sent only once or per every 1528 final CONCLUSION message. 1530 Note that any of these packets may be missing, and the sending party 1531 will never become aware. The missing packet problem is resolved this 1532 way: 1534 1. If the Responder misses the CONCLUSION + HSREQ message, it simply 1535 continues sending empty CONCLUSION messages. Only upon reception 1536 of CONCLUSION + HSREQ does it respond with CONCLUSION + HSRSP. 1538 2. If the Initiator misses the CONCLUSION + HSRSP response from the 1539 Responder, it continues sending CONCLUSION + HSREQ. The 1540 Responder must always respond with CONCLUSION + HSRSP when the 1541 Initiator sends CONCLUSION + HSREQ, even if it has already 1542 received and interpreted it. 1544 3. When the Initiator switches to the Connected state it responds 1545 with a AGREEMENT message, which may be missed by the Responder. 1547 Nonetheless, the Initiator may start sending data packets because 1548 it considers itself connected - it doesn't know that the 1549 Responder has not yet switched to the Connected state. Therefore 1550 it is exceptionally allowed that when the Responder is in the 1551 Initiated state and receives a data packet (or any control packet 1552 that is normally sent only between connected parties) over this 1553 connection, it may switch to the Connected state just as if it 1554 had received a AGREEMENT message. 1556 4. If the the Initiator has already switched to the Connected state 1557 it will not bother the Responder with any more handshake 1558 messages. But the Responder may be completely unaware of that 1559 (having missed the AGREEMENT message from the Initiator). 1560 Therefore it doesn't exit the connecting state, which means that 1561 it continues sending CONCLUSION + HSRSP messages until it 1562 receives any packet that will make it switch to the Connected 1563 state (normally AGREEMENT). Only then does it exit the 1564 connecting state and the application can start transmission. 1566 4.4. SRT Buffer Latency 1568 The SRT sender and receiver have buffers to store packets. 1570 On the sender, latency is the time that SRT holds a packet to give it 1571 a chance to be delivered successfully while maintaining the rate of 1572 the sender at the receiver. If an acknowledgement (ACK) is missing 1573 or late for more than the configured latency, the packet is dropped 1574 from the sender buffer. A packet can be retransmitted as long as it 1575 remains in the buffer for the duration of the latency window. On the 1576 receiver, packets are delivered to an application from a buffer after 1577 the latency interval has passed. This helps to recover from 1578 potential packet losses. See sections Section 4.5, Section 4.6 for 1579 details. 1581 Latency is a value (specified in milliseconds) that can cover the 1582 time to transmit hundreds or even thousands of packets at high 1583 bitrate. Latency can be thought of as a window that slides over 1584 time, during which a number of activities take place, such as the 1585 reporting of acknowledged packets (ACKs) (Section 4.8.1) and 1586 unacknowledged packets (NAKs)(Section 4.8.2). 1588 Latency is configured through the exchange of capabilities during the 1589 extended handshake process between initiator and responder. The 1590 Handshake Extension Message (Section 3.2.1.1) has TSBPD delay 1591 information (in milliseconds) from the SRT receiver and sender. The 1592 latency for a connection will be established as the maximum value of 1593 latencies proposed by the initiator and responder. 1595 4.5. Timestamp Based Packet Delivery 1597 The goal of the SRT Timestamp Based Packet Delivery (TSBPD) mechanism 1598 is to reproduce the output of the sending application (e.g., encoder) 1599 at the input of the receiving application (e.g., decoder) in live 1600 data transmission mode (see Section 4.2). It attempts to reproduce 1601 the timing of packets committed by the sending application to the SRT 1602 sender. This allows packets to be scheduled for delivery by the SRT 1603 receiver, making them ready to be read by the receiving application 1604 (see Figure 14). 1606 The SRT receiver, using the timestamp of the SRT data packet header, 1607 delivers packets to a receiving application with a fixed minimum 1608 delay from the time the packet was scheduled for sending on the SRT 1609 sender side. Basically, the sender timestamp in the received packet 1610 is adjusted to the receiver's local time (compensating for the time 1611 drift or different time zones) before releasing the packet to the 1612 application. Packets can be withheld by the SRT receiver for a 1613 configured receiver delay. A higher delay can accommodate a larger 1614 uniform packet drop rate, or a larger packet burst drop. Packets 1615 received after their "play time" are dropped if the Too-Late Packet 1616 Drop feature is enabled (see Section 4.6). 1618 The packet timestamp (in microseconds) is relative to the SRT 1619 connection creation time. Packets are inserted based on the sequence 1620 number in the header field. The origin time (in microseconds) of the 1621 packet is already sampled when a packet is first submitted by the 1622 application to the SRT sender. The TSBPD feature uses this time to 1623 stamp the packet for first transmission and any subsequent 1624 retransmission. This timestamp and the configured SRT latency 1625 (Section 4.4) control the recovery buffer size and the instant that 1626 packets are delivered at the destination (the aforementioned "play 1627 time" which is decided by adding the timestamp to the configured 1628 latency). 1630 It is worth mentioning that the use of the packet sending time to 1631 stamp the packets is inappropriate for the TSBPD feature, since a new 1632 time (current sending time) is used for retransmitted packets, 1633 putting them out of order when inserted at their proper place in the 1634 stream. 1636 Figure 14 illustrates the key latency points during the packet 1637 transmission with the TSBPD feature enabled. 1639 | Sending | | | 1640 | Delay | ~RTT/2 | SRT Latency | 1641 |<--------->|<------------>|<----------------->| 1642 | | | | 1643 | | | | 1644 | | | | 1645 ___ Scheduled Sent Received Scheduled 1646 / for sending | | for delivery 1647 Packet | | | | 1648 State | | | | 1649 | | | | 1650 | | | | 1651 -----------------------------------------------------> 1652 Time 1654 Figure 14: Key Latency Points during the Packet Transmission 1656 The main packet states shown in Figure 14 are the following: 1658 * "Scheduled for sending": the packet is committed by the sending 1659 application, stamped and ready to be sent; 1661 * "Sent": the packet is passed to the UDP socket and sent; 1663 * "Received": the packet is received and read from the UDP socket; 1665 * "Scheduled for delivery": the packet is scheduled for the delivery 1666 and ready to be read by the receiving application. 1668 It is worth noting that the round-trip time (RTT) of an SRT link may 1669 vary in time. However the actual end-to-end latency on the link 1670 becomes fixed and is approximately equal to (RTT_0/2 + SRT Latency) 1671 once the SRT handshake exchange happens, where RTT_0 is the actual 1672 value of the round-trip time during the SRT handshake exchange (the 1673 value of the round-trip time once the SRT connection has been 1674 established). 1676 The value of sending delay depends on the hardware performance. 1677 Usually it is relatively small (several microseconds) in contrast to 1678 RTT_0/2 and SRT latency which are measured in milliseconds. 1680 4.5.1. Packet Delivery Time 1682 Packet delivery time is the moment, estimated by the receiver, when a 1683 packet should be delivered to the upstream application. The 1684 calculation of packet delivery time (PktTsbpdTime) is performed upon 1685 receiving a data packet according to the following formula: 1687 PktTsbpdTime = TsbpdTimeBase + PKT_TIMESTAMP + TsbpdDelay + Drift 1689 where 1691 * TsbpdTimeBase is the time base that reflects the time difference 1692 between local clock of the receiver and the clock used by the 1693 sender to timestamp packets being sent (see Section 4.5.1.1); 1695 * PKT_TIMESTAMP is the data packet timestamp, in microseconds; 1697 * TsbpdDelay is the receiver's buffer delay (or receiver's buffer 1698 latency, or SRT Latency). This is the time, in milliseconds, that 1699 SRT holds a packet from the moment it has been received till the 1700 time it should be delivered to the upstream application; 1702 * Drift is the time drift used to adjust the fluctuations between 1703 sender and receiver clock, in microseconds. 1705 SRT Latency (TsbpdDelay) should be a buffer time large enough to 1706 cover the unexpectedly extended RTT time, and the time needed to 1707 retransmit the lost packet. The value of minimum TsbpdDelay is 1708 negotiated during the SRT handshake exchange and is equal to 120 1709 milliseconds. The recommended value of TsbpdDelay is 3-4 times RTT. 1711 it is worth noting that TsbpdDelay limits the number of packet 1712 retransmissions to a certain extent making impossible to retransmit 1713 packets endlessly. This is important for live data transmission. 1715 4.5.1.1. TSBPD Time Base Calculation 1717 The initial value of TSBPD time base (TsbpdTimeBase) is calculated at 1718 the moment of the second handshake request is received as follows: 1720 TsbpdTimeBase = T_NOW - HSREQ_TIMESTAMP 1722 where T_NOW is the current time according to the receiver clock; 1723 HSREQ_TIMESTAMP is the handshake packet timestamp, in microseconds. 1725 The value of TsbpdTimeBase is approximately equal to the initial one- 1726 way delay of the link RTT_0/2, where RTT_0 is the actual value of the 1727 round-trip time during the SRT handshake exchange. 1729 During the transmission process, the value of TSBPD time base may be 1730 adjusted in two cases: 1732 1. During the TSBPD wrapping period. 1734 The TSBPD wrapping period happens every 01:11:35 hours. This time 1735 corresponds to the maximum timestamp value of a packet 1736 (MAX_TIMESTAMP). MAX_TIMESTAMP is equal to 0xFFFFFFFF, or the 1737 maximum value of 32-bit unsigned integer, in microseconds 1738 (Section 3). The TSBPD wrapping period starts 30 seconds before 1739 reaching the maximum timestamp value of a packet and ends once the 1740 packet with timestamp within (30, 60) seconds interval is delivered 1741 (read from the buffer). The updated value of TsbpdTimeBase will be 1742 recalculated as follows: 1744 TsbpdTimeBase = TsbpdTimeBase + MAX_TIMESTAMP + 1 1746 1. By drift tracer. See Section 4.7 for details. 1748 4.6. Too-Late Packet Drop 1750 The Too-Late Packet Drop (TLPKTDROP) mechanism allows the sender to 1751 drop packets that have no chance to be delivered in time, and allows 1752 the receiver to skip missing packets that have not been delivered in 1753 time. The timeout of dropping a packet is based on the TSBPD 1754 mechanism (see Section 4.5). 1756 In the SRT, when Too-Late Packet Drop is enabled, and a packet 1757 timestamp is older than 125% of the SRT latency, it is considered too 1758 late to be delivered and may be dropped by the sender. However, the 1759 sender keeps packets for at least 1 second in case the SRT latency is 1760 not enough for a large RTT (that is, if 125% of the SRT latency is 1761 less than 1 second). 1763 When enabled on the receiver, the receiver drops packets that have 1764 not been delivered or retransmitted in time, and delivers the 1765 subsequent packets to the application when it is their time to play. 1767 In pseudo-code, the algorithm of reading from the receiver buffer is 1768 the following: 1770 1771 pos = 0; /* Current receiver buffer position */ 1772 i = 0; /* Position of the next available in the receiver buffer 1773 packet relatively to the current buffer position pos */ 1775 while(True) { 1776 // Get the position i of the next available packet 1777 // in the receiver buffer 1778 i = next_avail(); 1779 // Calculate packet delivery time PktTsbpdTime 1780 // for the next available packet 1781 PktTsbpdTime = delivery_time(i); 1783 if T_NOW < PktTsbpdTime: 1784 continue; 1786 Drop packets which buffer position number is less than i; 1788 Deliver packet with the buffer position i; 1790 pos = i + 1; 1791 } 1792 1794 where T_NOW is the current time according to the receiver clock. 1796 The TLPKTDROP mechanism can be turned off to always ensure a clean 1797 delivery. However, a lost packet can simply pause a delivery for 1798 some longer, potentially undefined time, and cause even worse tearing 1799 for the player. Setting higher SRT latency will help much more in 1800 the case when TLPKTDROP causes packet drops too often. 1802 4.7. Drift Management 1804 When the sender enters "connected" status it tells the application 1805 there is a socket interface that is transmitter-ready. At this point 1806 the application can start sending data packets. It adds packets to 1807 the SRT sender's buffer at a certain input rate, from which they are 1808 transmitted to the receiver at scheduled times. 1810 A synchronized time is required to keep proper sender/receiver buffer 1811 levels, taking into account the time zone and round-trip time (up to 1812 2 seconds for satellite links). Considering addition/subtraction 1813 round-off, and possibly unsynchronized system times, an agreed-upon 1814 time base drifts by a few microseconds every minute. The drift may 1815 accumulate over many days to a point where the sender or receiver 1816 buffers will overflow or deplete, seriously affecting the quality of 1817 the video. SRT has a time management mechanism to compensate for 1818 this drift. 1820 When a packet is received, SRT determines the difference between the 1821 time it was expected and its timestamp. The timestamp is calculated 1822 on the receiver side. The RTT tells the receiver how much time it 1823 was supposed to take. SRT maintains a reference between the time at 1824 the leading edge of the send buffer's latency window and the 1825 corresponding time on the receiver (the present time). This allows 1826 to convert packet timestamp to the local receiver time. Based on 1827 this time, various events (packet delivery, etc.) can be scheduled. 1829 The receiver samples time drift data and periodically calculates a 1830 packet timestamp correction factor, which is applied to each data 1831 packet received by adjusting the inter-packet interval. When a 1832 packet is received it is not given right away to the application. As 1833 time advances, the receiver knows the expected time for any missing 1834 or dropped packet, and can use this information to fill any "holes" 1835 in the receive queue with another packet (see Section 4.5). 1837 It is worth noting that the period of sampling time drift data is 1838 based on a number of packets rather than time duration to ensure 1839 enough samples, independently of the media stream packet rate. The 1840 effect of network jitter on the estimated time drift is attenuated by 1841 using a large number of samples. The actual time drift being very 1842 slow (affecting a stream only after many hours) does not require a 1843 fast reaction. 1845 The receiver uses local time to be able to schedule events -- to 1846 determine, for example, if it is time to deliver a certain packet 1847 right away. The timestamps in the packets themselves are just 1848 references to the beginning of the session. When a packet is 1849 received (with a timestamp from the sender), the receiver makes a 1850 reference to the beginning of the session to recalculate its 1851 timestamp. The start time is derived from the local time at the 1852 moment that the session is connected. A packet timestamp equals 1853 "now" minus "StartTime", where the latter is the point in time when 1854 the socket was created. 1856 4.8. Acknowledgement and Lost Packet Handling 1858 To enable the Automatic Repeat reQuest of data packet 1859 retransmissions, a sender stores all sent data packets in its buffer. 1861 The SRT receiver periodically sends acknowledgements (ACKs) for the 1862 received data packets so that the SRT sender can remove the 1863 acknowledged packets from its buffer (Section 4.8.1). Once the 1864 acknowledged packets are removed, their retransmission is no longer 1865 possible and presumably not needed. 1867 Upon receiving the full acknowledgement (ACK) control packet, the SRT 1868 sender should acknowledge its reception to the receiver by sending an 1869 ACKACK control packet with the sequence number of the full ACK packet 1870 being acknowledged. 1872 The SRT receiver also sends NAK control packets to notify the sender 1873 about the missing packets (Section 4.8.2). The sending of a NAK 1874 packet can be triggered immediately after a gap in sequence numbers 1875 of data packets is detected. In addition, a Periodic NAK report 1876 mechanism can be used to send NAK reports periodically. The NAK 1877 packet in that case will list all the packets that the receiver 1878 considers being lost up to the moment the Periodic NAK report is 1879 sent. 1881 Upon reception of the NAK packet, the SRT sender prioritizes 1882 retransmissions of lost packets over the regular data packets to be 1883 transmitted for the first time. 1885 The retransmission of the missing packet is repeated until the 1886 receiver acknowledges its receipt, or if both peers agree to drop 1887 this packet (see Section 4.6). 1889 4.8.1. Packet Acknowledgement (ACKs, ACKACKs) 1891 At certain intervals (see below), the SRT receiver sends an 1892 acknowledgement (ACK) that causes the acknowledged packets to be 1893 removed from the SRT sender's buffer. 1895 An ACK control packet contains the sequence number of the packet 1896 immediately following the latest in the list of received packets. 1897 Where no packet loss has occurred up to the packet with sequence 1898 number n, an ACK would include the sequence number (n + 1). 1900 An ACK (from a receiver) will trigger the transmission of an ACKACK 1901 (by the sender), with almost no delay. The time it takes for an ACK 1902 to be sent and an ACKACK to be received is the RTT. The ACKACK tells 1903 the receiver to stop sending the ACK position because the sender 1904 already knows it. Otherwise, ACKs (with outdated information) would 1905 continue to be sent regularly. Similarly, if the sender doesn't 1906 receive an ACK, it doesn't stop transmitting. 1908 There are two conditions for sending an acknowledgement. A full ACK 1909 is based on a timer of 10 milliseconds (the ACK period). For high 1910 bit rate transmissions, a "light ACK" can be sent, which is an ACK 1911 for a sequence of packets. In a 10 milliseconds interval, there are 1912 often so many packets being sent and received that the ACK position 1913 on the sender doesn't advance quickly enough. To mitigate this, 1914 after 64 packets (even if the ACK period has not fully elapsed) the 1915 receiver sends a light ACK. A light ACK is a shorter ACK (header + 1 1916 x 32-bit field). It does not trigger an ACKACK. 1918 When a receiver encounters the situation where the next packet to be 1919 played was not successfully received from the sender, it will "skip" 1920 this packet (see Section 4.6) and send a fake ACK. To the sender, 1921 this fake ACK is a real ACK, and so it just behaves as if the packet 1922 had been received. This facilitates the synchronization between SRT 1923 sender and receiver. The fact that a packet was skipped remains 1924 unknown by the sender. Skipped packets are recorded in the 1925 statistics on the SRT receiver. 1927 4.8.2. Packet Retransmission (NAKs) 1929 The SRT receiver sends NAK control packets to notify the sender about 1930 the missing packets. The NAK packet sending can be triggered 1931 immediately after a gap in sequence numbers of data packets is 1932 detected. 1934 Upon reception of the NAK packet, the SRT sender prioritizes 1935 retransmissions of lost packets over the regular data packets to be 1936 transmitted for the first time. 1938 The SRT sender maintains a list of lost packets (loss list) that is 1939 built from NAK reports. When scheduling packet transmission, it 1940 looks to see if a packet in the loss list has priority and sends it 1941 if so. Otherwise, it sends the next packet from the scheduled for 1942 the first transmission list. Note that when a packet is transmitted, 1943 it stays in the buffer in case it is not received by the SRT 1944 receiver. 1946 NAK packets are processed to fill in the loss list. As the latency 1947 window advances and packets are dropped from the sending queue, a 1948 check is performed to see if any of the dropped or resent packets are 1949 in the loss list, to determine if they can be removed from there as 1950 well so that they are not retransmitted unnecessarily. 1952 There is a counter for the packets that are resent. If there is no 1953 ACK for a packet, it will stay in the loss list and can be resent 1954 more than once. Packets in the loss list are prioritized. 1956 If packets in the loss list continue to block the send queue, at some 1957 point this will cause the send queue to fill. When the send queue is 1958 full, the sender will begin to drop packets without even sending them 1959 the first time. An encoder (or other application) may continue to 1960 provide packets, but there's no place for them, so they will end up 1961 being thrown away. 1963 This condition where packets are unsent doesn't happen often. There 1964 is a maximum number of packets held in the send buffer based on the 1965 configured latency. Older packets that have no chance to be 1966 retransmitted and played in time are dropped, making room for newer 1967 real-time packets produced by the sending application. See sections 1968 Section 4.5, Section 4.6 for details. 1970 In addition to the regular NAKs, the Periodic NAK report mechanism 1971 can be used to send NAK reports periodically. The NAK packet in that 1972 case will have all the packets that the receiver considers being lost 1973 at the time of sending the Periodic NAK report. 1975 An ACKACK tells the receiver to stop sending the ACK position because 1976 the sender already knows it. Otherwise, ACKs (with outdated 1977 information) would continue to be sent regularly. 1979 An ACK serves as a ping, with a corresponding ACKACK pong, to measure 1980 RTT. The time it takes for an ACK to be sent and an ACKACK to be 1981 received is the RTT. Each ACK has a number. A corresponding ACKACK 1982 has that same number. The receiver keeps a list of all ACKs in a 1983 queue to match them. Unlike a full ACK, which contains the current 1984 RTT and several other values in the CIF, a light ACK just contains 1985 the sequence number. All control messages are sent directly and 1986 processed upon reception, but ACKACK processing time is negligible 1987 (the time this takes is included in the round-trip time). 1989 4.9. Bidirectional Transmission Queues 1991 Once an SRT connection is established, both peers can send data 1992 packets simultaneously. 1994 4.10. Round Trip Time Estimation 1996 The round-trip time is estimated during the transmission of SRT data 1997 packets based on the time difference between the ACK packet is sent 1998 and the corresponding ACKACK is received by the data receiver. 2000 4.11. Congestion Control 2002 SRT provides certain mechanisms for the sender to get some feedback 2003 from the receiving side through the ACK packets (Section 3.2.3). 2004 Every 10 ms the sender receives the latest values of RTT and RTT 2005 variance, Available Buffer Size, Packets Receiving Rate and Estimated 2006 Link Capacity. Upon reception of the NAK packet (Section 3.2.4) the 2007 sender can detect packet losses during the transmission. These 2008 mechanisms provide a solid background for various congestion control 2009 algorithms. 2011 Given that SRT can operate in live and file transfer modes, there are 2012 two groups of congestion control algorithms possible. 2014 For live transmission mode (Section 4.2.2) the congestion control 2015 algorithm does not need to control the sending pace of the data 2016 packets, as the sending timing is provided by the live input. 2017 Although certain limitations on the minimal inter-sending time of 2018 consecutive packets can be applied in order to avoid congestion 2019 during fluctuations of the source bitrate. Also it is allowed to 2020 drop those packets that can not be delivered in time. 2022 For file transfer, any known File Congestion Control algorithms like 2023 CUBIC and BBR can apply, including the congestion control mechanism 2024 proposed in UDT [GHG04b]. The UDT congestion control relies on the 2025 available link capacity, packet loss reports (NAK) and packet 2026 acknowledgements (ACKs). It then slows down the output of packets as 2027 needed by adjusting the packet sending pace. In periods of 2028 congestion, it can block the main stream and focus on the lost 2029 packets. 2031 5. Encryption 2033 SRT supports encryption based on a pre-shared secret. Please refer 2034 to [SRTTO] for more information. 2036 6. Security Considerations 2038 SRT supports confidentiality of user data using stream ciphering 2039 based on AES. Session keys for ciphering are delivered through 2040 control packets during handshake, with the protection by Key 2041 Encryption Key, which is generated by a sender and receiver with pre- 2042 shared secret such as passphrase. As in UDT, careful uses of SYN 2043 Cookies may help to deter denial of service attacks. Appropriate 2044 security policy including key size, key refresh period, as well as 2045 passphrase should be managed by security officers, which is out of 2046 scope of the present document. 2048 7. IANA Considerations 2050 This document makes no requests of the IANA. 2052 Contributors 2054 This specification is heavily based on the SRT Protocol Technical 2055 Overview [SRTTO] written by Jean Dube and Steve Matthews. 2057 In alphabetical order, the contributors to the pre-IETF SRT project 2058 and specification at Haivision are: Marc Cymontkowski, Roman 2059 Diouskine, Jean Dube, Mikolaj Malecki, Steve Matthews, Maria 2060 Sharabayko, Maxim Sharabayko, Adam Yellen. 2062 The contributors to this specification at SK Telecom are Jeongseok 2063 Kim and Joonwoong Kim. 2065 We cannot list all the contributors to the open-sourced 2066 implementation of SRT on GitHub. But we appreciate the help, 2067 contribution, integrations and feedback of the SRT and SRT Alliances 2068 community. 2070 Acknowledgments 2072 The basis of the SRT protocol and its implementation was the UDP- 2073 based Data Transfer Protocol [GHG04b]. The authors thank Yunhong Gu 2074 and Robert Grossman, the authors of the UDP-based Data Transfer 2075 Protocol [GHG04b]. 2077 TODO acknowledge. 2079 References 2081 Normative References 2083 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2084 DOI 10.17487/RFC0768, August 1980, 2085 . 2087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2088 Requirement Levels", BCP 14, RFC 2119, 2089 DOI 10.17487/RFC2119, March 1997, 2090 . 2092 Informative References 2094 [AV1] Rivaz, P.d. and J. Haughton, "AV1 Bitstream & Decoding 2095 Process Specification", March 2020, 2096 . 2098 [GHG04b] Gu, Y., Hong, X., and R.L. Grossman,, "Experiences in 2099 Design and Implementation of a High Performance Transport 2100 Protocol", DOI 10.1109/SC.2004.24, December 2004, 2101 . 2103 [H.265] International Telecommunications Union, "H.265 : High 2104 efficiency video coding", ITU-T Recommendation H.265, 2105 2019. 2107 [I-D.ietf-quic-http] 2108 Bishop, M., "Hypertext Transfer Protocol Version 3 2109 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 2110 quic-http-27, 21 February 2020, . 2113 [I-D.ietf-quic-transport] 2114 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 2115 and Secure Transport", Work in Progress, Internet-Draft, 2116 draft-ietf-quic-transport-27, 21 February 2020, 2117 . 2120 [ISO13818-1] 2121 ISO, "Information technology -- Generic coding of moving 2122 pictures and associated audio information: Systems", ISO/ 2123 IEC 13818-1, March 2020. 2125 [ISO23009] ISO, "Information technology -- Dynamic adaptive streaming 2126 over HTTP (DASH)", ISO/IEC 23009:2019, March 2020. 2128 [PNPID] "PNP ID AND ACPI ID REGISTRY", March 2020, 2129 . 2131 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2132 Label Switching Architecture", RFC 3031, 2133 DOI 10.17487/RFC3031, January 2001, 2134 . 2136 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2137 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2138 May 2017, . 2140 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 2141 RFC 8216, DOI 10.17487/RFC8216, August 2017, 2142 . 2144 [RTMP] "Real-Time Messaging Protocol", March 2020, 2145 . 2147 [SP800-38A] 2148 Dworkin, M., "Recommendation for Block Cipher Modes of 2149 Operation", December 2001. 2151 [SRTSRC] "SRT fully functional reference implementation", March 2152 2020, . 2154 [SRTTO] Dube, J. and S. Matthews, "SRT Protocol Technical 2155 Overview", December 2019. 2157 [VP9] WebM, "VP9 Video Codec", March 2020, 2158 . 2160 Appendix A. Packet Sequence List coding 2162 For any single packet sequence number, it uses the original sequence 2163 number in the field. The first bit must start with "0". 2165 0 1 2 3 2166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 |0| Sequence Number | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 Figure 15: single sequence numbers coding 2173 For any consecutive packet sequence numbers that the difference 2174 between the last and first is more than 1, only record the first (a) 2175 and the the last (b) sequence numbers in the list field, and modify 2176 the the first bit of a to "1". 2178 0 1 2 3 2179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 |1| Sequence Number a (first) | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 |0| Sequence Number b (last) | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 Figure 16: list of sequence numbers coding 2188 Authors' Addresses 2190 Maxim Sharabayko 2191 Haivision Network Video, GmbH 2193 Email: maxsharabayko@haivision.com 2195 Maria Sharabayko 2196 Haivision Network Video, GmbH 2197 Email: msharabayko@haivision.com 2199 Jean Dube 2200 Haivision 2202 Email: jdube@haivision.com 2204 Jeongseok Kim 2205 SK Telecom Co., Ltd. 2207 Email: jeongseok.kim@sk.com 2209 Joonwoong Kim 2210 SK Telecom Co., Ltd. 2212 Email: joonwoong.kim@sk.com