RFC 9223
Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)
RFC 9223 Title Block 💖
Okay bestie, let's start with the basics 🎀
- RFC number: 9223 🦋
- Title: Real-Time Transport Object delivery over Unidirectional Transport (ROUTE)
- Stream: Independent Submission
- Category: Informational
- ISSN: 2070-1721
- Date: April 2022
- Obsoletes or updates: The title block doesn't list any RFCs that this one obsoletes or updates, so nothing gets replaced or changed 🙈
The authors are W. Zia and T. Stockhammer from Qualcomm CDMA Technologies GmbH, L. Chaponniere and G. Mandyam from Qualcomm Technologies Inc., and M. Luby from BitRipple, Inc. 👑
Abstract ✨
Okay so ROUTE (Real-time Transport Object delivery over Unidirectional Transport) is a protocol for robust delivery of Application Objects 💅 That includes the ones with real-time delivery constraints, sent to receivers over a unidirectional transport. Application Objects are just data that actually means something to the apps using ROUTE to get their data to receivers. It could be a file, a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, and so on. ROUTE also supports low-latency streaming apps, which is so good 😭
ROUTE works for unicast, broadcast, and multicast transport, so it can run over UDP/IP, including multicast IP. It can also lean on whatever the layer underneath already offers. For security, for example, it can use IP security protocols like IPsec 🔐
This document specifies ROUTE so that a bunch of different services can use it to deliver Application Objects, by making their own profiles of the protocol (like adding or restricting some features) 🌈
This is not an IETF specification and does not have IETF consensus. 🫶
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🌸
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor picked to publish this at its own discretion, and it makes no statement about how valuable this is for implementation or deployment. Documents the RFC Editor approves for publication are not candidates for any level of Internet Standard. See Section 2 of RFC 7841 for more on that 🧚
Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc9223 💜
Copyright Notice ✨
Copyright (c) 2022 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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜
Table of Contents 🍓
1. Introduction
1.1. Overview
1.2. Protocol Stack for ROUTE
1.3. Data Model
1.4. Architecture and Scope of Specification
1.5. Conventions Used in This Document
2. ROUTE Packet Format
2.1. Packet Structure and Header Fields
2.2. LCT Header Extensions
2.3. FEC Payload ID for Source Flows
2.4. FEC Payload ID for Repair Flows
3. Session Metadata
3.1. Generic Metadata
3.2. Session Metadata for Source Flows
3.3. Session Metadata for Repair Flows
4. Delivery Object Mode
4.1. File Mode
4.1.1. Extensions to FDT
4.1.2. Constraints on Extended FDT
4.2. Entity Mode
4.3. Unsigned Package Mode
4.4. Signed Package Mode
5. Sender Operation
5.1. Usage of ALC and LCT for Source Flow
5.2. ROUTE Packetization for Source Flow
5.2.1. Basic ROUTE Packetization
5.2.2. ROUTE Packetization for CMAF Chunked Content
5.3. Timing of Packet Emission
5.4. Extended FDT Encoding for File Mode Sending
5.5. FEC Framework Considerations
5.6. FEC Transport Object Construction
5.7. Super-Object Construction
5.8. Repair Packet Considerations
5.9. Summary FEC Information
6. Receiver Operation
6.1. Basic Application Object Recovery for Source Flows
6.2. Fast Stream Acquisition
6.3. Generating Extended FDT-Instance for File Mode
6.3.1. File Template Substitution for Content-Location
Derivation
6.3.2. File@Transfer-Length Derivation
6.3.3. FDT-Instance@Expires Derivation
7. FEC Application
7.1. General FEC Application Guidelines
7.2. TOI Mapping
7.3. Delivery Object Reception Timeout
7.4. Example FEC Operation
8. Considerations for Defining ROUTE Profiles
9. ROUTE Concepts
9.1. ROUTE Modes of Delivery
9.2. File Mode Optimizations
9.3. In-Band Signaling of Object Transfer Length
9.4. Repair Protocol Concepts
10. Interoperability Chart
11. Security and Privacy Considerations
11.1. Security Considerations
11.2. Privacy Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
1.1. Overview
ROUTE (Real-time Transport Object delivery over Unidirectional Transport) can be used for robust delivery of Application Objects, including the ones with real-time delivery constraints, to receivers over a unidirectional transport 🦋 "Unidirectional transport" means exactly what it means in RFC 6726 [RFC6726]: transport going from a sender toward the receiver(s) 💅 The robustness comes from built-in stuff, like signaling for loss detection that enables loss recovery, and optionally bringing in application-layer Forward Error Correction (FEC) 🛡️
Application Objects are data that has meaning to the apps using ROUTE to get their data to receivers. For instance, an Application Object can be a file, an MPEG Dynamic Adaptive Streaming over HTTP (DASH) [DASH] video segment, a WAV audio clip, an MPEG Common Media Application Format (CMAF) [CMAF] addressable resource, an MPEG-4 video clip, and more 🎬
ROUTE is designed to deliver sequences of related Application Objects to receivers in a timely way. Think of a run of DASH video segments tied to one Representation, or a run of CMAF addressable resources tied to a CMAF Track 🎞️ The apps here target services on media consumption devices like smartphones, tablets, television sets, and so on. Most of these apps are real-time, meaning they're sensitive to timely reception of data and depend on it ⏰ ROUTE also supports chunked delivery of real-time Application Objects for low-latency streaming apps, which behaves a lot like chunked delivery over HTTP. It also enables low-latency delivery of DASH and Apple HTTP Live Streaming (HLS) content with CMAF Chunks ⚡
Content that isn't meant to be rendered in real time as it arrives can also be delivered by ROUTE. That includes things like a downloaded application, a file with continuous or discrete media that belongs to an app-based feature, or a file with (opaque) data for a Digital Rights Management (DRM) system client to consume 🔒
ROUTE supports a caching model. Application Objects get recovered into a cache at the receiver, and apps can then reach them through standard HTTP requests against that cache. A lot of current apps rely on HTTP to access content, so this approach lets those apps work in broadcast and multicast environments too 📡
ROUTE is aligned with File Delivery over Unidirectional Transport (FLUTE) as defined in RFC 6726 [RFC6726], and with the extensions defined in Multimedia Broadcast/Multicast Service (MBMS) [MBMS]. It also borrows some ideas from FCAST (Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols), as defined in RFC 6968 [RFC6968]. For example, object metadata and object content can be sent together in one compound object 🧩
The alignment with FLUTE is a big deal because ROUTE reuses several of the basic FLUTE protocol features this document refers to. On top of that, it adds certain optimizations and restrictions that give real-time delivery of media data a fast lane, which is where the name comes from 🏎️ Among other things, the source ROUTE protocol enables or enhances these functionalities:
- Real-time delivery of object-based media data
- Flexible packetization, including media-aware packetization as well as transport-aware packetization of delivery objects
- Independence of Application Objects and delivery objects, meaning a delivery object may be part of a file or may be a group of files
Advanced Television Systems Committee (ATSC) 3.0 specifies ROUTE integrated with an ATSC 3.0 services layer. That spec is called ATSC-ROUTE [ATSCA331] for the rest of this document 📺 Digital Video Broadcasting (DVB) has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR] 🌟 This document covers the Application Object delivery aspects (the delivery protocol) for these services. The delivery protocol can serve as a reference for lots of services, which define their own profiles of ROUTE in their own fora, for example by adding new optional features on top or by restricting optional features specified here in a particular service standard 🧁 So in this document, ATSC-ROUTE and DVB-MABR are the services using ROUTE. Services defining profiles also have to think carefully about compatibility issues, and this document offers some related guidelines too 🫶
This document is not an IETF specification and does not have IETF consensus. It's provided here to help produce interoperable implementations, and that's the whole point 💖
1.2. Protocol Stack for ROUTE 🧚
Okay so ROUTE delivers Application Objects like MPEG DASH or HLS segments 🎬, and optionally the repair data that goes with them, all running over UDP/IP networks 🌐 (check out Table 1 below). The session metadata signaling used to set up a ROUTE session MAY be delivered out of band 📦 or in band 🎀, both are totally valid. ROUTE drops objects into an application cache on the receiver, and the app can grab them over HTTP 💖. So a DASH app can keep using its normal unicast streaming stuff while ROUTE handles broadcast/multicast to level up the whole service ✨. Teamwork makes the dream work 👯♀️
+--------------------------------------------------------+
| Application (DASH and HLS segments, CMAF Chunks, etc.) |
+--------------------------------------------------------+
| ROUTE |
+--------------------------------------------------------+
| UDP |
+--------------------------------------------------------+
| IP |
+--------------------------------------------------------+
Table 1: Protocol Layering1.3. Data Model 💅
Okay, the data model is built out of these key concepts, bestie, so let's break them down 🫶
- Application Object: data that has meaning to the application that uses the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, a DASH video segment, a WAV audio clip, an MPEG-4 video clip, etc. 🎞️
- Delivery Object: an object on course of delivery to the application from the ROUTE sender to ROUTE receiver. 🚚
- Transport Object: an object identified by the Transport Object Identifier (TOI) in RFC 5651 [RFC5651]. It MAY be either a source or a repair object, depending on if it is carried by a Source Flow or a Repair Flow, respectively. 🆔
- Transport Session: a Layered Coding Transport (LCT) channel, as defined by RFC 5651 [RFC5651]. A Transport Session SHALL be uniquely identified by a unique Transport Session Identifier (TSI) value in the LCT header. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. Transport Sessions are a subset of a ROUTE session. For media delivery, a Transport Session would typically carry a media component, for example, a DASH Representation. Within each Transport Session, one or more objects are carried, typically objects that are related, e.g., DASH segments associated to one Representation. 🚇
- ROUTE Session: an ensemble or multiplex of one or more Transport Sessions. Each ROUTE session is associated with an IP address/port combination. A ROUTE session typically carries one or more media components of streaming media e.g., Representations associated with a DASH Media Presentation. 🌈
- Source Flow: a Transport Session carrying source data. Source Flow is independent of the Repair Flow, i.e., the Source Flow MAY be used by a ROUTE receiver without the ROUTE Repair Flows. 💧
- Repair Flow: a Transport Session carrying repair data for one or more Source Flows. 🩹
1.4. Architecture and Scope of Specification 🏗️
The whole point of ROUTE is robust, real-time transport of delivery objects using LCT packets, and the setup is shown in Figure 1. It's giving architecture goals 🤌
The normative aspects of the ROUTE protocol focus on the following aspects:
- The format of the LCT packets that carry the transport objects. 📦
- The robust transport of the delivery object using a repair protocol based on Forward Error Correction (FEC). 🛡️
- The definition and possible carriage of object metadata along with the delivery objects. Metadata may be conveyed in LCT packets and/or separate objects. 🏷️
- The ROUTE session, LCT channel, and delivery object description provided as service metadata signaling to enable the reception of objects. 📡
- The normative aspects (formats, semantics) of the delivery objects conveyed as a content manifest to be delivered along with the objects to optimize the performance for specific applications e.g., real-time delivery. The objects and manifest are made available to the application through an Application Object cache. The interface of this cache to the application is not specified in this document; however, it will typically be enabled by the application acting as an HTTP client and the cache as the HTTP server. 🎯
Application Objects
Application to application
Objects from ^
an application +--------------------------------------------+
+ | ROUTE Receiver | |
| | +------+------+ |
| | | Application | |
| | | Object Cache| |
| | +------+------+ |
| LCT over| +---------------+ ^ |
v UDP/IP | | Source object | +---------+ | |
+----+---+ | +->+ recovery +--+ Repair +-+ |
| ROUTE | | | +---------------+ +----+----+ |
| Sender +----------+ ^ |
+----+---+ | | | |
| | | +---------------+ | |
| | | | Repair object | | |
| | +->+ recovery +-------+ |
+----------->+ +---------------+ |
ROUTE | |
Metadata +--------------------------------------------+
Figure 1: Architecture/Functional Block Diagram1.5. Conventions Used in This Document 📝
Quick vibe check on the keywords. When these words show up in this doc, they're read the way BCP 14 [RFC2119] [RFC8174] says, but only when they're written in all capitals like this 🙌
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
2. ROUTE Packet Format ✨
2.1. Packet Structure and Header Fields 🎀
okay so the ROUTE packet is basically an ALC packet (the one from RFC 5775 [RFC5775]) and it's stacked like a sandwich 🥪✨ UDP header on the bottom, then the default LCT header, then the source FEC Payload ID, and then the actual payload at the top. It's giving layers, bestie 💅 Check out Figure 2 below to see the whole stack.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Overall ROUTE Packet FormatThe Default LCT header comes from the LCT building block in RFC 5651 [RFC5651], and the LCT packet header fields SHALL be used exactly as that building block defines them 🫶 On top of that, ROUTE adds some extra rules for a few of the LCT fields, so pay attention, bestie 👑
Version number (V): This 4-bit field indicates the protocol version number. The version number SHALL be set to '0001', as specified in RFC 5651 [RFC5651]. 🌸
Congestion Control flag (C) field: This 2-bit field, as defined in RFC 5651 [RFC5651], SHALL be set to '00'. 💖
Protocol-Specific Indication (PSI): The most significant bit of this 2-bit flag is called the Source Packet Indicator (SPI). It tells you whether the current packet is a source packet or a FEC repair packet 🦋 The SPI SHALL be set to '1' to indicate a source packet and SHALL be set to '0' to indicate a repair packet. (Yes, I fixed the typo "bet" in the original, we love a clean spec ✨)
Transport Session Identifier flag (S): This 1-bit field SHALL be set to '1' to indicate a 32-bit word in the TSI field. 🧚
Transport Object Identifier flag (O): This 2-bit field SHALL be set to '01' to indicate the number of full 32-bit words in the TOI field. 🍓
Half-word flag (H): This 1-bit field SHALL be set to '0' to indicate that no half-word field sizes are used. 🌈
Codepoint (CP): This 8-bit field tells you what type of payload is riding in the packet. For ROUTE, it's defined in the table below to show what kind of delivery object is inside the payload of the ROUTE packet 💜 The remaining unmapped Codepoint values can be used by a service using ROUTE. When they are, the Codepoint values SHALL follow the semantics in the following table. "IS" means Initialization Segment of the media content, like the DASH Initialization Segment [DASH]. The different modes in the table (File/Entity/Package Mode) are specified in Section 4. The table also has a Codepoint range that's reserved for future service-specific uses 🎀
+=================+=================================+
| Codepoint value | Semantics |
+=================+=================================+
| 0 | Reserved (not used) |
+-----------------+---------------------------------+
| 1 | Non Real Time (NRT) - File Mode |
+-----------------+---------------------------------+
| 2 | NRT - Entity Mode |
+-----------------+---------------------------------+
| 3 | NRT - Unsigned Package Mode |
+-----------------+---------------------------------+
| 4 | NRT - Signed Package Mode |
+-----------------+---------------------------------+
| 5 | New IS, timeline changed |
+-----------------+---------------------------------+
| 6 | New IS, timeline continued |
+-----------------+---------------------------------+
| 7 | Redundant IS |
+-----------------+---------------------------------+
| 8 | Media Segment, File Mode |
+-----------------+---------------------------------+
| 9 | Media Segment, Entity Mode |
+-----------------+---------------------------------+
| 10 | Media Segment, File Mode with |
| | CMAF Random Access chunk |
+-----------------+---------------------------------+
| 11 - 255 | Reserved, service-specific |
+-----------------+---------------------------------+Table 2: Codepoint Values
Congestion Control Information (CCI): For packets carrying DASH segments, CCI MAY convey the 32-bit earliest presentation time [DASH] of the DASH segment inside the ROUTE packet. When it does, a ROUTE receiver can use it for fast stream acquisition (the juicy details are in Section 6.2) 🚀 Otherwise, this field SHALL be set to 0. 🧸
Transport Session Identifier (TSI): This 32-bit field identifies the Transport Session in ROUTE. The context of the Transport Session comes from signaling metadata. The value TSI = 0 SHALL only be used for service-specific signaling. 🌟
Transport Object Identifier (TOI): This 32-bit field SHALL identify the object within this session that the payload of the current packet belongs to. The mapping of the TOI field to the object is provided by the Extended File Delivery Table (FDT). 📚
2.2. LCT Header Extensions 🎀
ROUTE uses these LCT header extensions, ngl they're pretty cute:
EXT_FTI: as specified in RFC 5775. ✨
EXT_TOL: the length in bytes of the multicast transport object SHALL be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331] with 24 bits or, if required, 48 bits of Transfer Length. The frequency of using the EXT_TOL header extension is determined by channel conditions that may cause the loss of the packet carrying the Close Object flag (B) [RFC5651]. 🌊
NOTE: The transport object length can also be determined without the use of EXT_TOL by examining the LCT packet with the Close Object flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport object length. 💀
EXT_TIME Header: as specified in RFC 5651 [RFC5651]. The Sender Current Time SHALL be signaled using EXT_TIME. ⏰
2.3. FEC Payload ID for Source Flows 🦄
The FEC Payload ID for the Compact No-Code FEC Scheme used in ROUTE Source Flows is a 32-bit unsigned integer. It SHALL express the start_offset as an octet number that matches the first octet of the fragment of the delivery object carried in this packet. The start_offset value for the first fragment of any delivery object SHALL be set to 0. Figure 3 shows the 32-bit start_offset field. 🍭
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: FEC Payload ID for Source Flows
2.4. FEC Payload ID for Repair Flows 🌷
FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330]. Just go read that one, bestie 📖
3. Session Metadata 📋
The required session metadata for Source and Repair Flows is specified in the following sections. The list here is not exhaustive, so a service MAY signal more metadata to meet its needs 🌈 The data format isn't specified beyond its cardinality. The exact format is left up to the service, e.g., by using XML encoding format, as has been done by [DVBMABR] and [ATSCA331]. The following sections say whether an attribute is mandatory (m), conditional mandatory (cm) or optional (o) to realize a basic ROUTE session. A mandatory field SHALL always be present in the session metadata, and a conditional mandatory field SHALL be present if the specified condition is true. Delivery of the session metadata to the ROUTE receiver is beyond the scope of this document 🦋
3.1. Generic Metadata 🧁
Generic metadata applies to both Source and Repair Flows. Before a receiver can join a ROUTE session, the receiver needs to get this generic metadata, which contains at least the following information:
ROUTE version number (m): the version number of ROUTE used in this session. The version number conforming to this document SHALL be 1. 💜
Connection ID (m): the unique identifier of a Connection, usually made up of the following 4-tuple: source IP address/source port number, destination IP address/destination port number. The IP addresses can be IPv4 or IPv6 addresses, depending on which IP version the deployment uses. 🌐
3.2. Session Metadata for Source Flows 🎀
Okay bestie, here are the source flow attributes, and they're each a little different 💅
stsi(m): The LCT TSI value corresponding to the Transport Session for the Source Flow ✨rt(o): This Boolean flag SHALL indicate whether the content component carried by this Source Flow is real-time streaming media or non-real-time content 📺. When it's set to"true", it SHALL be an indication of real-time content, and when it's absent or set to"false", it SHALL be an indication of non-real-time (NRT) content 🌸minBufferSize(o): This is a 32-bit unsigned integer that SHALL represent, in kilobytes, the minimum required storage size of the receiver transport buffer for the parent LCT channel of this Source Flow 🧺. The buffer holds the data belonging to a source object until its complete reception. This attribute is only applicable whenrt="true". A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received data beyond its buffering capability. Such discarding of data will impact the service quality 😬EFDT(cm): When present, it SHALL contain a single instance of an FDT-Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain the optional FDT extensions as defined in Section 4.1 🧚. The optionalEFDTelement MAY only be present for File Mode of delivery. In File Mode, it SHALL be present if this Source Flow transports streaming media segments 🎬contentType(o): A string that SHALL represent the media type for the media content 🎶. It SHALL obey the semantics of theContent-Typeheader as specified by the HTTP/1.1 protocol in RFC 7231 [RFC7231]. This document does not define any newcontentTypestrings. In its absence, the signaling of media type for the media content is beyond the scope of this document 🙈applicationMapping(m): A set of identifiers that provide an application-specific mapping of the received Application Objects to the Source Flows 🗺️. For example, for DASH, this would provide the mapping of a Source Flow to a specific DASH Representation from a Media Presentation Description (MPD), the latter identified by its Representation and corresponding Adaptation Set and Period IDs 💖
3.3. Session Metadata for Repair Flows 🔧
minBuffSize(o): A 32-bit unsigned integer whose value SHALL represent a required size of the receiver transport buffer for AL-FEC decoding processing. When present, this attribute SHALL indicate the minimum buffer size that is required to handle all associated objects that are assigned to a super-object, i.e., a delivery object formed by the concatenation of multiple FEC transport objects in order to bundle these FEC transport objects for AL-FEC protection 📦. A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received repair data beyond its buffering capability. Such discarding of data will impact the service quality 😭fecOTI(m): A parameter made by concatenating the Common and Scheme-Specific FEC Object Transmission Information (FEC OTI) as defined in Sections 3.3.2 and 3.3.3 of [RFC6330]. It corresponds to the delivery objects carried in the Source Flow that this Repair Flow is associated with, with one extra detail 🦋: the 40-bit Transfer Length (F) field may either represent the actual size of the object, or it is encoded as all zeroes. In the latter case, the FEC transport object size either is unknown or cannot be represented by this attribute. In other words, for the all-zeroes format, the delivery objects in the Source Flow correspond to streaming content. That's either a live Service whose content encoding hasn't happened yet when this session data gets generated, or pre-recorded streaming content whose delivery object sizes are variable. Those sizes may be known at generation time, but they can't be represented as a single value by thefecOTIattribute 🌈ptsi(m): TSI value(s) of each Source Flow protected by this Repair Flow 🫶mappingTOIx(o): Values of the constant X for use in deriving the TOI of the delivery object of each protected Source Flow from the TOI of the FEC (super-)object 🧮. The default value is"1". MultiplemappingTOIxvalues MAY be provided for each protected Source Flow, depending upon the usage of FEC (super-)object ✨mappingTOIy(o): The corresponding constant Y to eachmappingTOIx, when present, for use in deriving the parent SourceTOI value from the above equation 💜. The default value is"0".
4. Delivery Object Mode ✨
ROUTE gives you several different delivery object modes, and one of them might suit your app's needs better for a given Transport Session 👑. A delivery object is self contained for the application. It's usually tied to certain properties, metadata, and timing-related info that matter to the app 🍓. The delivery object mode gets signaled on an object basis, using Codepoint as specified in Section 2.1.
4.1. File Mode 📁
File Mode uses an out-of-band Extended FDT (EFDT) signaling for recovery of delivery objects, with the following extensions and considerations 💅.
4.1.1. Extensions to FDT
Okay so these extensions get added to FDT, which is specified in RFC 6726 [RFC6726]. An Extended FDT-Instance is an instance of FLUTE FDT, as specified in [RFC6726], plus optionally one or more of the following extensions 🎀:
efdtVersion: A value that SHALL represent the version of this Extended FDT-Instance 🔖maxExpiresDelta: Let "tp" represent the wall clock time at the receiver when the receiver acquires the first ROUTE packet carrying data of the object described by this Extended FDT-Instance ⏰.maxExpiresDelta, when present, SHALL represent a time interval that, when added to "tp", SHALL represent the expiration time of the associated Extended FDT-Instance "te". The time interval is expressed in number of seconds. WhenmaxExpiresDeltais not present, the expiration time of the Extended FDT-Instance SHALL be given by the sum of a) the value of the ERT field in theEXT_TIMELCT header extension in the first ROUTE packet carrying data of that file, and b) the current receiver time when parsing the packet header of that ROUTE packet. See Sections 5.4 and 6.3.3 on additional rules for deriving the Extended FDT-Instance expiration time. Hence,te = tp + maxExpiresDelta🧮maxTransportSize: An attribute that SHALL represent the maximum transport size in bytes of any delivery object described by this Extended FDT-Instance 📏. This attribute SHALL be present if a) thefileTemplateis present in the Extended FDT-Instance, or b) one or moreFileelements, if present in this Extended FDT-Instance, do not include theTransfer-Lengthattribute. WhenmaxTransportSizeis not present, the maximum transport size is not signaled, while other signaling such as theTransfer-Lengthattribute signals the exact Transfer Length of the object 🌸fileTemplate: A string value that, when present and used together with parameter substitution, helps derive theContent-Locationattribute for the delivery object described by this Extended FDT-Instance 🪄. It SHALL include the"$TOI$"identifier. Each identifier MAY be suffixed as needed by specific file names, within the enclosing$characters, following this prototype:%0[width]d
The width parameter is an unsigned integer that gives the minimum number of characters to be printed 🔢. If the value to be printed is shorter than this number, the result SHALL be padded with leading zeroes. The value is not truncated even if the result is larger. When no format tag is present, a default format tag with width=1 SHALL be used.
Strings other than identifiers SHALL only contain characters that are permitted within URIs according to RFC 3986 [RFC3986] 🔗. Also, $$ is an escape sequence in a fileTemplate value, i.e., "$$" is non-recursively replaced with a single "$" 🦄. The usage of fileTemplate is described in Sender and Receiver operations in Sections 5.4 and 6.3, respectively.
4.1.2. Constraints on Extended FDT ⛓️
The Extended FDT-Instance SHALL conform to an FDT-Instance according to RFC 6726 [RFC6726], with the following constraints: at least one File element and the @Expires attribute SHALL be present 📋.
Content encoding MAY be used for delivery of any file described by an FDT-Instance.File element in the Extended FDT-Instance 🗜️. The content encoding defined in the present document is gzip [RFC1952]. When content encoding is used, the File@Content-Encoding and File@Content-Length attributes SHALL be present in the Extended FDT-Instance ✨
4.2. Entity Mode 🧁
For Entity Mode, the following applies 💖:
- Delivery object metadata SHALL be expressed in the form of entity headers as defined in HTTP/1.1. These correspond to one or more of the representation header fields, payload header fields, and response header fields, as defined in Sections 3.1, 3.3, and 7, respectively, of [RFC7231] 📨
- The entity headers sent along with the delivery object provide all information about that multicast transport object 🫶
- Sending a media object (if the object is chunked) in Entity Mode may result in one of the following options 🎞️:
Option 1: known length. If the length of the chunked object is known at the sender, the ROUTE Entity Mode delivery object MAY be sent without using HTTP/1.1 chunked transfer coding. In that case, the object starts with an HTTP header containing the Content Length field, followed by the concatenation of CMAF Chunks:
|HTTP Header+Length||---chunk ----||---chunk ----||---chunk --
--||---chunk ----|Option 2: unknown length. If the length of the chunked object is unknown at the sender when it starts sending the object, HTTP/1.1 chunked transfer coding format SHALL be used 🧩:
|HTTP Header||Separator+Length||---chunk ----
||Separator+Length||---chunk ----||Separator+Length||---chunk
----||Separator+Length||---chunk ----||Separator+Length=0|Note, however, that it is not required to send a CMAF Chunk in exactly one HTTP chunk 🙌
4.3. Unsigned Package Mode 🎁
In this delivery mode, the delivery object is a group of files that are packaged for delivery only 📦. If applied, the client is expected to unpack the package and provide each file as an independent object to the application. Packaging is supported by Multipart Multipurpose Internet Mail Extensions (MIME) [RFC2557], where objects are packaged into one document for transport, with Content-Type set to multipart/related. When binary files are included in the package, Content-Transfer-Encoding of "binary" should be used for those files 🌷.
4.4. Signed Package Mode 🔐
In Signed Package Mode delivery, the delivery object is a group of files that are packaged for delivery, and the package includes one or more signatures for validation 🖋️. Signed packaging is supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects are packaged into one document for transport, and the package includes the objects necessary for validation of the package 💜.
5. Sender Operation 🚀
5.1. Usage of ALC and LCT for Source Flow ✨
Okay bestie, so the ROUTE Source Flow carries the source data the way RFC 5775 [RFC5775] lays out 📦. ROUTE also brings some special twists to how it uses the LCT building block, so let's go through them 🦋
- ROUTE limits the LCT building block to a single channel per session 🎀. That means congestion control is sender driven in ROUTE 💅. There's no specific congestion-control signaling going from the sender to the receiver, so the CCI field is either set to 0 or used for other stuff, as explained in Section 2.1. The app can still offer receiver-driven layered multicast though, since the receiver application can pick the right delivery session based on how much bandwidth that session needs 🌈
Here are a few more details for LCT 🧚
The Layered Coding Transport (LCT) Building Block from RFC 5651 [RFC5651] gets used with these constraints:
- The TSI in the LCT header SHALL be set equal to the value of the
stsiattribute in Section 3.2 🌸 - The Codepoint (CP) in the LCT header SHALL be used to signal the applied formatting, as defined in the signaling metadata 🍓
- Following ALC, a source FEC Payload ID header identifies, for FEC purposes, the encoding symbols of the delivery object (or a portion of it) carried by the matching ROUTE packet 🔥. There are a few ways this info can get sent:
- As a simple new null FEC scheme, with this usage:
- The value of the source FEC Payload ID header SHALL be set to
0if the ROUTE packet contains the entire delivery object 💀, or - The value of the source FEC Payload ID header SHALL be set as a direct address (start offset) pointing to the starting byte position of the portion of the object carried in this packet, using a 32-bit field ✨
- The value of the source FEC Payload ID header SHALL be set to
- In a compatible manner to RFC 6330 [RFC6330], where the SBN and ESI define the start offset together with the symbol size T 👑
- The signaling metadata gives the right parameters to indicate any of the above modes, using the
srcFecPayloadIdattribute 🫶
- As a simple new null FEC scheme, with this usage:
Next up, the LCT Header EXT_TIME extension from RFC 5651 [RFC5651] MAY be used by the sender like this 🕰️
- The Sender Current Time (SCT) MAY be used, depending on the app, to signal the sender's current time occasionally or frequently, possibly for receiver time synchronization ⏰
- The Expected Residual Time (ERT) MAY be used to indicate the expected remaining time for transmitting the current object, so detecting a lost delivery object can be optimized 🔍
- The Sender Last Changed (SLC) flag is typically not utilized 🙈 but MAY be used to indicate the addition or removal of Segments 💜
Also, additional extension headers MAY be used to support real-time delivery 😭. Those extension headers are defined in Section 2.1 💖.
5.2. ROUTE Packetization for Source Flow 🎀
So this part is about how the ROUTE sender maps the Application Object into ROUTE packet payloads 📮. It's basically an extension of RFC 5445 [RFC5445], and it inherits the context, language, declarations, and restrictions of the FEC building block in RFC 5052 [RFC5052] 🧠.
The data in the payload of any given ROUTE packet is a contiguous portion of the Application Object 🧩. ROUTE source delivery can be seen as a special case of the Compact No-Code Scheme tied to FEC Encoding ID = 0, following Sections 3.4.1 and 3.4.2 of [RFC5445], where the encoding symbol size is exactly one byte 🦄. As Section 2.1 says, for ROUTE Source Flows, the FEC Payload ID SHALL deliver the 32-bit start_offset 💅. All receivers are expected to support, at minimum, operation with this special case of the Compact No-Code FEC 🫶.
Heads up: if the source object size is greater than 2^32 bytes (roughly 4.3 GB) 🙈, the applications (in the broadcaster server and the receiver) are expected to do segmentation and reassembly using methods that are outside the scope of this document 📚.
Last thing, in some special cases a ROUTE sender MAY need to produce ROUTE packets with no payload at all 🌙. For example, this might be needed to signal the end of a session 🏁. These dataless packets don't have a FEC Payload ID or payload data, just the LCT header fields 🍃. The total datagram length, which the outer protocol headers (like the IP or UDP header) carry, lets receivers tell that the LCT header, FEC Payload ID, and payload data are missing 🔎.
5.2.1. Basic ROUTE Packetization 🍓
In basic operation, the Application Object is assumed to be fully available at the ROUTE sender 💖.
- The amount of data sent in one ROUTE packet is limited by the maximum transfer unit of the data packets, or by the size of the remaining data of the Application Object being sent, whichever is smaller 📏. The transfer unit is determined either by knowing the underlying transport block sizes or by other constraints 🧃.
- The start_offset field in the LCT header of the ROUTE packet shows the byte offset of the carried data in the Application Object being sent 📍.
- The Close Object flag (B) is set to 1 if this is the last ROUTE packet carrying data of the Application Object 🏳️🌈.
Packet delivery order is arbitrary 🎲, but unless other constraints apply, delivery with increasing start_offset value is recommended 🌸.
5.2.2. ROUTE Packetization for CMAF Chunked Content 🎞️
For ROUTE packetization of CMAF Chunked Content, these extra guidelines should be followed on top of the ones in Section 5.2.1 🎀.
- If it's the first ROUTE packet carrying a CMAF Random Access chunk (except for the first CMAF Chunk in the segment), the Codepoint value MAY be set to 10, as specified in the Codepoint value table in Section 2.1 🦋. The receiver MAY use this info to optimize random access ⚡.
- As soon as the total length of the media object is known (possibly when the last CMAF Chunk of a segment gets packaged), the EXT_TOL extension header MAY be added to the LCT header to signal the Transfer Length 📏. That way the receiver can know this in a timely fashion ⏱️.
5.3. Timing of Packet Emission ⏱️
The sender SHALL use the timing info the application provides to time packet emission for timely reception 🎯. That info might live inside the Application Objects (like DASH segments) and/or the presentation manifest 📜. So packets of streaming media with real-time constraints SHALL be sent in a way that lets them arrive on time, relative to the presentation timeline 🎬✨.
5.4. Extended FDT Encoding for File Mode Sending 📂
For File Mode sending:
- The TOI field in the ROUTE packet header SHALL be set so that the Content-Location can be derived at the receiver using the File Template substitution in Section 6.3.1 🗂️.
- After sending the first packet with a given TOI value, none of the packets for that TOI SHALL be sent later than the wall clock time derived from
maxExpiresDelta⏳. The EXT_TIME header with Expected Residual Time (ERT) MAY be used to convey a more accurate expiry time 💜.
5.5. FEC Framework Considerations 🧩
The FEC framework borrows concepts from the FECFRAME work defined in RFC 6363 [RFC6363], plus the FEC building block in RFC 5052 [RFC5052], which is already adopted in the existing FLUTE/ALC/LCT specs 💅.
The FEC design sticks to these principles:
- FEC-related information is provided only where it's needed 🎯.
- Receivers that aren't capable of this framework can ignore repair packets 🙈.
- The FEC is symbol based, with a fixed symbol size per protected Source Flow 🔢. The ALC protocol and existing FEC schemes get reused 🔁.
- A FEC Repair Flow provides protection of delivery objects from one or more Source Flows 🛡️.
The FEC-specific components of the framework are:
- FEC Repair Flow declaration, including all FEC-specific information 📝.
- A FEC transport object, which is the concatenation of a delivery object, padding octets, and size information, forming a chunk of data with a size in symbols of N, where N >= 1 🧁.
- A FEC super-object, which is the concatenation of one or more FEC transport objects, bundling them up for FEC protection 🎁.
- A FEC protocol and packet structure 🦢.
And the big takeaway: a receiver needs to be able to recover delivery objects from repair packets based on the available FEC information 🫶🌈.
5.6. FEC Transport Object Construction 💖
okay so to point at a delivery object in the repair protocol, you need these bits of info 🎀:
- The TSI and TOI of the delivery object. In this case, the FEC object is the entire delivery object.
- An octet range: a start offset inside the delivery object, plus how many contiguous octets after that make up the FEC object (the FEC-protected part of the source object). In this case the FEC object is a contiguous byte range of the delivery object.
Typically, for real-time delivery with smaller delivery object sizes, the first mapping is used, so the delivery object is the FEC object 🦋
Assuming the FEC object is the delivery object, each delivery object gets an associated FEC transport object made of the delivery object, padding octets (P), and the FEC object size (F) in octets. F lives in a 4-octet field, bestie 🧚
The FEC transport object size S, in FEC encoding symbols, SHALL be an integer multiple of the symbol size Y. S gets figured out from the session information and/or the repair packet headers ✨
Here's the breakdown of the math, so everything is clear:
Fis the size of the delivery object in octets.F'is theFoctets of data in the delivery object.f'is the four octets carrying the value ofFin network octet order (high-order octet first).Sis the size of the FEC transport object, withS=ceil((F+4)/Y), where theceil()function rounds the result up to the nearest integer.P'isS*Y-4-Foctets of data. This is the padding that sits between the delivery object and the 4-byte field holdingF, at the very end of the FEC transport object.O'is the concatenation ofF',P', andf'.
So O' becomes the FEC transport object, which is S*Y octets long 🌸
Heads up: the padding octets and the object size F are NOT sent in the source packets of the delivery object. They only exist inside the FEC transport object, which FEC decoding recovers so it can pull out the FEC object (and therefore the delivery object, or the part of it that makes up the FEC object). With all that in mind, the FEC transport object size in symbols is S 😭
The general info a FEC-enabled receiver gets about a FEC transport object is the source TSI, the source TOI, and the octet range within the delivery object that makes up the FEC object. Since the FEC object's size in octets rides along in that appended field inside the FEC transport object, the rest can be conveyed as:
- The TSI and TOI of the delivery object that the FEC object (for this FEC transport object) was generated from
- The start octet within the delivery object for that FEC object
- The size in symbols of the FEC transport object,
S
5.7. Super-Object Construction 🧁
From the FEC Repair Flow declaration, you can work out how a FEC super-object gets built, as the concatenation of one or more FEC transport objects. The FEC super-object carries the general info about its FEC transport objects (like we covered in the earlier sections), plus the placement order of those FEC transport objects inside the super-object 💅
Here's the setup:
Nis the total number of FEC transport objects that go into the FEC super-object.- For
i = 0, ..., N-1,S[i]is the size in symbols of FEC transport objecti. B'is the FEC super-object, which is the concatenation of the FEC transport objects in numerical order. It's made ofK = Sum of Nsource symbols, with each symbol written asS[i].
For each FEC super-object, the remaining general info a FEC-enabled receiver needs (beyond what's already in the FEC transport objects that make up the super-object) is:
- The total number of FEC transport objects,
N. - For each FEC transport object:
- The TSI and TOI of the delivery object that the FEC object for this FEC transport object was generated from,
- The start octet within the delivery object for that FEC object, and
- The size in symbols of the FEC transport object.
How the FEC repair info actually gets carried is covered below 🦋
5.8. Repair Packet Considerations 🎀
The repair protocol is built on Asynchronous Layered Coding (ALC) as defined in RFC 5775 [RFC5775], and on the Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC5651], with these extra details:
- The Layered Coding Transport (LCT) Building Block from RFC 5651 [RFC5651] is used the way Asynchronous Layered Coding (ALC), Section 2.1, defines it. On top of that, this constraint applies:
- The TSI in the LCT header SHALL identify the Repair Flow that this packet applies to, by matching the value of the
ptsiattribute in the signaling metadata among the LCT channels that carry Repair Flows. 🌈
- The TSI in the LCT header SHALL identify the Repair Flow that this packet applies to, by matching the value of the
- The FEC building block is used according to RFC 6330 [RFC6330], but only repair packets get delivered.
- Each repair packet inside the scope of the Repair Flow (as indicated by the TSI field in the LCT header) SHALL carry the repair symbols for a matching FEC transport object/super-object, identified by its TOI. The repair object/super-object TOI SHALL be unique for each FEC super-object created within the scope of that TSI. 👑
5.9. Summary FEC Information 🌸
For each super-object that gets generated (identified by a unique TOI, within a Repair Flow, which is in turn identified by the TSI in the LCT header), the receiver needs to be told the following:
- The FEC configuration, which is made of:
- For each FEC transport object:
- The TSI and TOI of the delivery object used to generate the FEC object for this FEC transport object,
- The start octet within the delivery object of the associated FEC object, if applicable, and
- The size in symbols of the FEC transport object,
S.
All of that info gets delivered in two ways 🧚
- Statically, in the session metadata defined in Section 3.3, and
- Dynamically, in an LCT extension header.
6. Receiver Operation 👑
The receiver gets packets and filters them according to the following. For the ROUTE session and each LCT channel inside it, the receiver regenerates the delivery objects from that session and channel 🦋
Heads up, bestie! If the receiver gets data that doesn't follow the ROUTE protocol in this document, it SHOULD try to recover gracefully, e.g., by telling the application about the issue through means outside the scope of this document 😭
The ROUTE packetization in Section 5.2.1 means the receiver SHALL NOT receive overlapping data. If that situation shows up at the receiver, the packet SHALL be assumed to be corrupted 💀
The basic receiver operation is described below. It assumes an error-free scenario, and repair considerations are covered in Section 7 🫶
6.1. Basic Application Object Recovery for Source Flows ✨
okay so every time a ROUTE packet of a Source Flow shows up, the receiver runs through these steps in this exact order 💅
- The ROUTE receiver is expected to parse the LCT and FEC Payload ID to check that it's a valid header. If it's not valid, the payload gets tossed without any further processing 🗑️
- Every ROUTE packet used to recover a specific delivery object carries the same TOI value in the LCT header. bestie, that's the glue that keeps them together 🫶
- The ROUTE receiver is expected to confirm that the TSI and the Codepoint are valid operation points in the signaling metadata. That means the signaling needs a matching entry for the TSI value in the packet header, plus an entry for this TSI, and the Codepoint field in the LCT header has to have a valid Codepoint mapping. No mystery packets allowed 🕵️♀️
- The ROUTE receiver should process the rest of the payload, including how it reads the other payload header fields. It uses the source FEC Payload ID (to figure out the start_offset) and the payload data to rebuild the matching object, like this 🧩
- a. For File Mode, when the first ROUTE packet payload for an object shows up, the ROUTE receiver checks the File@Transfer-Length attribute of the associated Extended FDT-Instance (if it's there) to find the object's length T. If File@Transfer-Length isn't in the Extended FDT-Instance, the receiver uses the maxTransportSize attribute of that Extended FDT-Instance to find the object's maximum length T'. Alternatively, and specifically for delivery modes other than File Mode, the EXT_TOL header can be used to find the length T of the object 📏
- b. The ROUTE receiver allocates buffer space for the T or T' bytes the object will or may take up 🛏️
- c. The ROUTE receiver works out the payload length, Y, by subtracting the payload header length from the total length of the received payload 🧮
- d. The ROUTE receiver sets up a Boolean array RECEIVED[0..T-1] or RECEIVED[0..T'-1], depending on what applies, with every entry starting as false so it can track which object symbols have arrived. It keeps grabbing packet payloads for the object for as long as all of these are true:
- i. there's at least one entry in RECEIVED still set to false,
- ii. the object hasn't expired yet, and
- iii. the application hasn't given up on receiving this object.
More details are provided below. 👀
- e. For each received ROUTE packet payload for the object (the first payload included), these are the steps to help recover the object:
- i. If the packet includes an EXT_TOL or EXT_FTI header, it changes the Boolean array RECEIVED[0..T'-1] into RECEIVED[0..T-1]. 🔄
- ii. Let X be the value of the start_offset field in the ROUTE packet header, and let Y be the length of the payload, Y, which is figured out by subtracting the LCT header size and the FEC Payload ID size from the total length of the received packet. 🧠
- iii. The ROUTE receiver copies the data into the right spot in the space reserved for the object and sets RECEIVED[X ... X+Y-1] = true. 📥
- iv. If all T entries of RECEIVED are true, the receiver has recovered the entire object. 🎉
Once the receiver has the complete set of packet payloads for the delivery object tied to a given TOI value and the metadata for that delivery object, the delivery object is fully received and becomes an Application Object. Main character moment 👑
Now, if the ROUTE packets for an Application Object arrive on time, the receiver SHALL make the Application Objects available to the application in a timely fashion, using the timing data the application provides (for example, the timing data signaled through the presentation manifest file). For example, HTTP/1.1 chunked transfer may need to be enabled to pass the Application Objects along if MPD@availabilityTimeOffset is signaled in the DASH presentation manifest, so segment data can reach the application on time 🚀
6.2. Fast Stream Acquisition ⚡
So when the receiver first starts getting ROUTE packets, it's pretty likely that it didn't catch the very first packet carrying the data of a multicast transport object. Normally, a partially received object like that just gets thrown out. BUT, the channel acquisition or "tune-in" times can get way better if the app can actually use that partial object. Here's one example of how that could work 🦋
- The receiver checks for the first received packet with the Codepoint value set to 10, which signals the start of a CMAF Random Access chunk. 🔍
- The receiver MAY make the partially received object (a partial DASH segment starting from the packet above) available to the application for fast stream acquisition. 💨
- It MAY recover the earliest presentation time of this CMAF Random Access chunk from the ROUTE packet LCT Congestion Control Information (CCI) field, as specified in Section 2.1. Then it can add a new Period element to the MPD exposed to the application, containing just the partially received DASH segment with period continuity signaling. It's giving seamless 🌸
6.3. Generating Extended FDT-Instance for File Mode 🧁
An Extended FDT-Instance that conforms to RFC 6726 [RFC6726] gets produced at the receiver, using the service metadata and in-band signaling, in the following steps:
6.3.1. File Template Substitution for Content-Location Derivation 🔤
The Content-Location element of the Extended FDT for a specific Application Object is derived like this:
"$TOI$" is replaced with the unique TOI value in the LCT header of the ROUTE packets used to recover the given delivery object (as specified in Section 6.1).
After that substitution, the fileTemplate SHALL be a valid URL that matches the Content-Location attribute of the associated Application Object. ✅
An example @fileTemplate using a width of 5 looks like this: fileTemplate="myVideo$TOI%05d$.mps". That gives you file names with exactly five digits in the number portion. So the Media Segment file name for TOI=33 with this template is myVideo00033.mps. Cute, right? 🥰
6.3.2. File@Transfer-Length Derivation 📐
Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL header, when it's present, is used to derive the Transport Object Length (TOL) of the File. If the File@Transfer-Length parameter isn't in the Extended FDT-Instance, then the EXT_TOL header or the EXT_FTI header SHALL be present. ⚠️
Heads up: a header carrying the transport object length (EXT_TOL or EXT_FTI) doesn't need to be in every packet header. If the broadcaster doesn't know the length of the transport object at the beginning of the transfer, an EXT_TOL or EXT_FTI header SHALL be included in at least the last packet of the file, and should be included in the last few packets of the transfer 📦
6.3.3. FDT-Instance@Expires Derivation ⏰
When it's present, the maxExpiresDelta attribute SHALL be used to generate the value of the FDT-Instance@Expires attribute. The receiver is expected to add this value to its wall clock time when it acquires the first ROUTE packet carrying the data of a given delivery object, which gives the value for @Expires. 🕰️
When maxExpiresDelta isn't present, the EXT_TIME header with Expected Residual Time (ERT) SHALL be used to derive the expiry time of the Extended FDT-Instance. When both maxExpiresDelta and the ERT of EXT_TIME are present, the smaller of the two values should be used as the incremental time interval added to the receiver's current time to generate the effective value for @Expires. When neither maxExpiresDelta nor the ERT field of the EXT_TIME header is present, the expiration time of the Extended FDT-Instance is given by its @Expires attribute. Timers, but make it make sense 💅
7. FEC Application 🛡️
7.1. General FEC Application Guidelines 🧠
It's up to the receiver to decide whether to use zero, one, or more of the FEC streams. So the application assigns a recovery property to each flow, which defines things like the delay and the required memory if one or the other gets chosen. The receiver MAY decide whether or not to use Repair Flows, based on these considerations:
- The desired start-up and end-to-end latency. If a Repair Flow needs a lot of buffering time to be effective, it might only be used in time-shift operations or in poor reception conditions, since using it trades end-to-end latency off against DASH Media Presentation quality. ⏳
- FEC capabilities, i.e., the receiver MAY pick only the FEC algorithm that it supports. 🧰
- Which Source Flows are being protected. For example, if the Repair Flow protects Source Flows that the receiver didn't select, then the receiver may not select that Repair Flow. 🙅♀️
- Other considerations, like available buffer size, reception conditions, etc. 📶
If a receiver decides to acquire a certain Repair Flow, then the receiver must receive data on all Source Flows that are protected by that Repair Flow in order to collect the relevant packets. No skipping the homework 📚
7.2. TOI Mapping 🗺️
When mappingTOIx/mappingTOIy are used to signal X and Y values, the TOI value(s) of the one or more source objects (sourceTOI) protected by a given FEC transport object or FEC super-object with a TOI value rTOI is derived through the equation sourceTOI = X*rTOI + Y. Math bestie 🧮
When neither mappingTOIx nor mappingTOIy is present, there's a 1:1 relationship between each delivery object carried in the Source Flow (identified by ptsi) and a FEC object carried in this Repair Flow. In this case, the TOI of each of those delivery objects SHALL be identical to the TOI of the corresponding FEC object. Perfect match, no cap 💜
7.3. Delivery Object Reception Timeout ⏱️
Here are the permitted start and end times for the receiver to do the file repair procedure, in case a broadcast file didn't come through successfully, plus the rules and parameters that go with them:
- The latest time that the file repair procedure may start is bound by the @Expires attribute of the FDT-Instance. Deadline, bestie 💀
- The receiver may choose to start the file repair procedure earlier if it notices any of these events:
That's the whole vibe for this part, and it's giving ✨ full protocol glow-up ✨ 🌈
7.4. Example FEC Operation ✨
bestie, this is the moment where it all clicks 🧚💖. To recover the delivery objects that a Repair Flow protects, a receiver first needs the Service signaling metadata fragments that describe the matching collection of delivery objects covered by that Repair Flow. A Repair Flow is identified by the combo of an LCT channel, a unique TSI number, and the Source Flows it protects. Main character energy 👑
If a receiver gets data from a Repair Flow, it's expected to collect every packet from all the protected Transport Sessions. Each time a packet arrives, whether it's a source or a repair packet, the receiver runs through these steps in the order listed 💅
- The receiver is expected to parse the packet header and check that it's a valid header. If it isn't, the packet SHALL be discarded without further processing 🗑️
- The receiver is expected to parse the TSI field of the packet header and check that a matching value exists in the Service signaling for the Repair Flow or the associated Protected Source Flow. If no match is found, the packet SHALL be discarded without further processing 🙅♀️
- The receiver processes the rest of the packet, including the other header fields. Using the source FEC Payload ID (to work out the
start_offsetbyte position within the source object), the Repair FEC Payload ID, and the payload data, it rebuilds the decoding blocks that belong to a FEC super-object, like this 🧩 a. For a source packet, the receiver figures out which delivery object the packet belongs to, using the session information and the TOI carried in the payload header. For a repair packet, it does the same thing to find the FEC super-object the packet belongs to 🔍 b. For source packets, the receiver collects the data for each FEC super-object and recovers FEC super-objects the same way it would for a Source Flow in Section 6.1. The received FEC super-object is then mapped to a source block, and the matching encoding symbols get generated 🌸 c. Once the repair packets come in, the FEC super-object can be recovered 🦋 d. Once the FEC super-object is recovered, the individual delivery objects can be pulled out 🎀
8. Considerations for Defining ROUTE Profiles 🌈
okay so services like ATSC-ROUTE [ATSCA331] and DVB-MABR [DVBMABR] can define their own ROUTE "profiles" based on this document, through their own standards organizations 🏛️. DVB did exactly this with a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR], which is the example mentioned in the overview section. Here are the considerations for doing it. Services MAY:
- Restrict the signaling of certain values signaled in the LCT header and/or provision unused fields in the LCT header.
- Restrict using certain LCT header extensions and/or add new LCT header extensions.
- Restrict or limit usage of some Codepoints and/or assign semantics to service-specific Codepoints marked as reserved in this document.
- Restrict usage of certain Service signaling attributes and/or add their own service metadata.
Services SHALL NOT redefine the semantics of any of the ROUTE attributes in LCT headers and extensions, or any of the Service signaling attributes already specified in this document. That's the big rule, bestie 🚫
If services follow these guidelines, their profiles can stay interoperable 🫶
9. ROUTE Concepts 🦋
9.1. ROUTE Modes of Delivery 💜
The different ROUTE delivery modes from Section 4 are each tuned for different kinds of media data 🎬. File Mode, for example, is specifically optimized for delivering DASH content that uses Segment Template with number substitution. Using File Template in EFDT means you don't have to keep resending metadata, which the next section explains 🙌. The same optimizations can't be used for time substitution and segment timelines, though, because the addressing of each segment depends on time and usually doesn't follow a fixed or repeated pattern 😵💫. For that case, Entity Mode is the better fit, since it carries the file location in band. Entity Mode can also deliver a whole file or part of one by using HTTP Partial Content response headers ✨
9.2. File Mode Optimizations 📦
In File Mode, the delivery object represents an Application Object. This mode copies FLUTE as defined in RFC 6726 [RFC6726], but it adds the ability to send static, pre-known file metadata out of band 🚀
In FLUTE, FDT-Instances are delivered in band, and they need to be generated and sent in real time when objects are generated in real time at the sender 😩. These FDT-Instances differ a bit from the FDT in Section 3.4.2 of [RFC6726] and Section 7.2.10 of MBMS [MBMS]. The big difference is that, besides sending file metadata separately from the delivery object it describes, ROUTE's FDT can be extended with more file metadata and rules. Those rules let the receiver generate the Content-Location attribute of the File element of the FDT on the fly 🪄. It works by using information from both the FDT extensions and the LCT header. Pre-delivering static file metadata and letting the receiver self-generate dynamic file metadata means the FDT-Instances don't have to be sent over and over for real-time objects. This modified FDT functionality in ROUTE is called the Extended FDT 💅
9.3. In-Band Signaling of Object Transfer Length ⏱️
As an extension to FLUTE, ROUTE lets you use the EXT_TOL LCT header extension with 24 bits or, if needed, 48 bits to signal the Transfer Length right inside the ROUTE packet 📮
The transport object length can also be figured out without EXT_TOL, by looking at the LCT packet with the Close Object flag (B). But if that packet gets lost, the EXT_TOL information can help the receiver work out the transport object length 🛟
Applications that use ROUTE for low-latency streaming can use this feature for sender-end latency optimizations 🏎️. The sender doesn't have to wait for an entire Application Object to be packaged so it can find its Transfer Length for the FDT before sending can start. Instead, partially encoded data can start going out through the ROUTE sender right away. As encoding of the Application Object nears completion and its length becomes known (for example, when the last CMAF Chunk of a DASH segment is written), the sender can then signal the object length using the EXT TOL LCT header. For instance, with a 2-second DASH segment made of 100-millisecond chunks, this can save up to 1.9 second of latency at the sending end ⚡
9.4. Repair Protocol Concepts 🛡️
The ROUTE repair protocol is FEC-based. It's an extra layer that sits between the transport layer (for example, UDP) and the object delivery layer protocol 🍰. The FEC reuses concepts from the FEC Framework defined in RFC 6363 [RFC6363]. The difference is that, unlike the FEC Framework in RFC 6363 [RFC6363], the ROUTE repair protocol doesn't protect packets. It protects delivery objects as they're delivered in the source protocol 📚. As an extension to FLUTE, it also supports protecting multiple objects in one source block, which lines up with the FEC Framework defined in RFC 6363 [RFC6363]. Each FEC source block can consist of parts of a delivery object, a single delivery object (like FLUTE), or multiple delivery objects that are bundled before FEC protection 🧺. ROUTE FEC uses FEC schemes in a similar way to those defined in RFC 5052 [RFC5052], and it uses that document's terminology. The FEC scheme defines the FEC encoding and decoding, plus the protocol fields and procedures used to identify packet payload data in the context of the FEC scheme 🔐
In ROUTE, every packet is an LCT packet as defined in RFC 5651 [RFC5651]. Source and repair packets can be told apart by:
- Different ROUTE sessions, i.e., they are carried on different UDP/IP port combinations.
- Different LCT channels, i.e., they use different TSI values in the LCT header.
- The most significant PSI bit in the LCT, if carried in the same LCT channel. This mode of operation is mostly suitable for FLUTE-compatible deployments 💖
10. Interoperability Chart 🎀
okay so earlier sections kept hinting at this, bestie 💅. ATSC-ROUTE [ATSCA331] and DVB-MABR [DVBMABR] are services that use this document, and they lowkey constrain some features while adding new ones of their own ✨. Here's an informative side-by-side of how ROUTE (as defined here) lines up with both of them 🦋.
+===============+===================+==================+============+
| Element | ATSC-ROUTE | This Document | DVB-MABR |
+===============+===================+==================+============+
| LCT header | PSI LSB set to 0 | Not defined | Set to 1 |
| field | for Source Flow | | for Source |
| | | | Flow for |
| | | | CMAF |
| | | | Random |
| | | | Access |
| | | | chunk |
| +-------------------+------------------+------------+
| | CCI may be set to | CCI may be set to EPT for |
| | 0 | Source Flow |
+---------------+-------------------+------------------+------------+
| LCT header | EXT_ROUTE_ | Not defined; | Shall not |
| extensions | PRESENTATION_TIME | may be added by | be used. |
| | Header used for | a profile. | |
| | Media Delivery | | |
| | Event (MDE) mode | | |
| +-------------------+------------------+------------+
| | EXT_TIME Header | EXT_TIME Header may be used |
| | linked to MDE | regardless (for FDT- |
| | mode in Annex | Instance@Expires |
| | A.3.7.2 | calculation) |
| | [ATSCA331] | |
+---------------+-------------------+------------------+------------+
| Codepoints | Full set | Does not | Restricted |
| | | specify range | to 5 - 9 |
| | | 11 - 255 | |
| | | (leaves to | |
| | | profiles) | |
+---------------+-------------------+------------------+------------+
| Session | Full set | Only defines a | Reuses |
| metadata | | small subset of | A/331 |
| | | data necessary | metadata, |
| | | for setting up | duplicated |
| | | Source and | from its |
| | | Repair Flows. | own |
| | | Does not define | Service |
| | | format or | signaling. |
| | | encoding of | |
| | | data except if | |
| | | data is | |
| | | integral/ | |
| | | alphanumerical. | |
| | | Leaves rest to | |
| | | profiles. | |
+---------------+-------------------+------------------+------------+
| Extended FDT | Instance shall | Not restricted, | Instance |
| | not be sent with | may be | shall not |
| | Source Flow | restricted by a | be sent |
| | | profile. | with |
| | | | Source |
| | | | Flow |
| +-------------------+------------------+------------+
| | No restriction | Only allowed in File Mode |
+---------------+-------------------+------------------+------------+
| Delivery | File, Entity, Signed/unsigned | Signed/ |
| Object Mode | package | unsigned |
| | | package |
| | | not |
| | | allowed |
+---------------+-------------------+------------------+------------+
| Sender | Defined for DASH | Defined for DASH segment and |
| operation: | segment | CMAF Chunks |
| Packetization | | |
+---------------+-------------------+-------------------------------+
| Receiver | Object handed to | Object may be handed before |
| object | application upon | completion if |
| recovery | complete | MPD@availabilityTimeOffset |
| | reception | signaled |
| +-------------------+-------------------------------+
| | - | Fast Stream acquisition |
| | | guidelines provided |
+---------------+-------------------+-------------------------------+Table 3: Interoperability Chart
11. Security and Privacy Considerations 🔐
11.1. Security Considerations 🛡️
okay, security time, and this part is SERIOUS bestie 😭. As noted in Section 9, ROUTE is aligned with FLUTE as specified in RFC 6726 [RFC6726] and only diverges in certain signaling optimizations, especially for the real-time object delivery case 🔥. So most of the security considerations in RFC 6726 [RFC6726] for the data flow itself, the session metadata (session control parameters in RFC 6726 [RFC6726]), and the associated building blocks apply directly to ROUTE, plus some extra ones I'm about to spill ✨.
Both encryption and integrity protection, applied at either the file or packet level, are a total must-have vibe 💜. The file corruption considerations of RFC 6726 [RFC6726] recommend this, and ROUTE SHOULD use it. On top of that, RFC 3740 [RFC3740] documents the multicast security architecture in great detail with clear security recommendations that SHOULD be followed 🧚.
When ROUTE is carried over UDP and a reverse channel from receiver to sender is available, the security mechanisms in RFC 9147 [RFC9147] SHOULD be applied 🌸.
Now, attacks against the session description. This document doesn't specify the semantics or delivery mechanism for session metadata, but the same threats still apply to any service using ROUTE 😬. So a service using ROUTE SHOULD take these threats into consideration and address them appropriately, following the guidelines in RFC 6726 [RFC6726]. In addition to those RFC 6726 [RFC6726] recommendations, for Internet-connected devices, services SHOULD enable clients to access the session description information using HTTPS with customary authentication/authorization, instead of sending this data via multicast/broadcast. Why? Because a ton of security work has already been done in this unicast domain, which can enable highly secure access to session description data 💖. Accessing via unicast does bring different privacy considerations, which are covered in Section 11.2 🙈. Also note that the multicast/broadcast stream is generally delayed compared to the unicast stream, so the session description protocol SHOULD be time synchronized with the broadcast stream, especially if the session description contains security-related information ⏰.
Next up, FDT. There's one key difference for File Mode when using File Template in EFDT 👑. It avoids repeatedly sending FDT-Instances, so the corresponding threats noted in RFC 6726 [RFC6726] do not apply directly to ROUTE in this case. The threat doesn't disappear though, it just shifts to the ALC/LCT headers, since those carry the extra signaling that lets you determine Content-Location and File@Transfer-Length in this case. So integrity protection recommendations for the ALC/LCT header SHOULD be considered with higher emphasis for ROUTE here 🧐.
Finally, attacks against the congestion control building block can impact the optional fast stream acquisition specified in Section 6.2 🚨. Receivers SHOULD have robustness against suspicious timestamp values, e.g., by comparing the signaled time in the LCT headers with the approximate time signaled by the MPD, and SHOULD discard outlying values. Receivers MUST adhere to the expiry timelines specified in Section 6 ⏳. Integrity protection mechanisms documented in RFC 6726 [RFC6726] SHOULD be used to address this threat 🫶.
11.2. Privacy Considerations 🦋
Encryption mechanisms recommended for security in Section 11.1 SHOULD also be applied to enable privacy and protection from snooping attacks 🙈.
This protocol is mainly aimed at IP multicast/broadcast environments, where the end user is mostly just listening 🎧. That means identity protection and user data retention are more protected than in the unicast case. Still, best practices for enabling privacy on IP multicast/broadcast SHOULD be applied by operators, e.g., "Recommendations for DNS Privacy Service Operators" in RFC 8932 [RFC8932] 🌈.
However, if clients access session description information via HTTPS, the same privacy considerations and solutions SHALL apply to that access as for regular HTTPS communication 🔒. That's a very well-studied area, and its concepts are being built directly into newer transport protocols like IETF QUIC [RFC9000], which enables HTTP/3 [HTTP3]. So newer protocols SHOULD be used to foster privacy ✨.
One more thing: streaming services MAY contain content that can only be accessed via DRM (digital rights management) systems 🎬. DRM systems can prevent unauthorized access to content delivered via ROUTE 🔐.
12. IANA Considerations 📋
This document has no IANA actions 🌸.
13. References 📚
13.1. Normative References 📚
Okay bestie, these are the normative references, the ones you literally have to read to get the spec right. No skipping, fr fr 💅
- [ATSCA331] Advanced Television Systems Committee, "Signaling, Delivery, Synchronization, and Error Protection", ATSC Standard A/331:2022-03, March 2022. 📺
- [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI
10.17487/RFC1952, May 1996,https://www.rfc-editor.org/info/rfc1952. 🎁 - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997,https://www.rfc-editor.org/info/rfc2119. 🔑 - [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI
10.17487/RFC2557, March 1999,https://www.rfc-editor.org/info/rfc2557. 🧩 - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI
10.17487/RFC3986, January 2005,https://www.rfc-editor.org/info/rfc3986. 🔗 - [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI
10.17487/RFC5052, August 2007,https://www.rfc-editor.org/info/rfc5052. 🛡️ - [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, DOI
10.17487/RFC5445, March 2009,https://www.rfc-editor.org/info/rfc5445. 🛡️ - [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI
10.17487/RFC5651, October 2009,https://www.rfc-editor.org/info/rfc5651. 🥞 - [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI
10.17487/RFC5775, April 2010,https://www.rfc-editor.org/info/rfc5775. 🥞 - [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, DOI
10.17487/RFC6330, August 2011,https://www.rfc-editor.org/info/rfc6330. 🦖 - [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI
10.17487/RFC6363, October 2011,https://www.rfc-editor.org/info/rfc6363. 🖼️ - [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI
10.17487/RFC6726, November 2012,https://www.rfc-editor.org/info/rfc6726. 📦 - [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014,https://www.rfc-editor.org/info/rfc7231. 🌐 - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174, May 2017,https://www.rfc-editor.org/info/rfc8174. 🔠 - [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI
10.17487/RFC8551, April 2019,https://www.rfc-editor.org/info/rfc8551. ✉️
13.2. Informative References 🌸
These ones are more like the extra reading. Useful, not required, but I'd still check them out 🧚
- [CMAF] International Organization for Standardization, "Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media", First edition, ISO/IEC FDIS 23000-19, January 2018,
https://www.iso.org/standard/71975.html. 🎬 - [DASH] International Organization for Standardization, "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats", Fourth edition, ISO/IEC 23009-1:2019, December 2019,
https://www.iso.org/standard/79329.html. 🎥 - [DVBMABR] ETSI, "Digital Video Broadcasting (DVB); Adaptive media streaming over IP multicast", version 1.1.1, ETSI TS 103 769, November 2020. 📡
- [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-quic-http-34, 2 February 2021,
https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34. 🚀 - [MBMS] ETSI, "Universal Mobile Telecommunications Systems (UMTS); LTE; 5G; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", version 16.9.1, ETSI TS 126 346, May 2021. 📶
- [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, DOI
10.17487/RFC3740, March 2004,https://www.rfc-editor.org/info/rfc3740. 🔐 - [RFC6968] Roca, V. and B. Adamson, "FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6968, DOI
10.17487/RFC6968, July 2013,https://www.rfc-editor.org/info/rfc6968. 📬 - [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 232, RFC 8932, DOI
10.17487/RFC8932, October 2020,https://www.rfc-editor.org/info/rfc8932. 🕵️ - [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI
10.17487/RFC9000, May 2021,https://www.rfc-editor.org/info/rfc9000. ⚡ - [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI
10.17487/RFC9147, April 2022,https://www.rfc-editor.org/info/rfc9147. 🔒
Acknowledgments 🫶
So this part is giving thank-you-notes energy. As outlined in the introduction and in ROUTE concepts in Section 9, this spec is the culmination of the collaborative work of several experts and organizations over the years. The authors would especially like to acknowledge the work and efforts of the following people and organizations to help realize the technologies described in this document (in no specific order): Mike Luby, Kent Walker, Charles Lo, and other colleagues from Qualcomm Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&D. Iconic behavior, honestly 👑
Authors' Addresses 🎀
Meet the authors! Here's where you can find them 💖
Waqar Zia
Qualcomm CDMA Technologies GmbH
Anzinger Str. 13
81671 Munich
Germany
Email: wzia@qti.qualcomm.comThomas Stockhammer
Qualcomm CDMA Technologies GmbH
Anzinger Str. 13
81671 Munich
Germany
Email: tsto@qti.qualcomm.comLenaig Chaponniere
Qualcomm Technologies Inc.
5775 Morehouse Drive
San Diego, CA 92121
United States of America
Email: lguellec@qti.qualcomm.comGiridhar Mandyam
Qualcomm Technologies Inc.
5775 Morehouse Drive
San Diego, CA 92121
United States of America
Email: mandyam@qti.qualcomm.comMichael Luby
BitRipple, Inc.
1133 Miller Ave
Berkeley, CA 94708
United States of America
Email: luby@bitripple.comThat's the whole thing, bestie! 🌈✨ Literally the best spec we've ever read together 💅
📦 where this page comes from
- ietf: rfc9223 2022-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms