FBF hinter Thomson SpeedTouch 716i Router?

smartie

Mitglied
Mitglied seit
30 Mrz 2005
Beiträge
520
Punkte für Reaktionen
21
Punkte
18
Hallo Zusammen,
vielleicht hat ja schon jemand die gleichen Probleme gehabt und gelöst:

Ich versuche die FBF im ATA-Modus als IP-Client hinter dem SpeedTouch 716i Router zu betreiben.
Leider komme ich da von einem Problem ins nächste. Mal werden die SIP-Accounts nicht registriert. Nach ein bisschen herumprobieren funktioniert das, aber anrufen und angerufen werden geht immer noch nicht.
Was ich schon probiert habe:

+ Eine "Application" im Router angelegt um folgende Ports zu FBF weiterzuleiten (Any = TCP und UDP)
Code:
ProtocolPort RangeTranslate To ...Trigger ProtocolTrigger Port



Any5060 - 5060 5060 - 5060--

Any5070 - 5079 5070 - 5079--

Any30000 - 30019 30000 - 30019--

Any8000 - 8000 8000 - 8000--

Any10000 - 10000 10000 - 10000-
+ Im Router per Telnet folgendes Kommando ausgeführt (hatte ich in einem anderen Forum gefunden)
Code:
:connection appconfig application=SIP timeout=3600 trace=enabled tracelevel=4
+ Bei den SIP-Accounts Proxy- und STUN-Server eingetragen (die ich vorher nie brauchte)

Bisher hat alles keinen Erfolg gebracht, ich werde nun wieder auf reinen Bridge-Modus umstellen, da ich in keinem Fall auf VoIP verzichten kann. Schade, dass die FBF hinter einem IP-Router offensichtlich nicht ohne Probleme zum Laufen zu bringen ist.
Ich bin für alles Tipps dankbar!

Ciao ciao,
smartie
 
Zunächst einmal hängt das vom Router ab... insbesondere von der Art des NAT. Auf einen STUN-Server würde ich zunächst mal verzichten.

In Deiner Konfiguration fehlen die RTP-Ports der FBF: 7077-7087/udp. Dafür kann man die 30000-30019 vergessen.

--gandalf.
 
gandalf94305 schrieb:
Zunächst einmal hängt das vom Router ab... insbesondere von der Art des NAT. Auf einen STUN-Server würde ich zunächst mal verzichten.

In Deiner Konfiguration fehlen die RTP-Ports der FBF: 7077-7087/udp. Dafür kann man die 30000-30019 vergessen.

--gandalf.

Danke für den Hinweis. Wann genau werden die RTP-Ports benötigt, bzw. wie würde es sich auswirken, wenn diese Ports fehlen?

Hat denn jemand die FBF wirklich "sauber" hinter einem NAZ-Router laufen? Der 716i lässt sich recht umfangreich konfigurieren, wobei leider die "komplexeren" Features nur recht umständlich über telnet vorgenommen werden können. Das Web-Interface deckt nur die "Standard-Features" ab.

Im Bridge-Modus, so wie ich es derzeit laufen habe, funktioniert es einwandfrei. Aber prinzipiell sind die Router-Features des 716i deutlich besser und umfangreicher als die der FBF, so dass ich diese eben lieber als reinen IP-Client laufen lassen würde...
Würdet Ihr zum Beispiel empfehlen, der FBF direkt statische Adresse zu geben, oder diese über den Router zuweisen zu lassen? Bei mir hat beides prinzipiell funktioniert, aber auch keines von beidem meine Probleme gelöst...
 
