Summary:	ASTERISK-11946: [patch] Realtime queue callers
Reporter:	Atis Lezdins (atis)	Labels:
Date Opened:	2008-04-30 06:23:15	Date Closed:	2008-12-09 16:23:37.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_realtime_queue_callers_v1.patch ( 1) asterisk_realtime_queue_callers-1.4.19.patch
Description:	This patch adds new realtime family for queue callers. app_queue will do a realtime store for new caller, and destroy for one left. This allows better monitoring of queue callers from multiple clients at same time, as there is no need for caching of AMI commands, all is kept in Realtime, and multiple clients are handled by database engine. ****** ADDITIONAL INFORMATION ****** To enable realtime queue callers You need to add to extconfig.conf: queue_callers => mysql,asterisk,queue_callers And create corresponding database table: CREATE TABLE queue_callers (  uniqueid VARCHAR(40) PRIMARY KEY ,  queue VARCHAR(128),  channel VARCHAR(128),  priority VARCHAR(11),  callerid_name VARCHAR(80),  callerid_num VARCHAR(40),  accountcode VARCHAR(80),  started INT(10) UNSIGNED,  KEY i_queue_prio_started (queue, priority, started) )
Comments:	By: Atis Lezdins (atis) 2008-04-30 06:26:44 I also added backport for 1.4.19 (if somebody want's to use that right away), as this feature is working on our production for several months already. Note that this backport will also need backport to 1.4 of realtime store/destroy for asterisk and asterisk-addons (backport available at http://ftp.iq-labs.net/realtime_store_destroy-1.4/ ) By: Tilghman Lesher (tilghman) 2008-04-30 10:40:00 I really don't think this is something that we want to use realtime data for.  I see your point about caching, and I think the answer is a native AMI command for querying the channels in a Queue, not to expand what we use Realtime data for. By: Atis Lezdins (atis) 2008-04-30 11:10:18 The problem with AMI is that it needs queue locking, and throwing 100 such requests per second is quite a load for Asterisk. However MySQL deals with this great. My point for this is - to have current state of queues accessible by any application, anytime. For future I have current queue member state and channel state in realtime database (but I haven't cleaned up patches yet). So this way amount of monitoring clients is limited only by database capabilities. The need for this in first place was caching problems with simultaneous requests for channel/queue status and locking problems. For example, if I query channel/queue information once per second, chances that Asterisk will run into deadlock or crash increases. Plus this feature isn't active unless enabled by adding realtime family, so it won't affect users who don't need that. By: vieri (vieri) 2008-05-01 04:38:01 I am currently using a custom AMI script which runs a "show queues" each time it detects an Agent* event and parses the output (active calls, wait time, etc). I don't have too many queues or too many calls so I guess the AMI script won't overload asterisk but still, a database backend would handle this more efficiently. Also, parsing "show queues" isn't that simple because if I wanted to get the caller IDs of all the active callers I guess I would need to grab the caller channels and then run yet another command such as "zap show channel XX" for each channel and parse the output for the caller ID. A native AMI command that queries channels in a queue or all queues and yields easily parseable information would be nice. However, having app_queue store this data directly into a database (thus reducing potential deadlocks by excessive AMI queries) sounds very appealing. Couldn't we just have both? By: Tilghman Lesher (tilghman) 2008-05-01 07:07:25 There are lots of interfaces that we "could" have, but there are a limited number that we are willing to support.  Trying to use a database backend for status support is not an interface that we really want to start supporting, especially when there is a perfectly good interface (AMI) that serves the same need.  You're right that the command does not exist now, but that means that you may serve as a designer for a new command or set of commands and decide what that command should look like and what information the response will contain. This is really a request for "support this new interface I dreamed up", which is NOT appropriate for the bugtracker, anyway.  The fact that it looks like and works off an existing interface is irrelevant -- realtime is designed for configuration data, not for dissemination of status data. If you would like to design the appropriate AMI command for querying queue status, that is fine.  However, if you are not going down that road, this issue will be closed. By: P. Christeas (xrg) 2008-05-01 09:12:22 I humbly vote "for" the feature and ask for more db<->asterisk integration. By: vieri (vieri) 2008-05-01 10:58:30 How would you design the "appropriate AMI command for querying queue status" and avoid potential deadlocks while gathering data in "real-time"? (or do you believe deadlocks are not an issue?) What would trigger the update of this data? The patch proposed by Atis would suggest app_queue -> SQL DB (which in turn could have triggers on table data change running external custom apps/events, etc... and that's something the end user would administer). How would I know when to run the new-to-come queue status command? Could/is there a specific manager event for calls that enter and leave a queue? That would allow my script to run the AMI command as little as possible. But still, I'm wondering if asterisk could handle, say, 100 "show queues" in a couple of seconds in the case of having, say, 50 callers coming into the queue and another 50 going out (I would need to custom-program timers in my script to avoid excessive AMI commands but that in turn would slow everything down on a busy system). So all I would personally require is that the AMI command be "robust" and not lock or exhaust the system and at the same time have specific events for queue entry/exit. Before going into the design of this AMI command do you really think it's the "best way to go"? NB: I dont't care to use realtime for non-config purposes or not but all I'm looking for is a pragmatic solution for busy systems to the problem "who's on queue?". If there's a better place to discuss this then please kindly point me to it. Thanks. EDIT: OK, I found the relevant manager events which are Join and Leave but the user making the AMI connection must have read access to the Call group, not the Agent group. There's a lot more chatter in Call than in Agent which makes it a bit inefficient. By: Tilghman Lesher (tilghman) 2008-05-09 13:56:21 Given the feedback on the -users list, I'm now going to close this out as a rejected feature. By: Tilghman Lesher (tilghman) 2008-12-09 16:23:37.000-0600 Since this has recently come up on the -users list, I am linking several posts on the -users list which are relevant to the decision NOT to include this: http://lists.digium.com/pipermail/asterisk-users/2008-May/211147.html http://lists.digium.com/pipermail/asterisk-users/2008-May/211161.html http://lists.digium.com/pipermail/asterisk-users/2008-May/211163.html http://lists.digium.com/pipermail/asterisk-users/2008-May/211185.html