PVC-Option der FBF blockiert andere SIP-Accounts, auch am PC

nixgegendenise

Aktives Mitglied
Mitglied seit
6 Okt 2005
Beiträge
1,053
Punkte für Reaktionen
0
Punkte
36
Hallo,

ich habe mal bei einem Freund am DSL / PC gebastelt und folgendes bemerkt:
Er hat einen reinen DSL-Anschluss und realisiert seine Telefonie über SIP an einer FBF WLAN 7050 mit der FW 14.04.33. Für seinen SIP-Account nutzt er dabei die Option "weitere Verbindung für die Internettelefonie über DSL nutzen (PVC)" und darunter "Ich habe Zugangsdaten erhalten (PPP)". Klar ist, dass er an seiner FBF keinen anderen SIP-Account eintragen kann, da die FBF (leider) nicht den einen Account via PVC und den anderen direkt über das Internet registrieren kann.
Nun habe ich festgestellt, dass man bei ihm am PC aber auch keinen SIP-Account registrieren kann, (er hat als SIP-Programm eyebeam 1.3 oder 1.5, gleube ich), er bekommt Fehler 408, was definitiv an der PVC-Einstellung der FBF liegt, denn deaktiviert man diese Option, werden bei eyebeam die Accounts registriert, aber dafür wird sein "Haupt"-Account von der FBF deregistriert.
Wie kann man beides nutzen, den Account an der FBF via PVC und andere Accounts am PC ohne PVC? STUN-Server bei eyebeam bringen leider keine Abhilfe.

Vielen Dank
 
Hallo,

was ist denn das für ein Provider, der auf der 2. PVC keine fremden VoIP Accounts zulässt? Alice?

In den aktuellen Firmwares für die 7170 und 7270 kann man einstellen, ob VoIP Programme auf PCs über die erste oder 2. PVC geleitet werden. Die 7050 entscheidet das an anderen Kriterien. Entweder anhand von Protokollinformationen, Portnummern oder TOS Feldern. Hast du Einfluss auf diese Parameter? Dann kannst du testen, woran es liegt?
 
was ist denn das für ein Provider, der auf der 2. PVC keine fremden VoIP Accounts zulässt? Alice?
Ja.
Die 7050 entscheidet das an anderen Kriterien. Entweder anhand von Protokollinformationen, Portnummern oder TOS Feldern. Hast du Einfluss auf diese Parameter?
??? Meinst du, ob ich auf die FBF zugreifen kann und was ändern kann?
Dann kannst du testen, woran es liegt?
Wie?
 
Hallo,

nein, du musst es natürlich in der Software ändern. Könnte man es in der Box ändern, dann wüsste ich es wahrscheinlich. ;)
 
Und was genau muss ich in der Software ändern?
 
Leider finde ich bei eyebeam keinen einzigen dieser Parameter.
 
Hallo,

man kann nicht mal Portnummern in eyebeam verändern? Also das hätte ich erwartet. Die anderen Parameter sind zugegebenermaßen eher selten einstellbar.
 
portnummern unter eyebeam bei einstellungen für den sipaccount unter >> topology
 
Danke, voodoobaby,
hab jetzt mal ganz wild Portnummern eingetragen, die ich in meinem Router freigegeben hatte, allerdings ohne Effekt :(
Wisst ihr, ob man mit einem "Xtunnel" was machen kann?
 
Danke für den Hinweis, voodoobaby. Leider bringt mir der Thread aus dem cp-Forum nichts, denn Stuns habe ich eingetragen.
 
In den aktuellen Firmwares für die 7170 und 7270 kann man einstellen, ob VoIP Programme auf PCs über die erste oder 2. PVC geleitet werden. Die 7050 entscheidet das an anderen Kriterien. Entweder anhand von Protokollinformationen, Portnummern oder TOS Feldern. Hast du Einfluss auf diese Parameter? Dann kannst du testen, woran es liegt?
Was sind denn die Kriterien der 7170 und 7270, anhand der "VoIP Programme auf PCs" erkannt werden, um die Datenpakete dann entsprechend den Einstellungen zu routen?
 
Hallo,

keine Ahnung. Möglicherweise die gleichen, wie bei der 7050, nur kann man sie aktivieren und deaktivieren. ;)
 