Hallo,
ich bin immer noch bzw. wieder dabei, es zu probieren, aber es will einfach nicht klappen. :(

Inzwischen habe ich alle Ports die ich irgendwo gefunden habe per NAT weitergeleitet:
Protokoll Anschlussbereich Übersetzen in... Auslöserprotokoll Auslöseranschluss

Any 5060 - 5060 5060 - 5060 - -
Any 5004 - 5004 5004 - 5004 - -
Any 7077 - 7079 7077 - 7079 - -
Any 10000 - 10000 10000 - 10000 - -
Any 5070 - 5070 5070 - 5070 - -
Any 30000 - 30019 30000 - 30019 - -

Was mich am meisten wundert / ärgert ist, dass es zumindest für meine GMX-Accounts zunächst zu funktionieren schien. Die Nummern wurden registriert und ich konnte zumindest ausgehend auch anrufen. Der SIPGATE-Account liess sich nicht registrieren...
Dann nach einiger Zeit ohne dass ich großartig etwas geändert hatte, wurden die GMX-Accounts zwar noch als registriert angezeigt, aber im telnet habe ich gesehen, dass die Registrierung fehlschlägt.
Nach einem Neustart der FBF wurde kein Account mehr registriert :( ("Gegenstelle antwortet nicht. Zeitüberschreitung")

Hat irgend jemand eine Idee?!? Mir scheint, als ob das ganze auf der FBF über IP in keiner weise stabil läuft... Wenn ich den gleichen Router als Bridge konfiguriere und somit der ganze Traffic über die FBF geht (und diese somit auch das NAT übernimmt) geht es ohne Probleme.

Hat jemand, der die FBF hinter einem NAT-Router am Laufen hat, noch irgendwelche Tipps?!? Ich habe bei meinem Router schon alles was irgendwie stören könnte deaktiviert (Firewall, IDS...).

Ich bin leider (mal wieder) total ratlos und werde wohl zwangsläuft wieder auf "Bridge-Modus" zurückschalten, obwohl ich den 716iG viel lieber als echten Router nutzen würde...
 
Ich kenne Deinen Router nicht in Bezug auf welche Art von NAT hier drinsteckt, jedoch zu den Ports würde ich folgende empfehlen:

5060/udp (SIP)
7077-7087/udp (RTP)

STUN brauchst Du nur vielleicht (versuch's mal zuerst ohne):
10000/udp (STUN)

Generell würde ich vorschlagen, bei einem unbekannten Router die Konfiguration schrittweise in der FBF zu setzen:
- Account nur mit Registrar, ohne Proxy und STUN eintragen
- Account mit Registrar und Proxy, ohne STUN
- Account mit Registrar/Proxy/STUN versuchen

--gandalf.
 
gandalf94305 schrieb:
Ich kenne Deinen Router nicht in Bezug auf welche Art von NAT hier drinsteckt, jedoch zu den Ports würde ich folgende empfehlen:

5060/udp (SIP)
7077-7087/udp (RTP)

STUN brauchst Du nur vielleicht (versuch's mal zuerst ohne):
10000/udp (STUN)

Generell würde ich vorschlagen, bei einem unbekannten Router die Konfiguration schrittweise in der FBF zu setzen:
- Account nur mit Registrar, ohne Proxy und STUN eintragen
- Account mit Registrar und Proxy, ohne STUN
- Account mit Registrar/Proxy/STUN versuchen

--gandalf.

Erstmal danke für die Tipps... Ich bin hier echt am Verzweifeln... Vor allem, weil das Verhalten einfach nicht reproduzierbar ist. Da ich im Moment ja eher zu viele als zu wenige Ports forwarde, aheb ich am Router erstmal NICHTS geändert, sondern nur wie vorgeschlagen die SIP-Accounts bereinigt...

Das Ergebnis bestärkt mich in meiner Meinung, dass das Problem bei der FBF 7050 liegt, bzw. dass der ATA-Modus als IP-Client nicht sauber implementiert ist:
1. GMX-Nr1 geändert (Nur Registrar "sip-gmx.net" eingetragen)
=> (erstmal erfreulich) genau dieses Account wurde registriert (2 andere GMX + Sipgate weiterhin nicht).

2. Gleiche Änderung bei GMX-Nr2 gemacht.... Lange Zeit kein Account mehr registriert... Dann..... Oh Wunder... Sipgate + GMX-Nr3 (noch mit STUN etc.) sind registriert, die beiden gänderten GMX-Accounts NICHT!!!

3. Beim Schreiben dieses Postings noch mal in die FBF geschaut.... Auf einmal ist nur noch GMX-Nr1 NICHT registriert (d.h. die erste die zunächst wieder registriert wurde). Und das obwohl ich NICHTS mehr geändert habe!!!

Aktueller Stand:
GMX-Nr1 (nur Registrar "sip-gmx.net") NICHT registriert
GMX-Nr2 (nur Registrar "sip-gmx.net") registriert
GMX-Nr3 (Standardeintellung "GMX", d.h. ink. STUN & Proxy) registriert
Sipgate (Standardeintellung "Sipgate", d.h. inkl. STUN & Proxy) registriert

D.h. die beiden letzten Accounte wurden nun registriert, obwohl ich diese nicht modifiziert habe und sie vorher trotz langer Wartezeit nicht registriert wurden.... Zusätzlich wird von zwei identische Accounts eines registriert, das andere nicht... Wo ist da die Logik? Und vor allem: Wie soll es da am NAT-Router hängen?!?

Ich bin völlig ratlos... *snief*

Nachtrag:
Ich habe jetzt mal versucht, mit einer der registrierten Nummern zu telefonieren:
1. Ausgehender Anruf aufs Festnetz: Erfolgreich
2. Eingehender Anruf vom Festnetz auf (reiner) VoIP-Nummer: Nicht erfolgreich...
 
Zuletzt bearbeitet:
Hmm... hier ein paar Ideen:

Du hast Port Triggers aktiviert... Können das nicht direkte Port-Weiterleitungen sein? Das Problem mit Port Triggers ist, daß ab und zu Timeouts für die Zuordnung erfolgen und dann Pakete von draußen nicht mehr korrekt nach innen weitergeleitet werden.

In der FBF gibt es eine NAT-Keepalive-Option, die vielleicht helfen kann...

Ich verwende sip.gmx.net, nicht sip-gmx.net... macht das einen Unterschied?

Schließe DNS-Probleme aus, indem die Fritz!Box direkt DNS Lookups macht, nicht über den DNS-Forwarder des Routers.

In jedem Fall hilft es, das voipd Log mal auf der Console (per Telnet auf der FBF einloggen) anzuschauen, um zu sehen, was hier genau passiert...

Viel Erfolg! ;-)
--gandalf.
 
gandalf94305 schrieb:
Hmm... hier ein paar Ideen:

Du hast Port Triggers aktiviert... Können das nicht direkte Port-Weiterleitungen sein? Das Problem mit Port Triggers ist, daß ab und zu Timeouts für die Zuordnung erfolgen und dann Pakete von draußen nicht mehr korrekt nach innen weitergeleitet werden.

In der FBF gibt es eine NAT-Keepalive-Option, die vielleicht helfen kann...

Ich verwende sip.gmx.net, nicht sip-gmx.net... macht das einen Unterschied?

Schließe DNS-Probleme aus, indem die Fritz!Box direkt DNS Lookups macht, nicht über den DNS-Forwarder des Routers.

In jedem Fall hilft es, das voipd Log mal auf der Console (per Telnet auf der FBF einloggen) anzuschauen, um zu sehen, was hier genau passiert...

Viel Erfolg! ;-)
--gandalf.

Danke nochmal für die Hinweise... Bin schon die ganze Zeit auf der Box, meistens läuft da sowas durch:
Code:
Feb 24 00:20:07 voipd[647]: [email protected]: REGISTER end
Feb 24 00:20:07 voipd[647]: [email protected]: REGISTER failed 5 status 0 (try
again in 160 seconds)
Feb 24 00:20:07 voipd[647]: EVENT(73): Anmeldung der Internetrufnummer xxx war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeit³berschreitung.
Feb 24 00:21:05 voipd[647]: is_register_allowed - NOT running (voip=0)
Feb 24 00:21:05 voipd[647]: 0: connected    vcc 0/0/RBE/14 stay online 1
Feb 24 00:21:05 voipd[647]: dns: sip.sip-gmx.net: query
Feb 24 00:21:05 voipd[647]: dns: sip.sip-gmx.net: 212.227.15.197 ttl=156 from 19
2.168.1.254.
Feb 24 00:22:37 voipd[647]: is_register_allowed - NOT running (voip=0)
Feb 24 00:22:37 voipd[647]: 0: connected    vcc 0/0/RBE/14 stay online 1
Feb 24 00:22:47 voipd[647]: is_register_allowed - NOT running (voip=0)
Feb 24 00:22:47 voipd[647]: 0: connected    vcc 0/0/RBE/14 stay online 1
Feb 24 00:22:47 voipd[647]: [email protected]: REGISTER starting
Feb 24 00:22:47 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:22:48 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:22:49 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:22:51 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:22:55 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:22:59 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:03 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:07 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:11 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:15 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:19 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:19 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:20 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:21 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:23 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:27 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:31 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:35 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:39 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:43 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:47 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:51 voipd[647]: >>>udp Request: REGISTER sip:sipgate.de
Feb 24 00:23:51 voipd[647]: [email protected]: REGISTER end
Feb 24 00:23:51 voipd[647]: [email protected]: REGISTER failed 5 status 0 (try
again in 320 seconds)
Feb 24 00:23:51 voipd[647]: EVENT(73): Anmeldung der Internetrufnummer xx war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeit³berschreitung.
Feb 24 00:25:45 voipd[647]: is_register_allowed - NOT running (voip=0)
Feb 24 00:25:45 voipd[647]: 0: connected    vcc 0/0/RBE/14 stay online 1
Feb 24 00:25:45 voipd[647]: dns: sip.sip-gmx.net: query
Feb 24 00:25:45 voipd[647]: dns: sip.sip-gmx.net: 212.227.15.197 ttl=179 from 19
2.168.1.254.
Feb 24 00:27:17 voipd[647]: is_register_allowed - NOT running (voip=0)
Feb 24 00:27:17 voipd[647]: 0: connected    vcc 0/0/RBE/14 stay online 1

Inzwischen ist auch eine der GMX-Nummern nicht mehr registriert. Das NAT sollte soweit ich das bei meinem Router verstanden haben permanent sein, sofern kein Trigger-Port angegeben ist. Habe auch mal per Telnet nachgeschaut, es sieht vernünftig aus:
Code:
Idx Type Interface       Outside Address                Inside Address                 Use
  1 NAPT Internet        84.58.5.79:[3478-3479]         192.168.1.1:[3478-3479]        0
  2 NAPT Internet        84.58.5.79:5004                192.168.1.1:5004               0
  3 NAPT Internet        84.58.5.79:[5060-5062]         192.168.1.1:[5060-5062]        0
  4 NAPT Internet        84.58.5.79:[5070-5072]         192.168.1.1:[5070-5072]        0
  5 NAPT Internet        84.58.5.79:[7077-7081]         192.168.1.1:[7077-7081]        0
  6 NAPT Internet        84.58.5.79:10000               192.168.1.1:10000              0
  7 NAPT Internet        84.58.5.79:[30000-30019]       192.168.1.1:[30000-30019]      0
  8 NAPT Internet        84.58.5.79                     unmapped                       163
  1 NAPT LocalNetwork    any:80                         127.0.0.1:8080                 2
  2 NAPT LocalNetwork    any:1080                       127.0.0.1:8080                 0
  3 NAPT LocalNetwork    any:8080                       127.0.0.1:8080                 1
Das einzige was mich stutzig macht, ist das "Use" bei den ganzen VoIP-Ports auf "0" ist, obwohl ja sogar zwei Nummern registriert sind... ???

Na ja, ich muss jetzt erstmal drüber schlafen, morgen probiere ich noch ein bisschen weiter, aber im Moment sieht es so aus, dass ich bald wieder auf die Konfiguration FBF als Router und den 716i als reines Modem zurück gehe. Es ist schon ziemlich frustrierend....
 
Das Use=0 könnte damit zusammenhängen, daß die Registrierungsversuche von intern nach extern per NAT einen anderen, dynamischen Port zugewiesen bekommen und damit in der Tabelle nicht auftauchen. Mit anderen Worten: FBF:5060/udp wird nicht zu Router:5060/udp, sondern vielleicht Router:1844/udp. Eingehende Pakete werden dann ggf. nicht korrekt weitergeleitet.

--gandalf.
 
gandalf94305 schrieb:
Das Use=0 könnte damit zusammenhängen, daß die Registrierungsversuche von intern nach extern per NAT einen anderen, dynamischen Port zugewiesen bekommen und damit in der Tabelle nicht auftauchen. Mit anderen Worten: FBF:5060/udp wird nicht zu Router:5060/udp, sondern vielleicht Router:1844/udp. Eingehende Pakete werden dann ggf. nicht korrekt weitergeleitet.

--gandalf.

Na super... Und wie sollte man das in den Griff bekommen?!? Ich sehe schon, das wird wohl auf meine alte Lösung hinauslaufen. Der Router der FBF ist zwar lange nicht so Leistungsfähig wie der 716i, aber dafür funktioniert das VoIP wenigstens problemlos...

Trotzdem Danke und vielleicht kommen mir (oder anderen?!? ;) ) ja über Nacht noch ein paar geniale Ideen!

Gute Nacht,
smartie
 
Habe inzwischen noch mal alles mögliche ausprobiert, auf dem Router alles augeschaltet, was IRGENDWIE stören könnte. Alle Ports 1025-65535 weitergeleitet.
Erst schien es (mal wieder) zu funktionieren, alle Nummern wurden registriert, dann habe ich gemerkt, dass die VoIP-Rufnummern nicht anrufen konnte und nach und nach verloren sie auch die Regstrierung wieder.

Inzwischen ist (mal wieder) der Zustand erreicht, dass KEINE Nummer registriert wird, obwohl ich seit dem ersten Erfolgserlebnis (alle Nummern regstriert) an der Konfiguration nichts geändert habe.

Ich teste ja wirklicht gerne und probiere gerne vieles aus, aber inzwischen bin ich mit meiner Geduld und meinen Ideen echt am Ende.

Wenn hier auch keiner mehr eine geniale Idee hat, woran es liegen könnte, werde ich wohl endgültig auf den Bridge-Modus zurückgehen.
 
Ich denke, das Problem ist Dein NAT, das dynamische Port-Mappings anlegt und nicht einfach für abgehende Ports ein Mapping erlaubt. Ich habe erst einige Router getestet, bis ich schließlich mit meinem Netgear-Router den passenden für VoIP gefunden habe, der auch nicht in die Knie geht, wenn man ein paar Torrents drüber laufen ;-)

