|
|
This project website is in "archive mode" and is no longer updated. For more recent information on the VICIdial project, go to VICIdial.org
This set of programs was originally created to reduce the risk of deadlocks that occur when
the manager interface connection from a remote machine to the Asterisk server
becomes severed or backlogged in some way resulting in a buffer-overflow of the
manager interface on the Asterisk box and a deadlock of the Asterisk PBX. That's why we needed to find a way to still issue
manager Actions but not have to maintain a connection with the Asterisk Manager
interface. The unintended effect of using this Queue system also ended up being that the actions were executed faster and with fewer drops than when they were executed directly from a client machine in a high-volume environment. Here is a rundown of how the ACQS works:
There is a simple database table where the action information with unique IDs is
stored and where each action's information is updated by the listener. The table
I use is called vicidial_manager and is detailed in the MySQL_AST_CREATE_tables.sql file in
the distribution.
1. First, the GUI client application inserts a record into the table as a NEW
action and includes a unique callerID for REDIRECT and ORIGINATE commands(the
callerID field is how the listener will update the record in the DB)
INSERT INTO vicidial_manager values('','','2004-01-30
17:22:53','NEW','N','10.0.0.12','','Originate','DL40130172253cc100','Channel:
local/8600011@demo','Context: default','Exten: 917275551212','Priority:
1','Callerid: DL40130172253cc160','','','','','');
2. Second, there is a constantly running application on the Asterisk box that
selects queues from the database to be processed, and launches a new child
script to send the action to the database, then marks the action as SENT.
3. Third, each child process logs into the manager interface and sends the
action immediately, then stays open for 10 seconds to not cause any problems,
clears it's buffer and then logs out and exits.
4. Fourth, the listener app is constantly connected on the Asterisk box to the
manager interface and parses all output from the manager interface. Every time a
"Newstate Ringing" event is seen an update statement is sent to the DB based
upon the callerid of the call filling in the channel that the call is on and the
uniqueID of the call and sets the record to "UPDATED"
5. Fifth, the listener also listens for "Hangup" events and sends an update to
the DB with a "DEAD" status keyed by the call's uniqueID.
The above process is executed extremely fast and actually has suprisingly little
effect on the load of the Asterisk box. Because each action is sent through it's
own child process there is no risk of the Asterisk system or the client deadlocking because of a single
bad action thread.
NOTES:
This started out as a desperate quick fix that evolved into a system that has
been up and running reliably on many Asterisk servers. Since we
implemented ACQS we haven't had a single deadlock on any of these servers.
In more recent versions of Asterisk, the manager connection reliability issues have been corrected, but the volume of manager output data has increased sharply. We have modified the ACQS to optimize it's connections to not be flooded by unused data that comes with full output manager connections.
If anyone has suggestions/praises/criticisms we would love to hear them.
To use, install the scripts listed in the ACQS.txt file and set the $QUEUE_ACTION_enabled
variable in the client's libs/AST_VICI_conf.pl configuration file to 1
All astGUIclient software elements are distributed freely through the AGPLv2 with no warranty.
|
| |
|
