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.
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:
Kann sehen, wer in welchem Raum ist (Peer-IDs + Anzeigenamen).
Kann das SDP lesen — was die IP-Adressen der Teilnehmer offenlegt (gilt für jedes WebRTC-System der Welt).
Kann neue Beitritte stören, indem es Signaling verwirft.
Kann Medien nicht entschlüsseln. DTLS-Schlüssel werden Peer-to-Peer ausgehandelt und verlassen die Browser nie.
Kann Chatnachrichten, Dateitransfers oder Zeiger-Events nicht lesen. Dieselbe DTLS-Verschlüsselung gilt für jeden Datenkanal.
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:
Der Raum hat mehr als 6 Teilnehmer. Darüber hinaus reicht das Uplink-Budget jedes Peers nicht mehr — serverseitiges Fan-out ist die einzige Skalierungsoption.
Vom Browser gemeldete Netzwerkbedingungen zeigen, dass die Verbindung den Mesh-Fan-out-Aufwand nicht halten kann: anhaltend niedrige verfügbare Bandbreite, erhöhter Paketverlust oder hohe Round-Trip-Zeit. Die Hochstufung erfolgt, bevor die Qualität einbricht, nicht danach.
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.