Telefon an WDS-Slave?

Wie meinst du das mit dem Provider sperren und dem voipd -R ausführen?

Danke im übrigen für euere Hilfe!

PS: Dachte auch, dass ich mit Hilfe der statischen Portweiterleitung das gleiche ezeilen kann wie mit deieser Einstellung "port offen halten"
 
Hallo,

der Name "Portweiterleitungen offen halten" ist meines Erachtens irreführend, es geht nämlich gar nicht um Portweiterleitungen bei dieser Funktion. Wenn ich die Funktionalität dieser Einstellung aus den Paketmitschnitten auf DSL Ebene richtig gedeutet habe, dann geht es dabei um folgendes:

NAT Router halten intern eine Tabelle vor, in der sie sich alle aktiven ausgehenden Verbindungen merken, um eine Antwort auf eine solche Verbindung zuverlässig an den Initiator übergeben zu können. Alle ankommenden Pakete, die keiner solchen Verbindung oder einer Portweiterleitung zugeordnet werden können, werden von der NAT-Firewall verworfen (z.B. Viren oder Wurmattacken ;)). Wenn eine gewisse Zeit auf einer Verbindung keine Daten mehr geflossen sind, dann nimmt der Router an, die Verbindung ist nicht mehr aktuell und löscht den zugehörigen Eintrag seiner Tabelle. Der Zeitraum dieser Löschung ist unterschiedlich, je nach Router zwischen 30 Sekunden und einigen Minuten. Treffen danach doch noch Antwortpakete ein, so werden sie verworfen.
Eine SIP Registrierung eines Clients ist nichts anderes als eine solche ausgehende Verbindung. Die SIP-Signalisierung für einen reinkommenden Anruf ist die Antwort des Servers auf die Registrierung des Clients. Wenn der Router aber schon die zugehörige ausgehende Verbindung für diese Registrierung in seiner Tabelle gelöscht hat, so verwirft er die ankommenden Pakete, weil er sie keiner Verbindung mehr zuordnen kann. Der Client merkt nichts davon, und der Server kann nichts dagegen machen, weil er nicht weiß, wie er den Client nun erreichen soll. Das ist der Grund, warum ankommende Anrufe manchmal funktionieren, oft aber nicht: Zwischen der Registrierung und der Löschung des NAT Tabellen Eintrages kommen die Anrufe an, nach der Löschung nicht mehr.
Und hier kommt die Option "Portweiterleitungen offen halten" ins Spiel: Sie schickt in regelmäßigen Abständen ein kleines Dummy-Paket ohne sinnvollen Inhalt an den SIP Server (ein UDP Paket mit 4 Byte Payload - also praktisch nichts), und zwar an den gleichen Port, wie er für die Registrierung verwendet wird. Der NAT Router glaubt also, die Verbindung ist noch aktiv, lässt folglich den Eintrag in seiner NAT Tabelle bestehen, und leitet reinkommende Anrufe ordnungsgemäß an den Client weiter: Das Telefon klingelt :phone:. Die kleinen Dummy Pakete ohne Inhalt richten keinen Schaden an, sie werden vom SIP Server einfach verworfen.
Da die Pakete nur Dummy Pakete sind und keinerlei Information enthalten, können sie bei einem IP Wechsel nicht helfen: Am SIP Server kommen viele solcher Dummy Pakete von vielen Fritzboxen an, er kann sie keinem Client zuordnen. Da kommen dann die Scripte von Novize ins Spiel, die in dieser Situation eine komplette Neuregistrierung erzwingen, die dann dem Server die neue IP-Adresse des Clients bekannt machen.
Meiner Meinung wäre der Name "NAT-Tabellen aktuell halten" besser gewählt.

