[OPEN-ILS-DEV] Asterisk scheduling controls

[Joe Atzberger]

On Tue, Dec 15, 2009 at 3:34 PM, Bill Ott <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?

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