ein Freund betreibt bei sich an zwei Standorten je einen gebitswitcherten als ATA hinter einem Router, einmal per WLAN angebunden (an einen Zyxel Prestige 660) und einmal per LAN (an einen Siemens SE515 DSL), SIP-Anbieter jeweils Sipgate.
Sein Problem ist nun, dass der WLAN-Speedport (Firmware: 0.3.8, mit Telekom und Targa-Variante getestet) ein kleines Telefonproblem hat; nach einiger Zeit kann man die registrierte Nummer nicht mehr anrufen (der Sipgate-AB geht ran), obwohl im Statusmenü nach wie vor eine Registrierung für die Nummer angezeigt wird. Im Anrufmonitor tauchen solche Anrufe auch nicht mehr auf.
Der Speedport selbst ist aber nach wie vor im internen Netz erreichbar, der Port 5060 wird natürlich auch auf ihn geforwardet. (denglisch, ich weiss…)
Kurioserweise geht es wieder einige Zeit, wenn man den Router rebootet.
Hat jemand eine Idee, woran das liegen könnte?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tritt das Problem erst seit 0.3.8 auf oder kommt es bei früheren Versionen auch zum Problem? Wenn ältere Versionen auch Schwierigkeiten machen dann vermute ich hat Sipgate was an der Server-Konfiguration geändert.
Mir hat letztlich jemand auch von Problemen bei Sipgate berichtet, da hat angeblich das aktivieren das Arcor-Voip-Fix geholfen. Erklären kann ich das allerdings ohne tcpdump auch nicht.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Es war vorher 0.3.6 und danach 0.3.7 installiert, der selbe Fehler.
Wie gesagt - per Kabel am Siemens SE515 tritt das Problem nicht auf, obwohl ebenfalls Sipgate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
der Port 5060 wird natürlich auch auf ihn geforwardet.
Der Voip-Client verwendet auch noch die Ports 16384 bis 16400.
In der Bitswitcher-Firmware funktioniert der Voip-Client hinter einem NAT-Router nicht richtig, da er sich mit der Ip-Adresse vom Interface, an dem er lauscht, beim SIP-Registrar anmeldet. Man kann dann anrufen, selber aber nicht angerufen werden. Bei Sipgate sieht man dann eine lokale Ip (192.168.xxx.xxx) anstatt der WAN-Ip. Bei der Firmware der Telekom funktioniert das aber. Es muß da einen Trick geben (PSI-Update-File?), über den der Voip-Client die WAN-Ip-Adresse erhält und dem Registrar mitteilt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das mit den Ports 16384-16400 wusste ich nicht - falls dem so ist, sollte man es in die Dokumentation aufnehmen.
Allerdings bin ich ob der Aussagen von amd-65 ein wenig verwundert; erstens wird auf der Projektseite sogar die Einrichtung als ATA beschrieben, zweitens funktioniert sie in der Variante 'per LAN am Siemens SE515' und drittens frage ich mich, warum es nach dem Routerstart immer eine Zeut lang geht.
Zu dem Problem selbst ist mir etwas aufgefallen:
Im Webinterface unter Status / Connections sieht man im oberen Bereich mit dem Label ARP (vmtl.) alle MAC-Adressen, mit denen der Speedport Kontakt hat bzw. die er kennt (Zumindest nehme ich das an).
Bei dem problematischen Modell (das mit der WLAN-Anbindung) verschwindet die MAC des Routers nach einiger Zeit, evtl. ist das genau dann, wenn man nicht mehr angerufen werden kann. (Der Speedport selbst ist aber per WLAN vom Computer aus erreichbar).
Und weiter:
Loggt man sich per Telnet oder SSH auf dem Speedport ein und pingt eine Internetadresse (z.B. www.heise.de), so taucht in o.g. Übersicht der Router wieder auf und man kann wieder anrufen.
Kann sich das jemand erklären?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ein weiterer Nachtrag:
Ein 'arp -a' auf dem VoIP-Speedport zeigt, dass er die MAC-Adresse des Routers nicht kennt. Liegt das vielleicht an dem Zyxel-Router? Hat jemand generell hier Erfahrungen damit, den Speedport als ATA hinter einem anderen Router zu benutzen?
Es wurde übrigens wegen der Telefonie-Probleme ein zweiter Speedport beschafft, bei dem aber die selben Schwierigkeiten auftraten, es dürfte sich also nicht um ein Hardware-Problem des Speedports handeln.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also ein Test über mehrere Tage hat gezeigt das der Voip-Client in regelmäßigen Abständigen von ca. 14s leere UDP-Pakete von Quellport 5060 zum SIP-Proxy schickt und damit die Verbindung permanent, also selbst hinter einem NAT-Router, offen hält. Das Forwarding von 5060 ist also eigentlich pro-forma und sollte keine Rolle spielen.
Der Voip-Client verwendet auch noch die Ports 16384 bis 16400. In der Bitswitcher-Firmware funktioniert der Voip-Client hinter einem NAT-Router nicht richtig, da er sich mit der Ip-Adresse vom Interface, an dem er lauscht, beim SIP-Registrar anmeldet.
Die Ports 16384 bis 16400 spielen m.M.n. keine Rolle, werden zwar in der Orignalfirmware aufgemacht aber praktisch meldet sich der Voip-Client immer mit Port 5060 beim Registrar für ankommende Gespräche an. Auch das melden der internen IP
spielt zumindest bei Sipgate keine Rolle, da offensichtlich das Via-Attribut das z.B, die interne IP enthält ignoriert wird und der Sipgate-Server stattdessen natürlich die öffentliche Adresse verwendet. Außerdem ist das völlig klar, woher soll der Client die öffentliche Adresse auch kennen wenn er kein STUN unterstützt. Ich sehe da nur die Möglichkeit mit ipt_SIP das Attribut zu verändern.
@regenwetter
Der fehlende ARP-Eintrag zeigt eigentlich nur, das der Speedport eine Weile nicht mit seinem Standard-GW, dem Zyxel, geredet hat. Hat der Speedport eine statische IP oder per DHCP vom Zyxel bekommen. Das würde vielleicht etwas erklären….
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@coolman1982
Der Speedport hat eine fixe IP. (Der per LAN angebundene Speedport am anderen Standort, bei dem es keine Probleme gibt, übrigens auch). Soll ich es mal per DHCP versuchen?
Habe gestern Abend noch ein wenig rumgespielt. Was mir auffiel:
(i) Der Speedport meldet, daß er die Sipgate-Nummer registriert hat; abgehende Telefonate gehen, eingehende nur in einem knappen Fenster ab Systemstart. Trotzdem zeigt die Sipgate-Seite (www.sipgate.de) beim Status 'offline'.
(ii) Das Forwarding der Ports 16384-16400 hat nichts gebracht
(iii) Das mit dem Pingen vom Speedport aus scheint doch nicht immer etwas zu bringen; offenbar war es Zufall (?)
Hat denn jemand hier Erfahrung mit dem Speedport als ATA hinter einem Router?
Generell:
Mein Freund hat testeshalber den Zyxel schonmal gegen ein ähnliches Zyxel-Modell getauscht, allerdings erfolglos.
Wenn es passt, werde ich ihm die nächsten Wochen einen anderen Router mitgeben (D-Link oder AVM ohne VoIP).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Eine Freage kam mir gerade:
Wenn der Speedport alle 14s UDP-Pakete zum SIP-Registrar oder SIP-Proxy schickt, warum zeigt dann die ARP-Tabelle, dass er schon einige Zeit nicht mehr mit dem Standard-Gateway (Router) geredet hat?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weil er die Pakete mittels RAW-Socket versendet, da findet keine ARP-Auflösung statt weil er das komplette Paket inklusive IP-Header selbst generiert. Ich nehme das wurde im Voip-Client so gemacht damit auch im Falle dass das Interface zwischenzeitlich seine IP verliert (wegen DHCP z.B.) trotzdem die Keep-Alives (ich nenns mal so) versendet werden können.
Um das Ganze wirklich nachvollziehen zu können lade dir tcpdump (http://downloads.sourceforge.net/bitswitcher/tcpdump.tar.gz?use_mirror=) runter und schneide den UDP-Verkehr auf br0 mit. Am besten
folgendes ins custom-Skript:
Dann wartest du bis das Telefon aussteigt und lädst die Datei /tmp/sip.cap per SCP auf deinen Rechner und schaust sie dir mit wireshark an. Da solltest du anhand der SIP-Nachrichten nachvollziehen können was zwischen Client und Server passiert.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ein Freund betreibt bei sich an zwei Standorten je einen gebitswitcherten als ATA hinter einem Router, einmal per WLAN angebunden (an einen Zyxel Prestige 660) und einmal per LAN (an einen Siemens SE515 DSL), SIP-Anbieter jeweils Sipgate.
Sein Problem ist nun, dass der WLAN-Speedport (Firmware: 0.3.8, mit Telekom und Targa-Variante getestet) ein kleines Telefonproblem hat; nach einiger Zeit kann man die registrierte Nummer nicht mehr anrufen (der Sipgate-AB geht ran), obwohl im Statusmenü nach wie vor eine Registrierung für die Nummer angezeigt wird. Im Anrufmonitor tauchen solche Anrufe auch nicht mehr auf.
Der Speedport selbst ist aber nach wie vor im internen Netz erreichbar, der Port 5060 wird natürlich auch auf ihn geforwardet. (denglisch, ich weiss…)
Kurioserweise geht es wieder einige Zeit, wenn man den Router rebootet.
Hat jemand eine Idee, woran das liegen könnte?
Tritt das Problem erst seit 0.3.8 auf oder kommt es bei früheren Versionen auch zum Problem? Wenn ältere Versionen auch Schwierigkeiten machen dann vermute ich hat Sipgate was an der Server-Konfiguration geändert.
Mir hat letztlich jemand auch von Problemen bei Sipgate berichtet, da hat angeblich das aktivieren das Arcor-Voip-Fix geholfen. Erklären kann ich das allerdings ohne tcpdump auch nicht.
Es war vorher 0.3.6 und danach 0.3.7 installiert, der selbe Fehler.
Wie gesagt - per Kabel am Siemens SE515 tritt das Problem nicht auf, obwohl ebenfalls Sipgate.
Der Voip-Client verwendet auch noch die Ports 16384 bis 16400.
In der Bitswitcher-Firmware funktioniert der Voip-Client hinter einem NAT-Router nicht richtig, da er sich mit der Ip-Adresse vom Interface, an dem er lauscht, beim SIP-Registrar anmeldet. Man kann dann anrufen, selber aber nicht angerufen werden. Bei Sipgate sieht man dann eine lokale Ip (192.168.xxx.xxx) anstatt der WAN-Ip. Bei der Firmware der Telekom funktioniert das aber. Es muß da einen Trick geben (PSI-Update-File?), über den der Voip-Client die WAN-Ip-Adresse erhält und dem Registrar mitteilt.
Das mit den Ports 16384-16400 wusste ich nicht - falls dem so ist, sollte man es in die Dokumentation aufnehmen.
Allerdings bin ich ob der Aussagen von amd-65 ein wenig verwundert; erstens wird auf der Projektseite sogar die Einrichtung als ATA beschrieben, zweitens funktioniert sie in der Variante 'per LAN am Siemens SE515' und drittens frage ich mich, warum es nach dem Routerstart immer eine Zeut lang geht.
Zu dem Problem selbst ist mir etwas aufgefallen:
Im Webinterface unter Status / Connections sieht man im oberen Bereich mit dem Label ARP (vmtl.) alle MAC-Adressen, mit denen der Speedport Kontakt hat bzw. die er kennt (Zumindest nehme ich das an).
Bei dem problematischen Modell (das mit der WLAN-Anbindung) verschwindet die MAC des Routers nach einiger Zeit, evtl. ist das genau dann, wenn man nicht mehr angerufen werden kann. (Der Speedport selbst ist aber per WLAN vom Computer aus erreichbar).
Und weiter:
Loggt man sich per Telnet oder SSH auf dem Speedport ein und pingt eine Internetadresse (z.B. www.heise.de), so taucht in o.g. Übersicht der Router wieder auf und man kann wieder anrufen.
Kann sich das jemand erklären?
Ein weiterer Nachtrag:
Ein 'arp -a' auf dem VoIP-Speedport zeigt, dass er die MAC-Adresse des Routers nicht kennt. Liegt das vielleicht an dem Zyxel-Router? Hat jemand generell hier Erfahrungen damit, den Speedport als ATA hinter einem anderen Router zu benutzen?
Es wurde übrigens wegen der Telefonie-Probleme ein zweiter Speedport beschafft, bei dem aber die selben Schwierigkeiten auftraten, es dürfte sich also nicht um ein Hardware-Problem des Speedports handeln.
Also ein Test über mehrere Tage hat gezeigt das der Voip-Client in regelmäßigen Abständigen von ca. 14s leere UDP-Pakete von Quellport 5060 zum SIP-Proxy schickt und damit die Verbindung permanent, also selbst hinter einem NAT-Router, offen hält. Das Forwarding von 5060 ist also eigentlich pro-forma und sollte keine Rolle spielen.
@amd-65
Die Ports 16384 bis 16400 spielen m.M.n. keine Rolle, werden zwar in der Orignalfirmware aufgemacht aber praktisch meldet sich der Voip-Client immer mit Port 5060 beim Registrar für ankommende Gespräche an. Auch das melden der internen IP
spielt zumindest bei Sipgate keine Rolle, da offensichtlich das Via-Attribut das z.B, die interne IP enthält ignoriert wird und der Sipgate-Server stattdessen natürlich die öffentliche Adresse verwendet. Außerdem ist das völlig klar, woher soll der Client die öffentliche Adresse auch kennen wenn er kein STUN unterstützt. Ich sehe da nur die Möglichkeit mit ipt_SIP das Attribut zu verändern.
@regenwetter
Der fehlende ARP-Eintrag zeigt eigentlich nur, das der Speedport eine Weile nicht mit seinem Standard-GW, dem Zyxel, geredet hat. Hat der Speedport eine statische IP oder per DHCP vom Zyxel bekommen. Das würde vielleicht etwas erklären….
@coolman1982
Der Speedport hat eine fixe IP. (Der per LAN angebundene Speedport am anderen Standort, bei dem es keine Probleme gibt, übrigens auch). Soll ich es mal per DHCP versuchen?
Habe gestern Abend noch ein wenig rumgespielt. Was mir auffiel:
(i) Der Speedport meldet, daß er die Sipgate-Nummer registriert hat; abgehende Telefonate gehen, eingehende nur in einem knappen Fenster ab Systemstart. Trotzdem zeigt die Sipgate-Seite (www.sipgate.de) beim Status 'offline'.
(ii) Das Forwarding der Ports 16384-16400 hat nichts gebracht
(iii) Das mit dem Pingen vom Speedport aus scheint doch nicht immer etwas zu bringen; offenbar war es Zufall (?)
Hat denn jemand hier Erfahrung mit dem Speedport als ATA hinter einem Router?
Generell:
Mein Freund hat testeshalber den Zyxel schonmal gegen ein ähnliches Zyxel-Modell getauscht, allerdings erfolglos.
Wenn es passt, werde ich ihm die nächsten Wochen einen anderen Router mitgeben (D-Link oder AVM ohne VoIP).
Eine Freage kam mir gerade:
Wenn der Speedport alle 14s UDP-Pakete zum SIP-Registrar oder SIP-Proxy schickt, warum zeigt dann die ARP-Tabelle, dass er schon einige Zeit nicht mehr mit dem Standard-Gateway (Router) geredet hat?
Weil er die Pakete mittels RAW-Socket versendet, da findet keine ARP-Auflösung statt weil er das komplette Paket inklusive IP-Header selbst generiert. Ich nehme das wurde im Voip-Client so gemacht damit auch im Falle dass das Interface zwischenzeitlich seine IP verliert (wegen DHCP z.B.) trotzdem die Keep-Alives (ich nenns mal so) versendet werden können.
Um das Ganze wirklich nachvollziehen zu können lade dir tcpdump (http://downloads.sourceforge.net/bitswitcher/tcpdump.tar.gz?use_mirror=) runter und schneide den UDP-Verkehr auf br0 mit. Am besten
folgendes ins custom-Skript:
Dann wartest du bis das Telefon aussteigt und lädst die Datei /tmp/sip.cap per SCP auf deinen Rechner und schaust sie dir mit wireshark an. Da solltest du anhand der SIP-Nachrichten nachvollziehen können was zwischen Client und Server passiert.