Portweiterleitung für 5060

galegro

Neuer User
Mitglied seit
17 Jun 2019
Beiträge
32
Punkte für Reaktionen
0
Punkte
6
Ausgangslage ..

Leider kann unsere Fritz!Box 7590 kein RTP video. Von unseren (vier) Kameras von Mobotix kann jede einen voll funktionsfähigen SIP-Server für RTP audio&video bereitstellen. Innerhalb unseres Netzwerks können wir daher SIP-Telefonie für alle vier Kameras und zwei Grandstream 3380 und 3350 bereitstellen.

unser Wunsch ..

Unsere Türstation T25 (zentraler, lokaler SIP-Server) möchten wir via Sipgate mit dem Internet verbinden und somit per Internet-Telefonie erreichbar machen.

unsere Versuche ..

Wir können die Fritz!Box problemlos bei Sipgate registrieren. Da wir aber Bildtelefonie wünschen möchten wir natürlich die T25 bei Sipgate registrieren. Diese wird in unserem lokalen LAN hinter der Fritz!Box betrieben.

  • Sipgate stellt zwar einen STUN-Server zur Verfügung (stun.sipgate.net), der auch erreichbar ist, aber wir bekommen die Kamera bei Sipgate einfach nicht registriert.
  • Also versuchten wir, den Port 5060 via Portfreifgabe zur T25 zu leiten. Das scheitert jedoch daran, dass beim Aktivieren dieser Freigabe der externe Port von 5060 auf eine Nummer größer 60.000 sich ändert.
Weiß jemand Rat?
 

NDiIPP

Aktives Mitglied
Mitglied seit
13 Apr 2017
Beiträge
2,351
Punkte für Reaktionen
381
Punkte
83
Eine manuelle Portweiterleitung sollte normalerweise nicht notwendig ein. Schaue vielleicht erst einmal nach, ob die Option "Nutzung von Internettelefonie aus dem Heimnetz unterbinden" (Fritzbox > Telefonie > Rufnummern > Anschlusseinstellungen) aktiviert ist.
 

galegro

Neuer User
Mitglied seit
17 Jun 2019
Beiträge
32
Punkte für Reaktionen
0
Punkte
6
.., ob die Option "Nutzung von Internettelefonie aus dem Heimnetz unterbinden" (Fritzbox > Telefonie > Rufnummern > Anschlusseinstellungen) aktiviert ist.
Vielen Dank für deinen Hinweis, das war‘s.:) Vielen herzlichen Dank! Nun frage ich mich: Wie konnte ich nur so blind sein und das übersehen?;)

Mit etwas Nachdenken wäre auch meine zweite Frage überflüssig gewesen: Die Portweiterleitung für 5060 kann natürlich nicht funktionieren, diesen Port reklamiert schließlich die Fritz!Box für ihre SIP-Konfiguration. Damit scheitert vermutlich natürlich mein ursprüngliches Vorhaben, die Türstation T25 als Tk-Anlage einrichten zu können, es sei denn, man kann den Port in den verwendeten Apps auch abändern (z.B. 5061).
 
Zuletzt bearbeitet:

kisys

Neuer User
Mitglied seit
13 Jan 2009
Beiträge
19
Punkte für Reaktionen
0
Punkte
1
Es gibt noch eine Möglichkeit den Port via Telnet oder Config-Editor zu ändern, er findet sich ansonsten weiterhin in der Standard-Config auch wenn obiges deaktiviert ist. Nicht jede Anlage stört sich daran.

3CX beschreibt das Problem und Vorgehen in seinem Blog:
https://www.3cx.com/blog/docs/change-default-port-fritzbox/

Neben Telnet - welches so ohne weiteres nicht mehr zur Verfügung steht:
https://thomasheinz.net/telnet-debug-cfg-etc-auf-neuer-fritzbox-z-b-mit-fritzos-6-83-reaktivieren/

