Realtime media over quic workflow

Realtime Media Over QUIC Workflow

Purpose

Use this skill for Media over QUIC work where MoQ terminology, relay topology, media-object delivery, or draft-aware experimentation is central. Treat MoQ as draft-driven until current IETF status proves otherwise.

Source Check

Start with the IETF MoQ working group documents. Check the current active drafts before giving production guidance, especially:

• draft-ietf-moq-transport
• streaming format drafts such as draft-ietf-moq-msf, draft-ietf-moq-cmsf, or related packaging drafts when media format matters
• security, authorization, privacy, relay, qlog, and extension drafts when those behaviors are in scope

State the exact draft names and dates used. If the implementation targets a library, relay, CDN, browser experiment, or product preview, check its current docs or source too.

Planning Workflow

1. Inspect the media job:
   • live streaming, contribution, relay/CDN distribution, watch party, camera feed, generated media, telemetry plus media, or experiment
   • latency budget, viewer count, publisher count, reliability, ordering, object lifetime, rewind, caching, and fanout needs
   • media format, packaging, timestamps, encryption, authorization, and privacy requirements
   • existing WebRTC, HLS, DASH, LL-HLS, WebSocket, or HTTP streaming path
2. Decide whether MoQ fits:
   • fits when object-oriented low-latency media distribution, relay subscriptions, and QUIC transport properties are the core problem
   • does not fit by default for stable browser conferencing, ordinary app chat, file downloads, simple event streams, or production video delivery with mature HLS/DASH requirements
3. Separate roles:
   • publisher, subscriber, relay, catalog/discovery, auth service, media packager, player, and observability owner
   • do not make one service own relay, auth, media packaging, storage, and player behavior without a concrete reason
4. Design fallback:
   • WebRTC for browser/native real-time calls and peer/media interactivity
   • HLS/DASH or LL-HLS for broad production video playback
   • WebSocket or SSE for non-media app events
   • HTTP/3 or direct QUIC only when the transport itself is the experiment

Validation

Use evidence that matches the claim:

• draft version and implementation commit/version
• relay/publisher/subscriber logs
• qlog or protocol event output
• measured startup, live edge, and rebuffer behavior
• object loss, ordering, and retransmission behavior
• authorization and encryption checks
• player compatibility and fallback behavior

If validation requires a real network, media device, CDN, relay, or browser experiment that is not available, report that as a manual validation gap.

Output Shape

Return:

1. MoQ fit: yes, no, experiment-only, or mixed.
2. Draft state: exact IETF drafts and dates checked.
3. Topology: publisher, relay, subscriber, packager, player, auth, and observability roles.
4. Media behavior: latency, reliability, ordering, packaging, encryption, authorization, and fallback.
5. Implementation owner: stack plugin, relay/library, client, deployment, or docs-only plan.
6. Validation: logs, qlog, media metrics, compatibility checks, or manual gaps.

Guardrails

• Do not present MoQ as a stable production default while the relevant behavior is still draft-driven.
• Do not use MoQ as a synonym for WebRTC, HTTP/3, or generic QUIC.
• Do not skip fallback planning for user-facing media.
• Do not claim relay/CDN behavior without implementation-specific evidence.