FRITZ!Box Fon zu FRITZ!Box Fon ATA

[pfeffer]

Hi cyberax!

Hast Du X-Lite nach dem Eintrag des Outbound-Proxy mal neugestartet? - Häufiger klappt irgendwie die Ünernahme der geänderten Einstellungen nicht sofort.

Falls Dein Router symmetrisch NATet und der Router des Gesprächspartners auch, dann gibt es keine andere Möglichkeit als einen rtp- (outbound) proxy zu verwenden, um die Sprachkommonikation per SIP in beide Richtungen hinzubekommen.

Es könnte sein, dass die ATA den rtp-Proxy von sipgate kennt und verwendet, die Fon aber nicht. Würde mich aber sehr wundern.

In diagnostic log zeigt X-Lite an, welchen Firewall- bzw Routertyp es erkannt hat. Was zeigt es bei Dir an?

Gruß,
Pfeffer.

 

[cyberax]

Hi pfeffer!

Hatte ein bisschen mehr zu tun und war die letzten Tage nicht in Italien, deshalb bis jetzt kein neuer Input!

Ja, X-Lite hatte ich neugestartet, aber der Outbound-Proxy war auch schon zuvor eingetragen, dass hat nichts verändert.

Der Log von X-Lite sagt "Discovered Single Mapped Port Symmetric NAT Firewall", d.h. wenn ich mit zwei verschienden sipgate Accounts versuche von der Fritzbox auf X-Lite anzurufen wären beide hinter dem selben Router.

Derzeit habe ich aber auch noch ein anderes Problem: Die Box loggt sich - trotz cronjob - nach 30 Minuten aus. Da ich schon ein bisschen viel rumgespielt habe werde ich die Box morgen zunächst mit dem Recovery-Programm noch einmal komplett zurücksetzen und dann die bisher sinnvollen Mod. neu durchführen. Mal sehen ob das hilft, werde es kurz berichten...

Danke & ciao

Christian

 

[JSchling]

So, jetzt moecht ich das auch nochmal genaustens wissen. Wenn ich meine Fritzfon-Wlan auf ATA Firmware-Revision umstelle, kann ich die Box dann an einem DSL-Modem anschliessen, verhaelt sie sich dann auch exakt wie eine ATA ? hab ich trotzdem noch WLan ?
Das mit dem Reset ist ja komisch, aber gut, koennte man mit leben. Wie siehts aus bei Updates, kann man die bei geaendete HW-Revision einfach installieren ?

 

[cyberax]

Hallo!

Also nach meiner Erfahrung hast du dann kein WLAN mehr! Ob auch das Modem nicht mehr verfügbar ist weiß ich nicht, da ich das Modem hier nicht benutzen kann, aber konsequenterweise vermute ich nicht. Aber probier es doch einfach aus, man ist zwar etwas irritiert nach der Umstellung wegen einiger Fehlermeldungen, aber man kann die HWRevision immer noch zurückstellen (ging bei mir zumindest).

vg, Chris

 

[olistudent]

WLAN ist dann natürlich weg.
Aber man kann sich eine eigene Firmware machen, in der man in der rc.init für seine HW-Revision den Wert DSL=n setzt.
Sollte sich dann wie eine ATA-WLAN verhalten...

MfG Oliver

 

[k7power]

Hi,

mein Provider ist Qsc. Ich hab hier noch eine Fritzbox! Fon herumliegen, die ein integriertes ADSL Modem eingebaut hat. Wenn ich diese zur Fritz!box Fon ata modifiziere, kann ich sie dann auch praktisch wie eine ata nutzen ?

 

[cyberax]

So, nun endlich der seit einigen Tagen angekündigte Report: Das Recovery-Programm hat leider nicht ganz einwandfrei geklappt (bis mtd4 ging alles, hier trat dann immer wieder ein Fehler auf und es wurde abgebrochen). Ich habe anschließend nochmals die neuste mod. Firmware aufgespielt und die bisher erfolgreichen Änderungen vorgenommen. Dies sind:

in ar7.cfg:
mode = dsldmode_both
und unter bridgemode dhcp = yes (es gibt einen DHCP Server im Netz)

in voip.cfg:
STUN-Server eingetragen

in debug.cfg:
Cronjob eingetragen,
am Ende folgendes angefügt:
route add default gw 1.255.24.1
voipd -R
echo 8,2>/var/led


