[Asterisk-Users] Multiple AGI Issues

[Freddi Hansen]

>
> Thanks for the reply. Neat ideas there, but a couple of issues.
>
> 1. Don't want to have to jump around between the FastAGI and the dial plan. Our plan is to have NO customer data in the dialplan, as all data will be contained within MySQL. We don't want to have to make _any_ edits to the dial plan when a new customer is added. It's a provisioning nightmare to have to do this. It also may not be a Dial() command that gets excuted for a given number dialled. It might be Meetme(), Queue() or something else. Jumping back into the dialplan and then executing the right command would be hard to maintain. It'd be helpful if Asterisk accepted something like the following, which would make it easier, but it doesn't...
>
> exten => _X.,1,AGI(//localhost/script.py)
> exten => _X.,2,${APP}( ${ARGS} )
>   
We have no customer data in the dialplan,  everything is done through mysql.
There are 2 basic ways (at least) to use FastAGI when you  dont want to 
have a multithreaded  FastAGI server. 
1. Create some 'helper' contexts in the dialplan to handle 
applications/actions that may take some time (like meetme,dial a.s.o.). 
Let the FastAGI server set some channel variables that you may need 
(like Destination number, which CallerID to use aso) and  ofcourse the 
context before returning to the dialplan.
2.Use a modified version of  Asterisk.pm which is build around select 
and nonblocking i/o that uses event driven callbacks into your 
application code.(yes threadsafe, it sleeps on a select call until 
events then create the callback.  Since your not familiar with select i 
would recommend using method 1.             
 

> What about findme/followme functionality? Are we going to have to jump backwards and forwards between the agi and the dialplan each time (all the while maintaining the last number tried in the agi) a new number is tried? We could return ALL the numbers to try at once from the AGI I guess, kinda like ${NUM1}, ${NUM2}, ${NUM3} etc. Oh YUCK!
>
> 2. How did you get around the fact that it's quite clearly documented that the perl DBI is _not_ thread safe?
>   
You can easily use a perl distro compiled without multithread enabled 
eventhough it shouldn't be needed. Again read up on perl IO::select.  
You sleep waiting for event input, execute the job  and then sleep 
again. No multitread needed.  You  may issue sql request that takes 20 
or 50 msec and nothing else is going on within  a single server during 
that time  so no re-entrance into unsafe DBI code.  It also means  other 
calls are not being served from that server during this period that why 
I pointed you to use the server interleaving.
> 3. I don't have a high enough confidence in the stability of either perl or python threading, to allow the FastAGI server to potentially receive several dozen calls, and therefore several threads each. If the FastAGI server crashes, you lost the ability to place _any_ calls.
>
>   
As described above: no threading needed within the server. We have AGI 
servers that processes 10K+ calls per day per server ( some of the 
servers has 15K perl lines ) they never crash but they are started out 
of /etc/inittab anyway (just in case)
> 4. Using select() system calls is a little beyond my abilities...
>
> Doug.
I hope to get some time to do a cleanup on my framework for solution 2 
above, it might benefit some other people that like to use agi-perl
b.r.
Freddi