[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: axc minor release
Quoting Gregg Liming (7/9/06 4:09 PM):
> Hi Darren,
>
> Quoting darrenp_lock (7/9/06 12:54 PM):
>> Greg,
>>
>> would it be possible for axc to wait for about 30-40 secs after a
call
>> terminates until the next CTI2 is sent? Currently it would appear
axc
>> does this as soon as the call terminates so the message count is
>> usually 0 as it takes a few seconds for the caller to leave their
>> message and I have set the polling interval to 6 mins currently.
>
> axc sends out the CTI2.info messages only on an interval basis. If it
> coincides with a call termination, then it is purely coincidental.
>
> It would be better (IMO) if I would properly detect new events and
send
> them as CTI2.events. This way, you'd get the message the second that
a
> message was left. In addition, events would be sent anytime the
> read/unread count changes--which would change as voicemail messages
are
> heard/read and/or deleted. I should probably also include some flag
in
> the message body indicating whether the event reflects an increase in
> the unread count as this may frequently be what is really cared about.
>
> I had started to add the event logic in a while back but never
finished
> it. I'll get back to work on it.
Support for the above (real-time VM messages) was just added to axc v0.5
(http://limings.net/xap/axc). In
addition, several bug fixes were
addressed--most notably a problem that caused asterisk manager messages
to be delayed and hence the corresponding xAP messages. Also, axc now
accepts parameters that allow control over how it is launched and
initialized. Improvements to config file reading were added (which may
address your earlier problem resolved by creating a new file).
Gregg
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|