| Faster-Than-Light Standardization Effort | M. Casadevall, Ed. |
| Internet-Draft | Indepedent |
| Intended status: Informational | January 5, 2021 |
| Expires: July 9, 2021 |
Faster-Than-Light Streaming Protocl Specification
draft-ftl-specification-00
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.
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2021.
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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.
FTL was specifically designed with the following objectives in mind which is must handle at all times.
As originally designed, the following criticera were also kept in mind, although not realized at least during the initial implementation phases.
TBD
TBD
TBD
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.
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)
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.
The Charon protocol is built upon ASCII verbs with optional arguments. The lifecycle of this connection under normal circumstances is as follows.
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:
Client: PING\r\n\r\n
Server: 201 Ping OK!\r\n\r\n
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.
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:
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
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.
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
/*
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.
*/
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
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.
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\
Charon clients are MUST to use '\r\n\r\n' when transmitting commands over clear text.
TDB
TDB
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD