[HowTo] VOIP-Accounts einer Fritz als IP-Client nach IP-Wechsel registrieren

[kriegaex]

Mit Freetz IP-Watchdog und Onlinechanged-Infrastruktur nutzen

Der Thread ist alt, aber weil ich indirekt in Freetz etwas zu dem Thema gemacht habe, möchte ich kurz davon berichten: Es gibt inzwischen die Möglichkeit, mit Freetz die von AVM nicht für IP-Clients hinter einem NAT gedachte Onlinechanged-Infrastruktur trotzdem zu nutzen. Dazu habe ich einen kleinen IP-Watchdog entwickelt, der minütlich bei einem STUN-Server die externe IP abfragt und bei Änderung beliebige Skripten starten kann, z.B. auch eines zum Aktualisieren der VoIP-Konten. Die Abfrage via STUN (über ein eigens von Ralf Friedl für Freetz entwickeltes Busybox-Applet) ist viel effizienter und schneller als via HTTP mit wget. Der Watchdog wird, wenn er sich aus irgendeinem Grund beendet, automatisch via /etc/inittab neu gestartet, und er funktioniert auch für Onlinechanged-Skripten von AVM, ist also in diesem Punkt besser als das Original. Einziger "Nachteil": Man braucht Freetz in einer aktuellen Entwicklerversion (Trunk) dafür. Es gibt aber auch einen Patch, der im Branch freetz-stable-1.2 funktioniert und alles Notwendige dort nachrüstet. Mehr dazu unter

• Freetz-Paket Onlinechanged-CGI
• Freetz-Patch "replace onlinechanged" (neuer IP-Watchdog)
• Ankündigung des neuen IP-Watchdogs im IPPF
• Backport des IP-Watchdogs auf Freetz 1.2pre

 

[lolli]

Hallo, habe die Kombination einer 7390 als VOIP-Client hinter einer 3370 als Router (bei mit aktueller Stable FW) - warum das so sein muss lasse ich jetzt mal außen vor. Frage: Geht dieser Lösungsweg noch bei der aktuellen FW und in Zusammenhang mit 1&1 VOIP am VDSL (DTAG-Port)? Danke!

 

[KunterBunter]

Das sollte wegen fehlendem VLAN-Tagging nicht funktionieren.

 

[lolli]

Habe es vorhin mal ganz "nackt" getestet (3370 als Router am VDSL, 7390 als IP-Client mit den 1&1 VOIP-Nummern und Endgeräten). Raustelefonieren ging, rein nicht (bisher kein Portforwarding), bleiben noch die 8h Registrierungsintervall bei 1&1 mit Hilfe des Script zu unterlaufen. Wo wäre jetzt noch das VLAN-Problem (benutze die 3370 nicht als Modem) ?

 

[KunterBunter]

Dann hat es sich erledigt.

 

[alecxs]

Tag zusammen,

viele schlaue Köpfe hier, Respekt! Da mir die Variante mit WAN-IP abfragen am sichersten erscheint (ist nicht mein eigener Anschluss und die Konfiguration soll wartungsfrei bleiben, also auch wenn aus irgendwelchen Gründen whatismyip.org in Zukunft möglicherweise nicht mehr existieren sollte funktionieren), benötige ich Hilfe die Clientbox mit dem passenden Script zu bestücken. Die Variante mit Rudyshell / DS-MOD kommt leider nicht infrage, da es sich um eine o2 Box als Leihgerät handelt (und diese nicht modifiziert werden soll/kann).

Die Fritzbox darf modifiziert werden, jedoch möglichst einfach per Telnet ohne Freetz, da ich Newbie bin. Dyndns wird nicht genutzt, wäre dennoch sinnvoll wenn es gleich mit eingebaut würde. Log wird nicht unbedingt benötigt hauptsache es funktioniert (kein USB vorhanden). Vermutlich macht es Sinn den Port auf 5061 zu ändern, das kriege ich noch alleine hin denke ich. Allerdings lesen sich die diversen Scripts für mich wie chinesisch, habe echt kein Plan von Linux oder Programmierung.

Das hier habe ich nach einiger Recherche gefunden:
http://www.goetze.co.uk/computer/o2boxwanip.html

Da der Thread ziemlich alt ist - gibt es aktuelle andere Lösungen die ich möglicherweise übersehen habe (Dr. Easy FTP)? Wenn nicht, hat jemand Zeit/Muse hier ein entsprechend angepasstes Script zu posten?

DSL Gateway: o2 HomeBox 6641 (Firmware 1.00(AAJG.0)b14-2b) VDSL im VoIP Betrieb (5060)
Client: FRITZ!Box Fon WLAN 7113 (Firmware-Version 60.04.68 ) im VoIP Betrieb (momentan 5060)

 

[alecxs]

hab jetzt was zu der fehlenden debug.cfg gelesen - kriegt man ein script mit dieser Firmware überhaupt noch zum laufen? sonst hat sich das eh erledigt, da muss ich ne Zeitschaltuhr an die Steckdose hängen

 