Was also tun, wenn man die Option "Portweiterleitungen offen halten" nicht hat? Um den vorgeschalteten Router von Aktualität der Verbindung zu überzeugen, muss das ausgehende Paket einige Bedingungen erfüllen: Es muss mit dem richtigen Protokoll an den richtigen Port der richtigen Adresse gesendet werden. Einfach ein Ping an den Server reicht nicht. Mir wäre keine Möglichkeit bekannt, wie man ein solches Dummy Paket manuell erzeugen könnte (vielleicht wissen die Experten aus der MOD Szene, wie AVM diese Dummy Pakete erzeugt, ich vermute, es ist ein Feature des voipd oder vom "telefon" Binary). Man könnte sicherlich ein kleines Programm schreiben, dass dieses Paket erzeugt, das Problem ist nur: Es müsste die Parameter für den SIP Server aus der AVM Konfig auslesen, das würde die Sache schon wieder recht aufwendig machen. Alternativ müsste jeder diese Parameter von Hand konfigurieren, was die Sache fehleranfällig macht und definitiv nicht Einsteigertauglich ist.
Was man aber heute schon manuell kann: man kann eine Neuregistrierung erzwingen, die ja ebenfalls das Problem löst (Novizes Scripte tun ja genau das nach einem IP Wechsel). Alle 5 Minuten eine Neuregistrierung würden das Problem zuverlässig lösen. ABER:
Eigentlich wird das Intervall der Neuregistrierungen vom Server festgelegt, bei 1&1 sind es bis zu 8 Stunden. Ich hab keine Ahnung, wie die darauf reagieren, wenn plötzlich alle 5 Minuten eine Neuregistrierung aufläuft. Vielleicht blockt der Server dann sogar den Account, weil er eine DOS oder Hacker Attacke vermutet. Elegant ist das jedenfalls nicht.

Viele Grüße

Frank
 
frank_m24 schrieb:
Was also tun, wenn man die Option "Portweiterleitungen offen halten" nicht hat?
...dann einfach auf dem vorgeschalteten NAT-Router/Firewall eine feste (permanente) Portweiterleitung konfigurieren, z.B. vom Port 5060/udp auf dem Router zum SIP-Port 5060/udp der FBF. Oder wenn auf dem Router 5060 schon anderweitig benutzt wird, dann eben von einer anderen Port-Nummer (z.B. 5061/udp) des Routers zum Port 5060 der FBF. Mit solch einer festen Portweiterleitung für den SIP-Port kann man sich dann auch jegliche Maßnahmen sparen, Datenverkehr zu erzeugen, nur um den Port auf dem NAT-Firewall "offen" zu halten.

Und für die RTP-Ports, über die letzendlich das Gespräch selbst läuft, braucht man keine dauerhaften, festen Portweiterleitungen; da reicht es, einen STUN-Server für den VoIP-Account zu konfigurieren, damit beim Aufbau der Gesprächsverbindung das Port-Mapping des Routers ermittelt werden kann. Während eines Gesprächs ist dann ohnehin so viel Datenverkehr, dass der NAT-Router die RTP-Verbindung "offen hält" (da bedarf es keiner Nachhilfe), und danach darf er sie ruhig wieder vergessen, denn für die nächste Verbindung werden die RTP-Ports wieder neu ausgehandelt.

Nachtrag:
Ich sollte natürlich dazu sagen: Das bezieht sich ausschließlich auf den NAT-Firewall und hilft natürlich nicht gegen die Änderung der IP-Adresse nach einer DSL-Zwangstrennung. Dagegen hilft nur eine neuerliche Anmeldung der FBF beim SIP-Registrar (mit der neuen IP-Adresse), sonst wird vom VoIP-Betreiber ein eingehendes Gespräch nach wie vor an die alte IP-Adresse vermittelt - aber unter der ist die Box dann ja nicht mehr erreichbar.
 
Zuletzt bearbeitet:
ok und wie geht das dann genau? Ich habe dóch schon ports auf den repeater weitergeleitet.(s.h. Bilder Seite zuvor)
 
Die Einstellungen im linken Bild müßten eingentlich reichen. Und es braucht auch nur den einen Port 5060, der Zweite ist m.E. unnötig (es sei denn, es läuft z.B. noch irgend eine Erweiterung auf der Box (Asterisk, dtmfbox), die 5061 als weiteren SIP-Port benutzt). Die Weiterletung muß natürlich auf dem Router (d.h. die Box mit DSL-Anschluß) eingetragen sein, und nicht auf dem Slave. Aber ich gehe davon aus, dass Du das ohnehin so gemeint hattest. Und 192.168.0.201 ist die Adresse der Slave-Box, nehme ich an?

Damit sollten VoIP-Accounts auf der Slave-Box eigentlich vom Neustart der Slave-Box (oder dem Neustart des voipd auf der Slave-Box) bis zur nächsten Trennung der DSL-Verbindung für eingehende Gespräche erreichbar sein.

