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. By default phone.codeb.io serves tenant-local STUN from the built-in TURN service in the bridge — no public server is contacted at all unless an operator explicitly opts in via WebPhone:StunHosts. See privacy & security first.
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.
The default is full-mesh WebRTC: every browser opens a direct connection to every other browser. With N participants, each browser uploads N−1 copies of its video. The server stays out of the media path; your audio and video never touch our box.
The room automatically promotes to a self-hosted Selective Forwarding Unit (SFU) inside your own bridge when either of the following holds:
Per privacy & security first, the SFU runs inside your own bridge process on your own server — never on a third-party cloud, never on shared infrastructure. The server sees encrypted DTLS-SRTP bytes; the strict "your media never touches our box" sentence reads as "your media never leaves your own network" once you're on the SFU lane.
An operator can also pin a room to mesh (strictest peer-to-peer; the room then accepts the natural mesh ceiling at around six participants) or to SFU (always server-forwarded; one publisher uplink per browser, so the same hardware comfortably hosts around 30 active participants per room — more for audio-only) explicitly. The per-tile route badge in the meeting UI shows the live topology — MESH when peer-to-peer, SFU when server-forwarded.
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.