VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
atis at iq-labs.net
Guest
|
 Posted: Wed May 07, 2008 4:11 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
 |
|
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,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835 |
|
| Back to top |
|
 |
philipp.kempgen at amo...
Guest
|
| Posted: Wed May 07, 2008 4:41 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
Atis Lezdins schrieb:
| Quote: | 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.
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 |
|
| Back to top |
|
|
tilghman at mail.jeffa...
Guest
|
| Posted: Wed May 07, 2008 5:07 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
On Wednesday 07 May 2008 16:11:05 Atis Lezdins wrote:
| Quote: | 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.
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 |
|
| Back to top |
|
|
atis at iq-labs.net
Guest
|
| Posted: Wed May 07, 2008 5:27 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
On Thu, May 8, 2008 at 1:07 AM, Tilghman Lesher
<tilghman at mail.jeffandtilghman.com> wrote:
| Quote: | On Wednesday 07 May 2008 16:11:05 Atis Lezdins wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: |
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,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835 |
|
| Back to top |
|
|
tilghman at mail.jeffa...
Guest
|
| Posted: Wed May 07, 2008 6:02 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
On Wednesday 07 May 2008 17:27:33 Atis Lezdins wrote:
| Quote: | 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 |
|
| Back to top |
|
|
benoit at plessis.info
Guest
|
| Posted: Wed May 07, 2008 7:23 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
Tilghman Lesher a ?crit :
| Quote: | On Wednesday 07 May 2008 17:27:33 Atis Lezdins wrote:
| Quote: | 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
<benoit at plessis.info> +33 4 67 28 06 96 |
|
| Back to top |
|
|
atis at iq-labs.net
Guest
|
| Posted: Wed May 07, 2008 8:27 pm Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
On Thu, May 8, 2008 at 3:49 AM, Ex Vito <ex.vitorino at gmail.com> wrote:
| Quote: | On Thu, May 8, 2008 at 1:23 AM, Benoit Plessis <benoit at plessis.info> wrote:
| Quote: | Tilghman Lesher a ?crit :
|
| Quote: | | Quote: | 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.
| Quote: | | Quote: | 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,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835 |
|
| Back to top |
|
|
darren at aleph-com.net
Guest
|
| Posted: Thu May 08, 2008 1:10 am Post subject: [asterisk-users] Realtime status feature - user feedback nee |
|
|
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
darren at aleph-com.net
Atis Lezdins wrote:
| Quote: | On Thu, May 8, 2008 at 3:49 AM, Ex Vito <ex.vitorino at gmail.com> wrote:
| Quote: | On Thu, May 8, 2008 at 1:23 AM, Benoit Plessis <benoit at plessis.info> wrote:
| Quote: | Tilghman Lesher a ?crit :
|
| Quote: | | Quote: | Your question leads to this question: why don't you create a proxy
|
| Quote: | 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.
| Quote: | | Quote: | 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
|
|
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
