Toggle sidebar Toggle sidebar

Ausgehende Telefonate mit SRTP nicht möglich

B

bock

Customer
Mitglied seit
8. Oktober 2020
Beiträge
14
Guten Tag,

ich sitze seit Stunden daran, einen SIP-Trunk bei Easybell mit einer 3CX-Anlage über TLS zu registrieren.
Die Kommunikation soll natürlich über SRTP verschlüsselt werden.

Der SIP-Trunk ist folgendermaßen eingerichtet:
  • Host: secure.sip.easybell.de
  • Port: 5061
  • Transport: TLS
  • SRTP: Ja (!)
  • TLS-Root-Zertifikat ist hochgeladen
Die 3CX-Instanz registriert sich auch erfolgreich bei Easybell.
Allerdings kann ich keinen ausgehenden Anruf initiieren. Im Aktivitätenprotokoll taucht unter anderem folgende Meldung auf:

[CM503003]: Call(C:9): Call to <sip:[email protected]:5061> has failed; Cause: 488 Secure RTP is forced/INVITE from 212.172.58.207:5061

Dem Endgerät wird anschließend die Meldung "Not Acceptable Here" angezeigt:

[CM503016]: Call(C:9): Attempt to reach <sip:[email protected]:0> from Extn:055 has failed. Reason: Not Acceptable Here

Ich verstehe aber beim besten Willen nicht, wo hier das Problem liegen könnte: SRTP ist aktiviert.

Anscheinend ignoriert die 3CX-Instanz diese Einstellung und versucht trotzdem, eine RTP-Verbindung im Klartext aufzubauen?

Eine Regel für ausgehende Gespräche ist ebenfalls definiert, die alle Nummern (Präfix 0-9) zum registrierten Easybell-Trunk leitet.
 
Kennst du die folgende IP 212.172.58.207 ?
 
Das ist die IP des SIP-Servers von Easybell.

Bash: 
$ dig secure.sip.easybell.de +short
212.172.58.207
 
Mit dem Update auf die Version 16.0.5.612 hat 3CX eine Änderung eingebaut, welche es ermöglicht, zwei unterschiedliche RTP-Ströme parallel zu versenden.

3CX möchte durch das Senden zweier Audio-Ströme eine Fall-Back-Lösung für die Kunden schaffen. Wenn ein Provider eine verschlüsselte Verbindung nicht aufbauen kann, bietet die Anlage direkt die Möglichkeit, das unverschlüsselte Audio zu nutzen. Dadurch ist sichergestellt, dass das Gespräch immer zustande kommt.

Dies führt allerdings auch dazu, dass der Nutzer keinerlei Möglichkeit hat festzustellen, ob das Gespräch wirklich verschlüsselt war. Der Administrator könnte höchstens durch Tracen der Telefonate, im Nachhinein, feststellen, ob ein Telefonat verschlüsselt war oder nicht.

Wir haben einen anderen Blick auf dieses Thema, nämlich den der Sicherheit. Wenn eine verschlüsselte Audio-Übertragung angestrebt wird und die Anlage entsprechend konfiguriert ist, soll sichergestellt sein, dass die Audio-Übertragung auch wirklich verschlüsselt ist. Daher werden unverschlüsselte Audio-Kanäle von unserer Infrastruktur abgelehnt, wenn die Konfiguration entsprechend ausgelegt wurde. So ist sichergestellt, dass auch wirklich nur verschlüsselte Gespräche zustande kommen.

Wir stehen im Austausch mit 3CX, um eine gemeinsame Lösung zu finden.

Für Sie bedeutet dies leider, dass aktuell eine sicher verschlüsselte Telefonie (Audioübertragung) mit der 3CX nur mit den Versionen 16.0.3.676 und 16.0.4.493 möglich ist.
 
Danke für die Informationen. Ich verstehe allerdings nicht so recht, woran es hier genau hapert.
Wenn die 3CX-Anlage korrekt funktionieren würde, dann würde sie ja wohl eine verschlüsselte Sprachverbindung aufbauen, wenn ich den SIP-Trunk entsprechend konfiguriere.

Wenn eine SRTP-Verbindung mit dem SIP-Server von Easybell aufgenommen wird, sollte diese ja akzeptiert werden. Folglich würde die 3CX-Anlage doch dann nicht auf eine unsichere Verbindung downgraden, wenn ich die Erklärung von Easybell korrekt verstehe, oder?

Können Sie mir das bitte genauer erläutern, @ilias_3CX und @easybell GmbH?

Allgemein: Ich sehe das wie Easybell – aus meiner Sicht ist es unverantwortlich, eine unverschlüsselte Verbindung aufzubauen, wenn der Anwender explizit nur verschlüsselt kommunizieren möchte. Ich weiß, die VOIP-IT-Subbranche ist im Vergleich zu anderen Teilen der IT-Welt was Sicherheit angeht immer hinterher, aber dieses Systemverhalten überschreitet meiner Meinung nach die Grenze.
 
Unsere Systeme lehnen den Call derzeit generell ab, wenn bei einem unverschlüsselten Anruf zwei Streams und dabei ein unverschlüsselter Anruf angeboten wird. Da man das Verhalten von 3CX durchaus als RFC konform auslegen kann, arbeiten wir derzeit daran, mit diesem neuen Verhalten umzugehen.
 
  • Like
Reaktionen: 0michael0
easybell GmbH schrieb:
Unsere Systeme lehnen den Call derzeit generell ab, wenn bei einem unverschlüsselten Anruf zwei Streams und dabei ein unverschlüsselter Anruf angeboten wird. Da man das Verhalten von 3CX durchaus als RFC konform auslegen kann, arbeiten wir derzeit daran, mit diesem neuen Verhalten umzugehen.
Zum Vergrößern anklicken....
HalliHallo,

gibt es denn hier schon Neuigkeiten? Wir würden gern SRTP mit Easybell und 3CX verwenden.
 
Hallo. Wir haben von einem IT-Partner das Feedback bekommen, dass dies laut 3CX im nächsten Major Release behoben wird.

Man könne bereits in der aktuellen Alpha-Version (V18 Alpha 2) den SRTP-Mode erzwingen und so dafür sorgen, dass garantiert nur der verschlüsselte Mediastream übermittelt wird, statt verschlüsselt und unverschlüsselt.

So kann sichergestellt werden, dass eine Verbindung garantiert verschlüsselt wird. Mit der Alpha-Version (und hoffentlich auch möglichst bald in einem vollen Update) wird SRTP also wieder wie vorgesehen mit unseren Diensten laufen.
 
  • Like
Reaktionen: MarcosV_3CX
Moin, gibt es hier schon etwas neues? Wir haben die Version 18 Update 6 und bekommen mit der Easybell-Anleitung die verschlüsselte Telefonie nicht eingerichtet. Zumal auffällt, dass dass Zertifikat am 6. März 2023 ausläuft. Muss man wirklich jedes Mal händisch das Zertifikat neu eintragen?

1676039724015.png

1676039741176.png

1676039753430.png
 
Hi @EDV-Crew,

das was unser Anleitung sagt gilt. TLS = NO
 
Okay, gibt es auch irgendwann mal positive Neuerungen bei 3CX? Oder geht es nun nur noch nach hinten mit der "Entwicklung"?
 
Um antworten zu können musst du eingeloggt sein.

Einstieg für Admins

Statistik des Forums

Themen
44.414
Beiträge
232.720
Mitglieder
78.330
Neuestes Mitglied
uvitas
3CX Logo Footer Copyright © Sitemap Datenschutz Impressum
Oben Unten