Callmonitor 1.*

[cuma]

Schon seltsam, dass es für solch Äußerungen nicht einmal eine Verwarnung gibt

 

[olistudent]

Vielleicht hats noch kein Admin gesehen. Aber anschwärzen werde ich ihn nicht. :mrgreen:

MfG Oliver

 

[buehmann]

Hallo Guano,

Ich bin Besitzer eines MusicPals und würde mir jetzt auch sehr gern die Rufnummer auf dessen Display anzeigen lassen:

Hier mal ein Auszug aus der Anleitung wie es gehen soll:

Punkt 1 und 2 beziehen sich wohl auf den MusicPal, haben also mit Fritzbox und Callmonitor nichts zu tun. Beim dritten Schritt geht's nur darum, bei einem Anruf mit wget eine "Webseite" auf dem MusicPal abzurufen, mit der die Nachricht übergeben wird. Beim Callmonitor würdest du einfach die genannte Aktion

wget -O /dev/null "http://<DEINE MUSICPAL IP>/cgi-bin/call.cgi?cmd=${caller}" >/dev/null 2>&1

in die Listeners schreiben: http://trac.freetz.org/wiki/packages/callmonitor/listeners

(caller muss natürlich vorher definiert worden sein

Beim Callmonitor heißt die Variable für die Anrufernummer nicht caller, sondern SOURCE; weitere Variablen, die du verwenden kannst, findest du hier: http://trac.freetz.org/wiki/packages/callmonitor/listeners#Ereignis-InformationenfürAktionen

Im Endeffekt solltest du also von einem Listener-Eintrag der folgenden Art ausgehen:

in:request  ^  ^  wget -O /dev/null "http://<DEINE MUSICPAL IP>/cgi-bin/call.cgi?cmd=${SOURCE}" >/dev/null 2>&1

(bitte mit der Doku und der Zeile oben vergleichen und versuchen zu verstehen; nicht einfach nur abschreiben)

Hab auch schon sämtliche Optionen bei den Listeners durch.

Tatsächlich? Was hast du dir dafür angeschaut?

Viele Grüße,

Andreas

 

[atomphil]

E-Mail auch bei keiner Nachricht auf dem AB

Hallo,
ich habe folgendes Problem. Bei mir läuft freetz mit Callmonitor und soll mir eine E-Mail über verpaßte Anrufe schicken. Das funktioniert für erfolglose Anrufer auch prima mit der Regel:

in:cancel   ^   ^26266626$   mailmessage

Nun kommt es aber häufig vor, daß die Gesprächsbegehrenden bis zum Anspringen des FB-Anrufbeantworters warten und dann auflegen ohne eine Nachricht zu hinterlassen. In diesem Falle bekomme ich den Versuch erst durch die log-Datei der FB mit, da ja für Callmonitor der Ruf entgegengenommen, aber keine Nachricht durch den AB versendet wurde.

Weis jemand eine Lösung? Welche Zeile muß ich bei den Regeln einfügen?

.:atomphil:.

 

[Izzy]

Ich fürchte, da hast Du ein Problem. Es gibt bekanntlich 4 verschiedene Ereignisse (siehe Wiki): request, cancel, connect, disconnect. Ein Ereignis "ABort" gibt es nicht. Sobald der AB ran geht, ist das für CM "connect". Und egal, ob der anrufende nun etwas draufspricht oder nicht, ist der nächste Event "disconnect". Woher soll CM auch wissen, was beim AB geschieht?

Denkbar wäre aber u.U. folgendes: Bei "connect" ein Skript aufrufen, welches ein "Flag" setzt - und bei "disconnect" die Länge der Verbindung prüft. War sie kürzer als, sagen wir, 5 Sekunden, hat bestimmt niemand was draufgesprochen.

Wie genau das Skript dafür aussehen müsste, und ob das so überhaupt geht - keine Ahnung.

Ansatz zwei würde aber auf jeden Fall klappen: Bei "disconnect" wird ein Skript aufgerufen, dass in etwa wie folgt aussieht:

if [ ${DURATION} -gt 5 ]; then
  mailmessage ...
fi

d.h. es wird nur eine Mail geschickt, wenn der Anruf auch mindestens 5 Sekunden gedauert hat (die Zahl kann man natürlich auch anpassen).

Optimal ist das zwar auch nicht unbedingt - wäre aber eine Möglichkeit.

Beste Grüße,
Izzy.

 

[buehmann]

Hi atomphil,

den Bemerkungen von Izzy ist nichts hinzuzufügen (Danke!) ... außer: Damit du nicht herausfinden musst, wie du Skripte auf der Box anlegst, könntest du die Überprüfung der Dauer auch in einer Zeile in den Listeners erledigen:

in:disconnect   ^   ^26266626$   [ "$DURATION" -gt 5 ] && mailmessage

Andreas

 

[Izzy]

in:disconnect   ^   ^26266626$   [ "$DURATION" -gt 5 ] && mailmessage

Sicher, dass Du Quotes um die $DURATION machen solltest? "-gt" vergleicht Zahlen, keine Strings. Hm - wobei zumindest die Bash sich daran nicht zu stören scheint. Letztendlich stören die Gänsefüßchen also nicht - helfen aber auch nicht gegen "Leerstrings" - denn bei [ "" -gt 5 ] kommt dann doch der erwartete Fehler: "integer expression expected"...

Beste Grüße,
Izzy.

 

[atomphil]

Hallo Izzy, hallo Andreas,
vielen Dank für Eure Tipps. Die Version von Andreas funktioniert bei mir prima. Sowohl mit, als auch ohne Gänsefüßchen.

Allerdings sollte der Vergleich "-lt " heißen, denn ich will ja über die Schnellaufleger informiert werden.


Ganz nebenbei habe ich noch rausgefunden warum mir nie jemand was aufs Band spricht wenn der AB anspringt: Seit der Installation von freetz will der gar nicht mehr. Es kommt immer nur die Ansage "der Anruf kann nicht angenommen werden, bitte rufen Sie später wieder an" und nach Anlagenneustart ist es ganz weg.
Dazu gibt es hier schon ein paar Themen ohne Lösung und auch ein offenes Ticket.
Hat dieses Problem schon jemand im Griff`?

.:atomphil:.

 

[buehmann]

Hi Izzy,

Sicher, dass Du Quotes um die $DURATION machen solltest? "-gt" vergleicht Zahlen, keine Strings.

Die Shells machen keinen Unterschied zwischen Zahlen und Strings; für sie ist im Prinzip zunächst alles ein String. Die Quotes verhindern einfach, dass der Wert von DURATION in zwei Wörter zerlegt wird, falls er aus unerfindlichen Gründen ein Leerzeichen enthalten sollte. Ich habe mir angewöhnt, solchen Fehlern konsequent vorzubeugen (auch wenn es höchstunwahrscheinlich ist, dass DURATION z.B. den Wert "x -o 5" enthalten wird, der bei deiner Version nicht zu einer Fehlermeldung führen würde, obwohl das keine Zahl ist).

Andreas

 

[Izzy]

vielen Dank für Eure Tipps. Die Version von Andreas funktioniert bei mir prima. Sowohl mit, als auch ohne Gänsefüßchen.

Sowas liest man gern!

Allerdings sollte der Vergleich "-lt " heißen, denn ich will ja über die Schnellaufleger informiert werden.

Ooops - ja, freilich. Ich hatte halt noch meine Faxbenachrichtigung im Kopf, da isses genau umgekehrt: Es gilt bei mir, nur die wahrscheinlich "echten" Faxe zu melden, und die "fehlgeleiteten" auszufiltern. Hatte vergessen, das anzupassen - sorry. Zum Glück hast Du ja mitgedacht, und nicht nur stumpf kopiert

auch wenn es höchstunwahrscheinlich ist, dass DURATION z.B. den Wert "x -o 5" enthalten wird, der bei deiner Version nicht zu einer Fehlermeldung führen würde, obwohl das keine Zahl ist

Öh...äh...hone: OK, gebe mich geschlagen. Man sollte auch die unwahrscheinlichen Fehler abfangen, wenn es sich anbietet Und an die "implizierte Typ-Konvertierung" habe ich wohl nicht gedacht. Benimmt sich die Shell also genau wie PHP

Beste Grüße,
Izzy.

 

[cuma]

Ich bekomme in "/var/log/mod.log" folgenden Fehler beim Booten:

Setting up virtual network interface ... done.
Usage:	phonebook [option]... command [argument]...
	phonebook {get|exists|remove} 053712931
	phonebook put 0357937829 "John Smith"
	phonebook list [all]
	phonebook init # prepare SIP to name mapping
	phonebook tidy # tidy up phonebook (sort)
	phonebook flush # flush temporary caches
Options:
    --local  suppress reverse lookup
    --debug  enable extra debugging output
    --help   show this help and exit
Starting callmonitor...done.

Hat jemand eine Idee wie ich das wegbekommen kann? In älteren Revisionen war der noch nicht da

 

[Izzy]

Sicher, dass Du damit im richtigen Thread bist? Phonebook ist IMHO doch Teil der originalen Firmware, und nicht vom CallMonitor? Lasse mich natürlich gern berichtigen, sofern ich mich irre...

 

[buehmann]

phonebook ist ein Teil des Callmonitors. Der Fehler, auf den du, cuma, gestoßen bist, tritt wegen eines Fehlers in der Busybox auf, und zwar des gleichen, der die Ursache hier war: http://www.ip-phone-forum.de/showthread.php?p=1195168&postcount=46
Ist der dort genannte Workaround bei dir aktiv? (Die Busybox darf nicht als Standalone-Version kompiliert worden sein.)

Andreas

 

[cuma]

@Izzy: Ist reproduzierbar mit

$ killall callmonitor
$ sh -x ./rc.callmonitor
...
+ modreg extra callmonitor Wartung 1 maint
+ modreg file listeners Listeners 0 /mod/etc/default.callmonitor/listeners.def
+ modreg file callers Callers 1 /mod/etc/default.callmonitor/callers.def
+ phonebook init
+ try_start
+ start
+ local exitval=0
+ is_running
+ local pid
+ [ -e /var/run/callmonitor/pid/callmonitor ]
+ read pid
+ kill -0 4753
+ phonebook start
Usage:  phonebook [option]... command [argument]...
        phonebook {get|exists|remove} 053712931
        phonebook put 0357937829 "John Smith"
        phonebook list [all]
        phonebook init # prepare SIP to name mapping
        phonebook tidy # tidy up phonebook (sort)
        phonebook flush # flush temporary caches
Options:
    --local  suppress reverse lookup
    --debug  enable extra debugging output
    --help   show this help and exit
+ start_daemon
+ echo -n Starting callmonitor...

...

@buehmann: Ich hab Trunk 2775, der Workaround im anderen Thread Verweist auf Revision 2655. Also sollte ich das doch haben. Vor dem Flashen war der nicht da

Ab #2767 ist BusyBox 1.12.2 im Trunk



Nach Downgrad auf #2766 ist wieder alles ok:

Setting up virtual network interface ... done.
Reading AVM's phone book...done.
Starting callmonitor...done.

 

[buehmann]

Verweist auf Revision 2655. Also sollte ich das doch haben. Vor dem Flashen war der nicht da

Dass du eine Revision jenseits des Workarounds benutzt, hatte ich in deiner Signatur gesehen. Ich wollte nur noch mal nachfragen, ob du nicht deine Busybox-Konfiguration vielleicht von Hand geändert hast (oder noch eine alte benutzt).

Ich schaue mir das an; da ich das Problem am Wochenende auch hatte, jetzt aber busybox 1.12.2 bei mir läuft, muss ich nur den richtigen Patch einchecken.

Andreas

 

[ht81]

Folgendes Problem

Hi,

also schnell zu meiner Konfig --> Die 7170 (hängt am DSL) hat Freetz drauf und den CM (siehe Signatur) dort ist der Callback eingerichtet, der per Fon3 raus geht auf den analogen Eingang von meiner 2ten Fritzbox (hängt an 7170 per LAN1 dran). Von 10 anrufen gehen etwa nur 5 -6 durch. Mein Problem ist, das ich zwar IMMER ein Callback erhalte von meiner 7170, aber meine 2te Box die CallerID nicht erkennt (in der FB anruferliste steht "unbekannt"), somit bekomme ich immer die Ansage "Ihre Verbindung wird gehalten". Da ja "keine Rufnummer" übermittelt wurde bekomme ich auch keine Durchwahl. Wie gesagt, aber nicht immer! Ab und zu geht es einwandfrei..... Wenn ich den Fred hier lese habe ich ja dann auch das Problem mit der Busybox, oder??? Siehe meine aktuelle Sig. bezüglich Freetz Version. Wenn ich nun auf Freetz 2766 gehe, müsste doch alles wieder ok sein, oder benötige ich bei der Version immer noch das Workaround?

P.s. mir fällt grad noch was ein: Wenn ich ein Callback vom Handy aus mache, bekomme ich es öfters hin als wenn ich vom Festnetz versuche ein Callback zu machen. Falls es eine Bedeutung hat.

 

[buehmann]

Hallo Thomas,

Mein Problem ist, das ich zwar IMMER ein Callback erhalte von meiner 7170, aber meine 2te Box die CallerID nicht erkennt ...

all das ist kein Problem des Callmonitors (es sei denn, du beweist mir das Gegenteil): Mit Callbacks hat der Callmonitor nichts am Hut.

Wenn ich den Fred hier lese habe ich ja dann auch das Problem mit der Busybox, oder???

Hast du nicht; seit Version 2655 ist der Workaround im Trunk.

Andreas

 

[ht81]

Hallo Thomas,

all das ist kein Problem des Callmonitors (es sei denn, du beweist mir das Gegenteil): Mit Callbacks hat der Callmonitor nichts am Hut.


Hast du nicht; seit Version 2655 ist der Workaround im Trunk.

Andreas

Hi Andreas,

danke für deine Info. Ich dachte nur, das wenn der CM die Rückrufnummer wählt, es dort zu irgendein Problem kommt, sodass die 2te FB die CallerID nicht erkennt.

Hast Du vielleicht eine Idee was es sein könnte? Oder sollte ich mal im "Callback mit Callmonitor" Fred weiter posten?

 

[buehmann]

Ich dachte nur, das wenn der CM die Rückrufnummer wählt, es dort zu irgendein Problem kommt

Falls du auf die Funktion "dial" aus dem CM anspielst; die ruft nur die entsprechende Funktion in der Weboberfläche auf. Da steckt sonst nicht viel mehr dahinter, auf das ich einen Einfluss hätte.

Hast Du vielleicht eine Idee was es sein könnte? Oder sollte ich mal im "Callback mit Callmonitor" Fred weiter posten?

Probieren könntest du es da, weil die Leute, die diesen Thread lesen, bestimmt generell mehr Erfahrung haben mit Callbacks an sich (ich habe das noch nie gemacht). Aber wie gesagt, ich glaube, dass es mit dem CM nichts zu tun haben kann. Versuch doch zur Fehlereingrenzung einmal, die Situation mit der Wählhilfe aus der Weboberfläche nachzustellen.

Andreas

 

[ht81]

Hi Andreas,

o.k. werde ich machen. Wusste nicht das CM nur die entsprechende Funktion in der Weboberfläche aufruft. Also, dann mache ich mich mal ab ins andere Fred.

Trotzdem Danke nochmals für die Info + Danke für den Callmonitor. Bin nach wie vor total überzeugt und begeistert.