Skip to content
Thåst Docs

Roadmap

Phased development plan for Punch.

Status as of 2026-05-03. Phase 1 (MVP) and most of Phase 2 ship in v1.0.0. Phase 3 begins after real-world field validation feedback.

Principles

  • Ship early, iterate fast — a working signalling server is more valuable than a perfect one
  • Broadcast-first — features are prioritised by what broadcast engineers actually need in the field
  • Free tier viable — every phase must work within Cloudflare’s free tier for basic use
  • No vendor lock-in — the Punch protocol is open; the Cloudflare implementation is a reference, not the only option

Phase 1 — MVP

Get two SRT endpoints connected without manual IP exchange.

Core signalling

  • Session creation via REST API
  • Peer registration via WebSocket (Durable Objects + Hibernation API)
  • Peer coordinate exchange (IP:port from CF-Connecting-IP)
  • Session state machine (WAITING → READY → CONNECTED → CLOSED)
  • Automatic session TTL with Alarm API cleanup
  • Token-based authentication (HMAC-SHA256)

Auto-generated connection strings

  • FFmpeg command generation (with correct microsecond latency, pkt_size)
  • OBS configuration string
  • vMix configuration (GUI field values — vMix is GUI-only)
  • GStreamer pipeline string (role-aware: srtsrc/srtsink)
  • srt-live-transmit command (two-URI source → destination format)
  • REST endpoint (GET /api/session/:id/connect) for programmatic access
  • Direction-aware strings (send/receive toggle)

Web UI (minimal)

  • Session page (/s/:name) showing session state and peer info
  • QR code generation for session URL + token
  • Copy-to-clipboard for connection strings
  • Mobile-responsive (operators use phones in the field)
  • Admin observer receives peer match data for connection string generation
  • Stream and perspective selectors for multi-stream sessions

Passphrase distribution

  • Auto-generate 32-character AES passphrase on session creation
  • Distribute via WebSocket peer message
  • Include in generated connection strings

Deployment

  • wrangler.toml configuration
  • Custom domain support (IDN/punycode)
  • Health check endpoint
  • Basic rate limiting

Target: A producer creates a session, gets a QR code, sends it to the camera operator, who scans it and gets a working FFmpeg command — without manual port-forwarding or IP coordination, on networks that allow UDP rendezvous.

Phase 2 — Production grade

Support real multi-camera productions with monitoring and coordination.

Multi-stream session bundles

  • Named stream slots per session (cam-wide, cam-close, pgm-return, etc.)
  • Per-stream peer registration and state tracking
  • Stream slot claiming on connect
  • Session-level overview (N of M streams connected)
  • Dynamic stream creation (within configurable limits)

Real-time health dashboard

  • Peer-reported SRT statistics (RTT, retransmit, bitrate, buffer)
  • Colour-coded health indicators (green/amber/red)
  • Per-stream health cards on the session page
  • Threshold-based alerting (configurable per session)
  • Historical graph (last 5 minutes in-session)

Tally signalling

  • Tally state messages (off/preview/program) via WebSocket
  • Tally display on session dashboard per stream
  • API endpoint for external tally sources (vision mixer integration)
  • TSL UMD-compatible tally format

Latency recommendation

  • RTT estimation from WebSocket connection timing
  • Recommended SRT latency calculation (RTT × 4, minimum 120ms)
  • Display on session page: “Recommended: 200ms / Current: 120ms (too low)”
  • Include recommended value in generated connection strings

Peer token generation

  • Admin generates peer tokens via generatePeerToken() (stream-scoped, TTL-bound)
  • Admin UI for generating stream-scoped peer tokens
  • Per-stream QR codes with embedded peer tokens
  • Token expiry configuration

Target: A 4-camera ISO production runs through a single Punch session with per-camera health monitoring, tally, and one dashboard that shows everything.

Phase 3 — Ecosystem

Make Punch the standard tool for SRT session management.

Relay fallback

  • Detect hole-punch failure (peers report connecting but never connected)
  • Relay architecture design (separate UDP relay component)
  • Transparent relay activation (signalling server instructs peers to connect via relay)
  • Relay health monitoring on dashboard
  • RELAYING state in session state machine

STUN-based NAT classification

  • Client-side STUN probe before WebSocket connection
  • NAT type reporting to Punch (cone/restricted/symmetric)
  • Pre-flight compatibility check (“both sides are cone NAT → rendezvous will work”)
  • Automatic relay routing for symmetric NAT pairs

Pre-flight network analysis

  • RTT measurement between peers via relay probe
  • Bandwidth estimation
  • Jitter measurement
  • “Can we make it work?” assessment before going live
  • Recommended encoder settings based on measured path

CLI companion tool

  • punch create "show-name" — create a session from terminal
  • punch join "show-name" --stream cam-wide --port 9000 — register and get peer info
  • punch status "show-name" — display session state
  • punch connect "show-name" --ffmpeg — output ready-to-run FFmpeg command
  • Cross-platform binary (Go or Rust)

Protocol specification

  • Formal Punch protocol document (versioned)
  • Message schema validation (JSON Schema or Protocol Buffers)
  • Interoperability test suite
  • Reference client implementation (TypeScript)

Professional UI

  • Dark theme optimised for control rooms
  • Signal-flow visualisation (source → punch → destination)
  • Large status indicators (visible at arm’s length, like broadcast monitoring)
  • Multi-session overview (for facilities running multiple productions)
  • Keyboard shortcuts for operators

Target: Punch is the go-to tool for SRT session management. CLI for automation, web UI for operators, protocol spec for integrators.

Phase 4 — Advanced (future)

Features that extend Punch beyond basic session brokerage.

Return feed / IFB coordination

  • Bidirectional SRT sessions (contribution + return audio)
  • IFB audio stream as a named stream slot
  • Director-to-operator audio via SRT return path

Recording integration

  • Session-level recording trigger (start/stop via dashboard)
  • Webhook notifications on session events (for external recording systems)
  • R2 storage integration for session metadata/logs

Stream ID namespace

  • Registered broadcaster namespaces (e.g., broadcaster-org/*)
  • Automatic stream routing based on Stream ID
  • Multi-tenant session management

SRT bonding coordination

  • Multi-path SRT bonding via libsrt socket groups
  • Per-path health tracking on dashboard
  • Failover visualisation
  • Integration with cellular bonding hardware

NMOS / ST 2110 bridge

  • NMOS IS-04 registration for Punch-brokered SRT streams
  • IS-05 connection management integration
  • Metadata mapping between Punch sessions and NMOS resources

Non-goals

Things Punch will intentionally never do:

  • Transcode video — use FFmpeg, hardware encoders, or cloud transcoding
  • Distribute to viewers — use a CDN, HLS/DASH origin, or SRT relay tree
  • Replace vision mixers — Punch carries tally, it doesn’t generate it
  • Become a media server — Punch is signalling only; media flows peer-to-peer

Punch does one thing well: it gets SRT endpoints connected. Everything else is someone else’s job.