TomatoRTC

Shipped foundation. Production hardening. Clear next bets.

Build once. Deploy anywhere. Own the platform. Current maturity is capability-specific: production paths, bounded shipped slices, active hardening, and deliberately deferred work are labeled separately.

Shipped platform foundation Native media parity hardening mediasoup SFU today

Provenance

Roadmap priorities reflect production RTC experience — not a feature wish list.

TomatoRTC is independent new work by Nathaniel Currier (Temasys WebRTC architect, former CTO). Shipped vs hardening vs deferred lanes mirror what teams actually need after going live — learned from deployment, SDK adoption, and customer integration.

  • Real deployments TURN metering, ICE credential routing, and topology policy informed by relay and signaling operations at scale.
  • SDK friction Kitchen-sink diagnostics, support bundles, and reconnect behavior shaped by what integrators struggle with in the field.
  • Voice AI wedge Service-participant workers and client-ai perception reflect how buyers want agents in the room, not sideband hacks.
  • Clean slate Ground-up monorepo; see PROVENANCE.md for independence from Temasys proprietary materials and customer IP.
Note
Note Slide context
Authoritative provenance: PROVENANCE.md at repository root. TomatoRTC carries forward general technical, operational, and customer-experience learnings — not prior work, confidential implementation material, or customer-specific IP from Temasys or Temasys customers.

Timeline

Three lanes — shipped, hardening, planned.

The platform foundation shipped across 2024–2025. Current engineering concentrates on first-party congestion control and browser coverage, live recording orchestration and WHEP playback validation, native media packaging and interop, and broad PMG deployment proof.

Note
Note Slide context
Timeline is directional for planning conversations — not a contractual delivery schedule. Dashed items represent deliberately deferred roadmap entries.

Shipped

Production foundation — control plane and media.

Working code, focused tests, and examples. Production SFU media uses mediasoup; signaling, auth, TURN, and diagnostics are self-host ready.

shipped

Control & signaling

  • WebSocket/WSS signaling, distributed registry adapters, multi-node fan-out
  • JWT/OIDC/OAuth auth, tenant tokens, admin API, short links
  • Audit hash chain, SIEM + NDJSON export, global monitoring dashboard
  • Usage telemetry Phases 0–5 + 6b slices — server, TURN/SFU, browser opt-in, AI, recording, PMG, and sidecar meters
shipped

Media & edge

  • Browser SDK mesh + mediasoup SFU, simulcast/SVC, reconnect + cursor replay
  • First-party TURN/STUN with metering and relay verification harnesses
  • Cascaded SFU topology, regional routing, SFU producer/consumer recreation
  • WHIP/WHEP HTTP gateway — real SDP, trickle ICE, producer/consumer wiring, and dual-engine coverage

Shipped · workers & AI

Service participants and room-native voice AI wiring.

shipped

Workers & AI

  • Service participants — Node, Python, Go, C# signaling clients
  • WorkerAdapter hooks: transcription, moderation, assistant, analytics
  • AiWorkerSupervisor, POST /api/rooms/:roomId/ai-workers, client-ai VAD

Active hardening

Engineering focus — owned media and security depth.

Available for evaluation and pilot deployments; not positioned as universal production guarantees until cross-browser validation lands.

hardening

First-party media plane

  • Integrated FirstPartySfuMediaEngine — UDP RTP/RTCP, DTLS/SRTP, pacing
  • RTCP feedback (TWCC/REMB), congestion control, production pacing
  • Chromium↔Firefox separate-browser coverage; WebKit/Safari and production-scale tuning remain
hardening

Recording & security

  • Live room recording worker wiring (mesh + SFU) through signaling
  • E2EE frame transform attachment and key distribution protocol
  • Active speaker detection as room/subscription policy
Note
Note Slide context
† First-party SFU and media-plane items require continued hardening through production-grade cross-browser validation before enterprise GA positioning. See kitchen-sink real-vs-stubbed panel and production-readiness guide for current status.

Active hardening · ops

Durability, clustering, and automated verification.

hardening

Ops & durability

  • Durable persistence, clustering, durable short-link store
  • Monitoring history, alerting hooks, production runbook automation
  • Broader WebKit/Safari SFU coverage and full CI integration of the browser matrix

