TomatoRTC

The real-time infrastructure platform for products that outgrow hosted RTC.

Voice. Video. AI. One platform. Self-hostable or managed — signaling, control plane, TURN, SFU, and room-native AI workers in a single TypeScript monorepo.

Infrastructure software Voice AI enabler Self-host + managed

Provenance & founder

30 years building software. 10+ years of WebRTC. Production at scale.

TomatoRTC is independent new work by Nathaniel Currier after Temasys — WebRTC solutions architect → CTO. Healthcare, government, enterprise.

Temasys

WebRTC solutions architect → CTO — SDK design, signaling, media, TURN/STUN, platform ops, enterprise integrations.

Independent

Not copied from Temasys proprietary source, private repositories, or confidential implementation materials.

Carried forward

Deployment patterns, tenant isolation instincts, observability expectations, voice-AI room model — not prior code or customer IP.

Today

TypeScript monorepo with 600+ tests — protocol, server, clients, TURN, SFU, media-plane, workers, and runnable demos.

Note
Note Slide context
Full provenance statement: PROVENANCE.md (repository root). Similarity to prior systems reflects Nathaniel Currier's general professional knowledge, public WebRTC standards, browser APIs, open-source ecosystem behavior, and newly authored implementation work.

Market timing

Three converging markets — RTC, CPaaS, and voice AI.

Every B2B product eventually adds live video, voice, or AI-in-the-room. Hosted SDKs win the first sprint; at scale, buyers hit cost, compliance, and customization walls.

$12.6B WebRTC (2025)

→ $67B by 2032 at ~39.8% CAGR

Mordor Intelligence

$2.5B → $35B Voice AI agents

2025–2033 at ~39% CAGR — fastest wedge inside conversational AI

Grand View Research

Note
Note Slide context
WebRTC market $12.61B (2025), projected $67.37B (2032), 39.8% CAGR — Mordor Intelligence. Voice AI agents $2.54B (2025) → $35.2B (2033), ~39% CAGR — Grand View Research. CPaaS ~$14.9B (2025) — Metrigy. Segment definitions differ by publisher; chart uses publisher midpoint projections where ranges exist.

Problem

Hosted RTC optimizes for speed-to-demo, not speed-to-own.

Once teams need tenant isolation, audit exports, room-native voice AI, or predictable unit economics, hosted platforms become a strategic liability.

  • Economics Per-minute and per-participant SaaS fees compound as usage grows — voice AI multiplies audio minutes.
  • Compliance Regulated buyers need auditable signaling, tenant isolation, and data residency control.
  • Voice AI gap Sideband agent APIs route audio outside the product's media boundary; room-native workers are rare.
  • Observability Black-box vendors make root-cause analysis a support ticket, not an engineering workflow.

Solution

One platform: protocol, control plane, media, TURN, voice workers.

TomatoRTC ships as a cohesive monorepo — not a signaling SDK plus a separate SFU fork plus a TURN vendor plus a bolt-on agent framework. Integrate once, deploy on your cloud or ours.

Control plane

Multi-tenant rooms, JWT/OIDC, admin API, hash-chained audit, regional routing.

Media

Mesh + SFU (mediasoup production path), cascaded SFU, simulcast/SVC, integrated first-party engine.

Edge & relay

First-party TURN/STUN with dynamic credentials and bandwidth metering.

Voice & AI

Service participants — Node/Python/Go/C# SDKs; STT/LLM/TTS via WorkerAdapter; supervisor API.

Voice AI wedge

Room-native agents — the differentiation layer for the next decade of RTC.

Voice-AI spend is growing ~4× faster than core WebRTC. TomatoRTC treats workers as first-class participants: subscribe to remote audio on the SFU path, emit typed outputs, optionally publish synthesized voice back.

Human audio
AI worker output
Synthesized voice
  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.
