Peer-to-Peer (P2P)

General definition

Peer-to-Peer (P2P) describes any system where participants connect directly to each other and share the work, rather than all talking to one central server. File sharing networks such as BitTorrent made the model famous; in real-time communication it means the audio and video of a call flow straight between two devices, and the only server involved is the one that introduced them. The alternative is client-server, where a server in the middle receives everything and relays, stores or processes it.

WebRTC was designed around P2P. A one-to-one browser call sends encrypted media directly between the two peers once signaling has exchanged their addresses and ICE has found a path, which gives the lowest possible latency and costs the service nothing in media bandwidth. The model starts to break in four well-known places:

• NAT and firewalls: most devices have no public address, so a direct path may not exist; STUN and TURN servers are needed, and once TURN relays the traffic the call is no longer really peer-to-peer
• Group calls: a full mesh needs every participant to send a separately encoded stream to every other one, so upload bandwidth and CPU grow with each person added; mesh is rarely used beyond three or four participants
• Compliance: if no server ever sees the media, no server can record, archive, moderate or audit it, which regulated industries usually require
• Consistency: each peer sees a slightly different call, and features like recording, transcription or an AI participant have nowhere to run

This is why nearly every production calling product moves to a server-centred topology once it grows past two people: an SFU that forwards each stream to the other participants without decoding it, or less commonly an MCU that mixes them. Each participant then has exactly one connection, to the server, which also simplifies NAT traversal. P2P survives as an optimisation for two-party calls and as the default model in privacy-first messengers, where the absence of a server is the point.

In the Ethora ecosystem

Ethora chat and calls are server-based by design. Messages pass through an XMPP server that stores them, and calls run over WebRTC with an SFU, so media from every participant reaches a media server that forwards it to the others. That gives group calls a single upstream per participant, makes NAT traversal a one-sided problem, and means calls run through infrastructure you can monitor and control rather than hopping device to device.

The trade-off is deliberate. A pure P2P design would make compliance archiving, audit trails and moderation impossible, and those are the capabilities that healthcare, finance and insurance customers choose Ethora for; see the message archiving entry for the reasoning on the chat side. Who operates the server is then a deployment choice: managed cloud, a dedicated server in your own cloud account, or self-hosted, so the box in the middle can sit in your own network rather than a vendor’s.