[OPEN-ILS-DEV] Asterisk scheduling controls

[Bill Ott]

>
> On Tue, Dec 15, 2009 at 3:34 PM, Bill Ott <bott at grpl.org 
> <mailto:bott at grpl.org>> wrote:
>
>     Josh Stompro said the following on 12/15/2009 03:06 PM:
>>     Joe Atzberger wrote:
>>>     In the course of integrating Asterisk telephony with Evergreen's
>>>     action/trigger notice structure, we have encountered a problem
>>>     that you may have already come across, or possibly even solved. 
>>>     The question is basically how to schedule call times (on the
>>>     asterisk side), i.e. start at 9AM, stop at 9PM.
>>>     We are generating callfiles that are queued by moving them into
>>>     the Asterisk spool directory.  We can tell Asterisk not to call
>>>     before a certain time by setting the file's date modified time
>>>     in the future.  So we have a mechanism for the "begin" time. 
>>>     What we don't have is a mechanism to tell asterisk *not* to call
>>>     after a given "end" time.  Anything that is in the dialplan
>>>     logic itself does not appear suitable because that still
>>>     processes the callfile and either succeeds or fails.  What we
>>>     want is to *not* process the callfile, deferring it until the
>>>     next start time.
>>>     The reason there has to be a cutoff is that EG might spool up
>>>     several thousand calls to fire at the "begin" time, and it is
>>>     conceivable that not all calls would be completed by the
>>>     intended end.
>>>     Things we've ruled out:
>>>
>>>         * just turning off/on asterisk -- can't do that since local
>>>           voicemail, incoming calls and desktop phones might depend on
>>>           asterisk
>>>         * trying to adjust callfile date modified time inside
>>>     dialplan --
>>>           doesn't work, because the file is still processed, i.e.
>>>     moved to
>>>           the "done" dir at the end
>>>
>>>     So are there any solutions you guys have encountered?  This
>>>     problem is very similar to print queue management on unix, so
>>>     there may be products/packages in that problem-space that would
>>>     work for us.
>>>     --Joe
>>     I'm not at all familiar with the call files, so this is probably
>>     not an option, but would it be possible to move all spooled calls
>>     out of the call dir at a certain time, except the ones that are
>>     currently in use, and move them back in the next start time... Or
>>     modify the  date modified time of all the files not currently in
>>     use at 9pm every night to be for 9am the next morning. That would
>>     cause the system to skip them all until the next morning, right?
>>
>>     As well as set stop and start times, would it be possible to
>>     optionally not have the system call a customer while their home
>>     library is not open.  That way there would always be staff
>>     available at a customers library if they had questions and wanted
>>     to call back.  Assuming that EG takes into account holidays, it
>>     would also keep calls from being placed on holidays also.  This
>>     wouldn't work for every location though, so it should probably be
>>     a per OU setting. 
>     This is precisely what we do.  We call
>     'open-ils.actor.org_unit.closed.retrieve.all' and*
>     *'open-ils.actor.org_unit.hours_of_operation.retrieve' to see if
>     the library is open on a given day before we queue up the call.
>
>     We use an external notification server to place calls for both
>     overdue and hold notifications.  see:
>     http://svn.open-ils.org/trac/ILS-Contrib/browser/grpl/trunk/patron_notifications
>
>     Back to the original question which Doug already commented on. 
>     When we first started using this method we tried dumping all of
>     our call files into the spool directory at once.  This worked fine
>     in testing with a handful of calls, but with hundreds of files,
>     Asterisk choked on them and started locking up outgoing lines.
>
>
> Thanks for the responses.  There are some viable options in here.  Our 
> problem isn't knowing when to schedule the call (i.e. "open hours"), 
> it's knowing how to un/reschedule it when we get to closing time. 
>  Options seem to be:
>
>    1. shutdown asterisk (instance)
>   2.
>       maybe unload just the spool module part of asterisk (pbx_spool iirc)
>    3. mv callfiles outside spool directory, mv back at "open" time
>    4. update date modified to next "open" time
>    5. never queue more than one round of calls per channel, so there
>       *shouldn't* be much backlog
>
> The first is dead certain, but also overkill.  If we wanted to go that 
> route, I would push for a proxy layer that EG can treat like one 
> Asterisk instance, rather than needing a bunch of different instance 
> configs.
>
> The latter (#5) doesn't work w/ future-dated callfiles, since they 
> *should* accumulate in spool.  But maybe accumulation in spool is to 
> be avoided, as Bill suggests.  That would seem counter to the entire 
> purpose of a spool, but it wouldn't really surprise me either.
>
> I intend to avoid requiring that asterisk query back to the EG server 
> to figure out when an OU is open/closed.  For one thing, Asterisk has 
> no idea what OU is relevant.  It's hard enough for EG to know, and the 
> rules for that could be arbitrarily complex:
>
>     * If a user has 3 overdues from 3 branches, and one is closed,
>       make the call?
>     * If all are open but the user's home branch is closed, make the
>       call?
>     * If all are closed but the user's home branch is open, call?
>
> It is a little more obvious in the case of hold pickup notices since 
> the pickup branch is the only one that really matters, but there are 
> still good performance reasons to avoid this requerying altogether. 
>  When we send the file, we can include data about TTL, but since we 
> have already made use of the date modified, we would need to hold the 
> data in an external DB or have the mediator read through the content 
> of the file on the asterisk side to extract the data.  I also want to 
> avoid that, if possible.
>
> The most worrying report is that Asterisk choked on a spool containing 
> a few hundred files.  Bill, can you say what version of asterisk it 
> was and whether you were using SIP or traditional lines?


We're running 1.4 with multiple 4-port ZapTel cards and analog lines 
from our PBX.  No SIP in our case.

Calling out on 7 lines, today we initiated 473 and completed 405 calls 
in about 4.25 hours.  So, we can easily feed the spool and not have to 
worry about running late.  But just in case, we shut it down 
(programatically) at 6:00PM local time.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091215/df60ef08/attachment-0001.htm