WebRTC for Telemedicine and Telehealth: 4 Clinical Gotchas

Updated October 2026: a short answer up front, a new section on where WebRTC is used in healthcare (interpreters under Section 1557, tele-stroke, RPM, AI scribes), an FAQ, the HIPAA Security Rule final-rule target moved to July 2027, Medicare telehealth extended through 2027, and TURN prices rechecked.

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Short answer. WebRTC is the default technology for telemedicine and telehealth video because it runs an encrypted, sub-second video visit inside the patient’s browser with nothing to install, and because it is a free open standard (a W3C Recommendation, current edition March 2025) that nearly every major video API is built on. It does not make a product HIPAA compliant on its own, and four things decide whether a WebRTC telehealth build ships on time: TURN relay cost, hospital firewalls, recording, and the third participant who forces a media server.

If you are a founder, product manager, or hospital IT lead scoping a telemedicine build, "we'll use WebRTC" will appear in the first technical conversation — and it is the right call. What that sentence hides is everything around the standard: the relay servers, the firewall behavior of real clinics, the missing record button, and the point where peer-to-peer quietly becomes the wrong architecture. Those four items, not the video call itself, are where telemedicine video projects slip by months. This article is the anchor for the whole architecture block of this course: read it first, then go deeper per topic. By the end you should be able to ask a vendor or an engineering team exactly the questions that expose whether they have built clinical video before.

What WebRTC is, in plain language

A video call needs three things: capture the camera and microphone, move the audio and video to the other person with minimal delay, and do both securely. Before 2012 or so, that required installing software — a desktop app, or a browser plugin like Flash. The plugin era ended for good when Adobe retired Flash at the end of 2020 [7].

The technology that replaced it is Web Real-Time Communication, or WebRTC: a set of capabilities built into the browser itself that lets a web page capture media and stream it to another device in real time. Think of it as a phone line built into the browser tab. The page you open is the calling application; there is nothing else to install.

Two details matter for what comes later. First, WebRTC is an open standard, not a product. The browser-facing part is a W3C Recommendation — the web's formal standards body published it in January 2021 and continues to maintain it, with the current edition dated March 2025 [1]. The network protocol side is specified by the IETF, the body that standardizes internet protocols, in RFC 8825 and its companion documents [2]. Nobody licenses WebRTC to you, and nobody can take it away — which is exactly what you want under a product with a 10-year compliance lifetime.

Second, WebRTC is a component, not a platform. The standard gives you the call. It deliberately does not give you signaling (how two browsers find each other), user accounts, scheduling, recording, or any of the clinical workflow around the call. The phrase you will hear from engineers is that WebRTC is free like a puppy: the standard costs nothing, and then you feed it infrastructure for the rest of its life. A working consult also needs a signaling service, usually one or two kinds of helper servers, and — for anything beyond two participants — a media server. The anatomy of a telemedicine platform article maps where all of those live; this one focuses on the video layer itself.

For the protocol internals — how session descriptions are exchanged, how candidates are gathered, what an SFU does packet by packet — our Video Streaming section has the deep dives: start with WebRTC explained. Here we stay on the clinical application.

Why WebRTC won clinical video

Four properties, each of which maps to a clinical requirement.

1. The patient installs nothing

A telemedicine visit has a property most software does not: the user may use it exactly once, under stress, on whatever device they own. A 72-year-old patient with a new diagnosis is not a person you ask to download an app, create an account, and grant camera permissions in a settings menu. Every extra step before the consult costs show-rate: the patient who cannot get the software working becomes a no-show, a rebooked slot, and a support call.

WebRTC removes the steps. The patient taps a link in a text message or an email, the browser opens, the browser asks one question — "allow camera and microphone?" — and the visit starts. One detail founders often miss: browsers only expose camera and microphone capture to pages served over HTTPS (a rule called secure contexts), so the encrypted-web requirement is enforced by the browser before your compliance team ever asks [1]. Browser-first telehealth products — Doxy.me is the best-known example — built their entire pitch on this no-download flow, and every major video API (Twilio, Vonage, Daily, Agora, LiveKit) is WebRTC under the hood [10].

