Telefon an WDS-Slave?

[heini66]

und ich hab keine lust auch nur 1 buschstaben dazu zu tippen.
seht doch alles schon x mal beschrieben.
auch sind wird hier keine kostenlose auskunftsmaschine.
und:
lesen bildet!

 

[abcmaster]

Hallo,
"Portweiterleitungen offen halten"

Hallo, was ich nicht verstehe, kann die FB (7050) das nun oder nicht? Und wenn ja, wo schalte ich es ein. Ich habe die Option nicht gefunden

 

[frank_m24]

Hallo,

Und wenn ja, wo schalte ich es ein. Ich habe die Option nicht gefunden

In den "Erweiterten Einstellungen" bei "Internettelefonie".

 

[blieni]

hören erst beim zweiten mal..

Hallo Ich möchte den trööt hier mal wieder hochholen, da mir letztens ein komischer fehler untergekommen ist:

Settting ist wie dieses von user "gfuer":

MASTER SLWLAN---LAN1---SLAVE FB7270 FW57

Ports an slave. 5060,5061 UDP
und für RTP 7077-8005 UDP

MT-C an DECT der FB7270

folgender reproduzierbarer fehler trat auf:

anwahl und herstellung eines internettelefonates funktionieren..aber..

BEI DER ERSTEN HERSTELLUNG HÖRT MICH DIE GEGENSTELLE(DER ANGERUFENE)NICHT... mein audiokanal zum hören der gegenstelle ist STILL.. ICH HÖRE DIE GEGENSTELLE NICHT!

auflegen..wahlwiederholung.. alles 100%...hören und sprechen

das passiert sowohl bei MT-C als auch bei Gigaset 4000micro

es muss immer ein zweites mal eine telefonverbindung hergestellt werden..fragen über fragen

kann mir jemand weitrerhelfen ?

09.07.2008 12:59 03XXXXXXXX G.711 468 - 37 ms 38 ms 0 ms (0 %)
0:01
(770 ms) 217.10.69.3 0 - 37 ms 0 ms 0 ms (0 %) Eingangskanal = 0 pakete ..ich höre nichts, nicht einmal das klingelzeichen der gegenstelle

09.07.2008 13:00 03XXXXXXXX G.711 1367 - 33 ms 29 ms -
0:01
(630 ms) 217.10.69.6 G.711 2052 - 33 ms 1 ms 0 ms (0 %) Eingangskanal = 2052 pakete also ich höre

dank im vorraus
blieni

 

[apo86]

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

Ich weiß, der Thread ist alt. Aber ich hab ihn bei der Suche nach Infos gefunden und muss dazu jetzt einfach was aus Sicht eines Informatikers sagen. Hilft vielleicht dem einen oder anderen, besser zu verstehen was da passiert.

Grundlagen: Wenn keine statischen Portweiterleitungen eingerichtet sind, sind von außen gesehen keine Ports offen. Sendet jetzt ein Client im Netz ein beliebiges Paket nach draußen, muss kurzfristig für eine mögliche Antwort der Rückweg geöffnet werden. Wäre das nicht so, würden schon Dinge wie ganz normales Webbrowsing nicht funktionieren - irgendwie muss die Antwort vom Webserver ja zu euch zurückkommen.
Das ganze nennt sich connection tracking oder stateful packet inspection und gilt immer für eine einzelne Verbindung. Alles was als Antwort zurückkommt wird weitergeleitet an den der die Anfrage gestellt hat. Und was genau zu dieser Verbindung gehört wird nicht nur anhand des Ports bestimmt. Das ist deutlich komplizierter und berücksichtigt unter anderem auch die IP Adresse. Kommt ein Paket von einer anderen IP, als von der, an die ich meine Anfrage geschickt habe, kann es unmöglich zur gleichen Verbindung gehören und wird daher verworfen.
Wer jetzt sagt "Ja aber das Paket aus dem Beispiel oben gehört doch schon irgendwie dazu", hat recht. Aber so intelligent sind diese tracking Mechanismen einfach nicht, sie arbeiten auf einer anderen Ebene. Sie erkennen Netzwerkverbindungen, aber nicht die Zusammengehörigkeit mehrerer Netzwerkverbindungen die einen komplexen logischen Vorgang bilden.


Wenn ich schon grad dabei bin: Warum es mit der statischen Portweiterleitung funktioniert ist auch interessant. Ehrlich gesagt, als ich das das erste Mal gelesen hab, war ich höchst verwirrt. Aber eigentlich ist es ganz einfach
Warum funktioniert VOIP hinter einem NAT Router eigentlich nicht? STUN tut exakt das, was es tun soll: Der Client erfährt, dass er nach außen mit der IP <öffentliche IP-Adresse> und dem Source-Port <random Port über 49151> sichtbar ist. Aaaaaber dieser Source-Port gilt nur für die aktive Verbindung - nämlich die kurzlebige Verbindung zum STUN Server (siehe oben, connection tracking). Versucht irgendjemand anderes (z.B. der SIP Server) danach eine Verbindung auf eben diesen Port aufzubauen, wird er scheitern - der Port ist einfach nicht mehr offen, weil die Verbindung zum STUN Server schon längst beendet ist. Und wäre er noch offen, würden eingehende Pakete nicht als zur Verbindung zugehörig erkannt und auch wieder verworfen.

Da kommt die Portweiterleitung ins Spiel: Wie wir in diesem Thread gelernt haben (das war auch mir neu) nutzt die Fritzbox diese auch für ausgehende Verbindungen, das heißt nach außen wird für den STUN Server der Source-Port <fester Port X> sichtbar sein, eben dieser Port ist dank statischer Weiterleitung auch immer von außen erreichbar (auch für nachfolgende Verbindungen des SIP Servers) und wird intern korrekt weitergeleitet. Und schon klappt alles so wie es soll.


Ich hoff jetzt mal das hab ich mir alles richtig zusammengereimt, hat mir schon ein bisschen Kopfzerbrechen bereitet. Angaben ohne Gewähr^^