CodeB Conference 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.
Zwei Browser in einem Anruf · der Server vermittelt nur die Vorstellung
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.
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.
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.
Fällt die IIS-Maschine mitten im Anruf in feindliche Hände:
WebRTC fragt einen STUN-Server, um jedem Browser seine eigene öffentliche IP zu nennen. Die Installation auf phone.codeb.io nutzt öffentliche STUN-Server als kostenlosen Fallback — sie sehen pro Verbindung eine winzige Anfrage und keinerlei Medien.
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.
Diese App verwendet eine Vollvermaschte WebRTC-Topologie: Jeder Browser öffnet eine direkte Verbindung zu jedem anderen Browser. Bei N Teilnehmern lädt jeder Browser N−1 Kopien seines Videos hoch. Das hält die Architektur schlank und den Server aus dem Datenpfad — um den Preis einer weichen Obergrenze bei rund 6 Teilnehmern.
Darüber bräuchten Sie einen Media-Server (eine SFU wie mediasoup oder LiveKit), die den Stream jedes Peers einmal empfängt und an die anderen weiterleitet. Damit ist der Server im Medienpfad — sieht zwar immer noch nur verschlüsselte Bytes, wenn Sie Ende-zu-Ende-Verschlüsselung (E2EE-via-Insertable-Streams) konfigurieren, aber der schlichte Satz „Ihr Video läuft nie über unsere Maschine“ stimmt dann nicht mehr wörtlich.
CodeB Conference 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.