Die CodeB-SIP-Bridge sitzt zwischen der WebRTC-Seite (Opus über SRTP-DTLS) und der SIP-Seite (G.711 über klassisches UDP) und transkodiert im Lauf. Ihre SIP-Trunk-Zugangsdaten, Fraud-Kontrollen und Anrufprotokolle bleiben auf Ihrem eigenen Windows-Host — CodeB sieht und vermittelt Ihren PSTN-Verkehr nie.
Browser, signal.ashx, SIP-Bridge, Trunk · CodeB Webphone + SIP-Softphone nutzen dieselbe Bridge
Der Browser öffnet eine normale WebRTC-PeerConnection zur SIP-Bridge. Audio läuft auf Opus mit 48 kHz innerhalb von SRTP über DTLS. Die Verbindung ist identisch zu einem Browser-zu-Browser-CodeB-Meeting — die Bridge ist einfach der „andere Peer".
Die SIP-Bridge ist ein Windows-Dienst, der auf SIPSorcery aufsetzt. Sie dekodiert Opus, resamplet 48 kHz ↔ 8 kHz und kodiert dann µ-law oder A-law für die SIP-Seite. Derselbe Prozess besitzt den SIP-UDP-Listener (Standard-Port 5060) und den Public-Listener-Kanal für eingehende Anrufe.
Ausgehende PSTN-Anrufe gehen per SIP-INVITE gegen Ihre registrierten Trunks. Eingehende DIDs landen auf demselben Trunk. RTP zwischen Bridge und Trunk ist klassisches UDP-G.711 — die Verschlüsselungs-Posture der SIP-Seite hängt davon ab, was Ihr Carrier unterstützt.
CodeB Conference liefert die Bridge als Teil der Installation aus. Sie betreiben den SIP-Trunk — wir sehen, vermitteln oder transportieren Ihren PSTN-Verkehr nie. Die Bridge verbindet sich mit Ihren Trunk-Zugangsdaten auf Ihrem Windows-Host hinter Ihrer Firewall:
App_Data/<tenant>/appsettings.json auf Ihrer IIS-Box.App_Data/<tenant>/cdr/ geschrieben und auf der Admin-Seite cdr.html sichtbar — verlassen den Host nie.Die Bridge setzt drei Sperren vor jeder PSTN-Ausgabe durch:
403 not-in-whitelist beim Admit abgelehnt.Eingehende Anrufe bekommen die symmetrische Behandlung: ein Rate-Limit pro Quell-IP auf dem öffentlichen SIP-Listener, optional REGISTER-Pflicht (Standard an) und SIP-Digest-Authentifizierung gegen denselben Credential-Store wie der OIDC-IdP — eine Anmeldung, drei Dienste.
Ein Anruf in die andere Richtung — ein externes SIP-Telefon wählt eine CodeB-Nummer — nimmt innerhalb der Bridge einen von drei Wegen:
r_<raum>@phone.codeb.io setzt einen SIP-Anrufer direkt in einen WebRTC-Raum; user@phone.codeb.io klingelt die registrierten Softphones dieses Nutzers.Der signal.ashx-WebSocket trägt ausschließlich Steuer-Frames (Wähl-Anfragen, Ring-Frames, Annehmen/Ablehnen). Medien laufen nie über signal.ashx. Die Bridge ist das einzige Stück, das jemals entschlüsselte PCM-Samples im Speicher hält — für die Millisekunden, die das Transkodieren und Weiterleiten dauern. Nichts wird auf Platte gepuffert, es sei denn, Sie haben SaveTranscripts für eine KI-Empfangs-Regel eingeschaltet (und selbst dann nur der Text dieser einen vnum, nie rohes Audio).
Browser-zu-Browser-Medien-Datenfluss → · Virtual-Agent (KI-Empfang) Datenfluss → · OIDC-Anmelde-Datenfluss →