Lassen sich die Einstellungen auch mittels Config-Bearbeitung (Vorsicht, nicht einfach so die Textfiles ändern - dann stimmt die Prüfsumme nicht mehr und ein Einspielen ist nicht möglich - dazu gibts in den Editoren tools zur Korrektur der Prüfsummen) ändern:
https://www.mengelke.de/Projekte/FritzBoxJSTool

VIelen Dank auch an die Beitrag- und Tool-Verfasser für die Unterstützung.

So war es mir möglich eine etwas anspruchsvollere Anlage komplett fehlerfrei über Fritzbox anzubinden.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,475
Punkte für Reaktionen
839
Punkte
113
Die Aussage im verlinkten Blog-Eintrag bei 3CX:
Important: On newer firmware versions this procedure is not possible anymore.
kann man allerdings gar nicht genug unterstreichen.

Eine Änderung der "ar7.cfg" über eine Shell-Session mit anschließendem "reboot"-Kommando funktioniert - ziemlich sicher - in der überwiegenden Anzahl aller Versuche NICHT.

Der "ctlmgr" verwaltet eine Kopie dieser "ar7.cfg" in seinem Speicher und verzögert Änderungen anderer Komponenten an deren Inhalt (sofern sie über ihn erfolgen, was bei der Anwendung von "nvi" schon mal definitiv nicht der Fall ist) auch gerne mal, um so mehrere Schreibzugriffe zusammenfassen zu können (das geht in den Flash-Speicher, der nur eine begrenzte Lebensdauer hat und so mit allerlei Cache-Mechanismen versucht - auch auf verschiedenen Ebenen - die "Schreibbelastung" einzelner Zellen gering zu halten) und nicht bei jeder Kleinigkeit sofort die gesamte Datei neu schreiben zu müssen. Denn der Inhalt dieser (durchaus recht großen) Datei wird als "deflated stream" (mit zlib komprimiert) immer als Ganzes geschrieben und so zieht wenigstens nicht jede kleine Änderung in der Datei bzw. an einer einzelnen Einstellung in dieser, eine komplett neue Version der "ar7.cfg" nach sich.

Wer das nicht glauben kann oder will, braucht nur mal - bei laufenden "ctlmgr" wohlgemerkt - die eigene "ar7.cfg" löschen im TFFS (wirklich schlaue Tester legen sich trotzdem noch eine Kopie vor dem Löschen an und zwar auf einem Datenträger mit persistenter Speicherung - man weiß ja auch nie, ob die Box nicht vor dem oder beim Schreiben durch den "ctlmgr" abstürzt) ... das geht mit einem echo clear_id 113 > /proc/tffs ganz einfach und danach kann man sich (solange der "ctlmgr" noch keine neue geschrieben hat) auch mittels cat /var/flash/ar7.cfg oder mit dem AVM-eigenen checkempty <filename> davon überzeugen, daß da tatsächlich nichts mehr in der "Datei" steht (die "Gänsefüßchen" sind dem Umstand geschuldet, daß es sich nicht um eine reguläre Datei, sondern um einen Datenstrom aus einem speziellen Treiber (eben dem TFFS-Treiber) handelt).

Erst wenn man jetzt den "ctlmgr" beendet (mit ctlmgr -s) und dieser dabei den gecachten Inhalt der "ar7.cfg" wieder restauriert, steht da auch wieder etwas in der Datei. Wobei auch nicht (exakt) bekannt ist, ob der "ctlmgr" intern noch ein Flag führt, das anzeigt, ob die Datei seit dem letzten Schreiben geändert wurde ... vorsichtshalber sollte mal also vor dem Beenden des "ctlmgr" noch mit irgendeinem "ctlmgr_ctl w ..."-Kommando dafür sorgen, daß es tatsächlich etwas zum Schreiben gibt - sonst braucht man die "Vorsichtshalber-Kopie" schneller, als man denkt.

