Registrierung snom370 nicht mehr erfolgreich

Boilermaker · ‎13.05.2018

Hallo,

seit ca. 1 Woche funktioniert die Registrierung meines snom370 (mit Speedport W724V) nicht mehr. (Vorher war alles einwandfrei.)

Im Log des snom 370 finde ich folgende Infos:

May 13 19:17:29 [DEBUG1] SIP: route pending packet 1000027: entry=a tls h2-eps-608.edns.t-ipnet.de 5061 all 2
May 13 19:17:29 [DEBUG1] SIP: route pending packet 1000027: entry=tls 217.0.3.244 5061 all 2
May 13 19:17:29 [DEBUG2] SIP: Socket 169/connecting tls:192.168.2.108:1089 -> tls:217.0.3.244:5061
May 13 19:17:29 [DEBUG0] TLS: 0xa0fb00 HandShake Tx: max (invalid) -> idle
May 13 19:17:29 [DEBUG0] TLS: 0xa0fb00 HandShake Rx: max (invalid) -> idle
May 13 19:17:29 [DEBUG0] TLS: 0xa0fb00 HandShake Tx: idle -> client_hello_sent
May 13 19:17:29 [DEBUG2] SIP: Socket 169/connected tls:192.168.2.108:1089 -> tls:217.0.3.244:5061
May 13 19:17:29 [DEBUG2] SIP: Updated Transport 0xa81cc8 TTL 60
May 13 19:17:29 [DEBUG1] SIP: route pending packet 1000027: entry=tls 217.0.3.244 5061 all 2
May 13 19:17:29 [DEBUG1] SIP: Identity connection id tls:217.0.3.244:5061
May 13 19:17:29 [DEBUG0] SIP: Use Connection tls:217.0.3.244:5061 for packet 1000027
May 13 19:17:29 [DEBUG0] SIP: send REGISTER (8: 3934363638343834343138333133-653txj68kh5x) -> tls:217.0.3.244:5061
May 13 19:17:29 [DEBUG2] SIP: Updated Transport 0xa81cc8 TTL 60
May 13 19:17:29 [DEBUG2] SIP: Socket 169/disconnected tls:192.168.2.108:1089 -> tls:217.0.3.244:5061
May 13 19:17:29 [INFO ] SIP: Transaction timeout on packet 1000027 due to transport error
May 13 19:17:29 [NOTICE] SIP: transaction timeout tcp/tls: 1000027
May 13 19:17:29 [ERROR ] SIP: final transaction timeout 1000027 (tls:217.0.3.244:5061 3934363638343834343138333133-653txj68kh5x)
May 13 19:17:29 [NOTICE] SIP: Add dirty host: tls:217.0.3.244:5061 (0 sec)

Wäre super, wenn jemand einen Tipp hat.

Danke im Voraus!

Boilermaker · ‎22.05.2018

Danke für den Hinweis, dass der Speedport auch einen trace ziehen kann. Das Feature war mir neu.

Positiv ist, dass auf VDLS deutlich weniger Pakete verschickt werden als im LAN.

In wireshark habe ich gesehen, dass der SIP Server eine 'fatal' Fehlermeldung 'protocol version' zurück liefert.

D.h. im Mai 2018 ist es hier wohl zu einer Änderung der Protokollversion gekommen.

Nach meiner Beobachtung scheinen solche Änderungen alle paar Jahre aufzutreten...

Da mein VoIP Endgerät inzwischen nicht mehr weiter entwickelt wird, bleiben die Optionen

a) ein neues VoIP Endgerät anzuschaffen (regelmässig)

b) Nutzung eines VoIP PBX Service (monatliche Zusatzkosten)
c) ein analoges Endgerät anzuschaffen (einmalig, geringer Funktionsumfang)
d) ein DECT Endgerät anzuschaffen (einmalig)

Lösung in ursprünglichem Beitrag anzeigen

UlrichZ · ‎13.05.2018

@Boilermaker schrieb:

seit ca. 1 Woche funktioniert die Registrierung meines snom370 (mit Speedport W724V) nicht mehr.

Um welchen Speedport handelt es sich denn, klicke dazu auf den Link in Meiner Signatur und schaue oben unter Name des Gerätes.

Gruß Ulrich

Alu15 · ‎13.05.2018

Habe seit dem 05.05.2017 ähnliches Problem mit meinem Snom 370. Keine Anmeldung mehr.

