asterisk users - Jun 2004 - Some (lack of) answers regarding the wakeup call application...

Since I only seem to get questions, and no feedback, from the Wiki page,
I'll ask here.  There seems to be no lack of opinions here...

I have a working wakeup call system on my home * system.  The architecture
is something I'm not perfectly happy with, though.  There are two AGI
scripts, written in Perl, which handle (a) scheduling, confirming,
and cancelling a wakeup call, and (b) the wakeup call itself, with the
option to snooze for 5, 15, or 30 minutes.

The Perl scripts use the Asterisk::AGI module I came across months ago,
but by necessity, can't use the Asterisk/Perl code for creating call files
-- it has a habit of creating them right in the outgoing call queue,
generating a call immediately.  So the Perl code creates call files in
a wakeup queue directory, and a cron job (a shell script) runs every
minute looking for wakeup calls in the queue that need to be handled,
and moves them to the outgoing call queue.

It has occurred to me that the two AGI scripts could be rewritten as real
compiled asterisk applications, but then it always hits me that without
some kind of cron-line built-in scheduler, or changes to the outgoing
call queueing that would allow a call to be scheduled for the future,
there would still be that external cron-driven shell script.  Ugly.

What I'm wondering is this:  Is there enough interest in the new features
I mentioned (either an internal scheduler or scheduled outgoing calls)
that I should work on a C version of the wakeup AGI scripts, or should
my (impending) next rewrite maintain the current architecture?

Anyone with specific questions about using my wakeup app, please email
me directly.

Rob

-- 
Rob Fugina, Systems Guy
robf@geekthing.com -- http://www.geekthing.com
My firewall filters MS Office attachments.

The superior pilot uses his superior talent and superior judgment to avoid
 getting into situations where he needs to use his superior skill.

At 11:27 AM 6/1/2004, you wrote:
Rob

  I would be very interested

>Since I only seem to get questions, and no feedback, from the Wiki page,
>I'll ask here.  There seems to be no lack of opinions here...
>
>I have a working wakeup call system on my home * system.  The architecture
>is something I'm not perfectly happy with, though.  There are two AGI
>scripts, written in Perl, which handle (a) scheduling, confirming,
>and cancelling a wakeup call, and (b) the wakeup call itself, with the
>option to snooze for 5, 15, or 30 minutes.
>
>The Perl scripts use the Asterisk::AGI module I came across months ago,
>but by necessity, can't use the Asterisk/Perl code for creating call
files
>-- it has a habit of creating them right in the outgoing call queue,
>generating a call immediately.  So the Perl code creates call files in
>a wakeup queue directory, and a cron job (a shell script) runs every
>minute looking for wakeup calls in the queue that need to be handled,
>and moves them to the outgoing call queue.
>
>It has occurred to me that the two AGI scripts could be rewritten as real
>compiled asterisk applications, but then it always hits me that without
>some kind of cron-line built-in scheduler, or changes to the outgoing
>call queueing that would allow a call to be scheduled for the future,
>there would still be that external cron-driven shell script.  Ugly.
>
>What I'm wondering is this:  Is there enough interest in the new
features
>I mentioned (either an internal scheduler or scheduled outgoing calls)
>that I should work on a C version of the wakeup AGI scripts, or should
>my (impending) next rewrite maintain the current architecture?
>
>Anyone with specific questions about using my wakeup app, please email
>me directly.
>
>Rob
>
>--
>Rob Fugina, Systems Guy
>robf@geekthing.com -- http://www.geekthing.com
>My firewall filters MS Office attachments.
>
>The superior pilot uses his superior talent and superior judgment to avoid
>  getting into situations where he needs to use his superior skill.
>_______________________________________________
>Asterisk-Users mailing list
>Asterisk-Users@lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-users
>To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

Rob Fugina wrote:
>It has occurred to me that the two AGI scripts could be rewritten as real
>compiled asterisk applications, but then it always hits me that without
>some kind of cron-line built-in scheduler, or changes to the outgoing
>call queueing that would allow a call to be scheduled for the future,
>there would still be that external cron-driven shell script.  Ugly.
>  
>
Actually, there's no need for anything like that. Set the file's
modification time to the value you require, and watch asterisk do all
the dirty work for you.

