# MoQ & MMT: Streaming Delivery Paths

MoQ (Media over QUIC) is Blockcast's low-latency delivery protocol for interactive streaming. Built on IETF MoQ drafts and WebTransport/QUIC, it delivers sub-500ms glass-to-glass latency — making it suitable for live sports, esports, auctions, and any use case where seconds of delay are unacceptable.

Unlike [MAHP](/main/overview/control-plane/treedn-multicast/mahp.md), which stores-and-forwards content through an encrypted cache, MoQ is a **real-time pass-through protocol** with no store-and-forward semantics. MoQ Relays forward media tracks directly from publishers to subscribers without caching.

The underlying container format is **MPEG Media Transport (MMT)** ([ISO 23008-1](https://www.iso.org/standard/82259.html)) — the same format used by ATSC 3.0 broadcast, 5G MBS, and ISP multicast. By defining how MMT maps onto MoQ objects ([draft-ramadan-moq-mmt](https://github.com/blockcast/pim-multicast-gateway/blob/main/docs/draft-ramadan-moq-mmt-01.md)), the same MMTP packets — identical bytes — can flow over any transport without transcoding.

{% @mermaid/diagram content="flowchart LR
subgraph CAST\[CAST Node]
FF\[FFmpeg] -->|MMTP/QUIC| MR\_C\[MoQ Relay]
end

```
subgraph RELAY[RELAY Node]
    MR_R[MoQ Relay]
end

subgraph BEACON[BEACON Node]
    MR_B[MoQ Relay]
end

MR_C -->|QUIC| MR_R
MR_R -->|QUIC| MR_B

MR_R -->|MoQ| P1[Player]
MR_B -->|MoQ| P2[Player]

subgraph IWA[Optional: IWA/SDK]
    PIM[PIM Gateway]
end

FF -->|MMTP SSM| AMT[AMT Relay]
AMT -.->|AMT tunnel| PIM" %}
```

***

## How MoQ Works

### 1. Publishing (CAST → MoQ Relay)

FFmpeg on the CAST node publishes directly to the downstream MoQ Relay using the `moq_mmt` muxer — wrapping fMP4 fragments in MMTP packets and delivering them over **WebTransport/QUIC** (IETF MoQ draft).

There is no intermediate MoQ Server on the CAST node; FFmpeg acts as the MoQ publisher. This eliminates one hop of latency compared to architectures that require a local relay.

### 2. Relay Forwarding (RELAY → RELAY → BEACON)

MoQ Relays forward tracks from upstream publishers or parent relays to downstream subscribers and child relays. The relay implementation (`hang-mmt-fec`) is a Rust binary supporting:

* **Dual-stack protocol**: Both moqtail-00 (Draft-14 MoQ) and moqlite-00 protocols.
* **Track registry**: Cross-protocol forwarding with FEC metadata translation — a subscriber on moqlite can receive from a moqtail publisher.
* **Pass-through forwarding**: No caching, no transcoding. Packets arrive and leave in real time.

MoQ Relays can be chained (CAST → RELAY → RELAY → BEACON), same as [MAHP](/main/overview/control-plane/treedn-multicast/mahp.md), but the forwarding is purely real-time — there's no cache to warm up.

### 3. Playback (Relay → Player)

Each RELAY and BEACON exposes a **MoQ ingress** (ALPN `moq-00` on port 443). Unmodified MoQ players connect here over standard QUIC/WebTransport and subscribe to tracks. The player is unaware of the multicast infrastructure upstream.

***

## MoQ vs. MAHP Comparison

| Aspect             | MoQ                           | [MAHP](/main/overview/control-plane/treedn-multicast/mahp.md) |
| ------------------ | ----------------------------- | ------------------------------------------------------------- |
| Latency            | Sub-500ms                     | Seconds (segment-based)                                       |
| Transport          | QUIC/WebTransport             | Multicast UDP + HTTP                                          |
| Caching            | None (pass-through)           | Encrypted edge cache                                          |
| FEC                | ALTA (Ed25519 per-packet)     | TESLA + RaptorQ/Reed-Solomon                                  |
| Best for           | Interactive live, low-latency | High-throughput broadcast, file delivery                      |
| Player requirement | MoQ-capable (WebTransport)    | Standard HTTP (DASH/HLS)                                      |
| Offline resilience | None (real-time only)         | Cache serves during disruptions                               |

Both protocols run simultaneously on every RELAY and BEACON. The [CAST node](/main/overview/control-plane/treedn-multicast.md#cast-sender-content-source) feeds both paths from the same FFmpeg process, so content is always consistent.

***

## MMT: The Unified Container Format

MPEG Media Transport (MMT) is the unifying container across all Blockcast delivery paths. MMT is already the **native container** for ATSC 3.0 broadcast (Americas, South Korea), ARIB STD-B60 (Japan), and 5G Multicast-Broadcast Services (3GPP MBS).

Content ingested once at a CAST node reaches every device class through its optimal delivery path:

| Delivery Path          | Physical Medium              | Receiver                | Requirements                                |
| ---------------------- | ---------------------------- | ----------------------- | ------------------------------------------- |
| **ATSC 3.0 broadcast** | Over-the-air RF spectrum     | TV with ATSC 3.0 tuner  | Tuner hardware (Samsung, LG, Sony 2020+)    |
| **5G MBS**             | Cellular broadcast (3GPP)    | 5G phone/tablet         | 5G modem + MBS middleware                   |
| **PIM-SSM + IGMPv3**   | ISP IP multicast             | IWA browser, native app | Multicast-enabled ISP, UDP socket access    |
| **AMT unicast tunnel** | UDP encapsulation (RFC 7450) | IWA browser, native app | Any network with UDP, DRIAD relay discovery |
| **MoQ/QUIC unicast**   | WebTransport                 | Any browser, any app    | None (universal fallback)                   |

### ATSC 3.0 (Broadcast TV)

ATSC 3.0 televisions receive MMTP streams natively over RF tuner hardware. These devices perform S-TSID parsing for FEC parameters and multicast group information, RaptorQ FEC decoding, and MMTP depacketization into MPU media segments — all in dedicated silicon.

MoQ integration happens at the **gateway level**, not on the TV itself. The MMT-MoQ draft defines bidirectional S-TSID ↔ MoQ Catalog conversion, so the same content is discoverable by both broadcast receivers (via S-TSID/SLT bootstrap signaling) and MoQ subscribers (via catalog JSON). An ATSC 3.0 broadcast station's S-TSID becomes a MoQ catalog, enabling a single content pipeline to serve both broadcast and IP-delivered audiences simultaneously.

### 5G Multicast-Broadcast Services

3GPP MBS ([TS 22.246](https://www.3gpp.org/DynaReport/22246.htm), Release 17) defines multicast-broadcast at the 5G modem level. 5G MBS can carry the same MMTP streams as ATSC 3.0, with the modem handling delivery and the CAS (Conditional Access System) stack handling decryption independently.

**CAS muting** enables simultaneous broadcast: the same encrypted MMTP stream serves ATSC 3.0 tuners over RF and 5G MBS devices over cellular. Each receiver's CAS stack decrypts independently — the content provider encrypts once, and both physical layers deliver the same protected bytes.

On Android, the receive path is provided by the Qualcomm LTE Broadcast SDK or the open-source [5G-MAG middleware](https://github.com/5G-MAG/rt-libflute). The modem delivers MMTP packets directly to the application layer — same bytes, different physical medium. Combined with the DePIN token incentive model, 5G MBS receivers can earn rewards simply by tuning in to multicast streams, contributing to network offload.

### PIM-SSM + IGMPv3 (ISP Multicast)

When an ISP has enabled PIM-SSM on their routers, clients can receive multicast natively — the most bandwidth-efficient delivery path after broadcast.

1. The MoQ catalog includes SSM (S,G) endpoint addresses in its `multicast` extension field.
2. A native client or IWA browser app issues an **IGMPv3 join** for the source-specific group (e.g., `(10.0.0.1, 232.1.1.10)`).
3. PIM-SSM builds a shortest-path tree from the source through the ISP's routers to the subscriber's edge.
4. MMTP packets replicate **in router silicon** at each hop — not in software on x86 servers.
5. The client receives the identical MMTP packets that the CAST node produced.

SSM group allocation maps each ABR quality tier to a separate multicast group, so quality switches are IGMPv3 leave/join operations. FEC repair symbols are carried on dedicated groups. For browsers, this requires IWA with DirectSocket API (`UDPSocket.joinGroup()`). For native apps, Android provides `MulticastSocket` with `MulticastLock`, and iOS provides `NWConnectionGroup` (iOS 14+).

### Hardware-Offloaded AMT Unicast Tunnel

AMT ([RFC 7450](https://datatracker.ietf.org/doc/rfc7450/)) is the pragmatic fallback when PIM-SSM is not available on the subscriber's ISP. AMT encapsulates multicast packets inside a UDP unicast tunnel:

1. The client discovers the nearest AMT relay via **DRIAD** ([RFC 8777](https://datatracker.ietf.org/doc/rfc8777/)) — a DNS reverse lookup on the multicast source IP.
2. The client establishes an AMT tunnel (UDP port 2268) to the relay.
3. The relay performs an IGMPv3 join on behalf of the client on its multicast-enabled upstream interface.
4. MMTP packets arrive at the relay via native multicast, get encapsulated in UDP, and tunnel to the client.

The critical advantage is **hardware offload**: thousands of ISP edge routers (Juniper MX) already have AMT relay capability built into their routing ASICs. A single router performs the packet replication function that previously demanded dedicated CDN server complexes — up to 500,000 concurrent tunnels at line-rate throughput per device. The marginal cost is a configuration change, not new hardware.

This is the path shown in the [architecture diagram](/main/overview/control-plane/treedn-multicast.md#layered-architecture) as `FFmpeg → MMTP SSM → AMT Relay -.-> AMT tunnel -.-> IWA/SDK Player`. For full details on AMT relay infrastructure, see [AMT Relays & Multicast Backbone](/main/overview/control-plane/treedn-multicast/amt-relays.md).

***

## Transport Hierarchy (Graceful Degradation)

Clients attempt transports in preference order, starting with the highest-bandwidth path and falling back gracefully:

**Native clients (TV, mobile SDK)**:

| Priority | Transport                 | Availability               |
| -------- | ------------------------- | -------------------------- |
| 1        | Native SSM (IGMPv3/MLDv2) | Multicast-enabled networks |
| 2        | AMT over UDP (RFC 7450)   | Any network with UDP       |
| 3        | MoQ over QUIC             | Universal                  |
| 4        | HTTP DASH/HLS             | Universal fallback         |

**Browser clients**:

| Priority | Transport                | Availability             |
| -------- | ------------------------ | ------------------------ |
| 1        | SSM via IWA DirectSocket | IWA-enabled Chrome       |
| 2        | AMT via IWA DirectSocket | IWA-enabled Chrome       |
| 3        | MoQ over WebTransport    | Chrome 97+, Firefox 115+ |
| 4        | HTTP DASH via MSE/fetch  | Universal fallback       |

Every client starts at Priority 3 or 4 (unicast), receives the MoQ catalog which includes the `multicast` endpoint discovery extension, then **promotes itself** to the highest available path. The catalog itself is the discovery mechanism — no separate signaling infrastructure is needed.

For general consumer web applications, MoQ/WebTransport (Priority 3) is effectively the highest available transport. IWA DirectSocket (Priorities 1–2) is available to enterprise-managed Chrome, DePIN participants with token-incentivized IWA installation, and technical users who side-load the IWA.

***

## Direct Multicast via IWA & Mobile SDK

For clients that want to bypass the relay infrastructure entirely and receive multicast directly, Blockcast provides optional browser and mobile extensions through the PIM Multicast Gateway.

### Chrome IWA (Isolated Web App)

An optional in-browser gateway with Direct Sockets API access:

* Manages multicast subscriptions, AMT tunnel lifecycle, and DRIAD relay discovery.
* Enables direct multicast data path without a local BEACON.
* **WASM Modules**: Rust-compiled AMT protocol (RFC 7450 state machine, IGMP/MLD report generation) and ALTA authentication (Ed25519 verification).

### Chrome Extension

Message router bridging the webpage and IWA, handling tab lifecycle and origin-based security.

### Mobile SDK

Optional native AMT gateway for Android and iOS applications — same direct multicast capability as the IWA, for native apps.

### Transport Modes (when IWA or Mobile SDK is active)

| Mode               | Behavior                                                   | Latency  | Throughput |
| ------------------ | ---------------------------------------------------------- | -------- | ---------- |
| **Native**         | Direct Sockets API → OS multicast join                     | \~1ms    | 10Gbps+    |
| **AMT Tunnel**     | DRIAD discovery → UDP tunnel via WASM                      | \~2ms    | 5Gbps+     |
| **Auto** (default) | Try native → fallback to tunnel if no packets in N seconds | Adaptive | Adaptive   |

Without the IWA or Mobile SDK, the client simply connects to the nearest BEACON or RELAY as a standard MoQ player over WebTransport.

### Browser Compatibility

For browsers without IWA support (Firefox, Safari), the MoQ BEACON can bridge to non-IWA clients via:

* **mDNS advertisement** (`_moq-gateway._tcp.local`): Local network IWA discovery
* **WebTransport bridge**: Forwards multicast to secondary browsers over QUIC
* **Standalone Node.js gateway**: Docker-deployable for headless environments

***

## IWA Home Gateway

An IWA node running on a wired-connected device (Chromebox, desktop, mini-PC) can serve as a **local multicast anchor**, bridging ISP multicast to household wireless devices:

```
Internet (SSM/AMT)
       │
       ▼
 [ISP Router w/ AMT Relay]
       │  wired Ethernet
       ▼
 [Chromebox / Desktop IWA]  ← DirectSocket multicast rx
       │  WebTransport (local)
       ▼
 [Phone] [Tablet] [Smart TV] [Laptop]
```

Advantages:

* **Wired reception avoids Wi-Fi jitter** and supports higher bitrates than wireless multicast (most consumer APs do not relay multicast).
* **A single multicast stream serves the entire household** regardless of the number of local viewers.
* **Wireless clients use standard MoQ/WebTransport** with no IWA requirement, no special permissions, and full browser compatibility.
* **Local FEC repair** reduces retransmission round trips to the origin.

***

## Authentication

MoQ streams use a different authentication mechanism than MAHP:

* **ALTA** (Asymmetric Loss-Tolerant Authentication): Ed25519 per-packet verification for MoQ-MMT streams. Integrated into the PIM multicast gateway. Unlike TESLA's time-delayed disclosure, ALTA provides immediate verification — important for low-latency use cases.

***

## End-to-End Flows

### Multicast Publishing Flow

{% @mermaid/diagram content="sequenceDiagram
participant CP as Content Provider
participant UCDN as Upstream CDN
participant CTRL as Controller
participant CAST as CAST
participant TR as Traffic Router

```
CP->>UCDN: Configure delivery service
UCDN->>CTRL: CDNi CI push config
CAST->>CTRL: Discover delivery services
CTRL->>CAST: PublishConfig (relay, group, FEC)

Note over CAST: FFmpeg tee muxer: 3 outputs

par CMAF HTTP to MAHP Sender
    CAST->>CAST: ROUTE/FLUTE encode + FEC + TESLA
and MMTP/QUIC to MoQ Relay
    CAST->>CAST: moq_mmt publish via WebTransport
and MMTP SSM to multicast
    CAST->>CAST: RaptorQ FEC + SSM 232.x.x.x
end

CAST->>CTRL: Health report (service303)
CTRL->>TR: Update routing tables" %}
```

### Relay & Coverage Flow

{% @mermaid/diagram content="sequenceDiagram
participant CAST as CAST
participant AMT as AMT Relay
participant RELAY as RELAY
participant BEACON as BEACON

```
CAST->>AMT: SSM multicast
RELAY->>AMT: AMT Discovery + IGMPv3 join
AMT->>RELAY: Multicast data (UDP encap)
RELAY->>RELAY: FEC decode + push to cache
Note over RELAY: Repair server active

BEACON->>BEACON: DRIAD lookup
BEACON->>RELAY: IGMPv3 join
RELAY->>BEACON: Multicast stream
BEACON->>BEACON: FEC decode + cache

opt Packet loss
    BEACON->>RELAY: FEC repair request
    RELAY->>BEACON: Repair symbols
end" %}
```

### Playback Flow

{% @mermaid/diagram content="sequenceDiagram
participant EU as Player
participant TR as Traffic Router
participant RELAY as RELAY
participant BEACON as BEACON

```
EU->>TR: DNS or HTTP request
TR->>TR: Geo + health routing

alt BEACON available
    TR->>EU: HTTP 302 to BEACON
    EU->>BEACON: HTTP or MoQ
    alt Cache HIT
        BEACON->>EU: Serve from cache
    else Cache MISS
        BEACON->>RELAY: DRIAD + AMT join
        RELAY->>BEACON: Multicast stream
        BEACON->>EU: Serve content
    end
else RELAY coverage
    TR->>EU: DNS to RELAY
    EU->>RELAY: HTTP or MoQ
    RELAY->>EU: Serve from cache or relay
else No coverage
    TR->>EU: Upstream CDN unicast
end" %}
```

***

## Standards & References

| Standard                                                                                                                           | Role                                                           |
| ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| IETF MoQ (Draft-14)                                                                                                                | Core protocol for media delivery over QUIC                     |
| [ISO 23008-1](https://www.iso.org/standard/82259.html) (MMT)                                                                       | Universal container format across all delivery paths           |
| [draft-ramadan-moq-mmt](https://github.com/blockcast/pim-multicast-gateway/blob/main/docs/draft-ramadan-moq-mmt-01.md)             | MMT packaging for MoQ — maps MMTP packets to MoQ objects       |
| [draft-ramadan-moq-multicast](https://github.com/blockcast/pim-multicast-gateway/blob/main/docs/draft-ramadan-moq-multicast-00.md) | Multicast delivery and catalog endpoint discovery for MoQ      |
| [draft-ramadan-moq-fec](https://github.com/blockcast/pim-multicast-gateway)                                                        | Forward Error Correction for MoQ (RaptorQ, LDPC, Reed-Solomon) |
| ATSC 3.0                                                                                                                           | Over-the-air broadcast standard (Americas, South Korea)        |
| ARIB STD-B60                                                                                                                       | Japanese broadcast standard using MMT                          |
| [3GPP TS 22.246](https://www.3gpp.org/DynaReport/22246.htm) (5G MBS)                                                               | 5G Multicast-Broadcast Services                                |
| [RFC 7450](https://datatracker.ietf.org/doc/rfc7450/) (AMT)                                                                        | Tunneling for IWA/SDK direct multicast path                    |
| [RFC 8777](https://datatracker.ietf.org/doc/rfc8777/) (DRIAD)                                                                      | Relay discovery for IWA/SDK direct multicast path              |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.blockcast.network/main/overview/control-plane/treedn-multicast/moq.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.