[Frage] Auslesen von Daten des aktuellen Telefonats möglich?

Super!
Klappt aber noch nicht ganz.
Bei meinen Beispielen in #8 geht das 1. Beispiel, aber das 2. zeigt bei deinem Programm falsch: Keine Verbindungen zur Zeit!

eisbaerin schrieb:

Super!
Klappt aber noch nicht ganz.
Bei meinen Beispielen in #8 geht das 1. Beispiel, aber das 2. zeigt bei deinem Programm falsch: Keine Verbindungen zur Zeit!

Zum Vergrößern anklicken....

Bei deiner Fritzbox gibts noch Port6 habe ich gerade gesehen. Das habe ich noch eben mit eingebaut. Jetzt müsste es gehen. Neue Version siehe Post (#20) von mir.

Jo, das geht jetzt. Bei meiner FB7170 ist Port 5 - ISDN und Port 6 - VoIP.
Was passiert aber bei 2 ISDN Gesprächen und 2,3,4 VoIP Gesprächen gleichzeitig?
Ich könnte mir vorstelle, daß auch noch Port 7, 8, 9, 10, ... möglich sind.

z23 schrieb:

Rynah, das klappt hervorragend, besten Dank!

Zum Vergrößern anklicken....

Das freut mich.

z23 schrieb:

Darf man erfahren, in welcher Sprache/Entwicklungsumgebung du das programmiert hast?

Zum Vergrößern anklicken....

Das Programm habe ich in Win32-Assembler mit der Entwicklungsumgebung "WinAsm Studio" geschrieben.

Das kann gut sein.
Kann es leider nicht testen, da ich keine Fritzbox mit OS 6.20 habe.

Log dich mal in die Fritzbox per Telnet ein und gebe folgende Zeile ein:

echo "AT&V" | nc 127.0.0.1 1011 | grep Port

Da wird wahrscheinlich eine Fehlermeldung kommen.

Moin

Klaro, nc oder netcat ist wegen Sicherheitswahn seitens AVM entfernt worden.
Wenn also die Callmonitorschnitstelle (Port 1012) nicht abgehört wird,ja, das geht noch, auch von einen Klienten,
können laufende (VoIP) Verbindungen auf der Box noch mit einem AVM Kommando angezeigt werden: showvoipdstat

Die Ausgabe enthält von Oben nach Unten:
1. Alle Internetnummern und ob registriert oder nicht, auch Statistiken
2. Die unterstützten Sprachcodecs, als Liste
3. Die Registrare, ob angemeldet und die an ihr angemeldete Klienten
4. Die letzten 10 vollendeten Verbindungen plus Statistik

Mit einem geschickten grep lassen sich die gewünschte Infos auch separiert rausholen.
Beispiel: showvoipdstat | grep "connected ok"
Weil das in der Ausgabe für ein laufendes Gespräch steht.
Achtung: Damit sieht man nur externe Verbindungen, Interne nicht.

Zum Testen also mal mit Handy/Smartfon anrufen.

Laufende Telefonate lassen sich auch über das WEB-Interface der FritzBox prüfen:
http://fritz.box/fon_num/sip_quality.lua
Wenn man dort den Haken bei "Detailinformationen beendeter Telefonate anzeigen und mit Push Service versenden" setzt, wird auch eine Art History angelegt.

Joe

Wurde schon erwähnt: Callmonitor Port 1012
Wenn aktiviert ist der im LAN erreichbar, beispielsweise: nc fritz.box 1012

Oder gerade getestet, in einer Windowskommandozeileneingabe: telnet fritz.box 1012
...und ruf dich mal an. :mrgreen:
...probier mal.

Du kannst aber "nc" auch nachrüsten. Am einfachsten geht das, wenn du das Modul mit freetz compilierst. Kopiere die Datei nc auf /var/media/ftp und rufe sie mit /var/media/ftp/nc auf. Freetz selber musst du gar nicht installieren.

z23 schrieb:

Rynahs Programm öffnet deshalb, wenn ich es richtig verstand, eine telnet-Session, führt
das Kommando (damals nc mit Port-grep) durch und returned jeweils einen Rückgabewert.

Zum Vergrößern anklicken....

und

Soweit ich weiß lassen sich telnet-Session nicht automatisieren, oder?

Zum Vergrößern anklicken....

Was verstehe ich falsch, wenn ich daraus nicht schlau werde?

Wo soll denn nun am Schluß die Abfrage stattfinden, auf der Box oder außerhalb?

Wenn es auch auf der Box sein darf, würde ich ganz normal die Anrufliste über libcalllog.so in Lua einlesen und die Gespräche anhand des Status "läuft noch" auseinander dividieren. Anders macht es ja AVM selbst auch nicht, wenn es z.B. beim Firmware-Update zu einer Anzeige der laufenden Gespräche kommt. Ob da dann ein internes Gespräch auch drin ist, weiß ich nicht ... sollte das nicht der Fall sein (und wenn AVM es nicht vorgesehen hat, würde ich den Aufwand für recht hoch halten, das selbst festzustellen), muß man halt damit leben.

Genauso habe ich allerdings keine Ahnung, ob das auch für eine periodische Abfrage taugt ... andererseits macht es AVM ja auch wieder so, wenn die Übersichtsseite ständig aktualisiert wird, solange sie im Browser geöffnet ist.

Da ja der telefon-Daemon an den Port 1011 nur intern (unter 127.0.0.1) gebunden ist, kann/muß dann 'checktel' ja irgendwie Kommandos auf der Box selbst ausführen. Dafür gibt es ja nun zig verschiedene Wege.

Wenn ich das richtig verstehe, scheitert es inzwischen am fehlenden 'nc'-Applet in der AVM-Busybox. Dafür lassen sich genug Wege finden, von einer anderen Busybox (oder auch nur socat/netcat als gesondertes Kommando) auf einem USB-Stick oder per wget aus dem Netz oder per WebDAV aus dem Netz oder oder oder.

Folgende Programme sind nach wie vor in der Busybox (oder besser der AVM-Firmware) enthalten und können teilweise auch nicht ohne weiteres entsorgt/ersetzt werden:

ftpget/ftpput
telnetd (kein Client, aber problemlos mit beliebigen Programm auf einem gesonderten Port zu starten)
tftp (get/put)
wget (nur HTTP)
httpsdl (nur HTTPS)
cp (vom USB-Stick)
davfs2 (copy after mount)
echo (um aus einer Telnet-Session heraus mit Hex-Kodierung in eine Datei zu schreiben, beim Einsatz von gzip wird der zu kodierende Teil kleiner)

Dann muß man nur die Abfragen durch checktel so weit erweitern, daß erst einmal die Existenz eines passenden Tools sichergestellt wird bzw. dieses dann unter einem definierten Namen in /var abgelegt wird (das könnte im Extremfall sogar eine bash-Shell sein, die kann dann wieder direkt auf Netzwerk-Sockets zugreifen).

Das klingt jetzt alles viel komplizierter als es am Ende ist ... die entscheidende Frage wäre logischerweise erst einmal, welches Programm man verwenden will und wo man es speichern kann. Wenn man ohnehin per Telnet auf die Box muß/will, kann man auch das Programm irgendwie auf die Box schaffen.

Am Ende findet sich immer ein Weg, eine absolut vernagelte Firmware gibt es einfach nicht (bei der derzeit verwendeten Hardware- und Software-Architektur).