MessageWaiting events not forwarded in a timely mannor
Hi,
I'm an AstLinux developer integrating FOP2 for a future release, excellent work Nicolás ! I'm hearing cheers from our users already. :-)
Our development team has been testing, using fop2-2.27-debian-i386, and we notice the mailbox icon is not updated on status changes, only a "service fop2 reload" (-HUP) updates the mailbox icon. Logging out/in does not update it.
We are using basically the standard default fop2.cfg file.
--
poll_interval = 86400
poll_voicemail = 1
--
(setting poll_interval very short did not help, and seems unnecessary)
Manually "nc 127.0.0.1 5038" using the "fop2" user I see:
--
Event: MessageWaiting
Privilege: call,all
Mailbox: 1234@default
Waiting: 0
Event: MessageWaiting
Privilege: call,all
Mailbox: 1234@default
Waiting: 1
New: 1
Old: 0
--
which FOP2 seems to recognize, but does not get reflected to the web client until a "service fop2 reload".
Is this a config error on my part or possibly a bug in the beta ?
Lonnie
I'm an AstLinux developer integrating FOP2 for a future release, excellent work Nicolás ! I'm hearing cheers from our users already. :-)
Our development team has been testing, using fop2-2.27-debian-i386, and we notice the mailbox icon is not updated on status changes, only a "service fop2 reload" (-HUP) updates the mailbox icon. Logging out/in does not update it.
We are using basically the standard default fop2.cfg file.
--
poll_interval = 86400
poll_voicemail = 1
--
(setting poll_interval very short did not help, and seems unnecessary)
Manually "nc 127.0.0.1 5038" using the "fop2" user I see:
--
Event: MessageWaiting
Privilege: call,all
Mailbox: 1234@default
Waiting: 0
Event: MessageWaiting
Privilege: call,all
Mailbox: 1234@default
Waiting: 1
New: 1
Old: 0
--
which FOP2 seems to recognize, but does not get reflected to the web client until a "service fop2 reload".
Is this a config error on my part or possibly a bug in the beta ?
Lonnie
Comments
FOP2 reflects voicemail status in realtime, there is no bug as far as I know. It might be a misconfiguration, or perhaps lack of permissions in your manager.conf file, as FOP2 sometimes fires UserEvents to pass some additional metadata that is not available on standard AMI events. For testing, be sure you have "all" permissions for the fop2 manager user.
Also, it is important to know what way are you using to modify the voicemails, if you use the commedian mail application, events are broadcasted. If you use external web based tools, ami is not aware of anything at that point.
--
[fop2]
secret = secret1
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.255
read = all
write = all
writetimeout = 1000
eventfilter=!Event: RTCPSent
eventfilter=!Event: RTCPReceived
eventfilter=!Event: VarSet
eventfilter=!Event: Cdr
eventfilter=!Event: ExtensionStatus
eventfilter=!Event: ChannelUpdate
--
I even tried without the "eventfilter" lines, same result.
Clearly fop2_server is handling the "Event: MessageWaiting" and I am using the using the standard VoicemailMain() to test.
A "service fop2 reload" (-HUP) always immediately updates the web client.
Lonnie
-X 511 -l /tmp
That will write a log file in /tmp (if you use version 2.26 log files are output.log and error.log, if you use 2.27 is only one log file named fop2_debug.log).
Run in full debug and check the output ..