[koyaanisqatsi]

Abend

Bei der 7113?
Nee, da funktioniert alles noch.
Hab hier 3 Stück am Laufen.
1. telnetd aktivieren
2. Mit telnet oder PuTTY auf "fritz.box" Port 23 verbinden
3. Beim 1. Mal die debug.cfg aktivieren: echo -ne > /var/flash/debug.cfg
4. Wichtig!!! nvi benutzen bspw.: nvi /var/flash/debug.cfg
5. Vor dem ausloggen mit exit : echo clear_id 87 > /proc/tffs
...um das hier wieder loszuwerden:

Wenn das soweit bei dir geht, es verstanden ist, dann kriegste deine öffentliche IP so raus...

/usr/bin/wget -O- http://checkip.amazonaws.com/ > /var/tmp/myip.txt
export MYIP=$(cat /var/tmp/myip.txt)
echo $MYIP
/bin/ping -s 8192 -c 1 ${MYIP}
/usr/bin/traceroute ${MYIP}

...zum üben in der Konsole. Das klappt natürlich nur wenn Internetverbindung besteht.
Wenn du das soweit verstanden hast, und deine Version in der /var/flash/debug.cfg steht,
mal die debug.cfg ausführen mit: sh /var/flash/debug.cfg
...noch Fragen?

 

[alecxs]

Danke! Soweit verstanden, aber noch keine Zeit gehabt es auszuprobieren. Werde mich daran versuchen, vielleicht krieg ich das script ja alleine hin... kann aber paar Wochen dauern

 

[alecxs]

Verständnisfrage: was macht eigentlich der sip account mit der Antwort des STUN Servers, wozu verwendet er die, und vor allem wann und wie oft?

 

[koyaanisqatsi]

Abend
Was, wozu? - STUN wird verwendet um den benötigten, sonst lokalen IP/PORT, auf die Öffentliche umzubiegen.
Wann? - Immer.

Geänderte SIP Header: Via: From: Contact:

ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 93.220.3.78:5070;branch=z9hG4bK80ed7259960ce511b655e6e795493274;rport
From: <sip:[email protected]:5070>;tag=3371826499
To: <sip:[email protected]>;tag=32E2B2A0-55760E5B000A22CC-41587710
Call-ID: [email protected]
CSeq: 2 ACK
Contact: <sip:[email protected]:5070>
Max-Forwards: 70
Content-Length: 0

Beim Softphone PhonerLite steht der STUN so...

23:57:31,105: T: 212.227.67.194:3478
STUN
  public ip: 93.220.3.78:5070

...im Debug (Log).

 

[the.gangster]

Hallo alecxs
Die Frage hatte ich eigentlich in dem anderen Thread erwartet, wo du nach dem passenden Stun-Server gesucht hast.
Weil das etwas komplexer ist und dort gut erklärt wird, würde ich empfehlen: lies hier http://de.m.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Die Kurzform: den Verbindungstyp und Firewalltyp aufdecken um die Firewall entsprechend zu öffnen.

 

[alecxs]

Ich versuche gerade herauszufinden wozu dieses Script benötigt wird, wenn die Aufgabe eines STUN Servers doch die gleiche ist? Wie STUN funktioniert hab ich gelesen, nur weiß ich nicht was die Fritzbox dann mit den Daten anfängt. Wird STUN nur bei der Registrierung bzw. ausgehenden Telefonaten abgefragt? Und was ist dann der Unterschied zwischen dem IP-Watchdog von Alexander vs SIP-Registrierungsintervall auf 1 min gesetzt? Mir fehlen da einfach die Grundlagen für VoIP.

P.S. ich habe mir vorgenommen "chinesisch" zu lernen und mir ein script zu basteln, welches den STUN Server aus dem ersten SIP-Account der Fritzbox verwendet (weil diese Variable über das webinterface änderbar ist und nicht wie in obigen Lösungen fest im Quellcode hinterlegt). Nur drängt sich mir dann die Frage auf, ob nicht schon längst standard genau das getan wird, was ich hier laienhaft versuche nachzubauen?

 

[alecxs]

koyaanisqatsi danke für den Hinweis mit dem SIP Header. Mit 'immer' meinst Du vermutlich bei jedem Telefonat. Insofern bin ich jetzt etwas schlauer: während der Registrar Server erst in der Antwort die öffentliche Port/IP mittels Erweiterung des SIP Headers an die Fritzbox mitteilt, ermöglicht es STUN der Fritzbox dies bereits im Vorfeld selbst zu tun. Mir ist nur noch nicht klar für welche Anwendungsfälle das einen Unterschied macht? Gibt es Telefonate die nicht über den Registrar ausgehandelt werden?

 

[koyaanisqatsi]