Support for the standard is effectively universal: Chrome and Firefox have shipped it since 2013, Safari since version 11 in 2017, and Edge in its modern form since 2020 [1][2]. For a patient population, that means the browser they already have is the client you support.

2. Sub-second latency, because a consult is a conversation

Latency is the delay between one person speaking and the other person hearing it. For one-way video — a webinar, a sports stream — several seconds of delay is invisible. For a conversation it is fatal: people start talking over each other, pausing awkwardly, and repeating themselves.

The standards body for telephony, the ITU, quantified this decades ago in Recommendation G.114: one-way delay up to about 150 milliseconds feels natural, and beyond 400 milliseconds is unacceptable for interactive speech [6]. Walk through what that budget means. A milliseconds budget of 150 must cover capturing the frame, compressing it, crossing the network, decompressing, and rendering:

capture + encode ≈ 20–40 ms
network transit  ≈ 30–80 ms (same continent)
jitter buffer + decode + render ≈ 30–60 ms
total            ≈ 80–180 ms one way

WebRTC is engineered for exactly this: glass-to-glass delay typically lands under 500 milliseconds and often under 200 on decent networks. Streaming protocols built for one-to-many delivery sit in a different league entirely — standard HLS runs 6–30 seconds behind live, and even its low-latency variant runs 2–5 seconds [2]. A clinician cannot conduct an exam over a 6-second delay; they cannot even say "does it hurt when I press here?" and watch the reaction. This is why no serious telemedicine product runs consults over a streaming protocol, and why the protocol choice is not actually a choice.

Figure 1. The latency ladder. A live consult must stay inside the conversational band defined by ITU-T G.114; only real-time protocols like WebRTC do.

Where the clinical bar sits per specialty — and when dermatology or tele-stroke needs more than "good enough" — is covered in latency, quality, and the clinical bar.

3. Encryption is mandatory — but encryption is not compliance

WebRTC has no unencrypted mode. The standard requires that all media be carried over SRTP, the secure variant of the real-time transport protocol, with encryption keys negotiated through DTLS — a TLS-style handshake performed directly between the endpoints (RFC 8827; the underlying mechanisms are RFC 3711 and RFC 5763/5764) [3]. In plain terms: the audio and video are encrypted from one end of each network hop to the other, and an implementation that skipped this would not be WebRTC and would not interoperate with any browser.

That is a real head start on the HIPAA Security Rule, the part of US health-data law that dictates technical safeguards for electronic patient data. Protected Health Information, or PHI — any health data tied to an identifiable person — triggers the rule the moment it crosses the wire, and a video of a patient's face discussing symptoms is PHI. The Security Rule's transmission-security standard (45 CFR §164.312(e)(1)) asks for exactly the guard WebRTC ships by default [4].

It is also where teams overreach. Encryption in transit is one safeguard out of five in §164.312; the others — access control, audit controls, integrity, and person-or-entity authentication — live entirely in the application you build around WebRTC [4]. And no protocol can sign a contract: every vendor whose servers touch PHI on your behalf needs a signed Business Associate Agreement (BAA) — the written promise health-data law requires before a contractor may handle patient data — regardless of how well the bytes were encrypted in flight. Since the COVID-era enforcement discretion ended (May 11, 2023, with the transition period closing August 9, 2023), "we used an encrypted video tool" without a BAA is simply a violation [5].

Table 1. WebRTC covers one row well. The other four are your product. The full mapping is in HIPAA for telemedicine product teams and encryption in transit, at rest, end to end.

