[VOIP/SIP] | Snom D785 & Telekom VoIP hinter NAT-Router registriert nicht

[freshprince2002]

Der Screenshot hilft nicht

Ein Problem bei der Telekom ist es nicht.
Das Telefon hat ein Problem mit der Telekom.
Wie gesagt, wenn das Telefon DNS NAPTR macht, kriegt es Serveradressen für SIPS/TLS Verbindungen mitgeteilt.

Ist aber inakzeptabel, wenn das Endgerät selbst und nur selbst aus Lust und Laune entscheidet, welches Protokoll es denn nutzt.
Zumindest wenn die SIPS/TLS Verbindung nicht klappt, muss es einen Fallback machen zum nächsten Service.
Macht es aber nicht. Wer weiß, wie es sich dann mit den SRV Records anstellt, wenn ein Server mal down ist.

So sieht so eine NAPTR Antwort vom DNS Server aus.
Hier wird die SIPS Adresse sogar mit höherer Priorität verteilt als die SIP UDP Adresse, ist zwar nicht optimal, aber am Ende ein Problem des Endgeräts.

 

[Quafi]

Also habe ich quasi keine Chance, das Gerät (ohne vorgeschaltete Telefonanlage) zum laufen zu bekommen?

 

[freshprince2002]

Wies aussieht, nein.

 

[Todek49]

Ich würde die Hoffnung nicht so schnell aufgeben.
In einem der geposteten Logs, ziemlich am Anfang dessen, sucht das Snom nach FW-Updates mit einer DNS-Abfrage für die Domain tel.t-online.de. Da wird es bestimmt keine FW-Dateien finden.
Und ich denke damit beginnt das ganze Unheil.
Ich würde noch einen Versuch starten mit Registrierungs-Server tel.t-online.de und Outboundproxy
ebenfalls tel.t-online.de (ohne irgenwelche Pre- bzw. Suffixe).
Die zu registrierende Nummer mit +49 davor und als Authentication User die Daten die Du vermutlich auch in den PPoE-Anmeldedaten im Draytek2862 benutzt plus dem Passwort.

Vorher solltest Du allerdings beim Snom in den Netzwerkeinstellungen den Eintrag im Domain-Feld entfernen.
Dein Snom ist genausowenig wie Deine Rechner Teil der Domain tel.t-online.de. Den DNS-Server1 auf die Lan-Adresse des Draytek 2862, also vermutlich 192.168.1.1 abändern, DNS-Server 2 freilassen. Für die Änderung der DNS Einträge muss das Snom aber neu gebooted werden.

Viel Erfolg

 

[freshprince2002]

In einem der geposteten Logs, ziemlich am Anfang dessen, sucht das Snom nach FW-Updates mit einer DNS-Abfrage für die Domain tel.t-online.de. Da wird es bestimmt keine FW-Dateien finden. Und ich denke damit beginnt das ganze Unheil.

Tatsache. Die Domain hat in den DNS Einstellungen da nix verloren.

Ich würde noch einen Versuch starten mit Registrierungs-Server tel.t-online.de und Outboundproxy
ebenfalls tel.t-online.de (ohne irgenwelche Pre- bzw. Suffixe).

Ja wer weiß, was die Domain in den DNS Einstellungen alles verursacht hat.
Es fehlt aber immer noch die Möglichkeit, das Transportprotokoll zu definieren.

als Authentication User die Daten die Du vermutlich auch in den PPoE-Anmeldedaten im Draytek2862 benutzt plus dem Passwort.

Unnötig. anonymous und ohne PW reicht aus.

Den DNS-Server1 auf die Lan-Adresse des Draytek 2862, also vermutlich 192.168.1.1 abändern, DNS-Server 2 freilassen. Für die Änderung der DNS Einträge muss das Snom aber neu gebooted werden.

Mir fällt grad ein, ich hatte mal einen Kunden mit einem Draytek Router vor einer TK-Anlage und der hat die NAPTR Requests nicht beantworten/weiterleiten können aus unbekannten Gründen. (Die Anlage hat den Draytek als DNS Server genutzt, habe dann die externen DNS Server in die Anlage eingetragen und das hat sich dann erledigt).
Wäre so vielleicht hier sogar ein Workaround, falls das Problem hier genauso auftritt.
Frage ist, wie das Telefon da reagiert, wenn keine NAPTR Responses kommen.

 

[Todek49]

Hi,
beim Authentication User hab ich eh daneben gelegen mit den PPoE-Daten, dort steht wahrscheinlich noch der
12-stellige Zahlenwust drin, gemeint habe ich eigentlich seine Kennung mit der er sich auch im Kundencenter
anmeldet, da ich nicht weiß ob er EasyLogin an hat im Kundencenter, BNG oder nicht ?.

Ich habe in den letzten 9-10 Jahren nur Draytek-Router im Einsatz gehabt, 2750, 2850 mit 130 als Modem davor,
und aktuell einen 2132ac ebenfalls mit dem 130 davor.
Nach einem Gigaset C610IP, kein SIPS/SRTP und dauernde Akku-Probleme, bin ich Mitte letzten Jahres dann auf ein Yealink T41P gegangen. Dort kann man für jeden Account einstellen welches Transport Protokoll verwendet wird. TLS verwende ich bei DUS.net, weder die Telekom noch Sipgate unterstützen das bis jetzt, die mögen nicht mal TCP nur UDP wird dort akzeptiert.

Ich weiß nicht ob er beim Draytek in den LAN-Einstellungen die DNS Server erzwingt oder ob er die von der Telekom durchgereichten beibehält, vermutlich wo sollte er sonst die beide IP-Adressen her haben. Ich habe
schon seit Jahren dort die OpenDNS Server drin und nie Probleme bei der Registrierung der Telefone gehabt.