An Ports sollten die von mir genannten ausreichen. Sie sollten nicht per Trigger, sondern fix auf die interne Adresse geleitet werden.

Was die FBF betrifft, so sind die ext. Mappings im voipd Log zu sehen: "ip address changed 10.0.0.3:5060 -> 85.216.40.161:24667").

Noch ein Hinweis: ich habe gerade gesehen, daß der Router ALGs auch für SIP hat. Wenn möglich, versuche mal den ALG für SIP abzuschalten. Bei meinem Netgear hat das seeeehr geholfen ;-)

--gandalf.
 
gandalf94305 schrieb:
Ich denke, das Problem ist Dein NAT, das dynamische Port-Mappings anlegt und nicht einfach für abgehende Ports ein Mapping erlaubt. Ich habe erst einige Router getestet, bis ich schließlich mit meinem Netgear-Router den passenden für VoIP gefunden habe, der auch nicht in die Knie geht, wenn man ein paar Torrents drüber laufen ;-)

An Ports sollten die von mir genannten ausreichen. Sie sollten nicht per Trigger, sondern fix auf die interne Adresse geleitet werden.

Was die FBF betrifft, so sind die ext. Mappings im voipd Log zu sehen: "ip address changed 10.0.0.3:5060 -> 85.216.40.161:24667").

