Callmonitor 1.*

[buehmann]

EVENT=in:request SOURCE='0176xxxxxxxx' DEST='518xxx'

habe dann diesen listener hier versucht:

in:request ^0176xxxxxxxx$ ^518xxx$ [...]

ging immernoch nicht, bis ich geschnallt habe dass ^,$,SIP0-9 usw. nur beim quellcode des programms benötigt wird

Mooooment (und ja, ab da redest du Blödsinn ;-)). Wenn du zwischen ^ und $ jeweils die oben bei SOURCE und DEST angegebenen Nummern einsetzt, muss die Regel genau bei diesen Nummern ausgelöst werden. Alles andere wäre ein Fehler im Callmonitor. Könntest du bitte das ganze noch einmal mit aktiviertem Debug-Modus durchführen und mir die Ausgabe schicken?

Zur Erklärung: ^ im Muster bedeutet, dass an dieser Stelle die Nummer beginnen muss; $ bedeutet entsprechend das Ende der Nummer. Somit heißt ^123$, dass die Nummer genau "123" sein muss.

Wenn du jetzt ^ und $ weglässt, funktioniert das natürlich auch; allerdings würde die Regel so auch bei allen Nummern reagieren, die vorne und/oder hinten länger sind als deine angegebenen. (In deinem Fall recht unwahrscheinlich, aber möglich.)

Gruß,
Andreas

 

[steview_n1]

ok, hab ich beim ersten mal auch so verstanden wie du es jetzt sagst.. aber es ist doch recht seltsam dass es mit ^xxx$ nicht funktioniert und ohne ^ und $ schon. sorry für die blöde frage.. wie aktiviere ich den debug-modus und was muss ich eingeben um diese ausgabe zu sehen? - wieder logread?
hab übrigens meinen letzten beitrag unten editiert. vielleicht könntest du mir auch noch diese 2 fragen beantworten.

Gruß,
Alex

 

[buehmann]

1. "killall syslogd" (oder "kill $PID", wobei $PID die Prozess-Id von syslogd ist)
2. Diese Infos/Warnungen kenne ich, weiß aber nicht, woher sie kommen (sind erst in den letzten Firmwareversionen aufgetaucht).

Debug-Modus: Auf der Callmonitor-Einstellungen-Seite oben anzuschalten. Die Meldungen ins Syslog sind dann ausführlicher (ja, kannst du wieder mit logread anschauen; ich nehme gerne "logread -f").

 

[steview_n1]

sorry, ich nehm alles zurück... mit ^xxx$ funktioniert alles bestens.. habe es grade wieder getestet. habe mich wohl irgendwo vertippt gehabt. Danke für die beiden antworten!
habe jetzt trotzdem den debugmodus aktiviert, hier die ausgabe (nach löschen des logs 1x anruf getätigt):

Feb 27 15:30:14 fritz syslog.info syslogd started: BusyBox v1.9.1
Feb 27 15:30:27 fritz daemon.debug callmonitor: >>> in:request ID=0 TIMESTAMP=27.02.08 15:30:27 SOURCE=0176xxxxxxxx DEST=518xxx EXT= DURATION= PROVIDER=SIP1
Feb 27 15:30:27 fritz user.err telefon[587]: SIGCHLD received!
Feb 27 15:30:28 fritz daemon.info callmonitor: [3+] SOURCE_DISP='0176xxxxxxxx' DEST_DISP='518xxx' ID=0 EXT= DURATION= TIMESTAMP='27.02.08 15:30:27' PROVIDER=SIP1
Feb 27 15:30:28 fritz daemon.debug callmonitor: [3:0] processing rule 'in:request' '^0176xxxxxxxx$' '^518xxx$' 'ether-wake -i lan 00:18:F3:xx:xx:xx'
Feb 27 15:30:28 fritz daemon.debug callmonitor: [3:0] event 'in:request' matches pattern 'in:request'
Feb 27 15:30:28 fritz daemon.debug callmonitor: [3:0] parameter SOURCE='0176xxxxxxxx' matches pattern '^0176xxxxxxxx$'
Feb 27 15:30:28 fritz daemon.debug callmonitor: [3:0] parameter DEST='518xxx' matches pattern '^518xxx$'
Feb 27 15:30:28 fritz daemon.debug callmonitor: [3:0] SUCCEEDED
Feb 27 15:30:28 fritz daemon.info callmonitor: [3:0] ACTION: 'ether-wake -i lan 00:18:F3:xx:xx:xx'
Feb 27 15:30:37 fritz daemon.debug callmonitor: <<< timestamp=27.02.08 15:30:37 event=DISCONNECT id=0 duration=0
Feb 27 15:30:37 fritz daemon.debug callmonitor: >>> in:cancel ID=0 TIMESTAMP=27.02.08 15:30:37 SOURCE=0176xxxxxxxx DEST=518xxx EXT= DURATION=0 PROVIDER=SIP1
Feb 27 15:30:37 fritz daemon.info callmonitor: [4] EVENT=in:cancel SOURCE='0176xxxxxxxx' DEST='518xxx' SOURCE_NAME='' DEST_NAME='1und1'
Feb 27 15:30:37 fritz daemon.info callmonitor: [4+] SOURCE_DISP='0176xxxxxxxx' DEST_DISP='518xxx' ID=0 EXT= DURATION=0 TIMESTAMP='27.02.08 15:30:37' PROVIDER=SIP1
Feb 27 15:30:37 fritz daemon.debug callmonitor: [4:0] processing rule 'in:request' '^0176xxxxxxxx$' '^518xxx$' 'ether-wake -i lan 00:18:F3:xx:xx:xx'
Feb 27 15:30:37 fritz daemon.debug callmonitor: [4:0] event 'in:cancel' does NOT match pattern 'in:request'
Feb 27 15:30:37 fritz daemon.debug callmonitor: [4:0] FAILED