Gruß
Theo

 

[freshprince2002]

Man braucht keine Authentifizierungsdaten. Weder die Mailadresse, noch Zugangsnummer oder sonst was.
Das wird erst benötigt, wenn man die Rufnummer nomadisch an einem anderen Anschluss registrieren will.

TCP unverschlüsselt geht aktuell. Aber eben nicht mit TLS.

Wenn man Telekom VoIP nutzt, sollte das Gerät auch die Telekom DNS Server nutzen und keine anderen.
(Oder den Router als DNS Server, wenn der die Telekom DNS Server nutzt.)
Fremde DNS Server verteilen andere SIP Server Adressen. Gründe geheim

 

[TheCadillacMan]

Hab mal mein Snom 320 raus gekramt und den Fehler nachstellen können.
Was mich gewundert hat war, dass trotz tel.t-online.de;transport=tcp als Outbound-Proxy SIPS aus dem SRV-Eintrag genommen wurde.

Die Lösung ist recht einfach: Der Transport wird nur berücksichtigt, wenn auch eine Port-Nummer angegeben wird. Siehe How to Force SIP over UDP.
Mit tel.t-online.de:5060;transport=tcp als Outbound-Proxy funktioniert die Registrierung über TCP dann auch einwandfrei.

Hier wird die SIPS Adresse sogar mit höherer Priorität verteilt als die SIP UDP Adresse, ist zwar nicht optimal, aber am Ende ein Problem des Endgeräts.

Ich finde das schon optimal. Die Reihenfolge für SIP sollte SIPS > TCP > UDP sein.

Für Media (RTP) ist die Latenz kritisch, sodass UDP schon das richtige Protokoll ist.
Das Signaling (SIP) sollte meiner Meinung nach aber wenn möglich über TCP laufen, weil der Overhead für dabei zu vernachlässigen ist und hier ein zuverlässiges Protokoll sinnvoll ist.
Ich hatte tatsächlich schon Situationen in denen verlorene SIP-Pakete merkwürdige Effekte ausgelöst haben. Mit TCP kann das nicht passieren.

 

[freshprince2002]

Die Lösung ist recht einfach: Der Transport wird nur berücksichtigt, wenn auch eine Port-Nummer angegeben wird. Siehe How to Force SIP over UDP.
Mit tel.t-online.de:5060;transport=tcp als Outbound-Proxy funktioniert die Registrierung über TCP dann auch einwandfrei.

Das hatten wir schon in Post 8

 

[TheCadillacMan]

Das hatten wir schon in Post 8

Der Port oder "transport" alleine reichen nicht. Ich hatte den Eindruck dass @Quafi beides gemeinsam (also tel.t-online.de:5060;transport=tcp) noch nicht probiert hat.
Und wie gesagt: Bei mir hat das den reproduzierten Fehler gelöst.

 

[Quafi]

Hej! Ich melde mich nochmal gerade zurück!
Es funktioniert inzwischen und fragt bitte nicht wieso.
Ich habe die Daten wie jetzt hier noch von euch vorgeschlagen wurde, angegeben, die DNS-Server auf die Telekom geändert (bzw. einfach frei gelassen und automatisch beziehen lassen).
SIP over UDP zu erzwingen war nicht mehr notwendig, das hat er irgendwie schon selbst geregelt. Es reichte, einfach tel.t-online.de anzugeben, ohne irgendwas drumherum.

Ich kann fast 100%ig garantieren, es schonmal genauso eingestellt gehabt zu haben, ohne Erfolg. Werde mich morgen nochmal bei der Telekom melden und fragen, ob die etwas umgestellt haben, da ein Techniker von Snom bezüglich meines Problems noch mit denen in Kontakt steht.

Jedoch werde ich den Spaß bald sehr wahrscheinlich sowieso neu einstellen dürfen, da ich dann über einen Geschäftsanschluss verfügen werde

Aber ich bedanke mich für die rege Mithilfe hier! Danke!
Ohne euch wäre ich hier wahrscheinlich auf der Fehlersuche eingegangen

 

[freshprince2002]

Die Telekom hat nichts geändert.
Und selbst wenn, die an der Hotline haben keine Ahnung davon, wie, wann und was auf der VoIP Plattform sich verändert.

 

[Quafi]

Die Telekom hat nichts geändert.

Falsch!
Ich habe gerade erfahren, dass in den letzten Tagen von der Telekom SIP-over-TLS freigeschaltet wurde. Dadurch funktioniert es jetzt offensichtlich.

 

[freshprince2002]

Ist nur für Experimente in Laborumgebungen, nix Finales.
Wunder dich nicht, wenn es in ein paar Tagen/Wochen wieder nicht geht.

Und fehlerfrei/stabil muss die verschlüsselte Telefonie auch nicht funktionieren.

 

[Quafi]

Du willst mich auf den Arm nehmen.

Ernsthaft jetzt? xD

 

[freshprince2002]

Ernsthaft.
Bei MSN Anschlüssen steht die Verschlüsselung auch in keiner Leistungsbeschreibung.
Nur beim SIP-Trunk, der läuft aber auf einer ganz anderen technischen Plattform als die MSN Anschlüsse.
Bei MSN Anschlüssen wird das aktuell bei der Telekom in Laboren getestet. Wann es offiziell freigegeben wird, ist nicht genau definiert.

Verschlüsselung bringt aber sowieso nix, da es keine Ende-zu-Ende Verschlüsselung ist.
Nur, wenn du so paranoid bist und denkst, jemand Fremdes kommt unbemerkt an deinen Router ran und schneidet da deine Telefonate mit

Bring das Telefon dazu, via UDP zu kommunizieren, wie es sich für einen normalen SIP Client gehört.
TCP (unverschlüsselt) als Notlösung, da das auch noch experimentell ist.