-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ftl-specification-00.xml
335 lines (300 loc) · 14.5 KB
/
draft-ftl-specification-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.tools.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml2rfc.tools.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes" ?>
<!-- generate a ToC -->
<?rfc tocdepth="4" ?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes" ?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ftl-specification-00" submissionType="IAB" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">Faster-Than-Light Streaming Protocl Specification</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Michael Casadevall" initials="M.C." role="editor" surname="Casadevall">
<organization>Indepedent</organization>
<address>
<postal>
<street />
<!-- Reorder these if your country does things differently -->
<city>Jersey City</city>
<region />
<code />
<country>United States</country>
</postal>
<email>michael@casadevall.pro</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2021" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Faster-Than-Light Standardization Effort</workgroup>
<keyword>template</keyword>
<abstract>
<t>With the demise of Microsoft's Mixer, the future of the Faster-Than-Light (FTL) streaming protocol has been left in doubt.
As the Internet's first practical subsecond streaming protocol, several successors to Mixer have decided to re-implement
FTL from the original SDK and notes. While Mixer's original FTL specification had a de-facto specification in the form of
ftl-sdk, the source code was in-complete, and several aspects of the FTL were left undocumented.
</t>
<t>In an effort to keep FTL viable and cross-service compatible, this specification denotes a canonical implementation of FTL,
handshake protocols, WebRTC notes, and all relevant information as relating to FTL with the hope that FTL may still be continued
as a vechile for low latency video streaming over the Internet.
</t>
</abstract>
</front>
<middle>
<section title="Introduction and Overview">
<t>This specification covers several components of the FTL protocol stream, and is primarily derieved from the implementation used
at Mixer and the freely available source code in ftl-sdk. This document details the handshaking protocol known as Charon, the
SRTP ingest behaviors, and defines a recommended ingest->endpoint streaming protocol, as well as notes in regards to implementation
of the last mile WebRTC connections.</t>
<t>FTL was specifically designed with the following objectives in mind which is must handle at all times.</t>
<t>
<list style="symbols">
<t>
Real-world 500 millsecond delay for streamer to receiver broadcast under normal cirmstances at 30 FPS or more
<list style="symbols">
<t>At the time of it's implementation, 720p streaming was considered the best possible for most users, however,
advancements in technology have allowed for 1080p streaming.</t>
</list>
</t>
<t>That FTL has be technology neutral; it should be able to use any video or audio codec as supported by WebRTC
(or another last mile technology) independently. The original FTL implemntation used VP8 and Opus, later ones
used H.264, keeping with the original intent.</t>
<t>It is expected that to reduce latency, an FTL deployment has multiple ingest and points of presenses for client connections.
A stream connects to one ingest point, and then data is routed to points of presence as necessary.</t>
<t>FTL end-points must support being behind anycast, as well as use of STUN, and TURN if necessary</t>
<t>Use of standards based technology for use in a web browser with no additional software or downloads for viewers</t>
</list>
</t>
<t>As originally designed, the following criticera were also kept in mind, although not realized at least during the initial
implementation phases.</t>
<t>
<list style="symbols">
<t>Use of IPv6
<list style="symbols">
<t>IPv6 deployment and usage was considered highly desirable for multiple reasons, primarily to simplify
routing and mandated multicast support; as implemented, there should be no known IPv6 problems, but
the protocol never tested either.</t>
</list></t>
</list>
</t>
</section>
<section title="Design Tradeoffs/Limitations">
<t>TBD</t>
</section>
<section title="One-to-Many WebRTC">
<t>TBD</t>
</section>
<section title="A Note on SSRCs">
<t>TBD</t>
</section>
<section title="Charon Negotiation Protocol">
<t>Charon handles negotiation of RTP streams to Styx, and acts as an out of band signaling
method for FTL stream behavior. The Charon connection MUST be kept-alive at all times as
a TCP/IP connection on port 8084 (MC: should apply for IANA number). Upon establishment of
a CONNECT, a client MUST send PING messages once every five seconds, or the server MAY time-out
the connection.</t>
<t>It is RECOMMENDED that the server wait 10 seconds before assuming that a client has hung and
hanging up. PING messages must be responded to with a 201 respond code. The server SHOULD send
5XX Timeout message before disconnecting. (Ed: fix this and actually put the client behavior)</t>
<t>If the TCP/IP connection is reset, the broadcaster MUST assume that the ingest point of presence
has become unavailable, and begin clean-up and teardown. Likewise, the ingest daemon MUST begin
teardown and disregard any UDP traffic from the streamer upon Charon connection loss.
</t>
<t>The Charon protocol is built upon ASCII verbs with optional arguments. The lifecycle of this
connection under normal circumstances is as follows.
</t>
<t>
<list style="symbols">
<t>Broadcaster connects to ingest on TCP/IP 8084</t>
<t>Broadcaster gets HMAC authentication</t>
<t>Broadcaster generates HMAC authentication based off streamer connection ID and channel idea</t>
<t>Broadcaster sends CONNECT, combined with stream paramters.</t>
<t>Ingest sends FTL_OK or FTL_REJECT based on settings</t>
<t>If FLT_OK, Broadcaster sends RTP streams to the media port indicated by the ingest</t>
<t>Broadcaster starts RTP streams per Ingests response</t>
<t>Every five seconds, a PING response is sent, ingest replies with 201</t>
<t>Broadcaster sends DISCONNECT for orderly shutdown</t>
</list>
</t>
<section title="Message Format">
<t>Charon is directly modeled on SMTP commands and response codes. As such, commands take the form of a verb,
followed by a three digital response. An example exchange looks as such:</t>
<figure align="center">
<artwork><![CDATA[
Client: PING\r\n\r\n
Server: 201 Ping OK!\r\n\r\n
]]></artwork>
</figure>
<t>For legacy reasons, linebreaks in Charon are encoded as '\r\n\r\n' (hex 0x0D0A0D0A), with an unusually complex
implementation detail. See the section "On Linebreaks" for more details.</t>
<t>For commands that do not need additional meta-data, the server SHALL process them immediately upon receiving a
linebreak, otherwise, a multiline format using RFC822 headers is defined, with the message ended with a single
period. Unknown headers MUST be disregarded by the server. This message exchange looks as follows:</t>
<figure align="center">
<artwork><![CDATA[
Client: CONNECT 1234-myhashhere\r\n\r\n
C: Video: true\r\n\r\n
C: Audio: true\r\n\r\n
C: .\r\n\r\n
Server: 200 Send UDP!\r\n\r\n
]]></artwork>
</figure>
<t>The Charon protocol does not allow for transmission of binary data without encoding. If necessary, it is RECOMMENDED
that binary data base encoded in Base64.</t>
<section title="On Linebreaks">
<t>The reference implementation of FTL uses the message signature '\r\n\r\n' as an end of line marker.
This is an intentional implementation detail due to an unintentional similarity between FTL's CONNECT message,
and the HTTP CONNECT proxy command, and Microsoft discovered that some commercial firewalls would intercept
Charon's messages. The original justification was left as this comment in ftl_helpers.c</t>
<figure align="center">
<artwork><![CDATA[
/*
Please note that throughout the code, we send "\r\n\r\n", where a
normal newline ("\n") would suffice. This is done due to some
firewalls / anti-malware systems not passing our packets
through when we don't send those double-windows-newlines. They
seem to incorrectly detect our protocol as HTTP.
*/
]]></artwork>
</figure>
<t>A problem however arises that earlier implementations of FTL used "\n" as a newline indicator.
While it is unlikely that any of these legacy FTL clients are still in use, clients and ingests
must use the following behaviors</t>
<t>Charon servers MUST disregard any empty newline, and treat "\r\n" and "\n" as identical for the purposes
of message parsing. In effect, all the following are the same.</t>
<figure align="center">
<artwork><![CDATA[
CONNECT 1234-hash\n
Option1: 1234\n
Option2: 1234\n
.\n
CONNECT 1234-hash\r\n
Option1: 1234\r\n
Option2: 1234\r\n
.\r\n
CONNECT 1234-hash\r\n
Option1: 1234\r\n\r\n
Option2: 1234\r\n\r\n
.\r\n\
]]></artwork>
</figure>
<t>Charon clients MUST to use '\r\n\r\n' when transmitting commands over clear text.</t>
</section> <!-- newlines -->
</section>
<section title="Response Codes"></section>
<section title="Charon Verbs">
<section title="HMAC">
<t>TDB</t>
</section>
<section title="CONNECT">
<t>TDB</t>
<section title="ProtocolVersion">
<t>TBD</t>
</section>
<section title="VendorName">
<t>TBD</t>
</section>
<section title="VendorVersion">
<t>TBD</t>
</section>
<section title="Video">
<t>TBD</t>
</section>
<section title="VideoCodex">
<t>TBD</t>
</section>
<section title="VideoHeight">
<t>TBD</t>
</section>
<section title="VideoWidth">
<t>TBD</t>
</section>
<section title="VideoPayloadType">
<t>TBD</t>
</section>
<section title="VideoIngestSSRC">
<t>TBD</t>
</section>
<section title="Audio">
<t>TBD</t>
</section>
<section title="AudioCodec">
<t>TBD</t>
</section>
<section title="AudioPayloadType">
<t>TBD</t>
</section>
<section title="AudioIngestSSRC">
<t>TBD</t>
</section>
</section>
<section title="DISCONNECT">
<t>TBD</t>
</section>
<section title="PING">
<t>TBD</t>
</section>
</section>
</section>
<section title="Styx Protocol Ingest Behavior">
<t>TBD</t>
</section>
<section title="Babel Transcoding Behavior">
<t>TBD</t>
</section>
<section title="WebRTC Last Mile Negotations">
<t>TBD</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- Change Log
v00 2021-01-04 MC Initial version
-->
</back>
</rfc>