# ECP-0053: Direct WebRTC Wire Framing (Chunked Frames)

Status: Draft

## Problem

`direct-publish` currently sends each CMAF object (init or `.m4s` fragment) as a single WebRTC
data-channel message (`encode_object_frame(meta, data)`).

Real OTA CMAF fragments routinely exceed typical data-channel maximum message sizes, causing
runtime failure like:

- `Error: outbound packet larger than maximum message size`

This blocks real-world HDHomeRun end-to-end streaming via `https://every.channel`.

## Goal

Make direct WebRTC transport robust by supporting large objects while keeping:

- ordered delivery,
- simple decoding in the website and CLI,
- no additional servers beyond the existing bootstrap API.

## Proposal

Define a minimal application-layer framing over WebRTC data-channel messages:

- Each data-channel message begins with a 1-byte tag:
  - `0x00`: legacy "whole object frame in one message" (optional compatibility)
  - `0x01`: stream-chunk bytes (new default)
- In `0x01` mode, bytes carry a length-prefixed stream:
  - `[u32_be length][frame bytes]` repeated
  - `frame bytes` are exactly the existing `encode_object_frame(meta, data)` output
- Publishers MUST:
  - use `0x01` mode,
  - split the stream into safe message payloads (e.g. 16 KiB chunks)
- Subscribers SHOULD:
  - accept both `0x01` and `0x00` to ease rollout.

## Rollout

- Update `ec-node direct-publish`, the website receiver, and `ec-node direct-subscribe`.
- Redeploy static site assets; bootstrap API unchanged.

## Reversibility

- The change is localized to `direct-*` and can be removed or replaced without touching MoQ.