Router ist eine ASUS DSL-AC68U. Telekom weis natürlich von nichts. Folgende Fehlermeldung:

May 13 21:17:21.625 [NOTICE] SIP: transaction timeout tcp/tls: 1001437

May 13 21:17:21.626 [NOTICE] SIP: Add dirty host: tls:217.0.20.212:5061 (0 sec)

May 13 21:17:21.698 [NOTICE] SIP: transaction timeout tcp/tls: 1001437

May 13 21:17:21.699 [NOTICE] SIP: Add dirty host: tls:217.0.3.228:5061 (0 sec)

May 13 21:17:21.773 [NOTICE] SIP: transaction timeout tcp/tls: 1001437

May 13 21:17:21.774 [ERROR ] SIP: final transaction timeout 1001437 (tls:217.0.3.244:5061 313532363032373035333530383131-6dmtvqg4kg2a)

May 13 21:17:21.775 [NOTICE] SIP: Add dirty host: tls:217.0.3.244:5061 (0 sec)

May 13 21:17:21.776 [NOTICE] SIP: final transport error: 1001437 -> tls:217.0.3.244:5061

May 13 21:17:21.777 [ERROR ] SIP: transport error 1001437: generating fake 597

Wer kann helfen??

sg-flinux · ‎13.05.2018

@Alu15, @Boilermaker und @UlrichZ, neulich habe ich bereits jemanden mit seinem SNOM kämpfen sehen ...

Suchergebnis

Boilermaker · ‎13.05.2018

- Speedport W724V Typ A (FW-Stand von 11/2017: 05011603.05.028)
- snom370 FW 8.7.3.25 (Update auf 8.7.5.35 heute ohne Effekt)

buenni · ‎13.05.2018

Vielleicht ein Einstellungsfehler bei tls ?

UlrichZ · ‎14.05.2018

@Boilermaker & @Alu15: Was sagt den SNOM zu diesen Fehlermeldungen? Meines Wissens nutzt die telekom, worauf auch @buenni verwies, inzwischen Transportverschlüsselung zum SIP-Server. Evtl. muss im SNOM Telefon das entsprechend angepasst werden.

Gruß Ulrich

Boilermaker · ‎14.05.2018

Hallo Ullrich,

Hallo buenni,

Danke für die Fragen.

