crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
13.05.2018 19:53
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!
Gelöst! Gehe zu Lösung.
22.05.2018 20:58 Zuletzt bearbeitet: 22.05.2018 21:30 durch den Autor
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)
13.05.2018 20:42
@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
13.05.2018 21:25
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??
13.05.2018 21:47
@Alu15, @Boilermaker und @UlrichZ, neulich habe ich bereits jemanden mit seinem SNOM kämpfen sehen ...
13.05.2018 22:30
13.05.2018 23:13
Vielleicht ein Einstellungsfehler bei tls ?
14.05.2018 05:09 Zuletzt bearbeitet: 14.05.2018 05:09 durch den Autor
@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
14.05.2018 21:38
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.
14.05.2018 22:59
Und wenn du tls mal ausmachst (als Fallback)...
14.05.2018 23:11
14.05.2018 23:16
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.
15.05.2018 12:06
Boilermaker schrieb: Wäre super, wenn jemand einen Tipp hat.
15.05.2018 21:47
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...
15.05.2018 22:12
Danke für das Feedback @Alu15.... also vermutlich veraltetes Protokoll oder Ähnliches....
16.05.2018 06:08 Zuletzt bearbeitet: 16.05.2018 06:45 durch den Autor
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.
16.05.2018 06:42
16.05.2018 06:51 Zuletzt bearbeitet: 16.05.2018 06:53 durch den Autor
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.
16.05.2018 15:57 Zuletzt bearbeitet: 16.05.2018 16:00 durch den Autor
@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
16.05.2018 21:49
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:
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.
16.05.2018 22:52 Zuletzt bearbeitet: 16.05.2018 23:15 durch den Autor
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 ...
17.05.2018 05:26
@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.
@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
17.05.2018 06:42
@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.
17.05.2018 06:45
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.
17.05.2018 07:16 Zuletzt bearbeitet: 17.05.2018 07:16 durch den Autor
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).
17.05.2018 09:07
@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
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.