Damit die Slave-Box auch nach einer Trennung der DSL-Verbindung und anschließendem DSL-Verbindungswiederaufbau (verbunden mit der Zuweisung einer neuen IP-Adresse) wieder über VoIP erreichbar wird, hilft m.E. nur eine Vorgehensweise wie hier, oder ähnlich.

Übrigens, melden sich beide Boxen bei den VoIP-Providern eigentlich für die selben Rufnummern an, oder benutzen sie disjunkte Nummern?
 
Es sind unterschiedliche Nummern! Ich habe es also so gmeacht wie beschrieben, aber leider bringt das nichts. Problem beliebt witerhin bestehen!

Deine Annhamen sind korrekt! Die 192.168.0.201 ist meine SlaveBox. Also das sollte alles passsen,,,
Gruß TOM
 
bolle,
da der Thread ja von jemand anderem gestartet wurde,
was genau geht bei Dir eigentlich nicht? Ist die Slave-Box
  1. überhaupt nicht für eingehende Rufe erreichbar
  2. bereits nach einiger Zeit nicht mehr erreichbar, obwohl die DSL-Verbindung nicht getrennt wurde
  3. erst nach der DSL-Zwangstrennung nicht mehr erreichbar
?
 
das Problem unter 2., dass einghende Anrufe in der Slave Box nicht mehr durchkommen. Wenn ich die Box neu boote, geht es für einige Zeit aber dann ist wieder stille angesagt!

Gruß BOlle
 
Hallo,

@gfuer: Was ich nicht so richtig verstehe: Nehmen wir mal an, die SIP Signalisierung ist keine Antwort auf einer offenen Verbindung, sondern wird vom SIP Server aktiv an einen offenen Port des SIP Clients gerichtet: Woher weiß der Server, dass man ausgerechnet den Port 6060 in der Portweiterleitung geöffnet hat? Der SIP Client wird beim Registrieren mitteilen, dass er auf Port 5060 lauscht, er weiß nichts von dieser Portumleitung und nimmt seine lokale Einstellung. Wie exakt soll die von dir vorgeschlagene Lösung funktionieren?

Viele Grüße

Frank
 
frank_m24 schrieb:
Der SIP Client wird beim Registrieren mitteilen, dass er auf Port 5060 lauscht
Um zu ermitteln, dass der interne Port 5060 nach außen hin die Nummer 6060 hat, gibt es STUN. Das muß natürlich in den Account-Einstellungen aktiviert werden (-> d.h. einen STUN-Server eintragen).

Das läuft dann so: Der SIP-Client schickt von seinem Port 5060 über UDP eine Anfrage an den STUN-Server im Internet, und dieser teilt dann in seiner Antwort mit, von welcher Quell-Portnummer und von welcher IP-Adresse er die Anfrage erhalten hat. Danach weiß auch die FBF, unter welcher IP-Adresse und Port-Nummer sie nach außen hin (d.h. im Internet) sichtbar ist, und kann diese Daten beim REGISTER dem SIP-Registrar mitteilen (anstatt der internen Port-Nummer 5060 und der internen, privaten IP-Adresse).

Grüße
Gerhard
 
@bolle
Anscheinend hast Du meine vorletztes Posting (Nr.37) nicht gelesen, im zweiten Bild ist auf jeden fall einen Zahlendreher drin!

@frank_m24
Deine letzte Frage ist in der Tat interessant. Ich habe mich auch schon gefragt, was diese statischen Portweiterleitungen bringen. Aus meiner Konfigunration kann ich ja nur Vermutungen aus den Fakten herleiten.
Fakten: Ich habe sowohl am Master als auch am Slave eine Internetrufnummer registriert, beide funktionieren und beide sind bei GMX. Seit ich die statischen Portweiterleitungen eingerichtet habe, ist auch das Telefon am Slave zuverlässig zu erreichen, ohne ging es ja nicht richtig, ich habe aber die Option mit dem "Portoffenhalten" trotzdem noch an (evtl. sollte ich es mal deaktivieren und schauen was passiert).