Engineering priorities

What unlocks the next production wave.

Ordered by platform risk and customer impact. The remaining work is not one undifferentiated gap: each path has a shipped foundation and a specific hardening target.

  • First-party SFU Production-scale congestion control, pacing guidance, recovery, and WebKit/Safari coverage
  • Recording & WHEP Live signaling-room worker orchestration plus real playback validation
  • Native media parity Package and prove Swift/Kotlin/Flutter/C++ media interop beyond signaling foundations
  • PMG deployment Validate bounded compositor and broadcast paths with real downstream consumers
2 engines Browser SFU

mediasoup production path plus integrated SFU; Chromium↔Firefox coverage exists

0–5 + 6b Metering

Canonical exporters and server/browser/media/worker usage paths ship

4 paths Native foundations

Swift, Kotlin, Flutter, and C++ packages have capability-specific foundations

Recording Foundation shipped

WebM from synthetic SFU RTP; live worker wiring in hardening

Voice AI roadmap

Room-native agents — shipped wiring, expanding production surface.

Worker foundations and supervisor API are shipped. Near-term AI roadmap focuses on reference architectures, browser perception hardening, and production-grade STT/TTS adapter patterns — not bundling a proprietary model.

  1. Human participants publish live audio into the room over mesh or SFU paths.
  2. A service worker joins the same room via WorkerRoomClient with role service.
  3. The worker subscribes to remote audio, runs VAD turn detection, then STT, LLM, and TTS adapters.
  4. Structured WorkerOutput events and optional synthesized audio publish back into the room.
VAD / STT
LLM adapter
TTS publish-back
Note
Note Slide context
Browser STT/VAD varies by platform — see client-AI perception guide. Provider-specific STT, LLM, and moderation remain application adapters per the workers guide.

Voice AI roadmap · phases

Now, next, hardening — and explicit non-goals.

Now

WorkerRoomClient, transcription/assistant/moderation adapters, supervisor REST, kitchen-sink AI perception demo

Next

Streaming STT adapter templates (Deepgram, Whisper), TTS publish-back examples, worker output UI components

Hardening

Worker scaling policy, per-tenant worker quotas in admin, redacted transcript export for audit

Not in scope

Hosted foundation-model API, turnkey voice-agent SaaS — customers BYO LLM/STT/TTS

Deliberately deferred

Explicit non-commitments — clear scope boundaries.

We name these so evaluators know what TomatoRTC optimizes for vs. what we are not building near-term.

deferred

Media mixing & gateways

  • Traditional always-on MCU mixing (PMG is the bounded composition direction)
  • Production-scale WHIP/WHEP hardening and consumer playback proof (core Phases A–E ship)
  • SIP gateway / PSTN interop
deferred

ML effects & analytics warehouse

  • Production ML/audio effects beyond example plugins
  • Durable admin analytics warehouse and autoscaling policy engine

Why defer

TomatoRTC targets infrastructure buyers who want protocol ownership and room-native workers — not a fully managed UCaaS with PSTN and MCU compositing on day one.

Competitive trajectory

Catching LiveKit on mobile; ahead on tenant + TURN + audit.

Roadmap priorities now focus on native media parity beyond shipped signaling foundations, first-party media hardening for control-sensitive buyers, live recording/WHEP proof, and repeatable managed operations.

Capability
TomatoRTC today
Target (12–18 mo)
Self-host SFU
✓ mediasoup
+ first-party option GA
Native mobile SDKs
Signaling foundations
Proven Swift + Kotlin media interop
Voice AI in room
✓ workers shipped
+ reference arch + scaling
Tenant + audit
✓ built-in
+ compliance package
Composited recording
Bounded PMG slices
Durable live workflow + validated egress
Managed global edge
Managed playbook WIP
3-region reference deploy

Run the demo. Review the evidence. Scope a pilot.

  1. Kitchen sink

    Real vs stubbed panel shows actual production surface

  2. Capability evidence

    Current shipped, foundation, and roadmap status with source links

  3. Design partner

    Influence P0 ordering (mobile, recording, managed ops)