TLS wird grundsätzlich verwendet. (http://wiki.snom.com/Category:HowTo:TLS )

Testweise habe ich auf Eure Frage hin Server Authentication eingeschaltet (tls_server_authentication!: on) - das Telefon zeigt das gleiche Verhalten.

Die sonstigen TLS-Einstellungen sind:

ldap_over_tls!: off

empty_tls_client_cert!: off

xcap_via_tls!: on

Im SIP trace sehe ich, dass der client (das snom) eine Registrierungsanfrage sendet aber keine Antwort bekommt...

Sent to tls:217.0.3.228:5061 at May 14 21:08:46 (746 bytes):

   REGISTER sip:tel.t-online.de SIP/2.0
   Via: SIP/2.0/TLS 192.168.2.108:2959;branch=z9hG4bK-qygfay7znsyq;rport
   From: <sip:0xxxxxxxxx@tel.t-online.de>;tag=fb78plz35u
   To: <sip:0xxxxxxxxx@tel.t-online.de>
   Call-ID: 313532363332343535383236333831-qx2glbqf6l3e
   CSeq: 3 REGISTER
   Max-Forwards: 70
   User-Agent: snom370/8.7.5.35
   Contact: <sip:0xxxxxxxxx@192.168.2.108:2959;transport=tls>;reg-id=1;q=0.0;+sip.instance="<urn:uuid:bcc48f28-0b7d-4d80-87b3-0004132656C2>";audio;mobility="fixed";duplex="full";description="snom370";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
   Allow-Events: dialog
   X-Real-IP: 192.168.2.108
   Supported: path, gruu
   Expires: 3600
   Content-Length: 0

P.S. Da ich mich im snom User Forum nicht registrieren kann, konnte ich dort keinen Eintrag posten.

buenni · ‎14.05.2018

Und wenn du tls mal ausmachst (als Fallback)...

Boilermaker · ‎14.05.2018

TLS abschalten will ich nicht - Basis-Datenschutz sollte mit Telekom möglich sein.

Für mich ist die Frage, was am Telekom SIP Server geändert wurde, das Problem ist ja offensichtlich kein Einzelfall.

buenni · ‎14.05.2018

Ggf unterstützt das SNOM nicht den aktuellsten Standard und deswegen klappt es nicht. Nach dem Motto, wenn tls dann nur ganz aktuell, ansonsten nur ohne (für Hardware die kein tls kann) .

damit kannst du dann testen wo das Problem liegt... muss ja nicht so bleiben.

Stefan D. · ‎15.05.2018

Hallo @Boilermaker!

Boilermaker schrieb: Wäre super, wenn jemand einen Tipp hat.

Danke für die bisherigen Ideen.

Kann ich noch wo weiterhelfen?

Greetz
Stefan D.

Alu15 · ‎15.05.2018

Hi

habe mir ein neues Snom D710 besorgt.

Nach Installation selbe Fehlermeldung wie oben (transaction timeout tcp/tls: 1001437...). Nach Aufspielen der neusten Firmware funktioniert das Telefon ohne Probleme.

Scheint also eher ein Snom 370 Problem zu sein...

buenni · ‎15.05.2018

Danke für das Feedback @Alu15.... also vermutlich veraltetes Protokoll oder Ähnliches....

Boilermaker · ‎16.05.2018

Hallo @Alu15,

schön, dass eine neue FW Version Dir geholfen hat.

Ein timeout ist ein sehr allgemeiner Fehler und kann sehr viele Ursachen haben. Dein Schluss, dass an der FW liegt, mag stimmen, es mag aber auch an der SIP Server SW liegen oder an der SIP Server Konfiguration oder an der Provisionierung des Endgerätes.

In der Telekom-Welt werden VoIP Endgeräte vor einer Systemfreigabe leider nicht gestestet und von daher sind solche Überraschungen leider immer wieder gegeben. Ich habe das jetzt alle 2..3 Jahre erlebt.

@UlrichZ: ich bin verwundert, dass Du diesen Hinweis als Lösung gekennzeichnet hattest - aus meiner Sicht ist es keine Lösung. Die Lösungssetzung sollte bitte demjenigen obliegen, der das Problem hat:

@Stefan D.: ich suche weiter nach Infos was sich vor 10 Tagen geändert hat.

Alu15 · ‎16.05.2018

Nein, nein, meine Antwort ist nicht die Lösung. Würde gerne mein Snom 370 wieder zum Arbeiten bringen.
An dem blöden Snom ist ein Jabra headset verbunden (kriege diese Verbindung nur mit dem Snom hin), so dass ich eine Lösung brauchte. Darum das Snom D710.
Das Problem liegt zwischen dem Snom 370 und der Telekom. Denke auch, dass irgend eine Einstellung bei der Telekom verändert wurde. Sonst ist ja das Problem bei verschiedenen Users mit dem Snom 370 nicht zu erklären. Habe ja dort angerufen, aber das ist sinnlos ("habe ihr Problem noch nie gehört…und …die meisten user benutzen Telekom Geräte"). Habe die naive Vorstellung, dass die Telekom eine System hat, wo alle Veränderungen hinterlegt sind. Wird zu mindestens in fast allen anderen Industrien so zwingend verlangt.

buenni · ‎16.05.2018

Die Telekom hat ihre Schnittstellenbeschreibungen jeweils aktuell veröffentlicht.

Es obligt dem Hersteller (hier SNOM) für seine Kunden die Kompatibilität herzustellen bzw. seine Geräte aktuell zu halten.

ich würde an eurer Stelle die Traces Richtung SNOM zur Analyse schicken, damit die das fixen können.

oder ihr vergleicht die Einstellungen / Traces zwischen altem SNOM und neuem. Vielleicht sehr ihr ja selber den Unterschied und könnt das alte SNOM entsprechend anpassen.

UlrichZ · ‎16.05.2018

@Boilermaker schrieb:

In der Telekom-Welt werden VoIP Endgeräte vor einer Systemfreigabe leider nicht gestestet

Diese Aussage ist so allgemein nicht richtig. Zum einen ist die Telekom verpflichtet, Schnittstellenbeschreibungen Ihrer Anschlüsse offenzulegen, damit jeder Hersteller sein Endgerät entsprechend für einen Telekomanschluss auslegen kann.

Zum anderen bietet die Telekom Herstellern die Möglichkeit, ihre Endgeräte auf Kompatibilität/Interoperabilität zu testen. Viele Hersteller machen damit dann auch Werbung.

Wenn die Hersteller diese Möglichkeiten nicht nutzen, ist nicht die Telekom schuld.

@Boilermaker schrieb:

@UlrichZ: ich bin verwundert, dass Du diesen Hinweis als Lösung gekennzeichnet hattest - aus meiner Sicht ist es keine Lösung. Die Lösungssetzung sollte bitte demjenigen obliegen, der das Problem hat:

Wenn ein anderes SNOM-Produkt nach(!) Firmware-Update plötzlich wieder funktioniert, gehe ich davon aus, dass es sich um ein Firmware-Problem handelt. Was sagt denn SNOM zu Deinem Problem.

Gruß Ulrich

Boilermaker · ‎16.05.2018

Buenni und Ulrich,

ich finde gut, dass Ihr in Euren letzten beiden Kommentare ausführlich Euer Verständnis beschrieben habt.

Leider sind Eure Hinweise im konkreten Fall nicht zielführend. Für die Transparenz und ein besseres Verständnis gehe ich gerne darauf ein:

@buenni

Wenn Ihr von der Telekom Schnittstellenbeschreibungen zu den Änderungen von 05/2018 habt, wäre super wenn Ihr diese kommuniziert.
In dem verschickten link ist das letzte Änderungsdatum von 05/2017.
Da vom SIP Server keine Antwort kommt, ist es nicht hilfreich den pcap-trace an SNOM zu schicken.
(Das SNOM-Endgerät läuft wie geschrieben in einen timeout und ich kann nur traces bei mir ziehen.)
Der Vorschlag, dass ich die traces alt vs. neu selber vergleiche, funktioniert leider nicht, da ich in 09/2016 keinen trace gezogen habe.

@UlrichZ

Ich habe keinem der Komponenten-Lieferanten (Telekom oder Snom) eine "Schuld" gegeben. (Du verwendest diesen Begriff.)
Ich sehe aber klar die Telekom als denjenigen, der die Änderung ausgelöst hat.
Erläuterung: Da nachweisbar ist, dass sich am VoIP Endgerät seit 09/2016 nichts geändert hat, und auch der Speedport FW Stand von 11/2017 ist, bleibt die einzige logische Erklärung eine Änderung am SIP-Server in 05/2018 (SW, Konfiguration).
Ohne in die Architekturdetails zu gehen, sollte dies nachvollziehbar sein.
Danke für den Hinweis zum IP Testcenter / 3rd Party Lab der Telekom.
Super wäre, wenn Du eine Liste von zertifizierten VoIP Endgeräte hättest.
(Mir ist nur die Info zu analogen Endgeräten der Telekom bekannt.)
Einmalige Interoperabilitätstests sind gut aber leider nicht ausreichend - wie mein Beispiel zeigt.
Deswegen beziehe ich mich auf "Systemtests", die dann auch bei den laufenden Systemupdates durch den Systemlieferanten erfolgen.
Das Thema Interoperabilität und Test bei VoIP ist leider komplex.
Die Hinweise von @Alu15 bezogen sich auf ein anderes Endgerät und ein anderes Problem, daher hier - wie von ihm bestätigt - leider keine Lösung.

Ich hoffe, dass die Erläuterungen dem Verständnis helfen - das Problem bzw. Ursache scheint nicht trivial zu sein.

Ich bin an einer sachlich orientierten Suche interessiert und freue mich über kompetente Ratschläge.

Wie geschrieben, werde ich mich insbesondere über Infos freuen, was sich in 05/2018 geändert hat.

buenni · ‎16.05.2018

Hi,

wenn Du bei Google "Schnittstellenbeschreibung" und "telekom" eingibst landest Du auf https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-telefonanlagen/s....

Wenn Du damit nicht weiterkommst, solltest Du dich echt an SNOM wenden.

Selbst wenn es nur eine kleine Änderung an der Telekom Schnittstelle gab, die jetzt Endgeräte blockt, die sich nicht schnittstellenkonform verhalten, muss diese Schnittstelle doch in jeder Hinsicht der Schnittstellenbeschreibung entsprechen. d.h. SNOM muss "einfach" gegen die letzte veröffentlichte Version die Kompatibilität testen.

PS... schau doch mal ob Du im Menü bei SNOM abgelehnte Zertifikate / geblockte IP-Adressen findest....

"All rejected certificates are listed in the Unknown Certificates tab. If you want to permanently trust a certificate you can add it as an exception"

und ansonsten schaust Du Dir die Traces von Deinem Snom an und vergleichst sie mit den Beispielen hier... vielleicht fällt Dir ja etwas auf...

https://www.telekom.de/hilfe/downloads/1tr114-v300-amendment-7.pdf

Du kannst mir auch gerne mal einen Trace und/oder Deine Einstellungen per PN schicken, dann helfe ich gerne ...

UlrichZ · ‎17.05.2018

@Boilermaker schrieb:

Ich habe keinem der Komponenten-Lieferanten (Telekom oder Snom) eine "Schuld" gegeben. (Du verwendest diesen Begriff.)

Na ja, Dein Satz:

@Boilermaker schrieb:

In der Telekom-Welt werden VoIP Endgeräte vor einer Systemfreigabe leider nicht gestestet

suggeriert das aber für mich. Du schreibst nicht von Vodafone-Welt oder Netcologne-Welt ... oder allgemein in der Telekommunikations-Welt.

@Boilermaker schrieb:

Danke für den Hinweis zum IP Testcenter / 3rd Party Lab der Telekom.
Super wäre, wenn Du eine Liste von zertifizierten VoIP Endgeräte hättest.
(Mir ist nur die Info zu analogen Endgeräten der Telekom bekannt.)

Nein, eine Liste der getesteten Geräte ist mir nicht bekannt. Ich sehe nur, dass SNOM bislang diese Testmöglich nicht genutzt hat.

https://geschaeftskunden.telekom.de/startseite/festnetz-internet/tarife/sonderdienste/349882/3rd-par...

@Boilermaker schrieb:

Ich sehe aber klar die Telekom als denjenigen, der die Änderung ausgelöst hat.
Erläuterung: Da nachweisbar ist, dass sich am VoIP Endgerät seit 09/2016 nichts geändert hat, und auch der Speedport FW Stand von 11/2017 ist, bleibt die einzige logische Erklärung eine Änderung am SIP-Server in 05/2018 (SW, Konfiguration).
Ohne in die Architekturdetails zu gehen, sollte dies nachvollziehbar sein.

Ich bin kein Telekom-Mitarbeiter, kann zu möglichen Änderungen also überhaupt nichts sagen. Andererseits schließe ich daraus, weil hier nicht Millionen von FRITZ!Box- und Speedport-Kunden, die direkt ihren jeweiligen Router als VoIP-Telefon nutzen, von plötzlichen VoIP-Telefonie-Problemen berichten, dass eine mögliche Änderung (evtl. Aktivierung der Transportverschlüsselung*) von deren Hardware "akzeptiert" wird. Für mich liegt es dann eher an der SNOM-Hardware liegen.

*)Kannst Du die Transportverschlüsselung am SNOM-Telefon testweise deaktivieren?