Nun funktioniert wieder alles wie gehabt, d.h. die ersten dreißig Minuten geht VoIP, danach funktionieren weder ein- noch ausgehende Anrufe.
Ich habe den cronjob testweise derzeit ausgeschaltet und es selbst mit voipd -R versucht, aber nach 30 min scheint dies nichts mehr zu helfen.

Mir ist allerdings aufgefallen, dass alle 30 min auch eine andere Routine abläuft, könnte diese vielleicht stören:

Apr 14 14:20:13 multid[296]: DHCPC: lan: state bound, got event t1-fired
Apr 14 14:20:13 multid[296]: DHCPC: lan: state bound, got event request-sent
Apr 14 14:20:13 multid[296]: DHCPC: lan: state renewing
Apr 14 14:20:18 multid[296]: DHCPC: lan: state renewing, got event timeout
Apr 14 14:20:18 multid[296]: DHCPC: lan: state renewing, got event request-sent
Apr 14 14:20:19 multid[296]: DHCPC: lan: state renewing, got event ack-received
Apr 14 14:20:19 multid[296]: DHCPC: lan: state bound (3600)
Apr 14 14:20:19 multid[296]: DHCPC: lan 1.255.24.35/255.255.248.0 gw 1.255.24.1 dns 1.253.128.10 1.253.128.11
Apr 14 14:20:19 multid[296]: Can't set default route
Apr 14 14:20:19 multid[296]: static routes: 2 deleted (0 failed), 0 added (0 failed)
Apr 14 14:20:19 voipd[330]: dnsservers reloaded
Apr 14 14:20:19 voipd[330]: dns: _sip._udp.1und1.de: query
Apr 14 14:20:19 voipd[330]: dns: _sip._udp.1und1.de: "0 0 5060 sip.1und1.de" ttl=300 from 1.253.128.10.
Apr 14 14:20:19 voipd[330]: >>> Request: REGISTER sip:1und1.de
Apr 14 14:20:19 voipd[330]: dns: _sip._udp.sip.1und1.de: query
Apr 14 14:20:19 voipd[330]: dns; _sip._udp.sip.1und1.de: not found
Apr 14 14:20:19 voipd[330]: dns: sip.1und1.de: query
Apr 14 14:20:19 voipd[330]: dns: sip.1und1.de: 212.227.15.197 ttl=300 from 1.253.128.10.
Apr 14 14:20:19 voipd[330]: <<< Status: 401 Unauthorized
Apr 14 14:20:19 voipd[330]: query_local_ipaddress: 0.0.0.0
Apr 14 14:20:19 voipd[330]: >>> Request: REGISTER sip:1und1.de
Apr 14 14:20:20 voipd[330]: <<< Status: 200 OK
Apr 14 14:20:20 voipd[330]: sip:[email protected]:15224: REGISTER complete (next in 1620 seconds)

Leider weiß ich nicht genau, was dieser multid Dienst macht, aber scheinbar will er alle 30 min die IP Adresse erneuern, oder? Könnte das "ausloggen" bei den VoIP Server damit zusammenhängen? Ohne Neustart meldet die Box sich bei keinem VoIP-Anbieter mehr funktionsfähig an, auch wenn sie es scheinbar glaubt (Status: 200 OK).

Hätte jemand eine Idee???

Vielen Dank & schöne Grüße,

Christian

 

[olistudent]

Hi.
Der multid ist für dhcp zuständig. Es sieht so aus, als würde er vom Server eine neue dhcp-Adresse beziehen.
Und dann registriert er sich bei 1und1.
Auf dem Log sieht soweit alles okay aus...

Hast du es mal ohne STUN versucht?

MfG Oliver

 

[cyberax]

Ja, sieht ganz gut aus, allerdings geht VoIP genau ab dem Zeitpunkt, ab dem diese Meldung erscheint nicht mehr, dann hilft nur ein Neustart. Ob multid wirklich der "Schuldige" ist, oder ob ein da noch andere Prozesse im Hintergrund laufen weiß ich leider nicht. Könnte man den Intervall von multid nicht verändern? (Bzw. wenn ja, wo???)

vg, Christian

 

[olistudent]

Probier mal den multid anzuhalten und neuzustarten. Was sagt das Log?
multid -s
multid

