SIPS — verschlüsselte SIP-Signalisierung nach RFC 5630.
Der CodeB Souveräne SBC terminiert SIP über TLS auf eigenen Ports für Trunk- und öffentlichen Listener-Verkehr. Jeder TLS-Handshake wählt das mandanteneigene Zertifikat per SNI aus dem vorhandenen Windows-Zertifikatsspeicher — ein Let’s-Encrypt-Zertifikat pro Mandant, keine SAN-Liste zu pflegen. ACL, Auto-Blacklist und Observability werden mit dem restlichen Bridge-Stack geteilt.
Mandanten anlegenZwei TLS-Ports parallel zur UDP-Topologie
Die Aktivierung von SIPS auf einem CodeB-Mandanten strukturiert das Routing nicht um. Die zwei TLS-Listener liegen neben den vorhandenen UDP-Listenern, sodass Anrufabläufe, ACL-Regeln und Trunk-Konfiguration weiterhin wie konfiguriert funktionieren. Pro-Trunk-Aktivierung ermöglicht den schrittweisen SIPS-Rollout.
Carrier-ITSP mit SIPS-Endpunkt oder Enterprise-SBC
Hardphone oder SIP-Phone mit TLS-Pflicht beim REGISTER
Mandantenzertifikat per SNI
Jeder TLS-Handshake wählt das mandantenspezifische Zertifikat per SNI-Servername aus LocalMachine\My. Derselbe Zertifikatsspeicher, den auch der WSS-Listener und TURN-TLS verwenden; dasselbe per Mandant ausgerollte LE-Zertifikat via /acquire-cert.
Mandant N+1 hinzuzufügen bedeutet: ein weiteres Zertifikat installieren — keine SAN-Liste, keine betreiberseitige SIPS-Neukonfiguration.
Pro Trunk aktivierbar
In trunks-admin.html hat jeder Trunk eine TLS (SIPS)-Checkbox und einen optionalen TLS-Port (Standard 5061). Aktiviert registriert und wählt die Bridge via sips:user@host:5061;transport=tls nach RFC 5630.
Die meisten modernen Carrier bieten TLS auf 5061; klassische FRITZ!Box-/ATA-Boxen meist nicht — dort einfach deaktiviert lassen.
ACL-Tor (gemeinsam mit UDP)
Dieselben acl.html-Regeln, die SIP über UDP blockieren, blockieren auch SIPS. SIPS-Verkehr betritt denselben InboundDispatcher-Punkt; Regeln für IP, CIDR, Glob, sip-user, sip-from, sip-did und Mandant gelten ohne Sonderfall.
Hot-Reload, Selbst-Aussperr-Schutz für private IPs, Pro-Mandanten-Regelpools — alles an einer Stelle.
Per-IP TLS Auto-Blacklist
Sliding-Window-Detektor pro Quell-IP: mehr als 15 fehlgeschlagene TLS-Handshakes innerhalb von 5 Minuten sperrt die IP auf der SIPS-Annahmestufe für 1 Stunde. Fängt lärmenden SIP-Scanner-Traffic am kostengünstigsten Antwortpunkt ab.
Schwellenwert höher als TURN-Standard (5), um CGNAT-geteilte Mobilfunk-Quell-IPs zu schonen. Private, Loopback-, Link-local- und IPv4-mapped-IPv6-Adressen sind ausgenommen.
Slow-Loris-Verteidigung
15-Sekunden-Handshake-Timeout beendet Peers, die nach dem TLS-Record-Header nur tropfweise Bytes nachliefern. Per-Kanal-SemaphoreSlim(200) deckelt In-Flight-Handshakes pro Port, damit ein /16-Scanner den Thread-Pool nicht aushungert.
Über-Cap-Accepts erhalten ein sofortiges TCP-RST plus eine gedrosselte WRN-Logzeile.
Observability ohne REST-Exposure
Eine greppbare Logzeile pro eingehender SIPS-Anfrage: [sips-arrival] mit CallID, Methode, From, To, Remote, Local. Eine [sips-downgrade] WRN-Zeile pro Anruf, wenn eine SIPS-Strecke auf eine SIP-Klartextstrecke umsteigt — nie still, nie blockiert.
Periodische [SIPS-stats]-Zeile alle 30 s. Betreiberorientierter /sip-tls/health-Endpoint liefert dieselben Daten als JSON.
SRTP via SDES — Medien-Verschlüsselung auf der Trunk-Strecke
SIPS schützt die SIP-Steuerebene. SDES (Session Description Protocol Security Descriptions, RFC 4568) verschlüsselt SRTP auf der Medienebene derselben Trunk-Strecke. Zusammen ist die Strecke zwischen Bridge und Carrier auf beiden Ebenen verschlüsselt: SIPS für Signalisierung, SDES für Medien.
Pro-Trunk-SRTP-Schalter
In trunks-admin.html hat jeder Trunk eine SRTP-Checkbox neben der vorhandenen TLS (SIPS)-Checkbox. Aktiviert offeriert die Bridge SDES bei ausgehenden INVITEs und antwortet mit SDES bei eingehenden INVITEs dieses Trunks. Standardmäßig AUS pro Trunk — bestehende Routings bleiben unverändert, bis ein Betreiber aktiviert.
Crypto-Suite: AES_CM_128_HMAC_SHA1_80
Ausgehende INVITEs offerieren m=audio … RTP/SAVP mit a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<base64-key> — die nach RFC 4568 verpflichtende Basis-Suite. Der 32-Byte-Schlüssel (128-Bit Master Key + 112-Bit Master Salt) wird pro Anruf frisch erzeugt.
Asymmetrische eingehende Antwort
Eine eingehende INVITE mit a=crypto: wird unabhängig vom ausgehenden Schalter des Trunks mit SDES beantwortet — safe-by-default. Peers, die SRTP bevorzugen, erhalten SRTP zurück; Peers ohne Crypto-Angebot funktionieren weiterhin wie zuvor.
Fail closed, nie still Klartext
Wenn der Pro-Trunk-SRTP-Schalter aktiv ist und der Peer das SDES-Angebot ablehnt (oder keine brauchbare crypto-Zeile zurückgibt), endet der Anruf. Es gibt keinen Fallback auf Klartext-RTP, den ein Betreiber nicht ausdrücklich freigegeben hat. Jede Ablehnung wird auf INF-Ebene mit Anruf-Korrelations-ID protokolliert.
Bridge-terminiert für KI & Aufzeichnung
Die Bridge terminiert die SDES-Sitzung und sendet die passende Form auf der Gegenstrecke. KI-Empfang, signierte Anrufaufzeichnung, Transkription und Lawful-Intercept-Hooks arbeiten weiter, weil die Bridge intern dekodiertes Audio sieht. Der Carrier sieht nie Klartext auf der Leitung.
Ergänzt DTLS-SRTP auf WebRTC
Browser-Strecken verhandeln DTLS-SRTP bereits automatisch. SDES auf der Trunk-Strecke schließt die symmetrische Lücke auf der Carrier-Seite. Gepaart mit dem Pro-Trunk-Schalter TLS (SIPS) ist die Trunk-Strecke gleichzeitig auf Signalisierungs- und Medienebene verschlüsselt.
EU-CRA- und NIS2-Ausrichtung: Medien-Verschlüsselung zwischen einer regulierten Organisation und ihrer Telekom-Grenze ist zunehmend Basis-Erwartung, nicht Nice-to-have. SDES auf der Trunk-Strecke, gepaart mit SIPS auf der Signalisierungsebene, deckt beides ab — mit betreiberkontrollierter Pro-Trunk-Granularität, ohne All-or-Nothing-Rollout.
Häufig gefragt
Ist SIPS für jeden Mandanten Pflicht?
Nein. SIPS ist pro Trunk aktivierbar. Die Bridge startet mit gebundenen SIPS-Listenern; ein Trunk verwendet aber nur dann sips:-URIs, wenn ein Betreiber die TLS-Checkbox im Trunk-Admin aktiviert. Mandanten ohne SIPS laufen unverändert auf UDP/TCP weiter.
Wie steht es um SRTP auf der Medienstrecke?
SIPS schützt die Signalisierungsebene. SRTP für Medien ist eine ergänzende, separate Aushandlung. WebRTC-Browser-Strecken nutzen automatisch DTLS-SRTP. Für die Carrier-Trunk-Strecke bietet die Bridge SDES nach RFC 4568 mit der Crypto-Suite AES_CM_128_HMAC_SHA1_80 an, wenn der pro-Trunk-Schalter SRTP aktiviert ist — ausgehende INVITEs offerieren RTP/SAVP mit a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:…, eingehende INVITEs antworten mit SDES, wenn der Peer es anbietet. Lehnt der Peer ab, endet der Anruf — kein stiller Klartext-Fallback. Die Bridge terminiert SRTP, sodass KI-Empfang, Aufzeichnung und Lawful-Intercept-Hooks weiterhin funktionieren. Wenn eine SIPS-INVITE auf eine Klartext-SIP-Strecke brückt (SRTP aus), wird pro Anruf eine strukturierte WRN-Zeile geschrieben, sodass der Betreiber jede Klartext-Strecke sieht.
Funktioniert SIPS mit TLS 1.3 und Post-Quantum-Hybrid-Schlüsselaustausch?
Ja für TLS 1.3. Die Bridge erzwingt TLS 1.2+TLS 1.3 explizit über SCHANNEL. Post-Quantum-Hybrid-Key-Shares (Chrome 124+ liefert X25519+Kyber768; später ML-KEM-768 nach NIST FIPS 203) werden von SCHANNEL auf Windows Server 2025+ verhandelt. Der SNI-Peek-Puffer ist auf 8 KB dimensioniert.
Wie verhindert die Auto-Blacklist die Aussperrung legitimer CGNAT-Clients?
SIPS-Schwelle: 15 Fehlschläge in 5 Minuten pro Quell-IP — bewusst höher als der TURN-Standard von 5. Begründung: viele Mobilfunkanbieter routen tausende Nutzer hinter einer IPv4-Quell-IP. Ein zu niedriger Schwellenwert würde beim ersten Fehlerschauer einen ganzen Carrier-Pool blockieren.
Wo sehe ich SIPS-Health und Verkehrszähler?
GET /sip-tls/health liefert JSON mit Port-Status, lebenslangem Handshake-Zähler, aktueller und kumulativer Blocklist-Größe und einer menschenlesbaren Policy-Beschreibung. Dieselben Daten erscheinen alle 30 Sekunden als [SIPS-stats] INF-Logzeile.
EU-Made?
Ja. CodeB wird von Aloaha Limited unter EU-Recht entwickelt und betrieben. SIPS-Deployments laufen auf betreibereigener Infrastruktur — keine CodeB-seitige Datenebene, kein Drittanbieter-Cloud-STUN/TURN, kein Metadaten-Export. Die Bridge läuft auf .NET Framework 4.8 unter Windows Server mit SCHANNEL als TLS-Provider.