[OPEN-ILS-DEV] Asterisk scheduling controls

[Doug Kyle]

Bill Ott wrote:
>
>>
>> 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.
Is a couple couple cron calls overkill compared to a proxy layer?  IMO a 
shutdown of Asterisk is just proper insurance against any untimely 
calls, and I would want a separate Asterisk box/instance for EG calls vs 
my main phone system.  You don't need to unschedule calls if you use a 
temp dir and have a program feed the call files to the spool dir, you 
simply stop that program.  Any left over call files are left in the temp 
dir.

>>
>> 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 started with future-dated call files, but discovered that too many 
call files in the spool dir seems to be a well known Asterisk issue.

>>
>> 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.
We only consider closed dates for pickup calls, and the relevant OU 
(pickup lib) is set as a variable in each call file.  In our case, 
Asterisk itself does not query EG for those as we batch create call 
files from a perl program every morning.  We do have asterisk call a cgi 
script on EG that creates a hold notification after a pickup call, but 
that has never caused any performance issues.

>>
>> 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.
>
>