Skip to main content
Content Delivery Protocols

Implementation Detail

In short
  • rt-libflute is a FLUTE sender and receiver. It is judged against every requirement of the FLUTE documents that falls on a sender or a receiver, in each of the four ways FLUTE is specified:
    • Unprofiled FLUTE (RFC 3926 and its building blocks): 38 requirements in 107 cases: 79 implemented, 21 differ from the specification, 7 not implemented.
    • FLUTE version 2 (RFC 6726): 17 cases: 15 implemented, 1 differs from the specification, 1 not implemented.
    • MBMS download (TS 26.346, with the unprofiled requirements it keeps): 146 cases: 121 implemented, 20 differ from the specification, 3 not implemented, 2 where the specification contradicts itself.
    • MBS Object Distribution (TS 26.517 and the MBMS Download Profile, with the unprofiled requirements they keep): 118 cases: 94 implemented, 21 differ from the specification, 3 not implemented.
  • Releases: the 3GPP profiles are judged at Release 18 (TS 26.346 V18.2.0, TS 26.517 V18.6.0), the issues the code is built against; Release 17 gives the same result. At Release 19 (TS 26.346 V19.3.0, TS 26.517 V19.3.0), MBMS download has 120 of 146 cases implemented and MBS Object Distribution 93 of 118: the code writes the Release 18 FDT schema versions, 4 and 2, where Release 19 requires 5 and 3.
  • Not judged here: session descriptions, reception and operating modes, caching policy and repair belong to the components that use the library: the MBS Client (rt-mbs-client) and the MBSTF (rt-mbs-transport-function) for MBS, the MBMS Client (rt-mbms-client) and the BM-SC (rt-mbms-bmsc) for MBMS; see below.
  • Source of this page: a code audit of the repository, every open change read as merged: each requirement split into the cases its clauses define, then re-checked by a second reader.

For what the specifications define, see the Standards page and the Technical Analysis. For how to run the tools, see the Tutorials.

Unprofiled FLUTE​

FLUTE version 1 as the IETF defines it: RFC 3926 on ALC and LCT, the FEC building block and schemes, and WEBRC congestion control. The 3GPP profiles keep most of these requirements as they are; the sections below give only what they change or add. Filter by component; open a feature, then a requirement.

  • Unprofiled FLUTE: RFC 3926 (FLUTE version 1), RFC 3450 (ALC), RFC 3451 (LCT), RFC 5052 and RFC 3695 (FEC), RFC 5053 and RFC 6330 (Raptor, RaptorQ), RFC 3738 (WEBRC).
  • Sender (FLUTE sender (Transmitter and FDT writer), and the senders built on it): rt-libflute. Built against: RFC 3926, RFC 3450 and RFC 3451; RFC 6726 for version 2; TS 26.346 and TS 26.517 at Release 18.
  • Receiver (FLUTE receiver (Receiver, FDT parser and file reassembly), and the clients built on it): rt-libflute. Built against: the same.
  • Source: code read against every requirement of the FLUTE documents in the library's scope, every open change read as merged into main, nothing built or run for the verdicts, 2026-10-06.
79 of 107 implemented · 21 differ · 7 absentcases, over 38 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

Sessions, objects and packetsThe TSI and TOI are carried and checked as ALC and LCT require; the receiver checks the sender address only when the session names its source, and never leaves a session it cannot process.14 of 17 implemented · 2 differ · 1 absent
LCT header and extensionsThe default LCT header and the extensions FLUTE uses are written and parsed as required, with the 3GPP specialisations (zero 32-bit CCI, 16-bit TSI and TOI, no SCT or ERT) under the profiles.18 of 18 implemented
File Delivery TableThe FDT carries what each profile requires and none of what the MBMS Download Profile excludes, but the extended schema lacks its schema-version namespace and delimiters, the profiled schema's Cache-Control and File-ETag are written and read in the extension namespaces, a changed description keeps its TOI, Content-MD5 covers the unencoded file, FDT-Instance Content-Type and Content-Encoding are not applied to files, and numbering starts from 1.21 of 27 implemented · 6 differ
FEC and blockingCompact No-Code, Raptor and RaptorQ are sent and received, and blocking follows the documents; the decoder ignores the block structure the sender signals, a packet can mix source blocks, a short last symbol in a multi-symbol packet is lost, and RaptorQ's payload ID and EXT_FTI use the wrong field widths.15 of 27 implemented · 10 differ · 2 absent
Congestion control and channelsWEBRC runs on both sides outside the 3GPP profiles, whose single channel at a single rate is kept; the WEBRC receiver is never fed the measurements it needs, so it never joins a wave channel, and would not leave one.9 of 15 implemented · 3 differ · 3 absent
Content encodinggzip files are decoded; under the 3GPP profiles the sender does not encode, since the profile leaves no way to carry the transfer length.2 of 3 implemented · 1 absent

