[Asterisk-Users] Multiple AGI Issues

[Douglas Garstang]

Hi Freddi

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} )

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?

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.

4. Using select() system calls is a little beyond my abilities...

Doug.

-----Original Message-----
From: Freddi Hansen [mailto:fh at danovation.dk]
Sent: Tuesday, February 14, 2006 4:36 PM
To: asterisk-users at lists.digium.com
Subject: re:[Asterisk-Users] Multiple AGI Issues


>
>
>
>
> To:
> "Asterisk Users Mailing List - Non-Commercial Discussion" 
> <asterisk-users at lists.digium.com>
>
>
> I've got several issues with AGI/FastAGI
>
> 1. When an AGI script sends a command to Asterisk via stdin, why does Asterisk block and not return a result until the command is complete? Specifically, the dial command. If I send a Dial command to Asterisk, I don't get a return result until AFTER the call is HUNG UP. Not when it's ringing, not when the call is connected, but when it's DISCONNECTED. Why is that? How are you supposed to use commands like CHANNEL STATUS if you have to wait until the call is hung up, to check it's status?
>
> 2. Why do AGI scripts stay in memory until a call is complete? Is there any way to have the script terminate when a call is connected? With this scenario, you have a script for every single call in place, and that's really bad from a system resource perspective.
>
> 3. Seems that no scripting language is up to the task of FastAGI. Perl's threads aren't thread-safe with DBI and Python's aren't completely thread safe either. Don't know about Ruby, and I ain't no C programmer. What have people implemented? I also don't like the threading approach, because if something goes wrong with the script/server, you lose the ability to place ANY calls.
>
> Doug
>
>   
Hi,
If you want to have a speedy system that doesn't steal to many system 
resources then you have to use FastAGI. That being said you have to 
program your FastAGI server so it's completely event driven. The way to 
deal with f.ex. the dial command can be to let the FastAGI set a 
dialplan variable and then send the control back to the dialplan which 
then can execute the dial command that your FastAGI did prepare. I 
prefer to use perl for most AGI/FastAGI solutions, the servers are 
started out of inittab so no forking overhead during call handling. I do 
normally build FastAGI servers around 'select' so the process is either 
working or waiting on requests. I know you will say that means that no 
FastAGI request are served while I wait for database responses. The 
workaround is to start more than one copy of your FastAGI server on 
different ports. Create a global variable in your dialplan ,  increment  
on each call  - do a mod(4)  if you have  4 servers  so you can 
interleave the FastAGI requests between the servers.  If you need 
persistent data for you 'after call' process then use you DB system.
Let your FastAGI server write a dialplan status variable so you can 
retry another FastAGI server in case first one fails.
It's not difficult to get 100+ call setups per second with this approach.
b.r.
Freddi

   

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users