ds-mod: callmonitor: listener problem.

[knseibert]

Hallo zusammen,
habe eine FBF 7050 mit der aktuellen ds-mod 14.04.01ds-0.2rc7.
Per Callmonitor schalte ich die Rufumleitung um.
Anruf von xxx soll die Rufumleitung löschen... alle anderen diese setzen.
Es funktioniert alles wunderbar, solange ich das mit dem eingebauten Testanruf teste. Sobald die Sache ernst wird (Anruf von extern) versagen die Regeln.

Listener:

!xxx yyy rul.sh set
xxx yyy rul.sh del

Syslog:

Mar 17 15:00:58 (none) daemon.debug callmonitor: detected 'telefon: 17.03.06 15:00     0s Slot: -1 ID: 1 CIP: 16         xxx outgoing              yyy ChargeU:    0^M'
Mar 17 15:01:02 (none) daemon.info callmonitor: SOURCE='xxx' DEST='yyy' SOURCE_NAME=';' DEST_NAME='' NT=true END=true
Mar 17 15:01:02 (none) daemon.debug callmonitor: processing rules from /tmp/flash/callmonitor/listeners
Mar 17 15:01:02 (none) daemon.debug callmonitor: [0] processing rule '!xxx' 'yyy' 'rul.sh set'
Mar 17 15:01:02 (none) daemon.debug callmonitor: [1] processing rule 'xxx' 'yyy' 'rul.sh del'
Mar 17 15:01:02 (none) daemon.debug callmonitor: [0] is END of call
Mar 17 15:01:02 (none) daemon.debug callmonitor: [1] is END of call
Mar 17 15:01:02 (none) daemon.debug callmonitor: [1] FAILED
Mar 17 15:01:02 (none) daemon.debug callmonitor: [0] FAILED

Steh momentan auf dem Schlauch.
Was habe ich übersehen?

 

[bluba]

Hi!

Hatte ähnliche Probleme mit Regeln für ether-wake. Bei mir war es so, dass der Testanruf funktioniert hat, wenn ich bei DEST die Telefonnummer (Vorwahl + MSN) eingetragen hatte. Wenn ich dann mit dem Handy angerufen habe, ist nichts passiert!
Dann habe ich bei DEST den Anschlussnamen eingetragen, bei mir dann z.B. SIP1. Und siehe da, es ging! Und zwar sowohl beim echten anruf, als auch beim Testanruf.

Keine Ahnung, ob das so gedacht ist, jedenfalls hat's so bei mir funktioniert und es tut immernoch!!

Hoffentlich klappts bei Dir auch bald!

Gruß, bluba!

 

[buehmann]

Keine Ahnung, ob das so gedacht ist,

Naja, das ist so gedacht: Beim Testanruf kannst du beliebige Quellen und Ziele angeben, um deine Regeln zu testen. Welches Quellen-/Ziel-Paar dann bei einem realen Anruf auftaucht, steht auf einem anderen Blatt. Sprich: Wenn man die Regeln unter "realen" Bedingungen testen will, muss man auch reale Nummernpaare verwenden (z.B. aus den Syslog-Meldungen des Callmonitors ermittelt).

Die SIP-Accounts als Ziel heißen bei eingehenden Anrufen SIP0 bis SIP9.

Andreas

 

[buehmann]

@knseibert: Der Callmonitor sagt dir im Log, warum deine Regel gepasst oder nicht gepasst hat. Ich helfe dir mal beim Lesen: Alle Zeilen mit gleichem Anfang, z.B. [0], gehören zusammen (sie sind gemischt, weil alle Regeln gleichzeitig ausgewertet werden):

Mar 17 15:01:02 (none) daemon.info callmonitor: SOURCE='xxx' DEST='yyy' SOURCE_NAME=';' DEST_NAME='' NT=true END=true
Mar 17 15:01:02 (none) daemon.debug callmonitor: [0] processing rule '!xxx' 'yyy' 'rul.sh set'
Mar 17 15:01:02 (none) daemon.debug callmonitor: [0] is END of call
Mar 17 15:01:02 (none) daemon.debug callmonitor: [0] FAILED

In diesem Fall ist das beobachtete Ereignis das Ende eines Anrufs (END=true), deine Regel ist aber für normale Anrufe geschrieben (Anfang eines Anrufs von außen). Deswegen passt die Regel nicht und sie scheitert (FAILED).

Du hast also offenbar einen Anruf aus deinem Log kopiert, der dein Problem gar nicht zeigt.

Gruß,
Andreas

 

[knseibert]

Es lag tatsächlich an DEST. Nach der Änderung auf SIPx hat es funktioniert.
Die Tatsache, dass im Logfile "END of call" auftaucht, hängt - so glaube ich - damit zusammen, dass diese Nummer zwar in der FBF eingetragen, jedoch keinem Telefon zugewiesen ist. Diese dient lediglich als callmonitor Nummer.

Danke für Eure Hilfe!

Kai