Du kannst das Intervall für den voipd ändern, aber für den dhcp-Client wüsste ich im Moment nix...

 

[cyberax]

Danke für den Tipp, war - zumindest auf den ersten Blick - eine gute Idee. Habe folgendes eingegeben:

multid -s
voipd -s
multid # voipd hat sich automatisch mitgestartet

War jetzt nur ein Schnelltest, aber ich werde es in 30 min noch mal ausprobieren.

Frage: Wäre es sinnvoll, dass als cronjob einzugeben? Oder würden laufende Gespräche dadurch unterbrochen?

 

[cyberax]

Hallo Oliver!

Erste Testergebnisse: mit der beschriebenen Vorgehensweise funktioniert das Telefonieren nach Eingabe der Befehle wieder, allerdings hält dieser Effekt im Gegensatz zu einem Neustart deutlich weniger als 30 min (genauer habe ich es noch nicht erfasst).

Bsp.: wie beschrieben multid und voipd zurückgesetzt, 15 min telefoniert, danach schon geht VoIP nicht mehr!

 

[olistudent]

Log?
Mach mal mit tcpdump ein Netzwerk-Dump, vielleicht kann man da sehen was vor sich geht.
tcpdump -s 0 -w /var/tmp/logfile -i eth0

MfG Oliver

 

[cyberax]

sorry, hier der log nach multid -s // voipd -s // multid:

~ # multid -s
Apr 14 20:53:55 multid[658]: dyncfg: libar7cfg.so loaded for Dyn_AR7CFG_struct
2005-04-14 20:53:56 multid: stopped.
Apr 14 20:53:56 multid[747]: stopped.