Meine Vermutungen: Da ja vom Master zum Slave der Port 6060 auf 5060 umgeleitet wird, könnte man davon ausgehen, dass eingehende Anrufe normaler Weise auf Port 5060 eingehen (Obwohl 5060 kein Server Port ist, die gehen glaube ich nur bis 1024). Würde man den Port 5060 des Mastes direkt an den Slave weiterleiten, würde die Internettelefonie am Master selbst ja nicht mehr funktionieren, sondern nur noch am Slave, daher muss man irgendeinen anderen (z.B. 6060) nehmen. Im Moment kann ich mir nur vorstellen, dass diese statische Route in 2 Richtungen funktioniert, d.h. die Abgänge vom Slave auf Port 5060 werden vom Master auch wieder auf Port 6060 rausgeschickt (eigentlich hat man aber bei iptables separate Regeln für eingehen und ausgehend) :noidea:
Leider kenne ich zu wenig vom SIP-Protokoll, aber eine Antwort auf die Frage würde mich auch interessieren :)

Update: Ok, ich war zu langsam beim Tippen, die Erklärung vom gfuer klingt gut.
Das bedeutet also, dass statische Weiterleitungen in der Tat in beide Richtungen funktionieren, denn sonst kann der STUN-Server im Internet ja nicht feststellen, dass die Anfrage von Port 6060 kam wenn die Slave Box auf 5060 gesendet hat.
Das würde dann meines Erachtens aber auch bedeuten, dass wenn bolle die Ports korrekt weiterleitet es auch bei Ihm ohne die Option "Portsoffenhalten" funktionieren müsste!

@bolle
Beseitige mal Deinen Zahlendreher und melde uns Deine Antwort *neugierig*
 
Zuletzt bearbeitet:
Find ich nett das hier so rege Teilnahme gezeigt wird. Ich kann leider nicht soviel dazu beitragen....

So ob mit oder ohne Zahlendreher es geht nicht! Habe jetzt auch nur noch 6060 an 5060 drin. ..
Und an der Slave Box muss ich überhaupt nichts machen?

Gruß TOM
 
Hallo,

gfuer schrieb:
Um zu ermitteln, dass der interne Port 5060 nach außen hin die Nummer 6060 hat, gibt es STUN. Das muß natürlich in den Account-Einstellungen aktiviert werden (-> d.h. einen STUN-Server eintragen).
Nein, definitiv nicht. Habe ich eine korrekte STUN Konfiguration, dann sind Portweiterleitungen gar nicht mehr erforderlich. Die Option "Portweiterleitungen offen halten" aber schon. So habe ich lange eine 7050 hinter einem Draytek Vigor im Regelbetrieb gehabt, und dann noch mal hinter einer 7170 zum testen (allerdings nicht per WDS, sondern per "Internet über LAN").

gfuer schrieb:
Das läuft dann so: Der SIP-Client schickt von seinem Port 5060 über UDP eine Anfrage an den STUN-Server im Internet, und dieser teilt dann in seiner Antwort mit, von welcher Quell-Portnummer und von welcher IP-Adresse er die Anfrage erhalten hat. Danach weiß auch die FBF, unter welcher IP-Adresse und Port-Nummer sie nach außen hin (d.h. im Internet) sichtbar ist, und kann diese Daten beim REGISTER dem SIP-Registrar mitteilen (anstatt der internen Port-Nummer 5060 und der internen, privaten IP-Adresse).
Aha. Jetzt ließ dir noch mal genau durch, was du da selbst geschrieben hast (was ich übrigens gar nicht anzweifeln will):
"und dieser teilt dann in seiner Antwort mit, von welcher Quell-Portnummer und von welcher IP-Adresse er die Anfrage erhalten hat"
Quell-Port ... STUN dient also dazu, den Quell-Port der abgehenden Verbindung zu ermitteln. Dieser Quell-Port wird bestimmt durch die NAT/PAT Algorithmen des davor hängenden Routers. Er ist ganz eindeutig nicht identisch mit offenen Portweiterleitungen. Hast du eine Fritzbox als DSL Router, dann kannst du per "Paketmitschnitt auf DSL Ebene" schön herausfinden, welche Ports die Master-Box abgehend für solche Verbindungen nutzt. Wenn ich mich recht erinnere, dann liegen sie weit oberhalb der hier besprochenen Bereiche, meistens über 30000 (ich hab früher mal solche Analysen gemacht, ist aber lange her).
So ein Paketmitschnitt (angefertigt auf einer Master-Box) von einer SIP-Registrierung der Slave-Box (und evtl. auch von einem Dummy Paket ausgelöst durch "Portweiterleitungen offen halten), wäre interessanter Input für die weitere Diskussion. Schade, das ich meine zweite Fritzbox verkauft habe. :(
Wenn sich jemand der hier beteiligten berufen fühlt, so einen Mitschnitt anzufertigen: Damit könntet ihr der Nachwelt durchaus mal einen großen Dienst erweisen, wenn wir nämlich auf der Basis das Problem lösen können. ;)

