AW: CPBX Universelles Basisprofil mit snom 710: Immer "488 Unacceptable here"

[#1]

Gab es in den letzten Tagen irgendeine Umstellung, was akzeptierte Codecs oder sonstige Einstellungen betrifft? Seit irgendwann letzter Woche können sich unsere zwei nicht supporteten Endgeräte (Cisco SPA112 für analoges Fax und snom 710) zwar nach wie vor problemlos registrieren, bekommen jedoch auf jeden INVITE die Meldung "488 Unacceptable here". Auch eingehende Gespräche funktionieren nicht mehr. Habe nach Ausschlussverfahren die verschiedenen Codecs nach und nach rausgenommen, aber keiner hat funktioniert. Woran könnte es noch liegen? Verbindung erfolgt verschlüsselt SIPS/SRTP. Der Desktop Client funktioniert hingegen am selben Anschluss nach wie vor problemlos.

[#2]

Erfolgt die Registrierung an einem Telekom-Anschluss?

Meines Wissens war schon immer für die erfolgreiche verschlüsselte Kommunikation der Einsatz der Mediasec-Header notwendig (1TR114, Annex J), welche nur vom offiziellen CloudPBX-Portfolio unterstützt werden.

Funktioniert denn die unverschlüsselte Kommunikation per SIP & RTP?

[#3]

Danke für den Hinweis! Es geht sowohl an einem Telekom-Anschluss als auch an einem Dritt-Anschluss nicht. Bis vor ein paar Tagen ging es aber an beiden mit unveränderter Konfiguration. Daher die Idee, telekomseitig könnte etwas geändert worden sein. Unverschlüsselt werde ich Mal probieren.

[#4]

Unverschlüsselt am Telekom-Anschluss funktioniert. Am Dritt-Anschluss geht das ja nicht. Allerdings ist interessanterweise am Dritt-Anschluss ein REGISTER ohne die mediasec-Header möglich, nur beim INVITE kommt dann die 488. Am Telekom-Anschluss wurde verschlüsselt jedoch bereits die Registrierung abgelehnt.

Meine Vermutung geht momentan in die Richtung, dass die Verwendung der mediasec-Header zwar schon immer in der TR vorgeschrieben war, aber evtl. erst irgendwann in den letzten Tagen auch als harte Bedingung eingestellt wurde. Das würde zumindest erklären, dass es vorher ging und nun plötzlich nicht mehr.

[#5]

Hier nochmal ein Zwischenstand: Mittlerweile bin ich mir ziemlich sicher, dass es an den fehlenden mediasec- bzw. am 3GPP End-To-Access Security-Header liegt. Deren Notwendigkeit ist ja in der 1TR114, Annex J beschrieben. Wenn ich es richtig verstanden habe, sollte diese wohl ungefähr in diesen Tagen entfallen (@Meester Proper's Post im IP-Phone-Forum), ist es nun aber doch nicht. Stattdessen scheint es, als ob sie nunmehr auch tatsächlich vom System erzwungen wird, was vorher offenbar nicht der Fall war. Vielleicht weiß @Meester Proper da mehr? Ich würde mich jedenfalls auch über einen Beitrag vom Team freuen und evtl. eine Anfrage in der zuständigen Abteilung.

Konsequenz wäre, falls es dabei bleiben sollte, dass nicht offiziell für Cloud PBX oder SIP-Trunk unterstützte Endgeräte es nun deutlich schwerer haben, verschlüsselte Verbindungen aufzubauen. Das ist zwar vertraglich nicht zu beanstanden, aber dennoch schade. Vorhandene Endgeräte konnten so nämlich weiter genutzt werden, was nun höchstens noch unverschlüsselt am Telekom-Anschluss funktioniert, an Fremd-Anschlüssen gar nicht mehr.

[#6]

---

@SAMFS  schrieb:

Hier nochmal ein Zwischenstand: Mittlerweile bin ich mir ziemlich sicher, dass es an den fehlenden mediasec- bzw. am 3GPP End-To-Access Security-Header liegt. Deren Notwendigkeit ist ja in der 1TR114, Annex J beschrieben. Wenn ich es richtig verstanden habe, sollte diese wohl ungefähr in diesen Tagen entfallen (@Meester Proper's Post im IP-Phone-Forum), ist es nun aber doch nicht. Stattdessen scheint es, als ob sie nunmehr auch tatsächlich vom System erzwungen wird, was vorher offenbar nicht der Fall war. Vielleicht weiß @Meester Proper da mehr?

Meines Wissens war es bei Cloud-PBX Anschlüssen nie möglich SRTP ohne Mediasec-Header zu nutzen. Nutzbar war wohl jedoch TLS und RTP. Letzteres wird nun wohl blockiert, es ist nun also nur noch TCP und RTP oder TLS und SRTP möglich.

---

@SAMFS  schrieb:

Konsequenz wäre, falls es dabei bleiben sollte, dass nicht offiziell für Cloud PBX oder SIP-Trunk unterstützte Endgeräte es nun deutlich schwerer haben, verschlüsselte Verbindungen aufzubauen. Das ist zwar vertraglich nicht zu beanstanden, aber dennoch schade. Vorhandene Endgeräte konnten so nämlich weiter genutzt werden, was nun höchstens noch unverschlüsselt am Telekom-Anschluss funktioniert, an Fremd-Anschlüssen gar nicht mehr.

---

Bei SIP-Trunk sind die Mediasec-Header nicht notwendig, da diese Anschlüsse über eine andere Plattform realisiert werden. Mediasec-Header werden nur für die Retail-Produkte (DeutschlandLAN IP Voice(/Data), MagentaZuhause, usw.) und Cloud-PBX benötigt. Für DLAN SIP-Trunk wie gesagt, nicht notwendig.

[#7]

---

@Meester Proper  schrieb:

---

Meines Wissens war es bei Cloud-PBX Anschlüssen nie möglich SRTP ohne Mediasec-Header zu nutzen. Nutzbar war wohl jedoch TLS und RTP. Letzteres wird nun wohl blockiert, es ist nun also nur noch TCP und RTP oder TLS und SRTP möglich.

---

Hab nochmal ein paar alte Packet Captures vom snom rausgesucht. Es waren sowohl Signalisierung als auch Sprache verschlüsselt, also TLS und SRTP. Und das tatsächlich ohne MediaSec über einen Fremd-Anschluss.

Werde nun mit dem snom wohl über OpenVPN zum internen Netzwerk am Telekom-Anschluss verbinden. Bei der Sache frage ich mich nebenbei, welche Vorteile die MediaSec- und 3ge2ae-Header eigentlich bringen. Funktioniert hat es ja offensichtlich auch ohne.

[#8]

Hallo @SAMFS,

tut mir leid, für die späte Rückmeldung.
Ich habe das Problem weitergeleitet und melde mich dazu Ende der Woche erneut.

Lieben Gruß, Melanie B.

[#9]

Hallo @SAMFS,

da wir diese Geräte nicht in unserem unterstützen Portfolio haben können wir hierzu keine Aussage treffen. Deshalb erfolgt die Einrichtung des Universellen Basisprofils auch unter Kundeneigenverantwortung.
Eine Änderung der Codecs ist uns auch nicht bekannt.
Tut mir leid, leider kann ich von dieser Seite keine weitere Unterstützung anbieten.

Lieben Gruß, Melanie B.