NAT-Problem oder Sipgate Problem?

paulinus

Neuer User
Mitglied seit
7 Dez 2004
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Obwohl ich bereits den Router getauscht habe (vorher Netgear FR328S, jetzt Linksys BEFSR81) habe ich noch immer den Verdacht, daß mein Problem mit dem Router (bzw. mit NAT) zu tun hat.... Aber vielleicht bin ich auch falsch hier.

Der Effekt: Router und Telefone gestartet, alles funktioniert (rufe rein, raus, alles ok). Nach ein paar Stunden: Ich rufe eines der SIP Telefone aus dem Festnetz an und bekomme die Meldung: Der Sipgate-Teilnehmer mit der Nummer Blabla ist derzeit nicht erreichbar. Wähle ich mit dem Sip Telefon raus, ist es plötzlich auch wieder erreichbar. Manchmal. Manchmal geht auch das rauswählen mit dem SIP Telefon nicht... Telefon-Reset (neuanmeldung bei Sipgate als Folge), dann geht es wieder. Nur wie lange...???

Die Konfiguration: Linksys BEFSR81, macht NAT und DHCP, QOS ist auch eingestellt. Dahinter ein Cisco 7960 mit SIP Account1 und ein Grandstream BT100 mit nem anderen SIP Account, beide bei Sipgate. Zuweilen hängt statt dem BT100 auch ein ATA486 dran. Beide Telefone laufen parallel hinter demselben NAT Router, seitdem ich beiden unterschiedliche SIP-Fone Ports eingestellt hatte. Können sich auch wechselseitig anrufen. Der Effekt ist nicht neu und trat auch mit dem Netgear Router und mit nur einem SIP Telefon hinter dem Router auf. Der Tausch des Routers hat das Problem nicht gelöst, trotzdem habe ich den leisen Verdacht, daß es was mit dem Router zu tun hat (auch der Netgear hatte geNATtet). Oder muss man damit leben, daß ein Telefon bei Sipgate nur "manchmal" erreichbar ist?

Für Tipps zur Fehlereingrenzung bin ich jederzeit dankbar.

Gruß, Paul
P.S.: Hardwarebeschreibung ist aus dem Text ersichtlich
 
Softphones habe ich noch nie probiert. Mag ich mir auch nicht unbedingt anschaffen, das Headsetgefummel find ich zu nervig. Aber dreierlei "Hardphones" sollten ja genug sein :)

Noch ein Hinweis: Ich habe im Router kein explizites Portforwarding eingestellt. Beisst sich auch mit DHCP. Liegt es vielleicht daran? Falls ja, wundere ich mich nur, dass es manchmal mehrere Stunden lang geht, dann wieder plötzlich nicht. Heute schon dreimal getestet, das Telefon liess sich nicht anrufen, habe mit dem SIP-Phone dann nur kurz mal die Mailbox angerufen und wieder aufgelegt, dann war's sofort wieder erreichbar.
 
Zwangstrennung meines Providers ist immer nachts um 3:00 Uhr. Kann also nicht sein. Die Probleme habe ich heute bereits vier mal nachvollzogen, in der Zwischenzeit gab es mit Sicherheit keine Zwangstrennung.
 
Haben die Geraete eventuell ein Systemlog, aus dem man Hinweise auf "ungewoehnliche Vorkommnisse" entnehmen koennte (nein, ich kenne keines der bei Dir eingesetzten Geraete, daher die Frage :))?
 
@paulinus
Ich habe den gleichen Router, portforwarding eingestellt und feste IPs vergeben - keine Probleme.

Gruß,
Tin
 
@paulinus

ist beim BT100 ein outbound-proxy definiert?
stun-server mit NAT-Traversal akitiviert?
Register Expiration: was steht hier?
 
@netwiew
ja, outbound proxy ist sipgate.de
stun: Yes, stun.sipgate.net:10000
register expiration: 60 (Min)

@TinTin
ich werde es dann doch mal mit festen IPs versuchen. Hast Du UPNP Forwarding aktiviert? Ich kann leider nicht ganz auf DHCP verzichten und in der Doku des Linksys steht, daß DHCP dafür abgeschaltet werden MUSS. Beim übrigen Port-Forwarding steht da nur "soll", woraus ich schließe, wenn ich feste IPs ausserhalb der DHCP range und dorthin Ports forwarde, dass es funktionieren sollte.

Gruss, Paul
 
@paulinus

Auf welchem Wert steht denn der 'idle timer' im router (timeout bis zur automatischen Trennung der Verbindung)?

Ich würde mal damit experimentieren den Wert für 'register expiration' unter diesen Wert zu setzen (auf jeden Fall unter 15 min. wegen der DSL-Zwangstrennung der t-com)!
 
@netview
der Idle-Timer in meinem Router ist abgeschaltet (permanente Verbindung). Wird die Verbindung extern unterbrochen (Zwangstrennung), dann verbindet er nach 30 Sekunden wieder.

Zwangstrennung habe ich auf 3:00 früh gelegt (mein Provider lässt mich wählen, wann :) )

Gruß, Paul
 
Ich würde mal den outbound-proxy in beiden phones deaktivieren und nur mit dem stun-server arbeiten.

Voraussetzung ist jedoch, dass das port-forwarding korrekt eingestellt ist und auch unterschiedliche ports verwendet werden z.B. BT100 (alles udp) sip:5060 rtp 5004-5007 und beim Cisco sip port: 5061 und rtp: <> 5004-5007 (andere range!) entsprechend auf die feste IP (wichtig!) der phones forwarden!

Welchen Firmwarestand hat das BT100?
 
@paulinus
Ich benutze das "normale" port range forwarding, nicht UPnP. DHCP Server kann ruhig aktiviert bleiben, nur die Endgeräte auf die Du die Ports weiterleitest sollten eine feste IP haben.

Gruß,
Tin
 
@netview
habe jetzt feste ips vergeben und Port-Range forwarding eingetragen. Bis jetzt geht alles. Für RTP habe ich aber nur eine Range von zwei Ports eingetragen (müssen es denn gleich vier sein?).

Das Cisco Phone kann leider kein STUN, sodass ich den outbound proxy mal aktiv gelassen habe. Warum könnte der Proxy denn stören?

@TinTin
Ich habs jetzt so gemacht wie Du gesagt hast. Ich bin ja mal gespannt, ob der Effekt nun behoben ist.

@all
Vielen Dank schon mal für die Tipps. Da der Fehler nur sporadisch auftrat, manchmal erst nach Stunden, warte ich mal einen Tag ab, ob die ergriffenen Maßnahmen gefruchtet haben. Ich gebe auf jeden Fall bis morgen Abend Bescheid, ob der Thread als erledigt betrachtet werden kann oder nicht.

Viele Grüße,
Paul
 
@All
nach nahezu 24 Stunden ohne die sonst sehr häufig auftretenden Ausfälle kann ich wohl sagen, die Maßnahme war erfolgreich. Fazit also: NAT ohne Port-Forwarding scheint dem Anschein nach ja zu funktionieren, allerdings immer nur für eine kurze Zeit. Schon wieder was dazugelernt.

Allen schönen Dank für die zahlreichen Tipps, ich denke der Thread kann dann geschlossen werden.

Paul
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.