~ # voipd -s
Apr 14 20:54:02 voipd[670]: signal detected
Apr 14 20:54:02 voipd[670]: unregister for ua0
Apr 14 20:54:02 voipd[670]: unregister for ua1
Apr 14 20:54:02 voipd[670]: unregister for ua2
Apr 14 20:54:02 voipd[670]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:02 voipd[670]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:02 voipd[670]: >>> Request: REGISTER sip:sipgate.de
Apr 14 20:54:02 voipd[670]: <<< Status: 401 Unauthorized
Apr 14 20:54:02 voipd[670]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:02 voipd[670]: <<< Status: 401 Unauthorized
Apr 14 20:54:02 voipd[670]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:02 voipd[670]: <<< Status: 401 Unauthorized
Apr 14 20:54:02 voipd[670]: >>> Request: REGISTER sip:sipgate.de
Apr 14 20:54:02 voipd[670]: <<< Status: 200 OK
Apr 14 20:54:02 voipd[670]: sip:[email protected]:13855: UNREGISTER complete
Apr 14 20:54:02 voipd[670]: <<< Status: 200 OK
Apr 14 20:54:02 voipd[670]: sip:[email protected]:13855: UNREGISTER complete
Apr 14 20:54:02 voipd[670]: <<< Status: 200 OK
Apr 14 20:54:02 voipd[670]: sip:[email protected]:13855: UNREGISTER complete
voipd: stopped.
~ # multid
2005-04-14 20:54:08 multid: dyncfg: libar7cfg.so loaded for Dyn_AR7CFG_struct
Apr 14 20:54:08 multid[749]: dyncfg: libar7cfg.so loaded for Dyn_AR7CFG_struct
2005-04-14 20:54:08 multid: startup (Jan 20 2005 14:50:07)
Apr 14 20:54:08 multid[749]: startup (Jan 20 2005 14:50:07)
2005-04-14 20:54:08 multid: dyncfg: libar7cfg.so unloaded
Apr 14 20:54:08 multid[749]: dyncfg: libar7cfg.so unloaded
~ # Apr 14 20:54:08 multid[751]: br_add_if: add bridge eth0 failed - Device or resource busy (16)
Apr 14 20:54:08 multid[751]: br_add_if: add bridge usbrndis failed - Device or resource busy (16)
Apr 14 20:54:08 multid[751]: br_add_if: add bridge tiwlan0 failed - Device or resource busy (16)
Apr 14 20:54:08 multid[751]: static routes: 0 deleted (0 failed), 0 added (0 failed)
Apr 14 20:54:08 multid[751]: static routes: 0 deleted (0 failed), 0 added (0 failed)
Apr 14 20:54:08 multid[751]: dnsd: cache maxsize is 16384 bytes
Apr 14 20:54:08 multid[751]: DHCPC on lan
Apr 14 20:54:08 multid[751]: DHCPD on lan:0 skipped, is virtual interface
Apr 14 20:54:08 multid[751]: DHCPC: lan: state init
Apr 14 20:54:08 multid[751]: DHCPC: lan reset ip address
Apr 14 20:54:08 multid[751]: static routes: 0 deleted (0 failed), 0 added (0 failed)
Apr 14 20:54:08 multid[751]: chunk_alloc: max allocated packet chunks 1
Apr 14 20:54:08 multid[751]: 1 Packets
Apr 14 20:54:08 multid[751]: DHCPC: lan: state init, got event discover-sent
Apr 14 20:54:08 multid[751]: DHCPC: lan: state selecting
Apr 14 20:54:08 multid[751]: DDNS: is disabled
Apr 14 20:54:08 multid[751]: DDNS: no valid accounts
Apr 14 20:54:08 multid[751]: ONLINE: script /bin/onlinechanged not found.
Apr 14 20:54:10 multid[751]: DHCPC: lan: state selecting, got event offer-received
Apr 14 20:54:10 multid[751]: 2 Packets
Apr 14 20:54:10 multid[751]: DHCPC: lan: state selecting, got event request-sent
Apr 14 20:54:10 multid[751]: DHCPC: lan: state requesting
Apr 14 20:54:11 multid[751]: DHCPC: lan: state requesting, got event ack-received
Apr 14 20:54:11 multid[751]: DHCPC: lan: state bound (3600)
Apr 14 20:54:11 multid[751]: DHCPC: lan 1.255.24.34/255.255.248.0 gw 1.255.24.1 dns 1.253.128.10 1.253.128.11
Apr 14 20:54:11 multid[751]: static routes: 2 deleted (0 failed), 0 added (0 failed)
Apr 14 20:54:12 voipd[762]: startup (AVM FRITZ!Box Fon WLAN 08.03.37 AVM SIP v1.05.20 Jan 20 2005 14:50:36)
Apr 14 20:54:12 voipd[762]: using capi controller 4
Apr 14 20:54:12 voipd[762]: 0: [email protected] configured (STUN)
Apr 14 20:54:12 voipd[762]: 1: [email protected] configured (STUN)
Apr 14 20:54:12 voipd[762]: 2: [email protected] configured (STUN)
Apr 14 20:54:12 voipd[762]: 3 useragents configured
Apr 14 20:54:12 voipd[762]: INFO led: off (value=0)
Apr 14 20:54:12 voipd[762]: priority is -20
Apr 14 20:54:14 multid[751]: dns: 0.europe.pool.ntp.org: query
Apr 14 20:54:15 multid[751]: dns: 0.europe.pool.ntp.org: 82.161.0.227 ttl=120 from 1.253.128.10.
Apr 14 20:54:15 multid[751]: sending SNTP request to server 0.europe.pool.ntp.org (82.161.0.227)
Apr 14 20:54:15 multid[751]: The NTP time is 14.4.2005 18:54:14.968000 UTC
Apr 14 20:54:15 multid[751]: system time is 0.187000 seconds ahead
Apr 14 20:54:15 multid[751]: adjusting time backward 0.187000 seconds
Apr 14 20:54:15 voipd[762]: dns: _sip._udp.1und1.de: query
Apr 14 20:54:15 voipd[762]: dns: _sip._udp.sipgate.de: query
Apr 14 20:54:15 voipd[762]: dns: _sip._udp.1und1.de: "0 0 5060 sip.1und1.de" ttl=196 from 1.253.128.10.
Apr 14 20:54:15 voipd[762]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:15 voipd[762]: dns: _sip._udp.sip.1und1.de: query
Apr 14 20:54:15 voipd[762]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:15 voipd[762]: dns: _sip._udp.sipgate.de: "0 0 5060 proxy.de.sipgate.net" ttl=71253 from 1.253.128.10.
Apr 14 20:54:15 voipd[762]: >>> Request: REGISTER sip:sipgate.de
Apr 14 20:54:15 voipd[762]: dns: _sip._udp.proxy.de.sipgate.net: query
Apr 14 20:54:15 voipd[762]: dns; _sip._udp.sip.1und1.de: not found
Apr 14 20:54:15 voipd[762]: dns: sip.1und1.de: query
~ # Apr 14 20:54:15 voipd[762]: dns: _sip._udp.proxy.de.sipgate.net: "0 0 5060 proxy.de.sipgate.net" ttl=71253 from 1.253.128.10.
Apr 14 20:54:15 voipd[762]: dns: proxy.de.sipgate.net: query
Apr 14 20:54:15 voipd[762]: dns: sip.1und1.de: 212.227.15.197 ttl=196 from 1.253.128.10.
Apr 14 20:54:15 voipd[762]: dns: proxy.de.sipgate.net: 217.10.79.9 ttl=71253 from 1.253.128.10.
Apr 14 20:54:15 voipd[762]: <<< Status: 401 Unauthorized
Apr 14 20:54:15 voipd[762]: ip address changed 1.255.24.34 -> 213.156.XX.XX
Apr 14 20:54:15 voipd[762]: 492307XXXXXX: my address 213.156.XX.XX:35138
Apr 14 20:54:15 voipd[762]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:15 voipd[762]: <<< Status: 401 Unauthorized
Apr 14 20:54:15 voipd[762]: ip address changed 1.255.24.34 -> 213.156.XX.XX
Apr 14 20:54:15 voipd[762]: 492303XXXXXX: my address 213.156.XX.XX:35138
Apr 14 20:54:15 voipd[762]: >>> Request: REGISTER sip:1und1.de
Apr 14 20:54:15 voipd[762]: <<< Status: 401 Unauthorized
Apr 14 20:54:15 voipd[762]: ip address changed 1.255.24.34 -> 213.156.XX.XX
Apr 14 20:54:15 voipd[762]: 788XXXX: my address 213.156.XX.XX:35138
Apr 14 20:54:15 voipd[762]: >>> Request: REGISTER sip:sipgate.de
Apr 14 20:54:15 voipd[762]: <<< Status: 200 OK
Apr 14 20:54:15 voipd[762]: sip:[email protected]:35138: REGISTER complete (next in 1620 seconds)
Apr 14 20:54:15 voipd[762]: <<< Status: 200 OK
Apr 14 20:54:15 voipd[762]: sip:[email protected]:35138: REGISTER complete (next in 1620 seconds)
Apr 14 20:54:15 voipd[762]: <<< Status: 200 OK
Apr 14 20:54:15 voipd[762]: sip:[email protected]:35138: REGISTER complete (next in 1620 seconds)

