Sipgate - Request Timeout (408)


#1

Hi,

hat jemand von Euch auch Probleme mit SIPGate? Ich habe hier Test / Notaccounts von SIPGate und DUSNet konfiguriert (mein Baby hängt hauptsächlich noch an einem guten, alten ISDN-Anlagenanschluss :heart_eyes:)

Der SIPGater macht leider permanent Probleme und rennt in den Request-Timeout. Aber erst ein paar Stunden nach einer erfolgreichen Registrierung (und diese Zeit überschreitet alles an Timern, die SIP so hat).

Meine Config basiert im Wesentlichen auf dem aktuellen Auerswald-Template. NAT-Keepalive ist aus, da ich die entsprechenden Ports direkt auf die Anlage weiterleite. Registrierung habe ich auf 10 Minuten gesetzt (habe eh eine feste IP, die sich nicht ändert … daher kann man das eher entspannt sehen). Ist aber auch mit der ungeänderten Out-of-the-Box-Config nicht anders.

Wenn jemand hier Erfahrungen in dieser Richtung hat, sind diese herzlich willkommen!


#2

Hallo Marco.

Ist evtl. doch der falsche Port in Deinem Router umgeleitet? Versuch es ansonsten doch mal mit keiner Portumleitung und Nat keep alive…
Gibt es evtl. Einträge in den Systemmeldungen?
Ggfs. mal per Wireshark prüfen (Router/Anlage).


#3

Hi Martin,

Ohne Umleitung und mit Keepalive war es nicht anders, es gibt auch keine demenstsprechende Einträge in den Systemmeldungen. Ich werde dann bei Gelegenheit mal den Drahthai bemühen müssen … :wink:


#4

Hallo Marco.

Schau mal der Hinweis von Sipgate selber: http://www.sipgate.de/faq/index.php?do=displayArticle&article=602&id=249

:wink:


#5

Hi Martin,

danke für den Hinweis, aber den Artikel kenne ich schon :wink:

Der ist auch nicht wirklich hilfreich bzw. richtig. Für 5060 und 5004 brauche ich keine Weiterleitung, sondern die dürfen ausgehend in der Firewall nicht geblockt sein (ist ja die Richtung TK -> Sipgate).

Eingehend machen die es sich leicht und sagen: Mach’ UPnP an. Nö! Wer schaltet freiwillig ein riesiges Sicherheitsloch in seiner Firewall an :scream:

Ich werde um den Drahthai nicht herumkommen. IP-mäßig ist alles da, wo es hingehört. Irgendwas scheint SIPgate zu stören, ich muss nur herausfinden was. DUSnet läuft mit identischer Konfiguration ja rock-solid!


#6

Man sieht auch schön, dass die Verbindungen im Router sehr wohl bekannt und offen sind …

root@router:~# show conntrack table ipv4 source 10.0.4.1
TCP state codes: SS - SYN SENT, SR - SYN RECEIVED, ES - ESTABLISHED,
                 FW - FIN WAIT, CW - CLOSE WAIT, LA - LAST ACK,
                 TW - TIME WAIT, CL - CLOSE, LI - LISTEN

CONN ID    Source                 Destination            Protocol         TIMEOUT             
2379889216 10.0.4.1:45166         10.0.0.1:53            udp [17]         78                  
2307296088 10.0.4.1:5002          83.125.8.71:5060       udp [17]         38                  
1615855720 10.0.4.1:5003          217.10.79.9:5060       udp [17]         176   

Der ausgehende 5002-er ist die Verbindung zu DUSnet (einwandfrei), der 5003-er ist Sipgate (408 Request Timeout). Vielleicht doch noch mal mit STUN’s rumspielen … :rolling_eyes: … SIPgate scheint nicht an mich zurückzuschicken.

Sowieso bedeppert, dass SIP standardmäßig UDP ist. Schwachsinn! Für die RTP-Daten ist es klar, aber eine Kontrollverbindung darf (und kann) viel besser über TCP laufen …


#7

Hallo Marco.

Ich meinte eigentlich mehr die Firmware des Router/der Firewall - die Schuld sein könnte. Ggfs würde ich mal direkt auf dem Router Wiresharken.

Verwende bitte mal einen anderen Port (gerade, ich weiß klingt komisch, aber eigentlich wird ja immer für sips der eingestellte Port +1 verwendet), wäre zumindest eine Änderung :wink: - falls Dusnet evtl ein Einfluss hat.

Lade am Besten nochmal das Original_Profil über die Anlage runter.


#8

Naja, wenn das Baby auf seinem Absenderport +1 rummachen würde, wäre das ein böser Fauxpas … Ich habe den Absenderport für den SIPGate Account trotzdem mal geändert und beobachte … :wink:


#9

Hallo Marco.

Ich meinte eher zuhören, also Empfang von Signalisierungsmeldungen (in diesem Fall dann von Dusnet). Ist aber vermutlich. Auch eher ein Versuch.


#10

Auch wenn das Thema schon 2 Jahre alt ist, gibts in diesem Bereich neue Erkenntnisse?


#11

Sorry, was spät … aber mit der 7.0C keine Probleme in der Hinsicht.