Asterisk AGI(Asterisk Gateway Interface) 내용 정리.
Process Based AGI
Process-based AGI is the simplest variant of AGI. The script is invoked using the AGI() application from the Asterisk dialplan. The application to run is specified as the first argument to AGI(). Unless a full path is specified, the application is expected to exist in the /var/lib/asterisk/agi-bin directory. Arguments to be passed to the given AGI application can be specified as additional arguments to the AGI() application in the Asterisk dialplan.
- Pros of process-based AGI
- It is the simplest form of AGI to implement.
- Cons of process-based AGI
- It is the least efficient form of AGI with regard to resource consumption.
EAGI(Enhanced AGI) is a slight variant on AGI(). It is invoked in the Asterisk dialplan as EAGI(). The difference is that in addtion to the communication on stdin and stdout, Asterisk also provides a unidirectional stream of audio coming from the channel on file descriptor 3.
- Pros of Enhanced AGI
- It has the simplicity of process-based AGI, with the addition of a simple read-only stream of the channel's audio. This is the only variant that offers this feature.
- Cons of Enhanced AGI
- Since a new process must be spawned to run your application for every call, it has the same efficiency concern as regular, process-based AGI.
It's dead. Should not use this one.
FastAGI is the term used for AGI call control over a TCP connection. With process-based AGI, an instance of an AGI application is executed on the system for every call, and communication with that application is done over stdin and stdout. With FastAGI, a TCP connection is made to a FastAGI server. Call control is done using the same AGI protocol, but the communication is over the TCP conection and does not require a new process to be started for every call.
- Pros of FastAGI
- It's more efficient than process-based AGI. Instead of spawning a process per call, a FastAGI server can handle many calls. DNS can be used to a achieve high availability and load balancing among FastAGI servers to further enhance scalability.
- Cons of FstAGI
- It is more complex to implement a FastAGI server than to implement a process based AGI application. However, implementing a TCP server has been done countless times before, so there are many examples available for virtually any programming language.
Async AGI - AMI controlled AGI
The purpose of async AGI is to allow an application that uses the Asterisk Manager Interface(AMI) to asynchronously queue up AGI commands to be executed on a channel. This can be especially useful if the user already making extensive use of the AMI and would like to take advantage of the same application to handle call control, as opposed to writing a detailed Asterisk dialplan or developing a separate FastAGI server.
- Pros of async AGI
- An existing AMI application can be used to contorol calls using AGI commands.
- Cons of async AGI
- It is the most complex way to implement AGI.
When the user uses async AGI, Asterisk will send out a manager event called AsyncAGI to initiate the async AGI session. This event will allow applications listening to manager event to take over control of the call via the AGI manager action.
Commands and Responses
Once an AGI session has been set up Asterisk begins performing call processing in response to commands sent from the AGI application. As soon as an AGI command has been issued to Asterisk, no further commands will be processed on that channel until the current command has been completed. When it finishes processing a command, Asterisk will respond with the result.
Whn the AGI diaplan application is executed, a manager event called AsyncAGI will be sent out with all the AGI environment variables. After this, AGI manager actions can start to take place via AMI.