@tcpdump: Blöde Frage, aber wie geht das? Ein telnet Befehl, den ich der FBF geben kann scheint es nicht zu sein, ich hoffe auch keine Win-Software, denn ich habe Mac OS X. Der Befehl tcpdump scheint im Mac OS X Terminal zu existieren, allerdings nicht mit den Parametern:

iBook:~ christian$ tcpdump -?
tcpdump version 3.8.3
libpcap version 0.8.3
Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ]
[ -E algo:secret ] [ -F file ] [ -i interface ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ] [ -y datalinktype ]
[ expression ]
iBook:~ christian$ tcpdump -s 0 -w /var/tmp/logfile -i eth0
tcpdump: (no devices found) /dev/bpf0: Permission denied

... sagt mir leider alles gar nichts!


Gruß, Christian

 

[pfeffer]

Du mußt Dir das, was olistudent verlinkt hat irgendwie auf die fritz!Box kopieren. z.B. mit
cd /var/tmp # in das RAM-Laufwerk wechseln.
wget http://www.akk.org/~enrik/fbox/bin/tcpdump
dann muss der Befehl ausführbar gemacht werden mit:
chmod a+x tcpdump
dann kann man den Befehl starten ungefähr wie von olistudent beschrieben:
./tcpdump -s 0 -w /var/tmp/logfile -i eth0

Gruß,
Pfeffer.

 

[cyberax]

Hi pfeffer!

Danke, das hat soweit nun geklappt.

Ich vermute tcpdump schreibt nun ein Protokoll in eine logfile, zumindest sehe ich außer zwei Zeilen (die sofort erscheinen) keinen weiteren Output über Telnet.

~ # ./tcpdump -s 0 -w /var/tmp/logfile -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

Wenn ich die logfile mit vi /var/tmp/logfile öffne erscheint ein lange und ziemlich wüste Datei, gibt es eine Möglichkeit die einmal komplett im Terminal auszugeben um sie dann zu kopieren?