Note
Note Slide context
Conversational voice AI agents ~$7.6B (2025) → ~$72B (2034) — ResearchIntelo (broader segment than Grand View voice-agent definition). Worker STT/LLM/TTS are customer/provider integrations; TomatoRTC ships subscription, output protocol, and supervisor — not a bundled foundation model.

Voice AI wedge · market

Fastest-growing segment inside conversational AI.

$7.6B Conv. voice AI (2025)

Broad conversational voice segment

ResearchIntelo

BYO provider Architecture

Whisper, Deepgram, OpenAI, Anthropic — swap adapters without forking the room runtime

Room-native Differentiation

Workers subscribe on the SFU path — raw media stays on customer boundary, not a sideband API

Supervisor API Shipped

Per-room worker spawn, typed WorkerOutput, optional TTS publish-back into room mix

Product

Deep enough to differentiate. Honest about what is production today.

Production SFU media runs on mediasoup. Signaling, auth, TURN, tenant policies, reconnect, chat, data channels, diagnostics, AI worker foundations, and client-ai perception are implemented with tests and runnable examples.

Browser SDK Shipped

Mesh/SFU, chat, DC, diagnostics, client-ai VAD on supported browsers

Signaling server Shipped

WebSocket + alt transports; tenant isolation; admin API

AI workers Shipped

WorkerRoomClient, supervisor API, transcription/assistant adapters

Media path Hardening

mediasoup production SFU; first-party integrated engine in hardening

Note
Note Slide context
† Integrated first-party SFU, media-plane production hardening, and cross-browser SFU CI are active engineering priorities — not yet positioned as universal production guarantees. Client effects and browser STT require supported platforms/browsers.

Product · status matrix

Layer-by-layer production reality.

Layer
Status
Notes
Browser SDK
Shipped
Mesh/SFU, chat, DC, diagnostics, client-ai VAD on supported browsers
Signaling server
Shipped
WebSocket + alt transports; tenant isolation; admin API
AI workers
Shipped
WorkerRoomClient, supervisor API, transcription/assistant adapters
SFU (mediasoup)
Production path
Default for RTC_TOPOLOGY=sfu deployments
First-party SFU
Hardening
Integrated UDP path; smoke harness; pilot-ready
Native mobile SDKs
Foundation / hardening
Swift/Kotlin/Flutter/C++ signaling foundations; media parity varies
Note
Note Slide context
Native SDK maturity is capability-specific: signaling and SFU-control foundations ship, while media interop, packaging, and production room UX remain hardening work.

Why we win

Control-plane depth + room-native voice AI + first-party TURN.

LiveKit proved demand for self-host SFU and agents. TomatoRTC targets buyers who also need tenant-scoped auth, audit exports, and relay economics — and AI workers on the same protocol as humans.

TomatoRTC
Typical hosted RTC
Self-host
✓ Full source
✗ Vendor cloud
Tenant + audit
✓ Built-in
Partial / add-on
Room-native voice AI
✓ Service participants
Sideband / separate product
First-party TURN
✓ In repo
Managed / third-party
Per-minute tax
✗ License + infra
✓ Vendor meter
Mobile native media
Foundation / hardening
✓ Shipped

Business model

Two revenue lines — license the platform or run it for them.

Hosted RTC solves distribution. It does not solve ownership. Deep enough to differentiate. Simple enough to deploy.

Self-managed licensing

  • Annual/term platform license (source + releases + support tier)
  • Expansion via seats, regions, worker workloads, support SLAs
  • Customer bears infra — we capture software margin
  • Land with dev teams; expand as production traffic grows

Managed solution

  • Fixed monthly solution cost = pass-through infra + management fee
  • TomatoRTC operates signaling, SFU, TURN, AI worker supervisor
  • Higher ACV, longer contracts, services attach
  • Land with teams that want ownership without ops headcount

Business model · TCO

Flat license vs compounding hosted per-minute fees.

