Why Telehealth Platforms Are Quietly Moving Beyond WebRTC

A protocol transition is coming in real-time communications, and most telehealth engineering teams haven’t begun thinking about it yet. That’s understandable — WebRTC still works, your stack is stable, and there are always more urgent things to build. But the decisions telemedicine CTOs make about protocol architecture in the next 12–24 months will determine how much of their infrastructure needs to be rebuilt in the next three to five years.

Media over QUIC — MoQ, in the shorthand that’s gaining traction in the industry — is transitioning from an IETF working group draft to real-world deployment faster than most people expected. Cloudflare has been running public MoQ infrastructure. Major CDN providers are building support. And the capabilities MoQ unlocks are directly relevant to the problems telemedicine platforms are actively trying to solve: scale, latency, AI integration, and cost at large participant counts.

This isn’t a “watch this space” article. It’s an engineering-grounded assessment of what MoQ actually is, how it compares to WebRTC in the dimensions that matter for healthcare, where it’s genuinely better, where it isn’t, and what Trembit recommends telemedicine CTOs do about it today.

What MoQ Actually Is (Beneath the Hype)

Media over QUIC is an IETF protocol under active standardization that defines how media — audio, video, data — is published, subscribed to, and delivered over QUIC transport. QUIC itself is the underlying transport protocol that HTTP/3 is built on: it runs over UDP, handles multiplexed streams without head-of-line blocking, and has better congestion control behavior than TCP in lossy network conditions.

The mental model for MoQ is publish/subscribe, not peer-to-peer. A participant publishes a media track to a relay; other participants subscribe to it. Relays can be chained. The protocol handles the subscription, prioritization, and delivery semantics.

This is fundamentally different from WebRTC in a few important ways:

WebRTC was designed for direct peer-to-peer communication. The SFU architecture that most production telehealth platforms use is a workaround — WebRTC wasn’t built for it, which is why media servers are complex to operate and why adding non-participant consumers (AI agents, recording, monitoring) requires architectural gymnastics.

MoQ was designed for scalable media distribution from the start. The publish/subscribe model naturally supports any number of subscribers, including AI processing pipelines, without special infrastructure accommodations. An AI agent subscribing to a media track is architecturally identical to a human participant subscribing.

WebRTC is a browser standard with a JavaScript API. MoQ is a network protocol — it defines how media moves between relays and endpoints, not how applications integrate with it. Browser support is coming, but not here yet for production use.

The Honest Protocol Comparison for Telemedicine

Neither protocol is superior in all dimensions. The comparison that matters is which one serves specific telemedicine use cases better — and where each one has real limitations.

The headline reading of this table: WebRTC is the right protocol for telemedicine production infrastructure today, and for the foreseeable future, for 1:1 and small group calls. MoQ becomes genuinely interesting for telemedicine use cases at the edges of what WebRTC handles well — large virtual care group sessions, AI-heavy workflows, and CDN-distributed health content delivery.

Where MoQ Actually Solves Real Telemedicine Problems

Problem 1: Group Telehealth at Scale

WebRTC SFUs work well for calls up to roughly 50 simultaneous participants with careful configuration. Above that, you’re fighting the architecture — forwarding individual tracks to each participant doesn’t scale gracefully, and mixing/transcoding adds cost and latency.

MoQ’s publish/subscribe model handles this naturally. A participant publishes one stream; the relay handles fan-out to any number of subscribers without the originating client doing additional work. For telemedicine use cases that involve large group sessions — virtual chronic disease support groups, family care conferences, health education broadcasts with live Q&A — MoQ’s architecture is genuinely superior.

The real-world analogy: running a 200-participant group therapy session over WebRTC requires engineering heroics. Over a mature MoQ relay infrastructure, it’s architecturally trivial.

Problem 2: AI Agent Integration Without Infrastructure Complexity

As we covered in our Voice AI + WebRTC article, adding AI agents to live telehealth calls currently requires SFU-level audio track extraction, custom media routing, and careful pipeline architecture. The AI is fundamentally a second-class citizen in the WebRTC model — it has to be plumbed in rather than naturally participating.

In MoQ, an AI processing pipeline is just another subscriber. It subscribes to the audio track it needs, processes it, and publishes its output back to the relay as a new track — exactly like a human participant would. The architectural simplicity here is significant, and it directly maps to where telemedicine AI is heading: ambient scribes, decision support agents, real-time translation, and voice triage bots all become cleaner to build and operate.

Problem 3: Poor Network Resilience for Rural and Underserved Patients

QUIC’s transport properties are genuinely better than the TCP underpinnings of WebRTC’s signaling and data channels in high-packet-loss, variable-latency network conditions. For telehealth platforms serving rural patient populations — where satellite internet, mobile data, and congested rural broadband are common — MoQ’s QUIC foundation could meaningfully improve call quality for the patients who most need reliable care access.