ich schätze das 'FAILED' ist wohl normal, da ich für 'in:cancel' keine Aktion festgelegt habe, oder?

Gruß,
Alex

 

[buehmann]

Ja, das sind zwei Events in dem Logausschnitt (alle Zeilen mit [3...] gehören zusammen und alle mit [4...]), einmal für in:request, einmal für in:cancel (wenn du beim Testen auflegst). [4:0] ist deine erste Regel, die schlägt natürlich fehl, weil der Event-Typ nicht passt. Weitere Regeln würden unter den Kennungen [4:1], [4:2], etc. bearbeitet werden.

Andreas

 

[steview_n1]

OK, danke für die informationen
jetzt hab ich leider ein anderes problem.. hab einen thread im freetz-forum erstellt. vielleicht kann mir da einer helfen: klick

lg,
Alex

 

[JueLue]

Türöffner betätigen Callmonitor

Hallo!
Ich habe folgende Idee:
An meiner Fritzbox hängt am S0 ein ISTEC Türmanager. Wenn ich den anrufe:
(interne Rufnummer 55)

55<Pause>*71#<4stellige Geheimnummer>*

öffnet sich die Tür.

Ich hätte jetzt gern, dass wenn ich mit meinem Handy eine (geheime) MSN anrufe der Callmonitor über den DIAL-Befehl die Tür öffnet.
Meine Fragen:
Kann man über den DIAL-Befehl die Tastencodes übertragen (*,# und die Geheimnummer), gibt es eine Pause-Funktion und wie wählt man intern mit dem DIAL-Befehl?

MfG
Jürgen

 

[buehmann]

Hallo Jürgen,

der dial-Befehl kann genau das, was die Wählhilfe in der Weboberfläche von AVM kann (die ruft er nämlich auf). Wenn du also damit deinen Türmanager ansteuern kannst, wird es auch mit dem dial-Befehl gehen.

Die Zeichen * und # kann man einfach wie die Ziffern in die zu wählende Rufnummer einbauen; das habe ich selbst schon benutzt. Ob es ein Zeichen gibt, mit dem man eine Pause erzwingen kann, weiß ich nicht. (Ich weiß auch nicht, ob die Zeichen nach deiner Pause (in der ja wohl der Türmanager das "Gespräch" annimmt) als Tastentöne weitergegeben werden.)

Wie gesagt, probier am besten, ob du mit der Wählhilfe zum Ziel kommst, und übertrag die Lösung dann auf den dial-Befehl.

Andreas

 

[JueLue]

Ja, mit den Tastentönen, das geht wohl nicht so einfach, die Türstation wird zwar angewählt, dann werden aber keine weiteren Töne übertragen.
Gibts da ein Extratool?
JueLue

 

[buehmann]

Du könntest mal schauen, ob [thread=117590]dtmfbox[/thread] das kann. Als ich das letzte Mal geschaut habe, konnte man damit allerdings nur ankommende Tastentöne erkennen und keine senden.

Andreas

 

[bunni]

Hallo,
was muß ich in listeners eingeben, damit im Popup nur die
Nummer des Anrufers erscheint, und nicht zusätzlich noch an welche nummer es geht, denn an wen es geht ist mir weniger wichtig.

 

[buehmann]

Hallo bunni,

bei den meisten Aktionen kannst du die anzuzeigende Nachricht als Argument angeben, z.B.:

dboxpopup meine.dbox.adresse "${SOURCE_DISP} ruft mich an!"

Darüberhinaus lässt sich die Standardnachricht für die einzelnen Aktionen ändern. Näheres im Wiki: [wiki]software:callmonitor:anpassen[/wiki]
Zu den Variablen wie ${SOURCE_DISP}, die du verwenden kannst: [wiki]software:callmonitor:listeners#ereignis-informationen_fuer_aktionen[/wiki]

Gruß,
Andreas

 

[joelxy]

Hallo zusammen,

verstehe ich das richtig, daß wenn ich per config forward einen port freigebe, ich den port nicht wieder mit der selben Nummer schliessen kann. Der Callmonitor weiss ja sonst nicht was er machen soll, bei ein und der selben Nummer. Gibt es dazu eine Lösung den port durch Anrufe mit der selben Nummer einmal auf und wieder zu zumachen? So wie unten geht es wohl nicht, aus besagten Gründen.
Wäre schön zu hören.

Danke und Gruß

Joel!

in:request ^12345$ ^123$ config forward 6 on # 6. Portforwarding aktivieren
in:request ^12345$ ^123$ config forward 6 off # 6. Portforwarding deaktivieren

 

[buehmann]

config forward 6

gibt dir den aktuellen Zustand des Portforwardings ("on" oder "off"). Du könntest das also abfragen und dann entsprechend reagieren. Man könnte das in eine Listeners-Zeile quetschen, ich würde aber lieber ein kleines Skript dafür erstellen, ungefähr so:

case $(config forward 6) in
  "on") config forward 6 off ;;
  "off") config forward 6 on ;;
