Lee Allen
2004-Aug-19 16:42 UTC
[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. -Lee Allen
Jay Milk
2004-Aug-19 19:14 UTC
[Asterisk-Users] Request for help designing an unusual * application
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.
Adam Goryachev
2004-Aug-19 20:00 UTC
[Asterisk-Users] Request for help designing an unusual * application
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
Rich Adamson
2004-Aug-20 04:59 UTC
[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 startsTechnically, 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
Lee Allen
2004-Aug-20 05:58 UTC
[Asterisk-Users] Request for help designing an unusual * application
> 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