astGUIclient LOGO Asterisk Central Queue System(ACQS) -
A central queue for Asterisk Manager Interface actions
astGUIclient LOGO
DOWNLOAD
Sourceforge SUMMARY
astGUIclient
ACQS
VICIDIAL
SCREENSHOTS
CONTACT / HELP
FORUM
REQUIREMENTS
SCRATCH_INSTALL
FAQ
CONSULTANTS
AND SERVICES
CONTRIBUTORS
WEB ADMIN DEMO
CODE UPDATES

Project Sponsor
Binfone Telecom

To donate to this project:
Support This Project
click here
SourceForge.net Logo
Get Firefox!
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 GPL with no warranty.