P2P (peer-to-peer) sends audio and video directly between two endpoints with no media server in the path. Because nothing sits in the middle, it delivers the lowest possible latency and incurs no server-side media bandwidth cost, which makes it a natural fit for a one-on-one consult between a single patient and a single clinician.
Its limits arrive quickly, though. Even a direct connection usually needs help getting established: most devices sit behind NAT (network address translation) on home and hospital networks, so STUN and TURN servers are still required to discover addresses and, when direct paths are blocked, to relay the media. Group calls degrade fast in a pure P2P mesh because every participant must upload a separate stream to every other participant, which exhausts upstream bandwidth and CPU. And critically for healthcare, there is no server in the path to attach recording, quality observation, or compliance controls to.
For a telemedicine product the usual architecture is to run P2P for two-party calls and switch to an SFU (a forwarding media server) the moment a third participant joins or recording is required. The common pitfall is over-committing to P2P because it looks cheaper, then discovering that recording, multi-party consults, and reliable connectivity on locked-down hospital networks all push you toward server-mediated media anyway. Even on a P2P call, the media is encrypted with DTLS-SRTP, satisfying HIPAA's transmission-security expectations on the link itself.