FLUTE version 2​

What RFC 6726, with ALC (RFC 5775) and LCT (RFC 5651), changes from version 1. Neither 3GPP profile uses it.

  • FLUTE version 2: RFC 6726, RFC 5775 (ALC), RFC 5651 (LCT).
  • Sender (FLUTE sender (Transmitter and FDT writer), and the senders built on it): rt-libflute. Built against: RFC 3926, RFC 3450 and RFC 3451; RFC 6726 for version 2; TS 26.346 and TS 26.517 at Release 18.
  • Receiver (FLUTE receiver (Receiver, FDT parser and file reassembly), and the clients built on it): rt-libflute. Built against: the same.
  • Source: code read against every requirement of the FLUTE documents in the library's scope, every open change read as merged into main, nothing built or run for the verdicts, 2026-10-06.
15 of 17 implemented · 1 differs · 1 absentcases, over 7 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

Sessions, objects and packetsThe receiver tells versions apart by the EXT_FDT version field.1 of 1 implemented
LCT header and extensionsVersion 2 is written in EXT_FDT, the version 1 SCT and ERT fields are dropped, and version 2 is refused under the 3GPP profiles.4 of 4 implemented
File Delivery TableInstance IDs are never reused while live, expiry is read in the nearest era and the newer declaration of a file wins; choosing version 2 does not select its namespace, and reuse of a live ID is not detected at the receiver.8 of 10 implemented · 1 differs · 1 absent
FEC and blockingThe FEC Encoding ID is carried in the Codepoint.1 of 1 implemented
Congestion control and channelsWEBRC, which version 2 requires, is implemented.1 of 1 implemented

MBMS download​

What TS 26.346 adds to FLUTE for MBMS download (clause 7.2 and annex A), and the MBMS Download Profile of annex L.4. Congestion control, RaptorQ, the other optional FEC schemes, the ERT bound and FDT content encoding are replaced by the profile, so the unprofiled cases for them do not count here.

  • MBMS download: TS 26.346 V18.2.0 clause 7.2 and annex A.
  • MBMS Download Profile: TS 26.346 V18.2.0 annex L.4, followed by both MBMS download and MBS Object Distribution.
  • Sender (FLUTE sender (Transmitter and FDT writer), and the senders built on it): rt-libflute, rt-mbms-bmsc. Built against: RFC 3926, RFC 3450 and RFC 3451; RFC 6726 for version 2; TS 26.346 and TS 26.517 at Release 18.
  • Receiver (FLUTE receiver (Receiver, FDT parser and file reassembly), and the clients built on it): rt-libflute, rt-mbms-client. Built against: the same.
  • Source: code read against every requirement of the FLUTE documents in the library's scope, every open change read as merged into main, nothing built or run for the verdicts, 2026-10-06.
3GPP release
56 of 66 implemented · 6 differ · 2 absent · 2 where the specification is inconsistentcases, over 19 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

LCT header and extensionsThe header specialisations of clause 7.2.7, EXT_FTI only on FDT packets and no SCT or ERT are applied; the data-less Close Session packet cannot carry both no TOI and a 16-bit TSI, and the documents do not say which wins.14 of 15 implemented · 1 where the specification is inconsistent
File Delivery TableEvery element the profile requires is carried and none it excludes, except FEC-OTI-Max-Number-of-Encoding-Symbols; the extended schema lacks its schema-version namespace and delimiters, Content-Type is written on every File instead of only to override, and the receiver reads neither FDT-Instance Content-Type nor max-stale.25 of 30 implemented · 3 differ · 2 absent
FEC and blockingCompact No-Code and Raptor are sent with the required blocking; the Raptor decoder ignores the block structure the sender signals.11 of 14 implemented · 3 differ
Congestion control and channelsOne channel at one rate, with WEBRC refused.3 of 3 implemented
Content encodinggzip is decoded; the profile gives a sender no way to carry an encoded file's transfer length.3 of 4 implemented · 1 where the specification is inconsistent

MBS Object Distribution​

The MBMS Download Profile, which the MBS Distribution Session follows, and what TS 26.517 and the Profiled FDT Schema of annex L.6 add.

  • MBMS Download Profile: TS 26.346 V18.2.0 annex L.4, followed by both MBMS download and MBS Object Distribution.
  • MBS Object Distribution: TS 26.517 V18.6.0 clause 6.2, with the Profiled FDT Schema of TS 26.346 V18.2.0 annex L.6.
  • Sender (FLUTE sender (Transmitter and FDT writer), and the senders built on it): rt-libflute, rt-mbs-transport-function. Built against: RFC 3926, RFC 3450 and RFC 3451; RFC 6726 for version 2; TS 26.346 and TS 26.517 at Release 18.
  • Receiver (FLUTE receiver (Receiver, FDT parser and file reassembly), and the clients built on it): rt-libflute, rt-mbs-client. Built against: the same.
  • Source: code read against every requirement of the FLUTE documents in the library's scope, every open change read as merged into main, nothing built or run for the verdicts, 2026-10-06.