Viele Grüße

Frank
 
bolle schrieb:
Und an der Slave Box muss ich überhaupt nichts machen?

Also, ich habe noch einmal in diesem Thread nachgeschaut und finde ist nach wie vor schwierig, Dein Problem nachzuvollziehen.
Ich Rate jetzt erst einmal:
Du hast 2 7170 über WDS verbunden mit WPA2 Verschlüsselung hoffe ich, an jeder Box hängt ein Telefon und jedes Telefon hat seine eigene Internetrufnummer die bei 1und1 registriert ist. Ausgehende Telefonate vom Fritz!Box Repeater (Slave) funktionieren zuverlässig, nur von extern eingehende Anrufe funktionieren nur zeitweise. Hinzu kommt, dass Du eine ältere Version (eine der ersteren) der 7170 hast. Bis hierhin richtig?

1: Sind beide Fritz!Box 7170 ältere Modelle, sonst wäre es am einfachsten beide zu vertauschen, die ältere als Basisstation (Master) und die neuere als Repeater (Slave) und dort dann zusätzlich die Option "Portsoffenhalten" mit anzugeben.

2: Ist die Telefonnummer der SlaveBox auch im Master registriert? Wenn ja kann das auch Probleme machen...

3: Falls es noch andere Fakten Deiner Konfiguration gibt, die hier nicht genannt worden: frank_m24 hat [post=708618]hier[/post] ein schönes HOWTO geschrieben wo drinsteht, welche Fakten für diejenigen interessant sind, die versuchen zu helfen, damit man nicht tausendmal nachfragen muss.

Ich hatte ja ein ähnliches Problem, welches hier gelöst werden konnte, schau in [post=900577]mein Posting[/post] wie ich gemacht habe, meine Hardwarekonfig steht auch schon für alle immer leicht ersichtlich in der Signatur. Ich will nicht meine Signatur loben oder andere schlecht machen, es erleichtert aber die Fehlersuche enorm!
 
frank_m24 schrieb:
Nein, definitiv nicht. Habe ich eine korrekte STUN Konfiguration, dann sind Portweiterleitungen gar nicht mehr erforderlich. Die Option "Portweiterleitungen offen halten" aber schon.
IMO braucht man entweder das eine, oder das andere (beides schadet natürlich auch nicht). Wenn im NAT-Router keine feste Portweiterleitung zur FBF Port 5060 eingetragen ist, dann führt ein ausgehendes Datenpaket, das von der FBF Port 5060 kommt (z.B. die STUN-Anfrage), dazu, dass der NAT-Router implizit eine vorübergehende Portweiterleitung zwischen FBF Port 5060 und einer vom Router frei gewählten Portnummer (eine die gerade frei ist) einrichtet. Werden keine weiteren Daten übertragen, wird diese vorübergehende Weiterleitung nach einem Timeout wieder gelöscht. "Portweiterleitungen offen halten" sorgt ja jetzt nur dafür, dass das diese temopräre Portweiterleitung durch Übertragung von Daten immer wieder aufgefrischt wird, damit sie nicht verfällt. Solange eine solche temporäre Portweiterleitung "offen" gehalten wird, ist sie IMO weitgehend gleichwertig zu einer festen Weiterleitung. Der wesentliche Unterschied ist, dass man bei einer festen Weiterleitung auch eine ganz bestimmte, feste Portnummer festlegen kann, unter der die FBF im Internet sichtbar werden soll (die sich dann auch nicht ändert), und dass eine feste Weiterleitung auch nach einen Reboot des Routers weiterhin besteht.
frank_m24 schrieb:
Quell-Port ... STUN dient also dazu, den Quell-Port der abgehenden Verbindung zu ermitteln. Dieser Quell-Port wird bestimmt durch die NAT/PAT Algorithmen des davor hängenden Routers. Er ist ganz eindeutig nicht identisch mit offenen Portweiterleitungen.
Mein Verständnis ist eingentlich schon, dass eine bestehende Portweiterleitung (z.B. 6060 nach 5060 auf der FBF), vom NAT-Router auch für ausgehende Pakete honoriert wird, d.h. wenn so eine Weiterleitung besteht, dann erwarte ich eigentlich, dass Pakete, die von der FBF von Port 5060 kommen, dann vom NAT-Router mit der umgesetzten Quell-Portnummer 6060 ins Internet weiter geschickt werden, und nicht mit irgend einer anderen Portnummer. Nur wenn keine Portweiterleitung besteht, dann sucht sich der Router beim ersten ausgehenden Paket, das von der FBF Port 5060 kommt, eine freie Portnummer und richtet dann eine vorübergehende Weiterleitung von dieser Portnummer zur FBF Port 5060 ein. Für alle Folgepakete wird dann diese temporäre Weiterleitung honoriert (solange sie existiert).

