asterisk users - Aug 2004 - Request for help designing an unusual * application

I have been reading asterisk doc's for the past couple weeks, and
monitoring this list.  I have to implement an unusual (I think)
application of asterisk.  I have the beginnings of a plan, and I would
like to throw it up here for comments.

The application:
An after-hours emergency support "hotline" for our technology company.

We have 5 different support people that take turns on 24-hour call (at
any time, one support person is "on call").  We may have 3 or more
contact numbers for each person, eg:
- office phone
- cell phone
- home phone

The support people, and their contact numbers, would ideally be stored
in a database.

When a customer calls in, they get a canned greeting, and then they
leave a message.  Asterisk records it.

Asterisk then tries to reach the current "on call" person.  It starts
dialing the person's various contact numbers, one at a time, and then
plays the message left by the customer.  If it hears a DTMF '#' it knows
it has successfully given the message to a human, and it quits.
Otherwise it continues calling the next contact on the list.

Okay so far?

I think the basic extension stuff can get me the first part (answer &
record the incoming call):
- answer the call
- play the canned greeting
- wait for the caller to talk and then hang up
- record the conversation to a file
- invoke my script

Okay, now my script...

It creates an outoing call in /var/spool/asterisk/outgoing, pulling
information from a database (assuming I learn some perl and mysql, or
something!)
THAT file (outgoing call queue) would have to...
- call the given number
- if it gets an answer, play the recorded message
- then if it gets a # key just quit
- otherwise (busy, no answer, no # key) again invoke the (same) script,
passing an incrementing value so the script knows to try the NEXT
contact number (until it exhausts all its contact numbers, or someone
responds with the magic '#' key)

Does this all sound reasonable?

Do-able?

Is there a much easier way to accomplish it?

Thanks for any help.

-Lee Allen

Doesn't sound too unreasonable or unusual -- my previous PBX had message
delivery.  In the sense of usability, I would probably move the prompts
around a little -- i.e. dial number, play a short prompt on answer, wait
for #, THEN play the customer message.  Might also give them opportunity
to rewind/replay or call back based on caller-id of the customer.

If you need this right away, one option might be to simply set up a
voicemail-box for after-hour requests, and then send a notification with
attached message to a mailing list, which in turn the tech's receive.
The could receive these messages on a PDA or similar and listen to the
message at their own convenience.
> -----Original Message-----
> From: Lee Allen [mailto:lee@leadtec.com] 
> Sent: Thursday, August 19, 2004 6:43 PM
> To: asterisk-users@lists.digium.com
> Subject: [Asterisk-Users] Request for help designing an 
> unusual * application
> 
> 
> I have been reading asterisk doc's for the past couple weeks, 
> and monitoring this list.  I have to implement an unusual (I 
> think) application of asterisk.  I have the beginnings of a 
> plan, and I would like to throw it up here for comments.
> 
> The application:
> An after-hours emergency support "hotline" for our technology
company.
> 
> We have 5 different support people that take turns on 24-hour 
> call (at any time, one support person is "on call").  We may 
> have 3 or more contact numbers for each person, eg:
> - office phone
> - cell phone
> - home phone
> 
> The support people, and their contact numbers, would ideally 
> be stored in a database.
> 
> When a customer calls in, they get a canned greeting, and 
> then they leave a message.  Asterisk records it.
> 
> Asterisk then tries to reach the current "on call" person.  
> It starts dialing the person's various contact numbers, one 
> at a time, and then plays the message left by the customer.  
> If it hears a DTMF '#' it knows it has successfully given the 
> message to a human, and it quits. Otherwise it continues 
> calling the next contact on the list.
> 
> Okay so far?
> 
> I think the basic extension stuff can get me the first part 
> (answer & record the incoming call):
> - answer the call
> - play the canned greeting
> - wait for the caller to talk and then hang up
> - record the conversation to a file
> - invoke my script
> 
> Okay, now my script...
> 
> It creates an outoing call in /var/spool/asterisk/outgoing, 
> pulling information from a database (assuming I learn some 
> perl and mysql, or
> something!)
> THAT file (outgoing call queue) would have to...
> - call the given number
> - if it gets an answer, play the recorded message
> - then if it gets a # key just quit
> - otherwise (busy, no answer, no # key) again invoke the 
> (same) script, passing an incrementing value so the script 
> knows to try the NEXT contact number (until it exhausts all 
> its contact numbers, or someone responds with the magic '#' key)
> 
> Does this all sound reasonable?
> 
> Do-able?
> 
> Is there a much easier way to accomplish it?
> 
> Thanks for any help.

On Fri, 2004-08-20 at 09:42, Lee Allen wrote:
> Okay, now my script...
> 
> It creates an outoing call in /var/spool/asterisk/outgoing, pulling
> information from a database (assuming I learn some perl and mysql, or
> something!)
> THAT file (outgoing call queue) would have to...
> - call the given number
> - if it gets an answer, play the recorded message
> - then if it gets a # key just quit
> - otherwise (busy, no answer, no # key) again invoke the (same) script,
> passing an incrementing value so the script knows to try the NEXT
> contact number (until it exhausts all its contact numbers, or someone
> responds with the magic '#' key)
> 
> Does this all sound reasonable?
Simple...
> Do-able?
Easy... :)
> Is there a much easier way to accomplish it?
Don't create it as an asterisk app, create it as an AGI...

The .call file makes asterisk place a call to your AGI script, then your
AGI script makes whatever calls it needs to, playing various prompts,
receiving DTMF answers, and so on, until it has successfully delivered
the message, or given up.... It could even, as a last resort, send a few
SMS messages, and then email messages before totally giving up.

Regards,
Adam

> I have been reading asterisk doc's for the past couple weeks, and
> monitoring this list.  I have to implement an unusual (I think)
> application of asterisk.  I have the beginnings of a plan, and I would
> like to throw it up here for comments.
> 
> The application:
> An after-hours emergency support "hotline" for our technology
company.
> 
> We have 5 different support people that take turns on 24-hour call (at
> any time, one support person is "on call").  We may have 3 or
more
> contact numbers for each person, eg:
> - office phone
> - cell phone
> - home phone
> 
> The support people, and their contact numbers, would ideally be stored
> in a database.
> 
> When a customer calls in, they get a canned greeting, and then they
> leave a message.  Asterisk records it.
> 
> Asterisk then tries to reach the current "on call" person.  It
starts
Technically, all of that's very possible.

Having been through similar on-call arrangements in a previous life,
you might want to consider a slightly different management approach.

Whoever is the primary on-call person, allow that person to call into
asterisk and enter their on-call number. Store it, and use it for
delivery of the calls. Same for a secondary (or backup) on call person.

The management problem with your approach essentially is one that 
says the 'system' will dictate the calling numbers. In practical cases,
if the on-call person knowingly is at a location where cell phones (etc)
don't work, the system breaks down. Whereas, if you allow the on-call
person to program a "can-be-reached-at" variable, the on-call
person has the freedom to move around and it becomes that person's
responsibility to provide the contact number. Accountability is
shifted to the on-call person, which then avoids the finger pointing
that happens when the 'system' can't properly dispatch the call.
Same technical requirements, slightly different way to handle the
called numbers.

Using an approach similar to the above, its trivial to build an
escalation process into the call delivery mechanism. (E.g, if the
primary on-call person doesn't respond within xx minutes, then
dispatch the secondary. If that person doesn't respond, dispatch
same message to a manager, etc, etc.)

Typical problems go something like:
 - was in church/mass, turned my cell phone off
 - guess its  marginal coverage at my girlfriend's house
 - I was at xyz's house and didn't receive the call
 - etc

Rich

> Whoever is the primary on-call person, allow that person to 
> call into asterisk and enter their on-call number. Store it, 
> and use it for delivery of the calls. Same for a secondary 
> (or backup) on call person.
Yes, that makes a lot of sense.  I am replacing a (human-staffed)
answering service, and they were able to do that with the service, so I
should let them do it with *.

Thanks!

-Lee