Noch ein Hinweis: ich habe gerade gesehen, daß der Router ALGs auch für SIP hat. Wenn möglich, versuche mal den ALG für SIP abzuschalten. Bei meinem Netgear hat das seeeehr geholfen ;-)

--gandalf.

Ich habe mir den Router wegen seines guten Modems ausgesucht, denn meine Leitung ist ziemlich mies (35db Dämpfung) und nur mit so einem guten Modem komme ich wenigstens auf DSL-6000 (am ADSL2+ Port)... Er war auch eigentlich nur als Modem gedacht, bis ich gesehen habe, dass er wohl auch als Router (deutlich) leistungsfähiger ist, als die FBF.

Nun zu Deinem Hinweis... Dumme Frage, aber was ist ALG? Und wie könnte ich das ausschalten???
 
smartie schrieb:
Nun zu Deinem Hinweis... Dumme Frage, aber was ist ALG? Und wie könnte ich das ausschalten???

ALG = Application-Level Gateway

Dein Router nimmt an, er kennt etwas über das Protokoll und verändert entsprechend Pakete und NAT-Mappings... Wie man das ausschaltet sollte in der Dokumentation bzw. in irgendeinem Forum zu finden sein... Ich kenne den Router leider nicht aus eigener Erfahrung.

--gandalf.
 
