‎Von gestern auf heute: 'SIP/2.0 488 Not Acceptable Here - security violation'

Telekom hilft Community

Telekom Business Community

Private customers

Telekom Shops

Contact

Solved

Von gestern auf heute: 'SIP/2.0 488 Not Acceptable Here - security violation'

2 years 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

2225

Accepted Solution
accepted by
2 years 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...

INVITE sip:*21*02...........@tel.t-online.de;user=phone SIP/2.0

….....
[GRÜN]

Authorization: Digest username="d........@t-online.de",realm="tel.t-online.de",nonce="4e42........................",uri="sip:*21*02...........@tel.t-online.de;user=phone", qop=auth,nc=00000002,cnonce="30c5aa5d",response="ba01......",algorithm=MD5
Content-Type: application/sdp
Content-Length: 1454

[BLAU]

v=0
o=root …..
s=call
c=IN IP4 …...
t=0 0
m=audio 62164 RTP/SAVP 9 8 0 119 118 99 100 111 112 3 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:45em..........
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
…....
[ROT]

m=audio 62164 RTP/AVP 9 8 0 119 118 99 100 111 112 3 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
.......
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!
4
Answer
from
4 months 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
Answer
from
25 days ago
Du bist mein Held des Tages. Zwei Stunden suche ich bereits den Fehler, warum trotz scheinbar korrekter Konfiguration kein Gespräch rausgeht. Dein Beitrag hat mir also auch im Jahr 2025 noch geholfen, vielen Dank!
0
Answer
from
25 days ago
Hallo @dpachehl!

dpachehl

Du bist mein Held des Tages. Zwei Stunden suche ich bereits den Fehler, warum trotz scheinbar korrekter Konfiguration kein Gespräch rausgeht. Dein Beitrag hat mir also auch im Jahr 2025 noch geholfen, vielen Dank!

Du bist mein Held des Tages. Zwei Stunden suche ich bereits den Fehler, warum trotz scheinbar korrekter Konfiguration kein Gespräch rausgeht. Dein Beitrag hat mir also auch im Jahr 2025 noch geholfen, vielen Dank!

dpachehl
Du bist mein Held des Tages. Zwei Stunden suche ich bereits den Fehler, warum trotz scheinbar korrekter Konfiguration kein Gespräch rausgeht. Dein Beitrag hat mir also auch im Jahr 2025 noch geholfen, vielen Dank!

Klasse & toll, dass es Tipps und Tricks gibt, die einfach zeitlos sind. :) Ich erwähne auch eben @coonabarabran, damit er auch weiß, dass er der Held des Tages ist. :)

Greetz

Stefan
Unlogged in user
Answer
from