Re: [asterisk-users] Realtime status feature - user feedback needed
Just FYI, I wrote an application that tracks the status of SIP or IAX2 extensions by listening to the AMI. It was for use by callshops but would probably require minimal change to work for you. It's currently part of the ASTPP source code. Darren Wiebe [EMAIL PROTECTED] Atis Lezdins wrote: On Thu, May 8, 2008 at 3:49 AM, Ex Vito [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:23 AM, Benoit Plessis [EMAIL PROTECTED] wrote: Tilghman Lesher a écrit : Your question leads to this question: why don't you create a proxy application that listens on AMI and populates a database outside of Asterisk, then do all your queries to that database? That would provide exactly the same functionality, but it would not require a single change to the Asterisk codebase. You could even contribute that application back as something in the contrib/scripts subdirectory. True, that was one of initial options, however I prefer to NOT have yet another layer. I will consider this as an option where appropriate. However this looks quite awkward to me, somehow it reminds me tailing queue_log or CDR and putting result into MySQL database.. just one level more that way. For now, I see only one point against this - having status cleared upon module load/unload makes it easier to follow restarts/module loads. I second that, If there is already a way to do things, why adding another one, especialy if it's for caching reasons. While we cannot say that asterisk fall into the KISS rule, it's not a reason to let it grow. Agreed. There should be ONE to do it, it should be SIMPLE and as RELIABLE as possible, without interfereing (bad spelling?) with asterisk's operations: the proxy into AMI looks like the way to acheive the required funcionality... After all, that's exactly the purpose of AMI ! Let's keep the codebase as small as possible, let's make asterisk as solid and reliable as possible. Let's not reinvent wheels! Ok, so we're exactly at the point. Yes, I agree that it would act nearly the same way as AMI actions, however there's one great advantage - It would be really easy to set this up for user. AMI proxy would take more effort, need configuration, etc. Then there should be much more development support for proxy than for code within asterisk (if you have noticed, there's no new code, just reusing existing functionality) I think that there should be several ways how to do something, not just one. Having realtime status won't mean that much changes, for now I can see only 4 families for this - queue_members (already existing), queue_callers, channels and meetme. Really nothing more to give full overview of Asterisk Status. Regards, Atis ___ -- 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
[asterisk-users] Realtime status feature - user feedback needed
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
Re: [asterisk-users] Realtime status feature - user feedback needed
Atis Lezdins schrieb: I had developed several patches that allows to monitor current status of queues/channels in realtime db. [...] +1 as long as the user can choose whether they want realtime status data in the database. *** 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 Not sure if the bugtracker is the right place to write me too for a feature request type of bug. Grüße, Philipp Kempgen -- Asterisk-Tag.org 2008, May 26th/27th - http://www.asterisk-tag.org amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 ___ -- 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
Re: [asterisk-users] Realtime status feature - user feedback needed
On Wednesday 07 May 2008 16:11:05 Atis Lezdins wrote: 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. That's not quite correct, either. First of all, the correct forum for this is the -dev list, where we discuss development issues. Second, we gave you an alternative way to do this. You could do this with AMI, with the addition of a single query to access current state, then monitor status continuously for updates. And third, it doesn't make a difference how many users request a particular interface -- the development team has to maintain it afterwards, and if you're proposing a new interface, you need to convince the development team that it's worth the extra hassle -- not the users. So we're not opposed to the concept; we are opposed to the particular interface that you chose to use. Modify it, and it will make its way back into Asterisk. Stubbornly stamping your foot and insisting that you have the right way, and the status quo will remain. *** 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 Please don't. We've already discussed this to enough detail, and if you choose to modify your code, it will show up in the next major release of Asterisk. -- Tilghman ___ -- 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
Re: [asterisk-users] Realtime status feature - user feedback needed
On Thu, May 8, 2008 at 1:07 AM, Tilghman Lesher [EMAIL PROTECTED] wrote: On Wednesday 07 May 2008 16:11:05 Atis Lezdins wrote: 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. That's not quite correct, either. First of all, the correct forum for this is the -dev list, where we discuss development issues. Second, we gave you an alternative way to do this. You could do this with AMI, with the addition of a single query to access current state, then monitor status continuously for updates. And third, it doesn't make a difference how many users request a particular interface -- the development team has to maintain it afterwards, and if you're proposing a new interface, you need to convince the development team that it's worth the extra hassle -- not the users. True, but resistance I encountered gave me impression that there's no way how to convince devs except lot of users asking for this, so i want to see who would find this useful. I hope that this would convince the development team. So we're not opposed to the concept; we are opposed to the particular interface that you chose to use. Modify it, and it will make its way back into Asterisk. Stubbornly stamping your foot and insisting that you have the right way, and the status quo will remain. Unfortunately the concept I'm offering is that There's no need for continuous AMI connection. Current state can be retrieved already (but that needs locking), and incremental updates are available too (but that needs continuous AMI connection). So all together - I'm saying there could be really simple interface for all this - no troubles with locking of lists or keeping persistent connections. Why would user application need to take care of all this, if DB engine can do that. *** 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 Please don't. We've already discussed this to enough detail, and if you choose to modify your code, it will show up in the next major release of Asterisk. I understand that code have to match certain standards, coding guidelines and architecture. I'm willing to do any of this, but so far i see all the discussions are about concept. 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
Re: [asterisk-users] Realtime status feature - user feedback needed
On Wednesday 07 May 2008 17:27:33 Atis Lezdins wrote: So all together - I'm saying there could be really simple interface for all this - no troubles with locking of lists or keeping persistent connections. Why would user application need to take care of all this, if DB engine can do that. Your question leads to this question: why don't you create a proxy application that listens on AMI and populates a database outside of Asterisk, then do all your queries to that database? That would provide exactly the same functionality, but it would not require a single change to the Asterisk codebase. You could even contribute that application back as something in the contrib/scripts subdirectory. -- Tilghman ___ -- 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
Re: [asterisk-users] Realtime status feature - user feedback needed
Tilghman Lesher a écrit : On Wednesday 07 May 2008 17:27:33 Atis Lezdins wrote: So all together - I'm saying there could be really simple interface for all this - no troubles with locking of lists or keeping persistent connections. Why would user application need to take care of all this, if DB engine can do that. Your question leads to this question: why don't you create a proxy application that listens on AMI and populates a database outside of Asterisk, then do all your queries to that database? That would provide exactly the same functionality, but it would not require a single change to the Asterisk codebase. You could even contribute that application back as something in the contrib/scripts subdirectory. I second that, If there is already a way to do things, why adding another one, especialy if it's for caching reasons. While we cannot say that asterisk fall into the KISS rule, it's not a reason to let it grow. -- Benoit Plessis +33 6 77 42 78 32 [EMAIL PROTECTED] +33 4 67 28 06 96 ___ -- 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
Re: [asterisk-users] Realtime status feature - user feedback needed
On Thu, May 8, 2008 at 1:23 AM, Benoit Plessis [EMAIL PROTECTED] wrote: Tilghman Lesher a écrit : Your question leads to this question: why don't you create a proxy application that listens on AMI and populates a database outside of Asterisk, then do all your queries to that database? That would provide exactly the same functionality, but it would not require a single change to the Asterisk codebase. You could even contribute that application back as something in the contrib/scripts subdirectory. I second that, If there is already a way to do things, why adding another one, especialy if it's for caching reasons. While we cannot say that asterisk fall into the KISS rule, it's not a reason to let it grow. Agreed. There should be ONE to do it, it should be SIMPLE and as RELIABLE as possible, without interfereing (bad spelling?) with asterisk's operations: the proxy into AMI looks like the way to acheive the required funcionality... After all, that's exactly the purpose of AMI ! Let's keep the codebase as small as possible, let's make asterisk as solid and reliable as possible. Let's not reinvent wheels! -- exvito ___ -- 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
Re: [asterisk-users] Realtime status feature - user feedback needed
On Thu, May 8, 2008 at 3:49 AM, Ex Vito [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:23 AM, Benoit Plessis [EMAIL PROTECTED] wrote: Tilghman Lesher a écrit : Your question leads to this question: why don't you create a proxy application that listens on AMI and populates a database outside of Asterisk, then do all your queries to that database? That would provide exactly the same functionality, but it would not require a single change to the Asterisk codebase. You could even contribute that application back as something in the contrib/scripts subdirectory. True, that was one of initial options, however I prefer to NOT have yet another layer. I will consider this as an option where appropriate. However this looks quite awkward to me, somehow it reminds me tailing queue_log or CDR and putting result into MySQL database.. just one level more that way. For now, I see only one point against this - having status cleared upon module load/unload makes it easier to follow restarts/module loads. I second that, If there is already a way to do things, why adding another one, especialy if it's for caching reasons. While we cannot say that asterisk fall into the KISS rule, it's not a reason to let it grow. Agreed. There should be ONE to do it, it should be SIMPLE and as RELIABLE as possible, without interfereing (bad spelling?) with asterisk's operations: the proxy into AMI looks like the way to acheive the required funcionality... After all, that's exactly the purpose of AMI ! Let's keep the codebase as small as possible, let's make asterisk as solid and reliable as possible. Let's not reinvent wheels! Ok, so we're exactly at the point. Yes, I agree that it would act nearly the same way as AMI actions, however there's one great advantage - It would be really easy to set this up for user. AMI proxy would take more effort, need configuration, etc. Then there should be much more development support for proxy than for code within asterisk (if you have noticed, there's no new code, just reusing existing functionality) I think that there should be several ways how to do something, not just one. Having realtime status won't mean that much changes, for now I can see only 4 families for this - queue_members (already existing), queue_callers, channels and meetme. Really nothing more to give full overview of Asterisk Status. 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
