Architected and deployed a full WebRTC peer-to-peer video calling platform for healthcare, covering web android and iOS with COTURN-based NAT traversal on AWS.
Telehealth adoption accelerated significantly in 2020. Our client - a healthcare provider - needed to add video consultation capability to their existing patient-provider workflow. The requirements were specific: peer-to-peer video with no media server to minimise latency and infrastructure cost, cross-platform delivery across web android and iOS and deployment within a tight timeline.
They had existing web and mobile infrastructure but no prior WebRTC experience on their engineering side. We owned the full architecture and delivery.
Signaling server (Node.js / Socket.IO)
WebRTC connections require a signaling layer to exchange session descriptions and ICE candidates before the peer connection is established. We built a lightweight signaling server in Node.js using Socket.IO, deployed on an EC2 instance.
The signaling server handles session initiation: when a provider starts a consultation, it creates a session room and notifies the patient. Both parties join the room, exchange SDP offers and answers and ICE candidates through the Socket.IO relay and establish the direct peer connection. The signaling server's role ends once the peer connection is up - it carries no media traffic.
COTURN on AWS EC2
Pure peer-to-peer WebRTC fails for a significant portion of real-world connections because NAT traversal doesn't always succeed. We deployed a COTURN server on a dedicated EC2 instance to provide TURN relay capability for connections that cannot traverse NAT directly.
Server placement was based on geography - we deployed in the AWS region closest to the majority of the client's patient base to minimise relay latency for the cases where TURN was needed. The COTURN configuration was tuned for the expected concurrent session count with appropriate memory allocation and port range sizing.
Browser client (Express / JavaScript)
The web client is a minimal Express app serving a single-page interface. WebRTC media handling runs natively in the browser using the standard RTCPeerConnection API, with a UI that surfaces call controls, mute toggles and a waiting state when the other party has not yet joined.
The browser client handles the full ICE candidate exchange with graceful fallback: STUN first, TURN if STUN traversal fails. We tested across Chrome, Firefox and Safari - WebRTC compatibility differences between browsers required specific handling around SDP format variations identified through testing.
Android and iOS clients (Kotlin / Swift)
We led the mobile team through integration of WebRTC on both platforms. Both Android (using the official WebRTC Android library) and iOS (using the WebRTC.framework) clients connect to the same signaling server as the web client. The common signaling protocol meant the mobile and web clients were interoperable from day one.
Peer-to-peer architecture without a media server was the right call for this deployment scale. A selective forwarding unit would have added operational complexity and cost not justified for one-to-one consultations. If the use case had included group calls, the calculus would have been different.
COTURN server sizing deserves more attention than it usually gets. TURN relay traffic is symmetric - the server passes all media in both directions - and an undersized TURN deployment causes degraded call quality at exactly the moments when NAT traversal has already failed and the call most needs reliable infrastructure. We sized conservatively based on expected concurrent users with room for growth.
The platform went live across web android and iOS within the project timeline. Call success rate in testing was high, with TURN relay handling the cases where direct peer connection failed without any visible impact on the call experience. The client's telehealth consultations launched on schedule and the video infrastructure required no post-launch support interventions.