Geht schon lange auf die beschriebene Art und Weise bei easybell (auch mit sip.eaybell.de tcp/5061). Was ich bisher gesehen habe (wenn ich geschaut habe - ist ja nicht mehr so einfach mit SIPS - ob das also immer so ist, vermag ich nicht zu sagen):
Outbound: es wird zumindest ein crypto-key im SDP mitgeliefert.
Inbound: kein crypto-key im Invite
Test erfolgte Inbound mit einem vollverschlüsselten Call von der Telekom aus. D.h. mit hoher Wahrscheinlichkeit, dass die Telekom auf ihrer Seite entschlüsselt und unverschlüsselt übergibt.
Ich habe mir mal den Spaß gemacht, und via Telekom meinen eigenen Telekom-Account angerufen. Wenn hier Ende zu Ende verschlüsselt werden würde (was technisch problemlos möglich wäre), würde ich erwarten, dass genau zwei Keys zum Einsatz kommen (Asterisk ist hier sowohl Sender als auch Empfänger - sieht also beide Enden).
Dem ist nicht der Fall - jeder Leg hat einen individuellen Key. Also terminiert die Telekom grundsätzlich jeden Leg und muss daher entschlüsseln und neu verschlüsseln für die andere Seite (kein Transcoding relevant gewesen!).
Alles auf Basis Asterisk 16.x ausgeführt (mit Mediasec-Patch für Telekom).
Will man durchgehend verschlüsselt mit SIPS / RTPS kommunizieren, muss man sich also eine eigene geeignete Infrastruktur / Lösung aufbauen und es darf auf der ganzen Strecke kein ungeeigneter Provider involviert sein. Fraglich, in wie weit das realistisch möglich ist, ohne irgendwelche andere Verbindungsspuren zu hinterlassen.