This isn’t a guaranteed win: QUIC’s benefits in lossy network conditions are real but not magical, and a well-configured WebRTC stack with adaptive bitrate handles poor networks reasonably well today. But MoQ’s architectural alignment with how QUIC works gives it structural advantages for the hardest network environments.

Problem 4: Multi-Party Recording and Compliance Infrastructure

Recording a multi-participant telehealth session in WebRTC requires either cloud-based composition (expensive) or server-side mixing (latency and cost). MoQ’s relay model enables a recording subscriber to receive all tracks independently and composite them asynchronously — cleaner, cheaper, and more flexible for the multi-track archival that clinical and compliance use cases increasingly require.

Where WebRTC Stays Superior for Telemedicine

It’s important to be direct about MoQ’s current and structural limitations in telemedicine contexts:

1:1 clinical calls will stay on WebRTC for years. The direct P2P WebRTC path for a two-participant telehealth session has latency characteristics that a relay-dependent protocol like MoQ can’t match in the near term. The sub-200ms latency of a well-established WebRTC P2P connection is genuinely difficult to beat when both parties are geographically proximate. For the dominant telemedicine use case — one patient, one clinician — WebRTC remains the right answer.

HIPAA compliance architecture is established for WebRTC. Healthcare organizations have worked through the BAA, security review, and compliance audit process for WebRTC-based platforms. MoQ infrastructure — particularly the relay model, which involves media passing through intermediate nodes — introduces new questions about data custody, encryption in transit, and PHI handling that the healthcare compliance community has not yet worked through. Early MoQ adopters in healthcare will be navigating genuinely unsettled ground.

The engineering talent gap is real. WebRTC engineers are abundant. MoQ expertise is currently concentrated in browser vendors, CDN companies, and a small number of streaming infrastructure specialists. Staffing a MoQ migration requires either a significant investment in training existing WebRTC engineers or competing for scarce specialists.

Browser support isn’t there yet. For a telemedicine platform where patients connect through a web browser with zero installation friction, protocol choices are constrained by what browsers support. MoQ browser support is experimental. Until it’s standard across Chrome, Firefox, and Safari, MoQ can only be used on the server-side infrastructure layer or in native apps where you control the client.

The Strategic Roadmap: What to Do Now

Trembit’s recommendation for telemedicine engineering leaders, by company stage:

If you’re building a new telehealth platform today: Build on WebRTC with a modern SFU (LiveKit is the current recommendation for most use cases). Design your media pipeline with a clean abstraction layer between your application logic and your media transport. Don’t couple your product code directly to WebRTC APIs — this is the architectural investment that will make a future MoQ migration tractable rather than a full rebuild. Follow the MoQ standardization process at IETF; the draft is public and readable.

If you’re running a production telehealth platform at scale, you have no action items on MoQ today. Continue optimizing your WebRTC infrastructure. Assign one engineer to monitor MoQ browser support developments — specifically Chrome’s WebTransport/MoQ implementation timeline. Revisit in 12 months. The earliest realistic timeline for MoQ to be viable for production telehealth web clients is late 2026 to 2027.

If you’re running large-scale group telehealth sessions (50+ participants), this is the one current use case where investigating MoQ infrastructure is worth engineering time today. Cloudflare’s MoQ relay and similar CDN-backed infrastructure are available for experimentation. A proof-of-concept for group session delivery over MoQ, run in parallel with your WebRTC production system, is a reasonable 2025–2026 project for exploration.

If you’re building heavily AI-integrated telehealth infrastructure: MoQ’s native pub/sub model for AI agent media access is architecturally compelling and worth prototyping. Not for production — for understanding whether the architectural simplicity justifies migration investment as the standard matures. Build the prototype on the server-side only (WebRTC for client-facing sessions, MoQ internally for AI pipeline media delivery) — this is a hybrid architecture that’s achievable today without browser support.

Trembit’s Position on MoQ for Telehealth

We explore protocol transitions carefully because our clients’ infrastructure decisions need to last longer than a product cycle. The shift from SIP/H.264 to WebRTC took the better part of a decade to complete in healthcare organizations that understood the transition early, made better architecture decisions than those who waited until WebRTC was obviously dominant.

MoQ is earlier in that curve than WebRTC was when most healthcare organizations started paying attention to it. The trajectory is clearer than WebRTC’s was at a comparable stage: IETF standardization is active and progressing, major CDN infrastructure is already deployed, and the use cases where MoQ is architecturally superior map directly to heading telemedicine— AI-integrated, large-group, globally distributed care delivery.

The right posture isn’t urgent. It’s informed readiness: build WebRTC infrastructure that can evolve, understand the MoQ architecture well enough to recognize when migration becomes justified, and avoid coupling decisions that will make the transition unnecessarily expensive.

That’s the engineering discipline Trembit brings to clients, navigating these decisions — not chasing every emerging protocol, but understanding protocol trajectories well enough to make infrastructure investments that age well.

If you’re thinking about the protocol architecture for a new telehealth platform build or evaluating how MoQ-ready your current stack is, Trembit’s engineering team is available for a technical consultation. [Talk to us → here]