Most telehealth vendors describe their video visits as "secure" and "HIPAA compliant" without explaining how the video actually gets from one browser to another. Underneath almost every modern telehealth product sits WebRTC, the browser standard for real-time audio and video. If you are building or buying a telehealth platform, understanding how WebRTC moves media, where it can fail, and what it does and does not do for HIPAA compliance will change how you evaluate vendors and specify requirements. This article walks through the architecture: signaling, NAT traversal, media server choices, and the encryption and transmission security questions that actually matter for protected health information.
What WebRTC Actually Does in a Telehealth Visit
WebRTC (Web Real-Time Communication) is a set of browser APIs and network protocols that let two devices exchange audio, video, and data directly, without a plugin and without routing media through a general-purpose application server. It is built into Chrome, Safari, Firefox, and Edge, which is why a patient can join a video visit from a browser link instead of installing an app.
A WebRTC session has two separate jobs that are easy to conflate:
- Signaling: the process of two devices finding each other, agreeing on media formats, and exchanging network information before a call starts.
- Media transport: the actual audio and video packets, which flow over a separate, encrypted path once signaling is complete.
This split matters because WebRTC intentionally leaves signaling undefined. Every telehealth platform, whether custom-built or purchased, has to make its own decisions about how signaling works, and those decisions affect reliability, scalability, and how much infrastructure you have to secure.
Signaling: The Part WebRTC Doesn't Standardize
Before two browsers can exchange video, they need to negotiate session details using the Session Description Protocol (SDP): which codecs are supported, what resolution to start at, and how to reach each other on the network. This negotiation, commonly called the offer/answer exchange, has to travel over some channel, and WebRTC does not specify what that channel is.
In practice, telehealth platforms run a signaling server, usually over WebSockets, that both the clinician's and patient's browsers connect to when a visit starts. The signaling server's job ends once the peer connection is established. This has two practical implications for architecture:
- The signaling channel is where waiting room logic, provider-to-patient matching, and session authorization typically live, so it needs the same access controls as any other part of your application handling protected health information (PHI).
- Signaling traffic should run over TLS. It is a common mistake to encrypt the media path (which WebRTC does automatically) while treating the signaling channel as lower risk. Signaling messages can include session identifiers, appointment metadata, and sometimes PHI in the payload, so it needs equivalent protection.
NAT Traversal: STUN, TURN, and Why Calls Drop
Most clinicians and patients connect from behind a router performing network address translation (NAT), often on hospital or corporate networks with restrictive firewalls. WebRTC uses the ICE (Interactive Connectivity Establishment) framework to find a viable path between two devices, and that framework depends on two kinds of helper servers:
- STUN servers tell a device its public IP address and port, which is usually enough for a direct peer-to-peer connection on typical home or office networks.
- TURN servers relay media when a direct connection cannot be established, which happens frequently behind symmetric NAT or on networks that block peer-to-peer UDP traffic, both common on hospital networks with strict egress rules.
A telehealth platform that only deploys STUN will see calls fail intermittently for a meaningful share of users, almost always on the networks with the tightest security policies, which in healthcare tends to mean hospital and clinic environments. TURN infrastructure adds latency (the relayed path is inherently longer than a direct one) and cost (you are now carrying bandwidth for every relayed call), but skipping it is not a viable option for a clinical product. Any vendor or architecture review should confirm TURN is deployed in more than one region, since a single TURN region becomes both a latency bottleneck and a single point of failure for every call that needs relaying.
Peer-to-Peer vs. SFU vs. MCU: Choosing a Media Architecture
Once connectivity is established, media needs somewhere to flow. There are three common patterns:
- Peer-to-peer (P2P): devices send media directly to each other. This works well for a single clinician and patient, keeps latency low, and avoids routing PHI-bearing media through your own servers. It does not scale past two or three participants, since each device has to upload a separate stream to every other participant.
- Selective Forwarding Unit (SFU): a media server receives one stream from each participant and forwards copies to everyone else, without decoding or re-encoding. This is the standard choice for group visits, care team consults, or any session with more than two or three participants, because each device only uploads once regardless of how many people are on the call.
- Multipoint Control Unit (MCU): a server decodes every incoming stream, mixes them into a single composite stream, and sends one stream back to each participant. This reduces client-side bandwidth and CPU load further, but the server must decrypt media to mix it, which adds a point where unencrypted PHI briefly exists in server memory. MCUs are rarely the right default for healthcare video given that tradeoff, and most modern platforms use SFU architecture even for larger sessions.
For a straightforward one-to-one telehealth visit, P2P is often sufficient and simplest to reason about from a security standpoint, since media never touches your infrastructure. For group therapy sessions, multi-provider consults, or any product roadmap that includes more than two participants, plan for an SFU from the start. Retrofitting group calling onto a P2P architecture later is a rebuild, not an extension.
Encryption and What HIPAA Actually Requires
WebRTC media is encrypted by design. Every session uses DTLS to negotiate keys and SRTP to encrypt the actual audio and video packets, and this is mandatory in the specification, not a configuration option an application can disable. The security architecture is documented in RFC 8827, the IETF's WebRTC security architecture standard. In practical terms, this means the media path between two browsers is encrypted whether you are using a custom build or a commercial platform.
Encryption in transit is necessary but not sufficient for a HIPAA-conscious telehealth build. The HIPAA Security Rule's technical safeguards, at 45 CFR 164.312(e), require covered entities and business associates to implement technical security measures to guard against unauthorized access to electronic PHI while it is being transmitted, with encryption listed as an addressable implementation specification. "Addressable" is frequently misread as "optional." It is not: an addressable specification means the organization must assess whether it is reasonable and appropriate given its environment, implement it if so, and document an equivalent alternative and the reasoning if not. For video visits carrying clinical information, it is difficult to construct a reasonable argument against encrypting the transmission, which WebRTC provides natively for the media path.
Where organizations run into trouble is everything adjacent to the media stream itself: the signaling channel, session recordings written to disk, chat messages sent alongside video, and screen-sharing of clinical documents. Each of these needs its own encryption and access control decisions; none of them are automatically covered by WebRTC's built-in media encryption. This is also a reminder that no software vendor, including Sabyrix, can label a product "HIPAA compliant" as a fixed attribute. Compliance depends on the full set of administrative, physical, and technical safeguards an organization implements, its business associate agreements, and how the software is actually configured and used. This article is not legal advice; validate specific compliance decisions with qualified counsel or a compliance specialist.
Build vs. Buy: Self-Hosted Media Servers vs. Managed Platforms
Teams building telehealth video generally choose between two paths:
- Self-hosted, open-source media servers (such as mediasoup, Janus, or Jitsi) give full control over infrastructure, data residency, and how media is handled, which matters for organizations with strict data locality or on-premises requirements. The tradeoff is that your team owns TURN infrastructure, SFU scaling, monitoring, and every security patch.
- Managed WebRTC platforms (commercial video APIs and SDKs) handle signaling, TURN, and SFU infrastructure for you, and several offer a business associate agreement as part of a paid tier, which is a prerequisite if PHI will flow through their infrastructure. The tradeoff is per-minute or per-participant cost that scales with usage, less control over exactly how media is routed, and a dependency on the vendor's own security posture.
Neither path is automatically the right answer. A small clinical team validating a new care model with a handful of daily visits is usually better served by a managed platform with a signed BAA, since the engineering cost of running production media infrastructure well exceeds the per-minute fees at that volume. A platform expecting tens of thousands of concurrent sessions, or one with specific data residency or on-premises requirements common in some health systems, has a stronger case for self-hosting, provided the team has the operational depth to run it reliably. Whichever path you choose, confirm in writing (not in marketing copy) whether a BAA is available and what it actually covers before any real patient data touches the system.
Recording, Transcription, and Expanding the Compliance Surface
Features that seem like small additions often expand what needs to be secured and logged. Session recording requires a decision about where encrypted recordings are stored, how long they are retained, who can access them, and typically explicit patient consent captured before the recording starts. Live transcription or AI-generated visit notes introduce a third-party processor that also needs a BAA if PHI passes through it. Chat and file sharing during a visit need the same encryption and access logging as the video itself.
Every one of these features should show up in your audit logs, recording who accessed a recording, when a transcript was generated, and who viewed it. If your team has not yet worked through audit log design for a healthcare application, it is worth reading through how to design audit logs that hold up under review before adding features that increase what needs to be tracked.
A Practical Architecture Checklist
Before committing to a telehealth video architecture, work through these questions:
- Is TURN deployed in multiple regions, and has it been tested from a real hospital or clinic network, not just a home office?
- Is the signaling channel running over TLS, and does it carry any PHI in its payload that needs the same access controls as the rest of the application?
- Does the expected participant count call for peer-to-peer, or does the roadmap already require an SFU?
- If using a managed platform, is a BAA actually available, and does it cover video, recording, and any AI or transcription add-ons separately?
- Where are recordings stored, how are they encrypted at rest, and who has access?
- Does every access to a recording or transcript generate an audit log entry?
Getting the architecture right the first time avoids a costly rebuild later, particularly the P2P-to-SFU migration, which touches signaling, client code, and server infrastructure all at once.
Sabyrix Technologies builds telemedicine platforms and works through this exact set of architecture and compliance tradeoffs with healthcare teams. If you are scoping a telehealth build, or evaluating whether an existing platform's video architecture holds up, book a strategy call or see our broader approach to security and HIPAA-conscious development.
Frequently Asked Questions
Is WebRTC itself HIPAA compliant?
WebRTC is a protocol, not a product, so compliance is not something it can claim on its own. What WebRTC provides is mandatory encryption of the media stream in transit. Whether a telehealth platform built on WebRTC supports HIPAA compliance depends on the signaling infrastructure, storage, access controls, business associate agreements, and organizational processes built around it.
Do I need TURN servers if most of my users have good internet?
Yes. TURN is not about bandwidth quality, it is about network topology. Hospital and clinic networks frequently use symmetric NAT or block peer-to-peer UDP traffic for security reasons, which breaks direct WebRTC connections regardless of how fast the underlying internet connection is.
Can I start with peer-to-peer and add group calling later?
Technically yes, but it typically means rebuilding the media layer rather than extending it, since P2P and SFU architectures handle connections, bandwidth, and signaling differently. If group visits are anywhere on the roadmap, it is usually cheaper to build on an SFU from the start.
What is the difference between encrypting media in transit and end-to-end encryption?
WebRTC's DTLS-SRTP encrypts media between each device and the server it connects to (or directly between two devices in a P2P call). In an SFU architecture, the media server can technically access decrypted streams unless additional end-to-end encryption is layered on top, which is a separate, more complex feature most telehealth platforms do not implement by default.