Source code: https://github.com/wilsonmichaelpatrick/p2pconf.git
This project is a browser-based, WebRTC peer-to-peer audio conferencing application, with screensharing. It's also about seeing how much utility one can get from an inexpensive $5/month server in "the cloud".
The server does two basic things: it relays the out-of-band ICE messages needed for the clients to establish WebRTC peer connections between each other, and it responds to STUN binding requests from the clients. For speed and simplicity, there is no back-end database, and "authentication" (if it can be called that) relies on the uniqueness of a UUID to identify a particular call. There is no interpretation of the messages beyond decoding from the WebSockets protocol and determining which participant the message should be routed to.
The server is built using the STUN / WebSocket / HTTP implementations provided by libre library. It is written in a combination of C and C++. It can serve static HTML and JS files as a convenience, though a real deployment would have it handling only the WebSocket traffic.
For a "bad-case" scenario, where participants are continuously joining and departing after a 10-30 second call, a $5 per month server from Digital Ocean (1 vCPU / 1 GB Memory / 25 GB Disk / SFO2 - Ubuntu 18.04.3 (LTS) x64) touches around 25% CPU while ramping up to 300 4-person calls at a rate of about 6 calls (24 participants) per second. At the same time, it handles about 1700 STUN requests per second, which is commensurate with the number of participants in the calls. Profiling the code, the largest (by a decent margin) single consumer of CPU is the WebSocket protocol decoding.
If participants stayed for a longer duration, the connections would be mostly idle after the initial set-up, so perhaps a larger number of calls and participants could be handled at equilibrium. But it's easier to test with a semi-thundering herd, continuously incurring the messaging overhead of setting up the calls, than it is to define what that equilibrium would be.
The client code runs more-or-less correctly on Desktop Firefox, Chrome, Safari; Chrome on Android; and Safari on iOS. The screen-sharing behaves differently on mobile than on desktop even though the code is the same (it shares the camera instead), which needs to be addressed. It optionally uses pako to compress the message payloads before sending to the server.
The user interface leaves a lot of room for improvement.