Btw, ich betreibe meine FBF7170 derzeit auch hinter einer FB SL WLAN (Verbindung alternativ über Kabel oder WDS - das macht aber IMO keinen Unterschied diesbezüglich). Den Datenverkehr mitgesnoopt habe ich schon häufiger. Und ich denke, dass ich bisher in den Paketmitschnitten auch immer die von mir erwarteten erwarteten Portnummern gesehen hätte. Hatte aber auch nicht speziell darauf geachtet. Bei Gelegenheit schau' ich nochmal, und achte dann speziell auf die Portnummern, die über die Leitung gehen.
 
Hallo,

gfuer schrieb:
Mein Verständnis ist eingentlich schon, dass eine bestehende Portweiterleitung (z.B. 6060 nach 5060 auf der FBF), vom NAT-Router auch für ausgehende Pakete honoriert wird, d.h. wenn so eine Weiterleitung besteht, dann erwarte ich eigentlich, dass Pakete, die von der FBF von Port 5060 kommen, dann vom NAT-Router mit der umgesetzten Quell-Portnummer 6060 ins Internet weiter geschickt werden, und nicht mit irgend einer anderen Portnummer.
Wenn das stimmt, dann hast du natürlich recht, und man bräuchte nicht mehr die Option "Portweiterleitungen offen halten" verwenden. Und da kommt jetzt der Paketmitschnitt ins Spiel, der mich wirklich interessieren würde.
Was meinst du: Wenn ich auf meinem PC ein Softphone installiere (meintwegen das 1&1 Softphone), den entsprechenden Port an meinen PC weiterleite, ob ich damit das Szenario nachbilden kann? Ich denke, ich versuche es mal.

Viele Grüße

Frank
 
Also, ich habe noch einmal in diesem Thread nachgeschaut und finde ist nach wie vor schwierig, Dein Problem nachzuvollziehen.
Ich Rate jetzt erst einmal:
Du hast 2 7170 über WDS verbunden mit WPA2 Verschlüsselung hoffe ich, an jeder Box hängt ein Telefon und jedes Telefon hat seine eigene Internetrufnummer die bei 1und1 registriert ist. Ausgehende Telefonate vom Fritz!Box Repeater (Slave) funktionieren zuverlässig, nur von extern eingehende Anrufe funktionieren nur zeitweise. Hinzu kommt, dass Du eine ältere Version (eine der ersteren) der 7170 hast. Bis hierhin richtig?
zu 100% richtig!!

1: Sind beide Fritz!Box 7170 ältere Modelle, sonst wäre es am einfachsten beide zu vertauschen, die ältere als Basisstation (Master) und die neuere als Repeater (Slave) und dort dann zusätzlich die Option "Portsoffenhalten" mit anzugeben.
Ja

2: Ist die Telefonnummer der SlaveBox auch im Master registriert? Wenn ja kann das auch Probleme machen...
nein

Habe auch an den AVM Support geschrieben( muss man hier echt mal loben!! die melden sich wirklich auf alle Mails!! Klasse Service!!)