gandalf94305 schrieb:
ALG = Application-Level Gateway

Dein Router nimmt an, er kennt etwas über das Protokoll und verändert entsprechend Pakete und NAT-Mappings... Wie man das ausschaltet sollte in der Dokumentation bzw. in irgendeinem Forum zu finden sein... Ich kenne den Router leider nicht aus eigener Erfahrung.

--gandalf.

Danke für den Tipp, deaktivieren ging nicht, aber ich hb einen Timeout verlängert etc, ach ich zitiere mal mein Posting aus dem anderen Forum:

packetloss schrieb:
Es stimmt zwar, dass bei den Speedtouch Geräten (mit neuester Firmware) die externe IP der DMZ (hier: Fritz!Box) zugeordnet wird, jedoch sollte NAT für die anderen Clients (-> Deine Rechner) trotzdem funktionieren! Hier ein Thread aus dem Whirlpool Forum, in dem ein User das Gleiche Setup haben möchte wie Du, vielleicht helfen Dir die Tipps dort weiter (zwar nicht für den 716i (ist in Australien nicht erhältlich), aber es sollte beim 716i genauso funktionieren).

Der Ansatz mit ALG ist sicherlich einen Versuch wert. Die Speedtouch geräte haben einige Dutzend Profile gespeichert.
!!!! ES FUNKTIONIERT !!!!!