3GPP release
26 of 34 implemented · 7 differ · 1 absentcases, over 8 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

LCT header and extensionsEXT_FTI only on FDT packets and no SCT or ERT, as the MBMS Download Profile requires.4 of 4 implemented
File Delivery TableThe Profiled FDT Schema is used, but Cache-Control and File-ETag are written and read in the extension namespaces instead of the profiled one, Content-Type is written on every File instead of only to override, and the receiver reads neither FDT-Instance Content-Type nor max-stale.18 of 25 implemented · 6 differ · 1 absent
FEC and blockingBoth schemes are offered at the sender; the Raptor decoder ignores the block structure the sender signals.3 of 4 implemented · 1 differs
Congestion control and channelsOne channel at one rate.1 of 1 implemented

Judged with the clients and the MBSTF​

rt-libflute is the FLUTE layer of four Reference Tools, one sender and one receiver for each 3GPP profile:

ProfileSenderReceiver
MBMS downloadBM-SC (rt-mbms-bmsc)MBMS Client (rt-mbms-client)
MBS Object DistributionMBSTF (rt-mbs-transport-function)MBS Client, its MBSTF Client (rt-mbs-client)

These requirements of the same documents fall on those components rather than on the library:

FeatureDocumentsMBS Object DistributionMBMS download
Session descriptionRFC 3926 section 6; TS 26.346 clause 7.3 and table L.4.8-1; TS 26.517 clause 6.2.2MBS Client and MBSTF: 5G MBS implementationMBMS Client and BM-SC: not yet audited case by case
Reception and operating modesTS 26.346 clause 7.2.0; TS 26.517 clause 6.2.3MBSTF: 5G MBS implementationMBMS Client: not yet audited case by case
Caching policyTS 26.346 clause 7.2.13MBS Client; the library reads the directives (above)MBMS Client; the library reads the directives (above)
Repair and reception reportingTS 26.346 clauses 9.3, 9.4 and 9.4B; TS 26.517 clause 6.2.4MBS Client: 5G MBS implementationMBMS Client: not yet audited case by case
Full audit for members

This page summarises a requirement-by-requirement audit of the code. The full audit (each requirement with its clauses quoted, the code that meets or misses it, and the findings) is available to 5G-MAG members through Developer Tools (the Standards2Deployments repository).

Become a member · Request access

rt-media-origin: packaging and delivery​

A config-driven media origin: it packages each channel with ffmpeg as DASH, HLS or CMAF, and delivers it over HTTP or a push transport.

TransportDocument it followsWhat the receiving side needs
httpHTTPA DASH or HLS player
rtspRFC 2326 (RTSP 1.0)A server that accepts RTSP 1.0 publishing (ANNOUNCE and RECORD), such as MediaMTX; RFC 7826 (RTSP 2.0) removed both
rtmpAdobe RTMP 1.0 with FLV 10.1For HEVC, VP9, AV1 or VVC, Enhanced RTMP and a server that supports it
srtdraft-sharabayko-srt-01 (expired)A Stream ID declaring the mode when publishing to a relay
ristVSF TR-06-1:2020 (Simple Profile)An even media port, RTCP on the next one
rtpRFC 2250 over RFC 3550A receiver for MPEG-TS over RTP, payload type 33
moqdraft-lcurley-moq-liteA moq-lite relay, such as moq-dev's moq-relay
flutert-media-origin APIFLUTE transmission is done by rt-libflute-based tooling; the origin publishes the session metadata

It checks the manifests it produces against these named profiles. The checks cover manifest and segment signalling and structure, not codec or bitstream conformance.

ProfileSpecification
DASH-IFISO/IEC 23009-1, isoff-live-2011
DVB-DASHETSI TS 103 285
5GMS DASH IOPTS 26.247 clause 7.3.11
CMAFISO/IEC 23009-1, urn:mpeg💨profile:cmaf:2019
TV 720p HDTS 26.116
VR/OMAF BasicTS 26.118
DASH-IF Low-LatencyDASH-IF IOP v5
HLSRFC 8216

Coded Multisource Media Format (CMMF)​

rt-cmmf-encoder is an early-stage reference implementation of ETSI TS 103 973, packaging content for delivery from more than one network source at once. It is not yet audited against the published standard.

Components​

FLUTE Protocol and Profiles

This is an implementation of a FLUTE server and client.

Media Origin Server and Packager

A media origin server component for Content Delivery…

Reference Media Application

An Android test app and a laptop test rig that check every…

CMMF Encoder

Reference implementation of a CMMF Encoder according to…