So funktioniert es

Ihr Video läuft nie über den Server.

CodeB Sovereign Communications nutzt WebRTC. Audio, Video, Screenshare, Chat, Dateien und der Remote-Zeiger fließen direkt zwischen den Browsern — Ende-zu-Ende verschlüsselt. Der IIS-Server reicht nur ein paar Kilobyte Verbindungs-Metadaten weiter, um die Peers einander vorzustellen, und tritt dann beiseite.

phone.codeb.io NUR SIGNALING A Browser TEILNEHMER B Browser TEILNEHMER SDP · ICE SDP · ICE VIDEO · AUDIO · SCREEN CHAT · DATEIEN · ZEIGER · REAKTIONEN DTLS-SRTP · ENDE-ZU-ENDE VERSCHLÜSSELT · TURN-RELAY: phone.codeb.io
Signaling (Server) Medien + Daten (Peer-to-Peer)

Zwei Browser in einem Anruf · der Server vermittelt nur die Vorstellung

Server
01 / Signaling

Winziges JSON über WebSocket

Der IIS-Handler signal.ashx reicht vier Nachrichtentypen weiter: join, welcome, peer-joined/left und signal (das SDP und ICE-Kandidaten verpackt). Eine typische Sitzung bewegt insgesamt ein paar Kilobyte. Keine Medien, kein Chat, keine Dateien.

Browser ↔ Browser
02 / Medien

Direkt Peer-to-Peer

Kamera, Mikrofon und Bildschirm fahren auf SRTP über DTLS-verschlüsseltem UDP zwischen den beiden Browsern. Schafft WebRTC den NAT-Durchstich, ist es reines Ende-zu-Ende. Wenn nicht, übernimmt das in die CodeB-SIP-Bridge eingebaute TURN-Relay auf phone.codeb.io die noch immer verschlüsselten Bytes zwischen den Peers — das Relay sieht Chiffretext, nie Video oder Audio.

Browser ↔ Browser
03 / Datenkanäle

Chat, Dateien, Zeiger, Reaktionen

Alles, was kein Audio oder Video ist, fließt über SCTP-über-DTLS-Datenkanäle, ebenfalls Peer-to-Peer. Die Remote-Zeiger-Pfeile, die Datei, die Sie in den Chat ziehen, die 🎉-Reaktion — alles geht direkt an jeden Peer und berührt Ihren Server nie.

Was der Server sehen kann und was nicht

Fällt die IIS-Maschine mitten im Anruf in feindliche Hände:

STUN, TURN und NAT-Traversierung

WebRTC fragt einen STUN-Server, um jedem Browser seine eigene öffentliche IP zu nennen. Standardmäßig liefert phone.codeb.io einen tenant-lokalen STUN-Server aus dem in die Bridge eingebauten TURN-Dienst — ohne explizites Opt-in über WebPhone:StunHosts wird kein öffentlicher Server kontaktiert. Siehe Privatsphäre & Sicherheit zuerst.

Für die ~10–20% Nutzer hinter symmetrischen NATs (Firmen-WLAN, Mobilfunk) schaltet WebRTC auf TURN-Relay um. phone.codeb.io nutzt das in die CodeB-SIP-Bridge eingebaute STUN/TURN-Relay — derselbe .NET-Windows-Service, der auch SIP behandelt. Kein separates TURN-Tool zu installieren, keine Third-Party-Cloud. TURN reicht die verschlüsselten Medienbytes zwischen den Peers weiter; der Relay-Betreiber sieht Chiffretext, keine Gesichter oder Stimmen.

Browser-Sessions erhalten zeitlich befristete TURN-Credentials, die signal.ashx beim Beitritt mintet: HMAC-SHA1 über <expiry>:<peerId> mit einem Shared Secret, das nur Signaling- und TURN-Server kennen. Credentials laufen nach einer Stunde ab — ein Leak heilt sich selbst. Kein statisches TURN-Passwort lebt je im Seitenquelltext.

Topologie: Mesh als Standard, serverseitiges Fan-out bei Bedarf

Standard ist Vollvermaschtes WebRTC: Jeder Browser öffnet eine direkte Verbindung zu jedem anderen Browser. Bei N Teilnehmern lädt jeder Browser N−1 Kopien seines Videos hoch. Der Server bleibt aus dem Medienpfad raus; Ihr Audio und Video berühren unsere Maschine nicht.

Der Raum wechselt automatisch auf eine self-hosted Selective Forwarding Unit (SFU) innerhalb Ihrer eigenen Bridge, sobald eine der folgenden Bedingungen zutrifft:

Nach dem Grundsatz Privatsphäre & Sicherheit zuerst läuft die SFU in Ihrem eigenen Bridge-Prozess auf Ihrem eigenen Server — nie in einer Third-Party-Cloud, nie auf geteilter Infrastruktur. Der Server sieht verschlüsselte DTLS-SRTP-Bytes; aus dem strikten „Ihre Medien berühren nie unsere Maschine“ wird auf der SFU-Spur „Ihre Medien verlassen nie Ihr eigenes Netz“.

Ein Operator kann einen Raum auch explizit auf mesh (strikt Peer-to-Peer; der Raum akzeptiert dann die natürliche Mesh-Obergrenze bei rund sechs Teilnehmern) oder SFU (immer serverseitig weitergeleitet; ein Publisher-Uplink pro Browser, daher fasst dieselbe Hardware komfortabel rund 30 aktive Teilnehmer pro Raum — mehr bei Audio-only) pinnen. Das Routen-Badge pro Kachel im Meeting-UI zeigt die Live-Topologie an — MESH bei Peer-to-Peer, SFU bei serverseitigem Forwarding.

Der codeb.io-Blickwinkel

CodeB Sovereign Communications ist standardmäßig auf die stärkste Privacy-Posture eingestellt, die WebRTC bietet: Ende-zu-Ende-Verschlüsselung zwischen Browsern, kein Third-Party-Cloud-Dienst, keine Telemetrie, keine Medien auf dem Server. Die IIS-Maschine kann komplett vom öffentlichen Internet abgekoppelt sein (mit TURN im selben LAN) und der Anruf funktioniert trotzdem.

Diese Eigenschaft passt das Phone in den Rest der CodeB-Produktlinie: der Credential Provider, der Desktop-Switcher und die Web-SSO-Erweiterung teilen denselben „keine Cloud, kein Kompromiss“-Ansatz. Der Konferenzbaustein ist keine Ausnahme.