Gruß Ulrich

Boilermaker · ‎17.05.2018

@UlrichZleider führen Deine Diskussionsbeiträge nicht weiter.

Da es in dieser Anfrage um technische Probleme und nicht um Vermutungen und politische Diskussionen geht, wäre super, wenn Du Dich in dieser Anfrage nicht weiter beteiligst. Gerne kannst Du dazu einen eigenen Beitrag aufmachen, in dem solche Punkte dann diskutiert werden.

Danke für Dein Verständnis.

Boilermaker · ‎17.05.2018

@buenni

Zertifikate: Es gibt keine abgelehnten Zertifikate.

Wenn Du mir Deine PN (?) zukommen lässt, schicke ich Dir gerne einen Trace oder auch die Einstellungen. Vielleicht fällt Dir etwas auf.

wari1957 · ‎17.05.2018

@Boilermaker

Warum stellst du dein SNOM nicht auf Protokoll UDP oder TCP?

Bei meinem Anschluß war vor etlichen Tagen auch keine TLS Verbindung mehr möglich.

Was an deinem Anschluß möglich ist, lässt sich ganz einfach mit dem Befehl dig überprüfen.

Man sieht, mittlerweile sind wieder alle "Dienste" verfügbar, von der Priorität her: TLS (10), UDP (20) und TCP (30).

UlrichZ · ‎17.05.2018

@Boilermaker schrieb:

@UlrichZleider führen Deine Diskussionsbeiträge nicht weiter.

Da es in dieser Anfrage um technische Probleme ...

Und warum gehst Du dann nicht auf meinen Vorschlag ein, die Transportverschlüsselung (TLS) testweise mal zu deaktivieren?

Gruß Ulrich

Registrierung snom370 nicht mehr erfolgreich

Social Media