VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
dougmig33 at yahoo.com
Guest
|
 Posted: Mon Jul 07, 2008 12:21 pm Post subject: [asterisk-users] Building an IVR |
 |
|
So, I need to build a complicated IVR with Asterisk, with a lot of back end hooks. The dial plan itself has a lot of limitations, not the least of which is that the dial plan is ugly, hard to maintain, and full of gotchas like all variables being global etc etc.
I've been involved with Asterisk for a couple of years now and this is a problem I have yet to see a good solution for.
1. I looked at VXML but it has too many integration problems.
2. AGI has overhead.
3. Fast AGI has single point of failure problems (we're using Asterisk 1.2 which bombs out the call when an AGI request fails), and has too many moving parts for what should be something fairly simple.
4. I'm aware of res_perl, but am not a fan of the maintainability of perl.
5. I looked for a valid link to res_python, but couldn't find anything.
6. Adhearsion? Looked at it a few months ago but couldn't work it out. There was too much 'voodoo' going on.
7. I'm not a C programmer, so writing a custom module, is both overkill and not feasible.
Do I have any other options?
Doug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080707/d319106b/attachment.htm |
|
| Back to top |
|
 |
dbackeberg at gmail.com
Guest
|
| Posted: Mon Jul 07, 2008 12:47 pm Post subject: [asterisk-users] Building an IVR |
|
|
On Mon, Jul 7, 2008 at 1:21 PM, Douglas Garstang <dougmig33 at yahoo.com> wrote:
| Quote: | So, I need to build a complicated IVR with Asterisk, with a lot of back end
hooks. The dial plan itself has a lot of limitations, not the least of which
is that the dial plan is ugly, hard to maintain, and full of gotchas like
all variables being global etc etc.
I've been involved with Asterisk for a couple of years now and this is a
problem I have yet to see a good solution for.
|
We're using asterisk-1.4,
with AGI scripts written in Perl.
We find it maintainable, we find the overhead minimal, and we have
back-end hooks, primarily in a MySQL database. The code is
maintainable because it's well-structured, containing subroutines,
comments, and the code does no more than is needed at any given
moment.
We've also modded asterisk code in C, which was also a relatively
straightforward task. I found that variable and function names are
well-chosen and that the code worked in predictable ways.
Perl can be written with or without everything being global variables.
We make the variables we need in most of the plan to be global, and
everything else is a local variable, with limited scope, in a
subroutine. We also built our own Perl module which we call from the
dial plan. This gave us great encapsulation between private data /
only passing the exact data you need to accomplish the task.
The Perl module came in very handy. Dialplans that are not related to
each other are stored in completely separate AGI scripts, and never
need to know anything about each other. They get to use the nifty Perl
module for things that most of our AGI scripts need to do, like read /
update MySQL, transfer a call, dial out, etc.
I would say that a "good solution" can be met dozens of ways,
including studying your dial plan and deciding whether making
everything a global variable was a good idea. How about a main menu
that jumps to three separate dial plans, each of which are actually
maintainable? You can accomplish great things with structured
programming.
With or without asterisk, bad code is bad code. It may be time to have
somebody with fresh eyes look over your dialplan. |
|
| Back to top |
|
|
mcollins at fcnetwork.com
Guest
|
| Posted: Mon Jul 07, 2008 1:26 pm Post subject: [asterisk-users] Building an IVR |
|
|
Hmm...
You may be in one of those positions where there just isn't a great
solution because your environment has so many constraints. You might
want to check out the way freeswitch handles IVRs, dialplan hooks,
FAGI-ish connections, etc. It will still take some work, of course,
because there isn't an out-of-box solution (that I'm aware of) that can
meet all of your requirements without lots of time/money/effort.
-MC
________________________________
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Douglas
Garstang
Sent: Monday, July 07, 2008 10:21 AM
To: asterisk-users at lists.digium.com
Subject: [asterisk-users] Building an IVR
So, I need to build a complicated IVR with Asterisk, with a lot of back
end hooks. The dial plan itself has a lot of limitations, not the least
of which is that the dial plan is ugly, hard to maintain, and full of
gotchas like all variables being global etc etc.
I've been involved with Asterisk for a couple of years now and this is a
problem I have yet to see a good solution for.
1. I looked at VXML but it has too many integration problems.
2. AGI has overhead.
3. Fast AGI has single point of failure problems (we're using Asterisk
1.2 which bombs out the call when an AGI request fails), and has too
many moving parts for what should be something fairly simple.
4. I'm aware of res_perl, but am not a fan of the maintainability of
perl.
5. I looked for a valid link to res_python, but couldn't find anything.
6. Adhearsion? Looked at it a few months ago but couldn't work it out.
There was too much 'voodoo' going on.
7. I'm not a C programmer, so writing a custom module, is both overkill
and not feasible.
Do I have any other options?
Doug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080707/3e188d6f/attachment.htm |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