vielen Dank für Ihre Anfrage. Anscheinend ist meinem Kollegen hier ein Fehler unterlaufen. Es ist nicht nötig eine Portfreigabe einzurichten um mit einer FRITZ!Box die als Repeater eingerichtet ist die Internettelefonie zu nutzen. Eine Portfreigabe wird benötigt, wenn Sie in Ihrem Netzwerk eine Serveranwendung (z.B. einen FTP- oder einen Web-Server) anderen Internetnutzern zur Verfügung stellen wollen. Die Portfreigabe müsste in diesem Fall in dem Gerät eingerichtet werden, welches auch die Internetverbindung herstellt, in Ihrem Fall die Basisstation.
Für die Internettelefonie ist jedoch keine Portfreigabe nötig.

Die von Ihnen genannte Option "Portweiterleitung des Internet-Routers für Internettelefonie aktiv halten" ist nur dann verfügbar, wenn eine FRITZ!Box die Internetverbindung nicht selbst herstellt sondern die Internetverbindung eines anderen Routers verwendet. Das betrifft aber nicht die WDS-Verbindung bzw. den Repeater. Nach Ihren Angaben ist die Basisstation direkt mit Ihrem DSL-Anschluss verbunden, daher ist diese Option auch nicht nötig und ist ausgeblendet. Die Option ist ebenfalls ausgeblendet, wenn eine FRITZ!Box als Repeater arbeitet.

Um ausschließen zu können, dass sich Ihre FRITZ!Boxen in einem undefinierten Zustand befindet bitte ich Sie die Geräte einmal zurückzusetzen. Bitte gehen Sie hierzu jeweils in der Benutzeroberfläche der FRITZ!Boxen in den Bereich System -> Zurücksetzen. Lassen Sie hier bitte die Werkseinstellungen laden. Nehmen Sie dann bitte Ihre Einstellungen erneut vor und testen Sie dann das Verhalten. (Zuvor können Sie Ihre Konfiguration in der Benutzeroberfläche im Bereich System -> Einstellungen sichern abspeichern, bitte testen Sie die FRITZ!Box aber zunächst mit einer von Hand eingestellten Grundkonfiguration. So kann ausgeschlossen werden, dass das Problem in der Sicherungsdatei gespeichert
ist.)

Bitte entfernen Sie zu Testzwecken auch einmal die Internettelefonie-Zugangsdaten aus dem Repeater. Konfigurieren Sie dann bitte die Basisstation für die Internettelefonie. Beobachten Sie dann bitte das Verhalten. Kommt es nun auch zu dem Problem, dass Sie keine Anrufe auf Ihre Internettelefonie-Rufnummer entgegennehmen können?

Bitte stellen Sie auch sicher, dass die Internetverbindung von Ihrer Basisstation permanent gehalten wird. Andernfalls ist es nicht möglich permanent Anrufe aus dem Internet entgegenzunehmen.

Was meint ihr dazu?

Gruß TOM
 
Hallo,

also schaden können die Hinweise aus der AVM Mail auf keinen Fall. Ich würde sogar sagen: Einen Versuch ist es wert.

Viele Grüße

Frank
 
Hallo Frank,

habe gerade vorhin auf der DSL-Verbindung der FB SL WLAN mitgesnoopt.

Bisher war bei mir eine permanente Weiterleitung von 5061 nach FBF/5060 konfiguriert. Und tatsächlich hatten auch die ausgehenden SIP-Pakete auf der DSL-Verbindung die Port-Nummer 5061.

Dann habe ich die Weiterleitung abgeschaltet, und dann gingen die SIP-Pakete mit Quellportnummer 61001 raus. Offenbar beginnen die automatisch/temporär vergebenen Portnummern ab 61000.

Und nachdem ich wieder eine Weiterleitung von 6060 nach FBF/5060 eingestellt habe, gehen jetzt die SIP-Pakete mit Quellportnummer 6060 ins Internet raus - wie erwartet.

Unangenehm aufgefallen ist mir bei dem Test jedoch, dass das Hinzufügen, Löschen, Aktivieren, Deaktivieren einer festen Portweiterleitung nicht sofort wirkt. Sieht so aus, als würden nach Ändern der Einstellung für alle noch "offenen Verbindung" weiterhin die alten Einstelleungen gelten, und erst wenn die Verbindungen wegen Inaktivität nach einiger Zeit verschwinden, oder wenn man die FB rebootet, dann wirken erst die geänderten Einstellungen.

