CodeB Sovereign Communications uses WebRTC. Audio, video, screen sharing, chat, files and the remote pointer all travel directly between browsers — end-to-end encrypted. The IIS server only relays a few kilobytes of connection metadata to introduce the peers to each other, then steps aside.
Two browsers in a call · server only brokers the introduction
The IIS handler signal.ashx relays four message types: join, welcome, peer-joined/left, and signal (which wraps SDP and ICE candidates). A typical session moves a few kilobytes total. No media, no chat, no files.
Camera, microphone and screen ride on SRTP over DTLS-encrypted UDP between the two browsers. If WebRTC can punch through NAT, you get pure end-to-end. If not, the built-in TURN relay inside the CodeB SIP bridge at phone.codeb.io carries the still-encrypted bytes between peers — the relay sees ciphertext, never video or audio.
Everything that isn't audio or video flows on SCTP-over-DTLS data channels, also peer-to-peer. The remote pointer arrows, the file you drop into chat, the 🎉 reaction — all go directly to each peer and never touch your server.
If an attacker compromises the IIS box mid-call:
WebRTC asks a STUN server to tell each browser its own public IP address. The deployment at phone.codeb.io uses public STUN servers as a free fall-back — they see one tiny request per connection and no media.
For the ~10–20% of users behind symmetric NATs (corporate Wi-Fi, mobile carriers), WebRTC switches to TURN relay. phone.codeb.io uses the STUN/TURN relay that is built into the CodeB SIP bridge — the same .NET Windows Service that handles SIP. No separate TURN tool to install, no third-party cloud involvement. TURN forwards the encrypted media bytes between peers; the relay operator sees ciphertext, not faces or voices.
Browser sessions receive time-limited TURN credentials minted by signal.ashx at room-join time: HMAC-SHA1 over <expiry>:<peerId> using a shared secret only the signaling and TURN servers know. Credentials expire after one hour, so a leak self-heals. No static TURN password ever lives in the page source.
This app uses a full-mesh WebRTC topology: every browser opens a direct connection to every other browser. With N participants, each browser uploads N−1 copies of its video. That keeps the architecture simple and the server out of the data path — at the cost of a soft ceiling around 6 participants.
Above that you'd need a media server (an SFU like mediasoup or LiveKit) which receives each peer's stream once and forwards it to the others. At that point the server is in the media path — still only seeing encrypted bytes if you configure end-to-end encryption (E2EE-via-Insertable-Streams), but the simple "your video never touches our box" sentence stops being literally true.
CodeB Sovereign Communications defaults to the strongest privacy posture WebRTC offers: end-to-end encryption between browsers, no third-party cloud service, no telemetry, no media on the server. The IIS box can be air-gapped from the public internet entirely (with TURN running on the same LAN) and the call will still work.
That property is what makes the phone fit the rest of the CodeB product line: the credential provider, the desktop switcher, and the Web SSO extension all share the same "no cloud, no compromise" approach. The conferencing piece is no exception.