For a telemedicine platform, the SFU (Selective Forwarding Unit) choice comes down to three options: Janus (modular, plugin-based, the most control and the most self-build), mediasoup (a lower-level media-routing library for teams with deep WebRTC engineering capacity), or LiveKit (a complete platform with official SDKs and an optional managed cloud, the fastest path to a compliant production build). The honest verdict up front: all three can be deployed in a HIPAA- and GDPR-compliant way. Compliance is a property of how you deploy and operate the platform — encryption, access control, audit logging, Business Associate Agreements (BAAs), data residency — not a property inherent to any one SFU.
What is an SFU in telemedicine?
An SFU is a media server that receives each participant’s audio and video stream once and selectively forwards it to the other participants — without decoding and re-encoding the media, the way an MCU (Multipoint Control Unit) does. That “route, don’t re-encode” design is what keeps latency low and server CPU manageable, which is why every serious multi-participant telemedicine platform sits on an SFU rather than pure peer-to-peer WebRTC.
For a two-person consultation, plain peer-to-peer WebRTC can be enough — and in some regulated deployments it’s actively preferred, because keeping media off a central server simplifies the data-flow story for auditors (this is the model behind the KBV-certified WebPrax platform, discussed below). The SFU question becomes unavoidable the moment you add a third participant: group therapy, a multi-clinician case review, a supervised training session, or a consultation with an interpreter joining a patient and a clinician. At that point P2P’s mesh topology stops scaling — every participant would have to send their stream to every other participant — and you need a server that fans streams out efficiently.
For a clinical product, the SFU also becomes the natural place where compliance-relevant behavior lives: server-side recording for documentation, selective stream routing, and the logging of who joined which session and when. That is precisely why the SFU choice and the compliance architecture are entangled — and why this comparison is framed around deployment, not just features.
Janus — flexible and modular
Janus, built and maintained by Meetecho, is a general-purpose WebRTC server written in C, with a plugin-based architecture: the core handles the WebRTC transport (ICE, DTLS, SRTP), and plugins (VideoRoom, streaming, SIP gateway, recording) implement the actual application behavior. That design gives you the most granular control of the three — you can write or modify a plugin to do exactly what a clinical workflow needs, including non-standard recording or media-pipeline behavior that a higher-level platform would hide from you.
Is Janus still maintained? Yes. Janus is actively developed — Meetecho shipped v1.4.0 on 6 February 2026, with further tagged releases through April 2026, and treats the master branch as the only stable line, continuously patched. This matters for a telemedicine refresh decision: an unmaintained media server is a compliance liability (unpatched CVEs, no security fixes), so the maintenance question is a real gating check, not trivia.
What Janus’s architecture means for compliance. Because behavior lives in plugins, the compliance surface — audit logging, role-based access control, session-level authorization — is typically custom-built per deployment rather than provided out of the box. That’s an advantage for a team that wants full control over exactly what gets logged and retained, and a cost for a team that would rather inherit those controls. Janus is the strongest fit when you already have WebRTC engineering depth, you’re extending an existing Janus deployment, or your clinical product needs custom media behavior that off-the-shelf platforms don’t expose.
Mediasoup — powerful and scalable
Mediasoup is not a turnkey server; it’s a WebRTC SFU library: its media-routing core is a C++ worker (handling RTP/RTCP, SRTP, bandwidth estimation, and congestion control), which you drive through a Node.js or Rust application-layer API and build a media server around. It gives you fine-grained control over transports, producers, and consumers, and first-class support for simulcast and SVC (scalable video coding) — the mechanisms that let a session degrade gracefully when one participant’s connection is weak, which is common in remote and rural care. That control is why mediasoup scales well for larger multi-participant clinical sessions: group therapy, multi-clinician consults, and live clinical training.
The trade-off is engineering investment. Mediasoup hands you routing primitives, not room management, signaling, authentication, or recording — you build all of that. For compliance specifically, this means the entire compliance surface is your team’s responsibility: encryption configuration, access control, audit logging, retention. There is no vendor BAA conversation, because there is no vendor — mediasoup is self-hosted-only, and you are the only party touching PHI in the media path. For a team with the capacity, that’s an advantage: total control, no third-party subprocessor to vet or contract with. For a team without it, it’s the highest build burden of the three. Choose mediasoup when large-session scale and full control justify that investment.
LiveKit — comprehensive and developer-friendly
LiveKit is a complete real-time platform: an open-source SFU written in Go, plus official server and client SDKs (web, iOS, Android, React Native, and more), built-in room and session management, adaptive streaming, and server-side egress for recording. You can self-host it, or use LiveKit Cloud, the managed offering. Of the three, it is the fastest route to a working production telemedicine build, because the room, session, and SDK layers you’d otherwise write yourself are already there.
LiveKit Cloud’s compliance posture (verify at publish time). LiveKit publishes a list of HIPAA-eligible LiveKit Cloud services — realtime transport, ingress/egress (recording and export), agent hosting, and certain inference models — and requires an executed Business Associate Agreement before any Protected Health Information (PHI) flows through those services — BAA signing is gated to LiveKit’s paid Scale/Enterprise tiers.
One nuance worth stating plainly: self-hosting LiveKit does not, by itself, make you more compliant than using LiveKit Cloud. If you self-host LiveKit for data-residency or control reasons, you still build the same access-control and audit-logging layer you would with Janus or mediasoup — the managed-cloud BAA conversation is what’s different between the two LiveKit paths, not the self-hosted posture. Choose LiveKit when time-to-compliant-production matters most, you want official cross-platform SDKs, and either a vetted managed-cloud BAA is acceptable or a straightforward self-hosted path is preferred.
How do HIPAA, GDPR, and KBV requirements change the SFU decision?
This is where a telemedicine SFU decision diverges from a general-purpose one. The three most common regulatory regimes our healthcare clients face — HIPAA in the US, GDPR in the EU, and KBV for psychotherapy in Germany — don’t pick an SFU for you. But they do reshape the deployment model, and the deployment model is where the real decision lives. Here is what each one actually changes.
HIPAA (US): the SFU is fine; the subprocessor chain is the risk
Any of the three SFUs, self-hosted in a properly configured environment (encryption in transit and at rest, access control, audit logging), supports a HIPAA-compliant architecture. HIPAA does not certify software products — the HHS Office for Civil Rights is explicit that there is no official “HIPAA-compliant” seal for a product; compliance is a property of the covered entity’s or business associate’s overall safeguards.
The decision point HIPAA introduces is the subprocessor chain. The moment any managed or third-party component touches PHI — LiveKit Cloud, a TURN relay provider, a cloud recording or transcription service — you need a signed BAA with that subprocessor. Under the HIPAA Security Rule, a business associate that creates, receives, maintains, or transmits PHI on your behalf must be covered by a BAA.
The practical rule for the SFU decision: verify BAA availability before committing to any managed component. With self-hosted mediasoup there’s no external subprocessor in the media path at all; with LiveKit Cloud there is, and a BAA is required (LiveKit offers one — see above); with a Janus deployment, the SFU itself is yours, but any TURN or storage provider you add still needs its own BAA.
GDPR (EU): data residency outweighs the SFU choice
For EU deployments, the SFU features matter far less than where the media and metadata physically reside and who has access to them. GDPR restricts transfers of personal data (and health data is a special category under Article 9, with stricter conditions) outside the EU/EEA unless a valid transfer mechanism — such as Standard Contractual Clauses or an adequacy decision — is in place.
That reshapes the SFU decision in one clean way: self-hosting in-region (on EU-based infrastructure) sidesteps most cross-border transfer complexity. A US-headquartered managed cloud raises additional, solvable but real, questions around SCCs and where support/observability data flows. This is why self-hosted mediasoup, self-hosted Janus, or self-hosted LiveKit on EU infrastructure are the low-friction GDPR paths, while a managed US cloud component adds a transfer-assessment step you have to complete before go-live. It is not a reason to avoid managed cloud — it’s a reason to scope the data-residency and transfer question before the architecture is locked, not after an auditor asks.
KBV (Germany, psychotherapy): the strictest bar, and it can rule out the SFU entirely
KBV certification for psychotherapy telemedicine in Germany is the narrowest and strictest of the three regimes. It requires specific, audited technical and procedural controls beyond general HIPAA/GDPR compliance. In the KBV-certified build we know most directly (WebPrax, below), meeting the bar meant no third-party media routing at all — which rules out hosted WebRTC services and, in the strictest reading, an SFU that routes patient media through infrastructure the platform doesn’t fully control.
This is the case where the “which SFU” question can invert into a “should there be a routing SFU at all” question. Trembit built WebPrax Face2Face, the first psychotherapy video platform to achieve KBV certification in Germany, on peer-to-peer WebRTC deployed on Germany-only infrastructure (Hetzner), with STUN/TURN servers on the platform’s own premises and zero third-party media routing — reviewed by the Institut für Sicherheit und Datenschutz im Gesundheitswesen, and supporting group therapy sessions up to 20 participants.
The cross-cutting controls checklist — independent of which SFU wins
Regardless of which SFU you choose, the following controls are what actually make (or break) a compliant deployment. This is the checklist a CTO should walk through after the features comparison, not instead of it:
- Encryption — transport encryption (DTLS-SRTP) is built into WebRTC and non-negotiable; add encryption at rest for any recordings, transcripts, or logs. Confirm media is encrypted end-to-end where your regime requires it, not just terminated at the server.
- Role-based access control (RBAC) — enforce who can join, record, or view a session at the application layer. None of the three SFUs gives you clinical-grade RBAC out of the box; you build or configure it.
- Audit logging — immutable logs of session joins, recordings, and PHI access. With Janus and mediasoup this is custom-built; with LiveKit you extend what the platform emits.
- Data retention and deletion — a defined, enforced policy for how long recordings and metadata live and how they’re purged (GDPR’s storage-limitation and erasure rights make this mandatory, not optional).
- Subprocessor BAAs — a signed BAA with every third party that touches PHI (managed cloud, TURN provider, transcription, storage). If a component has no available BAA, it cannot be in the PHI path — full stop.
For a deeper walkthrough of the deployment side, see our guide to building HIPAA-compliant video consultations with WebRTC and LiveKit, and, on stabilizing a clinical video core before it goes to audit, from proof-of-concept to production.
When should a telemedicine platform choose Janus, mediasoup, or LiveKit?
- Choose Janus when your team needs custom, non-standard media-pipeline behavior — specialized recording or transcoding for clinical documentation, for instance — already has WebRTC engineering depth, or is extending an existing Janus-based deployment. Its plugin model rewards teams that want to own exactly what the media server does.
- Choose mediasoup when the platform must support large multi-participant clinical sessions at scale (group therapy, multi-clinician consults, clinical training) and you have the engineering capacity to build the surrounding room, auth, and compliance layer. It’s the most control and the most work.
- Choose LiveKit when time-to-compliant-production is the priority — a funded startup racing a launch or an audit deadline — you want official SDKs across web and mobile, and either a vetted managed-cloud BAA is acceptable or a clean self-hosted path is preferred.
For the general, non-healthcare production decision between LiveKit and mediasoup — team shape, time-to-market, operational cost, and LiveKit’s Agents ecosystem — see our full LiveKit vs. mediasoup production comparison.
Why choose Trembit for your telemedicine SFU build?
We’ve deployed every major media server architecture — Janus, mediasoup, LiveKit, Jitsi, and Kurento — across 50+ video/voice implementations over 15+ years, and we debug at the SDP, ICE, and SRTP layer rather than configuring a wrapper SDK. For telemedicine specifically, that protocol-level depth is what lets us answer the compliance question honestly instead of with a checkbox.
It’s also what makes us a rescue team, not just a build team. When a clinical video platform is failing an audit or buckling under load, the hard part is diagnosing whether that’s a media-server configuration problem or an architecture problem — the two get confused constantly, and the difference decides whether the fix is days or a rebuild. Trembit inherits and fixes telemedicine platforms other teams couldn’t get to compliant production; the rescue conversation starts the same place a greenfield one does — an architecture assessment.
The credential that matters most here: Trembit is KBV-certified for psychotherapy telemedicine — we designed, built, and supported the certification of WebPrax Face2Face, the first psychotherapy video platform to achieve KBV certification in Germany, reviewed by the Institut für Sicherheit und Datenschutz im Gesundheitswesen. [Confirmed against internal offering docs] KBV is the most restrictive healthcare video standard in Europe and rare among WebRTC teams, and the experience transfers directly to HIPAA and GDPR work.
The honest positioning we’ll give any telemedicine team: the right SFU depends on your compliance posture and your team, not on which project markets itself best. We’ve built and rescued production telemedicine platforms on all three of the SFUs compared here — and if a hosted CPaaS actually fits your case, we’ll tell you that too. When you’re ready to scope it, our telemedicine app development and WebRTC consulting teams can take it from architecture assessment through certification. If you’re starting from a blank page and want to compress time-to-market, our white-label telemedicine platform gives you a compliance-ready foundation.
Conclusion
Janus, mediasoup, and LiveKit are all capable foundations for a telemedicine platform, and all three can be deployed HIPAA- and GDPR-compliant. The decision is less “which SFU is best” and more “which deployment model fits our compliance requirements and our team’s capacity” — Janus for maximum control, mediasoup for large-session scale with full ownership, LiveKit for fastest time-to-compliant-production. Get the compliance framing right first — data residency, subprocessor BAAs, audit logging — and the SFU choice follows from it, not the other way around.
If your build doesn’t carry healthcare-compliance requirements, our general LiveKit vs. mediasoup production comparison covers the non-vertical decision in depth. [verify sibling is live before publishing this link]
Building or rescuing a telemedicine platform that has to pass a HIPAA, GDPR, or KBV audit — not just claim compliance? We’ve built compliant production telemedicine on Janus, mediasoup, and LiveKit, taken a psychotherapy platform through KBV certification, and inherited stalled clinical builds and gotten them audit-ready. Get a free architecture assessment — a working session with an engineer, not a sales call: we’ll review your current infrastructure against your certification requirements and tell you exactly where the gaps are. No obligation.