One regulatory note worth tracking: the proposed update to the Security Rule (published January 6, 2025) would make encryption in transit and at rest explicitly mandatory rather than "addressable." As of October 2026 it is still a proposed rule, not final law: the 2026 Unified Agenda moved the target for a final rule from May 2026 to July 2027, and HHS’s own Security Rule summary still describes the rule currently in effect [4][13]. WebRTC-based architectures already clear the in-transit half by construction, so designing to the stricter version now costs little.

4. It is the ecosystem, not just the protocol

Standards win on network effects. Because WebRTC is the browser's only real-time media API, every video API vendor builds on it, every SFU (the media-server type most telemedicine platforms use) speaks it, and every WebRTC engineer you hire transfers across stacks. The practical consequence for a buyer: choosing WebRTC does not lock you to a vendor. A platform built on a managed video API can later migrate to an open-source media server — mediasoup, Janus, LiveKit — without changing what runs in the patient's browser. That migration story is the subject of choosing the video layer: build vs buy, and it is a real option precisely because the standard underneath is shared. Vendor churn is also real — Twilio announced the end-of-life of its Video API in 2023 and reversed the decision in October 2024 [10] — and an open standard is your insurance policy against it.

How a consult actually connects

It helps to see the moving parts once, end to end, before we get to what breaks. When patient and provider click "join": the browsers exchange connection offers through your signaling server (an HTTPS/WebSocket service you run — this is where authorization happens); each browser gathers candidate network paths with the help of a STUN server, which simply tells a device what its public address looks like from outside; the ICE procedure (RFC 8445) tries those paths in pairs until one works, falling back to a TURN relay if none do; a DTLS handshake establishes keys; and encrypted media starts to flow [2][3]. On a good network the whole sequence takes one to three seconds — which is also why the pre-call tech check belongs in the waiting room, not at the moment the clinician joins.

Figure 2. The first seconds of a consult. Signaling finds the other side, ICE finds a network path, DTLS establishes keys, then encrypted media flows — directly if possible, through a TURN relay if not.

That is the why. Now the four places where clinical reality bites.

Gotcha 1 — TURN: the relay you forgot to budget

Most home and clinic networks sit behind NAT — network address translation, the router feature that lets many devices share one public address. Two devices behind NATs often cannot reach each other directly; it is like two people trying to mail letters using only apartment numbers, with no building address. STUN solves the easy cases by telling each device its public-facing address. The hard cases — strict NATs, symmetric NATs, networks that block the direct path — need TURN: a relay server with a public address that forwards the media between the two parties. TURN is the post-office forwarding address the call falls back to when no direct route exists (the current protocol specification is RFC 8656) [2].

Three facts about TURN drive real budgets.

First, you cannot ship without it. Industry measurements have been stable for years: expect somewhere between 5% and 20% of sessions to be unable to connect directly, varying with geography, carrier, and network strictness [9]. A telemedicine service that deploys without TURN simply fails for that slice of patients — and the slice is biased toward exactly the networks healthcare cares about: hospitals, clinics, corporate guest Wi-Fi, and cellular carrier-grade NAT.

Second, relayed media is metered media. A TURN server forwards every packet of a call, both directions, for the relayed party. The arithmetic, out loud. A typical 720p consult stream runs about 1.5 Mbps each way. A 20-minute consult moves, per direction:

1.5 Mbps × 60 s × 20 min = 1,800 megabits ≈ 225 MB
both directions through the relay ≈ 450 MB per relayed consult

Now scale it. Say your platform runs 10,000 consults a month and 15% relay:

10,000 × 15% = 1,500 relayed consults
1,500 × 0.45 GB ≈ 675 GB of relayed traffic per month