esac

Bei Gelegenheit könnte ich so etwas eigentlich mal direkt in "config" einbauen, so dass man "config forward 6 toggle" schreiben könnte.

Andreas

 

[joelxy]

Hallo Andreas,

schön das du so schnell geantwortet hast. Leider bin ich nicht so der scripter :-(
Wie und wo soll denn das kleine script hin? Oder sollte ich vielleicht warten, bis du das in 'config' direkt eingebaut hast?
Danke nochmal und Gruß

Joel!

 

[buehmann]

Ok, kopier die beiliegende Datei auf die Fritzbox, entpacke sie, kopiere sie nach /tmp/flash/callmonitor/actions.local.d/toggle.sh (das letzte Verzeichnis musst du ggf. erst anlegen), ruf "modsave flash" auf, starte den Callmonitor neu

gunzip toggle.sh.gz
mkdir /tmp/flash/callmonitor/actions.local.d
mv toggle.sh /tmp/flash/callmonitor/actions.local.d/
modsave flash
/etc/init.d/rc.callmonitor restart

und benutze dann

toggleforward 6

(oder eine andere Nummer) in den Listeners.

Andreas

 

[joelxy]

Hallo Andreas,

wow, das ging schnell!!!
OK, gemacht, getestet und es klappt!
Vielen Dank für die Mühe. Ich hoffe es fliesst in ein neues CallMonitor-Paket mit ein.

Schöne Ostern wünsche ich dir.

Gruß
Joel!

 

[buehmann]

Gern geschehen; ich wünsche dir auch schöne Ostertage.

Andreas

 

[fritzchen]

Frohe Ostern!
Ich weiß nicht seit wann, aber bei ich habe ein seltsames Phänomen:
fbf 7170, aktuelle beta mit freetz

ausgehender Anruf über s0, standard msn ist 74, der lcr macht aber 85 daraus
$SOURCE liefert mit leider aber nur die 74, auch bei event:disconnect - wo er es doch eigentlich besser wissen müsste, und die Anrufliste in der Box es auch korrekt anzeigt...

Eine eine österliche Idee?
Besten Dank!

 

[buehmann]

Hi,

so ganz verstehe ich dein Szenario noch nicht, aber du könntest einmal folgendes tun, damit wir sehen, was der Callmonitor sieht: Auf der Box "nc localhost 1012", und dann deinen Anruf durchspielen. Bei mir sieht das ganze bei einem Anruf auf meiner Sipgate-Mailbox z.B. so aus:

23.03.08 08:42:52;CALL;1;4;121;[email protected];SIP0;
23.03.08 08:42:53;CONNECT;1;4;[email protected];
23.03.08 08:42:56;DISCONNECT;1;4;

Frohe Ostern,

Andreas