Tauchen bei einer 7170 mit aktivierten 2. PVC eigentlich zwei separate Interfaces im ifconfig -a auf (je eines für jeden PCV), oder "verstecken" sich beide PVCs hinter einem gemeinsamen DSL Interface?
 
Hallo,

ich hab überhaupt kein Interface, dass sich direkt mit dem WAN Port in Verbindung bringen lässt. "dsl" ist ja auch nur ein Pseudo-Device des dsld, welches die Daten, die nicht intern verarbeitet werden, ins System routet. Es gibt haufenweise Datenverkehr, der von der Kombination dsld, multid, voipd, ctlmgr und evtl. auch avmike abgewickelt wird, der nie durchs System geroutet wird. Darüber werden sie die 2. PVC auch wegfischen.
 
Das "dsl"-Interface kann kein reiner Dummy sein, denn die Default-Route veweist (zumindest bei meiner SL WLAN) auf dieses Interface. D.h. der Kernel routet alle IP-Pakete ins Internet zu diesem Interface. Insofern würde ich schon das "dsl"-Interface als "Tor zum WAN" betrachten. Aber es ist schon klar, NAT, Firewall, uvm. passiert alles irgendwo hinter diesem Interface im proprietären Code. Und wenn es bei zwei konfigurierten PVCs kein zweites "dsl"-Interface gibt, dann muss wohl auch das Routing zum "richtigen" PVC im proprietären Code passieren. Wollte es nur mal wissen, da ich keinen Komplett-Anschluss habe, und es daher selbst nicht ausprobieren kann...
 
Hallo,

Das "dsl"-Interface kann kein reiner Dummy sein, denn die Default-Route veweist (zumindest bei meiner SL WLAN) auf dieses Interface.
Ein reiner Dummy ist es nicht. Es ist quasi der "Ausgang" des dsld für alles, was nicht intern verarbeitet wird. Schön zu sehen: Alles, was als Download aus dem Internet kommt, taucht hier als "Upload" auf. Damit "füttert" der dsld quasi den Rest des Systems. Ab hier verteilt es der Kernel auf die Bridge bzw. WLAN Devices.

D.h. der Kernel routet alle IP-Pakete ins Internet zu diesem Interface.
Alle, die er zu sehen kriegt. Was AVM vorher schon wegfiltert, sehen wir nicht, z.B. alles von TR069 oder vom Fernzugang (https).
 
Alle, die er zu sehen kriegt. Was AVM vorher schon wegfiltert, sehen wir nicht, z.B. alles von TR069 oder vom Fernzugang (https).
Aber ich wäre überrascht, wenn der Kernel die https-Pakete nicht zu sehen bekäme. Auf meiner 7170 taucht der Port ganz normal im "netstat -a" auf:
tcp 0 0 *:443 *:* LISTEN​
Der Daemon wartet hier also offenbar ganz normal auf eingehende TCP-Verbindungen auf Port 443, insofern muss die Verbindung letztendlich ja doch über den TCP/IP-Stack des Linux-Kernels 'reinkommen. [Firewall-Filterung der eingehenden DSL-Pakete und NAT-Umsetzung erfolgen natürlich noch vorher im dsld bzw. -Treiber]

Auch den Eintrag
forwardrules = "tcp 0.0.0.0:443 0.0.0.0:443 0"​
in der ar7.cfg würde ich als ganz normale Portweiterleitung des Ports tcp/443 an die FBF selbst auffassen.
 
So ganz steige ich nicht hinter eure Diskussion :(
Ich hab das Problem immer noch.
 
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.