Kaum zu glauben (ich hatte die Hoffnung ehrlich gesagt schon aufgegeben), aber wahr... es funktioniert und scheint inzwischen auch stabil zu sein. Ich bin erstmal happy (auch wenn es noch zwei kleine Schönheitsfehler gibt). Da ich einige Sachen geändert habe, werde ich der Sache nochmal Schritt für Schritt auf den Grund gehen, hier aber schonmal die ersten Infos was ich alles gemacht habe (falls jemand das Gleiche vor hat):

FBF:
+ IP-Client mit DHCP aktiviert

716iG:
+ Wie von Packetloss beschrieben ALLE Firewall-Module ausgeschaltet
+ Die connection-timer für UDP verlängert:
Code:
:connection timerconfig timer=udpidle value=1800
:connection timerconfig timer=udpkill value=1200
+ SIP-Application timeout verlängert
Code:
:connection appconfig application=SIP timeout=3600 trace=enabled tracelevel=3
+ Derzeit die Ports 1025-65535 per NAT an die FBF weitergeleitet

Aktuell noch vorhandene Probleme:
- Einige Anrufversuche über Sipgate sind fehlgeschlagen (obwohl die Nr. registriert ist). Das muss ich beobachten, eben funktionierte es. Kann auch ein Sipgate Problem gewesen sein (hoffentlich).
- Das DynDNS vom 716i funktioniert derzeit nicht (????). Obwohl die Konfiguration definitv korrekt ist, wird beri der IP-Adresse (die man ja nicht selbst eingeben kann/muss "0.0.0.0":
Code:
Configuration
Use DynDNS:Yes Internet Service:Internet
Username:XXXXX
Password:********
IP address:0.0.0.0
Dynamic DNS service:dyndns
Hostname:XXXX.dnsalias.net (Update needed)
Und im Protokoll steht dann:
Code:
DYNDNS Update failed for client dyndns_0, incomplete configuration
Na ja, fürs erste kann ich mit den Problemchen leben, ich werde mich nun dran machen, das ganze nochmal "von Null" an neu zu konfigurieren um zu sehen, ob es reproduzierbar ist. Und ob damit vielleicht auch der DynDNS Fehler weggeht (der sich vielleicht durch manches Rumprobieren eingeschlichen hat). Bis jetzt ist jedenfalls seit ca. 45 Minuten alles registriert...

Danke schonmal für alle Tipps!!! Ich hab echt nicht mehr damit gerechnet, dass ich es hinbekomme...
 
Soooo,
jetzt läuft erstmal alles... :D :D :D

Nach dem Zurücksetzen war es schon ein ganzes Stück Arbeit alle Settings wieder hinzubekommen, aber jetzt funktioniert auch Sipgate und DynDNS. Ich hoffe das bleibt so

Abgesehen von den üblichen Settings habe ich folgende Einstellungen vorgenommen:
Code:
:firewall config state=disabled
:firewall config keep=disabled
:firewall config tcpchecks=none
:firewall config udpchecks=disabled
:firewall config icmpchecks=disabled
:firewall config logthreshold=disabled
:ids config state = disabled

:connection timerconfig timer=udpidle value=1800
:connection timerconfig timer=udpkill value=1200

:connection unbind application=SIP port=5060
:connection appconfig application=SIP timeout=3600 trace=enabled tracelevel=3
Dazu noch folgende NAT-Settings (zur FBF):
Code:
VoIP    

    Game or Application Definition

A game or application is made of one or more TCP/UDP port ranges. Each incoming port range can be translated into a different internal (local network) port range. Port ranges can be statically assigned to devices or dynamically assigned using an outgoing trigger.

Protocol    Port Range    Translate To ...    Trigger Protocol    Trigger Port    
UDP        5060 - 5062    5060 - 5062    -    -
UDP        5004 - 5004    5004 - 5004    -    -
UDP        3478 - 3479    3478 - 3479    -    -
UDP        5070 - 5072    5070 - 5072    -    -
UDP        7077 - 7081    7077 - 7081    -    -
UDP        30000 - 30012    30000 - 30012    -    -
UDP        10000 - 10000    10000 - 10000    -    -

Was ich jetzt noch (nach und nach) machen muss ist, die NAT-Settings, aus der FBF in den 716iG zu übernehmen...

Also, vielen Dank nochmal, gandalf! Auch ohne Deine Tipps und Aufmunterung hätte ich bestimmt schon aufgegeben

Ach ja.... :) :) :) :) :)
 
Sehr gut! Dann kannst Du das Wochenende ja nun anders verbringen, als nur am Router zu basteln ;-)

Viel Spaß weiterhin!
--gandalf.
 

Statistik des Forums

Themen
245,793
Beiträge
2,239,956
Mitglieder
373,011
Neuestes Mitglied
Maxim77788
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.