Apollon Koutlides

On Tue, 2004-06-01 at 10:27, Rob Fugina wrote:
> It has occurred to me that the two AGI scripts could be rewritten as real
> compiled asterisk applications, but then it always hits me that without
> some kind of cron-line built-in scheduler, or changes to the outgoing
> call queueing that would allow a call to be scheduled for the future,
> there would still be that external cron-driven shell script.  Ugly.
> 
> What I'm wondering is this:  Is there enough interest in the new
features
> I mentioned (either an internal scheduler or scheduled outgoing calls)
> that I should work on a C version of the wakeup AGI scripts, or should
> my (impending) next rewrite maintain the current architecture?
A question, I don't like the idea of a cron-scheduler in asterisk but I
don't have a really good reason not to like it. I do however think that
by adding some form of date parser and a new configuration option to the
sample.call file wouldn't be too bad of an idea. I am only slightly
concerned that the reading of the file regularly might cause delays in
asterisk.

Consider this, you add the time-of-call config to sample.call, then you
have a few 100 calls queued, what is the time to open, read, and parse
the date string before deciding to act or not. Is this behavior going to
be likely to cause calls to go out late. What is an acceptable amount
late for a call to be processed.

Otherwise I think the idea of placing the time in the file and letting
it poll and then fire it off is a good idea. 
-- 
Steven Critchfield  <critch@basesys.com>

Rob Fugina [robf@geekthing.com] wrote:
> So the Perl code creates call files in
> a wakeup queue directory, and a cron job (a shell script) runs every
> minute looking for wakeup calls in the queue that need to be handled,
> and moves them to the outgoing call queue.
> 
You may want to consider using "at" instead of "cron" for
the scheduling
and cancelling of alarm call requests.  It'll be less ugly than checking
for new alarm call jobs every minute etc.  I'm not saying it'll be
pretty - just less ugly. :-)

I'd be interested in seeing your code, and perhaps I can help.  I was
going to write an alarm call application anyway.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin@cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/

I installed your wakeup agi script and it works well.  There are some 
typos on the wiki page--the printf format string seem to have been 
corrupted.  Also, I need a Linux tool to splice a series of gsm audio 
clips together in order to use one 'get_data' instead of multiple 
'stream_file' commands.

Mike

Rob Fugina wrote:
> Since I only seem to get questions, and no feedback, from the Wiki page,
> I'll ask here.  There seems to be no lack of opinions here...
> 
> I have a working wakeup call system on my home * system.  The architecture
> is something I'm not perfectly happy with, though.  There are two AGI
> scripts, written in Perl, which handle (a) scheduling, confirming,
> and cancelling a wakeup call, and (b) the wakeup call itself, with the
> option to snooze for 5, 15, or 30 minutes.
> 
> The Perl scripts use the Asterisk::AGI module I came across months ago,
> but by necessity, can't use the Asterisk/Perl code for creating call
files
> -- it has a habit of creating them right in the outgoing call queue,
> generating a call immediately.  So the Perl code creates call files in
> a wakeup queue directory, and a cron job (a shell script) runs every
> minute looking for wakeup calls in the queue that need to be handled,
> and moves them to the outgoing call queue.
> 
> It has occurred to me that the two AGI scripts could be rewritten as real
> compiled asterisk applications, but then it always hits me that without
> some kind of cron-line built-in scheduler, or changes to the outgoing
> call queueing that would allow a call to be scheduled for the future,
> there would still be that external cron-driven shell script.  Ugly.
> 
> What I'm wondering is this:  Is there enough interest in the new
features
> I mentioned (either an internal scheduler or scheduled outgoing calls)
> that I should work on a C version of the wakeup AGI scripts, or should
> my (impending) next rewrite maintain the current architecture?
> 
> Anyone with specific questions about using my wakeup app, please email
> me directly.
> 
> Rob
> 
-- 
Michael Welter
Introspect Telephony Corp.
Denver, Colorado
+1 303 674 2575
mike@introspect.com
www.introspect.com