Solved
Von gestern auf heute: 'SIP/2.0 488 Not Acceptable Here - security violation'
1 year ago
Hallo zusammen!
Gestern ging das Heraus-Telefonieren mit meinem SNOM D715 (neueste Firmware vom August '23) noch, heute nicht mehr: Bei jedweder Telefonummer gibt es im SIP-Log die Fehlermeldung:
'SIP/2.0 488 Not Acceptable Here - security violation'
und im Display die verkürzte Version davon: '488 Not Acceptable Here: 08003301000' (z.B.)
Angerufen werden funktioniert jedoch einwandfrei, jedoch in der letzten Zeit manchmal mit Gesprächsabbrüchen wenn am anderen Ende der Leitung auch ein Telekom-Kunde sitzt.
An den Einstellungen des SNOM-Telefons wurde schon monatelang nichts geändert. Von wegen Security: RTP-Verschlüsselung wird vom Telefon schon ewig angeboten ("kann ich"), aber nicht zwingend gefordert ("mandatory"). Router- und DSL-Modem-Konfiguration sind auch schon monatelang konstant.
Nur an "tel.t-online.de" (konkret und aktuell: 217.0.148.5) wurde wohl heute nacht wieder geschraubt.
Und was soll ich jetzt ändern, damit's wieder geht???
Grüße
Ingo
1708
24
This could help you too
3103
0
2
8438
0
3
767
0
1
6 months ago
1494
0
13
1 year ago
@coonabarabran: Was passiert, wenn Du die Verschlüsselung deaktivierst?
Gruß Ulrich
3
Answer
from
1 year ago
An dem geschilderten Problem ändert sich dadurch nichts. Auch das probeweise Aktivieren von "mediasec" hilft nicht.
Um anderen Rückfragen gleich mal vorzugreifen: Ein Neustart von Telefon, Router und DSL-Modem hilft genausowenig wie das einfache Abwarten (Stand 7.12. 23; 19:15 Uhr), ob sich der Fehler nicht von allein gibt. [Ja ich weiß, daß bei der Telekom so manche Fehler genauso 'magisch' verschwinden wie sie gekommen sind...]
Answer
from
1 year ago
@coonabarabran
Funktioniert es mit udp und rtp ohne Verschlüsselung und ohne MediaSec?
Answer
from
1 year ago
Nein, auch nicht. Ich habe alle möglichen Einstellungen durch-permutiert. RTP via udp (only) war schon immer so eingestellt und 'mediasec' war aus und ist auch nach dem Test wieder aus. RTP ohne Verschlüsselung war und ist möglich. Ich schrieb ja schon ganz oben, daß ich das auf optional eingestellt habe: Wenn man sich auf verschlüsseltes RTP einigen kann, dann wird's gemacht; wenn nicht, dann nicht.
Das hat bislang auch genauso funktioniert, denn auf einmal hatte die Telekom bei ankommenden Anrufen die RTP-Verschlüsselung ermöglicht, bei abgehenden Anrufen jedoch nicht. Das sieht man bei den SNOM-Telefonen im Display: Angerufen werden -> Schloß, raus telefonieren -> kein Schloß.
Ist ziemlich inkonsistent, aber der Vorwurf wäre an die Leute zu richten, die die Gerätschaften hinter 'tel.t-online.de' konfigurieren. Mir reicht's wenn's funktioniert.
Ich bin auch in der Lage, auf geänderte 'Gepflogenheiten' zu reagieren, wenn ich sie denn rechtzeitig (!) erfahre.
Unlogged in user
Answer
from
1 year ago
Nur an "tel.t-online.de" (konkret und aktuell: 217.0.148.5) wurde wohl heute nacht wieder geschraubt.
@coonabarabran
Was verwendest Du denn als Router und DNS?
Das ist doch die IP von einem alten dezentralen SIP Server, die gehen eben nicht mehr.
3
Answer
from
1 year ago
Router und Telefon sind so eingestellt, daß sie sich auf das verlassen, was der DNS der Telekom liefert. Also: Im Router ist ausschließlich der DNS der Telekom konfiguriert ('PPPoE') und nichts anderes. Es handelt sich um einen Draytek Vigor 2133; bei diesen Geräten ist bekannt, daß sie nicht heimlich noch einen anderen DNS-Server "zur Sicherheit" kontaktieren. (Bekanntlich gibt es ja so einige Hersteller, die Googles DNS fest in die Firmware 'genagelt' haben)
Das SNOM-Telefon fragt nur nach 'tel.t-online.de'; eine fixe IP für den SIP-Server (ja, ja es ist eigentlich ein SBC) ist nicht konfiguriert!
Answer
from
1 year ago
Es handelt sich um einen Draytek Vigor 2133;
@coonabarabran
Ist im Draytek der SIP ALG deaktiviert?
In meinem Yealink funktioniert SRTP/RTP mit den Cloud-Servern sowohl mit der Einstellung Compulsory als auch Optional.
Answer
from
1 year ago
ALG ist schon seit ewigen Zeiten deaktiviert. Und hat sich auch nicht wieder von selbst aktiviert; gerade noch einmal nachgeschaut.
Auch die Port Redirection ist immer noch wie gewohnt konfiguriert. Sonst gäbe es ja auch Schwierigkeiten beim Angerufen-Werden oder der SIP Registrierung.
Wie schon gesagt: Angerufen-Werden funktioniert einwandfrei, auch jetzt noch (8.12. 21:06 Uhr).
"Raus" wirft aber immer noch denselben Fehler.
Auch der mir automatisch zugeordnete "tel.t-online.de" ist immer noch 217.0.148.5.
Obwohl / trotz daß das ganze DSL- / Netzwerk- / Telefonzeugs heute nacht komplett aus war.
Unlogged in user
Answer
from
1 year ago
Moin!
Es ist so gekommen, wie ich es weiter oben schon prophezeit habe: Auf "magische Weise" ist das Problem heute über Nacht verschwunden, ohne daß ich etwas hätte tun müssen. 😇
Raustelefonieren klappt wieder ohne Probleme oder Fehlermeldungen des SNOM-Telefons.
"tel.t-online.de" ist immer noch 217.0.148.5, scheint aber ein Update bekommen zu haben, wenn ich den "Contact"-Header in den SIP-Dialogen auch als Hinweis auf die Software-Version interpretiere (kann mich auch dabei irren):
Contact: <sip:mavodi-0-266-.....Gestern stand da noch:
Contact: <sip:mavodi-0-264-.....Das wär's fürs Erste. Wenn das mit den oben angedeuteten Gesprächsabbrüchen (hier nicht das zentrale Thema) wieder auftreten sollte, gibt's 'nen neuen Thread.
Ingo
0
1 year ago
Und wieder die "Magie":
Gestern war das Problem weg; heute (11.12.) ist es genauso wieder da.
Und natürlich:
Ich habe zwischendurch keinerlei Einstellungen an Router oder Telefon verändert!
Daher habe diesen Thread wieder auf "ungelöst" zurückgestellt.
Leider liefert der SIP-Dialog aus dem Log des Telefons keine Hinweise, was genau dem Server der Telekom sicherheitsmäßig nicht in den Kram paßt.
1
Answer
from
1 year ago
@coonabarabran
Wenn Du dein Telefon auf udp und rtp fest einstellst, hast Du die Probleme nicht mehr.
Also kein tls, kein srtp und kein MediaSec.
Unlogged in user
Answer
from
1 year ago
Ich schrieb doch schon: RTP via udp (only) war schon immer so eingestellt und 'mediasec' war aus und ist auch nach dem Test wieder aus.
Wenn man wie von @wari1957 empfohlen SRTP fest auf "aus" und RTP/SAVP auf "nein" einstellt, kommt auch kein ankommendes Gespräch zustande! Gerade getestet. Der Anrufer hört dann: "Ihr gewünschter Gesprächspartner ist vorübergehend nicht erreichbar."
Wenn man SRTP auf "an" und RTP/SAVP auf "optional" einstellt, funktionieren ankommende Gespräche sofort wieder. Der Telekom-SIP-Server bietet die RTP-Verschlüsselung ja auch in der INVITE-Message von selbst an. Dieses Verhalten ist schon länger so; ganz früher war's aber tatsächlich anders, ich erinnere mich.
Die Ausfallstatistik seit Sonntag:
Und die Moral von der Geschicht: Telefonier an ungeraden Tagen nicht! (raus)
Sind wir hier in Absurdistan???
Fragt sich: Ingo
2
Answer
from
1 year ago
@coonabarabran
Wenn Du in deinem Telefon als SIP-Transport udp einstellst, wird der Telefonieserver der Telekom nie und nimmer im SDP-Header RTP/SAVP eintragen.
Das passiert nur bei SIP-Transport tls.
Answer
from
1 year ago
Moin!
Den SIP-Transport via "UDP unverschlüsselt" kann man in der aktuellen Firmware von SNOM nicht mehr einstellen. Das ist schon vor längerer Zeit 'entsorgt' worden, um den allgemeinen Sicherheitslevel bei SIP durch Endgeräte-seitigen Druck etwas 'anzuschieben'. Provider und Telefonanlagen(-Software-)-Hersteller waren zu dem Zeitpunkt wohl etwas zu 'gemütlich' unterwegs. Das stand irgendwo bei den Erläuterungen zu einem bestimmten Firmware-Update; was ich aber spontan nicht mehr finde.
Das Problem besteht zum aktuellen Zeitpunkt (20.12. 00:30 Uhr) immer noch. Übrigens: Zwischendurch fiel hier in Herne sogar das gesamte Telekom-Telefonnetz samt Notruf aus. Da ist doch irgendwas im Busch ...
Ein anderes hier im Forum geschildertes Problem deutet darauf hin, daß noch mehr Ungereimtheiten bei den SIP-Servern der Telekom bestehen. Gemeinsamkeit: Trat plötzlich auf und an der eigenen Hardware samt Konfiguration - die schon lange störungsfrei vor sich hin funktionierte - wurde nix geändert.
Und inzwischen habe ich durch eine Zufallsentdeckung einen Verdacht, woran es liegen könnte:
Ich habe nämlich genau an den Tagen, wo das Problem auftrat, immer von meiner Nextcloud-Instanz bei einem Hoster eine Email über ein 'verdächtiges Login von IP "soundso" ' bekommen. Das macht die Nextcloud-App "Suspicious Login".
Könnte es sein, daß auf den SIP-Servern der Telekom etwas Ähnliches läuft, und was die mir von der Telekom ja selbst zugeteilte IP-Adresse gegen eine Liste mit 'bösen' IPv4-Adressen prüft? Wobei genau diese Liste häufig veraltet ist, weil die Telekom ja recht intensiv Ex-Spammer-IPs einsammelt, diese IPs an die Kundschaft ausreicht und dann aber den eigenen 'braven' IP-Adressenpool verspätet den SIP-Servern zu Verfügung stellt.
Und genau ich kriege häufig die ehemals 'bösen' IPs zugeteilt.
Nur mal so als Idee...
Unlogged in user
Answer
from
1 year ago
Moin zusammen, ich hänge mich hier mal dran. Gab es jetzt eine Lösung für dieses Problem?
Ich habe das gleiche Problem mit den FRITZ!Fon Apps auf den Smartphones. Es wurde nichts verändert.
0
1 year ago
Nein, das Problem besteht immer noch. Mittlerweile ist durchgehend kein abgehender Anruf möglich, völlig egal, ob es ein gerader oder ungerader Tag ist. Angerufen werden klappt weiterhin einwandfrei, ebenso die reine SIP-Registrierung.
Ich hab natürlich noch ein bißchen was ausprobiert, aber ohne eine Lösung gefunden zu haben:
1.
Mal die totale Rufnummernsperre im Telefoniecenter aktiviert. Die Nacht über angelassen und am Mittag wieder ausgeschaltet. Hintergedanke: Es hätte ja sein können, daß die Datenbank hinter dem Telefoniecenter einen "Schluckauf" hatte und daß man das durch bewußte Konfiguration wieder gerade rückt. Leider nein...
2.
Das SNOM-Telefon mal zu einem anderen Telekom-Anschluß weiter weg mitgenommen und dort in die vorhandene Speedbox Smart 3 eingestöpselt. Kein Effekt, weil der Anschluß wohl nicht weit genug von hier einfernt war. Die kontaktierten SIP-Server waren nämlich immer noch dieselben (mit "dtm" im Namen, also wohl "Dortmund").
3.
Die Zoiper-App auf dem Smartphone installiert und mit den Zugangsdaten meiner dritten Rufnummer versorgt. Ergebnis: Das Raus-Telefonieren funktioniert, an Router oder DSL-Modem kann es wohl nicht liegen!
4.
Den DNS- Cache sowohl im Router als auch im Telefon gelöscht. Keine Besserung; aber es hätte ja sein können, daß aufgrund veralteter DNS-Einträge auf meiner Seite immer der SIP-Server kontaktiert wird, der nicht mehr für mich zuständig ist. Der Beitrag nebenan über die etwas "rumpeligen" DNS-Änderungen der Telekom für ihre SIP-Server im Dezember '23 brachte mich auf diese Idee.
Wahrscheinlich kommt man nur mit einer Aufzeichung des Rohdaten-Netzwerkverkehrs mit der anschließenden Verfütterung desselben an Wireshark weiter. Das ist mir ehrlich gesagt "too much".
Lieber wäre mir eine exakte Auflistung der Regeln, die die Telekom für die SIP-Kommunikation mit ihren Servern fordert, speziell wie es mit dem Zertifikatsaustausch und den Anforderungen für clientseitige Zertifikate läuft (mein neuer Verdacht ist, daß es da hakt). Aber da gibt's ja im Web nur "olle Kamellen" zu sehen. Hallo Teamies , wie wär's mal mit frischen Infos???
Grüße
Ingo
1
Answer
from
1 year ago
@coonabarabran
- Das sieht man bei den SNOM-Telefonen im Display: Angerufen werden -> Schloß, raus telefonieren -> kein Schloß.
Daraus schließe ich, daß dein SNOM als SIP-Transport TLS nutzt.
Seit geraumer Zeit setzt der Telekomserver bei SIP-Transport TLS und eingehenden Anrufen im SDP-Header RTP/SAVP (Schloß).
Ausgehende Anrufe hatten bei SIP-Transport TLS je nach Telekomserver sowohl mit RTP/AVP (kein Schloß) als auch RTP/SAVP funktioniert.
Jetzt funktioniert nur noch RTP/SAVP, ist also bei SIP-Transport TLS zwingend.
Lange Rede kurzer Sinn, RTP/SAVP ist bei SIP-Transport TLS Pflicht.
Die MediaSec Abhandlung scheint mir nicht ganz "einheitlich" gelöst zu sein.
Unlogged in user
Answer
from
1 year ago
Moin, ich konnte das Problem lösen. Bei mir lag es daran, dass Anrufe plötzlich verschlüsselt wurden. Im Router musste ich die Verschlüsselung der der Rufnummern in den SIP-Einstellungen aktivieren.
0
Accepted Solution
accepted by
1 year ago
So, inzwischen funktioniert das Heraus-Telefonieren wieder.
Die Lösung lautet:
Bei den „RTP“-Einstellungen einer jeden SIP-Identität die Option „RTP/SAVP“ auf „verbindlich“ einzustellen. Die beiden anderen möglichen Einstellungen „Aus“ und „optional“ bewirken weiterhin den Fehler 488. Die „RTP/SAVP“-Einstellungen hatte ich schon im Dezember durch-permutiert, damals allerdings ohne Effekt! Wahrscheinlich hat es zwischendurch noch ein weiteres Update der SIP-Server gegeben.
Damit stellt sich als Fehlerquelle das mangelhafte Parsen der SIP-Messages auf den Telekom-Servern heraus. Am Beispiel einer von meinem Telefon gesendeten INVITE-Message kann ich das zeigen. Bei „RTP/SAVP“ auf „optional“ werden von Telefon zwei Blöcke mit den möglichen Codecs direkt hintereinander gesendet; einmal mit der Zeile „a=crypto ...“ für die unterstützte Verschlüsselung [blau], einmal ohne diese Zeile [rot]. Bei „ RTP/SAVP“ auf „verbindlich“ wird nur der erste [blaue] Block gesendet.
BLAU und ROT führen zur Fehlermeldung 488, d.h. daß es dem Telekom-Server nicht gelingt, diese beiden Blöcke auseinanderzuhalten. Eigentlich eine programmiertechnische Standard-Aufgabe, die man im ersten Semester Informatik lernt...
Eine weitere Auffälligkeit bei der mangelhaften Input-Verarbeitung bei den SIP-Servern zeigt sich beim Block mit der „Authorization“ [in grün]. Das SNOM-Telefon liefert innerhalb der INVITE-Message auch gleich die Anmeldedaten aus der Registrierung mit. Für den Fall, daß es seit der Registrierung eine Verbindungsunterbrechung oder einen Timeout gegeben haben könnte.
Was macht aber der SIP-Server der Telekom? Obwohl eigentlich alles Notwendige übermittelt wurde, wird mit „SIP/2.0 407 Proxy Authentication Required“ noch einmal zurückgefragt, worauf dann das Telefon den grünen Block mit „ACK“ noch einmal sendet. Und die ursprüngliche INVITE-Message muß danach auch noch einmal gesendet werden. Überflüssigerweise!
2
Answer
from
1 year ago
Erstmal danke für deine Problemlösung. Ich hatte genau das gleiche Problem und konnte danke deines Threads dieses schnell lösen.
Ein riesen Kompliment auch dafür, dass Du dem Problem auf den Grund gegangen bist und sogar es für die Telekom Techniker erklärt hast. Wenn ich die Telekom wäre, würde ich Dir direkt ein Jobangebot machen. Aber ich bezweifle, dass die da so auf Zack sind
Answer
from
23 days ago
Einen aktuellen Nachtrag hätte ich noch: Durch ein bißchen Probieren habe ich festgestellt, daß es neuerdings zusätzlich auf das korrekte Setzen der Uhrzeit ankommt.
SNOM-Telefone zum Beispiel speichern die zuletzt mit einem NTP-Server synchronisierte Zeit ab. Schaltet man sie aus und - irgendwann - wieder ein, gehen sie zunächst von dieser Uhrzeit aus. Erst wenn sie wieder einen NTP-Server erreichen können - das kann aus verschiedenen Gründen schon mal dauern - ist die Uhrzeit korrekt. Das kann durchaus auch nach dem Registriervorgang bei den Telekom-SIP-Servern sein! Anrufe in der Zwischenzeit können mit 'nem 488-Fehler fehlschlagen.
Soooo ungewöhnlich ist das allerdings nicht: In anderen Bereichen der Internetkommunikation hingen Verschlüsselung und richtige Zeitstempel schon immer untrennbar zusammen.
HTH
Ingo
Unlogged in user
Answer
from
1 year ago
Danke für die Blumen! 😁
Zu dem Problem an sich hätte ich auch noch eine Neuigkeit - und eine Lösung (etwas unpraktisch, aber funktioniert):
Ab und zu kommt es vor, daß sowohl der SIP-Server der Telekom als auch das SNOM-Telefon einen Verbindungsaufbau mit dem SIP-Fehler 488 ablehnen. Egal von welcher Nummer oder SIP-Konto. Die Anruferin hört dann "... vorübergehend nicht erreichbar...". Ich würde auf eine "Meinungsverschiedenheit" tippen, was die Gültigkeitsdauer des jeweiligen Verschlüsselungs-Tokens (oder -Cookie; keine Ahnung wie das bei diesem Verfahren genau heißt) angeht.
Egal, es gibt eine definitiv funktionierende Lösung: Das Telefon neu starten. Dann sollte für den Rest des Tages alles geschmeidig funktionieren.
0
Unlogged in user
Ask
from