Cost divergence increases over time. Hosted RTC: ↗ rapidly increasing. TomatoRTC: ↗ shallow, predictable growth.

Traction & maturity

Platform built — commercial motion next.

Core signaling, browser media, workers, metering, operator tooling, and bounded PMG slices ship with code and evidence. The next phase combines repeatable sales and design partners with focused production hardening.

Monorepo Shipped

protocol, server, client-browser, client-ai, TURN, SFU, media-plane, workers, examples

2 engines SFU paths

mediasoup production path plus integrated first-party engine under hardening

AI workers Runnable

Supervisor API, transcription/assistant adapters, kitchen-sink AI perception demo

Design partners Pipeline

B2B SaaS, teams exiting Twilio/Vonage managed APIs, regulated verticals — LOIs in validation pipeline

Moat & roadmap

Own the protocol layer and you own the platform economics.

Owning signaling + tenant policy + TURN + optional first-party media creates switching costs and margin that a thin SDK wrapper cannot match.

Protocol

UDP RTP/RTCP, pacing, DTLS/SRTP termination — reduces mediasoup dependency for control-sensitive buyers.

Control

Auth, audit hash chain, admin API, regional policy — hard to replicate by bolting onto a generic SFU.

Extensibility

WorkerOutput on room chat + optional audio publish — same integration surface for humans and AI agents.

Note
Note Slide context
† First-party media-plane and integrated-SFU items are engineering investments in hardening — moat narrative assumes continued execution through production-grade cross-browser validation.

Moat · roadmap priorities

What compounds the platform advantage next.

Developer Adoption → Ecosystem → Integrations → Data → Platform Advantage.

Observability depth P0

Support bundles, OTLP, topology — lowers cost-to-serve and increases trust in enterprise deals.

P0 roadmap P0

First-party congestion control, live recording/WHEP proof, native media parity, and broader browser-matrix CI.

Managed ops playbook

Multi-region reference deploys, runbooks, and failover drills for teams that want ownership without headcount.

Note
Note Slide context
Roadmap priorities reflect the platform gap analysis and engineering roadmap — not contractual delivery dates.

Go-to-market

Developer-led land, platform expand, managed upsell.

ICP: B2B SaaS with backend teams, teams outgrowing Twilio Video's narrowed vertical focus or Vonage's Ericsson-owned managed model, regulated verticals, and voice-AI builders who need room-native agents. Motion: kitchen-sink eval → pilot → license or managed contract.

Land

Open-source examples, docs, demo menu, AI worker supervisor, competitive executive summary.

Expand

More regions, voice worker workloads, enterprise auth/audit, support tier upgrades.

Upsell

Self-managed license → managed solution when customer wants us to operate the plane.

Channels

SI/consultancies for Twilio Video and Vonage managed API exits; vertical specialists in health/fintech/edtech.

Go-to-market · market

TomatoRTC sits at the intersection of three growing markets.

$67B WebRTC by 2032

Core infrastructure market at 39.8% CAGR

Mordor Intelligence

$35B Voice AI by 2033

Fastest wedge inside conversational AI at 39% CAGR

Grand View Research

$14.9B CPaaS (2025)

Communications platform market — migration opportunity

Metrigy

TomatoRTC

Building the commercial layer on a shipped platform.

The technical foundation is largely built — this round accelerates revenue and production hardening where it unlocks ACV.

  1. Design-partner deployments

    Onboard 3–5 design partners across B2B SaaS, teams exiting managed API lock-in (Twilio vertical narrowing, Vonage/Ericsson risk), and regulated verticals.

  2. Managed ops + native media

    Multi-region reference deploys, runbooks, and proven Swift/Kotlin media packaging and interop.

  3. Voice-AI reference architectures + GTM

    Reference integrations, competitive enablement, and go-to-market for migration and AI-native segments.

Targeting $2.5M Seed 18-Month Runway Hiring: Dev, Mobile & Sales