Überschreibt man aber einen der TFFS-Nodes, während der "ctlmgr" nicht aktiv ist (das Beenden habe ich ja schon oben angeführt, starten kann man ihn einfach wieder mit einem neuen ctlmgr), klappt das auch wieder zuverlässig. Nur sollte man den "ctlmgr" nicht zu lange gestoppt lassen (andere Komponenten brauchen ihn und fangen an zu heulen (wie ein Wachhund), wenn er zu lange abwesend ist) ... was dann wieder nicht dazu paßt, daß die meisten sicherlich bei der Benutzung von "nvi" nicht die allerschnellsten wären.

Also taugt "nvi" nur noch sehr bedingt zum Editieren solcher Dateien und man verwendet (je nach Gusto) vielleicht besser ein anderes Skript. Meinen Vorschlag dafür findet man hier: https://github.com/PeterPawn/YourFritz/blob/master/tffs/fritzos_scripts/tvi - wobei die "Erkennung" von Nodes, die für den "ctlmgr" relevant sind, nur anhand der Endung ".cfg" erfolgt und nicht 100% korrekt ist, denn es gibt auch Dateien, die nicht auf dieses ".cfg" enden (auch wenn die dann wohl nicht vom "ctlmgr" gecacht werden).

Neben der korrekten Behandlung (Stop, Speichern, Starten) für das "ctlmgr"-Problem vermeidet das Skript auch gleich noch unnötige Schreibzugriffe auf das TFFS (anders als "nvi", was die Datei in jedem Falle zurückschreibt in den Node), wenn sich der neue Inhalt nicht vom alten unterscheidet ... es gibt ja auch "Anleitungen", wo das "nvi" nur zur Anzeige des Inhalts von TFFS-Nodes empfohlen wird (dafür gäbe es bei mir dann "tcat", wobei das keine seitenweise Anzeige beinhaltet und damit z.B. mit "more" kombiniert werden müßte - wer allerdings ein aktuelles "modfs" verwendet, findet in dessen BusyBox auch das "less"-Applet, was bei AVM m.W. fehlt).

Ob man jetzt für so eine Änderung tatsächlich die gesamten Einstellungen einer FRITZ!Box durch Ex- und Import (mit zwischenzeitlicher Änderung) wiederherstellen sollte, liegt sicherlich auch wieder im Auge des Betrachters. Angesichts der Tatsache, daß in so einer Export-Datei nicht wirklich ALLE Einstellungen enthalten sind und man dann nach dem Import wieder "von Hand" nacharbeiten muß an verschiedensten Stellen, wäre sogar die Änderung über ein speziell dafür angefertigtes Image (Beispiele hier: FRITZ!Box-Kennwort vergessen ... was nun? (Mail-)Recovery a la AVM oder besser nicht? bzw. hier: https://github.com/PeterPawn/YourFritz/tree/master/toolbox) in meinen Augen (auch ich darf ja Betrachter sein) noch einfacher und schneller - zumindest dann, wenn die notwendigen Vorkenntnisse ohnehin bereits vorhanden sind.

Die "handwerklichen Arbeiten" sind jedenfalls in unter 10 Minuten zu erledigen ... auch auf einem "Live-System" vom USB-Stick (wenn der Rechner und der Stick nicht allzu lahm sind). Gerade das "build_reset_tainted_image" ist praktisch (für VR9-Boxen, GRX-Modelle brauchen ein SquashFS als Root-Filesystem - da kommt aber (hoffentlich in Kürze) auch noch etwas für) schon komplett ... anstelle des "echo clear_id" braucht es nur ein "mknod" ("tmpfs" ist bereits gemountet) und einen passenden "sed"-Aufruf (der Link für dieses Applet wird auch erstellt) und das Ganze ist schon erledigt (den Rest macht dann ja das Skript) - man muß das Image jetzt nur noch in den Speicher laden und starten lassen (zumindest wenn man "vor Ort" ist).
 
Zuletzt bearbeitet:

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,770
Beiträge
2,038,225
Mitglieder
352,704
Neuestes Mitglied
CalvinH