WebRTC telemedicine calls fail for predictable reasons: the two devices cannot reach each other directly, the network blocks UDP, or bandwidth drops mid-call. The fixes are known too. Run your own TURN servers, including TURN over TLS on port 443. Test the patient’s connection before the doctor joins. Step down from HD video to audio, chat or a phone callback instead of dropping the consultation.
Quick answer
- WebRTC encrypts media by default with DTLS-SRTP.
- ICE tries a direct path first, then STUN, then relays through TURN.
- Some sessions always need TURN, so size and place TURN servers carefully.
- Offer TURN on TCP/TLS 443 for hospital and corporate networks.
- Build a fallback ladder so a weak network still ends in a completed consultation.
How a WebRTC telemedicine call connects
A browser or app cannot open a call on its own. It needs four things around it.
- Signalling server.
Usually a WebSocket service in your backend. It passes session descriptions and network candidates between the two sides. WebRTC does not define it, so you build or choose it. - STUN server.
Tells each device its public address. - TURN server.
Relays the media when a direct path is impossible. The protocol is defined in RFC 8656. - ICE.
The procedure, defined in RFC 8445, that gathers candidate paths and picks one that works.
Media is always encrypted. WebRTC uses DTLS to agree keys and SRTP to encrypt audio and video, as specified in RFC 5764. That is a good base for health data, but it does not replace access control, consent or logging in your app.
Why a telemedicine video call drops
ICE tries paths in order of preference: host candidates on the same network, then server-reflexive candidates found through STUN, then relay candidates through TURN.
The common failure causes:
- Symmetric NAT.
Some routers map each destination to a different port, which breaks direct connections. Only TURN gets through. - UDP blocked.
Hospital and corporate networks often block UDP or allow only port 443. A 2026 engineering write-up on hospital networks describes networks that block UDP entirely and inspect TLS traffic. - No TURN, or TURN too far away.
Without a relay, those sessions simply fail. With a distant relay, latency rises. - Bandwidth drops on mobile data.
Video freezes, then the call looks broken to the patient. - Device problems.
Camera permission denied, wrong microphone selected, battery saver throttling the app.
How many sessions need a relay varies by audience. A streaming vendor estimates 15 to 20% in enterprise environments. Measure your own rate from call logs; it will differ between home broadband patients and hospital-based doctors.
TURN servers: placement and sizing
Run TURN yourself, or use a managed provider in the right region. The open-source coturn server is the most common self-hosted choice. For UAE, Saudi or Indian patients, place relays in-country. That keeps latency low and keeps relayed health data inside the country’s borders.
Configure three listeners: UDP 3478, TCP 3478, and TLS on 443. The TLS listener is what gets calls through strict hospital firewalls.
For sizing, bandwidth is usually the limit, not CPU. Here is a rough model, not a benchmark: a relayed call’s media enters and leaves the server, so each call uses about twice its bitrate on the network port. On a 1 Gbps port kept at 70% use (700 Mbps):
- HD video at 3 Mbps: 700 / (2 × 3) ≈ 117 concurrent relayed calls
- SD video at 1 Mbps: 700 / (2 × 1) = 350
- Audio only at 0.1 Mbps: 700 / (2 × 0.1) = 3,500
Real numbers depend on codecs, resolution and how many sessions need relay. Load test with your own traffic.
Design a fallback ladder
A consultation that finishes on audio is better than one that fails on video. Dubai’s telehealth standard asks facilities to have alternative ways of communicating with patients, and our article on telemedicine in war zones shows how far degraded networks can go.
- HD video.
When bandwidth allows. - SD video.
Lower resolution and frame rate first. WebRTC’s congestion control does some of this automatically; add your own limits too. - Audio only.
Turn video off by default when quality stays poor. - Chat.
With image upload for rashes, wounds or documents. - Phone callback.
Through a telephony provider, with the call logged against the consultation.
Log every step down, so you can see which regions or networks need work.
Peer-to-peer or SFU?
For one doctor and one patient, a direct peer-to-peer connection is enough. Add a Selective Forwarding Unit (SFU) when you need three or more people, such as an interpreter, a family member or a second specialist, or when you need server-side recording.
Open-source SFUs include mediasoup, Janus and LiveKit. Recording has compliance weight, so check consent and storage rules before enabling it.
Test before the doctor joins
A pre-call check catches most problems while the patient is still in the waiting room.
Check camera and microphone permissions, run a short bandwidth test, confirm the TURN server is reachable, and only then mark the patient as ready. If a check fails, offer audio or a callback straight away. Our telemedicine app development guide covers where this fits in the patient journey, and secure cloud architecture for telemedicine apps covers hosting.
Common mistakes
- Using only public STUN servers.
Sessions that need a relay will fail. - No TURN over TLS 443.
Hospital networks block the rest. - One TURN region for everyone.
Far-away relays add latency and may move data abroad. - Treating video as all or nothing.
Build the fallback ladder. - No call-quality logging.
You cannot fix drops you cannot see. - Short-lived TURN credentials missing.
Static credentials in app code invite abuse.
FAQ
Is WebRTC secure enough for telemedicine?
WebRTC encrypts all media with DTLS-SRTP by default. You still need authentication, access control, consent and audit logs in your platform.
Why does my telemedicine video call work at home but not at the hospital?
Hospital networks often block UDP or allow only port 443. Add TURN over TLS on 443.
Do I need a TURN server?
Yes, for a reliable service. Some sessions cannot connect directly and will fail without one.
When do I need an SFU?
When calls have three or more participants, or when you need server-side recording.
