Hy my friend,
before setting up Agi server, you should choose your language programming,
you can use agi commnd on many manguages like C,JAVA,PHP,Perl,Rubby & ...
I prefer PHP for small programs and JAVA for huge ones,
I used php and found phpagi-fastagi. However, input/output from stdin and stdout are not passed. Looking at phpagi-fastagi, shouldn't the socket be passed to the NEW AGI (3rd parameter in the constructor)?? But where is the socket defined in phpagi-fastagi??
After having looked at various FastAGI offerings , I had decided I really did not care for any of them.
Being as I can just as easily create daemons in C++ or PHP, I had a choice to make.
For ease of development I elected to create a generic PHP daemon that would
allow me to dynamically load PHP scripts via the dial plan.
This makes development really easy as I can simply edit,save and dial, vs. any kind of
compiling or restarting after an edit to a particular PHP script.
When a script is called it is passed a reference to a PHP object containing all the
information passed by asterisk as well as interfaces to both AGI and AMI resources, and
soon a MySql reference as well so a script has everything it needs in a nice thin interface.
Excellent. Got my fastagi server running after fixing one bug in class.daemon.inc
I have a question regarding calling phpagi inside a Fastagi script.
I have 2 asterisk servers. Server A handles incoming call, server B handles some other phone lines.
my senerio is
1. caller calls into server A
2. server A invokes a fastagi script on serevr B, passing some info to it
3. server B will then make a phone call using the phone lines attached to itself (server B)
4. server B will pass the result back to server A
5. server A will then continue with the dial plan
Can anyone tell me if I can use phpagi inside a Fastagi script? It seems to hang with the "New" instance.
Firstly , if there was an error that you corrected , please let me know
so that I can fix it in the main code for everyone.
As to contacting the instance of asterisk on server B,
from the FastAGI plugin ,I guess I would for a down and dirty fix, issue
a an AMI logout command.
Then I would adjust the $oDaemon member variables $szAMIusername,$szAMIsecret,
$iAMIserverPort, and $iAMIserverHost as needed and call $oDaemon->AMIlogin()
to connect to server B's AMI interface to place the call.
The FastAGI is a connection between server A and you that was created when the fastAGI call was made.
The AMI connection is a separate connection between you and server A that talks to a different process.
Unless you are actually going to use AMI resources on server A , your free to disconnect and connect
o AMI on server B
If you really want to from your FastAGI context speak to AMI on both servers , you can probably extract
the logic for it from the code and have your FastAGI connection from A, and two AMI connections.
The Agispeedy is robust implemention of AGI in asterisk. Agispeedy is inconceivable faster than AGI. The result of test shows that by using Agispeedy in asterisk, the performance of system would be improved more than 10 times comparing with AGI.
2011-5-9 Support Asterisk 1.8.X AGI args syntax not support 1.4.X
implemention of AGI(FastAGI) over TCP Sockets
Work in Stabilize Prefork Mode and Written by Pure Perl.
Easy to Maintain, unlike FastAGI(Dynamic Load AGI no need restart Agispeedy services)
Providing possibility of running AGI on a remote server(Inheriting the FastAGI)
Fast Database Connect(system can hook database connection in child process)
Actually if you want truly speedy transactions, Web Sockets and AMI are an excellent combination, and not just in browsers either.
In a browser application a status change like perhaps pressing a hold button on a hard phone is reflected so fast that a web page indicator and the red light on the phone appear to come on at the same instant.
This is largely because WebSockets are event driven and totally do away with polling.
When a web socket application is idle , it consume zero bandwidth.
Polling systems have to keep making requests , even if there is no data.
Message overhead is amazing too. When one sends HTTP flavored requests , there
could easily be hundreds or even thousands of bytes transferred beyond the the message itself.
With web sockets , the worst the message overhead gets is about 15 bytes.
Less bandwidth. less CPU usage, less memory usage... etc. etc