Und weil es gerade so schön ist, habe ich jetzt nochmals die expliziten Weiterleitungen abgeschaltet. Diesmal hat der NAT-Router den SIP-Port der FBF auf den Port 61016 gemappt. Aber was sehen diesmal meine entzündeten Augen? Der Router weist einige eingehende SIP-Pakete (es waren NOTIFY Pakete - das ist aber für die NAT-Betrachtung eigentlich irrelevant) mit ICMP port unreachable ab, und leitet sie nicht an die FBF weiter! Die Ziel-Port-Nummer ist durchaus korrekt (61016), also frage ich mich, was ist bei diesen Paketen anders, als bei denen, die durchgelassen werden? Und da sehe ich auch schon einen Unterschied: Diese Pakete kommen von einer IP-Adresse, zu der die FBF bisher noch keine ausgehenden Pakete versandt hatte. Allerdings ist es in der SIP-Welt gar nicht so ungewöhnlich, dass man den Request zu einem Server schickt (z.B. zu einem Proxy), und die Antwort unter bestimmten Umständen von einem anderen Server (mit einer anderen IP-Adresse) erhält. Mit Servern, die sich so verhalten, hat man also offenbar durchaus ein Problem, wenn man keine expliziten Portweiterleitungen einrichtet (mit einer explizit eingerichten Portweiterleitung werden auch solche Pakete korrekt zur FBF geroutet).

Edit: Habe letztes sicherheitshalber noch einmal ausprobiert. Mit explizit eingerichter Portweiterleitung kommen die NOTIFY-Pakete bei der FBF an (sieht man im Output von voipd -v).

Also werde ich meine feste Portweiterleitung besser doch wieder aktivieren...

Grüße
Gerhard
 
Zuletzt bearbeitet:
Hallo,

gfuer schrieb:
Und tatsächlich hatten auch die ausgehenden SIP-Pakete auf der DSL-Verbindung die Port-Nummer 5061.
Gut, damit wäre das geklärt. Da es sich hierbei um eine Softwarefunktionalität handelt, sollten sich also alle Fritzboxen entsprechend verhalten - auch die, die "Internet über LAN" nicht explizit unterstützen.
Ist das eigentlich Standard bei NAT/PAT Routern, oder ein spezielles Feature der Box?

gfuer schrieb:
Dann habe ich die Weiterleitung abgeschaltet, und dann gingen die SIP-Pakete mit Quellportnummer 61001 raus. Offenbar beginnen die automatisch/temporär vergebenen Portnummern ab 61000.
Das kommt mir bekannt vor. In ähnlichen Regionen waren die Ports damals bei meinen Versuchen auch.

gfuer schrieb:
Diese Pakete kommen von einer IP-Adresse, zu der die FBF bisher noch keine ausgehenden Pakete versandt hatte. Allerdings ist es in der SIP-Welt gar nicht so ungewöhnlich, dass man den Request zu einem Server schickt (z.B. zu einem Proxy), und die Antwort unter bestimmten Umständen von einem anderen Server (mit einer anderen IP-Adresse) erhält.
Bei welchem Provider war das der Fall?
Hier könnte ich mir Problempotential vorstellen, vielleicht nicht unbedingt im hier diskutierten Anwendungsfall, aber bei den VoIP tauglichen Mobiltelefonen, die ja durchaus mal an Hotspots oder ohne statische Konfiguration an einem WLAN AP betrieben werden. Vielleicht eine Erklärung, warum so viele Leute Schwierigkeiten bei Nokias N- und E-Telefonen mit VoIP haben? Schließlich unterstützen die Nokias auch kein STUN, und die meisten verwenden es hinter einem NAT Router ohne Portweiterleitungen ...

So, aber jetzt der Salto Rückwärts: Wie lösen wir mit diesen Informationen bolles Problem? "Eigentlich" müsste bei ihm ja alles funktionieren, wenn er statische Portweiterleitungen einrichtet wie KingTutt es gemacht hat. Dazu dann noch STUN, und er ist glücklich. STUN sollte doch verfügbar sein an der Slave Box, oder?

Viele Grüße

Frank
 
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.