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.

1.6 KiB Raw Blame History