[asterisk-users] Querying channel variables via the Manager API

[Earl Terwilliger]

Hi Lenz,

Why not do it the same way as you do the queue log (for queuemetrics)?
i.e. have a program which captures all events (or certain events), logs them 
to a MySql database and then you just query the database.

There are many packages out there that run an Asterisk manager command at 
frequent intervals to obtain what they want. To me (as you have found this is 
very inefficient).

I have an open source package called Asterisk Event Monitor that has a python 
script (ah.. I think you like perl better?  but I like python) that connects 
to the Asterisk Manager and logs all events to a MySql table. There are PHP 
scripts that show the events and display the status of sip users, zap 
channels,etc. but you don't need that. The python script is similar to your 
qloader script in that my script grabs all the events and writes them to a 
MySql database. Anything you need to see is thus more efficiently extracted 
from the database table.

any question about it , holler..

the code is here:

	http://www.micpc.com/eventmonitor

earl

On Tuesday 17 April 2007 17:32, Lenz wrote:
> Hello list,
> we are developing a new application that uses the Manager API in order to
> find a set of channels where variables are set in a predefined way. To do
> this, we currently send a Status command to obtain all available channels
> and then query them all, one by one, fot the status of a certain dialplan
> variable. As you can imagine, this gets rapidly pretty tedious as the
> number of active channels on a server grows and requires a lot of
> round-trips to and from the Asterisk server.
>
> I was wondering if there are more efficient ways to get:
> 1. a variable as set on all channels
> 2. the complete list of channel variables for one channel, using standard
> manager response block and not reverting to an execute CLI command " show
> channel Local/1234 at x "
>
> Anybody has ideas/hints on how to make all this a bit less cumbersome?
> Best regards,
> l.