On a managed TURN service at list price — Twilio's Network Traversal Service charges $0.40/GB for US-located relays (list price rechecked October 2026; Asia-Pacific and South America run $0.60–0.80/GB) — that is 675 × $0.40 ≈ $270 per month [8]. Modest. But the same fleet on a locked-down enterprise estate, where relay rates of 60–70% are routinely observed, turns into 3,150 GB and $1,260 per month — for the relay alone, before a single media-server or recording dollar. Prices vary an order of magnitude across providers (Cloudflare Realtime lists $0.05/GB of egress with the first 1,000 GB a month free, shared between its TURN and SFU, October 2026 [8]), and self-hosting the open-source coturn server on a cloud VM with bundled egress is often cheaper still at volume — at the cost of operating it yourself. The point of the arithmetic is not the specific dollars; it is that relay percentage × minutes × bitrate is a line item you can and should forecast during the cost model stage, not discover on the first invoice.

Third, TURN sits inside your compliance boundary. A TURN relay forwards packets that are already DTLS-SRTP encrypted, and it does not hold the keys — so one school of thought treats it like a dumb pipe. The conservative reading, which this course recommends and the compliance architecture pattern explains in detail, is to treat any server in the media path as inside the PHI boundary: use a TURN provider that signs a BAA, or self-host TURN inside your own covered environment. Common mistake: copying a free public TURN/STUN credential set from a tutorial into production. You have just routed patient consultations through an unknown third party's server with no contract, no BAA, and no uptime promise — and because the failure is invisible when the direct path works, it surfaces months later, on exactly the patients with the worst networks.

Gotcha 2 — Hospital and clinic networks are built to stop you

The demo works at the office. Then the pilot starts at a hospital, and 40% of provider-side calls fail or arrive with relay-grade latency. Nothing is broken; the hospital network is doing its job.

Clinical networks are among the most restrictive environments WebRTC encounters. The pattern, observed across deployments: UDP — the fast, connectionless transport WebRTC prefers for media — is blocked outright except for named services; outbound traffic must pass a proxy or deep-packet inspection; and only TCP ports 80 and 443 (web browsing) are reliably open [9]. Home networks add their own obstacles: hotel and dorm Wi-Fi, cellular carrier-grade NAT, ISP-supplied routers with aggressive defaults.