STUN ermöglicht es eigenständigen IP-Telefonen, durch dass NAT des Routers hindurch, eine zurückadressierbare Verbindung/Übermittlung zum ITSP und dem Endgerät des Gesprächspartners zu Gewährleisten.
...sonst kein Ton (auf einer Seite), oder ähnliche Effekte.

In diesem Zusammenhang wird der Fehler oft zu sehr auf der eigenen Seite gesucht.
Diese Störung kann genauso gut an einer Fehlkonfiguration auf der Gegenseite beruhen.

Der Proxy hingegen dient der Identifizierung des Registrars, wie DNS, aber SIP-DNS.
Bei drei oder vier Fritz!Boxen im LAN gibt es 3 oder 4 verschiedene fritz.box Registrarserver/klienten.
...dann muss schon die IP oder der Proxy (auch IP oder Hostname) benutzt werden.

 

[alecxs]

STUN ermöglicht es eigenständigen IP-Telefonen ... eine Verbindung zum ... Endgerät des Gesprächspartners zu gewährleisten.

-> also direkt, nicht über den Registrar?

 

[koyaanisqatsi]

Der ITSP/Registrar vermittelt, bei IP direkt, und zu Analog/ISDN/Mobilfunk indirekt.
Den ITSP brauchts also nur für: Analog/ISDN/Mobilfunk

 

[alecxs]

Demnach ist STUN also nur für SIP <-> SIP Verbindungen erforderlich (wenn hinter NAT), alle anderen Verbindungen kommen ohne aus denn da klärt das zur Not noch der Registrar.
Um auf den Punkt zu kommen, interessant wirds ja erst bei eingehenden Verbindungen, die zwischen dem Verbindungsabbruch des Gateways und der Neuregistrierung des SIP Accounts liegen - hier kommt ja dann das Script ins Spiel. Während bei der Variante Registrierungsintervall verkürzen vermutlich der Registrar Server zu schnell überlastet wäre, ist die verkürzte Abfrage bei einem STUN Server weniger problematisch da diese 'nur' den NAT Typ testen können und extra für solche periodischen Abfragen gedacht sind. Das Script ist also die elegantere Lösung, da eine Neuregistrierung nur noch bei einem IP-Wechsel erfolgt. Bleibt nur noch die Frage offen, wieso das in der Standard STUN Config nicht genau so implementiert würde... Man müsste einfach ein Feld "STUN Intervall" haben wo man nur noch einstellt wie oft sich die Fritzbox/das Telefon erkundigen darf, und der Rest läuft automatisch. Oder sehe ich da was falsch?

 

[alecxs]

Habe mich nun für die Variante mit dem IP-Watchdog entschieden. Man kann zwar den STUN nicht ändern, aber es wird stun.1und1.de verwendet und den wollte ich ja sowieso nehmen
Ich bin jetzt mit der Box zufrieden und es läuft alles. Ich möchte jetzt nichts mehr ändern. Trotzdem habe ich eine Verständnisfrage. Warum läuft ctlmgr_ctl in der FRITZ!Box Fon WLAN 7112 - 87.04.88, in der FRITZ!Box Fon WLAN 7113 - freetz-stable-2.0 revision 13170 jedoch nicht?
Mein ursprünglicher Eintrag in onlinechanged.sh sah so aus

#!/bin/sh
# depends on FREETZ_REPLACE_ONLINECHANGED
#
# VOIP-Accounts einer Fritzbox als IP-Client nach IP-Wechsel neu registrieren -
# Fritz!Box Fon als IP-Client innerhalb eines Netzwerkes hinter NAT mit wechselnder externer IP-Adresse
#
# Die Clientbox bekommt vom IP-Wechsel (Zwangstrennung) des eigentlichen Routers nichts mit
# und vertraut weiterhin auf die Registrierungsintervalle für eine Neuregistrierung
#
# FIX: IP-Wechsel zeitnah erfassen und daraufhin eine Neuregistrierung der VoIP-Accounts erwingen
# BENÖTIGT: Patch Replace onlinechanged (http://freetz.org/wiki/patches/replace_onlinechanged)
#
# manueller Aufruf von der Konsole mittels 'killall ip_watchdog' (früher 'onlinechanged online')

case "$1" in
  online )
      if [ "$(ctlmgr_ctl r box settings/opmode)" == "opmode_eth_ipclient" ] &&  # Internetzugang über LAN
         [ $(ctlmgr_ctl r sip settings/sip0/activated) == 1 ]                   # Internetrufnummer *121# aktiv
        then
#          logger "$MOD_GET_IP_STUN meldet neue IP-Adresse: $IPADDR => VoIP neu registriert"
          voipd -R
      fi
    ;;
esac

jetzt hab ich nur noch voipd -R drin stehen, was ja im Grunde auch reicht

 

[andiling]

Die ctlmgr_ctl Aufrufe sind nur Abfragen (r steht für read) ob die Box im IP Client Modus ist und ob das (erste) IP Konto aktiv ist. Dass dürfte der Fall sein ergo entbehrlich.