Hello users, I had developed several patches that allows to monitor current status of queues/channels in realtime db. For example specifying realtime family "channels" will make asterisk to keep current channel list in realtime database engine. The same would be for queue callers and queue members (already partially available in 1.4).
However I encountered a resistance from Asterisk developers, as they don't wish to accept my patches - because they don't wish to support another interface. As I read in Bug Guidelines, if enough users request this, it should make into asterisk, so I'm asking You to express Your opinion on those features. *** So, realtime status - what's this all about? Basically you get output of "show channels", "show queues", etc directly in Realtime table (Realtime = database engine system for Asterisk). So, Asterisk will automatically update database upon any changes of channels or queues. *** Why would You need that? In beginning I created this in order to deal with large amount of monitoring software. If there's lot of users monitoring status, some kind of cache should be put into place. With current Asterisk interfaces this would mean either inquiring current status or developing a daemon that follows up all events and collects them to keep current picture always ready. I just decided to move this layer to database engine, which deals really good with this stuff. *** Rapid development of monitoring tools What it takes to create custom monitoring tool now? AMI event listener? AJAX page that gets changes from built-in webserver? All this takes lot of time to learn and start using. Adding just few config lines in "extconfig.conf" would allow to automatically populate database with current status - so it's accessible easily from any programming language. All the info is "just there", no need for processing or analyzing. *** Performance / Scalability Inquerying queue status means that there is lock put on queue list, all queues are traversed, information gathered and then returned. If lot of instances of monitoring software need to have this information, it's obvious that this would mean too much locks. So, as database update is thrown whenever some change is happening, it means that no additional locks are created for monitoring purposes. Transaction is sent to database engine, which keeps relatively small tables of current status. Then any number of clients can access data directly without any locking. Even 200 concurrent calls with 10 new calls per minute would still be a tiny load for MySQL. This can also be scaled by moving database to another machine, thus allowing more raw CPU usage for Asterisk. *** Development maintenance Those changes doesn't introduce any new functions in asterisk code. They utilize currently available "Realtime" engine which is meant for storage of configuration data. This just extends use of this engine also for status data, so maintenance of this interface should not take lot of work. *** Current patches If You are interested in using those changes right away, here are some backports for 1.4: Channels: http://ftp.iq-labs.net/realtime_channels/ Queue callers: http://ftp.iq-labs.net/realtime_queue_callers-1.4/ Queue members: work in progress, needs some refactoring and optimization to make that effective. Meetme: planned, no patches yet To use any of those patches, you will need to add backport of store/destroy to 1.4: http://ftp.iq-labs.net/realtime_store_destroy-1.4/ *** Supporting this feature If You find that those features would be good for merging into Asterisk, please write a comment in bugtracker: http://bugs.digium.com/view.php?id=12556 Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