The engineering answer is a graceful ladder of fallbacks, and your platform must implement all of it: try direct UDP; fall back to TURN over UDP; then TURN over TCP; and finally TURN over TLS on port 443 — media wrapped to look like ordinary secure web traffic, which traverses almost everything (TURN's TCP and TLS modes are part of RFC 8656) [2]. Each step down the ladder adds latency and jitter sensitivity, which is why it is a fallback ladder and not a default. The deployment-side answer is just as important: for fixed clinical sites, work with hospital IT before go-live to allowlist your TURN and media-server addresses, request UDP exceptions for them, and put quality-of-service rules on consult traffic. A pre-call network test in the waiting room — run while the patient still has time to switch from clinic Wi-Fi to cellular — converts hard failures into recoverable ones; connection reliability covers the full playbook, and the protocol mechanics live in the Streaming section's ICE, STUN and TURN deep dive.

Figure 3. The fallback ladder on a locked-down clinical network. Each step trades latency for reachability; TLS on 443 is the path of last resort that almost always works.

Common mistake: testing the pilot only on the engineering team's office network and the founder's home fiber. The populations a telemedicine product serves — rural patients (roughly a third of rural Americans lack broadband adequate for video visits [11]), elderly patients on old devices, clinicians inside hospital firewalls — are precisely the networks your office does not have. Test on hostile networks first; the good ones will take care of themselves.

Gotcha 3 — The recording problem: WebRTC has no record button

In consumer video, recording is a feature. In telemedicine it is an architectural fork, and WebRTC deliberately does not make the choice for you: the standard defines how two endpoints exchange encrypted media, and nothing else. There is no server in the loop by default, hence nothing in the middle to press record.

You have three options, each with a compliance shadow. Record client-side in the browser (the MediaRecorder API) and upload — fragile on exactly the low-end devices and networks telemedicine serves, and the recording exists unencrypted-at-rest on the patient's or provider's device until handled. Record server-side by routing the call through a media server (an SFU) that writes streams to storage — the production-grade answer, and the moment you do it, that server and that storage are squarely inside the PHI boundary: BAA-covered, encrypted at rest, access-controlled, audit-logged. Or use a managed video API's recording feature — the same server-side architecture, wearing a vendor badge, with the BAA question delegated to the contract.

Note what the server-side answer quietly changed: the call is no longer peer-to-peer, even for a 1:1 consult. That has knock-on effects — the media server's region affects latency and data-residency, and a true end-to-end-encryption posture (where even your own servers cannot read media) directly conflicts with server-side recording, a tension the E2EE article takes apart. Recording also drags in the legal layer — consent that varies by state, retention schedules, who may replay — which belongs to patient consent, recording, and data retention, and the full recording architecture is its own article in this block. The point for an anchor article is the planning one: "do we record?" is not a feature toggle to defer — it decides your topology, your vendor shortlist, and a slice of your compliance surface, so answer it in week one.

Gotcha 4 — P2P stops at two: the third participant changes the architecture

Peer-to-peer is WebRTC's superpower for a 1:1 consult: lowest latency, no media server to run, media that never touches your infrastructure. Then someone clinically unremarkable happens: an interpreter joins. Or an adult child joins a parent's visit from another city, or a supervising physician drops in on a resident's consult, or group therapy needs eight participants. Multi-party is not an edge case in telemedicine; it is Tuesday.

Without a media server, multi-party means full mesh: every participant encodes and uploads a separate copy of their video to every other participant. The upstream arithmetic kills it. At 1.5 Mbps per stream:

2 parties: 1 × 1.5 = 1.5 Mbps up per person   — fine
3 parties: 2 × 1.5 = 3.0 Mbps up per person   — strains home uplinks
4 parties: 3 × 1.5 = 4.5 Mbps up per person   — exceeds many; phones throttle, fans spin

Many residential connections offer 5–10 Mbps upstream on a good day, and each extra encode burns CPU and battery on the cheapest device in the call — which in telemedicine is the patient's. The standard answer is an SFU, a selective forwarding unit: each participant uploads one stream to the server, and the server forwards copies to everyone else. Upstream stays flat at one stream regardless of party size; the cost moves to server bandwidth, which you can buy. The P2P, SFU, MCU topology article maps which topology fits which clinical session type, and multi-party and multi-role consults covers the roles, permissions, and interpreter channels on top.

Figure 4. Why the third participant forces a media server. Mesh multiplies every participant's upload; an SFU holds it flat at one stream.

There is a second, less obvious reason production telemedicine platforms route even 1:1 calls through an SFU: visibility and control. A pure P2P call gives your operations team almost nothing — no server-side quality metrics, no recording point, no way to apply regional routing. Routing through an SFU gives you call-quality telemetry to act on (and to feed audit logging), a recording point when consent allows, and one consistent architecture for 1:1 and multi-party instead of two divergent code paths. The trade is server cost and a few tens of milliseconds. Most teams that have shipped clinical video at scale take that trade, and the reference architecture at the end of this block assumes it.

WebRTC against the alternatives

The comparison founders actually need is not "WebRTC vs some other RTC stack" — for browser-based real-time video there is no other browser-native stack — but WebRTC against the adjacent technologies that keep getting proposed in scoping meetings.

Table 2. The adjacent technologies and where each one belongs. The clinical consult itself has one defensible answer.

The last row matters: the alternatives are not competitors, they are complements. A complete telemedicine platform often ships WebRTC for consults, HLS for a one-to-many education stream, and PSTN dial-in as the last-resort fallback — because the patient whose network defeats even TURN-over-TLS still deserves their appointment, and because synchronous video is only one of three telemedicine modalities anyway. Telehealth demand is concentrated where conversation quality matters most: in 2025 data, telehealth delivered around 44% of behavioral-health visits among traditional Medicare beneficiaries, against roughly 9% of primary-care visits [12] — and a therapy session is nothing but conversation, which is the latency argument made clinical. The policy floor under that demand is firmer than a year ago: the Consolidated Appropriations Act, 2026 (H.R. 7148, February 2026) extended Medicare’s telehealth flexibilities, including visits from the patient’s home and the waiver of in-person requirements for behavioral health, through December 31, 2027, and the DEA and HHS extended telemedicine prescribing of controlled substances through December 31, 2026 [14][15]. That second date is about ten weeks away as this is written, so a prescribing workflow should have a plan for either another extension or a permanent DEA rule.

Where WebRTC is used in healthcare

WebRTC in healthcare is wider than the scheduled video visit: the same browser stack carries interpreter calls, specialist consults to a bedside cart, live device data next to the video, and AI scribes that join the call. Each use case moves one of the four gotchas from “later” to “week one”.

Table 3. Where WebRTC shows up in healthcare and which gotcha each use case pulls forward. Deeper dives: tele-stroke and tele-ICU, specialty visual consults, HL7 FHIR and EHR integration, ambient clinical documentation and AI scribes.

One US rule turns call quality into a legal obligation. A provider that receives federal funding and uses video remote interpreting must deliver real-time, full-motion video and audio with no lags, choppy, blurry or grainy images or irregular pauses, a picture large enough to show both the interpreter’s and the patient’s faces, and clear voices (45 CFR §92.201(f), the 2024 Section 1557 rule) [16]. For an interpreter call, the TURN budget, the firewall ladder and the SFU in this article are how you meet that sentence.

Design for the asymmetry of the two ends as well. Clinicians usually join from a managed desktop browser on a hospital network; patients join from a phone after tapping a text-message link, and on an iPhone that usually means Apple’s WebKit engine whatever browser icon they tap. Test the patient side on the oldest iPhone and the cheapest Android your population uses, on cellular, before you test anything else.

WebRTC for telemedicine: frequently asked questions

Is WebRTC good for telemedicine?

Yes. WebRTC is the standard choice for telemedicine video because it runs in the browser with no install, keeps delay under half a second and encrypts all media by default. The work is in what surrounds it: TURN relays, firewall fallbacks, recording and a media server for three or more people.

Is WebRTC HIPAA compliant?

WebRTC encrypts media in transit by design (DTLS-SRTP, RFC 8827), which covers the transmission-security safeguard of 45 CFR §164.312. HIPAA compliance also needs access control, audit logs, authentication and a signed BAA with every vendor whose servers touch the call, including TURN and media servers.

Do I need a TURN server for telehealth video?

Yes. Expect 5–20% of sessions to need a TURN relay on ordinary networks and far more behind hospital firewalls. At Twilio’s US list price of $0.40/GB (October 2026), a relayed 20-minute 720p consult moves about 0.45 GB, roughly $0.18 per consult.

What are WebRTC services for telehealth?

They are managed video APIs (Twilio, Vonage, Daily, Agora, LiveKit Cloud) that run the signaling, TURN and media servers for you, as opposed to open-source servers such as mediasoup, Janus or LiveKit that you host yourself. Use one only if the vendor signs a BAA; the trade-offs are in build vs buy for the video layer.

Can WebRTC record a telehealth visit?

Not on its own: the standard has no recording function. Production recording routes the call through an SFU that writes encrypted files to storage, which puts that server and that storage inside your HIPAA boundary, together with consent and retention rules.

How many people can join a WebRTC telehealth call?

Two people work peer-to-peer. From three participants (an interpreter, a family member, a supervisor) you should use an SFU, which keeps each person’s upload at one stream and scales a session to dozens of participants.

Is WebRTC used in healthcare beyond video visits?

Yes. It carries interpreter calls, tele-stroke and tele-ICU consults, group therapy, live remote-monitoring data over RTCDataChannel and audio for AI scribes. Each use case changes the architecture differently, as Table 3 shows.

What this means for your build

Pull the four gotchas together and a scoping picture emerges. The WebRTC standard costs you nothing and solves the hardest problem — real-time encrypted media in any browser. Everything around it is your project: a signaling service with real authorization, STUN/TURN with a BAA or self-hosted, an SFU once you record or seat three people, the fallback ladder for hostile networks, and the audit-and-consent layer HIPAA expects. None of it is exotic; all of it is work that belongs in the estimate. As a rule of thumb from our own scoping practice: the visible video call is roughly a fifth of a telemedicine platform's engineering effort, and the four gotchas above predict most of the rest of the video layer's share. Whether you assemble it from a managed video API or build on open-source media servers is the next decision — build vs buy — and the cost model article turns it into numbers.

To make the gotchas actionable, we condensed them into a one-page pre-flight: fifteen checks across TURN budgeting, hostile-network testing, the recording decision, topology, and the compliance boundary. Download the WebRTC telemedicine pre-flight checklist and run it against your architecture before the first sprint.

Where Fora Soft fits in

Fora Soft has built real-time video products since 2005 — video conferencing, streaming, surveillance, e-learning, and telemedicine — and WebRTC has been our daily tool since it shipped in browsers. In telemedicine specifically, the requirement comes first: we design the consult flow around the HIPAA boundary (BAA-covered TURN and media servers, audit logging, consent-aware recording) and then make it survive real networks — hospital firewalls, rural broadband, elderly patients' devices. That ordering — compliance first, then reliability, then features — is what this section of Learn teaches, because it is what we do on projects. If you are scoping a telemedicine platform and want the gotchas priced before they become surprises, talk to our telemedicine software development team; for the video layer itself, our AI telehealth video platform development on WebRTC covers HIPAA-grade calls on WebRTC and LiveKit, EHR integration over FHIR and AI scribes. If you already run a product and the open question is topology (P2P, SFU, regions, where recording sits), our custom WebRTC architecture team reviews and redesigns it.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook, 9,000+ pages, that works through the whole video stack from the pixel to production — encoding, delivery, audio and AI — and a WebRTC consult touches every layer of it. Start with volume 3: WebRTC and real-time delivery, player recovery and QoE monitoring. Volume 2 covers what the network does to a call — NAT, TCP against UDP, congestion control — which is the ground under TURN and the hospital firewall ladder, and volume 5 covers the jitter buffer, loss concealment, FEC and recording that decide how the consult sounds on a bad link. Work through the series and you can design and build the video layer of a telemedicine platform yourself. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. W3C — WebRTC: Real-Time Communication in Browsers, W3C Recommendation (first published 2021-01-26; current edition 2025-03-13), https://www.w3.org/TR/webrtc/ — browser API standard; secure-context requirement for media capture. Tier 1.
2. IETF — RFC 8825 Overview: Real-Time Protocols for Browser-Based Applications (2021); RFC 8445 ICE (2018); RFC 8656 TURN (2020, incl. TCP/TLS transports); RFC 8831 WebRTC Data Channels (2021), https://www.rfc-editor.org/ — protocol suite, NAT traversal, relay fallback. Tier 1.
3. IETF — RFC 8827 WebRTC Security Architecture (2021); RFC 3711 SRTP (2004); RFC 5763/5764 DTLS-SRTP (2010) — mandatory encrypted media; no unencrypted mode in WebRTC. Tier 1.
4. eCFR / HHS — 45 CFR §164.312 Technical safeguards (access control, audit controls, integrity, authentication, transmission security), https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312; HHS — HIPAA Security Rule To Strengthen the Cybersecurity of ePHI (NPRM), 90 FR 898, 2025-01-06, RIN 0945-AA22 — still proposed, not final, as of 2026-10-20. Tier 1.
5. HHS Office for Civil Rights — Notification of Enforcement Discretion for Telehealth Remote Communications, https://www.hhs.gov/hipaa/for-professionals/special-topics/emergency-preparedness/notification-enforcement-discretion-telehealth/index.html — discretion ended 2023-05-11; transition ended 2023-08-09. Tier 1.
6. ITU-T — Recommendation G.114 One-way transmission time (05/2003) — ≤150 ms one-way preferred for conversation; >400 ms unacceptable. Tier 1.
7. Adobe — Adobe Flash Player End of Life announcement (EOL 2020-12-31), https://www.adobe.com/products/flashplayer/end-of-life.html — the end of the plugin era. Tier 4.
8. Twilio — Network Traversal Service Pricing, https://www.twilio.com/en-us/stun-turn/pricing — TURN $0.400/GB (US/Germany), $0.600/GB (Singapore/India/Japan), $0.800/GB (Australia/Brazil), checked 2026-10-20; Cloudflare — Realtime TURN pricing, https://developers.cloudflare.com/realtime/sfu/pricing/ — $0.05/GB egress, first 1,000 GB/month free, shared between TURN and SFU, checked 2026-10-20. List prices; re-verify at publication. Tier 4.
9. BlogGeek.me (Tsahi Levent-Levi) — WebRTC TURN: Why you NEED it and when you DON'T need it, https://bloggeek.me/webrtc-turn/ — 5–20% of sessions require TURN; TURN-over-TCP/TLS shares; restrictive-network behavior. Industry measurement, not a standard. Tier 6.
10. Twilio — Twilio Video product changelog (EOL announced 2023-12; reversal published 2024-10-21), https://www.twilio.com/en-us/changelog — CPaaS churn risk; WebRTC as the common substrate of CPaaS video APIs. Tier 4.
11. AMA — Why so many patients still can't connect to doctors via telehealth, https://www.ama-assn.org/practice-management/digital-health/why-so-many-patients-still-can-t-connect-doctors-telehealth — ~33% of rural Americans lack broadband adequate for video visits. Tier 5.
12. Medical Economics — Medicare telehealth boom hasn't driven more visits, study finds (2025), https://www.medicaleconomics.com/view/medicare-telehealth-boom-hasn-t-driven-more-visits-study-finds — telehealth ≈44% of behavioral-health visits vs ≈9% of primary-care visits among traditional Medicare beneficiaries. Tier 5.
13. HIPAA Journal — HIPAA Updates and HIPAA Changes in 2026 (updated 2026-10-19), https://www.hipaajournal.com/hipaa-updates-hipaa-changes/ — Security Rule NPRM still not final; 2026 Unified Agenda target for the final rule moved from May 2026 to July 2027. Tier 5.
14. Telehealth.org — Medicare Telehealth Policy in 2026: Extensions, https://telehealth.org/news/federal-telehealth-policy-in-2026-what-the-medicare-extensions-mean/ — Consolidated Appropriations Act, 2026 (H.R. 7148) extends Medicare telehealth flexibilities (home as originating site, geographic waiver, behavioral-health in-person waiver) through 2027-12-31. Tier 5.
15. Holland & Knight — DEA and HHS Extend Telemedicine Prescribing Flexibilities Through 2026 (2026-01-13), https://hklaw.com/en/insights/publications/2026/01/dea-and-hhs-extend-telemedicine-prescribing-flexibilities-through-2026 — fourth temporary rule; flexibilities through 2026-12-31. Tier 5.
16. eCFR — 45 CFR §92.201(f) Video remote interpreting services (Section 1557 final rule, 2024), https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-A/part-92/subpart-C/section-92.201 — real-time full-motion video and audio without lags or irregular pauses; interpreter’s face visible; clear voices; user training. Tier 1.

Where lower-tier sources disagreed with rule or standard text, the rule wins in this article: vendor and listicle claims that WebRTC is "HIPAA compliant" were replaced with the precise framing (encryption is mandatory per RFC 8827; compliance additionally requires the §164.312 safeguards and BAAs per 45 CFR §164.308(b)); and blogs describing the 2025 Security Rule NPRM as final were overridden by the Federal Register record (still proposed as of 2026-10-20).