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
