iqnetwork schrieb:
Noch einen Nachtrag: Heute morgen stand auf dem Display des Telefons: Low Memory.
An der Konsole eines Bintec-Routers sieht man bei einem DEBUG ALL &, dass das Snom tausende UDP-Verbindungen auf Port 5060 des SIP-Servers eröffnet! Dass das Snom dann irgendwann mit LowMem umkippt ist doch klar.
iqnetwork schrieb:
Wenigstens konnte man das Teil ohne auszustecken neu booten.
Das ging bei mir nicht mehr, wenige Sekunden nach dem Start zeigte es keine Reaktion mehr. Ich musste das Snom booten und mich dann gleich am Anfang nach dem Start sofort durchs Menü hacken, um die Konfiguration des Snom zu löschen, sonst ist das Snom gleich wieder Amok gelaufen und abgestürzt.
iqnetwork schrieb:
Ich glaube nicht nur die Dokumenntation von 1und1, resp. alle aderen Provider ist unter aller Sau, auch die Firmware des Snoms.
Es muss in erheblichen Teilen das Snom sein. Wir haben eine Fritz Box Fon hinter dem gleichen Router getestet. Siehe auch
http://www.ip-phone-forum.de/forum/viewtopic.php?p=204004 Dabei haben wir festgestellt, dass die FBF kein STUN braucht, obwohl sie hinter einer NAT arbeitet und kein UPnP aktiv ist. Das Snom macht ohne STUN aber gar nichts, weil es sich immer mit seiner eigenen privaten Adresse beim SIP-Server registrieren will. Portforwardings helfen auch nichts, da von den SIP-Servern überhaupt keine Anfragen auf irgendwelche Ports gesendet werden.
Ergebnis: Das Snom kann abgehend wählen und es klingelt am Ziel. Das Snom bekommt aber nicht mit, dass es am Ziel klingelt (kein Rufton) und dass das Ziel abgenommen hat (man hört das Ziel nicht). Es bekommt auch nicht mit, wenn das Ziel wieder aufgelegt hat. Während der gesamten Verbindung kommt keine einzige Verbindungs-Anfrage oder -Antwort der SIP-Server beim Snom an. Wahrscheinlich liegt das daran, dass der SIP-Server vom Snom gar nicht erfahren hat, wohin er antworten soll.
iqnetwork schrieb:
Habe auch die neuen Betas erfolglos getestet.
Ich habe vor zwei Monaten mal ausführlich getestet und gestern, nachdem wir eine Fritz Box Fon mal hinter einem Bintec ausführlich beobachtet haben wieder. Letze Beta und letzten offiziellen Release haben wir ausführlichst durchgekaut. Fehler wie oben beschrieben.
iqnetwork schrieb:
Bintecs aussage dazu: Man braucht kein Portforwarding machen, Stun erledigt alles. Das Stuninterval muss nur auf 10 Sekunden stehen.
Du meinst sicher die Anleitung
http://www.funkwerk-ec.com/index.php?seite=faq_bintec_179_voip_elmeg_c290_01_de&navigation=5860 Bei sipgate mag das funktionieren, aber bei 1&1 (Schlund, GMX) nicht.
Aber in dem Debug-Protokoll steht was wirklich sehr interessantes:
00:04:10 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.100.2:2051/84.149.228.165:32777 -> 10.254.146.202:5060
00:04:10 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.100.2:2051/84.149.228.165:32778 -> 192.168.1.1:5060
Ziel der abgehenden Verbindungen von 84.149.228.165 ist der UDP Port 5060 auf 10.254.146.202 bzw. 192.168.1.1. Seit wann ist sipgate.de über private Netzwerkadressen im Internet erreichbar? Wie also soll das bitte jemals bei denen funktionert haben? Wollen die uns hier für dumm verkaufen?
iqnetwork schrieb:
Ich finde es eine Frechheit, dass Firmware-Versionen vom Kunde getestet werden müssen.
Noch schlimmer finde ich aber, dass Funkwerk (wir haben ein Elmeg IP290, baugleich mit Snom 190 hinter Bintec-Routern getestet) sagt so (siehe Link) sollte es gehen, Schlund/1&1/GMX schieben es auf das Telefon (weil ja andere Boxen funktionieren) und Snom schiebt es auf 1&1/Schlund/GMX.
Nachdem ich jetzt aber weiß wie eine FBF hinter einer NAT funktioniert werde ich am Dienstag eine fette E-Mail an den Funkwerk-Support schreiben. Wenn die solchen Schrott (IP290) verkaufen sollen sie gefälligst auch sagen wie er funktioniert.
PS: Die Anleitung des Snom 190 (bzw. IP290) ist noch schlechter als ungenügend. Fehlerbeschreibungen werden überhaupt nicht erklärt und wer kein SIP-Studium abgelegt hat kommt damit eigentlich überhaupt nicht klar.