thx & vg

Christian

 

[pfeffer]

Die Datei enthält genau die Daten, die über die Netzwerkkarte der Fritzbaox laufen. Es ist eine binär-Datei. Du kannst sie auf Deinen Rechner kopieren (mit tftp oder bei mod-Image auch mit ftp möglich) und mit ethereal angucken / dekodieren lassen. - Oder Du schickst sie Olistudent oder mir, um zu gucken, wo der Fehler liegt.

Gruß,
Pfeffer.

 

[pfeffer]

Hi cyberax!

Erstmal etwas NAT-Erklärung:
Jerde NAT-Router muss sich merken, welcher reinkommenden Pakete auf welche interne IP verteilt werden müssen. Dazu ändert der NAT-Router den Port, von dem aus der interne Rechner sendet. Eingehende Pakete auf die geänderte Portnummer werden dann auf den interne IP mit dem ursprünglichen Port weitergeleitet. Bei TCP funktioniert das auch gnz zuverlässig, weil klar ist, wann eine Verbindung beginnt und wann sie endet. Bei UDP ist das überhaupt nicht klar. Darum vergisst der NAT-Router nach einer gewissen Zeit die externe-interne-Port- und IP-Zuordnung, wenn keine Daten übertragen wurden.

Die Analyse Deine tcpdumps hat ergeben:
dass genau das bei Dir passiert. Dein Router "vergisst" die Zuordnung von externem UDP-Port und interner IP, wenn Du versuchst nach längerer Zeit eine Verbindung aufzubauen. Darum kommen die Antworten auf die SIP-Pakete (die per UDP transportiert werden) nicht mehr bei der Fritz!Box an.

Warum klappt trotzdem die Registrierung bei dem SIP-Provider?
Die Antwort liegt in eine seltsamen verhaltens des SIP-Providers 1und1: Die Registrierungsantworten werden offenbar an den UDP-Port zurück geschickt, von dem sie stammen. Sie werden nicht an den Port zurückgeschickt, den die Fritz!Box in der UDP-Nachricht selbst angibt. Darum kommen sie immer korrekt an, auch wenn der NAT-Router (weil er angenommen hatte, dass die verbindung nicht mehr besteht) einen neuen externen UDP-Port verwendet.

Bei der Antwort auf die INVITE-Nachricht hingegen schickt 1und1 die Antwort an den Port, den die Fritz!Box in der SIP-Nachricht angegeben hat. Der ist falsch, weil Dein NAT-Router ihn geändert hat.
Die Fritz!Box vermittelt diesen Port mit Hilfe des STUN-Servers bei einem Neustart des multid.

Eine Lösung für das Problem ist es, sog. "keep-a-live"-Pakete zu senden. Dabei sendet die Fritz!Box (oder der Provider) jede Minute oder so ein im Prinzip leeres Paket an den SIP-Provider, damit der NAT-Router nicht annimmt, die Verbindung sei beendet.

Gruß,
Pfeffer.

 

[cyberax]

Hi Pfeffer!

Tolle Erklärung! Stimmt, ich erinnere mich, dass in X-Lite auch so eine Einstellung existiert, aber mehr habe ich mir dabei bisher nicht gedacht!

Wie, bzw. wo in der FBF lässt sich der Intervall für diese keep-a-live Pakete denn einstellen? Bzw., wäre dies eine Sache für einen cronjob? Mir ist in voip.cfg die Einstellung "sipping_enabled" aufgefallen, ist die vielleicht dafür zuständig?

Vielen, vielen Dank schonmal, ich sehe erste Sonnenstrahlen am Ende des VoIP-Datentunnels!

Schönen Gruß,

Christian

Update: Habe die Keep-a-live Pakete bei X-Lite probeweise mal ausgeschaltet, dann geht es nach ca. 30 Min. auch nicht mehr!

 

[pfeffer]

Mir ist in voip.cfg die Einstellung "sipping_enabled" aufgefallen, ist die vielleicht dafür zuständig?

ja, ich glaube, genau das ist die richtige Stelle dafür. Auf "yes" stellen und es sollte gehen.
Falls es damit nicht geht, könnte man wohl auch was mit cronjob basteln.

Gruß,
Pfeffer.